\item [Incremental]
\index[fd]{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:
+ Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde valide du FileSet
+ sp\'ecifi\'e. Si le Director ne peut trouver une sauvegarde Full ant\'erieure,
+ le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le Director
+ recherche une Full valide dans le catalogue, il recherche un job avec
+ les caract\'eristiques suivantes :
\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}
+\item le m\^eme nom de job ;
+\item le m\^eme nom de client ;
+\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle
+ que l'ajout ou la suppression de fichiers dans les sections Include ou
+ Exclude constitue un changement de FileSet).
+\item le niveau requis (Full, Differential ou Incremental)
+\item le job s'est termin\'e normalement, c'est \`a dire un qu'il ne s'est pas termin\'e
+ en \'echec, et n'a pas \'et\'e effac\'e.
+\end{itemize}
-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 {\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 a Incremental backup is quite a time consuming
-process and not currently implemented in Bacula.
+Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director
+augmentera la sauvegarde incr\'ementale en une sauvegarde Full. Dans le cas
+contraire, la sauvegarde incr\'ementale sera effectu\'ee normalement.
+
+Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une
+incr\'ementale par comparaison de l'heure de d\'emarrage du Job pr\'ec\'edent
+(Full, Diff\'erentiel ou Incr\'emental) avec les dates de derni\`ere modification
+de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier
+ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier
+sera sauvegard\'e.
+
+Veuillez noter que certains logiciels anti-virus peuvent modifier la date
+st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie
+la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il
+provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder
+les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le
+cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant
+l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez
+leurs manuels.
+
+Lorsque Bacula effectue une sauvegarde incr\'ementale, tous les fichiers modifi\'es
+pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis
+la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez
+une restauration \`a partir de sauvegardes incr\'ementales (et de la Full associ\'ee),
+les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers
+n'apparaîtront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde
+Full. Le processus pour supprimer ces fichiers du catalogue lors d'une
+incr\'ementale ralentirait fortement les sauvegardes incr\'ementales. Il n'est
+actuellement pas impl\'ement\'e dans Bacula.
\item [Differential]
\index[fd]{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:
+ Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde Full valide du FileSet
+ sp\'ecifi\'e. Si le Director ne peut trouver une sauvegarde Full ant\'erieure,
+ le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le Director
+ recherche une Full valide dans le catalogue, il recherche un job avec
+ les caract\'eristiques suivantes :
\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}
+\item le m\^eme nom de job ;
+\item le m\^eme nom de client ;
+\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle
+ que l'ajout ou la suppression de fichiers dans les sections Include ou
+ Exclude constitue un changement de FileSet).
+\item le Job \'etait une sauvegarde FULL
+\item le Job s'est termin\'e normalement, c'est \`a dire qu'il ne s'est pas termin\'e
+ en \'echec, et n'a pas \'et\'e effac\'e.
+\end{itemize}
+
+Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director
+augmentera la sauvegarde diff\'erentielle en une sauvegarde Full. Dans le cas
+contraire, la sauvegarde diff\'erentielle sera effectu\'ee normalement.
+
+Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une
+diff\'erentielle par comparaison de l'heure de d\'emarrage de la derni\`ere
+sauvegarde Full avec les dates de derni\`ere modification
+de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier
+ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier
+sera sauvegard\'e. La date de d\'emarrage utilis\'ee est affich\'e apr\`es le {\bf Since}
+du rapport de Job. Dans de rares cas, certains fichiers sont sauvegard\'es deux fois
+\`a cause de l'utilisation de la date de d\'emarrage de la sauvegarde pr\'ec\'edente,
+mais ceci assure qu'aucun changement n'est perdu. Comme pour les incr\'ementales,
+vous devriez vous assurer que les horloges de votre serveur Bacula et de vos clients
+sont synchronis\'ees, ou aussi proches que possible, pour \'eviter le risque d'omission
+d'un fichier. Notez qu'\`a partir de la version 1.33, Bacula effectue automatiquement
+ces ajustements de sorte que les horloges utilis\'ees par Bacula soient synchrones.
+
+Veuillez noter que certains logiciels anti-virus peuvent modifier la date
+st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie
+la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il
+provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder
+les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le
+cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant
+l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez
+leurs manuels.
+
+Lorsque Bacula effectue une sauvegarde diff\'erentielle, tous les fichiers modifi\'es
+pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis
+la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez
+une restauration \`a partir de sauvegardes diff\'erentielles (et de la Full associ\'ee),
+les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers
+n'apparaîtront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde
+Full. Le processus pour supprimer ces fichiers du catalogue lors d'une
+incr\'ementale ralentirait fortement les sauvegardes diff\'erentielles. Il n'est
+actuellement pas impl\'ement\'e dans Bacula.
-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 {\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 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.
\end{description}
-For a {\bf Restore} Job, no level need be specified.
+Pour un Job de type {\bf Restore}, aucun niveau ne doit \^etre sp\'ecifi\'e.
-For a {\bf Verify} Job, the Level may be one of the following:
+Pour un Job de type {\bf Verify}, le niveau peut \^etre l'un des suivants :
\begin{description}
\item [InitCatalog]
\index[fd]{InitCatalog }
- does a scan of the specified {\bf FileSet} and stores the file attributes in
-the Catalog database. Since no file data is saved, you might ask why you
-would want to do this. It turns out to be a very simple and easy way to have
-a {\bf Tripwire} like feature using {\bf Bacula}. In other words, it allows
-you to save the state of a set of files defined by the {\bf FileSet} and
-later check to see if those files have been modified or deleted and if any
-new files have been added. This can be used to detect system intrusion.
-Typically you would specify a {\bf FileSet} that contains the set of system
-files that should not change (e.g. /sbin, /boot, /lib, /bin, ...). Normally,
-you run the {\bf InitCatalog} level verify one time when your system is first
-setup, and then once again after each modification (upgrade) to your system.
-Thereafter, when your want to check the state of your system files, you use
-a {\bf Verify} {\bf level = Catalog}. This compares the results of your {\bf
-InitCatalog} with the current state of the files.
+ Examine le {\bf FileSet} sp\'ecifi\'e et stocke les attributs de fichiers dans le
+ catalogue. Vous pouvez vous interroger sur l'int\'er\^et d'un Job qui ne
+ sauvegarde aucun fichier. La r\'eponse est de pouvoir utiliser Bacula comme
+ vous utiliseriez Tripwire, en d'autres termes, ce type de Jobs vous permet
+ de sauvegarder l'\'etat d'un ensemble de fichiers d\'efini par un {\bf FileSet}
+ afin de pouvoir ult\'erieurement contr\^oler si rien n'a \'et\'e modifi\'e, supprim\'e ou
+ ajout\'e. Ceci peut \^etre utilis\'e pour d\'etecter une intrusion. Typiquement,
+ vous sp\'ecifiez un {\bf FileSet} qui contient l'ensemble des fichiers qui ne
+ devraient pas changer (par exemple /sbin, /boot, /lib, /bin, ...). Ensuite,
+ vous ex\'ecutez le Job verify de niveau {\bf InitCatalog} apr\`es l'installation
+ de votre syst\`eme, puis apr\`es chaque modification (mise \`a jour). Ensuite,
+ lorsque vous souhaitez contr\^oler l'\'etat de votre syst\`eme de fichiers,
+ vous utilisez un Job {\bf Verify}, {\bf level = Catalog} afin de comparer
+ le r\'esultat de votre {\bf InitCatalog} avec l'\'etat actuel de votre syst\`eme
+ de fichiers.
\item [Catalog]
\index[fd]{Catalog }
- Compares the current state of the files against the state previously saved
-during an {\bf InitCatalog}. Any discrepancies are reported. The items
-reported are determined by the {\bf verify} options specified on the {\bf
-Include} directive in the specified {\bf FileSet} (see the {\bf FileSet}
-resource below for more details). Typically this command will be run once a
-day (or night) to check for any changes to your system files.
-
-Please note! If you run two Verify Catalog jobs on the same client at the
-same time, the results will certainly be incorrect. This is because Verify
-Catalog modifies the Catalog database while running in order to track new
-files.
+ Compare l'\'etat actuel des fichiers et l'\'etat pr\'ec\'edemment sauvegard\'e
+ lors d'un {\bf InitCatalog}. Toutes les anomalies sont rapport\'ees.
+ Les objets du rapport sont d\'etermin\'es par les options {\bf verify}
+ sp\'ecifi\'ees dans la directive {\bf Include} du {\bf FileSet} sp\'ecifi\'e
+ (voyez la ressource {\bf FileSet} ci-dessous pour plus de d\'etails).
+ Typiquement, cette commande sera ex\'ecut\'ee quotidiennement pour
+ contr\^oler toute modification de votre syst\`eme de fichier.
+
+Attention ! Si vous ex\'ecutez deux jobs Verify Catalog simultan\'ement sur le m\^eme client,
+les r\'esultats seront probablement erronn\'es. En effet, Verify Catalog modifie
+le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers.
\item [VolumeToCatalog]
\index[fd]{VolumeToCatalog }
- This level causes Bacula to read the file attribute data written to the
-Volume from the last Job. The file attribute data are compared to the values
-saved in the Catalog database and any differences are reported. This is
-similar to the {\bf Catalog} level except that instead of comparing the disk
-file attributes to the catalog database, the attribute data written to the
-Volume is read and compared to the catalog database. Although the attribute
-data including the signatures (MD5 or SHA1) are compared the actual file data
-is not compared (it is not in the catalog).
-
-Please note! If you run two Verify VolumeToCatalog jobs on the same client at
-the same time, the results will certainly be incorrect. This is because the
-Verify VolumeToCatalog modifies the Catalog database while running.
+ Ce niveau permet de lire les attributs de fichiers \'ecrits sur le Volume
+ lors du dernier Job. Les attributs de fichiers sont compar\'es aux valeurs
+ sauvegard\'ees dans le catalogue et toute diff\'erence est rapport\'ee. Ceci
+ est similaire au niveau {\bf Catalog}, sauf que ce sont les
+ attributs des fichiers du volume plut\^ot que ceux des fichiers du disque
+ qui sont compar\'es aux attributs sauvegard\'es dans le catalogue. Bien que
+ les attributs et signatures (MD5 ou SHA1) soient compar\'es, les donn\'ees
+ r\'eelles ne le sont pas (elles ne figurent pas dans le catalogue).
+
+Attention ! Si vous ex\'ecutez deux jobs Verify VolumeToCatalog simultan\'ement sur le m\^eme client,
+les r\'esultats seront probablement erronn\'es. En effet, Verify VolumeToCatalog modifie
+le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers.
\item [DiskToCatalog]
\index[fd]{DiskToCatalog }
- This level causes Bacula to read the files as they currently are on disk, and
-to compare the current file attributes with the attributes saved in the
-catalog from the last backup for the job specified on the {\bf VerifyJob}
-directive. This level differs from the {\bf Catalog} level described above by
-the fact that it compare not against a previous Verify job but against a
-previous backup. When you run this level, you must supply the verify options
-on your Include statements. Those options determine what attribute fields are
-compared.
-
-This command can be very useful if you have disk problems because it will
-compare the current state of your disk against the last successful backup,
-which may be several jobs.
-
-Note, the current implementation (1.32c) does not identify files that have
-been deleted.
+ Ce niveau permet de lire les fichiers tels qu'ils sont actuellement sur le
+ disque et de comparer leurs attributs actuels avec ceux stock\'es dans le
+ catalogue lors de la derni\`ere sauvegarde pour le Job sp\'ecifi\'e par la
+ directive {\bf VerifyJob}. Ce niveau diff\`ere du niveau {\bf Catalog}
+ d\'ecrit plus haut en ce qu'il ne se r\'ef\`ere pas \`a un Job Verify ant\'erieur,
+ mais \`a la derni\`ere sauvegarde. Lorsque vous utilisez ce niveau , vous devez
+ renseigner les option Verify de la section Include. Ces options d\'eterminent
+ quels attributs seront compar\'es.
+
+Cette commande peut se r\'ev\'eler tr\`es utile si vous avez des probl\`emes de disque
+car elle comparera l'\'etat actuel de votre disque avec la derni\`ere sauvegarde
+valide, qui peut remonter \`a plusieurs jobs.
+
+Notez que l'impl\'ementation actuelle (1.32c) n'identifie pas les fichiers qui
+ont \'et\'e supprim\'es.
\end{description}
\item {\bf Verify Job = \lt{}Job-Resource-Name\gt{}}
\index[fd]{Verify Job }
- If you run a verify job without this directive, the last job run will be
-compared with the catalog, which means that you must immediately follow a
-backup by a verify command. If you specify a {\bf Verify Job} Bacula will
-find the last job with that name that ran. This permits you to run all your
-backups, then run Verify jobs on those that you wish to be verified (most
-often a {\bf VolumeToCatalog}) so that the tape just written is re-read.
-
+ Si vous ex\'ecutez un job verify sans cette directive, le dernier job
+ ex\'ecut\'e sera compar\'e avec le catalogue, ce qui signifie que votre commande
+ verify doit succ\'eder imm\'ediatement \`a une sauvegarde. Si vous sp\'ecifiez
+ un {\bf Verify Job}, Bacula trouvera le dernier job ex\'ecut\'e avec ce nom.
+ Ceci vous permet d'ex\'ecuter toutes vos sauvegardes, puis d'ex\'ecuter les jobs
+ Verify sur les sauvegardes de votre choix (le plus souvent, un {\bf VolumeToCatalog}
+ de sorte que la cartouche qui vient juste d'\^etre \'ecrite est relue).
+
\item {\bf JobDefs = \lt{}JobDefs-Resource-Name\gt{}}
\index[fd]{JobDefs }
If a JobDefs-Resource-Name is specified, all the values contained in the
projects / bacula / docs / commitdiff