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