+++ /dev/null
-%%
-%%
-
-\chapter{Katalog Verwaltung}
-\label{CatMaintenanceChapter}
-\index[general]{Verwaltung!Katalog }
-\index[general]{Katalog Verwaltung}
-
-Ohne eine ordnungsgem\"{a}{\ss}e Einrichtung und Verwaltung kann es sein,
-dass Ihr Katalog immer gr\"{o}{\ss}er wird wenn Jobs laufen und Daten gesichert werden.
-Zudem kann der Katalog ineffizient und langsam werden. Wie schnell der Katalog w\"{a}chst,
-h\"{a}ngt von der Anzahl der Jobs und der Menge der dabei gesicherten Dateien ab.
-Durch das L\"{o}schen von Eintr\"{a}gen im Katalog kann Platz geschaffen werden f\"{u}r
-neue Eintr\"{a}ge der folgenden Jobs. Durch regelm\"{a}{\ss}iges l\"{o}schen alter abgelaufener
-Daten, \"{a}lter als durch die Aufbewahrungszeitr\"{a}ume (Retention Periods) angegeben,
-wird daf\"{u}r gesorgt, dass die Katalog-Datenbank eine nahezu konstante Gr\"{o}{\ss}e beibeh\"{a}lt.
-
-Sie k\"{o}nnen anfangs die vorgegebene Konfiguration benutzen, sie enth\"{a}lt bereits
-sinnvolle Vorgaben f\"{u}r eine kleine Anzahl von Clients (kleiner 5). Wenn Sie dann einige
-hundert Megabyte freien Plattenplatz haben, wird die daraus resultierende Katalog-Gr\"{o}{\ss}e
-vorerst kein Problem darstellen. Was aber auch immer der Fall ist, grundlegendes Wissen \"{u}ber
-die Retention Periods/Aufbewahrungszeitr\"{a}ume der Daten im Katalog und auf den Volumes ist notwendig.
-
-\section{Einstellung der Aufbewahrungszeitr\"{a}ume}
-\label{Retention}
-\index[general]{Einstellung der Aufbewahrungszeitr\"{a}ume }
-\index[general]{Zeitr\"{a}ume!Einstellung der Aufbewahrungs- }
-
-Bacula benutzt drei verschiedene Aufbewahrungszeitr\"{a}ume:
-die {\bf File Retention}: der Aufbewahrungszeitraum f\"{u}r Dateien,
-die {\bf Job Retention}: der Aufbewahrungszeitraum f\"{u}r Jobs und
-die {\bf Volume Retention}: der Aufbewahrungszeitraum f\"{u}r Volumes.
-Von diesen drei ist der Aufbewahrungszeitraum f\"{u}r Dateien der entscheidende,
-wenn es darum geht, wie gro{\ss} die Datenbank werden wird.
-
-Die {\bf File Retention} und die {\bf Job Retention} werden in der Client-Konfiguration,
-wie unten gezeigt, angegeben. Die {\bf Volume Retention} wird in der Pool-Konfiguration
-angegeben, genauere Informationen dazu finden Sie im Handbuch "`Bacula Installation und Konfiguration"'.
-
-\begin{description}
-
-\item [File Retention = \lt{}time-period-specification\gt{}]
- \index[general]{File Retention}
- Der Aufbewahrungszeitraum f\"{u}r Dateien gibt die Zeitspanne an, die die
-Datei-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden.
-Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist,
-wird Bacula die Katalog-Eintr\"{a}ge der Dateien l\"{o}schen, die \"{a}lter als
-dieser Zeitraum sind. Das L\"{o}schen erfolgt nach Beendigung eines Jobs des entsprechenden Clients.
-Bitte beachten Sie, dass die Client-Datenbank-Eintr\"{a}ge eine Kopie der Aufbewahrungszeitr\"{a}ume
-f\"{u}r Dateien und Jobs enthalten, Bacula aber die Zeitr\"{a}ume aus der aktuellen Client-Konfiguration
-des Director-Dienstes benutzt um alte Katalog-Eintr\"{a}ge zu l\"{o}schen.
-
-Da die Datei-Eintr\"{a}ge ca. 80 Prozent der Katalog-Datenbankgr\"{o}{\ss}e ausmachen,
-sollten Sie sorgf\"{a}lltig ermitteln \"{u}ber welchen Zeitraum Sie die Eintr\"{a}ge aufbewahren wollen.
-Nachdem die Datei-Eintr\"{a}ge gel\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien
-wiederherzustellen. Die Bacula-Versionen 1.37 und sp\"{a}ter sind allerdings in der Lage, aufgrund des
-Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern, solange der Job-Eintrag
-im Katalog vorhanden ist.
-
-Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
-eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen,
-Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
-dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
-
-Der Standardwert der Aufbewahrungszeit f\"{u}r Dateien ist 60 Tage.
-
-\item [Job Retention = \lt{}time-period-specification\gt{}]
- \index[general]{Job Retention }
- Der Aufbewahrungszeitraum f\"{u}r Jobs gibt die Zeitspanne an, die die
-Job-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden.
-Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist,
-wird Bacula die Katalog-Eintr\"{a}ge der Jobs l\"{o}schen, die \"{a}lter als
-dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag gel\"{o}scht wird,
-auch alle zu diesem Job geh\"{o}renden Datei- und JobMedia-Eintr\"{a}ge aus dem
-Katalog gel\"{o}scht werden. Dies passiert unabh\"{a}ngig von der Aufbewahrungszeit f\"{u}r Dateien,
-infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rzer sein als f\"{u}r Jobs.
-
-Wie oben erw\"{a}hnt, sind Sie nicht mehr in der Lage einzelne Dateien eines Jobs zur\"{u}ckzusichern,
-wenn die Datei-Eintr\"{a}ge aus der Katalog-Datenbank entfernt wurden. Jedoch, solange der Job-Eintrag
-im Katalog vorhanden ist, k\"{o}nnen Sie immer noch den kompletten Job mit allen Dateien wiederherstellen
-(ab Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog
-l\"{a}nger als die Datei-Eintr\"{a}ge aufzubewahren.
-
-Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
-eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen,
-Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
-dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
-
-Der Standardwert der Aufbewahrungszeit f\"{u}r Jobs ist 180 Tage.
-
-\item [AutoPrune = \lt{}yes/no\gt{}]
- \index[general]{AutoPrune }
- Wenn AutoPrune auf {\bf yes} (Standard) gesetzt ist, wird Bacula nach jedem Job
-automatisch \"{u}berpr\"{u}fen, ob die Aufbewahrungszeit f\"{u}r bestimmte Dateien und/oder Jobs
-des gerade gesicherten Clients abgelaufen ist und diese aus dem Katalog entfernen.
-Falls Sie AutoPrune durch das Setzen auf {\bf no} ausschalten, wird Ihre Katalog-Datenbank mit jedem
-gelaufenen Job immer gr\"{o}{\ss}er werden.
-\end{description}
-
-\label{CompactingMySQL}
-\section{Komprimieren Ihrer MySQL Datenbank}
-\index[general]{Datenbank!Komprimieren Ihrer MySQL }
-\index[general]{Komprimieren Ihrer MySQL Datenbank }
-
-Mit der Zeit, wie oben schon angemerkt, wird Ihre Datenbank dazu neigen zu wachsen.
-Auch wenn Bacula regelm\"{a}{\ss}ig Datei-Eintr\"{a}ge l\"{o}scht, wird die {\bf MySQL}-Datenbank
-st\"{a}ndig gr\"{o}{\ss}er werden. Um dies zu vermeiden, muss die Datenbank komprimiert werden.
-Normalerweise kennen gro{\ss}e kommerzielle Datenbanken, wie Oracle, bestimmte Kommandos
-um den verschwendeten Festplattenplatz wieder freizugeben. MySQL hat das {\bf OPTIMIZE TABLE}
-Kommando und bei SQLite (Version 2.8.4 und gr\"{o}{\ss}er) k\"{o}nnen Sie das {\bf VACUUM}
-Kommando zu diesem Zweck benutzen. Wir \"{u}berlassen es Ihnen, die N\"{u}tzlichkeit von
-{\bf OPTIMIZE TABLE} oder {\bf VACUUM} zu beurteilen.
-
-Alle Datenbanken haben Hilfsmittel, um die enthaltenen Daten im ASCII-Format in eine Datei zu schreiben
-und diese Datei dann auch wieder einzulesen. Wenn man das tut, wird die Datenbank erneut erzeugt, was ein
-sehr kompaktes Datenbank-Format als Ergebnis hat. Weiter unten zeigen wir Ihnen, wie Sie das bei
-MySQL, SQLite und PostgreSQL durchf\"{u}hren k\"{o}nnen.
-
-Bei einer {\bf MySQL} Datenbank k\"{o}nnen Sie den Inhalt der Katalog-Datenbank mit den folgenden Kommandos
-in eine ASCII-Datei (bacula.sql) schreiben und neu in die Datenbank importieren:
-
-\footnotesize
-\begin{alltt}
-mysqldump -f --opt bacula > bacula.sql
-mysql bacula < bacula.sql
-rm -f bacula.sql
-\end{alltt}
-\normalsize
-
-Abh\"{a}ngig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
-ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenbank liegt (typischerweise
-/var/lib/mysql) und dieses Kommando ausf\"{u}hre:
-
-\footnotesize
-\begin{alltt}
-du bacula
-\end{alltt}
-\normalsize
-
-bekomme ich die Ausgabe {\bf 620,644}, was bedeutet dass das Verzeichnis bacula 620.644 Bl\"{o}cke
-von 1024 Bytes auf der Festplatte belegt, meine Datenbank enth\"{a}lt also ca. 635 MB an Daten.
-Nachdem ich das {\bf mysqldump} ausgef\"{u}hrt habe, ist die dabei entstandene Datei bacula.sql
-{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei mit dem Kommando {\bf mysql bacula \lt{} bacula.sql}
-wieder in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464}
-Bl\"{o}cken. Mit anderen Worten, die komprimierte Version meiner Datenbank, die seit ca. 1 Jahr
-in Benutzung ist, ist ungef\"{a}hr nur noch ein Drittel so gro{\ss} wie vorher.
-
-Als Konsequenz wird empfohlen, auf die Gr\"{o}{\ss}e der Datenbank zu achten und sie von Zeit zu Zeit
-(alle sechs Monate oder j\"{a}hrlich) zu komprimieren.
-
-\label{DatabaseRepair}
-\label{RepairingMySQL}
-\section{Reparatur Ihrer MySQL Datenbank}
-\index[general]{Datenbank!Reparatur Ihrer MySQL }
-\index[general]{Reparatur Ihrer MySQL Datenbank }
-
-Wenn Sie bemerken, dass das Schreiben der MySQL-Datenbank zu Fehlern f\"{u}hrt,
-oder das der Director-Dienst h\"{a}ngt, wenn er auf die Datenbank zugreift,
-sollten Sie sich die MySQL Datenbank\"{u}berpr\"{u}fungs- und Reparaturprogramme ansehen.
-Welches Programm Sie laufen lassen sollten, h\"{a}ngt mit der von Ihnen benutzten Datenbank-
-Indizierung zusammen. Wenn Sie das Standardverfahren nutzen, werden Sie vermutlich {\bf myisamchk}
-laufen lassen. F\"{a}r n\"{a}here Information lesen Sie bitte auch:
-\elink{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}
-{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}.
-
-Falls die auftretenden Fehler einfache SQL-Warnungen sind, sollten Sie zuerst das von Bacula mitgelieferte
-dbcheck-Programm ausf\"{u}hren, bevor Sie die MySQL-Datenbank-Reparaturprogramme nutzen.
-Dieses Programm kann verwaiste Datenbankeintr\"{a}ge finden und andere Inkonsistenzen in der
-Katalog-Datenbank beheben.
-
-Eine typische Ursache von Datenbankproblemen ist das Volllaufen einer Partition.
-In solch einem Fall muss entweder zus\"{a}tzlicher Platz geschaffen werden, oder
-belegter Platz freigegeben werden, bevor die Datenbank mit {\bf myisamchk} repariert werden kann.
-
-Hier ist ein Beispiel, wie man eine korrupte Datenbank reparieren k\"{o}nnte, falls nach dem Vollaufen
-einer Partition die Datenbankprobleme mit {\bf myisamchk -r} nicht behoben werden k\"{o}nnen:
-
-kopieren Sie folgende Zeilen in ein Shell-Script names {\bf repair}:
-\footnotesize
-\begin{alltt}
-#!/bin/sh
-for i in *.MYD ; do
- mv \$i x\$\{i\}
- t=`echo \$i | cut -f 1 -d '.' -`
- mysql bacula <<END_OF_DATA
-set autocommit=1;
-truncate table \$t;
-quit
-END_OF_DATA
- cp x\$\{i\} \$\{i\}
- chown mysql:mysql \$\{i\}
- myisamchk -r \$\{t\}
-done
-\end{alltt}
-\normalsize
-
-dieses Shell-Script, wird dann wie folgt aufgerufen:
-
-\footnotesize
-\begin{alltt}
-cd /var/lib/mysql/bacula
-./repair
-\end{alltt}
-\normalsize
-
-nachdem sichergestellt ist, dass die Datenbank wieder korrekt funktioniert,
-kann man die alten Datenbank-Dateien l\"{o}schen:
-\footnotesize
-\begin{alltt}
-cd /var/lib/mysql/bacula
-rm -f x*.MYD
-\end{alltt}
-\normalsize
-
-\section{MySQL-Tabelle ist voll}
-\index[general]{Datenbank!MySQL-Tabelle ist voll}
-\index[general]{MySQL-Tabelle ist voll}
-
-Falls ein Fehler wie {\bf The table 'File' is full ...} auftritt,
-passiert das vermutlich, weil bei den MySQL-Versionen 4.x die Tabellengr\"{o}{\ss}e
-standardm\"{a}{\ss}ig auf 4 GB begrenzt ist und Sie dieses Limit erreicht haben.
-Hinweise zu der maximal m\"{o}glichen Tabellengr\"{o}{\ss}e gibt es auf
-\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}
-
-Sie k\"{o}nnen sich die maximale Tabellengr\"{o}{\ss}e mit:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-SHOW TABLE STATUS FROM bacula like "File";
-\end{alltt}
-\normalsize
-
-anzeigen lassen. Wenn die Spalte {\bf max\_data\_length} ca. 4 GB entspricht,
-dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\"{o}{\ss}e aber mit:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-ALTER TABLE File MAX_ROWS=281474976710656;
-\end{alltt}
-\normalsize
-
-anpassen. Alternativ k\"{o}nnen Sie auch die /etc/my.cnf editieren, bevor Sie die Bacula-Tabellen erstellen,
-setzen Sie im Abschnitt [mysqld]:
-
-\footnotesize
-\begin{alltt}
-set-variable = myisam_data_pointer_size=6
-\end{alltt}
-\normalsize
-
-
-Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem Anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen
-gesetzt werden, um wirksam zu sein.
-
-Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen gr\"{o}{\ss}er 5.x nicht n\"{o}tig sein,
-somit sind diese \"{A}nderungen nur bei MySQL 4.x, in Abh\"{a}gigkeit von Ihrer Katalog-Datenbank-Gr\"{o}{\ss}e,
-notwendig.
-
-\section{MySQL-Server Has Gone Away-Fehler}
-\index[general]{Datenbank!MySQL-Server Has Gone Away-Fehler}
-\index[general]{MySQL-Server Has Gone Away-Fehler}
-Fall Sie Probleme damit haben, dass Ihr MySQL-Server nicht mehr erreichbar ist, oder Meldungen wie
-"`MySQL server has gone away"' erscheinen, dann lesen Sie bitte die MySQL-Dokumentation auf:
-
-\elink{http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
-{http://dev.mysql.com/doc/refman/5.1/de/gone-away.html}
-
-
-\label{RepairingPSQL}
-\section{Reparatur Ihrer PostgreSQL Datenbank}
-\index[general]{Datenbank!Reparatur Ihrer PostgreSQL }
-\index[general]{Reparatur Ihrer PostgreSQL Datenbank}
-
-Dieselben \"{U}berlegungen, wie oben f\"{u}r MySQL angef\"{u}hrt, sind auch hier g\"{u}ltig.
-Lesen Sie die PostgreSQL-Dokumentation um zu erfahren, wie Sie Ihre Datenbank reparieren k\"{o}nnen.
-Erw\"{a}gen Sie auch den Einsatz von Bacula's dbcheck-Programm, falls es sinnvoll erscheint (siehe oben).
-
-\label{DatabasePerformance}
-\section{Datenbank-Leistung}
-\index[general]{Datenbank-Leistung}
-\index[general]{Leistung!Datenbank}
-
-Es gibt viele Wege, die verschiedenen von Bacula unterst\"{u}tzten Datenbanken abzustimmen, um ihre Leistung zu erh\"{o}hen.
-Zwischen einer schlecht und gut abgestimmten Datenbank kann ein Geschwindigkeitsunterschied von 100 und mehr liegen,
-wenn es darum geht Datenbankeintr\"{a}ge zu schreiben oder zu suchen.
-
-Bei jeder der Datenbanken, k\"{o}nnen Sie erhebliche Verbesserungen erwarten, wenn Sie weitere Indexe hinzuf\"{u}gen.
-Die Kommentare in den Bacula make\_xxx\_tables-Scripts (z.B. make\_postgres\_tables) geben einige Hinweise,
-wof\"{u}r Indexe geeignet sind. Sehen Sie bitte auch unten f\"{u}r genaue Informationen, wie Sie Ihre Indexe
-\"{u}berpr\"{u}fen k\"{o}nnen.
-
-F\"{u}r MySQL ist es sehr wichtig, die my.cnf-Datei durchzusehen (gw\"{o}hnlich /etc/my.cnf)
-Eventuell k\"{o}nnen Sie die Leistung wesentlich erh\"{o}hen, wenn Sie die Konfigurationsdateien
-my-large.cnf oder my-huge.cnf aus dem MySQL-Quellcode verwenden.
-
-F\"{u}r SQLite3 ist ein wichtiger Punkt, dass in der Konfiguration die Angabe "`PRAGMA synchronous = NORMAL;"'
-vorhanden ist. Dadurch werden die Zeitabst\"{a}nde vergr\"{o}{\ss}ert, in denen die Datenbank ihren RAM-Zwischenspeicher
-auf die Festplatte schreibt. Es gibt noch andere Einstellungen f\"{u}r PRAGMA die die Effizienz steigern k\"{o}nnen,
-aber auch das Risiko einer Datenbankbesch\"{a}digung beim Absturz des Systems erh\"{o}hen.
-
-Bei PostgreSQL sollten Sie eventuell in Betracht ziehen "`fsync"' abzuschalten,
-aber auch das kann bei Systemabst\"{u}rzen zu Datenbankprobleme f\"{u}hren.
-Es gibt viele Wege die Leistungsf\"{a}higkeit von PostgreSQL zu steigern,
-diese Internetseiten erkl\"{a}ren ein paar von ihnen (auf englisch):
-\elink{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
-{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
-
-Auch in den PostgreSQL FAQ's finden sich Hinweise die Performanz zu verbessern:
-\elink{http://www.postgresql.org/docs/faqs.FAQ.html}
-{http://www.postgresql.org/docs/faqs.FAQ.html}.
-
-Bei PostgreSQL sollten Sie auch auf die "`effective\_cache\_size"' achten.
-F\"{u}r ein System mit 2GB Arbeitsspeicher k\"{o}nnen Sie sie auf 131072 setzen,
-aber setzen Sie sie nicht zu hoch. Zus\"{a}tzlich sind "`work\_mem = 256000"' und
-"`maintenance\_work\_mem = 256000"', f\"{u}r Systeme mit 2GB Speicher, sinnvolle Werte.
-Stellen Sie sicher das "`checkpoint\_segments"' auf mindestens 8 gesetzt ist.
-
-\section{Datenbank-Leistung und Indexe}
-\index[general]{Datenbank-Leistung und Indexe}
-\index[general]{Leistung!Datenbank und Indexe}
-Eine der wichtigsten Aspekte die Leistungsf\"{a}higkeit der Bacula-Datenbank sicherzustellen ist zu \"{u}berpr\"{u}fen,
-ob alle Indexe richtig sind. Mehrere Benutzer haben angemerkt, dass ihre Datenbank in der Standardkonfiguration
-nicht alle notwendigen Indexe hatte. Auch werden Sie eventuell, abh\"{a}ngig von Ihrem Anwendungszweck,
-zus\"{a}tzlich Indexe ben\"{o}tigen.
-
-Die wichtigsten Indexe f\"{u}r eine schnelle Datenbank sind die drei Indexe auf der {\bf File}-Tabelle.
-Der erste Index ist auf der {\bf FileId} und wird automatisch anglegt, da es der eindeutige Schl\"{u}ssel ist,
-um auf die Tabelle zuzugreifen. Die anderen beiden sind der {\bf JobId}-Index und der {\bf Filename, PathId}-Index.
-Wenn einer dieser Indexe fehlt, verliert Ihre Datenbank enorm an Performance.
-
-\subsection{PostgreSQL Indexe}
-Bei PostgreSQL k\"{o}nnen Sie mit dem folgenden Kommandos \"{u}berpr\"{u}fen ob Sie alle Indexe haben:
-
-\footnotesize
-\begin{alltt}
-psql bacula
-select * from pg_indexes where tablename='file';
-\end{alltt}
-\normalsize
-
-Wenn Sie keine Ausgaben sehen die anzeigen das alle drei Indexe vorhanden sind,
-k\"{o}nnen Sie die beiden zus\"{a}tzlichen Indexe mit:
-
-\footnotesize
-\begin{alltt}
-psql bacula
-CREATE INDEX file_jobid_idx on file (jobid);
-CREATE INDEX file_fp_idx on file (filenameid, pathid);
-\end{alltt}
-\normalsize
-
-anlegen.
-
-\subsection{MySQL Indexes}
-Bei MySQL k\"{o}nnen Sie die Indexe mit:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-show index from File;
-\end{alltt}
-\normalsize
-
-\"{u}berpr\"{u}fen.
-Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-CREATE INDEX file_jobid_idx on File (JobId);
-CREATE INDEX file_jpf_idx on File (JobId, FilenameId, PathId);
-\end{alltt}
-\normalsize
-
-erzeugt werden.
-
-Obgleich das normalerweise kein Problem darstellt, sollten Sie sicherstellen, dass Ihre Indexe f\"{u}r {\bf Filename} und {\bf PathId}
-beide auf 255 Zeichen gesetzt sind. Einige Benutzer berichten von Problemen mit Indexen die auf 50 Zeichen gesetzt sind.
-Um das zu kontrollieren, f\"{u}hren Sie:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-show index from Filename;
-show index from Path;
-\end{alltt}
-\normalsize
-
-aus.
-F\"{u} die Dateinamen ist es wichtig, dass Sie einen Index haben mit dem Key\_name "`Name"' und dem Sub\_part "`255"'.
-F\"{u} den Pfad m\"{u}ssen Sie einen Index mit dem Key\_name "`Path"' und dem Sub\_part "`255"' haben.
-Wenn einer der Indexe nicht existiert oder der Sub\_part kleiner 255 ist, k\"{o}nnen Sie den Index neu anlegen indem Sie
-die folgende Kommandos benutzen:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-DROP INDEX Path on Path;
-CREATE INDEX Path on Path (Path(255);
-
-DROP INDEX Name on Filename;
-CREATE INDEX Name on Filename (Name(255));
-\end{alltt}
-\normalsize
-
-
-\subsection{SQLite Indexes}
-Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:
-
-\footnotesize
-\begin{alltt}
-sqlite <path>bacula.db
-select * from sqlite_master where type='index' and tbl_name='File';
-\end{alltt}
-\normalsize
-
-Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen:
-
-\footnotesize
-\begin{alltt}
-mysql bacula
-CREATE INDEX file_jobid_idx on File (JobId);
-CREATE INDEX file_jfp_idx on File (JobId, FilenameId, PathId);
-\end{alltt}
-\normalsize
-
-
-
-\label{CompactingPostgres}
-\section{Komprimieren Ihrer PostgreSQL Datenbank}
-\index[general]{Datenbank!Komprimieren Ihrer PostgreSQL }
-\index[general]{Komprimieren Ihrer PostgreSQL Datenbank }
-
-\"{U}ber die Zeit, wie schon oben angemerkt, wird Ihre Datenbank wachsen.
-Auch wenn Bacula regelm\"{a}{\ss}ig alte Daten l\"{o}scht, wird das PostgreSQL Kommando {\bf VACUUM}
-Ihnen helfen die Datenbank zu komprimieren. Alternativ wollen Sie eventuell das {\bf vacuumdb}-Kommando nutzen,
-das vom cron-Dienst gestartet werden kann.
-
-Alle Datenbanken haben Hilfsmittel, um die Daten in eine ASCII-Datei zu schreiben um sie dann erneut einzulesen.
-Wenn Sie das tun, wird die Datenbank komplett neu aufgebaut und so eine kompaktere Version entstehen.
-Wie Sie so etwas tun k\"{o}nnen, zeigt Ihnen das folgende PostgreSQL Beispiel.
-
-Bei einer PostgreSQL-Datenbank lassen Sie die Daten in eine ASCII-Datei schreiben und neu einlesen,
-wenn Sie diese Kommandos ausf\"{u}hren:
-
-\footnotesize
-\begin{alltt}
-pg_dump -c bacula > bacula.sql
-cat bacula.sql | psql bacula
-rm -f bacula.sql
-\end{alltt}
-\normalsize
-
-Abh\"{a}gig von Ihrer Datenbankgr\"{o}{\ss}e wird dieser Vorgang mehr oder
-weniger Zeit und Festplattenplatz in Anspruch nehmen. Sie sollten vorher
-in das Arbeitsverzeichnis Ihrer Datenbank wechseln (typischerweise
-/var/lib/postgres/data) und die Gr\"{o}{\ss}e \"{u}berpr\"{u}fen.
-
-Bestimmte PostgreSQL-Nutzer empfehlen nicht die oben genannte Prozedur, sie sind der Meinung:
-bei PostgreSQL ist es nicht notwendig, die Daten zu exportieren um sie dann wieder einzulesen.
-Das normale Ausf\"{u}hren des {\bf VACUUM}-Kommandos reicht, um die Datenbank performant zu halten.
-Wenn Sie es ganz genau machen wollen, benutzen Sie speziellen Kommandos {\bf VACUUM FULL, REINDEX} und {\bf CLUSTER}
-um sich den Umweg \"{u}ber das exportieren und wiedereinlesen der Daten zu ersparen.
-
-Zum Schlu{\ss} wollen Sie vielleicht noch einen Blick auf die zugeh\"{o}rige PostgreSQL-Dokumentation werfen,
-Sie finden sie (auf englisch) unter:
-\elink{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}
-{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}.
-
-\section{Komprimieren Ihrer SQLite Datenbank}
-\index[general]{Komprimieren Ihrer SQLite Datenbank}
-\index[general]{Datenbank!Komprimieren Ihrer SQLite }
-
-Lesen Sie bitte zuerst die vorherigen Abschnitte die erkl\"{a}ren, warum es erforderlich ist, eine Datenbank zu komprimieren.
-SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren:
-
-\footnotesize
-\begin{alltt}
-cd {\bf working-directory}
-echo 'vacuum;' | sqlite bacula.db
-\end{alltt}
-\normalsize
-
-Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:
-
-\footnotesize
-\begin{alltt}
-cd {\bf working-directory}
-echo '.dump' | sqlite bacula.db > bacula.sql
-rm -f bacula.db
-sqlite bacula.db < bacula.sql
-rm -f bacula.sql
-\end{alltt}
-\normalsize
-
-Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Dienst-Konfiguration angegeben haben.
-Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen,
-bevor die komprimierte Version angelegt werden kann.
-
-\section{Migration von SQLite zu MySQL/PostgreSQL}
-\index[general]{MySQL!Migration von SQLite zu }
-\index[general]{PostgreSQL!Migration von SQLite zu }
-\index[general]{Migration von SQLite zu MySQL/PostgreSQL }
-
-Wenn Sie Bacula anfangs mit SQLite zusammen benutzt haben, gibt es sp\"{a}ter
-eine Reihe von Gr\"{u}nden, weshalb Sie eventuell auf MySQL oder PostgreSQL
-umsteigen wollen:
-SQLite belegt mehr Festplattenplatz f\"{u}r dieselbe Datenmenge als MySQL;
-falls die Datenbank besch\"{a}digt wird, ist es mit SQLite problematischer als
-bei MySQL oder PostgreSQL, sie wiederherzustellen. Viele Benutzer sind erfolgreich
-von SQLite auf MySQL oder PostgreSQL umgestiegen, indem sie zuerst die Daten
-exportiert haben und sie dann mit einem Perl-Script in ein passendes Format
-konvertiert haben, um sie in die neue Datenbank zu importieren.
-Dies ist aber kein ganz einfacher Vorgang. Beispiel-Scripte dazu finden Sie
-im Bacula-Quelltext unter {\bf examples/database}.
-
-\label{BackingUpBacula}
-\section{Sichern Ihrer Bacula Datenbank}
-\index[general]{Sichern Ihrer Bacula Datenbank}
-\index[general]{Datenbank!Sichern Ihrer Bacula }
-
-Falls jemals der Rechner auf dem Ihre Bacula-Installation l\"{a}uft abst\"{u}rzt,
-und Sie diesen wiederherstellen m\"{u}ssen, wird es einer der ersten Schritte sein,
-die Datenbank zur\"{u}ckzusichern. Obwohl Bacula fr\"{o}hlich die Datenbank sichert,
-wenn sie im FileSet angegeben ist, ist das kein sehr guter Weg, da Bacula die Datenbank
-\"{a}ndert, w\"{a}hrend sie gesichert wird. Dadurch ist die gesicherte Datenbank wahrscheinlich
-in einem inkonsistenten Zustand. Noch schlimmer ist, dass die Datenbank gesichert wird,
-bevor Bacula alle Aktualisierungen durchf\"{u}hren kann.
-
-Um diese Problem zu umgehen, m\"{u}ssen Sie die Datenbank sichern nachdem alle Backup-Jobs
-gelaufen sind. Zus\"{a}tzlich werden Sie wohl eine Kopie der Datenbank erstellen wollen,
-w\"{a}hrend Bacula keine Aktualisierungen vornimmt. Um das zu erreichen, k\"{o}nnen Sie
-die beiden Scripte {\bf make\_catalog\_backup} und {\bf delete\_catalog\_backup} benutzen,
-die Ihrer Bacula-Version beiliegen. Diese Dateien werden, zusammen mit den anderen Bacula-Scripts,
-automatisch erzeugt. Das erste Script erzeugt eine ASCII-Kopie Ihrer Datenbank namens {\bf bacula.sql}
-in dem Arbeitsverzeichnis, dass Sie in der Konfiguration angegeben haben. Das zweite Script
-l\"{o}scht die Datei {\bf bacula.sql} wieder.
-
-Die grundlegenden Arbeitsschritte damit alles korrekt funktioniert, sind folgende:
-
-\begin{itemize}
-\item alle Backup-Jobs laufen lassen
-\item wenn alle Jobs beendet sind, wird ein Catalog Backup-Job gestartet
-\item Der Catalog Backup-Job muss nach den anderen Backup-Jobs laufen
-
-\item Benutzen Sie {\bf RunBeforeJob} um die ASCII-Sicherungsdatei zu erstellen und
- {\bf RunAfterJob} um sie wieder zu l\"{o}schen
-\end{itemize}
-
-Angenommen Sie starten alle Ihre Backup-Jobs nachts um 01:05, k\"{o}nnen Sie das Catalog-Backup
-mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen:
-
-\footnotesize
-\begin{alltt}
-# Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung)
-Job \{
- Name = BackupCatalog
- Type = Backup
- Client=rufus-fd
- FileSet=Catalog
- Schedule = WeeklyCycleAfterBackup
- Storage = DLTDrive
- Messages = Standard
- Pool = Default
- # Achtung!!! Das Passwort auf der Kommandozeile zu \"{u}bergeben ist nicht sicher.
- # Lesen Sie bitte die Kommentare in der Datei make_catalog_backup.
- RunBeforeJob = "/home/bacula/bin/make_catalog_backup"
- RunAfterJob = "/home/bacula/bin/delete_catalog_backup"
- Write Bootstrap = "/home/bacula/working/BackupCatalog.bsr"
-\}
-# Diese Schedule starten das Catalog-Backup nach den anderen Sicherungen
-Schedule \{
- Name = WeeklyCycleAfterBackup
- Run = Level=Full sun-sat at 1:10
-\}
-# Das FileSet f\"{u}r die ASCII-Kopie der Datenbank
-FileSet \{
- Name = Catalog
- Include \{
- Options \{
- signature=MD5
- \}
- File = "<working_directory>/bacula.sql"
- \}
-\}
-\end{alltt}
-\normalsize
-
-Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird.
-Bevorzugterweise wird eine Kopie dieser Bootstrap-Datei auf einem andern Computer gespeichert.
-Dies erlaubt eine schnelle Wiederherstellung der Datenbank, falls erforderlich. Wenn Sie
-keine Bootstrap-Datei haben, ist es trotzdem m\"{o}glich, erfordert aber mehr Arbeit und dauert l\"{a}nger.
-
-
-\label{BackingUpBaculaSecurityConsiderations}
-\section{Sicherheitsaspekte}
-\index[general]{Sicherung der Bacula Datenbank - Sicherheitsaspekte }
-\index[general]{Datenbank!Sicherung der Bacula Datenbank - Sicherheitsaspekte }
-
-Das Script make\_catalog\_backup wird als Beispiel bereitgestellt, wie Sie Ihre
-Bacula Datenbank sichern k\"{o}nnen. Wir erwarten das Sie, entsprechend Ihrer Situation,
-Vorsichtsma{\ss}nahmen treffen.
-make\_catalog\_backup ist so ausgelegt, dass das Passwort auf der Kommandozeile \"{u}bergeben wird.
-Das ist in Ordnung, solange sich nur vertrauensw\"{u}rdige Benutzer am System anmelden k\"{o}nnen,
-ansonsten ist es inakzeptabel. Die meisten Datenbanksysteme bieten eine alternative Methode an,
-um das Passwort nicht auf der Kommandozeile \"{u}bergeben zu m\"{u}ssen.
-
-Das Script make\_catalog\_backup enth\"{a}lt einige Warnungen dies betreffend. Bitte lesen Sie
-die Kommentare im Script.
-
-Bei PostgreSQL k\"{o}nnen Sie z.B. eine Passwort-Datei verwenden, siehe
-\elink{.pgpass}{http://www.postgresql.org/docs/8.2/static/libpq-pgpass.html},
-und MySQL hat die \elink{ .my.cnf}{http://dev.mysql.com/doc/refman/5.1/de/password-security.html}.
-
-Wir hoffen, dass wir Ihnen damit etwas helfen konnten,
-aber nur Sie k\"{o}nenn beurteilen, was in Ihrer Situation erforderlich ist.
-
-
-\label{BackingUPOtherDBs}
-\section{Sicherung anderer Datenbanken}
-\index[general]{Sicherung anderer Datenbanken }
-\index[general]{Datenbanken!Sicherung anderer }
-
-Wie oben schon erw\"{a}hnt wurde, f\"{u}hrt das Sichern von Datenbank-Dateien im laufenden Betrieb
-dazu, dass die gesicherten Dateien sich wahrscheinlich in einem inkonsistenten Zustand befinden.
-
-Die beste L\"{o}sung daf\"{u}r ist, die Datenbank vor der Sicherung zu stoppen,
-oder datenbankspezifische Hilfsprogramme zu verwenden, um eine g\"{u}ltige Sicherungsdatei zu erstellen,
-die Bacula dann auf die Volumes schreiben kann. Wenn Sie unsicher sind, wie Sie das am besten mit der
-von Ihnen benutzten Datenbank erreichen k\"{o}nnen, hilft Ihnen eventuell die Webseite von Backup Central
-weiter. Auf \elink{ Free Backup and Recovery Software}{http://www.backupcentral.com/toc-free-backup-software.html}
-finden Sie Links zu Scripts die zeigen, wie man die meisten gr\"{o}{\ss}eren Datenbanken sichern kann.
-
-\label{Size}
-\section{Datenbank Gr\"{o}{\ss}e}
-\index[general]{Gr\"{o}{\ss}e!Datenbank }
-\index[general]{Datenbank Gr\"{o}{\ss}e }
-
-Wenn Sie nicht automatisch alte Datens\"{a}tze aus Ihrer Katalog-Datenbank l\"{o}schen lassen,
-wird Ihre Datenbank mit jedem gelaufenen Backup-Job wachsen (siehe auch weiter oben).
-Normalerweise sollten Sie sich entscheiden, wie lange Sie die Datei-Eintr\"{a}ge im Katalog
-aufbewaren wollen und die {\bf File Retention} entsprechend konfigurieren. Dann k\"{o}nnen Sie
-entweder abwarten wie gro{\ss} Ihre Katalog-Datenbank werden wird, oder es aber auch unge\"{a}hr
-berechnen. Dazu m\"{u}ssen Sie wissen, dass f\"{u}r jede gesicherte Datei in etwa 154 Bytes in der
-Katalog-Datenbank belegt werden und wieviele Dateien Sie auf wievielen Computern sichern werden.
-
-Ein Beispiel: angenommen Sie sichern zwei Computer, jeder mit 100.000 Dateien.
-Weiterhin angenommen, Sie machen ein w\"{o}chentliches Full-Backup und ein
-inkrementelles jeden Tag, wobei bei einem inkrementellen Backup typischerweise 4.000 Dateien
-gesichert werden. Die ungef\"{a}hre Gr\"{o}{\ss}e Ihrer Datenbank nach einem Monat
-kann dann so berechnet werden:
-
-\footnotesize
-\begin{alltt}
- Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26)
-\end{alltt}
-\normalsize
-
-wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen.
-Das ergibt das folgende:
-\footnotesize
-\begin{alltt}
- Gr\"{o}{\ss}e = 154 * 2 * (100.000 * 4 + 10.000 * 26)
-or
- Gr\"{o}{\ss}e = 308 * (400.000 + 260.000)
-or
- Gr\"{o}{\ss}e = 203.280.000 Bytes
-\end{alltt}
-\normalsize
-
-f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank
-in etwa 200 Megabytes gro{\ss} wird. Nat\"{u}rlich h\"{a}ngt dieser Wert davon ab, wieviele
-Dateien wirklich gesichert werden.
-
-Unten sehen Sie ein paar Statistiken f\"{u}r eine MySQL-Datenbank die
-Job-Eintr\"{a}ge f\"{u}r 5 Clients \"{u}ber 8.5 Monate und
-Datei-Eintr\"{a}ge \"{u}ber 80 Tage enth\"{a}lt (\"{a}ltere
-Datei-Eintr\"{a}ge wurden schon gel\"{o}scht). Bei diesen 5 Clients wurden
-nur die Benutzer- und System-Dateien gesichert, die sich st\"{a}ndig
-\"{a}ndern. Bei allen anderen Dateien wird angenommen, dass sie leicht aus
-den Software-Paketen des Betriebssystems wiederherstellbar sind.
-
-In der Liste sind die Dateien (die den MySQL-Tabellen entsprechen) mit der Endung .MYD
-die, die die eigentlichen Daten enthalten und die mit der Endung .MYI enthalten die Indexe.
-
-Sie werden bemerken, dass die meisten Eintr\"{a}ge in der Datei File.MYD
-(die die Datei-Attribute enth\"{a}lt) enthalten sind und diese auch den
-meisten Platz auf der Festplatte belegt. Die {\bf File Retention} (der Aufbewahrungszeitraum
-f\"{u}r Dateien) ist also im wesentlichen daf\"{u}r verantwortlich, wie gro{\ss} die Datenbank wird.
-Eine kurze Berechnung zeigt, dass die Datenbank mit jeder gesicherten Datei ungef\"{a}hr um
-154 Bytes w\"{a}chst.
-
-\footnotesize
-\begin{alltt}
-Gr\"{o}{\ss}e
- in Bytes Eintr\"{a}ge Dateiname
- ============ ========= ===========
- 168 5 Client.MYD
- 3,072 Client.MYI
- 344,394,684 3,080,191 File.MYD
- 115,280,896 File.MYI
- 2,590,316 106,902 Filename.MYD
- 3,026,944 Filename.MYI
- 184 4 FileSet.MYD
- 2,048 FileSet.MYI
- 49,062 1,326 JobMedia.MYD
- 30,720 JobMedia.MYI
- 141,752 1,378 Job.MYD
- 13,312 Job.MYI
- 1,004 11 Media.MYD
- 3,072 Media.MYI
- 1,299,512 22,233 Path.MYD
- 581,632 Path.MYI
- 36 1 Pool.MYD
- 3,072 Pool.MYI
- 5 1 Version.MYD
- 1,024 Version.MYI
-\end{alltt}
-\normalsize
-
-Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes..
-
-H\"{a}tten wir SQLite genommen, w\"{a}re die Bestimmung der Datenbankgr\"{o}{\ss}e
-viel einfacher gewesen, da SQLite alle Daten in einer einzigen Datei speichert,
-dann aber h\"{a}tten wir nicht so einfach erkennen k\"{o}nnen, welche der Tabellen
-den meisten Speicherplatz ben\"{o}tigt.
-
-SQLite Datenbanken k\"{o}nnen bis zu 50 \% gr\"{o}{\ss}er sein als MySQL-Datenbanken
-(bei gleichem Datenbestand), weil bei SQLite alle Daten als ASCII-Zeichenketten gespeichert werden.
-Sogar bin\"{a}re Daten werden als ASCII-Zeichenkette dargestellt, und das scheint den Speicherverbrauch
-zu erh\"{o}hen.
projects / bacula / docs / blobdiff