Home > Backup and Recovery Strategies Blog > How to Backup Proxmox? Proxmox Backup and Recovery Methods
1 Star2 Stars3 Stars4 Stars5 Stars
(17 votes, average: 5.00 out of 5)
Loading...

How to Backup Proxmox? Proxmox Backup and Recovery Methods

  • October 28, 2020, Rob Morrison

Creating effective backups is a critical practice for almost any company nowadays, no matter what types of data and applications they are working with. Proxmox Virtual Environment (VE) is no different in this regard. Fortunately, the quickly rising popularity of Proxmox has led to a lot of different third-party backup solutions having developed some way of creating a Proxmox-specific backup, and there’s also a few built-in ways of making backups, as well.

Built-in Proxmox backup methods

First, it’s understandable that built-in backup methods may have limitations and problems with customizability. Therefore, and as a general rule, all the built-in Proxmox backup methods tend to be Full backups. This, in turn, means they come  with all the inherent limitations involved with using this backup level.

There are two main ways of initiating a built-in Proxmox backup – using the original GUI or via the specific vzdump command in the command line. These backups also need to have a file-level backup storage, and backups can also be scheduled using the “Datacenter” level in the GUI.

Proxmox can operate with both VMs and containers – although there are some differences when it comes to different backup modes, despite there being the same trio of modes for both containers and VMs: stop mode, suspend mode and snapshot mode.

  • Stop mode for a VM is the one that provides the most consistency out of the three, at the cost of a short downtime period. As the name suggests, the VM needs to be stopped before performing this backup mode.
    The idea for containers is the same, but there is a potential for prolonged downtime.
  • Suspend mode for a VM tries to lessen the potential downtime by not stopping the entire VM completely, but the downtime is still relatively large, and the data consistency may suffer drastically, so this option is not generally recommended.
    The situation for containers is somewhat different, since that process creates a copy of the live container data to a temporary location, suspends the container afterwards and then replaces the first backup’s files with the copy from the suspended container. This operation’s downtime is significantly less than in the stop mode, but it does require an additional free space to hold the temporary container copy.
  • Snapshot is probably the most interesting option out of the three, providing the ability to create VM backups with little to no downtime, but with a risk of a backup job being inconsistent. Since the data is copied from an active VM, there’s a possibility of copying some file mid-change; that is why snapshot usually performs guest-fsfreeze-freeze and guest-fsfreeze-thaw commands to attempt to mitigate the potential consistency issues.
    The process of creating a snapshot of a container is mostly the same since the backup software also suspends the operations inside of a specific container and then creates a temporary snapshot of all the contents from that container. The entirety of the container’s contents is then archived and the snapshot itself is deleted afterwards.

The restoration process with built-in Proxmox appliances is also relatively simple – it can be done either via the original GUI or with the help of two different commands:

  • qmrestore – to restore VMs.
  • pct restore – to restore containers.

One potential problem with the restoration process is that it might seriously affect your overall performance with VMs/containers, since there’s no limit to the amount of bandwidth that the restore operations can undertake. Fortunately, those limits can be set up by the user. There are two types of such a limit: per-restore and per-storage write.

Per-restore is all about limiting the bandwidth for a restoration from a single backup archive, and per-storage write limits the amount of bandwidth used in the process of writing to a specific storage.

File names and compression

Some of the newer vzdump versions are encoding both the backup time and the guest type into the filename. An example of such a filename is shown below:


vzdump-lxc-105-2019_05_24-11_08_39.tar

This kind of naming allows for the storage of several different backups in the same directory. There’s also a number of retention options available that we’ll go into later.

File compression is another part of the backup process when it comes to Proxmox. There’s three commonly known compression algorithms: lzo, gzip and zstd. As it stands, zstd is currently the fastest algorithm out of the three, since it does support multi-threading. Surprisingly enough, both lzo and gzip are often the default choices for a lot of cases and are more commonly used in general.

There’s also a drop-in replacement for gzip available called pigz, and it boasts improved performance due to the ability to use multi-threading. Both pigz and zstd’s amount of cores/threads used can be adjusted manually.

Most of the time it’s easy to understand what compression algorithm was used just by looking at the extension of the backup file.

  • .zst – Zstandard compression
  • .gz or .tgz – gzip compression
  • .lzo – lzo compression

If the backup file extension doesn’t match any of the examples above – then it was  not compressed by vzdump in the first place.

Backup retention and examples

There’s a number of different options available when it comes to backup retention in Proxmox, here’s the list of them all:

  • keep-all <boolean> – all of the backups are kept. No other options can be set if this is “true”.
  • keep-last <N> – specifies the number of backups that would be kept, counting backward from the last one.
  • keep-hourly <N> – specifies the number of hours that your backups would be kept for. If there’s more than a single backup for an hour, only the most recent backup is kept.
  • keep-daily <N> – specifies the number of days that your backups would be kept for. If there’s more than a single backup for a day, only the most recent backup is kept.
  • keep-weekly <N> – specifies the number of weeks that your backups would be kept for. If there’s more than a single backup for a week, only the most recent backup is kept.
  • keep-monthly <N> – specifies the number of months that your backups would be kept for. If there’s more than a single backup for a month, only the most recent backup is kept.
  • keep-yearly <N> – specifies the number of years that your backups would be kept for. If there’s more than a single backup for a year, only the most recent backup is kept.

All of the retention options are processed in this order, from top to bottom. Each of these options is only covering for the backups within its time period and does not take care of the backups that were already covered by the previous options. The retention options of your choice should be specified in a comma-separated list, as in the example below:


# vzdump 777 --prune-backups keep-last=3,keep-daily=13,keep-yearly=9

Now we’ll go over some of the regular backup commands and their additional capabilities in regards to the configuration


# vzdump 777

In the example above we’re creating a basic dump of a guest 777 to the default dump directory without any snapshots.


# vzdump 777 --mode suspend

In the example above we are creating a backup of the same guest using a snapshot, which results in a minimal downtime.


# vzdump --all --mode suspend --mailto root --mailto admin

In the example above we are backing up all of our guest systems and sending notification emails to both admin and root users.


# vzdump 777 --dumpdir /mnt/backup --mode snapshot

In the example above we use the snapshot method with a custom dump directory.


# vzdump 101 102 103 --mailto root

In the example above we are backing up several different guests at once (101, 102, 103…).


# vzdump --mode suspend --exclude 101,102

In the example above we are backing up all of the guests except the specified ones (101, 102).


# pct restore 600 /mnt/backup/vzdump-lxc-777.tar

In the example above we are restoring a container to a new CT 600.


# qmrestore /mnt/backup/vzdump-qemu-888.vma 601

In the example above we are restoring a QemuServer VM as VM 601.

Bacula Enterprise’s Proxmox backup methods

Fortunately, there is a good range of third-party alternatives when it comes to backup and restore operations within the Proxmox virtual environment. For example, there is Bacula Enterprise, which is a comprehensive backup solution that’s capable of working with a myriad of different database/VM types, and it also has a natively integrated Proxmox module.

Surprisingly enough, Bacula Enterprise also offers two different ways of performing a Proxmox VM backup, and one of them does not even involve the Proxmox module in the first place.

The first method involves installing a Bacula Enterprise File Daemon on each of the guest VMs of which you want to perform backups. Please note that you will have to schedule and prioritize if you are using multiple VMs with this method since backing up all of them at once might easily create a bottleneck for your network/disk subsystem.

Other than that, installing a Bacula File Daemon allows for a large choice of features, including job verification, individual file restoration, file level compression, checksum verification, and more.

Because the second method of creating Proxmox backups with the help of Bacula’s  Proxmox module is the more powerful one, we’ll only dive into this specific module’s details and configurations.

Proxmox backup with Bacula Enterprise

Three main steps are included in the process of creating a Proxmox VM backup with Bacula Enterprise:

  • Guest VM configuration saving.
  • Guest VM snapshot creation.
  • Data offloading with the help of vzdump command.

As you can see, the main backup mode that Bacula Enterprise utilizes is Snapshot mode, allowing for consistent backups and little to no downtime. LXC guest VM backups are stored in two file types – .tar and .conf, while QEMU guest VMs are using the .vma file type.

This applies to one guest VM only, so there is a need to create multiple backup jobs if you need to backup multiple Proxmox VMs. The process itself is largely  automated, creating snapshots and removing them after offloading the data, so it is relatively simple from a regular user’s standpoint.

Proxmox restore with Bacula Enterprise

Two restore types are available when it comes to Proxmox with Bacula Enterprise. You can restore the data as a complete Proxmox guest VM (it will be restored either with the original vmid that it was backed up with, or with the new one if the previous one is already taken). All you have to do is to use the where= parameter during the Bacula data recovery process.

Another nuance is about the vmid of the restored guest VM. If there’s a need for a restored VM to have a new vmid, it is randomly chosen as a number of the highest vmid available +1…11 added to that number. You can also go over this random process with the sequentialvmid command – that way your guest VM would get the first available number within the system.

Another recovery option is to restore all of the data into a local directory. This can also be done with a similar command: where=/some/path. Nonexistent paths would be automatically created by the Proxmox module.

Conclusion

Bacula Enterprise offers an especially wide range of different options when it comes to backup and restore operations, and its Proxmox backup and recovery is no different. The high level of customization results in especially fast backup and (more importantly) fast recovery of an organization’s data. Utilizing its advanced snapshot technology and leveraging the software’s flexibility in the process, Bacula Enterprise is a strong choice for your Proxmox backup and restore needs.

About the author

Rob Morrison Rob on LinkedIn

Rob Morrison is the marketing director at Bacula Systems. He started his IT marketing career with Silicon Graphics in Switzerland, performing strongly in various marketing management roles for almost 10 years. In the next 10 years Rob also held various marketing management positions in JBoss, Red Hat and Pentaho ensuring market share growth for these well-known companies. He is a graduate of Plymouth University and holds an Honours Digital Media and Communications degree, and completed an Overseas Studies Program.

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>