Hello,
On 02.10.2005 10:39, Kern Sibbald wrote:
...
After reading all the emails, I'm a bit confused, so I'm not planning to do
anything for several reasons: 1. I have a number of undocumented features to
document that important to work on, and for which I am having problems
finding the time. 2. What is desired in this case is not clear to me as there
seem to be several proposals and counter proposals.
That was mainly my fault, I fear...
Just the same, if some improvement can be made along the lines you have been
discussing, all the better, so if someone can put it all together and supply
me a patch to the development doc, and everyone agrees with it, and it looks
good to me, I'll be more than happy to apply it.
Well, I modified the underlying tex file, and as an attachment you find
the resulting diff. This is my first try in obtaining a cvs diff, and I
didn't try anything sophisticated - apply this patch in directory
docs/manual. And watch what patch reports :-)
Perhas more important - I'd be glad if someone would spell-check this
again, and see if I forgot to escape any special characters for tex.
Thanks,
Arno
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
Index: dirdconf.tex
===================================================================
RCS file: /cvsroot/bacula/docs/manual/dirdconf.tex,v
retrieving revision 1.14
diff -u -r1.14 dirdconf.tex
--- dirdconf.tex 25 Sep 2005 18:44:08 -0000 1.14
+++ dirdconf.tex 2 Oct 2005 13:27:53 -0000
@@ -361,124 +361,98 @@
must be specified either by a {\bf Level} directive or as a override
specified in the {\bf Schedule} resource.
-For a {\bf Backup} Job, the Level may be one of the following:
+For a Backup Job, the Level may be one of the following:
-\begin{description}
-
-\item [Full]
- \index[dir]{Full }
- is all files in the FileSet whether or not they have changed.
-
-\item [Incremental]
- \index[dir]{Incremental }
- is all files that have changed since the last successful backup of the
-specified FileSet. If the Director cannot find a previous Full backup then
-the job will be upgraded into a Full backup. When the Director looks for a
-"suitable" backup record in the catalog database, it looks for a previous
-Job with:
-
-\begin{itemize}
-\item The same Job name.
-\item The same Client name.
-\item The same FileSet (any change to the definition of the FileSet such as
- adding or deleting a file in the Include or Exclude sections constitutes a
- different FileSet.
-\item The Job was a Full, Differential, or Incremental backup.
-\item The Job terminated normally (i.e. did not fail or was not canceled).
- \end{itemize}
+ Full
+ is all files in the FileSet whether or not they have changed.
-If all the above conditions do not hold, the Director will upgrade the
-Incremental to a Full save. Otherwise, the Incremental backup will be
-performed as requested.
-
-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 example, 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 {\bf \verb:--:no-reset-atime} option. For other
-software,
-please see their manual.
-
-When Bacula does an Incremental 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 an Incremental backup is quite a time consuming
-process and not currently implemented in Bacula.
-
-In addition, if you move a directory rather than copy it, the files in it do
not
-have their modification time (st\_mtime) or their attribute change time
-(st\_ctime)
-changed. As a consequence, those files will probably not be backed up by an
-Incremental
-or Differential backup which depend solely on these time stamps. If you move a
-directory,
-and which it to be properly backed up, it is generally preferable to copy it
-then
-delete the original.
-
-\item [Differential]
- \index[dir]{Differential }
- is all files that have changed since the last successful Full backup of the
-specified FileSet. If the Director cannot find a previous Full backup or a
-suitable Full backup, then the Differential job will be upgraded into a Full
-backup. When the Director looks for a "suitable" Full backup record in the
-catalog database, it looks for a previous Job with:
-
-\begin{itemize}
-\item The same Job name.
-\item The same Client name.
-\item The same FileSet (any change to the definition of the FileSet such as
- adding or deleting a file in the Include or Exclude sections constitutes a
- different FileSet.
-\item The Job was a FULL backup.
-\item The Job terminated normally (i.e. did not fail or was not canceled).
-\end{itemize}
-
-If all the above conditions do not hold, the Director will upgrade the
-Differential to a Full save. Otherwise, the Differential backup will be
-performed as requested.
-
-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 attributes
-were changed on or after this start time, it will then be backed up. The
-start time used is displayed after the {\bf 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 should ensure 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 adjustments to the time between the server and the client
-so that the times Bacula uses are synchronized.
-
-When Bacula does a 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.
-
-As noted above, if you move a directory rather than copy it, the
-files in it do not have their modification time (st\_mtime) or
-their attribute change time (st\_ctime) changed. As a
-consequence, those files will probably not be backed up by an
-Incremental or Differential backup which depend solely on these
-time stamps. If you move a directory, and which it to be
+ 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 {\bf 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 {\bf with} the Ignore Fileset Changes option, then
+{\bf 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 {\bf 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.
+
+Please note that in certain cases this way of working doesn't produce the
+expected results: If (under unix / linux) you move a whole directory,
+the directories contents access times are not updated. Thus, when moving
+a directory into a fiilesystem tree that is backed up, bacula might not
+back up files you need to be stored. When moving directories inside the
+backed up filesets, their contents will not be backed up from the new
+locations. You can work around these problems by using the touch command
+on the files in directories affected by such operations, although this
+might break other software.
+If you move a directory, and wish it to be
properly backed up, it is generally preferable to copy it then
delete the original.
