Virtual Full Jobs

Available as of version 14.0.4

Since Bacula Enterprise version 14.0.4, most plugins are compatible with VirtualFull jobs. Refer to a specific plugin’s article for more information.

When the Job Level is set to VirtualFull, it permits you to consolidate the previous Full backup plus the most recent Differential backup and any subsequent Incremental backups into a new Full backup. This new Full backup will then be considered as the most recent Full for any future Incremental or Differential backups. The VirtualFull backup is accomplished without contacting the client by reading the previous backup data and writing it to a volume in a different pool.

Bacula Enterprise virtual backup feature is often called Synthetic Backup or Consolidation in other backup products.

Administrators will understand that the “Accurate” mode takes additional resources and time when running backups.

To improve performance, you may use the “Accurate” directive when using Virtual Full backups only for the last incremental before the Virtual Full itself. Activating this directive for every incremental backup would be even better but could increase the backup time.

In some respects the Virtual Backup feature works similar to a Migration job, in that Bacula normally reads the data from the pool specified in the Job resource, and writes it to the Next Pool specified in the Job resource. Note, this means that usually the output from the Virtual Backup is written into a different pool from where your prior backups are saved. Doing it this way guarantees that you will not get a deadlock situation attempting to read and write to the same volume in the Storage daemon. If you then want to do subsequent backups, you may need to move the Virtual Full Volume back to your normal backup pool. Alternatively, you can set your Next Pool to point to the current pool. This will cause Bacula to read and write to Volumes in the current pool. In general, this will work, because Bacula will not allow reading and writing on the same Volume. In any case, once a VirtualFull has been created, and a restore is done involving the most current Full, it will read the Volume or Volumes by the VirtualFull regardless of in which Pool the Volume is found.

A typical Job resource definition might look like the following:

Job {
    Name = "MyBackup"
    Type = Backup
    Client = localhost-fd
    FileSet = "Full Set"
    Storage = File
    Messages = Standard
    Pool = Default
    SpoolData = yes
}
# Default pool definition
Pool {
    Name = Default
    Pool Type = Backup
    Volume Retention = 365d  # one year
    NextPool = Full
    Storage = File
}
Pool {
    Name = Full
    Pool Type = Backup
    Volume Retention = 365d  # one year
    Storage = DiskChanger
}
# Definition of file storage device
Storage {
    Name = File
    Address = localhost
    Password = "xxx"
    Device = FileStorage
    Media Type = File
    Maximum Concurrent Jobs = 5
}
# Definition of DDS Virtual tape disk storage device
Storage {
    Name = DiskChanger
    Address = localhost # N.B. Use a fully qualified name here
    Password = "yyy"
    Device = DiskChanger
    Media Type = DiskChangerMedia
    Maximum Concurrent Jobs = 4
    Autochanger = yes
}

Then in bconsole or via a Run schedule, you would run the job as:

run job=MyBackup level=Full
run job=MyBackup level=Incremental accurate=yes
run job=MyBackup level=Differential accurate=yes
run job=MyBackup level=Incremental accurate=yes
run job=MyBackup level=Incremental accurate=yes

So providing there were changes between each of those jobs, you would end up with a Full backup, a Differential, which includes the first Incremental backup, then two Incremental backups. Please notice that incremental and differential jobs require the option accurate=yes to work properly. All the above jobs would be written to the Default pool.

To consolidate those backups into a new Full backup, you would run the following:

run job=MyBackup level=VirtualFull

And it would produce a new Full backup without using the client, and the output would be written to the Full Pool which uses the Diskchanger Storage.

If the Virtual Full is run, and there are no prior Jobs, the Virtual Full will fail with an error.

Note, the Start and End time of the Virtual Full backup is set to the values for the last job included in the Virtual Full (in the above example, it is an Increment). This is so that if another incremental is done, which will be based on the Virtual Full, it will backup all files from the last Job included in the Virtual Full rather than from the time the Virtual Full was actually run.