From 5380d366a30a2043ab9390fe49a186a17a8e227e Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Fri, 9 Sep 2005 09:30:19 +0000 Subject: [PATCH] updates --- docs/manual/dirdconf.tex | 35 ++++++++++++++++++++----------- docs/manual/supportedchangers.tex | 1 + 2 files changed, 24 insertions(+), 12 deletions(-) diff --git a/docs/manual/dirdconf.tex b/docs/manual/dirdconf.tex index 17f56f7d..a9c516aa 100644 --- a/docs/manual/dirdconf.tex +++ b/docs/manual/dirdconf.tex @@ -444,7 +444,7 @@ catalog database, it looks for a previous Job with: 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} +\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 @@ -473,17 +473,28 @@ 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 properly backed up, it is generally preferable to copy it -then -delete the original. +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 +properly backed up, it is generally preferable to copy it then +delete the original. + +Every once and a while, someone asks why we need Differential +backups as long as Incremental backups pickup all changed files. +There are possibly many answers to this question, but the one +that is the most important for me is that it effectively combines +all the Incremental and Differential backups since the last Full +backup into a single Differential backup. This has two effects: +1. It gives some redundancy. 2. More importantly, it reduces the +number of Volumes that are needed to do a restore effectively +eliminating the need to read all the volumes on which the +preceding Incremental and Differential backups since the last +Full are done. + + \end{description} For a {\bf Restore} Job, no level needs to be specified. diff --git a/docs/manual/supportedchangers.tex b/docs/manual/supportedchangers.tex index d37219fd..aa645363 100644 --- a/docs/manual/supportedchangers.tex +++ b/docs/manual/supportedchangers.tex @@ -35,6 +35,7 @@ Slot). \hline {z/VM } & {IBM } & {?? } & {IBM Tape Manager } & {-} & {?? } \\ \hline {z/VM } & {IBM } & {?? } & {native tape } & {-} & {?? } \\ \hline {Linux } & {Exabyte } & {VXA2 } & {VXA PacketLoader 1x10 2U } & {10} & {80/160GB } \\ + \hline {- } & {Exabyte } & {LTO } & {Magnum 1x7 LTO Tape Auotloader } & {7} & {200/400GB } \\ \hline {Linux Gentoo 1.4 } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} & {50GB } \\ \hline {Linux } & {HP } & {DDS-4 } & {SureStore DAT-40X6 } & {6 } & {40GB } \\ \hline {Linux } & {HP } & {Ultrium-2/LTO } & {MSL 6000/ 60030/ 5052 } & {28 } & {200/400GB } \\ -- 2.39.5