From: Thomas Glatthor <Thomas.Glatthor@ic3s.de>
Date: Wed, 12 Sep 2007 19:38:01 +0000 (+0000)
Subject: ~20 % translated
X-Git-Tag: Release-3.0.0~2538
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=1b77afaf751a58d11db56f912e4f34ab3994ed6f;p=bacula%2Fdocs

~20 % translated
---

diff --git a/docs/manual-de/catmaintenance.tex b/docs/manual-de/catmaintenance.tex
index 77448757..a9cdb361 100644
--- a/docs/manual-de/catmaintenance.tex
+++ b/docs/manual-de/catmaintenance.tex
@@ -1,120 +1,113 @@
 %%
 %%
 
-\section*{Catalog Maintenance}
-\label{_ChapterStart12}
-\index[general]{Maintenance!Catalog }
-\index[general]{Catalog Maintenance }
-\addcontentsline{toc}{section}{Catalog Maintenance}
-
-Without proper setup and maintenance, your Catalog may continue to grow
-indefinitely as you run Jobs and backup Files. How fast the size of your
-Catalog grows depends on the number of Jobs you run and how many files they
-backup. By deleting records within the database, you can make space available
-for the new records that will be added during the next Job. By constantly
-deleting old expired records (dates older than the Retention period), your
-database size will remain constant. 
-
-If you started with the default configuration files, they already contain
-reasonable defaults for a small number of machines (less than 5), so if you
-fall into that case, catalog maintenance will not be urgent if you have a few
-hundred megabytes of disk space free. Whatever the case may be, some knowledge
-of retention periods will be useful. 
+\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 Megabytes 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- }
 
-\subsection*{Setting Retention Periods}
-\index[general]{Setting Retention Periods }
-\index[general]{Periods!Setting Retention }
-\addcontentsline{toc}{subsection}{Setting Retention Periods}
+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.
 
-{\bf Bacula} uses three Retention periods: the {\bf File Retention} period,
-the {\bf Job Retention} period, and the {\bf Volume Retention} period. Of
-these three, the File Retention period is by far the most important in
-determining how large your database will become. 
-
-The {\bf File Retention} and the {\bf Job Retention} are specified in each
-Client resource as is shown below. The {\bf Volume Retention} period is
-specified in the Pool resource, and the details are given in the next chapter
-of this manual. 
+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  }
-   The  File Retention record defines the length of time that  Bacula will keep
-File records in the Catalog database.  When this time period expires, and if
-{\bf AutoPrune} is set to {\bf yes}, Bacula will prune (remove) File records
-that  are older than the specified File Retention period. The pruning  will
-occur at the end of a backup Job for the given Client.  Note that the Client
-database record contains a copy of the  File and Job retention periods, but
-Bacula uses the  current values found in the Director's Client resource to  do
-the pruning.  
-
-Since File records in the database account for probably 80 percent of the 
-size of the database, you should carefully determine exactly what File
-Retention period you need. Once the File records have been removed from
-the database, you will no longer be able to restore individual files
-in a Job. However, with Bacula version 1.37 and later, as long as the
-Job record still exists, you will be able to restore all files in the
-job.
-
-Retention periods are specified in seconds, but as a convenience, there are
-a number of modifiers that permit easy specification in terms of minutes,
-hours, days, weeks, months, quarters, or years on the record.  See the
-\ilink{ Configuration chapter}{Time} of this manual for additional details
-of modifier specification.
-
-The default File retention period is 60 days.  
+   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  ge\"{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 Nummer von Hilfsangaben vorhanden, 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  }
-   The Job Retention record defines the length of time that {\bf Bacula}
-will keep Job records in the Catalog database.  When this time period
-expires, and if {\bf AutoPrune} is set to {\bf yes} Bacula will prune
-(remove) Job records that are older than the specified Job Retention
-period.  Note, if a Job record is selected for pruning, all associated File
-and JobMedia records will also be pruned regardless of the File Retention
-period set.  As a consequence, you normally will set the File retention
-period to be less than the Job retention period.
-
-As mentioned above, once the File records are removed from the database,
-you will no longer be able to restore individual files from the Job.
-However, as long as the Job record remains in the database, you will be
-able to restore all the files backuped for the Job (on version 1.37 and 
-later). As a consequence, it is generally a good idea to retain the Job
-records much longer than the File records.
-
-The retention period is specified in seconds, but as a convenience, there
-are a number of modifiers that permit easy specification in terms of
-minutes, hours, days, weeks, months, quarters, or years.  See the \ilink{
-Configuration chapter}{Time} of this manual for additional details of
-modifier specification.
-
-The default Job Retention period is 180 days.  
+   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 ge\"{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
+(mit 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 Nummer von Hilfsangaben vorhanden, 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  }
-   If AutoPrune is set to  {\bf yes} (default), Bacula will  automatically apply
-the File retention period and the Job  retention period for the Client at the
-end of the Job.  
-
-If you turn this off by setting it to {\bf no}, your  Catalog will grow each
-time you run a Job. 
+   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}
-
-\subsection*{Compacting Your MySQL Database}
-\index[general]{Database!Compacting Your MySQL }
-\index[general]{Compacting Your MySQL Database }
-\addcontentsline{toc}{subsection}{Compacting Your MySQL Database}
-
-Over time, as noted above, your database will tend to grow. I've noticed that
-even though Bacula regularly prunes files, {\bf MySQL} does not effectively
-use the space, and instead continues growing. To avoid this, from time to
-time, you must compact your database. Normally, large commercial database such
-as Oracle have commands that will compact a database to reclaim wasted file
-space. MySQL has the {\bf OPTIMIZE TABLE} command that you can use, and SQLite
+\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 has the {\bf OPTIMIZE TABLE} command that you can use, and SQLite
 version 2.8.4 and greater has the {\bf VACUUM} command. We leave it to you to
 explore the utility of the {\bf OPTIMIZE TABLE} command in MySQL. 
 
@@ -145,7 +138,7 @@ du bacula
 \normalsize
 
 I get {\bf 620,644} which means there are that many blocks containing 1024
-bytes each or approximately 635 MB of data. After doing the {\bf msqldump}, I
+bytes each or approximately 635 MB of data. After doing the {\bf mysqldump}, I
 had a bacula.sql file that had {\bf 174,356} blocks, and after doing the {\bf
 mysql} command to recreate the database, I ended up with a total of {\bf
 210,464} blocks rather than the original {\bf 629,644}. In other words, the
@@ -153,13 +146,13 @@ compressed version of the database took approximately one third of the space
 of the database that had been in use for about a year. 
 
 As a consequence, I suggest you monitor the size of your database and from
-time to time (once every 6 months or year), compress it. 
-\label{RepairingMySQL}
+time to time (once every six months or year), compress it. 
 
-\subsection*{Repairing Your MySQL Database}
+\label{DatabaseRepair}
+\label{RepairingMySQL}
+\section{Repairing Your MySQL Database}
 \index[general]{Database!Repairing Your MySQL }
 \index[general]{Repairing Your MySQL Database }
-\addcontentsline{toc}{subsection}{Repairing Your MySQL Database}
 
 If you find that you are getting errors writing to your MySQL database, or
 Bacula hangs each time it tries to access the database, you should consider
@@ -175,23 +168,120 @@ If the errors you are getting are simply SQL warnings, then you might try
 running dbcheck before (or possibly after) using the MySQL database repair
 program. It can clean up many of the orphaned record problems, and certain
 other inconsistencies in the Bacula database. 
-\label{RepairingPSQL}
 
-\subsection*{Repairing Your PostgreSQL Database}
+A typical cause of MySQL database problems is if your partition fills. In
+such a case, you will need to create additional space on the partition or
+free up some space then repair the database probably using {\bf myisamchk}.
+Recently my root partition filled and the MySQL database was corrupted.
+Simply running {\bf myisamchk -r} did not fix the problem. However,
+the following script did the trick for me:
+
+\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
+
+I invoked it with the following commands:
+
+\footnotesize
+\begin{verbatim}
+cd /var/lib/mysql/bacula
+./repair
+\end{verbatim}
+\normalsize
+
+Then after ensuring that the database was correctly fixed, I did:
+\footnotesize
+\begin{verbatim}
+cd /var/lib/mysql/bacula
+rm -f x*.MYD
+\end{verbatim}
+\normalsize
+
+\section{MySQL Table is Full}
+\index[general]{Database!MySQL Table is Full}
+\index[general]{MySQL Table is Full}
+
+If you are running into the error {\bf The table 'File' is full ...}, 
+it is probably because on version 4.x MySQL, the table is limited by   
+default to a maximum size of 4 GB and you have probably run into
+the limit. The solution can be found at:
+\elink{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
+{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
+
+You can display the maximum length of your table with:
+
+\footnotesize
+\begin{verbatim}
+mysql bacula
+SHOW TABLE STATUS FROM bacula like "File";
+\end{verbatim}
+\normalsize
+
+If the column labeled "Max\_data\_length" is around 4Gb, this is likely
+to be the source of your problem, and you can modify it with:
+
+\footnotesize
+\begin{verbatim}
+mysql bacula
+ALTER TABLE File MAX_ROWS=281474976710656;
+\end{verbatim}
+\normalsize
+
+Alternatively you can modify your /etc/my.conf file before creating the
+Bacula tables, and in the [mysqld] section set:
+
+\footnotesize                                 
+\begin{verbatim}
+set-variable = myisam_data_pointer_size=6
+\end{verbatim}
+\normalsize
+
+The above myisam data pointer size must be made before you create your
+Bacula tables or it will have no effect.
+
+The row and pointer size changes should already be the default on MySQL
+version 5.x, so making these changes should only be necessary on MySQL 4.x
+depending on the size of your catalog database.
+
+\section{MySQL Server Has Gone Away}
+\index[general]{Database!MySQL Server Has Gone Away}
+\index[general]{MySQL Server Has Gone Away}
+If you are having problems with the MySQL server disconnecting or with
+messages saying that your MySQL server has gone away, then please read
+the MySQL documentation, which can be found at:
+
+\elink{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
+{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
+
+
+\label{RepairingPSQL}
+\section{Repairing Your PostgreSQL Database}
 \index[general]{Database!Repairing Your PostgreSQL }
 \index[general]{Repairing Your PostgreSQL Database }
-\addcontentsline{toc}{subsection}{Repairing Your PostgreSQL Database}
 
 The same considerations apply that are indicated above for MySQL. That is,
 consult the PostgreSQL documents for how to repair the database, and also
 consider using Bacula's dbcheck program if the conditions are reasonable for
 using (see above). 
-\label{CompactingPostgres}
 
-\subsection*{Performance Issues}
+\label{DatabasePerformance}
+\section{Database Performance Issues}
 \index[general]{Database Performance Issues}
 \index[general]{Performance!Database}
-\addcontentsline{toc}{subsection}{Database Performance Issues}
 
 There are a considerable number of ways each of the databases can be
 tuned to improve the performance. Going from an untuned database to one
@@ -199,12 +289,13 @@ that is properly tuned can make a difference of a factor of 100 or more
 in the time to insert or search for records.
 
 For each of the databases, you may get significant improvements by adding
-additional indexes. The comments in the Bacula make_xxx_tables give some
+additional indexes. The comments in the Bacula make\_xxx\_tables give some
 indications as to what indexes may be appropriate.  Please see below
 for specific instructions on checking indexes.
 
-For MySQL, what seems to be very important is to use the examine the    
-my.cnf file. You may obtain significant performances by switching to
+For MySQL, what is very important is to use the examine the    
+my.cnf file (usually in /etc/my.cnf).
+You may obtain significant performances by switching to
 the my-large.cnf or my-huge.cnf files that come with the MySQL source
 code.
 
@@ -216,7 +307,7 @@ give even further performance improvements at the risk of a database
 corruption if your system crashes.
 
 For PostgreSQL, you might want to consider turning fsync off.  Of course
-doing so can cause corrupted databases in the even of a machine crash.
+doing so can cause corrupted databases in the event of a machine crash.
 There are many different ways that you can tune PostgreSQL, the
 following document discusses a few of them:
 \elink{
@@ -227,14 +318,21 @@ There is also a PostgreSQL FAQ question number 3.3 that may
 answer some of your questions about how to improve performance
 of the PostgreSQL engine:
 \elink{
-http://www.postgresql.org/docs/faqs.FAQ.html#3.3}
-{http://www.postgresql.org/docs/faqs.FAQ.html#3.3}.
+http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}
+{http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}.
+% TODO: verify above is correct. is this okay for book?
+
+Also for PostgreSQL, look at what "effective\_cache\_size". For a 2GB memory 
+machine, you probably want to set it at 131072, but don't set it too high.
+In addition, for a 2GB system, work\_mem = 256000 and
+maintenance\_work\_mem = 256000 seem to be reasonable values.  Make
+sure your checkpoint\_segments is set to at least 8.
+
 
 
-\subsection*{Performance Issues Indexes}
+\section{Performance Issues Indexes}
 \index[general]{Database Performance Issues Indexes}
 \index[general]{Performance!Database}
-\addcontentsline{toc}{subsection}{Database Performance Issues Indexes}
 One of the most important considerations for improving performance on
 the Bacula database is to ensure that it has all the appropriate indexes.
 Several users have reported finding that their database did not have
@@ -245,9 +343,9 @@ The most important indexes for performance are the three indexes on the
 {\bf File} table.  The first index is on {\bf FileId} and is automatically
 made because it is the unique key used to access the table.  The other
 two are the JobId index and the (Filename, PathId) index.  If these Indexes
-are not present, your peformance may suffer a lot.
+are not present, your performance may suffer a lot.
 
-\subsubsection*{PostgreSQL Indexes}
+\subsection{PostgreSQL Indexes}
 On PostgreSQL, you can check to see if you have the proper indexes using
 the following commands:
 
@@ -269,7 +367,7 @@ CREATE INDEX file_fp_idx on file (filenameid, pathid);
 \end{verbatim}
 \normalsize
 
-\subsubsection*{MySQL Indexes}
+\subsection{MySQL Indexes}
 On MySQL, you can check if you have the proper indexes by:
 
 \footnotesize
@@ -290,7 +388,38 @@ CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId);
 \end{verbatim}
 \normalsize
 
-\subsubsection*{SQLit Indexes}
+Though normally not a problem, you should ensure that the indexes 
+defined for Filename and Path are both set to 255 characters. Some users 
+reported performance problems when their indexes were set to 50 characters.
+To check, do:
+
+\footnotesize
+\begin{verbatim}
+mysql bacula
+show index from Filename;
+show index from Path;
+\end{verbatim}
+\normalsize
+
+and what is important is that for Filename, you have an index with
+Key\_name "Name" and Sub\_part "255". For Pth, you should have a Key\_name
+"Path" and Sub\_part "255".  If one or the other does not exist or the
+Sub\_part is less that 255, you can drop and recreate the appropriate
+index with:
+
+\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}
 On SQLite, you can check if you have the proper indexes by:
 
 \footnotesize
@@ -307,16 +436,16 @@ create them with the following commands:
 \begin{verbatim}
 mysql bacula
 CREATE INDEX file_jobid_idx on File (JobId);
-CREATE INDEX file_jpf_idx on File (Job, FilenameId, PathId);
+CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId);
 \end{verbatim}
 \normalsize
 
 
 
-\subsection*{Compacting Your PostgreSQL Database}
+\label{CompactingPostgres}
+\section{Compacting Your PostgreSQL Database}
 \index[general]{Database!Compacting Your PostgreSQL }
 \index[general]{Compacting Your PostgreSQL Database }
-\addcontentsline{toc}{subsection}{Compacting Your PostgreSQL Database}
 
 Over time, as noted above, your database will tend to grow. I've noticed that
 even though Bacula regularly prunes files, PostgreSQL has a {\bf VACUUM}
@@ -333,7 +462,7 @@ ASCII file (bacula.sql) then reload it by doing the following:
 
 \footnotesize
 \begin{verbatim}
-pg_dump bacula > bacula.sql
+pg_dump -c bacula > bacula.sql
 cat bacula.sql | psql bacula
 rm -f bacula.sql
 \end{verbatim}
@@ -344,10 +473,23 @@ fair amount of disk space. For example, you can {\bf cd} to the location of
 the Bacula database (typically /usr/local/pgsql/data or possible
 /var/lib/pgsql/data) and check the size. 
 
-\subsection*{Compacting Your SQLite Database}
+There are certain PostgreSQL users who do not recommend the above 
+procedure. They have the following to say:
+PostgreSQL does not
+need to be dumped/restored to keep the database efficient.  A normal
+process of vacuuming will prevent the database from every getting too
+large.  If you want to fine-tweak the database storage, commands such
+as VACUUM FULL, REINDEX, and CLUSTER exist specifically to keep you
+from having to do a dump/restore.
+
+Finally, you might want to look at the PostgreSQL documentation on
+this subject at
+\elink{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}
+{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}.  
+
+\section{Compacting Your SQLite Database}
 \index[general]{Compacting Your SQLite Database }
 \index[general]{Database!Compacting Your SQLite }
-\addcontentsline{toc}{subsection}{Compacting Your SQLite Database}
 
 First please read the previous section that explains why it is necessary to
 compress a database. SQLite version 2.8.4 and greater have the {\bf Vacuum}
@@ -378,27 +520,23 @@ Director's configuration file. Note, in the case of SQLite, it is necessary to
 completely delete (rm) the old database before creating a new compressed
 version. 
 
-\subsection*{Migrating from SQLite to MySQL}
+\section{Migrating from SQLite to MySQL}
 \index[general]{MySQL!Migrating from SQLite to }
 \index[general]{Migrating from SQLite to MySQL }
-\addcontentsline{toc}{subsection}{Migrating from SQLite to MySQL}
 
 You may begin using Bacula with SQLite then later find that you want to switch
 to MySQL for any of a number of reasons: SQLite tends to use more disk than
-MySQL, SQLite apparently does not handle database sizes greater than 2GBytes,
-... Several users have done so by first producing an ASCII "dump" of the
-SQLite database, then creating the MySQL tables with the {\bf
-create\_mysql\_tables} script that comes with Bacula, and finally feeding the
-SQLite dump into MySQL using the {\bf -f} command line option to continue past
-the errors that are generated by the DDL statements that SQLite's dump
-creates. Of course, you could edit the dump and remove the offending
-statements. Otherwise, MySQL accepts the SQL produced by SQLite. 
+MySQL; when the database is corrupted it is often more catastrophic than
+with MySQL or PostgreSQL.
+Several users have succeeded in converting from SQLite to MySQL by
+exporting the MySQL data and then processing it with Perl scripts
+prior to putting it into MySQL. This is, however, not a simple
+process.
 
 \label{BackingUpBacula}
-\subsection*{Backing Up Your Bacula Database}
+\section{Backing Up Your Bacula Database}
 \index[general]{Backing Up Your Bacula Database }
 \index[general]{Database!Backing Up Your Bacula }
-\addcontentsline{toc}{subsection}{Backing Up Your Bacula Database}
 
 If ever the machine on which your Bacula database crashes, and you need to
 restore from backup tapes, one of your first priorities will probably be to
@@ -426,7 +564,7 @@ The basic sequence of events to make this work correctly is as follows:
 
 \item You use {\bf RunBeforeJob} to create the ASCII  backup file and {\bf
    RunAfterJob} to clean up 
-   \end{itemize}
+\end{itemize}
 
 Assuming that you start all your nightly backup jobs at 1:05 am (and that they
 run one after another), you can do the catalog backup with the following
@@ -451,29 +589,31 @@ Job {
 # This schedule does the catalog. It starts after the WeeklyCycle
 Schedule {
   Name = "WeeklyCycleAfterBackup
-  Run = Full sun-sat at 1:10
+  Run = Level=Full sun-sat at 1:10
 }
 # This is the backup of the catalog
 FileSet {
   Name = "Catalog"
-  Include = signature=MD5 {
-     @working_directory@/bacula.sql
+  Include {
+    Options {
+      signature=MD5
+    }
+    File = \lt{}working_directory\gt{}/bacula.sql
   }
 }
 \end{verbatim}
 \normalsize
 
-Be sure to write a bootstrap file as in the above example. It is preferable
+Be sure to write a bootstrap file as in the above example. However, it is preferable
 to write or copy the bootstrap file to another computer. It will allow
 you to quickly recover the database backup should that be necessary.  If
 you do not have a bootstrap file, it is still possible to recover your
 database backup, but it will be more work and take longer. 
 
 \label{BackingUPOtherDBs}
-\subsection*{Backing Up Third Party Databases}
+\section{Backing Up Third Party Databases}
 \index[general]{Backing Up Third Party Databases }
 \index[general]{Databases!Backing Up Third Party }
-\addcontentsline{toc}{subsection}{Backing Up Third Party Databases}
 
 If you are running a database in production mode on your machine, Bacula will
 happily backup the files, but if the database is in use while Bacula is
@@ -492,10 +632,9 @@ links to scripts that show you how to shutdown and backup most major
 databases. 
 \label{Size}
 
-\subsection*{Database Size}
+\section{Database Size}
 \index[general]{Size!Database }
 \index[general]{Database Size }
-\addcontentsline{toc}{subsection}{Database Size}
 
 As mentioned above, if you do not do automatic pruning, your Catalog will grow
 each time you run a Job. Normally, you should decide how long you want File
@@ -516,7 +655,7 @@ database after a month can roughly be calculated as:
 \end{verbatim}
 \normalsize
 
-where we have assumed 4 weeks in a month and 26 incremental backups per month.
+where we have assumed four weeks in a month and 26 incremental backups per month.
 This would give the following: 
 
 \footnotesize
@@ -537,7 +676,7 @@ Below are some statistics for a MySQL database containing Job records for five
 Clients beginning September 2001 through May 2002 (8.5 months) and File
 records for the last 80 days. (Older File records have been pruned). For these
 systems, only the user files and system files that change are backed up. The
-core part of the system is assumed to be easily reloaded from the RedHat rpms.
+core part of the system is assumed to be easily reloaded from the Red Hat rpms.
 
 
 In the list below, the files (corresponding to Bacula Tables) with the