]> git.sur5r.net Git - bacula/docs/commitdiff
ebl Update accurate doc
authorEric Bollengier <eric@eb.homelinux.org>
Wed, 27 Feb 2008 19:46:53 +0000 (19:46 +0000)
committerEric Bollengier <eric@eb.homelinux.org>
Wed, 27 Feb 2008 19:46:53 +0000 (19:46 +0000)
docs/manuals/en/install/dirdconf.tex

index 4d1614b7e64b379c396c151443d3476e4a04f737..f4419f45f822b6fb1cfb2923df1c2c0e2dbeeaf1 100644 (file)
@@ -481,13 +481,11 @@ For a {\bf Backup} Job, the Level may be one of the  following:
 
    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.
+   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.
 
    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
@@ -497,6 +495,11 @@ For a {\bf Backup} Job, the Level may be one of the  following:
    it to be properly backed up, it is generally preferable to copy it, then
    delete the original.
 
+   However, to manage deleted files or directories changes in the
+   catalog during an Incremental backup you can use \texttt{accurate}
+   mode. This is quite memory consuming process. See \ilink{Accurate
+     mode}{accuratemode} for more details.
+
 \item [Differential]
    \index[dir]{Differential}
    When the Level is set to Differential
@@ -558,6 +561,12 @@ For a {\bf Backup} Job, the Level may be one of the  following:
    delete the original. Alternatively, you can move the directory, then
    use the {\bf touch} program to update the timestamps.
 
+%% TODO: merge this with incremental 
+   However, to manage deleted files or directories changes in the
+   catalog during an Differential backup you can use \texttt{accurate}
+   mode. This is quite memory consuming process. See \ilink{Accurate
+     mode}{accuratemode} for more details.
+
    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
@@ -649,6 +658,24 @@ For a {\bf Verify} Job, the Level may be one of the  following:
    have been deleted.
 \end{description}
 
+\item [Accurate = \lt{}yes|no\gt{}]
+\index[dir]{Accurate}
+   In accurate mode, FileDaemon known exactly which files were present
+   after last backup. So it is able to handle deleted or renamed files.
+
+   When restoring a fileset for a specified date (including "most
+   recent"), Bacula is able to give you exactly the files and
+   directories that existed at the time of the last backup prior to
+   that date.
+
+   In this mode, FileDaemon have to keep all files in memory. So you have
+   to check that your memory and swap are sufficent.
+
+   $$ memory = \sum_{i=1}^{n}(strlen(path_i + file_i) + sizeof(CurFile))$$
+
+   For 500.000 files (typical desktop linux system), it will take
+   around 64MB of RAM on your FileDaemon.
+
 \item [Verify Job = \lt{}Job-Resource-Name\gt{}]
    \index[dir]{Verify Job}
    \index[dir]{Directive!Verify Job}