The File daemon (Client) decides which files to backup for a
differential backup by comparing the start time of the prior Full backup
Job against the time each file was last ``modified'' (st_mtime) and the
time its attributes were last ``changed''(st_ctime). If the file was
modified or its attributs were changed on or after this start time, it
will then be backed up. The start time used is displayed after the Since
on the Job report. In rare cases, using the start time of the prior
backup may cause some files to be backed up twice, but it ensures that
no change is missed. As with the Incremental option, you shouldensure
that the clocks on your server and client are synchronized or as close
as possible to avoid the possibility of a file being skipped. Note, on
versions 1.33 or greater Bacula automatically makes the necessary
adjstments to the time between the server and the client so that the
times Bacula uses are synchronized.
When Bacula does an Differential backup, all modified files that are
still on the system are backed up. However, any file that has been
deleted since the last Full backup remains in the Bacula catalog, which
means that if between a Full save and the time you do a restore, some
files are deleted, those deleted files will also be restored. The
deleted files will no longer appear in the catalog after doing another
Full save. However, to remove deleted files from the catalog during a
Differential backup is quite a time consuming process and not currently
implemented in Bacula.
--------------------------------------------------------------------
How about we replace this entire section with something like this:
--------------------------------------------------------------------
For a Backup Job, the Level may be one of the following:
Full
is all files in the FileSet whether or not they have changed.
Differential
is all files in the Fileset that have been modified or changed
since the last successful Full backup of the same Job
Incremental
is all files in the Fileset that have been modified or changed
since the last successful Full, Differential or Incremental
backup of the same Job
These may not be configured as separate Jobs; they must all be the same
Job definition run at different levels. This can be accomplished either
by modifying the job options when running it manually in the Console, or
by specifying different Job levels in the Job's Schedule.
When the Director looks for a ``suitable'' reference backup record in
the catalog database to make an Incremental or Differential backup
against, it looks for a previous reference Job which MUST HAVE ALL of
the following:
The same Job name;
The same Client;
The same version of the same Fileset;
The required reference Job level as above (Full for Differentials,
any level for Incrementals)
Completed successfully (i.e, did not fail and was not cancelled)
If any of these conditions cannot be met, the Director will be
unable to locate a matching job to base the Differential or Incremental
on, and the backup job will be automatically promoted from Incremental
or Differential to a Full backup. If Bacula is making a Full backup
when you expected a Differential or Incremental, check that you are
using the same Client, the same Job definition record with the same Job
name, and the same Fileset as the most recent Full backup that it should
be based on.
The one exception to the above is that if you desire to be able to
make changes to the Fileset without triggering a new Full backup, you
may use the "Ignore Fileset Changes" option in your Fileset definition
(see Filesets). This WILL NOT allow you to base an Incremental or
Differential off a Full backup against a different Fileset. It will
merely allow you to make changes to the same Fileset in order to tune or
update it.
Note that adding "Ignore Fileset Changes" to a Fileset definition is
itself considered a change, and will trigger a Full backup. Once the
Fileset has been stored WITH the Ignore Fileset Changes option, then
SUBSEQUENT changes will be ignored when deciding whether to upgrade the
Job level.
The File daemon (Client) decides which files to backup for an
Incremental backup by comparing start time of the prior Job (Full,
Differential, or Incremental) against the time each file was last
``modified'' (st_mtime) and the time its attributes were last
``changed'' (st_ctime). If the file was modified or its attributes
changed on or after this start time, it will then be backed up.
Please note that some virus scanning software may change st_ctime
while doing the scan. For exaple, if the the virus scanning program
attempts to reset the access time (st_atime), which Bacula does not use,
it will cause st_ctime to change and hence Bacula will backup the file
during an Incremental or Differential backup. In the case of Sophos
virus scanning, you can prevent it from resetting the access time
(st_atime) and hence changing st_ctime by using the --no-reset-atime
option. For other software, please see their manual.
When Bacula does an Incremental or Differential backup, all modified
files that are still on the system are backed up. However, any file that
has been deleted since the previous backup remains in the Bacula
catalog, which means that if between a Full save and the time you do a
restore, some files are deleted, those deleted files will also be
restored. The deleted files will no longer appear in the catalog after
doing another Full save. However, to remove deleted files from the
catalog during a Incremental or Differential backup is quite a time
consuming process and not currently implemented in Bacula. In addition,
Bacula has no way of knowing whether you INTENDED to delete the file(s);
therefore it plays safe by leaving them in the Catalog, allowing you to
choose whether to restore them or not.
-----------------------------------------------------------------------
This should make the dependency clearer, and also eliminates some of the
repetition in the existing text.
Thoughts, feeling, flames? :)
