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