From: Ludovic Strappazon Date: Wed, 17 Aug 2005 14:54:22 +0000 (+0000) Subject: Suite de dirdconf.tex X-Git-Tag: Release-1.38.0~182 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=a3f56250b1054566f42dd760f0d42f6b6c9d7bb2;p=bacula%2Fdocs Suite de dirdconf.tex --- diff --git a/docs/manual-fr/dirdconf.tex b/docs/manual-fr/dirdconf.tex index a5778bb2..7975ac32 100644 --- a/docs/manual-fr/dirdconf.tex +++ b/docs/manual-fr/dirdconf.tex @@ -363,177 +363,193 @@ Pour un job de type {\bf Backup} le niveau doit \^etre l'un des suivants : \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