Basic Volume Management

This chapter presents most all the features needed to do Volume management. Most of the concepts apply equally well to both tape and disk Volumes. However, the chapter was originally written to explain backing up to disk, so you will see it is slanted in that direction, but all the directives presented here apply equally well whether your volume is disk or tape.

If you have a lot of hard disk storage or you absolutely must have your backups run within a small time window, you may want to direct Bacula to backup to disk Volumes rather than tape Volumes. This chapter is intended to give you some of the options that are available to you so that you can manage either disk or tape volumes.

Key Concepts and Resource Records

Getting Bacula to write to disk rather than tape in the simplest case is rather easy. In the Storage daemon’s configuration file, you simply define an Archive Device to be a directory. For example, if you want your disk backups to go into the directory /mnt/bacula/backups, you could use the following:

Device {
    Name = DiskDevice_Dev0
    DriveIndex = 0
    Media Type = DiskStorage-mnt-bacula
    Archive Device = /mnt/bacula/backups
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    AlwaysOpen = no;
}

The above disk device should be part of a disk autochanger:

Autochanger {
    Name = DiskAutochanger
    Device = DiskDevice_Dev0
    ChangerCommand = ""
    ChangerDevice = /dev/null

}

Assuming you have the appropriate Storage resource in your Director’s configuration file that references the above Autochanger resource,

Storage {
     Name = DiskAutochanger
     Address = ...
     Password = ...
     Device = DiskAutochanger
     Media Type = DiskStorage-mnt-bacula
 }

Bacula will then write the archive to the file /mnt/bacula/backups/ where is the volume name of a Volume defined in the Pool. For example, if you have labeled a Volume named Vol-0001, Bacula will write to the file /home/bacula/backups/Vol-0001. You should not rename it or it will become unreadable by Bacula. This is because each archive has the filename as part of the internal label, and the internal label must agree with the system filename before Bacula will use it.

Although this is quite simple, there are a number of problems. The first is that unless you specify otherwise, Bacula will always write to the same volume until you run out of disk space. This problem is addressed below.

In addition, if you want to use concurrent jobs that write to several different volumes at the same time, you will need to understand a number of other details. An example of such a configuration is given at the end of this chapter under Concurrent Disk Jobs.

Pool Options to Limit the Volume Usage

Some of the options you have, all of which are specified in the Pool record, are:

• To write each Volume only once (i.e. one Job per Volume or file in this case), use:

  UseVolumeOnce = yes.

• To write nnn Jobs to each Volume, use:

  Maximum Volume Jobs = nnn.

• To limit the maximum size of each Volume, use:

  Maximum Volume Bytes = mmmm.

  Note, if you use disk volumes and do not specify a Maximum Volume Bytes, Bacula will write to your first Volume until your whole disk fills. This is probably not what you want. We recommend keeping your total number of Volumes created in the Catalog down to less than 5,000 for performance reasons when pruning. For a small site (10-20 clients), you might choose a Maximum Volume Bytes of 5G, for a medium site (20-100 clients) you might choose as size of 50G, and for large sites (greater than 100 clients) 200G.

  The advantage of bigger Volumes is that it improves performance during pruning (smaller number of Volumes to prune). The advantage of smaller Volumes is that you waste less disk space by being able to recycle them more often than big Volumes.

  Large Volumes present little performance penality during restores, because Bacula is able to seek to the start of each Job (and often within a Job).

• To limit the use time (i.e. write the Volume for a maximum of five days), use:

  Volume Use Duration = ttt.

Note that although you probably would not want to limit the number of bytes on a tape as you would on a disk Volume, the other options can be very useful in limiting the time Bacula will use a particular Volume (be it tape or disk). For example, the above directives can allow you to ensure that you rotate through a set of daily Volumes if you wish.

As mentioned above, each of those directives is specified in the Pool or Pools that you use for your Volumes. In the case of Maximum Volume Job, Maximum Volume Bytes, and Volume Use Duration, you can actually specify the desired value on a Volume by Volume basis. The value specified in the Pool record becomes the default when labeling new Volumes. Once a Volume has been created, it gets its own copy of the Pool defaults, and subsequently changing the Pool will have no effect on existing Volumes. You can either manually change the Volume values, or refresh them from the Pool defaults using the update volume command in the Console. As an example of the use of one of the above, suppose your Pool resource contains:

Pool {
    Name = Disk-pool
    Pool Type = Backup
    Volume Use Duration = 23h
}

then if you run a backup once a day (every 24 hours), Bacula will use a new Volume for each backup, because each Volume it writes can only be used for 23 hours after the first write.

Automatic Volume Labeling

Use of the above records brings up another problem – that of labeling your Volumes. For automated disk backup, you can either manually label each of your Volumes, or you can have Bacula automatically label new Volumes when they are needed. Automatic Volume labeling permit automatic creation of a wide variety of labels including information from environment variables and special Bacula Counter variables.

Please note that automatic Volume labeling can also be used with tapes, but it is not nearly so practical since the tapes must be pre-mounted. This requires some user interaction. Automatic labeling from templates does NOT work with autochangers since Bacula will not access unknown slots. There are several methods of labeling all volumes in an autochanger magazine. For more information on this, read the section about AutochangerSupport.

Automatic Volume labeling is enabled by making a change to both the Pool resource (Director) and to the Device resource (Storage daemon) shown below. In the case of the Pool resource, you must provide Bacula with a label format that it will use to create new names. In the simplest form, the label format is simply the Volume name, to which Bacula will append a four digit number. This number starts at 0001 and is incremented for each Volume the catalog contains. Thus if you modify your Pool resource to be:

Pool {
    Name = Disk-pool
    Pool Type = Backup
    Volume Use Duration = 23h
    LabelFormat = "Vol-"
}

Bacula will create Volume names Vol-0001, Vol-0002, and so on when new Volumes are needed. Much more complex and elaborate labels can be created using variable expansion defined in the of the Variable Expansion chapter of the Bacula Enterprise Miscellaneous Guide. .

The second change that is necessary to make automatic labeling work is to give the Storage daemon permission to automatically label Volumes. Do so by adding LabelMedia = yes to the Device resource as follows:

Device {
    Name = DiskDevice_Dev0
    DriveIndex = 0
    Media Type = DiskStorage-mnt-bacula
    Archive Device = /mnt/bacula/backups
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    AlwaysOpen = no;
    LabelMedia = yes
}

You can find more details of the Label Format Pool record in Label Format description of the Pool resource records.

Restricting the Number of Volumes and Recycling

Automatic labeling discussed above brings up the problem of Volume management. With the above scheme, a new Volume will be created every day. If you have not specified Retention periods, your Catalog will continue to fill keeping track of all the files Bacula has backed up, and this procedure will create one new archive file (Volume) every day.

The tools Bacula gives you to help automatically manage these problems are the following:

1. Catalog file record retention periods, the File Retention = ttt record in the Client resource.

2. Catalog job record retention periods, the Job Retention = ttt record in the Client resource.

3. The AutoPrune = yes record in the Client resource to permit application of the above two retention periods.

4. The Volume Retention = ttt record in the Pool resource.

5. The AutoPrune = yes record in the Pool resource to permit application of the Volume retention period.

6. The Recycle = yes record in the Pool resource to permit automatic recycling of Volumes whose Volume retention period has expired.

7. The Recycle Oldest Volume = yes record in the Pool resource tells Bacula to Prune the oldest volume in the Pool, and if all files were pruned to recycle this volume and use it.

8. The Recycle Current Volume = yes record in the Pool resource tells Bacula to Prune the currently mounted volume in the Pool, and if all files were pruned to recycle this volume and use it.

9. The Purge Oldest Volume = yes record in the Pool resource permits a forced recycling of the oldest Volume when a new one is needed. N.B. This record ignores retention periods! We highly recommend not to use this record, but instead use Recycle Oldest Volume

10. The Maximum Volumes = nnn record in the Pool resource to limit the number of Volumes that can be created.

The first three directives (File Retention, Job Retention, and AutoPrune) determine the amount of time that Job and File records will remain in your Catalog, and they are discussed in detail in Volume Recycling.

Volume Retention, AutoPrune, and Recycle in the Pool resource determine how long Bacula will keep Jobs and Files associated to your Volumes before reusing them, and these directives are also discussed in detail in Volume Recycling.

The Maximum Volumes record can also be used in conjunction with the Volume Retention period to limit the total number of archive Volumes (files) that Bacula will create. By setting an appropriate Volume Retention period, a Volume will be purged just before it is needed and thus Bacula can cycle through a fixed set of Volumes. Cycling through a fixed set of Volumes can also be done by setting Recycle Oldest Volume = yes or Recycle Current Volume = yes. In this case, when Bacula needs a new Volume, it will prune the specified volume.

Concurrent Disk Jobs

Above, we discussed how you could have a single device named DiskDevice_Dev0 that writes to volumes in /mnt/bacula/backups. You can, in fact, run multiple concurrent jobs using the Storage definition given with this example, and all the jobs will simultaneously write into the Volume that is being written.

Now suppose you want to use multiple Pools, which means multiple Volumes, or suppose you want each client to have its own Volume and perhaps its own directory such as /mnt/bacula/client1 and /mnt/bacula/client2 … With the single Storage and Device definition above, neither of these two is possible. Why? Because Bacula disk storage follows the same rules as tape devices. Only one Volume can be mounted on any Device at any time. If you want to simultaneously write multiple Volumes, you will need multiple Device resources in one or more Autochangers in your bacula-sd.conf file, and thus multiple Storage resources in your bacula-dir.conf.

OK, so now you should understand that you need different Device definitions in the case of different directories, but you also need to know that the catalog data that Bacula keeps contains only the Media Type and not the specific storage device. This permits a tape for example to be re-read on any compatible tape drive. The compatibility being determined by the Media Type. The same applies to disk storage. Since a volume that is written by a Device in say directory /mnt/bacula/backups cannot be read by a Device with an Archive Device definition of /mnt/bacula/client1, you will not be able to restore all your files if you give both those devices Media Type = *DiskStorage-mnt-bacula*. During the restore, **Bacula will simply choose the first available device, which may not be the correct one. If this is confusing, just remember that the Directory has only the Media Type and the Volume name. It does not know the Archive Device (or the full path) that is specified in the Storage daemon. Thus you must explicitly tie your Volumes to the correct Device by using the Media Type.

The example shown below shows a case where there are two clients, each using its own Pool and storing their Volumes in different directories.

An Example

The following example is not very practical, but can be used to demonstrate the proof of concept in a relatively short period of time. The example consists of a two clients that are backed up to a set of 12 archive files (Volumes) for each client into different directories on the Storage machine. Each Volume is used (written) only once, and there are four Full saves done every hour (so the whole thing cycles around after three hours).

What is key here is that each physical device on the Storage daemon has a different Media Type. This allows the Director to choose the correct device for restores.

The Director’s configuration file is as follows:

Director {
    Name = bacula-dir
    QueryFile = "/opt/bacula/scripts/query.sql"
    PidDirectory = "/opt/bacula/working"
    WorkingDirectory = "/opt/bacula/working"
    Password = dir_password
}
Schedule {
    Name = "FourPerHour"
    Run = Level=Full hourly at 0:05
    Run = Level=Full hourly at 0:20
    Run = Level=Full hourly at 0:35
    Run = Level=Full hourly at 0:50
}
Job {
    Name = "RecycleExample-1"
    Type = Backup
    Level = Full
    Client = Rufus
    FileSet= "Example FileSet"
    Messages = Standard
    Storage = DiskDevice-1
    Pool = Recycle-1
    Schedule = FourPerHour
}
Job {
    Name = "RecycleExample-2"
    All trademarks are the property of their respective owners
    Main Reference Manual
    An Example
    Type = Backup
    Level = Full
    Client = Roxie
    FileSet= "Example FileSet"
    Messages = Standard
    Storage = DiskDevice-2
    Pool = Recycle-2
    Schedule = FourPerHour
}
FileSet {
    Name = "Example FileSet"
    Include {
        Options {
            compression=GZIP
            signature=SHA1
        }
        File = /home/kern/bacula/bin
    }
}
Client {
    Name = Rufus
    Address = rufus
    Catalog = BaculaCatalog
    Password = client1_password
}
Client {
    Name = Roxie
    Address = roxie
    Catalog = BaculaCatalog
    Password = client2_password
}
Storage {
    Name = DiskDevice-1
    Address = rufus
    Password = local_storage_password
    Device = DiskDevice-1
    Media Type = DiskStorage-1-mnt-bacula
}
Storage {
    Name = DiskDevice-2
    Address = rufus
    Password = local_storage_password
    Device = DiskDevice-2
    Media Type = DiskStorage-2-mnt-bacula
}
Catalog {
    Name = BaculaCatalog
    dbname = bacula; user = bacula; password = ""
}
Messages {
    Name = Standard
    All trademarks are the property of their respective owners
    An Example
    ...
}
Pool {
    Name = Recycle-1
    Use Volume Once = yes
    Pool Type = Backup
    LabelFormat = "Recycle1-"
    AutoPrune = yes
    VolumeRetention = 2h
    Maximum Volumes = 12
    Recycle = yes
}
Pool {
    Name = Recycle-2
    Use Volume Once = yes
    Pool Type = Backup
    LabelFormat = "Recycle2-"
    AutoPrune = yes
    VolumeRetention = 2h
    Maximum Volumes = 12
    Recycle = yes
}

and the Storage daemon’s configuration file is:

Storage {
     Name = bacula-sd
     WorkingDirectory = "/opt/bacula/working"
     Pid Directory = "/opt/bacula/working"
     MaximumConcurrentJobs = 10
 }
 Director {
     Name = bacula-dir
     Password = local_storage_password
 }
 Device {
     Name = DiskDevice-1
     Media Type = DiskStorage-1-mnt-bacula
     Archive Device = /mnt/bacula/backups-1
     LabelMedia = yes;
     Random Access = Yes;
     AutomaticMount = yes;
     RemovableMedia = no;
     AlwaysOpen = no;
 }
 Device {
     Name = DiskDevice-2
     Media Type = DiskStorage-2-mnt-bacula
     Archive Device = /mnt/bacula/backups-2
     LabelMedia = yes;
     Random Access = Yes;
     AutomaticMount = yes;
     RemovableMedia = no;
     AlwaysOpen = no;
 }
 Messages {
     Name = Standard
     director = bacula-dir = all
 }

With a little bit of work, you can change the above example into a weekly or monthly cycle (take care about the amount of archive disk space used).

Considerations for Multiple Clients

If we take the above example and add a second Client, here are a few considerations:

• Although the second client can write to the same set of Volumes, you will probably want to write to a different set.

• You can write to a different set of Volumes by defining a second Pool, which has a different name and a different LabelFormat.

• If you wish the Volumes for the second client to go into a different directory (perhaps even on a different filesystem to spread the load), you would do so by defining a second Device resource in the Storage daemon. The Name must be different, and the Archive Device could be different. To ensure that Volumes are never mixed from one pool to another, you might also define a different MediaType (e.g. File1).

In this example, we have two clients, each with a different Pool and a different number of archive files retained. They also write to different directories with different Volume labeling.

The Director’s configuration file is as follows:

Director {
    Name = bacula-dir
    QueryFile = "/opt/bacula/scripts/query.sql"
    PidDirectory = "/opt/bacula/working"
    WorkingDirectory = "/opt/bacula/working"
    Password = dir_password
}
# Basic weekly schedule
Schedule {
    Name = "WeeklySchedule"
    Run = Level=Full fri at 1:30
    Run = Level=Incremental sat-thu at 1:30
}
FileSet {
    Name = "Example FileSet"
    Include {
        Options {
            compression=GZIP
            signature=SHA1
        }
        File = /home/kern/bacula/bin
    }
}
Job {
    Name = "Backup-client1"
    Type = Backup

    Level = Full
    Client = client1
    FileSet= "Example FileSet"
    Messages = Standard
    Storage = DiskDevice-1
    Pool = client1-pool
    Schedule = "WeeklySchedule"
}
Job {
    Name = "Backup-client2"
    Type = Backup
    Level = Full
    Client = client2
    FileSet= "Example FileSet"
    Messages = Standard
    Storage = DiskDevice-2
    Pool = client2-pool
    Schedule = "WeeklySchedule"
}
Client {
    Name = client1
    Address = client1
    Catalog = BaculaCatalog
    Password = client1_password
    File Retention = 7d
}
Client {
    Name = client2
    Address = client2
    Catalog = BaculaCatalog
    Password = client2_password
}
# Two Storage definitions with different Media Types
# permits different directories
Storage {
    Name = DiskDevice-1
    Address = rufus
    Password = local_storage_password
    Device = DiskDevice-1
    Media Type = DiskStorage-1-mnt-bacula
}
Storage {
    Name = DiskDevice-2
    Address = rufus
    Password = local_storage_password
    Device = DiskDevice-2
    Media Type = DiskStorage-2-mnt-bacula
}
Catalog {
    Name = BaculaCatalog
    dbname = bacula; user = bacula; password = ""
}
Messages {
    Name = Standard
    ...
}
# Two pools permits different cycling periods and Volume names
# Cycle through 15 Volumes (two weeks)
Pool {
    Name = client1-pool
    Use Volume Once = yes
    Pool Type = Backup
    LabelFormat = "Client1-"
    AutoPrune = yes
    VolumeRetention = 13d
    Maximum Volumes = 15
    Recycle = yes
}
# Cycle through 8 Volumes (1 week)
Pool {
    Name = client2-pool
    Use Volume Once = yes
    Pool Type = Backup
    LabelFormat = "Client2-"
    AutoPrune = yes
    VolumeRetention = 6d
    Maximum Volumes = 8
    Recycle = yes
}

and the Storage daemon’s configuration file is:

Storage {
    Name = bacula-sd
    WorkingDirectory = "/opt/bacula/working"
    Pid Directory = "/opt/bacula/working"
    MaximumConcurrentJobs = 10
}
Director {
    Name = bacula-dir
    Password = local_storage_password
}
# Archive directory for Client1
Device {
    Name = DiskDevice-1
    Media Type = DiskStorage-1-mnt-bacula
    Archive Device = /mnt/bacula/client1
    LabelMedia = yes;
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    AlwaysOpen = no;
}
# Archive directory for Client2
Device {
    Name = DiskDevice-2
    Media Type = DiskStorage-2-mnt-bacula
    Archive Device = /mnt/bacula/client2
    LabelMedia = yes;
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    AlwaysOpen = no;
}
Messages {
    Name = Standard
    director = bacula-dir = all
}