4 \chapter{Katalog Verwaltung}
5 \label{CatMaintenanceChapter}
6 \index[general]{Verwaltung!Katalog }
7 \index[general]{Katalog Verwaltung}
9 Ohne eine ordnungsgem\"{a}{\ss}e Einrichtung und Verwaltung kann es sein,
10 dass Ihr Katalog immer gr\"{o}{\ss}er wird wenn Jobs laufen und Daten gesichert werden.
11 Zudem kann der Katalog ineffizient und langsam werden. Wie schnell der Katalog w\"{a}chst,
12 h\"{a}ngt von der Anzahl der Jobs und der Menge der dabei gesicherten Dateien ab.
13 Durch das L\"{o}schen von Eintr\"{a}gen im Katalog kann Platz geschaffen werden f\"{u}r
14 neue Eintr\"{a}ge der folgenden Jobs. Durch regelm\"{a}{\ss}iges l\"{o}schen alter abgelaufener
15 Daten (\"{a}lter als durch die Aufbewahrungszeitr\"{a}ume (Retention Periods) angegeben),
16 wird daf\"{u}r gesorgt, dass die Katalog-Datenbank eine konstante Gr\"{o}{\ss}e beibeh\"{a}lt.
18 Sie k\"{o}nnen mit der vorgegebenen Konfiguration beginnen, sie enth\"{a}lt bereits
19 sinnvolle Vorgaben f\"{u}r eine kleine Anzahl von Clients (kleiner 5), in diesem Fall
20 wird die Katalogwartung, wenn Sie einige hundert Megabytes freien Plattenplatz haben,
21 nicht dringlich sein. Was aber auch immer der Fall ist, einiges Wissen \"{u}ber
22 die Retention Periods/Aufbewahrungszeitr\"{a}ume der Daten im Katalog und auf den Volumes ist hilfreich.
24 \section{Einstellung der Aufbewahrungszeitr\"{a}ume}
26 \index[general]{Einstellung der Aufbewahrungszeitr\"{a}ume }
27 \index[general]{Zeitr\"{a}ume!Einstellung der Aufbewahrungs- }
29 Bacula benutzt drei verschiedene Aufbewahrungszeitr\"{a}ume:
30 die {\bf File Retention}: der Aufbewahrungszeitraum f\"{u}r Dateien,
31 die {\bf Job Retention}: der Aufbewahrungszeitraum f\"{u}r Jobs und
32 die {\bf Volume Retention}: der Aufbewahrungszeitraum f\"{u}r Volumes.
33 Von diesen drei ist der Aufbewahrungszeitraum f\"{u}r Dateien der entscheidende,
34 wenn es darum geht, wie gro{\ss} die Datenbank werden wird.
36 Die {\bf File Retention} und die {\bf Job Retention} werden in der Client-Konfiguration,
37 wie unten gezeigt, angegeben. Die {\bf Volume Retention} wird in der Pool-Konfiguration
38 angegeben, genauere Informationen dazu finden Sie im n\"{a}chsten Kapitel dieses Handbuchs.
42 \item [File Retention = \lt{}time-period-specification\gt{}]
43 \index[dir]{File Retention }
44 Der Aufbewahrungszeitraum f\"{u}r Dateien gibt die Zeitspanne an, die die
45 Datei-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden.
46 Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist,
47 wird Bacula die Katalog-Eintr\"{a}ge der Dateien l\"{o}schen, die \"{a}lter als
48 dieser Zeitraum sind. Das L\"{o}schen erfolgt nach Beendigung eines Jobs des entsprechenden Clients.
49 Bitte beachten Sie, dass die Client-Datenbank-Eintr\"{a}ge eine Kopie der Aufbewahrungszeitr\"{a}ume
50 f\"{u}r Dateien und Jobs enthalten, Bacula aber die Zeitr\"{a}ume aus der aktuellen Client-Konfiguration
51 des Director-Dienstes benutzt um alte Katalog-Eintr\"{a}ge zu l\"{o}schen.
53 Da die Datei-Eintr\"{a}ge ca. 80 Prozent der Katalog-Datenbankgr\"{o}{\ss}e ausmachen,
54 sollten Sie sorgf\"{a}lltig ermitteln \"{u}ber welchen Zeitraum Sie die Eintr\"{a}ge aufbewahren wollen.
55 Nachdem die Datei-Eintr\"{a}ge ge\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien
56 mit einem R\"{u}cksicherungs-Job wiederherzustellen, aber die Bacula-Versionen 1.37 und sp\"{a}ter
57 sind in der Lage, aufgrund des Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern
58 solange der Job-Eintrag im Katalog vorhanden ist.
60 Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
61 eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen,
62 Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
63 dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
65 Der Standardwert der Aufbewahrungszeit f\"{u}r Dateien ist 60 Tage.
67 \item [Job Retention = \lt{}time-period-specification\gt{}]
68 \index[dir]{Job Retention }
69 Der Aufbewahrungszeitraum f\"{u}r Jobs gibt die Zeitspanne an, die die
70 Job-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden.
71 Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist,
72 wird Bacula die Katalog-Eintr\"{a}ge der Jobs l\"{o}schen, die \"{a}lter als
73 dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag ge\"{o}scht wird,
74 auch alle zu diesem Job geh\"{o}renden Datei- und JobMedia-Eintr\"{a}ge aus dem
75 Katalog gel\"{o}scht werden. Dies passiert unabh\"{a}ngig von der Aufbewahrungszeit f\"{u}r Dateien,
76 infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rzer sein als f\"{u}r Jobs.
78 Wie oben erw\"{a}hnt, sind Sie nicht mehr in der Lage einzelne Dateien eines Jobs zur\"{u}ckzusichern,
79 wenn die Datei-Eintr\"{a}ge aus der Katalog-Datenbank entfernt wurden. Jedoch, solange der Job-Eintrag
80 im Katalog vorhanden ist, k\"{o}nnen Sie immer noch den kompletten Job mit allen Dateien wiederherstellen
81 (mit Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog
82 l\"{a}nger als die Datei-Eintr\"{a}ge aufzubewahren.
84 Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
85 eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen,
86 Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
87 dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
89 Der Standardwert der Aufbewahrungszeit f\"{u}r Jobs ist 180 Tage.
91 \item [AutoPrune = \lt{}yes/no\gt{}]
92 \index[dir]{AutoPrune }
93 Wenn AutoPrune auf {\bf yes} (Standard) gesetzt ist, wird Bacula nach jedem Job
94 automatisch \"{u}berpr\"{u}fen, ob die Aufbewahrungszeit f\"{u}r bestimmte Dateien und/oder Jobs
95 des gerade gesicherten Clients abgelaufen ist und diese aus dem Katalog entfernen.
96 Falls Sie AutoPrune durch das Setzen auf {\bf no} ausschalten, wird Ihre Katalog-Datenbank mit jedem
97 gelaufenen Job immer gr\"{o}{\ss}er werden.
100 \label{CompactingMySQL}
101 \section{Komprimieren Ihrer MySQL Datenbank}
102 \index[general]{Datenbank!Komprimieren Ihrer MySQL }
103 \index[general]{Komprimieren Ihrer MySQL Datenbank }
105 Mit der Zeit, wie oben schon angemerkt, wird Ihre Datenbank dazu neigen zu wachsen.
106 Auch wenn Bacula regelm\"{a}{\ss}ig Datei-Eintr\"{a}ge l\"{o}scht, wird die {\bf MySQL}-Datenbank
107 st\"{a}ndig gr\"{o}{\ss}er werden. Um dies zu vermeiden, muss die Datenbank komprimiert werden.
108 Normalerweise kennen gro{\ss}e kommerzielle Datenbanken, wie Oracle, bestimmte Kommandos
109 um den verschwendeten Festplattenplatz wieder freizugeben. MySQL hat das {\bf OPTIMIZE TABLE}
110 Kommando und bei SQLite (Version 2.8.4 und gr\"{o}{\ss}er) k\"{o}nnen Sie das {\bf VACUUM}
111 Kommando zu diesem Zweck benutzen. Wir \"{u}berlassen es Ihnen, die N\"{u}tzlichkeit von
112 {\bf OPTIMIZE TABLE} oder {\bf VACUUM} zu ermitteln.
114 Alle Datenbanken haben Hilfsmittel, um die enthaltenen Daten im ASCII-Format in eine Datei zu schreiben
115 und diese Datei dann auch wieder einzulesen. Wenn man das tut, wird die Datenbank erneut erzeugt, was ein
116 sehr kompaktes Datenbank-Format als Ergebnis hat. Weiter unten zeigen wir Ihnen, wie Sie das bei
117 MySQL, SQLite und PostgreSQL durchf\"{u}hren k\"{o}nnen.
119 Bei einer {\bf MySQL} Datenbank k\"{o}nnen Sie den Inhalt der Katalog-Datenbank mit den folgenden Kommandos
120 in eine ASCII-Datei (bacula.sql) schreiben und neu in die Datenbank importieren:
124 mysqldump -f --opt bacula > bacula.sql
125 mysql bacula < bacula.sql
130 Abh\"{a}gig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
131 ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenabnk liegt (typischerweise
132 /var/lib/mysql) und diese Kommando ausf\"{u}hre:
140 bekomme ich die Ausgabe {\bf 620,644}, was bedeutet dass das Verzeichnis bacula 620.644 Bl\"{o}cke
141 von 1024 Bytes auf der Festplatte belegt, meine Datenbank enth\"{a}lt also ca. 635 MB an Daten.
142 Nachdem ich das {\bf mysqldump} ausgef\"{u}hrt habe, ist die dabei entstandene Datei bacula.sql
143 {\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei wieder mit dem Kommando {\bf mysql bacula < bacula.sql}
144 in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464}
145 Bl\"{o}cken. Mit anderen Worten, die komprimierte Version meiner Datenbank, die seit ca. 1 Jahr
146 in Benutzung ist, ist ungef\"{a}hr nur noch ein Drittel so gro{\ss} wie vorher.
148 Als Konsequenz wird empfohlen, auf die Gr\"{o}{\ss}e der Datenbank zu achten und sie von Zeit zu Zeit
149 (alle sechs Monate oder j\"{a}hrlich) zu komprimieren.
151 \label{DatabaseRepair}
152 \label{RepairingMySQL}
153 \section{Reparatur Ihrer MySQL Datenbank}
154 \index[general]{Datenbank!Reparatur Ihrer MySQL }
155 \index[general]{Reparatur Ihrer MySQL Datenbank }
157 Wenn Sie bemerken, dass das Schreiben der MySQL-Datenbank zu Fehlern f\"{u}hrt,
158 oder das der Director-Dienst h\"{a}ngt, wenn er auf die Datenbank zugreift,
159 sollten Sie sich die MySQL Datenbank\"{u}berpr\"{u}fungs- und Reparaturprogramme ansehen.
160 Welches Programm Sie laufen lassen sollten, h\"{a}ngt von der von Ihnen benutzten Datenbank-
161 Indizierung zusammen. Wenn Sie das Standardverfahren nutzen, werden Sie vermutlich {\bf myisamchk}
162 laufen lassen. F\"{a}r n\"{a}here Information lesen Sie bitte auch:
163 \elink{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}
164 {http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}.
166 Falls die auftretenden Fehler einfache SQL-Warnungen sind, sollten Sie zuerst das von Bacula mitgelieferte
167 dbcheck-Programm ausf\"{u}hren, bevor Sie die MySQL-Datenbank-Reparaturprogramme nutzen.
168 Dieses Programm kann verwaiste Datenbankeintr\"{a}ge finden und andere Inkonsistenzen in der
169 Katalog-Datenbank beheben.
171 Eine typische Ursache von Datenbankproblemen ist das Volllaufen einer Partition.
172 In solch einem Fall muss entweder zus\"{a}tzlicher Platz geschaffen werden, oder
173 belegter Platz freigegeben werden, bevor die Datenbank mit {\bf myisamchk} repariert werden kann.
175 Recently my root partition filled and the MySQL database was corrupted.
176 Simply running {\bf myisamchk -r} did not fix the problem. However,
177 the following script did the trick for me:
184 t=`echo $i | cut -f 1 -d '.' -`
185 mysql bacula <<END_OF_DATA
191 chown mysql:mysql ${i}
197 I invoked it with the following commands:
201 cd /var/lib/mysql/bacula
206 Then after ensuring that the database was correctly fixed, I did:
209 cd /var/lib/mysql/bacula
214 \section{MySQL Table is Full}
215 \index[general]{Database!MySQL Table is Full}
216 \index[general]{MySQL Table is Full}
218 If you are running into the error {\bf The table 'File' is full ...},
219 it is probably because on version 4.x MySQL, the table is limited by
220 default to a maximum size of 4 GB and you have probably run into
221 the limit. The solution can be found at:
222 \elink{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
223 {http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
225 You can display the maximum length of your table with:
230 SHOW TABLE STATUS FROM bacula like "File";
234 If the column labeled "Max\_data\_length" is around 4Gb, this is likely
235 to be the source of your problem, and you can modify it with:
240 ALTER TABLE File MAX_ROWS=281474976710656;
244 Alternatively you can modify your /etc/my.conf file before creating the
245 Bacula tables, and in the [mysqld] section set:
249 set-variable = myisam_data_pointer_size=6
253 The above myisam data pointer size must be made before you create your
254 Bacula tables or it will have no effect.
256 The row and pointer size changes should already be the default on MySQL
257 version 5.x, so making these changes should only be necessary on MySQL 4.x
258 depending on the size of your catalog database.
260 \section{MySQL Server Has Gone Away}
261 \index[general]{Database!MySQL Server Has Gone Away}
262 \index[general]{MySQL Server Has Gone Away}
263 If you are having problems with the MySQL server disconnecting or with
264 messages saying that your MySQL server has gone away, then please read
265 the MySQL documentation, which can be found at:
267 \elink{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
268 {http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
271 \label{RepairingPSQL}
272 \section{Repairing Your PostgreSQL Database}
273 \index[general]{Database!Repairing Your PostgreSQL }
274 \index[general]{Repairing Your PostgreSQL Database }
276 The same considerations apply that are indicated above for MySQL. That is,
277 consult the PostgreSQL documents for how to repair the database, and also
278 consider using Bacula's dbcheck program if the conditions are reasonable for
281 \label{DatabasePerformance}
282 \section{Database Performance Issues}
283 \index[general]{Database Performance Issues}
284 \index[general]{Performance!Database}
286 There are a considerable number of ways each of the databases can be
287 tuned to improve the performance. Going from an untuned database to one
288 that is properly tuned can make a difference of a factor of 100 or more
289 in the time to insert or search for records.
291 For each of the databases, you may get significant improvements by adding
292 additional indexes. The comments in the Bacula make\_xxx\_tables give some
293 indications as to what indexes may be appropriate. Please see below
294 for specific instructions on checking indexes.
296 For MySQL, what is very important is to use the examine the
297 my.cnf file (usually in /etc/my.cnf).
298 You may obtain significant performances by switching to
299 the my-large.cnf or my-huge.cnf files that come with the MySQL source
302 For SQLite3, one significant factor in improving the performance is
303 to ensure that there is a "PRAGMA synchronous = NORMAL;" statement.
304 This reduces the number of times that the database flushes the in memory
305 cache to disk. There are other settings for this PRAGMA that can
306 give even further performance improvements at the risk of a database
307 corruption if your system crashes.
309 For PostgreSQL, you might want to consider turning fsync off. Of course
310 doing so can cause corrupted databases in the event of a machine crash.
311 There are many different ways that you can tune PostgreSQL, the
312 following document discusses a few of them:
314 http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
315 {http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
317 There is also a PostgreSQL FAQ question number 3.3 that may
318 answer some of your questions about how to improve performance
319 of the PostgreSQL engine:
321 http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}
322 {http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}.
323 % TODO: verify above is correct. is this okay for book?
325 Also for PostgreSQL, look at what "effective\_cache\_size". For a 2GB memory
326 machine, you probably want to set it at 131072, but don't set it too high.
327 In addition, for a 2GB system, work\_mem = 256000 and
328 maintenance\_work\_mem = 256000 seem to be reasonable values. Make
329 sure your checkpoint\_segments is set to at least 8.
333 \section{Performance Issues Indexes}
334 \index[general]{Database Performance Issues Indexes}
335 \index[general]{Performance!Database}
336 One of the most important considerations for improving performance on
337 the Bacula database is to ensure that it has all the appropriate indexes.
338 Several users have reported finding that their database did not have
339 all the indexes in the default configuration. In addition, you may
340 find that because of your own usage patterns, you need additional indexes.
342 The most important indexes for performance are the three indexes on the
343 {\bf File} table. The first index is on {\bf FileId} and is automatically
344 made because it is the unique key used to access the table. The other
345 two are the JobId index and the (Filename, PathId) index. If these Indexes
346 are not present, your performance may suffer a lot.
348 \subsection{PostgreSQL Indexes}
349 On PostgreSQL, you can check to see if you have the proper indexes using
350 the following commands:
355 select * from pg_indexes where tablename='file';
359 If you do not see output that indicates that all three indexes
360 are created, you can create the two additional indexes using:
365 CREATE INDEX file_jobid_idx on file (jobid);
366 CREATE INDEX file_fp_idx on file (filenameid, pathid);
370 \subsection{MySQL Indexes}
371 On MySQL, you can check if you have the proper indexes by:
376 show index from File;
380 If the indexes are not present, especially the JobId index, you can
381 create them with the following commands:
386 CREATE INDEX file_jobid_idx on File (JobId);
387 CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId);
391 Though normally not a problem, you should ensure that the indexes
392 defined for Filename and Path are both set to 255 characters. Some users
393 reported performance problems when their indexes were set to 50 characters.
399 show index from Filename;
400 show index from Path;
404 and what is important is that for Filename, you have an index with
405 Key\_name "Name" and Sub\_part "255". For Pth, you should have a Key\_name
406 "Path" and Sub\_part "255". If one or the other does not exist or the
407 Sub\_part is less that 255, you can drop and recreate the appropriate
413 DROP INDEX Path on Path;
414 CREATE INDEX Path on Path (Path(255);
416 DROP INDEX Name on Filename;
417 CREATE INDEX Name on Filename (Name(255));
422 \subsection{SQLite Indexes}
423 On SQLite, you can check if you have the proper indexes by:
427 sqlite <path>bacula.db
428 select * from sqlite_master where type='index' and tbl_name='File';
432 If the indexes are not present, especially the JobId index, you can
433 create them with the following commands:
438 CREATE INDEX file_jobid_idx on File (JobId);
439 CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId);
445 \label{CompactingPostgres}
446 \section{Compacting Your PostgreSQL Database}
447 \index[general]{Database!Compacting Your PostgreSQL }
448 \index[general]{Compacting Your PostgreSQL Database }
450 Over time, as noted above, your database will tend to grow. I've noticed that
451 even though Bacula regularly prunes files, PostgreSQL has a {\bf VACUUM}
452 command that will compact your database for you. Alternatively you may want to
453 use the {\bf vacuumdb} command, which can be run from a cron job.
455 All database programs have some means of writing the database out in ASCII
456 format and then reloading it. Doing so will re-create the database from
457 scratch producing a compacted result, so below, we show you how you can do
460 For a {\bf PostgreSQL} database, you could write the Bacula database as an
461 ASCII file (bacula.sql) then reload it by doing the following:
465 pg_dump -c bacula > bacula.sql
466 cat bacula.sql | psql bacula
471 Depending on the size of your database, this will take more or less time and a
472 fair amount of disk space. For example, you can {\bf cd} to the location of
473 the Bacula database (typically /usr/local/pgsql/data or possible
474 /var/lib/pgsql/data) and check the size.
476 There are certain PostgreSQL users who do not recommend the above
477 procedure. They have the following to say:
479 need to be dumped/restored to keep the database efficient. A normal
480 process of vacuuming will prevent the database from every getting too
481 large. If you want to fine-tweak the database storage, commands such
482 as VACUUM FULL, REINDEX, and CLUSTER exist specifically to keep you
483 from having to do a dump/restore.
485 Finally, you might want to look at the PostgreSQL documentation on
487 \elink{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}
488 {http://www.postgresql.org/docs/8.1/interactive/maintenance.html}.
490 \section{Compacting Your SQLite Database}
491 \index[general]{Compacting Your SQLite Database }
492 \index[general]{Database!Compacting Your SQLite }
494 First please read the previous section that explains why it is necessary to
495 compress a database. SQLite version 2.8.4 and greater have the {\bf Vacuum}
496 command for compacting the database.
500 cd {\bf working-directory}
501 echo 'vacuum;' | sqlite bacula.db
505 As an alternative, you can use the following commands, adapted to your system:
510 cd {\bf working-directory}
511 echo '.dump' | sqlite bacula.db > bacula.sql
513 sqlite bacula.db < bacula.sql
518 Where {\bf working-directory} is the directory that you specified in the
519 Director's configuration file. Note, in the case of SQLite, it is necessary to
520 completely delete (rm) the old database before creating a new compressed
523 \section{Migrating from SQLite to MySQL}
524 \index[general]{MySQL!Migrating from SQLite to }
525 \index[general]{Migrating from SQLite to MySQL }
527 You may begin using Bacula with SQLite then later find that you want to switch
528 to MySQL for any of a number of reasons: SQLite tends to use more disk than
529 MySQL; when the database is corrupted it is often more catastrophic than
530 with MySQL or PostgreSQL.
531 Several users have succeeded in converting from SQLite to MySQL by
532 exporting the MySQL data and then processing it with Perl scripts
533 prior to putting it into MySQL. This is, however, not a simple
536 \label{BackingUpBacula}
537 \section{Backing Up Your Bacula Database}
538 \index[general]{Backing Up Your Bacula Database }
539 \index[general]{Database!Backing Up Your Bacula }
541 If ever the machine on which your Bacula database crashes, and you need to
542 restore from backup tapes, one of your first priorities will probably be to
543 recover the database. Although Bacula will happily backup your catalog
544 database if it is specified in the FileSet, this is not a very good way to do
545 it, because the database will be saved while Bacula is modifying it. Thus the
546 database may be in an instable state. Worse yet, you will backup the database
547 before all the Bacula updates have been applied.
549 To resolve these problems, you need to backup the database after all the backup
550 jobs have been run. In addition, you will want to make a copy while Bacula is
551 not modifying it. To do so, you can use two scripts provided in the release
552 {\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
553 will be automatically generated along with all the other Bacula scripts. The
554 first script will make an ASCII copy of your Bacula database into {\bf
555 bacula.sql} in the working directory you specified in your configuration, and
556 the second will delete the {\bf bacula.sql} file.
558 The basic sequence of events to make this work correctly is as follows:
561 \item Run all your nightly backups
562 \item After running your nightly backups, run a Catalog backup Job
563 \item The Catalog backup job must be scheduled after your last nightly backup
565 \item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf
566 RunAfterJob} to clean up
569 Assuming that you start all your nightly backup jobs at 1:05 am (and that they
570 run one after another), you can do the catalog backup with the following
571 additional Director configuration statements:
575 # Backup the catalog database (after the nightly save)
577 Name = "BackupCatalog"
581 Schedule = "WeeklyCycleAfterBackup"
585 RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
586 RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
587 Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
589 # This schedule does the catalog. It starts after the WeeklyCycle
591 Name = "WeeklyCycleAfterBackup
592 Run = Level=Full sun-sat at 1:10
594 # This is the backup of the catalog
601 File = \lt{}working_directory\gt{}/bacula.sql
607 Be sure to write a bootstrap file as in the above example. However, it is preferable
608 to write or copy the bootstrap file to another computer. It will allow
609 you to quickly recover the database backup should that be necessary. If
610 you do not have a bootstrap file, it is still possible to recover your
611 database backup, but it will be more work and take longer.
613 \label{BackingUPOtherDBs}
614 \section{Backing Up Third Party Databases}
615 \index[general]{Backing Up Third Party Databases }
616 \index[general]{Databases!Backing Up Third Party }
618 If you are running a database in production mode on your machine, Bacula will
619 happily backup the files, but if the database is in use while Bacula is
620 reading it, you may back it up in an unstable state.
622 The best solution is to shutdown your database before backing it up, or use
623 some tool specific to your database to make a valid live copy perhaps by
624 dumping the database in ASCII format. I am not a database expert, so I cannot
625 provide you advice on how to do this, but if you are unsure about how to
626 backup your database, you might try visiting the Backup Central site, which
627 has been renamed Storage Mountain (www.backupcentral.com). In particular,
629 \elink{ Free Backup and Recovery
630 Software}{http://www.backupcentral.com/toc-free-backup-software.html} page has
631 links to scripts that show you how to shutdown and backup most major
635 \section{Database Size}
636 \index[general]{Size!Database }
637 \index[general]{Database Size }
639 As mentioned above, if you do not do automatic pruning, your Catalog will grow
640 each time you run a Job. Normally, you should decide how long you want File
641 records to be maintained in the Catalog and set the {\bf File Retention}
642 period to that time. Then you can either wait and see how big your Catalog
643 gets or make a calculation assuming approximately 154 bytes for each File
644 saved and knowing the number of Files that are saved during each backup and
645 the number of Clients you backup.
647 For example, suppose you do a backup of two systems, each with 100,000 files.
648 Suppose further that you do a Full backup weekly and an Incremental every day,
649 and that the Incremental backup typically saves 4,000 files. The size of your
650 database after a month can roughly be calculated as:
654 Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26)
658 where we have assumed four weeks in a month and 26 incremental backups per month.
659 This would give the following:
663 Size = 154 * 2 * (100,000 * 4 + 10,000 * 26)
665 Size = 308 * (400,000 + 260,000)
667 Size = 203,280,000 bytes
671 So for the above two systems, we should expect to have a database size of
672 approximately 200 Megabytes. Of course, this will vary according to how many
673 files are actually backed up.
675 Below are some statistics for a MySQL database containing Job records for five
676 Clients beginning September 2001 through May 2002 (8.5 months) and File
677 records for the last 80 days. (Older File records have been pruned). For these
678 systems, only the user files and system files that change are backed up. The
679 core part of the system is assumed to be easily reloaded from the Red Hat rpms.
682 In the list below, the files (corresponding to Bacula Tables) with the
683 extension .MYD contain the data records whereas files with the extension .MYI
686 You will note that the File records (containing the file attributes) make up
687 the large bulk of the number of records as well as the space used (459 Mega
688 Bytes including the indexes). As a consequence, the most important Retention
689 period will be the {\bf File Retention} period. A quick calculation shows that
690 for each File that is saved, the database grows by approximately 150 bytes.
696 ============ ========= ===========
699 344,394,684 3,080,191 File.MYD
701 2,590,316 106,902 Filename.MYD
702 3,026,944 Filename.MYI
705 49,062 1,326 JobMedia.MYD
707 141,752 1,378 Job.MYD
711 1,299,512 22,233 Path.MYD
720 This database has a total size of approximately 450 Megabytes.
722 If we were using SQLite, the determination of the total database size would be
723 much easier since it is a single file, but we would have less insight to the
724 size of the individual tables as we have in this case.
726 Note, SQLite databases may be as much as 50\% larger than MySQL databases due
727 to the fact that all data is stored as ASCII strings. That is even binary
728 integers are stored as ASCII strings, and this seems to increase the space