This command permits you to disable a Job for automatic scheduling.
The job may have been previously enabled with the Job resource
{\bf Enabled} directive or using the console {\bf enable} command.
- The next time the Director is restarted or the conf file is reloaded,
- the Enable/Disable state will be set to the value in the Job resource
- (default enabled) as defined in the bacula-dir.conf file.
+ The next time the Director is restarted, the Enable/Disable state
+ will be set to the value in the Job resource (default enabled) as
+ defined in the bacula-dir.conf file.
\item [enable job\lt{}job-name\gt{}]
\index[general]{enable}
This command permits you to enable a Job for automatic scheduling.
The job may have been previously disabled with the Job resource
{\bf Enabled} directive or using the console {\bf disable} command.
- The next time the Director is restarted or the conf file is reloaded,
- the Enable/Disable state will be set to the value in the Job resource
- (default enabled) as defined in the bacula-dir.conf file.
+ The next time the Director is restarted, the Enable/Disable state
+ will be set to the value in the Job resource (default enabled) as
+ defined in the bacula-dir.conf file.
\label{estimate}
\item [estimate]
hours may be delayed. Jobs that have already been scheduled to run
(i.e. surpassed their requested start time) will continue with the
old values. New jobs will use the new values. Each time you issue
- a reload command while jobs are running, the prior config values
- will queued until all jobs that were running before issuing
+ a reload command while jobs are running, the old config values
+ will kept until all jobs that were running before issuing
the reload terminate, at which time the old config values will
- be released from memory. The Directory permits keeping up to
- ten prior set of configurations before it will refuse a reload
- command. Once at least one old set of config values has been
- released it will again accept new reload commands.
-
- While it is possible to reload the Director's configuration on the fly,
- even while jobs are executing, this is a complex operation and not
- without side effects. Accordingly, if you have to reload the Director's
- configuration while Bacula is running, it is advisable to restart the
- Director at the next convenient opportunity.
+ be released from memory. As a default a maximum number of
+ 32 reload requests that can be made, which is generally sufficient.
+ In the case that you make a very large number of reload requests,
+ you may use the {\bf Maximum Reload Requests} directive in the
+ Director resource of {\bf bacula-dir.conf} to set a larger maximum
+ to that value you wish.
\label{restore_command}
\item [restore]
\index[general]{Recycling!Automatic Volume }
\index[general]{Automatic Volume Recycling }
-By default, once Bacula starts writing a Volume, it can append to the
+By default, once Bacula starts writing a Volume, it may append to the
volume, but it will not overwrite the existing data thus destroying it.
However when Bacula {\bf recycles} a Volume, the Volume becomes available
for being reused, and Bacula can at some later time overwrite the previous
-contents of that Volume. Thus all previous data will be lost. If the
-Volume is a tape, the tape will be rewritten from the beginning. If the
-Volume is a disk file, the file will be truncated before being rewritten.
-
-You may not want Bacula to automatically recycle (reuse) tapes. This would
-require a large number of tapes though, and in such a case, it is possible
-to manually recycle tapes. For more on manual recycling, see the section
-entitled \ilink{Manually Recycling Volumes}{manualrecycling} below in this
-chapter.
-
-Most people prefer to have a Pool of tapes that are used for daily backups and
-recycled once a week, another Pool of tapes that are used for Full backups
-once a week and recycled monthly, and finally a Pool of tapes that are used
+contents of that Volume. At that point all previous data on that Volume
+will be lost. If the Volume is a tape, the tape will be rewritten from the
+beginning. If the Volume is a disk file, the file will be truncated before
+being rewritten.
+
+You may not want Bacula to automatically recycle (reuse) Volumes. Doing so
+may require a large number of Volumes though. However, it is also possible
+to manually recycle Volumes so that they may be reused. For more on manual
+recycling, see the section entitled \ilink{Manually Recycling
+Volumes}{manualrecycling} below in this chapter.
+
+Most people prefer to have a Pool of Volumes that are used for daily backups and
+recycled once a week, another Pool of Volumes that are used for Full backups
+once a week and recycled monthly, and finally a Pool of Volumes that are used
once a month and recycled after a year or two. With a scheme like this, the
-number of tapes in your pool or pools remains constant.
+number of Volumes in your pool or pools remains constant.
By properly defining your Volume Pools with appropriate Retention periods,
Bacula can manage the recycling (such as defined above) automatically.
purged Volume, you must first ensure that no other Volume in the Pool is
marked {\bf Append}. If necessary, you can manually set a volume to {\bf
Full}. The reason for this is that Bacula wants to preserve the data on
-your old tapes (even though purged from the catalog) as long as absolutely
+your old Volumes (even though purged from the catalog) as long as absolutely
possible before overwriting it. There are also a number of directives such
as
{\bf Volume Use Duration} that will automatically mark a volume as {\bf
\index[general]{Automatic Pruning}
\index[general]{Pruning!Automatic}
-As Bacula writes files to tape, it keeps a list of files, jobs, and volumes
+As Bacula writes files to Volumes, it keeps a list of files, jobs, and volumes
in a database called the catalog. Among other things, the database helps
Bacula to decide which files to back up in an incremental or differential
backup, and helps you locate files on past backups when you want to restore
\item [Volume Retention = \lt{}time-period-specification\gt{}]
\index[console]{Volume Retention}
The Volume Retention record defines the length of time that Bacula will
- guarantee that the Volume is not reused counting from the time the last
- job stored on the Volume terminated, providing that all the File records
- on the Volume have not been pruned. A key point is that this time
- period is not even considered as long at the Volume remains appendable.
- The Volume Retention period count down begins only when the Append
- status has been changed to some othe status (Full, Used, Purged, ...).
+ guarantee that the Volume is not reused (i.e. recycled). As long as
+ a Volume has the status {\bf Append}, it will not be recycled even
+ though the retention period may have expired, until the status
+ is changed to some other status such as Full, Used, Purged, ...
+
+\smallskip
+ The retention period when applied starts at the time of the last
+ write to the Volume. For a Volume to recycled, the volume must not
+ have a status of {\bf Append} and the retention period must have
+ expired. Even in that case, the Volume will not be recycled if
+ any other appendable Volume is available for the Job to complete.
+ As noted above, the Volume status will be marked {\bf Purged} by
+ Bacula prior to it being recycled.
+
Note, when all the File records have been removed that are on the
Volume, the Volume will marked Purged (i.e. it has no more valid
Files stored on it), and the Volume may be recycled even if the Volume
yes}, and a new Volume is needed, but no appendable Volume is available,
Bacula will prune (remove) Job records that are older than the specified
Volume Retention period even if the Job or File retention has not been
- reached.
+ reached. Normally this should not happen since the Volume Retention
+ period should always be set greater than the Job Retention period,
+ which should be greater than the File Retention period.
The Volume Retention period takes precedence over any Job Retention
period you have specified in the Client resource. It should also be
noted, that the Volume Retention period is obtained by reading the
Catalog Database Media record rather than the Pool resource record.
This means that if you change the VolumeRetention in the Pool resource
- record, you must ensure that the corresponding change is made in the
- catalog by using the {\bf update pool} command. Doing so will insure
- that any new Volumes will be created with the changed Volume Retention
- period. Any existing Volumes will have their own copy of the Volume
- Retention period that can only be changed on a Volume by Volume basis
- using the {\bf update volume} command.
+ record (in bacula-dir.conf), you must ensure that the corresponding
+ change is made in the catalog by using the {\bf update pool} command.
+ Doing so will insure that any new Volumes will be created with the
+ changed Volume Retention period. Any existing Volumes will have their
+ own copy of the Volume Retention period that can only be changed on a
+ Volume by Volume basis using the {\bf update volume} command.
When all file catalog entries are removed from the volume, its VolStatus is
set to {\bf Purged}. The files remain physically on the Volume until the
\ilink{Configuration chapter}{Time} of this manual for
additional details of time specification.
-The default is 1 year.
+The default Volume Retention period is 1 year.
% TODO: if that is the format, should it be in quotes? decide on a style
\item [Recycle = \lt{}yes|no\gt{}]
This statement tells Bacula whether or not the particular Volume can be
recycled (i.e. rewritten). If Recycle is set to {\bf no} (the
default), then even if Bacula prunes all the Jobs on the volume and it
- is marked {\bf Purged}, it will not consider the tape for recycling. If
+ is marked {\bf Purged}, it will not consider the volume for recycling. If
Recycle is set to {\bf yes} and all Jobs have been pruned, the volume
status will be set to {\bf Purged} and the volume may then be reused
when another volume is needed. If the volume is reused, it is relabeled
\index[general]{Algorithm!Recycling }
\index[general]{Recycling Algorithm }
-After all Volumes of a Pool have been pruned (as mentioned above, this happens
-when a Job needs a new Volume and no appendable Volumes are available), Bacula
-will look for the oldest Volume that is Purged (all Jobs and Files expired),
-and if the {\bf Recycle} flag is on (Recycle=yes) for that Volume, Bacula will
-relabel it and write new data on it.
+After all Volumes of a Pool have been pruned (as mentioned above, this
+happens when a Job needs a new Volume and no appendable Volumes are
+available), Bacula will look for the oldest Volume that is Purged (all Jobs
+and Files expired), and if the {\bf Recycle} flag is on (Recycle=yes) for
+that Volume, Bacula will relabel it and write new data on it.
As mentioned above, there are two key points for getting a Volume
to be recycled. First, the Volume must no longer be marked Append (there
The above occurs when Bacula has finished writing a Volume or when no Volume
is present in the drive.
-On the other hand, if you have inserted a different Volume after the last job,
-and Bacula recognizes the Volume as valid, it will request authorization from
-the Director to use this Volume. In this case, if you have set {\bf Recycle
-Current Volume = yes} and the Volume is marked as Used or Full, Bacula will
-prune the volume and if all jobs were removed during the pruning (respecting
-the retention periods), the Volume will be recycled and used.
+On the other hand, if you have inserted a different Volume after the last
+job, and Bacula recognizes the Volume as valid, the Storage daemon will
+request authorization from the Director to use this Volume. In this case,
+if you have set {\bf Recycle Current Volume = yes} and the Volume is marked
+as Used or Full, Bacula will prune the volume and if all jobs were removed
+during the pruning (respecting the retention periods), the Volume will be
+recycled and re-used.
The recycling algorithm in this case is:
\begin{itemize}
\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.
+\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.
\end{itemize}
-This permits users to manually change the Volume every day and load tapes in
+This permits users to manually change the Volume every day and use volumes in
an order different from what is in the catalog, and if the volume does not
contain a current copy of your backup data, it will be used.
-A few points from Alan Brown to keep in mind:
+A few points to keep in mind:
\begin{enumerate}
\item If a pool doesn't have maximum volumes defined then Bacula will prefer to
recycling - these will be used in preference to creating new volumes.
\item If the Job, File, and Volume retention periods are different, then
- it's common to see a tape with no files or jobs listed in the database,
+ it's common to see a volume with no files or jobs listed in the database,
but which is still not marked as "purged".
\end{enumerate}
\index[general]{Recycle Status }
Each Volume inherits the Recycle status (yes or no) from the Pool resource
-record when the Media record is created (normally when the Volume is labeled).
-This Recycle status is stored in the Media record of the Catalog. Using
-the Console program, you may subsequently change the Recycle status for each
-Volume. For example in the following output from {\bf list volumes}:
+record when the Media record is created (normally when the Volume is
+labeled). This Recycle status is stored in the Media record of the
+Catalog. Using the Console program, you may subsequently change the
+Recycle status for each Volume. For example in the following output from
+{\bf list volumes}:
\footnotesize
\begin{verbatim}
This example is meant to show you how one could define a fixed set of volumes
that Bacula will rotate through on a regular schedule. There are an infinite
number of such schemes, all of which have various advantages and
-disadvantages.
+disadvantages. Note: these volumes may either be tape volumes or disk
+volumes.
We start with the following assumptions:
\index[general]{Automatic Pruning and Recycling Example }
\index[general]{Example!Automatic Pruning and Recycling }
-Perhaps the best way to understand the various resource records that come into
-play during automatic pruning and recycling is to run a Job that goes through
-the whole cycle. If you add the following resources to your Director's
-configuration file:
+Perhaps the best way to understand the various resource records that come
+into play during automatic pruning and recycling is to run a Job that goes
+through the whole cycle. If you add the following resources to your
+Director's configuration file:
\footnotesize
\begin{verbatim}
Once the Volume is marked Purged, it will be recycled the next time a Volume
is needed.
-If you wish to reuse the tape by giving it a new name, follow the following
+If you wish to reuse the Volume by giving it a new name, follow the following
steps:
\begin{itemize}
\item Use the {\bf purge jobs volume} command in the Console to mark the
Volume as {\bf Purged}. Check by using {\bf list volumes}.
-\item In Bacula version 1.30 or greater, use the Console {\bf relabel}
- command to relabel the Volume.
+\item Use the Console {\bf relabel} command to relabel the Volume.
\end{itemize}
-Please note that the relabel command applies only to tape Volumes.
-
-For Bacula versions prior to 1.30 or to manually relabel the Volume, use the
+To manually relabel the a tape Volume, use the
instructions below:
\begin{itemize}
projects / bacula / docs / commitdiff