Subsections


Volumes

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.

The _left_quote_Pool_right_quote_

The Concept

Pools in Bacula are just a way to manage volumes and to manage collections of similar volumes. The following are just examples and you might have either different requirements or even no requirement to separate volumes into several pools: There can be many reasons to use or not use several pools; the Bacula configuration gives the Backup Administrator the ability to match the defined requirements.

Due to how Bacula manages Volume Retention periods, the jobs put into the same pool should have the same retention periods.

Pool Types

Bacula allows several kinds of pools includingnoteListed in the logical order : A Scratch pool contains volumes that may be with any pool. If no volumes are available for a particular pool Bacula will look in the Scratch pool and move the volume to the pool in question.

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).

Volume Cycling Process
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 \bog{}Full\cog{} (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.
  }

Media Type

Even if Media Types may be used for several different reasons with Bacula, you must use them when dealing with several storages or several locations on the same storage.

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.

Storage Capacity Management

If you want to overwrite a backup you need to overwrite the corresponding volume(s). Additionally, to be able to reuse a Volume, its retention period should first be expired.


Volume Retention

The Volume retention period is defined as the time Bacula will not overwrite a Volume after it was last written to. Therefore, if you keep writing to a volume with a retention period of seven days for six months, your volume will not be overwritten for a total of 187 days - perhaps even more: remember that Bacula will try to keep your data safe for as long as possible.

Limiting the Volume Size

Tapes

On tapes, we usually don't need to explicitly limit the volume size, because the volume is identical to the tape which has a limited and defined maximum capacity.

Disks

On disks, on the other hand, as volumes are handled with files, there is a risk of filling the disk with only one volume, so we need to limit the volume size and number of volumes. We explained above how the volume retention periods are handled by Bacula. However, often we need to get back our volumes as soon as possible to be able to reuse the storage space they are using during their retention periods. In the previous case (see chapter (here)) we should have restricted the use duration of the Volume.

There are several directives available to limit the occupied storage space in a Pool:

These limitations can be managed manually (by the Administrator with console commands) or automatically (through scripts or Admin jobs, for example).

Space Management

As we already noted, Bacula will try to keep your data safe as long as possible. This means that you can be in a situation (disk backups only) where your storage space is too small even if you defined correct retention periods. In such cases, you can use the _left_quote_Action on Purge_right_quote_ directive requesting Bacula to actually truncate the disk volumes and thus to get back the corresponding storage space freed by the truncate.

Volumes and Pool Modifications

Because of its great flexibility, Bacula can be puzzling. Let's say you defined Maximum Volume Bytes to 10GB and then realize that you want to move it to 15GB. Then you will modify your _left_quote_Pool_right_quote_ resource definition. This is correct and will work for all new volumes created into the Pool. But the existing volumes are not modified by this change. To update the existing volumes already in the Pool with the new values you must update the existing volumes' meta-data:

bsbuild 2025-03-27