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.
Use Bacula to avoid using multiple backup solutions, or having inadequate protection from ransomware.
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 Bacula's Proxmox module (details further below).
The first method does not use the Proxmox module, but instead a Bacula Enterprise file daemon is installed on every VM to operate properly. Treating your virtual servers as physical ones by equipping them with Bacula Enterprise File Daemon nevertheless allows for a variety of Bacula Enterprise features and advantages, including:
The second backup strategy uses Bacula's Proxmox module, and prioritizes image backups as the main backup method. This module offers far higher performance, efficiency and speed of use. With the Proxmox module, there is no need to install Bacula’s file daemon onto every VM. Data is saved either as 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 place specified the system administrator.
With Bacula's Proxmox module, 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 therefore lighter than with the other one. Bacula’s Proxmox module offers a number of industry leading advantages, and its backup and restore operations are examined more thoroughly here.
Regular backup operations for a single guest VM usually includes 3 main steps:
There is no limitation to the power state of a VM that you back up. 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:
Using Bacula's Proxmox module, there are 2 different restore operations:
Restore to a local directory is possible; 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 will also be able to see the location of the restore, as well as its process.
Restore as a VM 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 offers some options such as:
Restore to a Proxmox hypervisor as a VM can be initiated with the command:
* restore where=/
Here is an example log for a VM restore to the hypervisor directly. The restore job log will indicate which guest VM is restored and which new guest VM was created:
JobId 76: Start Restore Job RestoreFiles.2018-01-25_13.50.31_29
JobId 76: Using Device "FileChgr1-Dev1" to read.
JobId 76: Ready to read from volume "Vol-0004" on File device "FileChgr1-Dev1" (/opt/bacula/archive).
JobId 76: proxmox: VM restore: lxc/ubuntu-container/VM101 as VM222
JobId 76: End of Volume "Vol-0004" at addr=47137166325 on device "FileChgr1-Dev1" (/opt/bacula/archive).
The new guest VM created during the restore will get a new VMID (if the original VMID is not available anymore) but the name / hostname will stay the same as it was with the original VM.
Further help on Proxmox backup: