Proxmox backup software. How to backup Proxmox?

Proxmox Backup and Recovery Software: Ease and Speed.

Bacula Enterprise’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 Proxmox module provides Incremental backup – contact us for more details.

Download Proxmox whitepaper Download free trial

Proxmox Guest VM backup Strategies

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:

Jobs verification;
File level compression capabilities;
Individual file restoration;
Backup accuracy;
Spyware and ransomware detection via checksum comparison;
Exclusion of specific files or folders, and more.

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.

Proxmox Backup Operations

Regular backup operations for a single guest VM usually includes 3 main steps:

Guest VM config is saved (specifically for LXC VMs)
Snapshot of a VM is created (does not require stopping the VM/container)
Data is saved through vzdump execution

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:

/@proxmox/lxc/<name-label>/VM<vmid>.conf + /@proxmox/lxc/<name-label>/VM<vmid>.tar for LXC guest VMs
/@proxmox/qm/<name-label>/VM<vmid>.vma for QEMU guest VMs

Proxmox Restore Operations

Using Bacula’s Proxmox module, there are 2 different restore operations:

Restore to a local directory;
Restore to Proxmox hypervisor as a new VM.

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:

Possible to restore to an alternate proxmox hypervisor
To select a specific storage for the restore
To select a specific proxmox pool for the restore

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.

Here are some of the Proxmox backup software features:

Snapshot-based online backup of any Proxmox VM including QEMU and LXC Guests. Snapshot mode generates live backup which minimizes the downtime of a VM during the the backup process.

Restore complete virtual machine image to original or alternate Proxmox hypervisor

Ability to automatically scan Proxmox clusters to create Bacula Enterprise configurations for each virtual machine

Full image-level Proxmox backup

Restore QEMU VM archive (.vma) to alternate directory

Restore LXC VM archive (.tar) and configuration to alternate directory

bwlimit “bwlimit=” specifies if the backup should be performed with an I/O bandwidth limitation. This Bacula feature can therefore limit the I/O bandwidth Backup Operations on the Hypervisor side. It can control the backup process to avoid I/O overhead on the hypervisor, preventing the exhaust of Hardisk Resources on the Hypervisor itself, during the backup operations. This is in addition to Bacula’s own bandwidth limitation feature.