From: Jo Simoens Date: Tue, 4 Oct 2005 14:50:06 +0000 (+0000) Subject: fixed some typos X-Git-Tag: Release-1.38.0~93 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=aaf4499180463dd2dd17a75277007e3eba4d20be;p=bacula%2Fdocs fixed some typos --- diff --git a/docs/manual/dirdconf.tex b/docs/manual/dirdconf.tex index ac0512c4..c96bd84c 100644 --- a/docs/manual/dirdconf.tex +++ b/docs/manual/dirdconf.tex @@ -11,7 +11,7 @@ Of all the configuration files needed to run {\bf Bacula}, the Director's is the most complicated, and the one that you will need to modify the most often as you add clients or modify the FileSets. -For a general discussion of configuration file and resources including the +For a general discussion of configuration files and resources including the data types recognized by {\bf Bacula}. Please see the \ilink{Configuration}{_ChapterStart16} chapter of this manual. @@ -28,16 +28,15 @@ Messages. We present them here in the most logical order for defining them: \begin{itemize} \item \ilink{Director}{DirectorResource4} -- to define the Director's - name and its access password used for authenticating the Console program. + name and its access password used for authenticating the Console program. Only a single Director resource definition may appear in the Director's configuration file. If you have either {\bf /dev/random} or {\bf bc} on your -machine, Bacula will generate a random password during the configuration +machine, Bacula will generate a random password during the configuration process, otherwise it will be left blank. \item \ilink{Job}{JobResource} -- to define the backup/restore Jobs and to tie together the Client, FileSet and Schedule resources to be used -for -each Job. + for each Job. \item \ilink{JobDefs}{JobDefsResource} -- optional resource for providing defaults for Job resources. @@ -99,7 +98,7 @@ to be authorized. The same password must appear in the {\bf Director} resource of the Console configuration file. For added security, the password is never actually passed across the network but rather a challenge response hash code created with the password. This directive is required. If you have -either {\bf /dev/random} {\bf bc} on your machine, Bacula will generate a +either {\bf /dev/random} or {\bf bc} on your machine, Bacula will generate a random password during the configuration process, otherwise it will be left blank and you must manually supply it. @@ -127,7 +126,7 @@ directive is required. \item [Pid Directory = \lt{}Directory\gt{}] \index[dir]{Pid Directory } This directive is mandatory and specifies a directory in which the Director -may put its process Id file files. The process Id file is used to shutdown +may put its process Id file. The process Id file is used to shutdown Bacula and to prevent multiple copies of Bacula from running simultaneously. Standard shell expansion of the {\bf Directory} is done when the configuration file is read so that values such as {\bf \$HOME} will be @@ -302,8 +301,7 @@ Clients, you must define a Job for each one. console program to start a job. If the name contains spaces, it must be specified between quotes. It is generally a good idea to give your job the same name as the Client that it will backup. This permits easy -identification - of jobs. + identification of jobs. When the job actually runs, the unique Job Name will consist of the name you specify here followed by the date and time the job was scheduled for @@ -312,9 +310,9 @@ identification \item [Type = \lt{}job-type\gt{}] \index[dir]{Type } The {\bf Type} directive specifies the Job type, which may be one of the -following: {\bf Backup}, {\bf Restore}, {\bf Verify}, or {\bf Admin}. This -directive is required. Within a particular Job Type, there are also Levels -as discussed in the next item. + following: {\bf Backup}, {\bf Restore}, {\bf Verify}, or {\bf Admin}. This + directive is required. Within a particular Job Type, there are also Levels + as discussed in the next item. \begin{description} @@ -358,7 +356,7 @@ different Job Type (Backup, Restore, ...) has a different set of Levels that can be specified. The Level is normally overridden by a different value that is specified in the {\bf Schedule} resource. This directive is not required, but -must be specified either by a {\bf Level} directive or as a override +must be specified either by a {\bf Level} directive or as an override specified in the {\bf Schedule} resource. For a {\bf Backup} Job, the Level may be one of the following: @@ -399,7 +397,7 @@ 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 example, if the the virus scanning program attempts to +doing the scan. For example, if 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 @@ -424,7 +422,7 @@ 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 +and wish it to be properly backed up, it is generally preferable to copy it, then delete the original. @@ -478,8 +476,8 @@ 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 +time stamps. If you move a directory, and wish 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 @@ -545,7 +543,7 @@ 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 +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