git.sur5r.net Git - bacula/docs/blob - docs/manual/disk.tex

   1 %%
   2 %%
   3
   4 \chapter{Basic Volume Management}
   5 \label{_ChapterStart39}
   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}{_ChapterStart60} 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}{_ChapterStart18} 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 pool
 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}{_ChapterStart50} 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 }
 229 \index[general]{Restricting the Number of Volumes and Recycling }
 230 Recycling}
 231
 232 Automatic labeling discussed above brings up the problem of Volume management.
 233 With the above scheme, a new Volume will be created every day. If you have not
 234 specified Retention periods, your Catalog will continue to fill keeping track
 235 of all the files Bacula has backed up, and this procedure will create one new
 236 archive file (Volume) every day.
 237
 238 The tools Bacula gives you to help automatically manage these problems are the
 239 following:
 240
 241 \begin{enumerate}
 242 \item Catalog file record retention periods, the
 243    \ilink{File Retention = ttt}{FileRetention}  record in the Client
 244    resource.
 245 \item Catalog job record retention periods, the
 246    \ilink{Job Retention = ttt}{JobRetention}  record in the Client
 247    resource.
 248 \item The
 249    \ilink{ AutoPrune = yes}{AutoPrune} record in the Client resource
 250    to permit  application of the above two retention periods.
 251 \item The
 252    \ilink{ Volume Retention = ttt}{VolRetention} record in the Pool
 253    resource.
 254 \item The
 255    \ilink{ AutoPrune = yes}{PoolAutoPrune} record in the Pool
 256    resource to permit  application of the Volume retention period.
 257 \item The
 258    \ilink{ Recycle = yes}{PoolRecycle} record in the Pool resource
 259    to permit  automatic recycling of Volumes whose Volume retention period has
 260    expired.
 261 \item The
 262    \ilink{ Recycle Oldest Volume = yes}{RecycleOldest} record in the
 263    Pool resource tells Bacula  to Prune the oldest volume in the Pool, and if all
 264    files  were pruned to recycle this volume and use it.
 265 \item The
 266    \ilink{ Recycle Current Volume = yes}{RecycleCurrent} record in
 267    the Pool resource tells Bacula  to Prune the currently mounted volume in the
 268    Pool, and if all files  were pruned to recycle this volume and use it.
 269 \item The
 270    \ilink{ Purge Oldest Volume = yes}{PurgeOldest} record in the
 271    Pool resource  permits a forced recycling of the oldest Volume when a new one
 272    is  needed.  {\bf N.B. This record ignores retention periods! We highly
 273    recommend  not to use this record, but instead use Recycle Oldest Volume}
 274 \item The
 275    \ilink{ Maximum Volumes = nnn}{MaxVolumes} record in the Pool
 276    resource to limit  the number of Volumes that can be created.
 277 \end{enumerate}
 278
 279 The first three records (File Retention, Job Retention, and AutoPrune)
 280 determine the amount of time that Job and File records will remain in your
 281 Catalog, and they are discussed in detail in the
 282 \ilink{Automatic Volume Recycling}{_ChapterStart22} chapter of
 283 this manual.
 284
 285 Volume Retention, AutoPrune, and Recycle determine how long Bacula will keep
 286 your Volumes before reusing them, and they are also discussed in detail in the
 287 \ilink{Automatic Volume Recycling}{_ChapterStart22} chapter of
 288 this manual.
 289
 290 The Maximum Volumes record can also be used in conjunction with the Volume
 291 Retention period to limit the total number of archive Volumes (files) that
 292 Bacula will create. By setting an appropriate Volume Retention period, a
 293 Volume will be purged just before it is needed and thus Bacula can cycle
 294 through a fixed set of Volumes. Cycling through a fixed set of Volumes can
 295 also be done by setting {\bf Recycle Oldest Volume = yes} or {\bf Recycle
 296 Current Volume = yes}. In this case, when Bacula needs a new Volume, it will
 297 prune the specified volume.
 298
 299 \label{ConcurrentDiskJobs}
 300 \section{Concurrent Disk Jobs}
 301 \index[general]{Concurrent Disk Jobs}
 302 Above, we discussed how you could have a single device named {\bf
 303 FileBackup} that writes to volumes in {\bf /home/bacula/backups}.
 304 You can, in fact, run multiple concurrent jobs using the
 305 Storage definition given with this example, and all the jobs will
 306 simultaneously write into the Volume that is being written.
 307
 308 Now suppose you want to use multiple Pools, which means multiple
 309 Volumes, or suppose you want each client to have its own Volume
 310 and perhaps its own directory such as {\bf /home/bacula/client1}
 311 and {\bf /home/bacula/client2} ... With the single Storage and Device
 312 definition above, neither of these two is possible.  Why?  Because
 313 Bacula disk storage follows the same rules as tape devices. Only
 314 one Volume can be mounted on any Device at any time. If you want
 315 to simultaneously write multiple Volumes, you will need multiple
 316 Device resources in your bacula-sd.conf file, and thus multiple
 317 Storage resources in your bacula-dir.conf.
 318
 319 OK, so now you should understand that you need multiple Device definitions
 320 in the case of different directories or different Pools, but you also
 321 need to know that the catalog data that Bacula keeps contains only
 322 the Media Type and not the specific storage device.  This permits a tape
 323 for example to be re-read on any compatible tape drive.  The compatibility
 324 being determined by the Media Type.  The same applies to disk storage.
 325 Since a volume that is written by a Device in say directory {\bf
 326 /home/bacula/backups}  cannot be read by a Device with an Archive Device
 327 definition of {\bf /home/bacula/client1}, you will not be able to
 328 restore all your files if you give both those devices
 329 {\bf Media Type = File}. During the restore, Bacula will simply choose
 330 the first available device, which may not be the correct one.  If this
 331 is confusing, just remember that the Directory has only the Media Type
 332 and the Volume name.  It does not know the {\bf Archive Device} (or the
 333 full path) that is specified in the Storage daemon.  Thus you must
 334 explicitly tie your Volumes to the correct Device by using the Media Type.
 335
 336 The example shown below shows a case where there are two clients, each
 337 using its own Pool and storing their Volumes in different directories.
 338
 339
 340 \label{Example2}
 341 \section{An Example}
 342 \index[general]{Example }
 343
 344 The following example is not very practical, but can be used to demonstrate
 345 the proof of concept in a relatively short period of time. The example
 346 consists of a two clients that are backed up to a set of 12 archive files
 347 (Volumes) for each client into different directories on the Storage
 348 machine.  Each Volume is used (written) only once, and there are four Full
 349 saves done every hour (so the whole thing cycles around after three hours).
 350
 351 What is key here is that each physical device on the Storage daemon
 352 has a different Media Type. This allows the Director to choose the
 353 correct device for restores ...
 354
 355 The Director's configuration file is as follows:
 356
 357 \footnotesize
 358 \begin{verbatim}
 359 Director {
 360   Name = my-dir
 361   QueryFile = "~/bacula/bin/query.sql"
 362   PidDirectory = "~/bacula/working"
 363   WorkingDirectory = "~/bacula/working"
 364   Password = dir_password
 365 }
 366 Schedule {
 367   Name = "FourPerHour"
 368   Run = Level=Full hourly at 0:05
 369   Run = Level=Full hourly at 0:20
 370   Run = Level=Full hourly at 0:35
 371   Run = Level=Full hourly at 0:50
 372 }
 373 Job {
 374   Name = "RecycleExample"
 375   Type = Backup
 376   Level = Full
 377   Client = Rufus
 378   FileSet= "Example FileSet"
 379   Messages = Standard
 380   Storage = FileStorage
 381   Pool = Recycle
 382   Schedule = FourPerHour
 383 }
 384
 385 Job {
 386   Name = "RecycleExample2"
 387   Type = Backup
 388   Level = Full
 389   Client = Roxie
 390   FileSet= "Example FileSet"
 391   Messages = Standard
 392   Storage = FileStorage1
 393   Pool = Recycle1
 394   Schedule = FourPerHour
 395 }
 396
 397 FileSet {
 398   Name = "Example FileSet"
 399   Include = compression=GZIP signature=SHA1 {
 400     /home/kern/bacula/bin
 401   }
 402 }
 403 Client {
 404   Name = Rufus
 405   Address = rufus
 406   Catalog = BackupDB
 407   Password = client_password
 408 }
 409
 410 Client {
 411   Name = Roxie
 412   Address = roxie
 413   Catalog = BackupDB
 414   Password = client1_password
 415 }
 416
 417 Storage {
 418   Name = FileStorage
 419   Address = rufus
 420   Password = local_storage_password
 421   Device = RecycleDir
 422   Media Type = File
 423 }
 424
 425 Storage {
 426   Name = FileStorage1
 427   Address = rufus
 428   Password = local_storage_password
 429   Device = RecycleDir1
 430   Media Type = File1
 431 }
 432
 433 Catalog {
 434   Name = BackupDB
 435   dbname = bacula; user = bacula; password = ""
 436 }
 437 Messages {
 438   Name = Standard
 439   ...
 440 }
 441 Pool {
 442   Name = Recycle
 443   Use Volume Once = yes
 444   Pool Type = Backup
 445   LabelFormat = "Recycle-"
 446   AutoPrune = yes
 447   VolumeRetention = 2h
 448   Maximum Volumes = 12
 449   Recycle = yes
 450 }
 451
 452 Pool {
 453   Name = Recycle1
 454   Use Volume Once = yes
 455   Pool Type = Backup
 456   LabelFormat = "Recycle1-"
 457   AutoPrune = yes
 458   VolumeRetention = 2h
 459   Maximum Volumes = 12
 460   Recycle = yes
 461 }
 462
 463 \end{verbatim}
 464 \normalsize
 465
 466 and the Storage daemon's configuration file is:
 467
 468 \footnotesize
 469 \begin{verbatim}
 470 Storage {
 471   Name = my-sd
 472   WorkingDirectory = "~/bacula/working"
 473   Pid Directory = "~/bacula/working"
 474   MaximumConcurrentJobs = 10
 475 }
 476 Director {
 477   Name = my-dir
 478   Password = local_storage_password
 479 }
 480 Device {
 481   Name = RecycleDir
 482   Media Type = File
 483   Archive Device = /home/bacula/backups
 484   LabelMedia = yes;
 485   Random Access = Yes;
 486   AutomaticMount = yes;
 487   RemovableMedia = no;
 488   AlwaysOpen = no;
 489 }
 490
 491 Device {
 492   Name = RecycleDir1
 493   Media Type = File1
 494   Archive Device = /home/bacula/backups1
 495   LabelMedia = yes;
 496   Random Access = Yes;
 497   AutomaticMount = yes;
 498   RemovableMedia = no;
 499   AlwaysOpen = no;
 500 }
 501
 502 Messages {
 503   Name = Standard
 504   director = my-dir = all
 505 }
 506 \end{verbatim}
 507 \normalsize
 508
 509 With a little bit of work, you can change the above example into a weekly or
 510 monthly cycle (take care about the amount of archive disk space used).
 511
 512 \label{MultipleDisks}
 513 \section{Backing up to Multiple Disks}
 514 \index[general]{Disks!Backing up to Multiple }
 515 \index[general]{Backing up to Multiple Disks }
 516
 517 Bacula can, of course, use multiple disks, but in general, each disk must be a
 518 separate Device specification in the Storage daemon's conf file, and you must
 519 then select what clients to backup to each disk. You will also want to
 520 give each Device specification a different Media Type so that during
 521 a restore, Bacula will be able to find the appropriate drive.
 522
 523 The situation is a bit more complicated if you want to treat two different
 524 physical disk drives (or partitions) logically as a single drive, which
 525 Bacula does not directly support.  However, it is possible to back up your
 526 data to multiple disks as if they were a single drive by linking the
 527 Volumes from the first disk to the second disk.
 528
 529 For example, assume that you have two disks named {\bf /disk1} and {\bf
 530 /disk2}. If you then create a standard Storage daemon Device resource for
 531 backing up to the first disk, it will look like the following:
 532
 533 \footnotesize
 534 \begin{verbatim}
 535 Device {
 536   Name = client1
 537   Media Type = File
 538   Archive Device = /disk1
 539   LabelMedia = yes;
 540   Random Access = Yes;
 541   AutomaticMount = yes;
 542   RemovableMedia = no;
 543   AlwaysOpen = no;
 544 }
 545 \end{verbatim}
 546 \normalsize
 547
 548 Since there is no way to get the above Device resource to reference both {\bf
 549 /disk1} and {\bf /disk2} we do it by pre-creating Volumes on /disk2 with the
 550 following:
 551
 552 \footnotesize
 553 \begin{verbatim}
 554 ln -s /disk2/Disk2-vol001 /disk1/Disk2-vol001
 555 ln -s /disk2/Disk2-vol002 /disk1/Disk2-vol002
 556 ln -s /disk2/Disk2-vol003 /disk1/Disk2-vol003
 557 ...
 558 \end{verbatim}
 559 \normalsize
 560
 561 At this point, you can label the Volumes as Volume {\bf Disk2-vol001}, {\bf
 562 Disk2-vol002}, ... and Bacula will use them as if they were on /disk1 but
 563 actually write the data to /disk2. The only minor inconvenience with this
 564 method is that you must explicitly name the disks and cannot use automatic
 565 labeling unless you arrange to have the labels exactly match the links you
 566 have created.
 567
 568 An important thing to know is that Bacula treats disks like tape drives
 569 as much as it can. This means that you can only have a single Volume
 570 mounted at one time on a disk as defined in your Device resource in
 571 the Storage daemon's conf file.  You can have multiple concurrent
 572 jobs running that all write to the one Volume that is being used, but
 573 if you want to have multiple concurrent jobs that are writing to
 574 separate disks drives (or partitions), you will need to define
 575 separate Device resources for each one, exactly as you would do for
 576 two different tape drives.  There is one fundamental difference, however.
 577 The Volumes that you create on the two drives cannot be easily exchanged
 578 as they can for a tape drive, because they are physically resident (already
 579 mounted in a sense) on the particular drive.  As a consequence, you will
 580 probably want to give them different Media Types so that Bacula can
 581 distinguish what Device resource to use during a restore.
 582 An example would be the following:
 583
 584 \footnotesize
 585 \begin{verbatim}
 586 Device {
 587   Name = Disk1
 588   Media Type = File1
 589   Archive Device = /disk1
 590   LabelMedia = yes;
 591   Random Access = Yes;
 592   AutomaticMount = yes;
 593   RemovableMedia = no;
 594   AlwaysOpen = no;
 595 }
 596
 597 Device {
 598   Name = Disk2
 599   Media Type = File2
 600   Archive Device = /disk2
 601   LabelMedia = yes;
 602   Random Access = Yes;
 603   AutomaticMount = yes;
 604   RemovableMedia = no;
 605   AlwaysOpen = no;
 606 }
 607 \end{verbatim}
 608 \normalsize
 609
 610 With the above device definitions, you can run two concurrent
 611 jobs each writing at the same time, one to {\bf /disk2} and the
 612 other to {\bf /disk2}.  The fact that you have given them different
 613 Media Types will allow Bacula to quickly choose the correct
 614 Storage resource in the Director when doing a restore.
 615
 616 \label{MultipleClients}
 617 \section{Considerations for Multiple Clients}
 618 \index[general]{Clients!Considerations for Multiple }
 619 \index[general]{Multiple Clients}
 620
 621 If we take the above example and add a second Client, here are a few
 622 considerations:
 623
 624 \begin{itemize}
 625 \item Although the second client can write to the same set of  Volumes, you
 626    will probably want to write to a different  set.
 627 \item You can write to a different set of Volumes by defining  a second Pool,
 628    which has a different name and a different  {\bf LabelFormat}.
 629 \item If you wish the Volumes for the second client to go into  a different
 630    directory (perhaps even on a different filesystem  to spread the load), you
 631    would do so by defining a second  Device resource in the Storage daemon. The
 632 {\bf Name}  must be different, and the {\bf Archive Device} could  be
 633 different. To ensure that Volumes are never mixed from  one pool to another,
 634 you might also define a different  MediaType (e.g. {\bf File1}).
 635 \end{itemize}
 636
 637 In this example, we have two clients, each with a different Pool and a
 638 different number of archive files retained. They also write to different
 639 directories with different Volume labeling.
 640
 641 The Director's configuration file is as follows:
 642
 643 \footnotesize
 644 \begin{verbatim}
 645 Director {
 646   Name = my-dir
 647   QueryFile = "~/bacula/bin/query.sql"
 648   PidDirectory = "~/bacula/working"
 649   WorkingDirectory = "~/bacula/working"
 650   Password = dir_password
 651 }
 652 # Basic weekly schedule
 653 Schedule {
 654   Name = "WeeklySchedule"
 655   Run = Level=Full fri at 1:30
 656   Run = Level=Incremental sat-thu at 1:30
 657 }
 658 FileSet {
 659   Name = "Example FileSet"
 660   Include = compression=GZIP signature=SHA1 {
 661     /home/kern/bacula/bin
 662   }
 663 }
 664 Job {
 665   Name = "Backup-client1"
 666   Type = Backup
 667   Level = Full
 668   Client = client1
 669   FileSet= "Example FileSet"
 670   Messages = Standard
 671   Storage = File1
 672   Pool = client1
 673   Schedule = "WeeklySchedule"
 674 }
 675 Job {
 676   Name = "Backup-client2"
 677   Type = Backup
 678   Level = Full
 679   Client = client2
 680   FileSet= "Example FileSet"
 681   Messages = Standard
 682   Storage = File2
 683   Pool = client2
 684   Schedule = "WeeklySchedule"
 685 }
 686 Client {
 687   Name = client1
 688   Address = client1
 689   Catalog = BackupDB
 690   Password = client1_password
 691   File Retention = 7d
 692 }
 693 Client {
 694   Name = client2
 695   Address = client2
 696   Catalog = BackupDB
 697   Password = client2_password
 698 }
 699 # Two Storage definitions with different Media Types
 700 #  permits different directories
 701 Storage {
 702   Name = File1
 703   Address = rufus
 704   Password = local_storage_password
 705   Device = client1
 706   Media Type = File1
 707 }
 708 Storage {
 709   Name = File2
 710   Address = rufus
 711   Password = local_storage_password
 712   Device = client2
 713   Media Type = File2
 714 }
 715 Catalog {
 716   Name = BackupDB
 717   dbname = bacula; user = bacula; password = ""
 718 }
 719 Messages {
 720   Name = Standard
 721   ...
 722 }
 723 # Two pools permits different cycling periods and Volume names
 724 # Cycle through 15 Volumes (two weeks)
 725 Pool {
 726   Name = client1
 727   Use Volume Once = yes
 728   Pool Type = Backup
 729   LabelFormat = "Client1-"
 730   AutoPrune = yes
 731   VolumeRetention = 13d
 732   Maximum Volumes = 15
 733   Recycle = yes
 734 }
 735 # Cycle through 8 Volumes (1 week)
 736 Pool {
 737   Name = client2
 738   Use Volume Once = yes
 739   Pool Type = Backup
 740   LabelFormat = "Client2-"
 741   AutoPrune = yes
 742   VolumeRetention = 6d
 743   Maximum Volumes = 8
 744   Recycle = yes
 745 }
 746 \end{verbatim}
 747 \normalsize
 748
 749 and the Storage daemon's configuration file is:
 750
 751 \footnotesize
 752 \begin{verbatim}
 753 Storage {
 754   Name = my-sd
 755   WorkingDirectory = "~/bacula/working"
 756   Pid Directory = "~/bacula/working"
 757   MaximumConcurrentJobs = 10
 758 }
 759 Director {
 760   Name = my-dir
 761   Password = local_storage_password
 762 }
 763 # Archive directory for Client1
 764 Device {
 765   Name = client1
 766   Media Type = File1
 767   Archive Device = /home/bacula/client1
 768   LabelMedia = yes;
 769   Random Access = Yes;
 770   AutomaticMount = yes;
 771   RemovableMedia = no;
 772   AlwaysOpen = no;
 773 }
 774 # Archive directory for Client2
 775 Device {
 776   Name = client2
 777   Media Type = File2
 778   Archive Device = /home/bacula/client2
 779   LabelMedia = yes;
 780   Random Access = Yes;
 781   AutomaticMount = yes;
 782   RemovableMedia = no;
 783   AlwaysOpen = no;
 784 }
 785 Messages {
 786   Name = Standard
 787   director = my-dir = all
 788 }
 789 \end{verbatim}
 790 \normalsize