

Bacula manages all its storage compartments - Volumes in our terminology - in Pools. In particular, a Job is not configured to write to any particular Volume, but to a set of Volumes called a Pool. Volumes of Bacula are always members of only one Pool. There can however be multiple pools. Accordingly, we present the conceptual overview here starting with the higher-level Pool view.
Due to how Bacula manages Volume Retention periods, the jobs put into the same pool should have the same retention periods.
A Backup pool contains volumes intended to keep data from backups for a defined retention period. It can also include Recycled or Purged volumes, i.e. Volumes that are eligible to be overwritten.
A Recycle pool contains volumes after the purging process freed them, after they have been used in a Backup pool.
The Bacula configuration allows the Administrator to attach a Scratch Pool and a Recycle Pool to a Backup pool. The volume cycle management process is described by the figure (here).
The following example is a pool definition to manage Volumes for day-to-day incremental backup jobs:
# Pool to handle day-to-day backup jobs
Pool {
Name = PoolFile
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 15 days
Label Format = "file-"
# Auto-labeling new volumes
Action on Purge = Truncate
# Backup to disk. We get back the space ASAP.
Next Pool = PoolVFull
# This is the pool where Virtual Full will take place
Storage = t-disk
Volume Use Duration = 23h
# Low duration time, better volume retention period.
Maximum Volumes = 750
Maximum Volume Bytes = 1GB
# Small volumes. A lot of them. This is for incrementals.
}
In the next example you will find a pool definition to keep the Virtual Full backups for the previously described incremental backup jobs:
#
# Virtual Full in this pool
Pool {
Name = PoolVFull
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 20 days
Label Format = "file-vfull-"
# Auto-labeling new volumes
Action on Purge = Truncate
# Backup to disk. We get back the space ASAP.
Next Pool = PoolRDX
# This is the pool where Copy jobs will be sent
Storage = t-migrate
Volume Use Duration = 23h
# Low duration time, better volume retention period.
Maximum Volume Bytes = 10GB
Maximum Volumes = 20
# Few volumes, bigger than the incremental ones. For "Full" (VF) purpose.
}
And below, we show a pool definition to store the Copy volumes for the previous Full backup jobs:
#
# Copy of Fulls in this pool
Pool {
Name = PoolRDX
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 40 days
Action on Purge = Truncate
# Backup to disks. We get back the space ASAP.
Volume Use Duration = 20h
# Low duration time, better volume retention period.
Storage = t-rdx
Maximum Volume Bytes = 20GB
# 320GB RDX removable disk. 20GB per RDX volume.
}
In particular when Bacula is searching for a volume to be used for a backup, it will go through the available volumes. A Bacula job uses a distinct Storage device and the volume selection must be restricted to the actually available volumes. For example, it is quite common to see different disk storage arrays, mounted at different mount points and used by different storage devices, where volumes located in one directory are not available through the other storage device.
More obvious (and less easy to fix!) is a case of mixed media - for example, a disk storage device will never be able to write to a physical tape. So, all storage devices that cannot share their media must use distinct Media Types.
There are several directives available to limit the occupied storage space in a Pool: