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-Datenbank 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 Hier ist ein Beispiel, wie man eine korrupte Datenbank reparieren k\"{o}nnte, falls nach dem Vollaufen
176 einer Partition die Datenbankprobleme mit {\bf myisamchk -r} nicht behoben werden k\"{o}nnen:
178 kopieren Sie folgende Zeilen in ein Shell-Script names {\bf repair}:
184 t=`echo $i | cut -f 1 -d '.' -`
185 mysql bacula <<END_OF_DATA
191 chown mysql:mysql ${i}
197 dieses Shell-Script, wird dann wie folgt aufgerufen:
201 cd /var/lib/mysql/bacula
206 nachdem sichergestellt ist, dass die Datenbank wieder korrekt funktioniert,
207 kann man die alten Datenbank-Dateien l\"{o}schen:
210 cd /var/lib/mysql/bacula
215 \section{MySQL-Tabelle ist voll}
216 \index[general]{Datenbank!MySQL-Tabelle ist voll}
217 \index[general]{MySQL-Tabelle ist voll}
219 Falls ein Fehler wie {\bf The table 'File' is full ...} auftritt,
220 passiert das vermutlich, weil bei den MySQL-Versionen 4.x die Tabellengr\"{o}{\ss}e
221 standardm\"{a}{\ss}ig auf 4 GB begrenzt ist und Sie dieses Limit erreicht haben.
222 Hinweise zu der maximal m\"{o}glichen Tabellengr\"{o}{\ss}e gibt es auf
223 \elink{http://dev.mysql.com/doc/refman/5.1/de/table-size.html}{http://dev.mysql.com/doc/refman/5.1/de/table-size.html}
225 Sie k\"{o}nnen sich die maximale Tabellengr\"{o}{\ss}e mit:
230 SHOW TABLE STATUS FROM bacula like "File";
234 anzeigen lassen. Wenn die Spalte {\bf max\_data\_length} ca. 4 GB entspricht,
235 dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\2{o}{\ss}e mittels:
240 ALTER TABLE File MAX_ROWS=281474976710656;
244 anpassen. Alternativ k\"{o}nnen Sie auch die /etc/my.cnf editieren, bevor Sie die Bacula-Tabellen erstellen,
245 setzen Sie im Abschnitt [mysqld]:
249 set-variable = myisam_data_pointer_size=6
254 Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen
255 gesetzt sein, um wirksam zu sein.
257 Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen > 5.x nicht n\"{o}tig sein,
258 somit sind diese \"{A}nderungen nur bei MySQL 4.x, in Abh\"{a}gigkeit von Ihrer Katalog-Datenbank-Gr\"{o}{\ss}e,
261 \section{MySQL-Server Has Gone Away-Fehler}
262 \index[general]{Datenbank!MySQL-Server Has Gone Away-Fehler}
263 \index[general]{MySQL-Server Has Gone Away-Fehler}
264 Fall Sie Probleme damit haben, dass Ihr MySQL-Server nicht mehr erreichbar ist, oder Meldungen wie
265 "MySQL server has gone away" erscheinen, dann lesen Sie bitte die MySQL-Dokumentation auf:
267 \elink{http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
268 {http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
271 \label{RepairingPSQL}
272 \section{Reparatur Ihrer PostgreSQL Datenbank}
273 \index[general]{Datenbank!Reparatur Ihrer PostgreSQL }
274 \index[general]{Reparatur Ihrer PostgreSQL Datenbank}
276 Dieselben \"{U}berlegungen, wie oben f\"{u}r MySQL angef\"{u}hrt, sind auch hier g\"{u}ltig.
277 Lesen Sie die PostgreSQL-Dokumentation um zu erfahren, wie Sie Ihre Datenbank reparieren k\"{o}nnen.
278 Erw\"{a}gen Sie auch den Einsatz von Bacula's dbcheck-Programm, falls es sinnvoll erscheint (siehe oben).
280 \label{DatabasePerformance}
281 \section{Datenbank-Leistung}
282 \index[general]{Datenbank-Leistung}
283 \index[general]{Leistung!Datenbank}
285 Es gibt viele Wege, die verschiedenen von Bacula unterst\"{u}tzten Datenbanken abzustimmen, um ihre Leistung zu erh\"{o}hen.
286 Zwischen einer schlecht und gut abgestimmten Datenbank kann ein Geschwindigkeitsunterschied von 100 und mehr liegen,
287 wenn es darum geht Datenbankeintr\"{a}ge zu schreiben oder zu suchen.
289 Bei jeder der Datenbanken, k\"{o}nnen Sie erhebliche Verbesserungen erwarten, wenn Sie weitere Indexe hinzuf\"{u}gen.
290 Die Kommentare in den Bacula make\_xxx\_tables-Scripts (z.B. make\_postgres\_tables) geben einige Hinweise,
291 wof\"{u}r Indexe geeignet sind. Sehen Sie bitte auch unten f\"{u}r genaue Informationen, wie Sie Ihre Indexe
292 \"{u}berpr\"{u}fen k\"{o}nnen.
294 F\"{u}r MySQL ist es sehr wichtig, die my.cnf-Datei durchzusehen (gw\"{o}hnlich /etc/my.cnf)
295 Eventuell k\"{o}nnen Sie die Leistung wesentlich erh\"{o}hen, wenn Sie die Konfigurationsdateien
296 my-large.cnf oder my-huge.cnf aus dem MySQL-Quellcode verwenden.
298 F\"{u}r SQLite3 ist ein wichtiger Punkt, dass in der Konfiguration die Angabe "PRAGMA synchronous = NORMAL;"
299 vorhanden ist. Dadurch werden die Zeitabst\"{a}nde vergr\"{o}{\ss}ert, in denen die Datenbank ihren RAM-Zwischenspeicher
300 auf die Festplatte schreibt. Es gibt noch andere Einstellungen f\"{u}r PRAGMA die die Effizienz steigern k\"{o}nnen,
301 aber auch das Risiko einer Datenbankbesch\"{a}digung beim Absturz des Systems erh\"{o}hen.
303 Bei PostgreSQL sollten Sie eventuell in Betracht ziehen "fsync'' abzuschalten,
304 aber auch das kann bei Systemabst\"{u}rzen zu Datenbankprobleme f\"{u}hren.
305 Es gibt viele Wege die Leistungsf\"{a}higkeit von PostgreSQL zu steigern,
306 diese Internetseiten erkl\"{a}ren ein paar von ihnen (auf englisch):
307 \elink{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
308 {http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
310 Auch in den PostgreSQL FAQ's finden sich Hinweise die Performanz zu verbessern:
312 http://www.postgresql.org/docs/faqs.FAQ.html#item3.3}
313 {http://www.postgresql.org/docs/faqs.FAQ.html#item3.3}.
315 Bei PostgreSQL sollten Sie auch auf die "effective\_cache\_size" achten.
316 F\"{u}r ein System mit 2GB Arbeitsspeicher k\"{o}nnen Sie sie auf 131072 setzen,
317 aber setzen Sie sie nicht zu hoch. Zus\"{a}tzlich sind "work_mem = 256000" und
318 "maintenance\_work\_mem = 256000", f\"{u}r Systeme mit 2GB Speicher, sinnvolle Werte.
319 Stellen Sie sicher das "checkpoint_segments" auf mindestens 8 gesetzt ist.
321 \section{Datenbank-Leistung und Indexe}
322 \index[general]{Datenbank-Leistung und Indexe}
323 \index[general]{Leistung!Datenbank und Indexe}
324 Eine der wichtigsten Aspekte die Leistungsf\"{a}higkeit der Bacula-Datenbank sicherzustellen ist zu \"{u}berpr\"{u}fen,
325 ob alle Indexe richtig sind. Mehrere Benutzer haben angemerkt, dass ihre Datenbank in der Standardkonfiguration
326 nicht alle notwendigen Indexe hatte. Auch werden Sie eventuell, abh\"{a}ngig von Ihrem Anwendungszweck,
327 zus\"{a}tzlich Indexe ben\"{o}tigen.
329 Die wichtigsten Indexe f\"{u}r eine schnelle Datenbank sind die drei Indexe auf der {\bf File}-Tabelle.
330 Der erste Index ist auf der {\bf FileId} und wird automatisch anglegt, da es der eindeutige Schl\"{u}ssel ist,
331 um auf die Tabelle zuzugreifen. Die anderen beiden sind der {\bf JobId}-Index und der {\bf Filename, PathId}-Index.
332 Wenn einer dieser Indexe fehlt, verlieret Ihre Datenbank enorm an Performanz.
334 \subsection{PostgreSQL Indexe}
335 Bei PostgreSQL k\"{o}nnen Sie mit dem folgenden Kommandos \"{u}berpr\"{u}fen ob Sie alle Indexe haben:
340 select * from pg_indexes where tablename='file';
344 Wenn Sie keine Ausgaben sehen die anzeigen das alle drei Indexe vorhanden sind,
345 k\"{o}nnen Sie die beiden zus\"{a}tzlichen Indexe mit:
350 CREATE INDEX file_jobid_idx on file (jobid);
351 CREATE INDEX file_fp_idx on file (filenameid, pathid);
357 \subsection{MySQL Indexes}
358 Bei MySQL k\"{o}nnen Sie die Indexe mit:
363 show index from File;
368 Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:
373 CREATE INDEX file_jobid_idx on File (JobId);
374 CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId);
380 Obgleich das normalerweise kein Problem darstellt, sollten Sie sicherstellen, dass Ihre Indexe f\"{u}r {\bf Filename} und {\bf PathId}
381 beide auf 255 Zeichen gesetzt sind. Einige Benutzer berichten von Problemem mit Indexen die auf 50 Zeichen gesetzt sind.
382 Um das zu kontrollieren, f\"{u}hren Sie:
387 show index from Filename;
388 show index from Path;
393 F\"{u} die Dateinamen ist es wichtig, dass Sie einen Index haben mit dem Key\_name "Name" und dem Sub\_part "255".
394 F\"{u} den Pfad m\"{u}ssen Sie einen Index mit dem Key\_name "Path" und dem Sub\_part "255" haben.
395 Wenn einer der Indexe nicht existiert oder der Sub\_part kleiner 255 ist, k\"{o}nnen Sie den Index neu anlegen indem Sie
396 die folgende Kommandos benutzen:
401 DROP INDEX Path on Path;
402 CREATE INDEX Path on Path (Path(255);
404 DROP INDEX Name on Filename;
405 CREATE INDEX Name on Filename (Name(255));
410 \subsection{SQLite Indexes}
411 Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:
415 sqlite <path>bacula.db
416 select * from sqlite_master where type='index' and tbl_name='File';
420 Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen:
425 CREATE INDEX file_jobid_idx on File (JobId);
426 CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId);
432 \label{CompactingPostgres}
433 \section{Komprimieren Ihrer PostgreSQL Datenbank}
434 \index[general]{Datenbank!Komprimieren Ihrer PostgreSQL }
435 \index[general]{Komprimieren Ihrer PostgreSQL Datenbank }
437 \"{U}ber die Zeit, wie schon oben angemerkt, wird Ihre Datenbank wachsen.
438 Auch wenn Bacula regelm\"{a}{\ss}ig alte Daten l\"{o}scht, wird das PostgreSQL Kommando {\bf VACUUM}
439 Ihnen helfen die Datenbank zu komprimieren. Alternativ wollen Sie eventuell das {\bf vacuumdb}-Kommande nutzen,
440 das vom cron-Dienst gestartet werden kann.
442 Alle Datenbanken haben Hilfsmittel, um die Daten in eine ASCII-Datei zu schreiben um sie dann erneut einzulesen.
443 Wenn Sie das tun, wird die Datenbank komplett neu aufgebaut und so eine kompaktere Version entstehen.
444 Wie Sie so etwas tun k\"{o}nnen, zeigt Ihnen das folgende PostgreSQL Beispiel.
446 Bei einer PostgreSQL-Datenbank lassen Sie die Daten in eine ASCII-Datei schreiben und neu einlesen,
447 wenn Sie diese Kommandos ausf\"{u}hren:
451 pg_dump -c bacula > bacula.sql
452 cat bacula.sql | psql bacula
457 Abh\"{a}gig von Ihrer Datenabnkgr\"{o}{\ss}e wird dieser Vorgang mehr oder weniger Zeit und Festplattenplatz in anspruch nehmen.
458 Sie sollten vorher in das Arbeitsverzeichnis Ihrer Datenbank wechseln (typischerweise /var/lib/postgres/data) und die Gr\"{o}[\ss}e \"{u}berpr\"{u}fen.
460 Bestimmte PostgreSQL-Nutzer empfehlen nicht die oben genannte Prozedur, sie sind der Meinung:
461 bei PostgreSQL ist es nicht notwendig, die Daten zu exportieren um sie dann wieder einzulesen.
462 Das normale Ausf\"{u}hren des {\bf VACUUM}-Kommandos reicht, um die Datenbank performant zu halten.
463 Wenn Sie es ganz genau machen wollen, benutzen Sie speziellen Kommandos {\bf VACUUM FULL, REINDEX} und {\bf CLUSTER}
464 um sich den Umweg \"{u}ber das exportiren und wiedereinlesen der Daten zu ersparen.
466 Zum Schlu{\ss} wollen Sie vielleicht noch einen Blick auf die zugeh\"{o}rige PostgreSQL-Dokumentation werfen,
467 Sie finden sie (auf englisch) unter:
468 \elink{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}
469 {http://www.postgresql.org/docs/8.2/interactive/maintenance.html}.
471 \section{Komprimieren Ihrer SQLite Datenbank}
472 \index[general]{Komprimieren Ihrer SQLite Datenbank}
473 \index[general]{Datenbank!Komprimieren Ihrer SQLite }
475 Lesen Sie bitte zuerst die vorherigen Abschnitte die erkl\"{a}ren, warum es erforderlich ist, eine Datenbank zu komprimieren.
476 SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren:
480 cd {\bf working-directory}
481 echo 'vacuum;' | sqlite bacula.db
485 Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:
489 cd {\bf working-directory}
490 echo '.dump' | sqlite bacula.db > bacula.sql
492 sqlite bacula.db < bacula.sql
497 Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Dienst-Konfiguration angegeben haben.
498 Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen,
499 bevor die komprimierte Version angelegt werden kann.
501 \section{Migrating from SQLite to MySQL}
502 \index[general]{MySQL!Migrating from SQLite to }
503 \index[general]{Migrating from SQLite to MySQL }
505 You may begin using Bacula with SQLite then later find that you want to switch
506 to MySQL for any of a number of reasons: SQLite tends to use more disk than
507 MySQL; when the database is corrupted it is often more catastrophic than
508 with MySQL or PostgreSQL.
509 Several users have succeeded in converting from SQLite to MySQL by
510 exporting the MySQL data and then processing it with Perl scripts
511 prior to putting it into MySQL. This is, however, not a simple
514 \label{BackingUpBacula}
515 \section{Backing Up Your Bacula Database}
516 \index[general]{Backing Up Your Bacula Database }
517 \index[general]{Database!Backing Up Your Bacula }
519 If ever the machine on which your Bacula database crashes, and you need to
520 restore from backup tapes, one of your first priorities will probably be to
521 recover the database. Although Bacula will happily backup your catalog
522 database if it is specified in the FileSet, this is not a very good way to do
523 it, because the database will be saved while Bacula is modifying it. Thus the
524 database may be in an instable state. Worse yet, you will backup the database
525 before all the Bacula updates have been applied.
527 To resolve these problems, you need to backup the database after all the backup
528 jobs have been run. In addition, you will want to make a copy while Bacula is
529 not modifying it. To do so, you can use two scripts provided in the release
530 {\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
531 will be automatically generated along with all the other Bacula scripts. The
532 first script will make an ASCII copy of your Bacula database into {\bf
533 bacula.sql} in the working directory you specified in your configuration, and
534 the second will delete the {\bf bacula.sql} file.
536 The basic sequence of events to make this work correctly is as follows:
539 \item Run all your nightly backups
540 \item After running your nightly backups, run a Catalog backup Job
541 \item The Catalog backup job must be scheduled after your last nightly backup
543 \item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf
544 RunAfterJob} to clean up
547 Assuming that you start all your nightly backup jobs at 1:05 am (and that they
548 run one after another), you can do the catalog backup with the following
549 additional Director configuration statements:
553 # Backup the catalog database (after the nightly save)
555 Name = "BackupCatalog"
559 Schedule = "WeeklyCycleAfterBackup"
563 RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
564 RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
565 Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
567 # This schedule does the catalog. It starts after the WeeklyCycle
569 Name = "WeeklyCycleAfterBackup
570 Run = Level=Full sun-sat at 1:10
572 # This is the backup of the catalog
579 File = \lt{}working_directory\gt{}/bacula.sql
585 Be sure to write a bootstrap file as in the above example. However, it is preferable
586 to write or copy the bootstrap file to another computer. It will allow
587 you to quickly recover the database backup should that be necessary. If
588 you do not have a bootstrap file, it is still possible to recover your
589 database backup, but it will be more work and take longer.
591 \label{BackingUPOtherDBs}
592 \section{Backing Up Third Party Databases}
593 \index[general]{Backing Up Third Party Databases }
594 \index[general]{Databases!Backing Up Third Party }
596 If you are running a database in production mode on your machine, Bacula will
597 happily backup the files, but if the database is in use while Bacula is
598 reading it, you may back it up in an unstable state.
600 The best solution is to shutdown your database before backing it up, or use
601 some tool specific to your database to make a valid live copy perhaps by
602 dumping the database in ASCII format. I am not a database expert, so I cannot
603 provide you advice on how to do this, but if you are unsure about how to
604 backup your database, you might try visiting the Backup Central site, which
605 has been renamed Storage Mountain (www.backupcentral.com). In particular,
607 \elink{ Free Backup and Recovery
608 Software}{http://www.backupcentral.com/toc-free-backup-software.html} page has
609 links to scripts that show you how to shutdown and backup most major
613 \section{Database Size}
614 \index[general]{Size!Database }
615 \index[general]{Database Size }
617 As mentioned above, if you do not do automatic pruning, your Catalog will grow
618 each time you run a Job. Normally, you should decide how long you want File
619 records to be maintained in the Catalog and set the {\bf File Retention}
620 period to that time. Then you can either wait and see how big your Catalog
621 gets or make a calculation assuming approximately 154 bytes for each File
622 saved and knowing the number of Files that are saved during each backup and
623 the number of Clients you backup.
625 For example, suppose you do a backup of two systems, each with 100,000 files.
626 Suppose further that you do a Full backup weekly and an Incremental every day,
627 and that the Incremental backup typically saves 4,000 files. The size of your
628 database after a month can roughly be calculated as:
632 Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26)
636 where we have assumed four weeks in a month and 26 incremental backups per month.
637 This would give the following:
641 Size = 154 * 2 * (100,000 * 4 + 10,000 * 26)
643 Size = 308 * (400,000 + 260,000)
645 Size = 203,280,000 bytes
649 So for the above two systems, we should expect to have a database size of
650 approximately 200 Megabytes. Of course, this will vary according to how many
651 files are actually backed up.
653 Below are some statistics for a MySQL database containing Job records for five
654 Clients beginning September 2001 through May 2002 (8.5 months) and File
655 records for the last 80 days. (Older File records have been pruned). For these
656 systems, only the user files and system files that change are backed up. The
657 core part of the system is assumed to be easily reloaded from the Red Hat rpms.
660 In the list below, the files (corresponding to Bacula Tables) with the
661 extension .MYD contain the data records whereas files with the extension .MYI
664 You will note that the File records (containing the file attributes) make up
665 the large bulk of the number of records as well as the space used (459 Mega
666 Bytes including the indexes). As a consequence, the most important Retention
667 period will be the {\bf File Retention} period. A quick calculation shows that
668 for each File that is saved, the database grows by approximately 150 bytes.
674 ============ ========= ===========
677 344,394,684 3,080,191 File.MYD
679 2,590,316 106,902 Filename.MYD
680 3,026,944 Filename.MYI
683 49,062 1,326 JobMedia.MYD
685 141,752 1,378 Job.MYD
689 1,299,512 22,233 Path.MYD
698 This database has a total size of approximately 450 Megabytes.
700 If we were using SQLite, the determination of the total database size would be
701 much easier since it is a single file, but we would have less insight to the
702 size of the individual tables as we have in this case.
704 Note, SQLite databases may be as much as 50\% larger than MySQL databases due
705 to the fact that all data is stored as ASCII strings. That is even binary
706 integers are stored as ASCII strings, and this seems to increase the space