Add new German manual

[bacula/docs] / docs / manuals / de / catalog / catmaintenance.tex

%%
%%

\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 konstante Gr\"{o}{\ss}e beibeh\"{a}lt.

Sie k\"{o}nnen mit der vorgegebenen Konfiguration beginnen, sie enth\"{a}lt bereits
sinnvolle Vorgaben f\"{u}r eine kleine Anzahl von Clients (kleiner 5), in diesem Fall
wird die Katalogwartung, wenn Sie einige hundert Megabyte freien Plattenplatz haben,
nicht dringlich sein. Was aber auch immer der Fall ist, einiges Wissen \"{u}ber
die Retention Periods/Aufbewahrungszeitr\"{a}ume der Daten im Katalog und auf den Volumes ist hilfreich.

\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 n\"{a}chsten Kapitel dieses Handbuchs.

\begin{description}

\item [File Retention = \lt{}time-period-specification\gt{}]
   \index[dir]{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
mit einem R\"{u}cksicherungs-Job wiederherzustellen, aber die Bacula-Versionen 1.37 und sp\"{a}ter
sind 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[dir]{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[dir]{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 ermitteln.

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{verbatim}
mysqldump -f --opt bacula > bacula.sql
mysql bacula < bacula.sql
rm -f bacula.sql
\end{verbatim}
\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{verbatim}
du bacula
\end{verbatim}
\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 < 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{verbatim}
#!/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{verbatim}
\normalsize

dieses Shell-Script, wird dann wie folgt aufgerufen:

\footnotesize
\begin{verbatim}
cd /var/lib/mysql/bacula
./repair
\end{verbatim}
\normalsize

nachdem sichergestellt ist, dass die Datenbank wieder korrekt funktioniert,
kann man die alten Datenbank-Dateien l\"{o}schen:
\footnotesize
\begin{verbatim}
cd /var/lib/mysql/bacula
rm -f x*.MYD
\end{verbatim}
\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{verbatim}
mysql bacula
SHOW TABLE STATUS FROM bacula like "File";
\end{verbatim}
\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{verbatim}
mysql bacula
ALTER TABLE File MAX_ROWS=281474976710656;
\end{verbatim}
\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{verbatim}
set-variable = myisam_data_pointer_size=6
\end{verbatim}
\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{verbatim}
psql bacula
select * from pg_indexes where tablename='file';
\end{verbatim}
\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{verbatim}
psql bacula
CREATE INDEX file_jobid_idx on file (jobid);
CREATE INDEX file_fp_idx on file (filenameid, pathid);
\end{verbatim}
\normalsize

anlegen.

\subsection{MySQL Indexes}
Bei MySQL k\"{o}nnen Sie die Indexe mit:

\footnotesize
\begin{verbatim}
mysql bacula
show index from File;
\end{verbatim}
\normalsize

\"{u}berpr\"{u}fen.
Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:

\footnotesize
\begin{verbatim}
mysql bacula
CREATE INDEX file_jobid_idx on File (JobId);
CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId);
\end{verbatim}
\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{verbatim}
mysql bacula
show index from Filename;
show index from Path;
\end{verbatim}
\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{verbatim}
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{verbatim}
\normalsize


\subsection{SQLite Indexes}
Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:

\footnotesize
\begin{verbatim}
sqlite <path>bacula.db
select * from sqlite_master where type='index' and tbl_name='File';
\end{verbatim}
\normalsize

Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen:

\footnotesize
\begin{verbatim}
mysql bacula
CREATE INDEX file_jobid_idx on File (JobId);
CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId);
\end{verbatim}
\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{verbatim}
pg_dump -c bacula > bacula.sql
cat bacula.sql | psql bacula
rm -f bacula.sql
\end{verbatim}
\normalsize

Abh\"{a}gig von Ihrer Datenabnkgr\"{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{verbatim}
cd {\bf working-directory}
echo 'vacuum;' | sqlite bacula.db
\end{verbatim}
\normalsize

Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:

\footnotesize
\begin{verbatim}
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{verbatim}
\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}
\index[general]{MySQL!Migration von SQLite zu }
\index[general]{Migration von SQLite zu MySQL }

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 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 umgestiegen, indem sie zuerst die Daten exportiert haben und sie dann
mit einem z.B. Perl-Script in ein passendes Format konvertiert haben, um sie in die
MySQL-Datenbank zu importieren. Dies ist aber kein sehr einfacher Vorgang.

\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{verbatim}
# 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/kern/bacula/bin/make_catalog_backup"
  RunAfterJob  = "/home/kern/bacula/bin/delete_catalog_backup"
  Write Bootstrap = "/home/kern/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 = \lt{}working_directory\gt{}/bacula.sql
  }
}
\end{verbatim}
\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{verbatim}
   Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26)
\end{verbatim}
\normalsize

wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen.
Das ergibt das folgende:
\footnotesize
\begin{verbatim}
   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{verbatim}
\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{verbatim}
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{verbatim}
\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.