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 nahezu konstante Gr\"{o}{\ss}e beibeh\"{a}lt.
18 Sie k\"{o}nnen anfangs die vorgegebene Konfiguration benutzen, sie enth\"{a}lt bereits
19 sinnvolle Vorgaben f\"{u}r eine kleine Anzahl von Clients (kleiner 5). Wenn Sie dann einige
20 hundert Megabyte freien Plattenplatz haben, wird die daraus resultierende Katalog-Gr\"{o}{\ss}e
21 vorerst kein Problem darstellen. Was aber auch immer der Fall ist, grundlegendes Wissen \"{u}ber
22 die Retention Periods/Aufbewahrungszeitr\"{a}ume der Daten im Katalog und auf den Volumes ist notwendig.
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 Handbuch "`Bacula Installation und Konfiguration"'.
42 \item [File Retention = \lt{}time-period-specification\gt{}]
43 \index[general]{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 gel\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien
56 wiederherzustellen. Die Bacula-Versionen 1.37 und sp\"{a}ter sind allerdings in der Lage, aufgrund des
57 Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern, solange der Job-Eintrag
58 im Katalog vorhanden ist.
60 Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
61 eine Reihe von Hilfsangaben m\"{o}glich, 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[general]{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 gel\"{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 (ab 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 Reihe von Hilfsangaben m\"{o}glich, 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[general]{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 beurteilen.
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}ngig 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 dieses 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 mit dem Kommando {\bf mysql bacula \lt{} bacula.sql}
144 wieder 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 mit 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\"{o}{\ss}e aber mit:
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 werden, um wirksam zu sein.
257 Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen gr\"{o}{\ss}er 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:
311 \elink{http://www.postgresql.org/docs/faqs.FAQ.html}
312 {http://www.postgresql.org/docs/faqs.FAQ.html}.
314 Bei PostgreSQL sollten Sie auch auf die "`effective\_cache\_size"' achten.
315 F\"{u}r ein System mit 2GB Arbeitsspeicher k\"{o}nnen Sie sie auf 131072 setzen,
316 aber setzen Sie sie nicht zu hoch. Zus\"{a}tzlich sind "`work\_mem = 256000"' und
317 "`maintenance\_work\_mem = 256000"', f\"{u}r Systeme mit 2GB Speicher, sinnvolle Werte.
318 Stellen Sie sicher das "`checkpoint\_segments"' auf mindestens 8 gesetzt ist.
320 \section{Datenbank-Leistung und Indexe}
321 \index[general]{Datenbank-Leistung und Indexe}
322 \index[general]{Leistung!Datenbank und Indexe}
323 Eine der wichtigsten Aspekte die Leistungsf\"{a}higkeit der Bacula-Datenbank sicherzustellen ist zu \"{u}berpr\"{u}fen,
324 ob alle Indexe richtig sind. Mehrere Benutzer haben angemerkt, dass ihre Datenbank in der Standardkonfiguration
325 nicht alle notwendigen Indexe hatte. Auch werden Sie eventuell, abh\"{a}ngig von Ihrem Anwendungszweck,
326 zus\"{a}tzlich Indexe ben\"{o}tigen.
328 Die wichtigsten Indexe f\"{u}r eine schnelle Datenbank sind die drei Indexe auf der {\bf File}-Tabelle.
329 Der erste Index ist auf der {\bf FileId} und wird automatisch anglegt, da es der eindeutige Schl\"{u}ssel ist,
330 um auf die Tabelle zuzugreifen. Die anderen beiden sind der {\bf JobId}-Index und der {\bf Filename, PathId}-Index.
331 Wenn einer dieser Indexe fehlt, verliert Ihre Datenbank enorm an Performance.
333 \subsection{PostgreSQL Indexe}
334 Bei PostgreSQL k\"{o}nnen Sie mit dem folgenden Kommandos \"{u}berpr\"{u}fen ob Sie alle Indexe haben:
339 select * from pg_indexes where tablename='file';
343 Wenn Sie keine Ausgaben sehen die anzeigen das alle drei Indexe vorhanden sind,
344 k\"{o}nnen Sie die beiden zus\"{a}tzlichen Indexe mit:
349 CREATE INDEX file_jobid_idx on file (jobid);
350 CREATE INDEX file_fp_idx on file (filenameid, pathid);
356 \subsection{MySQL Indexes}
357 Bei MySQL k\"{o}nnen Sie die Indexe mit:
362 show index from File;
367 Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:
372 CREATE INDEX file_jobid_idx on File (JobId);
373 CREATE INDEX file_jpf_idx on File (JobId, FilenameId, PathId);
379 Obgleich das normalerweise kein Problem darstellt, sollten Sie sicherstellen, dass Ihre Indexe f\"{u}r {\bf Filename} und {\bf PathId}
380 beide auf 255 Zeichen gesetzt sind. Einige Benutzer berichten von Problemen mit Indexen die auf 50 Zeichen gesetzt sind.
381 Um das zu kontrollieren, f\"{u}hren Sie:
386 show index from Filename;
387 show index from Path;
392 F\"{u} die Dateinamen ist es wichtig, dass Sie einen Index haben mit dem Key\_name "`Name"' und dem Sub\_part "`255"'.
393 F\"{u} den Pfad m\"{u}ssen Sie einen Index mit dem Key\_name "`Path"' und dem Sub\_part "`255"' haben.
394 Wenn einer der Indexe nicht existiert oder der Sub\_part kleiner 255 ist, k\"{o}nnen Sie den Index neu anlegen indem Sie
395 die folgende Kommandos benutzen:
400 DROP INDEX Path on Path;
401 CREATE INDEX Path on Path (Path(255);
403 DROP INDEX Name on Filename;
404 CREATE INDEX Name on Filename (Name(255));
409 \subsection{SQLite Indexes}
410 Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:
414 sqlite <path>bacula.db
415 select * from sqlite_master where type='index' and tbl_name='File';
419 Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen:
424 CREATE INDEX file_jobid_idx on File (JobId);
425 CREATE INDEX file_jfp_idx on File (JobId, FilenameId, PathId);
431 \label{CompactingPostgres}
432 \section{Komprimieren Ihrer PostgreSQL Datenbank}
433 \index[general]{Datenbank!Komprimieren Ihrer PostgreSQL }
434 \index[general]{Komprimieren Ihrer PostgreSQL Datenbank }
436 \"{U}ber die Zeit, wie schon oben angemerkt, wird Ihre Datenbank wachsen.
437 Auch wenn Bacula regelm\"{a}{\ss}ig alte Daten l\"{o}scht, wird das PostgreSQL Kommando {\bf VACUUM}
438 Ihnen helfen die Datenbank zu komprimieren. Alternativ wollen Sie eventuell das {\bf vacuumdb}-Kommando nutzen,
439 das vom cron-Dienst gestartet werden kann.
441 Alle Datenbanken haben Hilfsmittel, um die Daten in eine ASCII-Datei zu schreiben um sie dann erneut einzulesen.
442 Wenn Sie das tun, wird die Datenbank komplett neu aufgebaut und so eine kompaktere Version entstehen.
443 Wie Sie so etwas tun k\"{o}nnen, zeigt Ihnen das folgende PostgreSQL Beispiel.
445 Bei einer PostgreSQL-Datenbank lassen Sie die Daten in eine ASCII-Datei schreiben und neu einlesen,
446 wenn Sie diese Kommandos ausf\"{u}hren:
450 pg_dump -c bacula > bacula.sql
451 cat bacula.sql | psql bacula
456 Abh\"{a}gig von Ihrer Datenbankgr\"{o}{\ss}e wird dieser Vorgang mehr oder
457 weniger Zeit und Festplattenplatz in Anspruch nehmen. Sie sollten vorher
458 in das Arbeitsverzeichnis Ihrer Datenbank wechseln (typischerweise
459 /var/lib/postgres/data) und die Gr\"{o}{\ss}e \"{u}berpr\"{u}fen.
461 Bestimmte PostgreSQL-Nutzer empfehlen nicht die oben genannte Prozedur, sie sind der Meinung:
462 bei PostgreSQL ist es nicht notwendig, die Daten zu exportieren um sie dann wieder einzulesen.
463 Das normale Ausf\"{u}hren des {\bf VACUUM}-Kommandos reicht, um die Datenbank performant zu halten.
464 Wenn Sie es ganz genau machen wollen, benutzen Sie speziellen Kommandos {\bf VACUUM FULL, REINDEX} und {\bf CLUSTER}
465 um sich den Umweg \"{u}ber das exportieren und wiedereinlesen der Daten zu ersparen.
467 Zum Schlu{\ss} wollen Sie vielleicht noch einen Blick auf die zugeh\"{o}rige PostgreSQL-Dokumentation werfen,
468 Sie finden sie (auf englisch) unter:
469 \elink{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}
470 {http://www.postgresql.org/docs/8.2/interactive/maintenance.html}.
472 \section{Komprimieren Ihrer SQLite Datenbank}
473 \index[general]{Komprimieren Ihrer SQLite Datenbank}
474 \index[general]{Datenbank!Komprimieren Ihrer SQLite }
476 Lesen Sie bitte zuerst die vorherigen Abschnitte die erkl\"{a}ren, warum es erforderlich ist, eine Datenbank zu komprimieren.
477 SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren:
481 cd {\bf working-directory}
482 echo 'vacuum;' | sqlite bacula.db
486 Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:
490 cd {\bf working-directory}
491 echo '.dump' | sqlite bacula.db > bacula.sql
493 sqlite bacula.db < bacula.sql
498 Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Dienst-Konfiguration angegeben haben.
499 Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen,
500 bevor die komprimierte Version angelegt werden kann.
502 \section{Migration von SQLite zu MySQL/PostgreSQL}
503 \index[general]{MySQL!Migration von SQLite zu }
504 \index[general]{PostgreSQL!Migration von SQLite zu }
505 \index[general]{Migration von SQLite zu MySQL/PostgreSQL }
507 Wenn Sie Bacula anfangs mit SQLite zusammen benutzt haben, gibt es sp\"{a}ter
508 eine Reihe von Gr\"{u}nden, weshalb Sie eventuell auf MySQL oder PostgreSQL
510 SQLite belegt mehr Festplattenplatz f\"{u}r dieselbe Datenmenge als MySQL;
511 falls die Datenbank besch\"{a}digt wird, ist es mit SQLite problematischer als
512 bei MySQL oder PostgreSQL, sie wiederherzustellen. Viele Benutzer sind erfolgreich
513 von SQLite auf MySQL oder PostgreSQL umgestiegen, indem sie zuerst die Daten
514 exportiert haben und sie dann mit einem Perl-Script in ein passendes Format
515 konvertiert haben, um sie in die neue Datenbank zu importieren.
516 Dies ist aber kein ganz einfacher Vorgang. Beispiel-Scripte dazu finden Sie
517 im Bacula-Quelltext unter {\bf examples/database}.
519 \label{BackingUpBacula}
520 \section{Sichern Ihrer Bacula Datenbank}
521 \index[general]{Sichern Ihrer Bacula Datenbank}
522 \index[general]{Datenbank!Sichern Ihrer Bacula }
524 Falls jemals der Rechner auf dem Ihre Bacula-Installation l\"{a}uft abst\"{u}rzt,
525 und Sie diesen wiederherstellen m\"{u}ssen, wird es einer der ersten Schritte sein,
526 die Datenbank zur\"{u}ckzusichern. Obwohl Bacula fr\"{o}hlich die Datenbank sichert,
527 wenn sie im FileSet angegeben ist, ist das kein sehr guter Weg, da Bacula die Datenbank
528 \"{a}ndert, w\"{a}hrend sie gesichert wird. Dadurch ist die gesicherte Datenbank wahrscheinlich
529 in einem inkonsistenten Zustand. Noch schlimmer ist, dass die Datenbank gesichert wird,
530 bevor Bacula alle Aktualisierungen durchf\"{u}hren kann.
532 Um diese Problem zu umgehen, m\"{u}ssen Sie die Datenbank sichern nachdem alle Backup-Jobs
533 gelaufen sind. Zus\"{a}tzlich werden Sie wohl eine Kopie der Datenbank erstellen wollen,
534 w\"{a}hrend Bacula keine Aktualisierungen vornimmt. Um das zu erreichen, k\"{o}nnen Sie
535 die beiden Scripte {\bf make\_catalog\_backup} und {\bf delete\_catalog\_backup} benutzen,
536 die Ihrer Bacula-Version beiliegen. Diese Dateien werden, zusammen mit den anderen Bacula-Scripts,
537 automatisch erzeugt. Das erste Script erzeugt eine ASCII-Kopie Ihrer Datenbank namens {\bf bacula.sql}
538 in dem Arbeitsverzeichnis, dass Sie in der Konfiguration angegeben haben. Das zweite Script
539 l\"{o}scht die Datei {\bf bacula.sql} wieder.
541 Die grundlegenden Arbeitsschritte damit alles korrekt funktioniert, sind folgende:
544 \item alle Backup-Jobs laufen lassen
545 \item wenn alle Jobs beendet sind, wird ein Catalog Backup-Job gestartet
546 \item Der Catalog Backup-Job muss nach den anderen Backup-Jobs laufen
548 \item Benutzen Sie {\bf RunBeforeJob} um die ASCII-Sicherungsdatei zu erstellen und
549 {\bf RunAfterJob} um sie wieder zu l\"{o}schen
552 Angenommen Sie starten alle Ihre Backup-Jobs nachts um 01:05, k\"{o}nnen Sie das Catalog-Backup
553 mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen:
557 # Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung)
563 Schedule = WeeklyCycleAfterBackup
567 # Achtung!!! Das Passwort auf der Kommandozeile zu \"{u}bergeben ist nicht sicher.
568 # Lesen Sie bitte die Kommentare in der Datei make_catalog_backup.
569 RunBeforeJob = "/home/bacula/bin/make_catalog_backup"
570 RunAfterJob = "/home/bacula/bin/delete_catalog_backup"
571 Write Bootstrap = "/home/bacula/working/BackupCatalog.bsr"
573 # Diese Schedule starten das Catalog-Backup nach den anderen Sicherungen
575 Name = WeeklyCycleAfterBackup
576 Run = Level=Full sun-sat at 1:10
578 # Das FileSet f\"{u}r die ASCII-Kopie der Datenbank
585 File = "<working_directory>/bacula.sql"
591 Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird.
592 Bevorzugterweise wird eine Kopie dieser Bootstrap-Datei auf einem andern Computer gespeichert.
593 Dies erlaubt eine schnelle Wiederherstellung der Datenbank, falls erforderlich. Wenn Sie
594 keine Bootstrap-Datei haben, ist es trotzdem m\"{o}glich, erfordert aber mehr Arbeit und dauert l\"{a}nger.
597 \label{BackingUpBaculaSecurityConsiderations}
598 \section{Sicherheitsaspekte}
599 \index[general]{Sicherung der Bacula Datenbank - Sicherheitsaspekte }
600 \index[general]{Datenbank!Sicherung der Bacula Datenbank - Sicherheitsaspekte }
602 Das Script make\_catalog\_backup wird als Beispiel bereitgestellt, wie Sie Ihre
603 Bacula Datenbank sichern k\"{o}nnen. Wir erwarten das Sie, entsprechend Ihrer Situation,
604 Vorsichtsma{\ss}nahmen treffen.
605 make\_catalog\_backup ist so ausgelegt, dass das Passwort auf der Kommandozeile \"{u}bergeben wird.
606 Das ist in Ordnung, solange sich nur vertrauensw\"{u}rdige Benutzer am System anmelden k\"{o}nnen,
607 ansonsten ist es inakzeptabel. Die meisten Datenbanksysteme bieten eine alternative Methode an,
608 um das Passwort nicht auf der Kommandozeile \"{u}bergeben zu m\"{u}ssen.
610 Das Script make\_catalog\_backup enth\"{a}lt einige Warnungen dies betreffend. Bitte lesen Sie
611 die Kommentare im Script.
613 Bei PostgreSQL k\"{o}nnen Sie z.B. eine Passwort-Datei verwenden, siehe
614 \elink{.pgpass}{http://www.postgresql.org/docs/8.2/static/libpq-pgpass.html},
615 und MySQL hat die \elink{ .my.cnf}{http://dev.mysql.com/doc/refman/5.1/de/password-security.html}.
617 Wir hoffen, dass wir Ihnen damit etwas helfen konnten,
618 aber nur Sie k\"{o}nenn beurteilen, was in Ihrer Situation erforderlich ist.
621 \label{BackingUPOtherDBs}
622 \section{Sicherung anderer Datenbanken}
623 \index[general]{Sicherung anderer Datenbanken }
624 \index[general]{Datenbanken!Sicherung anderer }
626 Wie oben schon erw\"{a}hnt wurde, f\"{u}hrt das Sichern von Datenbank-Dateien im laufenden Betrieb
627 dazu, dass die gesicherten Dateien sich wahrscheinlich in einem inkonsistenten Zustand befinden.
629 Die beste L\"{o}sung daf\"{u}r ist, die Datenbank vor der Sicherung zu stoppen,
630 oder datenbankspezifische Hilfsprogramme zu verwenden, um eine g\"{u}ltige Sicherungsdatei zu erstellen,
631 die Bacula dann auf die Volumes schreiben kann. Wenn Sie unsicher sind, wie Sie das am besten mit der
632 von Ihnen benutzten Datenbank erreichen k\"{o}nnen, hilft Ihnen eventuell die Webseite von Backup Central
633 weiter. Auf \elink{ Free Backup and Recovery Software}{http://www.backupcentral.com/toc-free-backup-software.html}
634 finden Sie Links zu Scripts die zeigen, wie man die meisten gr\"{o}{\ss}eren Datenbanken sichern kann.
637 \section{Datenbank Gr\"{o}{\ss}e}
638 \index[general]{Gr\"{o}{\ss}e!Datenbank }
639 \index[general]{Datenbank Gr\"{o}{\ss}e }
641 Wenn Sie nicht automatisch alte Datens\"{a}tze aus Ihrer Katalog-Datenbank l\"{o}schen lassen,
642 wird Ihre Datenbank mit jedem gelaufenen Backup-Job wachsen (siehe auch weiter oben).
643 Normalerweise sollten Sie sich entscheiden, wie lange Sie die Datei-Eintr\"{a}ge im Katalog
644 aufbewaren wollen und die {\bf File Retention} entsprechend konfigurieren. Dann k\"{o}nnen Sie
645 entweder abwarten wie gro{\ss} Ihre Katalog-Datenbank werden wird, oder es aber auch unge\"{a}hr
646 berechnen. Dazu m\"{u}ssen Sie wissen, dass f\"{u}r jede gesicherte Datei in etwa 154 Bytes in der
647 Katalog-Datenbank belegt werden und wieviele Dateien Sie auf wievielen Computern sichern werden.
649 Ein Beispiel: angenommen Sie sichern zwei Computer, jeder mit 100.000 Dateien.
650 Weiterhin angenommen, Sie machen ein w\"{o}chentliches Full-Backup und ein
651 inkrementelles jeden Tag, wobei bei einem inkrementellen Backup typischerweise 4.000 Dateien
652 gesichert werden. Die ungef\"{a}hre Gr\"{o}{\ss}e Ihrer Datenbank nach einem Monat
653 kann dann so berechnet werden:
657 Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26)
661 wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen.
662 Das ergibt das folgende:
665 Gr\"{o}{\ss}e = 154 * 2 * (100.000 * 4 + 10.000 * 26)
667 Gr\"{o}{\ss}e = 308 * (400.000 + 260.000)
669 Gr\"{o}{\ss}e = 203.280.000 Bytes
673 f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank
674 in etwa 200 Megabytes gro{\ss} wird. Nat\"{u}rlich h\"{a}ngt dieser Wert davon ab, wieviele
675 Dateien wirklich gesichert werden.
677 Unten sehen Sie ein paar Statistiken f\"{u}r eine MySQL-Datenbank die
678 Job-Eintr\"{a}ge f\"{u}r 5 Clients \"{u}ber 8.5 Monate und
679 Datei-Eintr\"{a}ge \"{u}ber 80 Tage enth\"{a}lt (\"{a}ltere
680 Datei-Eintr\"{a}ge wurden schon gel\"{o}scht). Bei diesen 5 Clients wurden
681 nur die Benutzer- und System-Dateien gesichert, die sich st\"{a}ndig
682 \"{a}ndern. Bei allen anderen Dateien wird angenommen, dass sie leicht aus
683 den Software-Paketen des Betriebssystems wiederherstellbar sind.
685 In der Liste sind die Dateien (die den MySQL-Tabellen entsprechen) mit der Endung .MYD
686 die, die die eigentlichen Daten enthalten und die mit der Endung .MYI enthalten die Indexe.
688 Sie werden bemerken, dass die meisten Eintr\"{a}ge in der Datei File.MYD
689 (die die Datei-Attribute enth\"{a}lt) enthalten sind und diese auch den
690 meisten Platz auf der Festplatte belegt. Die {\bf File Retention} (der Aufbewahrungszeitraum
691 f\"{u}r Dateien) ist also im wesentlichen daf\"{u}r verantwortlich, wie gro{\ss} die Datenbank wird.
692 Eine kurze Berechnung zeigt, dass die Datenbank mit jeder gesicherten Datei ungef\"{a}hr um
693 154 Bytes w\"{a}chst.
698 in Bytes Eintr\"{a}ge Dateiname
699 ============ ========= ===========
702 344,394,684 3,080,191 File.MYD
704 2,590,316 106,902 Filename.MYD
705 3,026,944 Filename.MYI
708 49,062 1,326 JobMedia.MYD
710 141,752 1,378 Job.MYD
714 1,299,512 22,233 Path.MYD
723 Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes..
725 H\"{a}tten wir SQLite genommen, w\"{a}re die Bestimmung der Datenbankgr\"{o}{\ss}e
726 viel einfacher gewesen, da SQLite alle Daten in einer einzigen Datei speichert,
727 dann aber h\"{a}tten wir nicht so einfach erkennen k\"{o}nnen, welche der Tabellen
728 den meisten Speicherplatz ben\"{o}tigt.
730 SQLite Datenbanken k\"{o}nnen bis zu 50 \% gr\"{o}{\ss}er sein als MySQL-Datenbanken
731 (bei gleichem Datenbestand), weil bei SQLite alle Daten als ASCII-Zeichenketten gespeichert werden.
732 Sogar bin\"{a}re Daten werden als ASCII-Zeichenkette dargestellt, und das scheint den Speicherverbrauch