-1.39.5 (14 February 2006)
+1.39.5 (20 February 2006)
-1.39.5 (14 February 2006)
+1.39.5 (20 February 2006)
slot number when you label Volumes.
\end{itemize}
-In version 1.37, there is a new \ilink{Autochanger
+In version 1.37 and later, there is a new \ilink{Autochanger
resource}{AutochangerRes} that permits you to group Device resources thus
-creating a multi-drive autochanger. If you have a multi-drive autochanger,
-you must use this new resource. If you have a single drive autochanger,
-it is recommended, but not required.
+creating a multi-drive autochanger. If you have an autochanger,
+you must use this new resource.
Bacula uses its own {\bf mtx-changer} script to interface with a program
that actually does the tape changing. Thus in principle, {\bf mtx-changer}
enabled, and thus used again. By setting {\bf MaximumVolumeJobs} to
one, you get the same effect as setting {\bf UseVolumeOnce = yes}.
-The value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ The value defined by this directive in the bacula-dir.conf
+ file is the default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change what
+ is stored for the Volume. To change the value for an existing Volume you
+ must use the {\bf update} command in the Console.
\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
\index[dir]{Maximum Volume Files }
The Volume Use Duration directive defines the time period that the
Volume can be written beginning from the time of first data write to the
Volume. If the time-period specified is zero (the default), the Volume
- can be written indefinitely. Otherwise, when the time period from the
+ can be written indefinitely. Otherwise, the next time a job
+ runs that wants to access this Volume, and the time period from the
first write to the volume (the first Job written) exceeds the
time-period-specification, the Volume will be marked {\bf Used}, which
means that no more Jobs can be appended to the Volume, but it may be
- recycled if recycling is enabled. Once the Volume is
+ recycled if recycling is enabled. Using the command {\bf
+ status dir} applies algorithms similar to running jobs, so
+ during such a command, the Volume status may also be changed.
+ Once the Volume is
recycled, it will be available for use again.
You might use this directive, for example, if you have a Volume used for
is the one that effectively takes precedence. Note, that when the {\bf
Volume Retention} period has been reached, and it is necessary to obtain
a new volume, Bacula will prune both the Job and the File records.
+ This pruning could also occur during a {\bf status dir}
+ command because it uses similar algorithms for finding the
+ next available Volume.
It is important to know that when the Volume Retention period expires,
Bacula does not automatically recycle a Volume. It attempts to keep the
Recycle = yes
AutoPrune = yes
Volume Retention = 6 months
- Accept Any Volume = yes
Maximum Volume Jobs = 1
Label Format = Full-
Maximum Volumes = 6
Recycle = yes
AutoPrune = yes
Volume Retention = 40 days
- Accept Any Volume = yes
Maximum Volume Jobs = 1
Label Format = Diff-
Maximum Volumes = 6
Recycle = yes
AutoPrune = yes
Volume Retention = 20 days
- Accept Any Volume = yes
Maximum Volume Jobs = 6
Label Format = Inc-
Maximum Volumes = 5
Recycle = yes # automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 6 months
- Accept Any Volume = yes # write on any volume in the pool
Maximum Volume Jobs = 1
Label Format = Full-
Maximum Volumes = 6
Recycle = yes # automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 20 days
- Accept Any Volume = yes
Maximum Volume Jobs = 6
Label Format = Inc-
Maximum Volumes = 5
Recycle = yes
AutoPrune = yes
Volume Retention = 40 days
- Accept Any Volume = yes
Maximum Volume Jobs = 1
Label Format = Diff-
Maximum Volumes = 6
\index[general]{Dbcheck }
\addcontentsline{toc}{subsection}{dbcheck}
-{\bf dbcheck} is a simple program that will search for inconsistencies in your
-database, and optionally fix them. The {\bf dbcheck} program can be found in
+{\bf dbcheck} is a simple program that will search for logical
+inconsistencies in the Bacula tables in your database, and optionally fix them.
+It is a database maintenance routine, in the sense that it can
+detect and remove unused rows, but it is not a database repair
+routine. To repair a database, see the tools furnished by the
+database vendor. Normally dbcheck should never need to be run,
+but if Bacula has crashed or you have a lot of Clients, Pools, or
+Jobs that you have removed, it could be useful.
+
+The {\bf dbcheck} program can be found in
the {\bf \lt{}bacula-source\gt{}/src/tools} directory of the source
distribution. Though it is built with the make process, it is not normally
"installed".
\item Duplicate filename records. This can happen if you accidentally run two
copies of Bacula at the same time, and they are both adding filenames
simultaneously. It is a rare occurrence, but will create an inconsistent
-database. If this is the case, you will receive error messages during Jobs
-warning of duplicate database records. If you are not getting these error
-messages, there is no reason to run this check.
+ database. If this is the case, you will receive error messages during Jobs
+ warning of duplicate database records. If you are not getting these error
+ messages, there is no reason to run this check.
\item Repair bad Filename records. This checks and corrects filenames that
have a trailing slash. They should not.
\item Repair bad Path records. This checks and corrects path names that do
\item Duplicate path records. This can happen if you accidentally run two
copies of Bacula at the same time, and they are both adding filenames
simultaneously. It is a rare occurrence, but will create an inconsistent
-database. See the item above for why this occurs and how you know it is
-happening.
+ database. See the item above for why this occurs and how you know it is
+ happening.
\item Orphaned JobMedia records. This happens when a Job record is deleted
(perhaps by a user issued SQL statement), but the corresponding JobMedia
record (one for each Volume used in the Job) was not deleted. Normally, this
-should not happen, and even if it does, these records generally do not take
-much space in your database. However, by running this check, you can
-eliminate any such orphans.
+ should not happen, and even if it does, these records generally do not take
+ much space in your database. However, by running this check, you can
+ eliminate any such orphans.
\item Orphaned File records. This happens when a Job record is deleted
(perhaps by a user issued SQL statement), but the corresponding File record
(one for each Volume used in the Job) was not deleted. Note, searching for
-these records can be {\bf very} time consuming (i.e. it may take hours) for a
-large database. Normally this should not happen as Bacula takes care to
-prevent it. Just the same, this check can remove any orphaned File records.
-It is recommended that you run this once a year since orphaned File records
-can take a large amount of space in your database.
+ these records can be {\bf very} time consuming (i.e. it may take hours) for a
+ large database. Normally this should not happen as Bacula takes care to
+ prevent it. Just the same, this check can remove any orphaned File records.
+ It is recommended that you run this once a year since orphaned File records
+ can take a large amount of space in your database. You might
+ want to ensure that you have indexes on JobId, FilenameId, and
+ PathId for the File table in your catalog before running this
+ command.
\item Orphaned Path records. This condition happens any time a directory is
deleted from your system and all associated Job records have been purged.
During standard purging (or pruning) of Job records, Bacula does not check
-for orphaned Path records. As a consequence, over a period of time, old
-unused Path records will tend to accumulate and use space in your database.
-This check will eliminate them. It is strongly recommended that you run this
-check at least once a year.
+ for orphaned Path records. As a consequence, over a period of time, old
+ unused Path records will tend to accumulate and use space in your database.
+ This check will eliminate them. It is recommended that you run this
+ check at least once a year.
\item Orphaned Filename records. This condition happens any time a file is
deleted from your system and all associated Job records have been purged.
This can happen quite frequently as there are quite a large number of files
-that are created and then deleted. In addition, if you do a system update or
-delete an entire directory, there can be a very large number of Filename
-records that remain in the catalog but are no longer used.
-
-During standard purging (or pruning) of Job records, Bacula does not check
-for orphaned Filename records. As a consequence, over a period of time, old
-unused Filename records will accumulate and use space in your database. This
-check will eliminate them. It is strongly recommended that you run this check
-at least once a year, and for large database (more than 200 Megabytes), it is
-probably better to run this once every 6 months.
+ that are created and then deleted. In addition, if you do a system update or
+ delete an entire directory, there can be a very large number of Filename
+ records that remain in the catalog but are no longer used.
+
+ During standard purging (or pruning) of Job records, Bacula does not check
+ for orphaned Filename records. As a consequence, over a period of time, old
+ unused Filename records will accumulate and use space in your database. This
+ check will eliminate them. It is strongly recommended that you run this check
+ at least once a year, and for large database (more than 200 Megabytes), it is
+ probably better to run this once every 6 months.
\item Orphaned Client records. These records can remain in the database long
after you have removed a client.
\item Orphaned Job records. If no client is defined for a job or you do not
run a job for a long time, you can accumulate old job records. This option
allow you to remove jobs that are not attached to any client (and thus
-useless).
+ useless).
\item All Admin records. This command will remove all Admin records,
regardless of their age.
\item All Restore records. This command will remove all Restore records,
regardless of their age.
- \end{itemize}
+\end{itemize}
+
+By the way, I personally run dbcheck only where I have messed up
+my database due to a bug in developing Bacula code, so normally
+you should never need to run dbcheck inspite of the
+recommendations given above, which are given so that users don't
+waste their time running dbcheck too often.
\subsection*{testfind}
\label{testfind}
the volume can be marked Purged and hence recycled.
The full algorithm that Bacula uses when it needs a new Volume is:
+\index[general]{New Volume Algorithm}
+\index[general]{Algorithm!New Volume}
\begin{itemize}
\item Search the Pool for a Volume with VolStatus=Append (if there is more
than one, the Volume with the oldest date last written is chosen. If
two have the same date then the one with the lowest MediaId is chosen).
+\item If the current device is an Autochanger, search the Scratch
+ Pool for a Volume that is in the Autochanger. If found, move
+ it to the correct Pool.
\item Search the Pool for a Volume with VolStatus=Recycle and the InChanger
flag is set true (if there is more than one, the Volume with the oldest
date last written is chosen. If two have the same date then the one
The recycling algorithm in this case is:
\begin{itemize}
-\item If the VolStatus is {\bf Append} or {\bf Recycle} and {\bf Accept Any
- Volume} is set, the volume will be used.
+\item If the VolStatus is {\bf Append} or {\bf Recycle}
+ is set, the volume will be used.
\item If {\bf Recycle Current Volume} is set and the volume is marked {\bf
Full} or {\bf Used}, Bacula will prune the volume (applying the retention
period). If all Jobs are pruned from the volume, it will be recycled.
created (at the Run yes/mod/no) prompt but before you start the restore.
\end{enumerate}
+\subsection*{Restore Errors}
+\index[general]{Errors!Restore}
+\index[general]{Restore Errors}
+\addcontentsline{toc}{subsection}{Restore Errors}
+
+There are a number of reasons why there may be restore errors or
+warning messages. Some of the more common ones are:
+
+\begin{description}
+
+\item [file count mismatch]
+ This can occur for the following reasons:
+ \begin{itemize}
+ \item You requested Bacula not to overwrite existing or newer
+ files.
+ \item A Bacula miscount of files/directories. This is an
+ on-going problem due to the complications of directories,
+ soft/hard link, and such. Simply check that all the files you
+ wanted were actually restored.
+ \end{itemize}
+\item [file size error]
+ When Bacula restores files, it checks that the size of the
+ restored file is the same as the file status data it saved
+ when starting the backup of the file. If the sizes do not
+ agree, Bacula will print an error message. This size mismatch
+ most often occurs because the file was being written as Bacula
+ backed up the file. In this case, the size that Bacula
+ restored will be greater than the status size. This often
+ happens with log files.
+
+ If the restored size is smaller, then you should be concerned
+ about a possible tape error and check the Bacula output as
+ well as your system logs.
+\end{description}
+
+
+
\subsection*{Example Restore Job Resource}
\index[general]{Example Restore Job Resource }
\index[general]{Resource!Example Restore Job }
important purposes.
\begin{itemize}
-\item It can take a long time for data to come in from the File daemon during
- an Incremental backup. If it is directly written to tape, the tape will start
- and stop or shoe-shine as it is often called causing tape wear. By first
- writing the data to disk, then writing it to tape, the tape can be kept in
- continual motion.
-\item While the spooled data is being written to the tape, the despooling
- process has exclusive use of the tape. This means that you can spool multiple
- simultaneous jobs to disk, then have them very efficiently despooled one at a
- time without having the data blocks from several jobs intermingled, thus
- substantially improving the time needed to restore files.
-\item Writing to a tape can be slow. By first spooling your data to disk, you
- can often reduce the time the File daemon is running on a system, thus
- reducing downtime, and/or interference with users.
+\item It take a long time for data to come in from the File daemon during
+ an Incremental backup. If it is directly written to tape, the tape will
+ start and stop or shoe-shine as it is often called causing tape wear.
+ By first writing the data to disk, then writing it to tape, the tape can
+ be kept in continual motion.
+\item While the spooled data is being written to the tape, the despooling
+ process has exclusive use of the tape. This means that you can spool
+ multiple simultaneous jobs to disk, then have them very efficiently
+ despooled one at a time without having the data blocks from several jobs
+ intermingled, thus substantially improving the time needed to restore
+ files. While despooling, all jobs spooling continue running.
+\item Writing to a tape can be slow. By first spooling your data to disk,
+ you can often reduce the time the File daemon is running on a system,
+ thus reducing downtime, and/or interference with users. Of course, if
+ your spool device is not large enough to hold all the data from your
+ File daemon, you may actually slow down the overall backup.
\end{itemize}
-Data spooling is exactly that "spooling". It is not a way to first write a
-"backup" to a disk file and then to a tape. When the backup has only been spooled to disk,
-it is not complete yet and cannot be restored until it is written to tape. In a
-future version, Bacula will support writing a backup to disk then later {\bf
-Migrating} or {\bf Copying} it to a tape.
+Data spooling is exactly that "spooling". It is not a way to first write a
+"backup" to a disk file and then to a tape. When the backup has only been
+spooled to disk, it is not complete yet and cannot be restored until it is
+written to tape. In a future version, Bacula will support writing a backup
+to disk then later {\bf Migrating} or {\bf Copying} it to a tape.
The remainder of this chapter explains the various directives that you can use
in the spooling process.
\addcontentsline{toc}{subsection}{What is Implemented}
\begin{itemize}
-\item Network backup/restore with centralized Director.
-\item Internal scheduler for automatic
- \ilink{Job}{JobDef} execution.
-\item Scheduling of multiple Jobs at the same time.
-\item You may run one Job at a time or multiple simultaneous Jobs.
-\item Job sequencing using priorities.
-\item Restore of one or more files selected interactively either for the
- current backup or a backup prior to a specified time and date.
-\item Restore of a complete system starting from bare metal. This is mostly
- automated for Linux systems and partially automated for Solaris. See
- \ilink{Disaster Recovery Using Bacula}{_ChapterRescue}. This is also
- reported to work on Win2K/XP systems.
-\item Listing and Restoration of files using stand-alone {\bf bls} and {\bf
- bextract} tool programs. Among other things, this permits extraction of files
- when Bacula and/or the catalog are not available. Note, the recommended way
- to restore files is using the restore command in the Console. These programs
- are designed for use as a last resort.
-\item Ability to recreate the catalog database by scanning backup Volumes
- using the {\bf bscan} program.
-\item
- \ilink{Console}{UADef} interface to the Director allowing complete
- control. A shell, GNOME GUI and wxWidgets GUI versions of the Console program
- are available. Note, the GNOME GUI program currently offers very few
- additional features over the shell program.
-\item Verification of files previously cataloged, permitting a Tripwire like
- capability (system break-in detection).
-\item CRAM-MD5 password authentication between each component (daemon).
-\item Configurable
- \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component.
-\item A comprehensive and extensible
- \ilink{configuration file}{_ChapterStart40} for each daemon.
-\item Catalog database facility for remembering Volumes, Pools, Jobs, and
- Files backed up.
-\item Support for SQLite, PostgreSQL, and MySQL Catalog databases.
-\item User extensible queries to the SQLite, PostgreSQL and MySQL databases.
-\item Labeled Volumes, preventing accidental overwriting (at least by
- Bacula).
-\item Any number of Jobs and Clients can be backed up to a single Volume.
- That is, you can backup and restore Linux, Unix, Sun, and Windows machines to
- the same Volume.
-\item Multi-volume saves. When a Volume is full, {\bf Bacula} automatically
- requests the next Volume and continues the backup.
-\item
- \ilink{Pool and Volume}{PoolResource} library management
- providing Volume flexibility (e.g. monthly, weekly, daily Volume sets, Volume
- sets segregated by Client, ...).
-\item Machine independent Volume data format. Linux, Solaris, and Windows
- clients can all be backed up to the same Volume if desired.
-\item A flexible
- \ilink{ message}{MessageResource} handler including routing
- of messages from any daemon back to the Director and automatic email
- reporting.
-\item Multi-threaded implementation.
-\item Programmed to handle arbitrarily long filenames and messages.
-\item GZIP compression on a file by file basis done by the Client program if
- requested before network transit.
-\item Computation of MD5 or SHA1 signatures of the file data if requested.
-\item Saves and restores POSIX ACLs on most OSes if enabled.
-\item Autochanger support using a simple shell interface that can interface
- to virtually any autoloader program. A script for {\bf mtx} is provided.
-\item Support for autochanger barcodes -- automatic tape labeling from
- barcodes.
-\item Automatic support for multiple autochanger magazines either using
- barcodes or by reading the tapes.
-\item Support for multiple drive autochangers.
-\item Raw device backup/restore. Restore must be to the same device.
-\item All Volume blocks (approx 64K bytes) contain a data checksum.
-\item Access control lists for Consoles that permit restricting user access
- to only their data.
-\item Data spooling to disk during backup with subsequent write to tape from
- the spooled disk files. This prevents tape "shoe shine" during
- Incremental/Differential backups.
-\item Support for save/restore of files larger than 2GB.
-\item Support for 64 bit machines, e.g. amd64.
-\item Ability to encrypt communications between daemons using stunnel.
-\item Support ANSI and IBM tape labels.
-\item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
- version 1.37.28 and greater.
-\item Consistent backup of open files on Win32 systems (WinXP, Win2003),
- but not Win2000, using Volume Shadow Copy (VSS).
+\item Job Control
+ \begin{itemize}
+ \item Network backup/restore with centralized Director.
+ \item Internal scheduler for automatic
+ \ilink{Job}{JobDef} execution.
+ \item Scheduling of multiple Jobs at the same time.
+ \item You may run one Job at a time or multiple simultaneous Jobs.
+ \item Job sequencing using priorities.
+ \item \ilink{Console}{UADef} interface to the Director allowing complete
+ control. A shell, GNOME GUI and wxWidgets GUI versions of the Console program
+ are available. Note, the GNOME GUI program currently offers very few
+ additional features over the shell program.
+ \end{itemize}
+
+\item Security
+ \begin{itemize}
+ \item Verification of files previously cataloged, permitting a Tripwire like
+ capability (system break-in detection).
+ \item CRAM-MD5 password authentication between each component (daemon).
+ \item Configurable
+ \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component.
+ \item Computation of MD5 or SHA1 signatures of the file data if requested.
+ \end{itemize}
+
+
+\item Restore Features
+ \begin{itemize}
+ \item Restore of one or more files selected interactively either for the
+ current backup or a backup prior to a specified time and date.
+ \item Restore of a complete system starting from bare metal. This is mostly
+ automated for Linux systems and partially automated for Solaris. See
+ \ilink{Disaster Recovery Using Bacula}{_ChapterRescue}. This is also
+ reported to work on Win2K/XP systems.
+ \item Listing and Restoration of files using stand-alone {\bf bls} and {\bf
+ bextract} tool programs. Among other things, this permits extraction of files
+ when Bacula and/or the catalog are not available. Note, the recommended way
+ to restore files is using the restore command in the Console. These programs
+ are designed for use as a last resort.
+ \item Ability to recreate the catalog database by scanning backup Volumes
+ using the {\bf bscan} program.
+ \end{itemize}
+
+\item SQL Catalog
+ \begin{itemize}
+ \item Catalog database facility for remembering Volumes, Pools, Jobs, and
+ Files backed up.
+ \item Support for SQLite, PostgreSQL, and MySQL Catalog databases.
+ \item User extensible queries to the SQLite, PostgreSQL and MySQL databases.
+ \end{itemize}
+
+\item Advanced Volume and Pool Management
+ \begin{itemize}
+ \item Labeled Volumes, preventing accidental overwriting (at least by
+ Bacula).
+ \item Any number of Jobs and Clients can be backed up to a single Volume.
+ That is, you can backup and restore Linux, Unix, Sun, and Windows machines to
+ the same Volume.
+ \item Multi-volume saves. When a Volume is full, {\bf Bacula} automatically
+ requests the next Volume and continues the backup.
+ \item
+ \ilink{Pool and Volume}{PoolResource} library management
+ providing Volume flexibility (e.g. monthly, weekly, daily Volume sets, Volume
+ sets segregated by Client, ...).
+ \item Machine independent Volume data format. Linux, Solaris, and Windows
+ clients can all be backed up to the same Volume if desired.
+ \item A flexible
+ \ilink{ message}{MessageResource} handler including routing
+ of messages from any daemon back to the Director and automatic email
+ reporting.
+ \item Data spooling to disk during backup with subsequent write to tape from
+ the spooled disk files. This prevents tape "shoe shine" during
+ Incremental/Differential backups.
+ \end{itemize}
+
+\item Advanced Support for most Storage Devices
+ \begin{itemize}
+ \item Autochanger support using a simple shell interface that can interface
+ to virtually any autoloader program. A script for {\bf mtx} is provided.
+ \item Support for autochanger barcodes -- automatic tape labeling from
+ barcodes.
+ \item Automatic support for multiple autochanger magazines either using
+ barcodes or by reading the tapes.
+ \item Support for multiple drive autochangers.
+ \item Raw device backup/restore. Restore must be to the same device.
+ \item All Volume blocks (approx 64K bytes) contain a data checksum.
+ \end{itemize}
+
+\item Multi-Operating System Support
+ \begin{itemize}
+ \item Programmed to handle arbitrarily long filenames and messages.
+ \item GZIP compression on a file by file basis done by the Client program if
+ requested before network transit.
+ \item Saves and restores POSIX ACLs on most OSes if enabled.
+ \item Access control lists for Consoles that permit restricting user access
+ to only their data.
+ \item Support for save/restore of files larger than 2GB.
+ \item Support for 64 bit machines, e.g. amd64.
+ \item Ability to encrypt communications between daemons using stunnel.
+ \item Support ANSI and IBM tape labels.
+ \item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
+ version 1.37.28 and greater.
+ \item Consistent backup of open files on Win32 systems (WinXP, Win2003),
+ but not Win2000, using Volume Shadow Copy (VSS).
+ \end{itemize}
+
+\item Miscellaneous
+ \begin{itemize}
+ \item Multi-threaded implementation.
+ \item A comprehensive and extensible
+ \ilink{configuration file}{_ChapterStart40} for each daemon.
+ \end{itemize}
\end{itemize}
\subsection*{Advantages of Bacula Over Other Backup Programs}
comprehensive shell administrative interface, which allows the
administrator to use tools such as ssh to administrate any part of
Bacula from anywhere (even from home).
-
\item Bacula has a Rescue CD for Linux systems with the following features:
\begin{itemize}
\item You build it on your own system from scratch with one simple command:
not supported. They will be backed up, but they cannot be restored. By
using the {\bf Portable=yes} directive in your FileSet, files with
long names can be restored to Unix and Linux systems.
-
Long filenames for Win32 will be implemented in a later version.
\item If you have over 4 billion file entries stored in your database, the
database FileId is likely to overflow. This is a monster database, but still
to 64 bits and this problem will go away. In the mean time, a good workaround
is to use multiple databases.
\item Files deleted after a Full save will be included in a restoration.
+\item Bacula's Differential and Incremental backups are based on
+ time stamps. Consequently, if you move files into an existing directory or
+ move a whole directory into the backup fileset after a Full backup, those
+ files will probably not be backed up by an Incremental save because they
+ will have old dates. You must explicitly update the date/time stamp on all
+ moved files. Correcting this is a future project.
\item File System Modules (configurable routines for saving/restoring special
files) are not yet implemented.
\item Data encryption of the Volume contents.
Recycle = yes
AutoPrune = yes
Volume Retention = 6d
- Accept Any Volume = yes
Maximum Volume Jobs = 2
}
Pool {
Recycle = yes
AutoPrune = yes
Volume Retention = 6d
- Accept Any Volume = yes
Maximum Volume Jobs = 2
}
Pool {
Recycle = yes
AutoPrune = yes
Volume Retention = 6d
- Accept Any Volume = yes
Maximum Volume Jobs = 2
}
Pool {
Recycle = yes
AutoPrune = yes
Volume Retention = 6d
- Accept Any Volume = yes
Maximum Volume Jobs = 2
}
Pool {
Recycle = yes
AutoPrune = yes
Volume Retention = 12d
- Accept Any Volume = yes
Maximum Volume Jobs = 2
}
# EOF
\footnotesize
\begin{verbatim}
FileSet: name=Full Set
- Inc: /home/kern/bacula/bacula-1.30
- Exc: /proc
- Exc: /tmp
- Exc: /.journal
- Exc: /.fsck
+ O M
+ N
+ I /home/kern/bacula/regress/build
+ N
+ E /proc
+ E /tmp
+ E /.journal
+ E /.fsck
+ N
FileSet: name=Catalog
- Inc: /home/kern/bacula/testbin/working/bacula.sql
+ O M
+ N
+ I /home/kern/bacula/regress/working/bacula.sql
+ N
\end{verbatim}
\normalsize
configuration. For testing purposes, we have chosen a directory of moderate
size (about 40 Megabytes) and complexity without being too big. The FileSet
{\bf Catalog} is used for backing up Bacula's catalog and is not of interest
-to us for the moment. The {\bf Inc:} entries are the files or directories that
-will be included in the backup and the {\bf Exc:} are those that will be
-excluded. You can change what is backed up by editing {\bf bacula-dir.conf}
+to us for the moment. The {\bf I} entries are the files or directories that
+will be included in the backup and the {\bf E} are those that will be
+excluded, and the {\bf O} entries are the options specified for
+the FileSet. You can change what is backed up by editing {\bf bacula-dir.conf}
and changing the {\bf File =} line in the {\bf FileSet} resource.
Now is the time to run your first backup job. We are going to backup your
-1.39.5 (14 February 2006)
+1.39.5 (20 February 2006)
projects / bacula / docs / commitdiff