Hello,
If I have understood this thread correct, the text below is mean to replace
the current text in the manual, and everyone agrees it is an improvement.
Is that correct?
There always seem to be complaints about the manual, probably for the reason
that Arno states (it is hard to put oneself in the shoes of a beginning) and
also, due to lack of time to work on it. So it is a real pleasure :-) when
someone takes the time to rewrite the text and sends it to me -- thanks Phil.
On Saturday 01 October 2005 02:50, Phil Stracchino wrote:
> > I hope you don't take Phils's remark personal - after all, at least he
> > thinks about your suggestion ;-)
> >
> > Arno
>
> Oh, it certainly wasn't MEANT personally.
>
> Hrm. Perhaps we could do a better job by rewriting that section
> altogether.
>
>
>
> OK, this is going to be sizeable. Now, we have 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.
>
> 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:
>
> * The same Job name.
> * The same Client name.
> * 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.
> * The Job was a Full, Differential, or Incremental backup.
> * The Job terminated normally (i.e. did not fail or was not
> canceled).
>
> 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 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 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
> Incremental backup is quite a time consuming process and not currently
> implemented in Bacula.
>
> 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:
>
> * The same Job name.
> * The same Client name.
> * 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.
> * The Job was a FULL backup.
> * The Job terminated normally (i.e. did not fail or was not
> canceled).
>
> 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 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? :)
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
