git.sur5r.net Git - bacula/docs/blob - docs/manuals/en/main/disk.tex

   1 %%
   2 %%
   3
   4 \chapter{Basic Volume Management}
   5 \label{DiskChapter}
   6 \index[general]{Basic Volume Management}
   7 \index[general]{Management!Basic Volume}
   8 \index[general]{Disk Volumes}
   9
  10 This chapter presents most all the features needed to do Volume management.
  11 Most of the concepts apply equally well to both tape and disk Volumes.
  12 However, the chapter was originally written to explain backing up to disk, so
  13 you will see it is slanted in that direction, but all the directives
  14 presented here apply equally well whether your volume is disk or tape.
  15
  16 If you have a lot of hard disk storage or you absolutely must have your
  17 backups run within a small time window, you may want to direct Bacula to
  18 backup to disk Volumes rather than tape Volumes. This chapter is intended to
  19 give you some of the options that are available to you so that you can manage
  20 either disk or tape volumes.
  21
  22 \label{Concepts}
  23 \section{Key Concepts and Resource Records}
  24 \index[general]{Key Concepts and Resource Records }
  25 \index[general]{Records!Key Concepts and Resource }
  26
  27 Getting Bacula to write to disk rather than tape in the simplest case is
  28 rather easy. In the Storage daemon's configuration file, you simply define an
  29 {\bf Archive Device} to be a directory. For example, if you want your disk
  30 backups to go into the directory {\bf /home/bacula/backups}, you could use the
  31 following:
  32
  33 \footnotesize
  34 \begin{verbatim}
  35 Device {
  36   Name = FileBackup
  37   Media Type = File
  38   Archive Device = /home/bacula/backups
  39   Random Access = Yes;
  40   AutomaticMount = yes;
  41   RemovableMedia = no;
  42   AlwaysOpen = no;
  43 }
  44 \end{verbatim}
  45 \normalsize
  46
  47 Assuming you have the appropriate {\bf Storage} resource in your Director's
  48 configuration file that references the above Device resource,
  49
  50 \footnotesize
  51 \begin{verbatim}
  52 Storage {
  53   Name = FileStorage
  54   Address = ...
  55   Password = ...
  56   Device = FileBackup
  57   Media Type = File
  58 }
  59 \end{verbatim}
  60 \normalsize
  61
  62 Bacula will then write the archive to the file {\bf
  63 /home/bacula/backups/\lt{}volume-name\gt{}} where \lt{}volume-name\gt{} is the
  64 volume name of a Volume defined in the Pool. For example, if you have labeled
  65 a Volume named {\bf Vol001}, Bacula will write to the file {\bf
  66 /home/bacula/backups/Vol001}. Although you can later move the archive file to
  67 another directory, you should not rename it or it will become unreadable by
  68 Bacula. This is because each archive has the filename as part of the internal
  69 label, and the internal label must agree with the system filename before
  70 Bacula will use it.
  71
  72 Although this is quite simple, there are a number of problems. The first is
  73 that unless you specify otherwise, Bacula will always write to the same volume
  74 until you run out of disk space. This problem is addressed below.
  75
  76 In addition, if you want to use concurrent jobs that write to several
  77 different volumes at the same time, you will need to understand a number
  78 of other details. An example of such a configuration is given
  79 at the end of this chapter under \ilink{Concurrent Disk
  80 Jobs}{ConcurrentDiskJobs}.
  81
  82 \subsection{Pool Options to Limit the Volume Usage}
  83 \index[general]{Usage!Pool Options to Limit the Volume }
  84 \index[general]{Pool Options to Limit the Volume Usage }
  85
  86 Some of the options you have, all of which are specified in the Pool record,
  87 are:
  88
  89 \begin{itemize}
  90 \item To write each Volume only once (i.e. one Job per Volume or file  in this
  91    case), use:
  92
  93 {\bf UseVolumeOnce = yes}.
  94
  95 \item To write nnn Jobs to each Volume, use:
  96
  97    {\bf Maximum Volume Jobs = nnn}.
  98
  99 \item To limit the maximum size of each Volume, use:
 100
 101    {\bf Maximum Volume Bytes = mmmm}.
 102
 103    Note, if you use disk volumes, with all versions up to and including
 104    1.39.28, you should probably limit the Volume size to some reasonable
 105    value such as say 5GB. This is because during a restore, Bacula is
 106    currently unable to seek to the proper place in a disk volume to restore
 107    a file, which means that it must read all records up to where the
 108    restore begins. If your Volumes are 50GB, reading half or more of the
 109    volume could take quite a bit of time.  Also, if you ever have a partial
 110    hard disk failure, you are more likely to be able to recover more data
 111    if they are in smaller Volumes.
 112
 113 \item To limit the use time (i.e. write the Volume for a maximum of five days),
 114    use:
 115
 116 {\bf Volume Use Duration = ttt}.
 117 \end{itemize}
 118
 119 Note that although you probably would not want to limit the number of bytes on
 120 a tape as you would on a disk Volume, the other options can be very useful in
 121 limiting the time Bacula will use a particular Volume (be it tape or disk).
 122 For example, the above directives can allow you to ensure that you rotate
 123 through a set of daily Volumes if you wish.
 124
 125 As mentioned above, each of those directives is specified in the Pool or
 126 Pools that you use for your Volumes. In the case of {\bf Maximum Volume Job},
 127 {\bf Maximum Volume Bytes}, and {\bf Volume Use Duration}, you can actually
 128 specify the desired value on a Volume by Volume basis. The value specified in
 129 the Pool record becomes the default when labeling new Volumes. Once a Volume
 130 has been created, it gets its own copy of the Pool defaults, and subsequently
 131 changing the Pool will have no effect on existing Volumes. You can either
 132 manually change the Volume values, or refresh them from the Pool defaults using
 133 the {\bf update volume} command in the Console. As an example
 134 of the use of one of the above, suppose your Pool resource contains:
 135
 136 \footnotesize
 137 \begin{verbatim}
 138 Pool {
 139   Name = File
 140   Pool Type = Backup
 141   Volume Use Duration = 23h
 142 }
 143 \end{verbatim}
 144 \normalsize
 145
 146 then if you run a backup once a day (every 24 hours), Bacula will use a new
 147 Volume for each backup, because each Volume it writes can only be used for 23 hours
 148 after the first write. Note, setting the use duration to 23 hours is not a very
 149 good solution for tapes unless you have someone on-site during the weekends,
 150 because Bacula will want a new Volume and no one will be present to mount it,
 151 so no weekend backups will be done until Monday morning.
 152
 153 \label{AutomaticLabeling}
 154 \subsection{Automatic Volume Labeling}
 155 \index[general]{Automatic Volume Labeling }
 156 \index[general]{Labeling!Automatic Volume }
 157
 158 Use of the above records brings up another problem -- that of labeling your
 159 Volumes. For automated disk backup, you can either manually label each of your
 160 Volumes, or you can have Bacula automatically label new Volumes when they are
 161 needed. While, the automatic Volume labeling in version 1.30 and prior is a
 162 bit simplistic, but it does allow for automation, the features added in
 163 version 1.31 permit automatic creation of a wide variety of labels including
 164 information from environment variables and special Bacula Counter variables.
 165 In version 1.37 and later, it is probably much better to use Python scripting
 166 and the NewVolume event since generating Volume labels in a Python script is
 167 much easier than trying to figure out Counter variables. See the
 168 \ilink{Python Scripting}{PythonChapter} chapter of this manual for more
 169 details.
 170
 171 Please note that automatic Volume labeling can also be used with tapes, but
 172 it is not nearly so practical since the tapes must be pre-mounted.  This
 173 requires some user interaction.  Automatic labeling from templates does NOT
 174 work with autochangers since Bacula will not access unknown slots.  There
 175 are several methods of labeling all volumes in an autochanger magazine.
 176 For more information on this, please see the \ilink{
 177 Autochanger}{AutochangersChapter} chapter of this manual.
 178
 179 Automatic Volume labeling is enabled by making a change to both the Pool
 180 resource (Director) and to the Device resource (Storage daemon) shown above.
 181 In the case of the Pool resource, you must provide Bacula with a label format
 182 that it will use to create new names. In the simplest form, the label format
 183 is simply the Volume name, to which Bacula will append a four digit number.
 184 This number starts at 0001 and is incremented for each Volume the catalog
 185 contains. Thus if you modify your Pool resource to be:
 186
 187 \footnotesize
 188 \begin{verbatim}
 189 Pool {
 190   Name = File
 191   Pool Type = Backup
 192   Volume Use Duration = 23h
 193   LabelFormat = "Vol"
 194 }
 195 \end{verbatim}
 196 \normalsize
 197
 198 Bacula will create Volume names Vol0001, Vol0002, and so on when new Volumes
 199 are needed. Much more complex and elaborate labels can be created using
 200 variable expansion defined in the
 201 \ilink{Variable Expansion}{VarsChapter} chapter of this manual.
 202
 203 The second change that is necessary to make automatic labeling work is to give
 204 the Storage daemon permission to automatically label Volumes. Do so by adding
 205 {\bf LabelMedia = yes} to the Device resource as follows:
 206
 207 \footnotesize
 208 \begin{verbatim}
 209 Device {
 210   Name = File
 211   Media Type = File
 212   Archive Device = /home/bacula/backups
 213   Random Access = Yes;
 214   AutomaticMount = yes;
 215   RemovableMedia = no;
 216   AlwaysOpen = no;
 217   LabelMedia = yes
 218 }
 219 \end{verbatim}
 220 \normalsize
 221
 222 You can find more details of the {\bf Label Format} Pool record in
 223 \ilink{Label Format}{Label} description of the Pool resource
 224 records.
 225
 226 \label{Recycling1}
 227 \subsection{Restricting the Number of Volumes and Recycling}
 228 \index[general]{Recycling!Restricting the Number of Volumes and Recycling}
 229 \index[general]{Restricting the Number of Volumes and Recycling}
 230
 231 Automatic labeling discussed above brings up the problem of Volume management.
 232 With the above scheme, a new Volume will be created every day. If you have not
 233 specified Retention periods, your Catalog will continue to fill keeping track
 234 of all the files Bacula has backed up, and this procedure will create one new
 235 archive file (Volume) every day.
 236
 237 The tools Bacula gives you to help automatically manage these problems are the
 238 following:
 239
 240 \begin{enumerate}
 241 \item Catalog file record retention periods, the
 242    \ilink{File Retention = ttt}{FileRetention}  record in the Client
 243    resource.
 244 \item Catalog job record retention periods, the
 245    \ilink{Job Retention = ttt}{JobRetention}  record in the Client
 246    resource.
 247 \item The
 248    \ilink{ AutoPrune = yes}{AutoPrune} record in the Client resource
 249    to permit  application of the above two retention periods.
 250 \item The
 251    \ilink{ Volume Retention = ttt}{VolRetention} record in the Pool
 252    resource.
 253 \item The
 254    \ilink{ AutoPrune = yes}{PoolAutoPrune} record in the Pool
 255    resource to permit  application of the Volume retention period.
 256 \item The
 257    \ilink{ Recycle = yes}{PoolRecycle} record in the Pool resource
 258    to permit  automatic recycling of Volumes whose Volume retention period has
 259    expired.
 260 \item The
 261    \ilink{ Recycle Oldest Volume = yes}{RecycleOldest} record in the
 262    Pool resource tells Bacula  to Prune the oldest volume in the Pool, and if all
 263    files  were pruned to recycle this volume and use it.
 264 \item The
 265    \ilink{ Recycle Current Volume = yes}{RecycleCurrent} record in
 266    the Pool resource tells Bacula  to Prune the currently mounted volume in the
 267    Pool, and if all files  were pruned to recycle this volume and use it.
 268 \item The
 269    \ilink{ Purge Oldest Volume = yes}{PurgeOldest} record in the
 270    Pool resource  permits a forced recycling of the oldest Volume when a new one
 271    is  needed.  {\bf N.B. This record ignores retention periods! We highly
 272    recommend  not to use this record, but instead use Recycle Oldest Volume}
 273 \item The
 274    \ilink{ Maximum Volumes = nnn}{MaxVolumes} record in the Pool
 275    resource to limit  the number of Volumes that can be created.
 276 \end{enumerate}
 277
 278 The first three records (File Retention, Job Retention, and AutoPrune)
 279 determine the amount of time that Job and File records will remain in your
 280 Catalog, and they are discussed in detail in the
 281 \ilink{Automatic Volume Recycling}{RecyclingChapter} chapter of
 282 this manual.
 283
 284 Volume Retention, AutoPrune, and Recycle determine how long Bacula will keep
 285 your Volumes before reusing them, and they are also discussed in detail in the
 286 \ilink{Automatic Volume Recycling}{RecyclingChapter} chapter of
 287 this manual.
 288
 289 The Maximum Volumes record can also be used in conjunction with the Volume
 290 Retention period to limit the total number of archive Volumes (files) that
 291 Bacula will create. By setting an appropriate Volume Retention period, a
 292 Volume will be purged just before it is needed and thus Bacula can cycle
 293 through a fixed set of Volumes. Cycling through a fixed set of Volumes can
 294 also be done by setting {\bf Recycle Oldest Volume = yes} or {\bf Recycle
 295 Current Volume = yes}. In this case, when Bacula needs a new Volume, it will
 296 prune the specified volume.
 297
 298 \label{ConcurrentDiskJobs}
 299 \section{Concurrent Disk Jobs}
 300 \index[general]{Concurrent Disk Jobs}
 301 Above, we discussed how you could have a single device named {\bf
 302 FileBackup} that writes to volumes in {\bf /home/bacula/backups}.
 303 You can, in fact, run multiple concurrent jobs using the
 304 Storage definition given with this example, and all the jobs will
 305 simultaneously write into the Volume that is being written.
 306
 307 Now suppose you want to use multiple Pools, which means multiple
 308 Volumes, or suppose you want each client to have its own Volume
 309 and perhaps its own directory such as {\bf /home/bacula/client1}
 310 and {\bf /home/bacula/client2} ... With the single Storage and Device
 311 definition above, neither of these two is possible.  Why?  Because
 312 Bacula disk storage follows the same rules as tape devices. Only
 313 one Volume can be mounted on any Device at any time. If you want
 314 to simultaneously write multiple Volumes, you will need multiple
 315 Device resources in your bacula-sd.conf file, and thus multiple
 316 Storage resources in your bacula-dir.conf.
 317
 318 OK, so now you should understand that you need multiple Device definitions
 319 in the case of different directories or different Pools, but you also
 320 need to know that the catalog data that Bacula keeps contains only
 321 the Media Type and not the specific storage device.  This permits a tape
 322 for example to be re-read on any compatible tape drive.  The compatibility
 323 being determined by the Media Type.  The same applies to disk storage.
 324 Since a volume that is written by a Device in say directory {\bf
 325 /home/bacula/backups}  cannot be read by a Device with an Archive Device
 326 definition of {\bf /home/bacula/client1}, you will not be able to
 327 restore all your files if you give both those devices
 328 {\bf Media Type = File}. During the restore, Bacula will simply choose
 329 the first available device, which may not be the correct one.  If this
 330 is confusing, just remember that the Directory has only the Media Type
 331 and the Volume name.  It does not know the {\bf Archive Device} (or the
 332 full path) that is specified in the Storage daemon.  Thus you must
 333 explicitly tie your Volumes to the correct Device by using the Media Type.
 334
 335 The example shown below shows a case where there are two clients, each
 336 using its own Pool and storing their Volumes in different directories.
 337
 338
 339 \label{Example2}
 340 \section{An Example}
 341 \index[general]{Example }
 342
 343 The following example is not very practical, but can be used to demonstrate
 344 the proof of concept in a relatively short period of time. The example
 345 consists of a two clients that are backed up to a set of 12 archive files
 346 (Volumes) for each client into different directories on the Storage
 347 machine.  Each Volume is used (written) only once, and there are four Full
 348 saves done every hour (so the whole thing cycles around after three hours).
 349
 350 What is key here is that each physical device on the Storage daemon
 351 has a different Media Type. This allows the Director to choose the
 352 correct device for restores ...
 353
 354 The Director's configuration file is as follows:
 355
 356 \footnotesize
 357 \begin{verbatim}
 358 Director {
 359   Name = my-dir
 360   QueryFile = "~/bacula/bin/query.sql"
 361   PidDirectory = "~/bacula/working"
 362   WorkingDirectory = "~/bacula/working"
 363   Password = dir_password
 364 }
 365 Schedule {
 366   Name = "FourPerHour"
 367   Run = Level=Full hourly at 0:05
 368   Run = Level=Full hourly at 0:20
 369   Run = Level=Full hourly at 0:35
 370   Run = Level=Full hourly at 0:50
 371 }
 372 Job {
 373   Name = "RecycleExample"
 374   Type = Backup
 375   Level = Full
 376   Client = Rufus
 377   FileSet= "Example FileSet"
 378   Messages = Standard
 379   Storage = FileStorage
 380   Pool = Recycle
 381   Schedule = FourPerHour
 382 }
 383
 384 Job {
 385   Name = "RecycleExample2"
 386   Type = Backup
 387   Level = Full
 388   Client = Roxie
 389   FileSet= "Example FileSet"
 390   Messages = Standard
 391   Storage = FileStorage1
 392   Pool = Recycle1
 393   Schedule = FourPerHour
 394 }
 395
 396 FileSet {
 397   Name = "Example FileSet"
 398   Include {
 399         Options {
 400         compression=GZIP
 401         signature=SHA1
 402                 }
 403     File = /home/kern/bacula/bin
 404           }
 405 }
 406
 407 Client {
 408   Name = Rufus
 409   Address = rufus
 410   Catalog = BackupDB
 411   Password = client_password
 412 }
 413
 414 Client {
 415   Name = Roxie
 416   Address = roxie
 417   Catalog = BackupDB
 418   Password = client1_password
 419 }
 420
 421 Storage {
 422   Name = FileStorage
 423   Address = rufus
 424   Password = local_storage_password
 425   Device = RecycleDir
 426   Media Type = File
 427 }
 428
 429 Storage {
 430   Name = FileStorage1
 431   Address = rufus
 432   Password = local_storage_password
 433   Device = RecycleDir1
 434   Media Type = File1
 435 }
 436
 437 Catalog {
 438   Name = BackupDB
 439   dbname = bacula; user = bacula; password = ""
 440 }
 441 Messages {
 442   Name = Standard
 443   ...
 444 }
 445 Pool {
 446   Name = Recycle
 447   Use Volume Once = yes
 448   Pool Type = Backup
 449   LabelFormat = "Recycle-"
 450   AutoPrune = yes
 451   VolumeRetention = 2h
 452   Maximum Volumes = 12
 453   Recycle = yes
 454 }
 455
 456 Pool {
 457   Name = Recycle1
 458   Use Volume Once = yes
 459   Pool Type = Backup
 460   LabelFormat = "Recycle1-"
 461   AutoPrune = yes
 462   VolumeRetention = 2h
 463   Maximum Volumes = 12
 464   Recycle = yes
 465 }
 466
 467 \end{verbatim}
 468 \normalsize
 469
 470 and the Storage daemon's configuration file is:
 471
 472 \footnotesize
 473 \begin{verbatim}
 474 Storage {
 475   Name = my-sd
 476   WorkingDirectory = "~/bacula/working"
 477   Pid Directory = "~/bacula/working"
 478   MaximumConcurrentJobs = 10
 479 }
 480 Director {
 481   Name = my-dir
 482   Password = local_storage_password
 483 }
 484 Device {
 485   Name = RecycleDir
 486   Media Type = File
 487   Archive Device = /home/bacula/backups
 488   LabelMedia = yes;
 489   Random Access = Yes;
 490   AutomaticMount = yes;
 491   RemovableMedia = no;
 492   AlwaysOpen = no;
 493 }
 494
 495 Device {
 496   Name = RecycleDir1
 497   Media Type = File1
 498   Archive Device = /home/bacula/backups1
 499   LabelMedia = yes;
 500   Random Access = Yes;
 501   AutomaticMount = yes;
 502   RemovableMedia = no;
 503   AlwaysOpen = no;
 504 }
 505
 506 Messages {
 507   Name = Standard
 508   director = my-dir = all
 509 }
 510 \end{verbatim}
 511 \normalsize
 512
 513 With a little bit of work, you can change the above example into a weekly or
 514 monthly cycle (take care about the amount of archive disk space used).
 515
 516 \label{MultipleDisks}
 517 \section{Backing up to Multiple Disks}
 518 \index[general]{Disks!Backing up to Multiple }
 519 \index[general]{Backing up to Multiple Disks }
 520
 521 Bacula can, of course, use multiple disks, but in general, each disk must be a
 522 separate Device specification in the Storage daemon's conf file, and you must
 523 then select what clients to backup to each disk. You will also want to
 524 give each Device specification a different Media Type so that during
 525 a restore, Bacula will be able to find the appropriate drive.
 526
 527 The situation is a bit more complicated if you want to treat two different
 528 physical disk drives (or partitions) logically as a single drive, which
 529 Bacula does not directly support.  However, it is possible to back up your
 530 data to multiple disks as if they were a single drive by linking the
 531 Volumes from the first disk to the second disk.
 532
 533 For example, assume that you have two disks named {\bf /disk1} and {\bf
 534 /disk2}. If you then create a standard Storage daemon Device resource for
 535 backing up to the first disk, it will look like the following:
 536
 537 \footnotesize
 538 \begin{verbatim}
 539 Device {
 540   Name = client1
 541   Media Type = File
 542   Archive Device = /disk1
 543   LabelMedia = yes;
 544   Random Access = Yes;
 545   AutomaticMount = yes;
 546   RemovableMedia = no;
 547   AlwaysOpen = no;
 548 }
 549 \end{verbatim}
 550 \normalsize
 551
 552 Since there is no way to get the above Device resource to reference both {\bf
 553 /disk1} and {\bf /disk2} we do it by pre-creating Volumes on /disk2 with the
 554 following:
 555
 556 \footnotesize
 557 \begin{verbatim}
 558 ln -s /disk2/Disk2-vol001 /disk1/Disk2-vol001
 559 ln -s /disk2/Disk2-vol002 /disk1/Disk2-vol002
 560 ln -s /disk2/Disk2-vol003 /disk1/Disk2-vol003
 561 ...
 562 \end{verbatim}
 563 \normalsize
 564
 565 At this point, you can label the Volumes as Volume {\bf Disk2-vol001}, {\bf
 566 Disk2-vol002}, ... and Bacula will use them as if they were on /disk1 but
 567 actually write the data to /disk2. The only minor inconvenience with this
 568 method is that you must explicitly name the disks and cannot use automatic
 569 labeling unless you arrange to have the labels exactly match the links you
 570 have created.
 571
 572 An important thing to know is that Bacula treats disks like tape drives
 573 as much as it can. This means that you can only have a single Volume
 574 mounted at one time on a disk as defined in your Device resource in
 575 the Storage daemon's conf file.  You can have multiple concurrent
 576 jobs running that all write to the one Volume that is being used, but
 577 if you want to have multiple concurrent jobs that are writing to
 578 separate disks drives (or partitions), you will need to define
 579 separate Device resources for each one, exactly as you would do for
 580 two different tape drives.  There is one fundamental difference, however.
 581 The Volumes that you create on the two drives cannot be easily exchanged
 582 as they can for a tape drive, because they are physically resident (already
 583 mounted in a sense) on the particular drive.  As a consequence, you will
 584 probably want to give them different Media Types so that Bacula can
 585 distinguish what Device resource to use during a restore.
 586 An example would be the following:
 587
 588 \footnotesize
 589 \begin{verbatim}
 590 Device {
 591   Name = Disk1
 592   Media Type = File1
 593   Archive Device = /disk1
 594   LabelMedia = yes;
 595   Random Access = Yes;
 596   AutomaticMount = yes;
 597   RemovableMedia = no;
 598   AlwaysOpen = no;
 599 }
 600
 601 Device {
 602   Name = Disk2
 603   Media Type = File2
 604   Archive Device = /disk2
 605   LabelMedia = yes;
 606   Random Access = Yes;
 607   AutomaticMount = yes;
 608   RemovableMedia = no;
 609   AlwaysOpen = no;
 610 }
 611 \end{verbatim}
 612 \normalsize
 613
 614 With the above device definitions, you can run two concurrent
 615 jobs each writing at the same time, one to {\bf /disk1} and the
 616 other to {\bf /disk2}.  The fact that you have given them different
 617 Media Types will allow Bacula to quickly choose the correct
 618 Storage resource in the Director when doing a restore.
 619
 620 \label{MultipleClients}
 621 \section{Considerations for Multiple Clients}
 622 \index[general]{Clients!Considerations for Multiple }
 623 \index[general]{Multiple Clients}
 624
 625 If we take the above example and add a second Client, here are a few
 626 considerations:
 627
 628 \begin{itemize}
 629 \item Although the second client can write to the same set of  Volumes, you
 630    will probably want to write to a different  set.
 631 \item You can write to a different set of Volumes by defining  a second Pool,
 632    which has a different name and a different  {\bf LabelFormat}.
 633 \item If you wish the Volumes for the second client to go into  a different
 634    directory (perhaps even on a different filesystem  to spread the load), you
 635    would do so by defining a second  Device resource in the Storage daemon. The
 636 {\bf Name}  must be different, and the {\bf Archive Device} could  be
 637 different. To ensure that Volumes are never mixed from  one pool to another,
 638 you might also define a different  MediaType (e.g. {\bf File1}).
 639 \end{itemize}
 640
 641 In this example, we have two clients, each with a different Pool and a
 642 different number of archive files retained. They also write to different
 643 directories with different Volume labeling.
 644
 645 The Director's configuration file is as follows:
 646
 647 \footnotesize
 648 \begin{verbatim}
 649 Director {
 650   Name = my-dir
 651   QueryFile = "~/bacula/bin/query.sql"
 652   PidDirectory = "~/bacula/working"
 653   WorkingDirectory = "~/bacula/working"
 654   Password = dir_password
 655 }
 656 # Basic weekly schedule
 657 Schedule {
 658   Name = "WeeklySchedule"
 659   Run = Level=Full fri at 1:30
 660   Run = Level=Incremental sat-thu at 1:30
 661 }
 662 FileSet {
 663   Name = "Example FileSet"
 664   Include {
 665         Options {
 666         compression=GZIP
 667         signature=SHA1
 668                 }
 669     File = /home/kern/bacula/bin
 670           }
 671 }
 672 Job {
 673   Name = "Backup-client1"
 674   Type = Backup
 675   Level = Full
 676   Client = client1
 677   FileSet= "Example FileSet"
 678   Messages = Standard
 679   Storage = File1
 680   Pool = client1
 681   Schedule = "WeeklySchedule"
 682 }
 683 Job {
 684   Name = "Backup-client2"
 685   Type = Backup
 686   Level = Full
 687   Client = client2
 688   FileSet= "Example FileSet"
 689   Messages = Standard
 690   Storage = File2
 691   Pool = client2
 692   Schedule = "WeeklySchedule"
 693 }
 694 Client {
 695   Name = client1
 696   Address = client1
 697   Catalog = BackupDB
 698   Password = client1_password
 699   File Retention = 7d
 700 }
 701 Client {
 702   Name = client2
 703   Address = client2
 704   Catalog = BackupDB
 705   Password = client2_password
 706 }
 707 # Two Storage definitions with different Media Types
 708 #  permits different directories
 709 Storage {
 710   Name = File1
 711   Address = rufus
 712   Password = local_storage_password
 713   Device = client1
 714   Media Type = File1
 715 }
 716 Storage {
 717   Name = File2
 718   Address = rufus
 719   Password = local_storage_password
 720   Device = client2
 721   Media Type = File2
 722 }
 723 Catalog {
 724   Name = BackupDB
 725   dbname = bacula; user = bacula; password = ""
 726 }
 727 Messages {
 728   Name = Standard
 729   ...
 730 }
 731 # Two pools permits different cycling periods and Volume names
 732 # Cycle through 15 Volumes (two weeks)
 733 Pool {
 734   Name = client1
 735   Use Volume Once = yes
 736   Pool Type = Backup
 737   LabelFormat = "Client1-"
 738   AutoPrune = yes
 739   VolumeRetention = 13d
 740   Maximum Volumes = 15
 741   Recycle = yes
 742 }
 743 # Cycle through 8 Volumes (1 week)
 744 Pool {
 745   Name = client2
 746   Use Volume Once = yes
 747   Pool Type = Backup
 748   LabelFormat = "Client2-"
 749   AutoPrune = yes
 750   VolumeRetention = 6d
 751   Maximum Volumes = 8
 752   Recycle = yes
 753 }
 754 \end{verbatim}
 755 \normalsize
 756
 757 and the Storage daemon's configuration file is:
 758
 759 \footnotesize
 760 \begin{verbatim}
 761 Storage {
 762   Name = my-sd
 763   WorkingDirectory = "~/bacula/working"
 764   Pid Directory = "~/bacula/working"
 765   MaximumConcurrentJobs = 10
 766 }
 767 Director {
 768   Name = my-dir
 769   Password = local_storage_password
 770 }
 771 # Archive directory for Client1
 772 Device {
 773   Name = client1
 774   Media Type = File1
 775   Archive Device = /home/bacula/client1
 776   LabelMedia = yes;
 777   Random Access = Yes;
 778   AutomaticMount = yes;
 779   RemovableMedia = no;
 780   AlwaysOpen = no;
 781 }
 782 # Archive directory for Client2
 783 Device {
 784   Name = client2
 785   Media Type = File2
 786   Archive Device = /home/bacula/client2
 787   LabelMedia = yes;
 788   Random Access = Yes;
 789   AutomaticMount = yes;
 790   RemovableMedia = no;
 791   AlwaysOpen = no;
 792 }
 793 Messages {
 794   Name = Standard
 795   director = my-dir = all
 796 }
 797 \end{verbatim}
 798 \normalsize