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 that 5), so if you
+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.
\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
+{\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.
-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.
+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.
-The default is 60 days.
+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.
\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 File 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.
-
-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 is 180 days.
-
-\item [AutoPrune = \lt{}yes|no\gt{}]
+ 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.
+
+\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
All database programs have some means of writing the database out in ASCII
format and then reloading it. Doing so will re-create the database from
scratch producing a compacted result, so below, we show you how you can do
-this for both MySQL and SQLite.
+this for MySQL, PostgreSQL and SQLite.
For a {\bf MySQL} database, you could write the Bacula database as an ASCII
file (bacula.sql) then reload it by doing the following:
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 orphanned record problems, and certain
+program. It can clean up many of the orphaned record problems, and certain
other inconsistencies in the Bacula database.
-\label{ReparingPSQL}
+\label{RepairingPSQL}
\subsection*{Repairing Your PostgreSQL Database}
\index[general]{Database!Repairing Your PostgreSQL }
using (see above).
\label{CompactingPostgres}
+\subsection*{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
+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
+indications as to what indexes may be appropriate.
+
+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
+the my-large.cnf or my-huge.cnf files that come with the MySQL source
+code.
+
+For SQLite3, one significant factor in improving the performance is
+to ensure that there is a "PRAGMA synchronous = NORMAL;" statement.
+This reduces the number of times that the database flushes the in memory
+cache to disk. There are other settings for this PRAGMA that can
+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.
+There are many different ways that you can tune PostgreSQL, the
+following document discusses a few of them:
+\elink{
+http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
+{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
+
+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}.
+
+
+
+
\subsection*{Compacting Your PostgreSQL Database}
\index[general]{Database!Compacting Your PostgreSQL }
\index[general]{Compacting Your PostgreSQL Database }
\footnotesize
\begin{verbatim}
cd {\bf working-directory}
-echo 'vacuum' | sqlite bacula.db
+echo 'vacuum;' | sqlite bacula.db
\end{verbatim}
\normalsize
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
+... 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.
-\label{BackingUpBacula}
+\label{BackingUpBacula}
\subsection*{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 you Bacula database crashes, and you need to
+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
recover the database. Although Bacula will happily backup your catalog
database if it is specified in the FileSet, this is not a very good way to do
-it because the database will be saved while Bacula is modifying it. Thus the
-database may be in and instable state. Worse yet, you will backup the database
+it, because the database will be saved while Bacula is modifying it. Thus the
+database may be in an instable state. Worse yet, you will backup the database
before all the Bacula updates have been applied.
-To resolve these problems, you need backup the database after all the backup
+To resolve these problems, you need to backup the database after all the backup
jobs have been run. In addition, you will want to make a copy while Bacula is
not modifying it. To do so, you can use two scripts provided in the release
{\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
will be automatically generated along with all the other Bacula scripts. The
first script will make an ASCII copy of your Bacula database into {\bf
-bacula.sql} in the working directory you specified on your configuration, and
+bacula.sql} in the working directory you specified in your configuration, and
the second will delete the {\bf bacula.sql} file.
The basic sequence of events to make this work correctly is as follows:
Pool = Default
RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
+ Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
}
# This schedule does the catalog. It starts after the WeeklyCycle
Schedule {
\end{verbatim}
\normalsize
-\label{BackingUPOtherDBs}
+Be sure to write a bootstrap file as in the above example. 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}
\index[general]{Backing Up Third Party Databases }
\index[general]{Databases!Backing Up Third Party }
projects / bacula / docs / blobdiff