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.
+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 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.
+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}
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.
+angegeben, genauere Informationen dazu finden Sie im Handbuch "`Bacula Installation und Konfiguration"'.
\begin{description}
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.
+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,
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.
+{\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
in eine ASCII-Datei (bacula.sql) schreiben und neu in die Datenbank importieren:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
mysqldump -f --opt bacula > bacula.sql
mysql bacula < bacula.sql
rm -f bacula.sql
-\end{verbatim}
+\end{alltt}
\normalsize
Abh\"{a}ngig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
/var/lib/mysql) und dieses Kommando ausf\"{u}hre:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
du bacula
-\end{verbatim}
+\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 < 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.
kopieren Sie folgende Zeilen in ein Shell-Script names {\bf repair}:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
#!/bin/sh
for i in *.MYD ; do
- mv $i x${i}
- t=`echo $i | cut -f 1 -d '.' -`
+ mv \$i x\$\{i\}
+ t=`echo \$i | cut -f 1 -d '.' -`
mysql bacula <<END_OF_DATA
set autocommit=1;
-truncate table $t;
+truncate table \$t;
quit
END_OF_DATA
- cp x${i} ${i}
- chown mysql:mysql ${i}
- myisamchk -r ${t}
+ cp x\$\{i\} \$\{i\}
+ chown mysql:mysql \$\{i\}
+ myisamchk -r \$\{t\}
done
-\end{verbatim}
+\end{alltt}
\normalsize
dieses Shell-Script, wird dann wie folgt aufgerufen:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
cd /var/lib/mysql/bacula
./repair
-\end{verbatim}
+\end{alltt}
\normalsize
nachdem sichergestellt ist, dass die Datenbank wieder korrekt funktioniert,
kann man die alten Datenbank-Dateien l\"{o}schen:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
cd /var/lib/mysql/bacula
rm -f x*.MYD
-\end{verbatim}
+\end{alltt}
\normalsize
\section{MySQL-Tabelle ist voll}
Sie k\"{o}nnen sich die maximale Tabellengr\"{o}{\ss}e mit:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
mysql bacula
SHOW TABLE STATUS FROM bacula like "File";
-\end{verbatim}
+\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{verbatim}
+\begin{alltt}
mysql bacula
ALTER TABLE File MAX_ROWS=281474976710656;
-\end{verbatim}
+\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{verbatim}
+\begin{alltt}
set-variable = myisam_data_pointer_size=6
-\end{verbatim}
+\end{alltt}
\normalsize
Bei PostgreSQL k\"{o}nnen Sie mit dem folgenden Kommandos \"{u}berpr\"{u}fen ob Sie alle Indexe haben:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
psql bacula
select * from pg_indexes where tablename='file';
-\end{verbatim}
+\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{verbatim}
+\begin{alltt}
psql bacula
CREATE INDEX file_jobid_idx on file (jobid);
CREATE INDEX file_fp_idx on file (filenameid, pathid);
-\end{verbatim}
+\end{alltt}
\normalsize
anlegen.
Bei MySQL k\"{o}nnen Sie die Indexe mit:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
mysql bacula
show index from File;
-\end{verbatim}
+\end{alltt}
\normalsize
\"{u}berpr\"{u}fen.
Wenn Indexe fehlen, besonders der {\bf JobId}-Index, kann er mit:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
mysql bacula
CREATE INDEX file_jobid_idx on File (JobId);
CREATE INDEX file_jpf_idx on File (JobId, FilenameId, PathId);
-\end{verbatim}
+\end{alltt}
\normalsize
erzeugt werden.
Um das zu kontrollieren, f\"{u}hren Sie:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
mysql bacula
show index from Filename;
show index from Path;
-\end{verbatim}
+\end{alltt}
\normalsize
aus.
die folgende Kommandos benutzen:
\footnotesize
-\begin{verbatim}
+\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{verbatim}
+\end{alltt}
\normalsize
Bei SQLite k\"{o}nnen Sie so die Indexe \"{u}berpr\"{u}fen:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
sqlite <path>bacula.db
select * from sqlite_master where type='index' and tbl_name='File';
-\end{verbatim}
+\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{verbatim}
+\begin{alltt}
mysql bacula
CREATE INDEX file_jobid_idx on File (JobId);
CREATE INDEX file_jfp_idx on File (JobId, FilenameId, PathId);
-\end{verbatim}
+\end{alltt}
\normalsize
wenn Sie diese Kommandos ausf\"{u}hren:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
pg_dump -c bacula > bacula.sql
cat bacula.sql | psql bacula
rm -f bacula.sql
-\end{verbatim}
+\end{alltt}
\normalsize
-Abh\"{a}gig von Ihrer Datenabnkgr\"{o}{\ss}e wird dieser Vorgang mehr oder
+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.
SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
cd {\bf working-directory}
echo 'vacuum;' | sqlite bacula.db
-\end{verbatim}
+\end{alltt}
\normalsize
Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen:
\footnotesize
-\begin{verbatim}
+\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{verbatim}
+\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}
+\section{Migration von SQLite zu MySQL/PostgreSQL}
\index[general]{MySQL!Migration von SQLite zu }
-\index[general]{Migration von SQLite zu MySQL }
+\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 umsteigen wollen:
+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 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.
+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}
mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
# Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung)
-Job {
- Name = "BackupCatalog"
+Job \{
+ Name = BackupCatalog
Type = Backup
Client=rufus-fd
- FileSet="Catalog"
- Schedule = "WeeklyCycleAfterBackup"
+ 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"
-}
+ 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
+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 {
+FileSet \{
+ Name = Catalog
+ Include \{
+ Options \{
signature=MD5
- }
- File = \lt{}working_directory\gt{}/bacula.sql
- }
-}
-\end{verbatim}
+ \}
+ File = "<working_directory>/bacula.sql"
+ \}
+\}
+\end{alltt}
\normalsize
Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird.
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 }
kann dann so berechnet werden:
\footnotesize
-\begin{verbatim}
+\begin{alltt}
Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26)
-\end{verbatim}
+\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{verbatim}
+\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{verbatim}
+\end{alltt}
\normalsize
f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank
154 Bytes w\"{a}chst.
\footnotesize
-\begin{verbatim}
+\begin{alltt}
Gr\"{o}{\ss}e
in Bytes Eintr\"{a}ge Dateiname
============ ========= ===========
3,072 Pool.MYI
5 1 Version.MYD
1,024 Version.MYI
-\end{verbatim}
+\end{alltt}
\normalsize
Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes..
projects / bacula / docs / blobdiff