Bacula Enterprise Edition’s unique compatibility with diverse types of virtual environments also includes Proxmox and Proxmox clusters. Bacula enables true enterprise-grade backup and recovery of the Proxmox open-source server virtualization environment. It makes Proxmox backup and restore operations as fast and simple as possible, and brings all the advantages of Bacula’s especially broad feature set to benefit the user with increased operational efficiency and reduced costs.
Proxmox VE is a powerful and lightweight open source server virtualization software, optimized for performance and usability. Offering maximum flexibility and using the Proxmox API, Bacula is fully integrated and can back up and recover data from Proxmox, including its two virtualization technologies – Kernel-based Virtual Machine (KVM) and container-based virtualization with Linux Containers (LXC) – and / or QEMU virtual machines.
Bacula’s capabilities for Proxmox backup can be exploited in two different ways: by installing Bacula Enterprise File Daemon on each Guest, or by creating image backups using the Proxmox module.
The first method does not use the Proxmox module, but itinstead needs to have a Bacula Enterprise file daemon installed on every VM to operate properly. Users that are planning to utilize this method would also have to use scheduling, prioritizing and other Bacula features to prevent cluttering and creating the “bottleneck” effect for the backup window due to the high amount of I/O requests at once.
Treating your virtual servers as the physical ones by equipping them with Bacula Enterprise File Daemon allows for a variety of Bacula Enterprise features and advantages, including:
The second backup strategy prioritizes image backups as the main backup method. In this case there’s no need to install Bacula’s file daemon onto every VM, but you do need instead to use the Proxmox module. The disks in question are saved either as the raw images (QEMU VMs), or as .tar archives (LXC VMs). The snapshot technology is used to both read and save the contents of your disks, and the Proxmox API is utilized after that to dump these copies in a specific place.
Since with this method Bacula has no need to go through the Client filesystems to read and analyze the data, the overall toll on the infrastructure from this backup method is lighter than with the other one. And as the design goal of Bacula’s Proxmox module is the second method, its backup and restore operations are examined more thoroughly here.
Regular backup operations for a single guest VM usually includes 3 main steps:
There’s no limitation to the power state of a VM that you’re creating a backup of. The snapshots themselves are created using the Proxmox hypervisor. The specific part of the program log lets you know about the process and its steps.
The normal procedure is to create two files for LXC guest VM (.tar and .conf), and one file for a QEMU guest VM. Inside Bacula’s ecosystem these files can be found in specific locations:
For the mentioned Proxmox backup method, there are 2 different restore operations:
Restoration process to a local directory is the easier one, it utilizes one specific parameter where=/some/path of Bacula that you have to use to specify the location for the backup that you’re restoring – it has to be a full path to the Proxmox module (the server that it’s located onto).
An example of a local directory restoration command would look like this:
* restore where=/tmp/bacula/restores
You should see something like this as a result (with some different valuables, of course):
JobId 90: Start Restore Job RestoreFiles.2019-05-15_12.02.12_05
JobId 90: Using Device "FileChgr1-Dev1" to read.
JobId 90: Forward spacing Volume "Vol-0001" to addr=45406565308
JobId 90: proxmox: VM local restore: qm/ubuntu-server/VM108
In this log you’ll also be able to see the location of the restore, as well as its process.
Restoration as a VM is a bit more complicated. It also utilizes the where= parameter, it is used to send the entire guest VM archive to the Proxmox hypervisor, which then restores the archive as a new guest VM if the vmid of the backup is already allocated, or restored with the original vmid if it’s not taken.
The way that all of the new guest VMs get their vmid is also pretty interesting, it’s the highest vmid from all of the allocated ones + a number from 1 to 11 to mitigate the possibility of a resource allocation conflicts (since Proxmox itself has no mechanisms to deal with such situations). This random vmid allocation pattern can also be changed with the sequentialvmid restore option that forces the new guest VM to get the next available vmid with no added numbers.
Restore to a Proxmox hypervisor as a VM can be initiated with the command:
* restore where=/
Further help on Proxmox backup: