Built-in Proxmox backup solutions
Backup systems are often considered to be one of the most important parts of the company’s IT infrastructure in general, and for a good reason. The risk of losing or exposing at least some of the company’s data could mean drastic consequences for the majority of companies, no matter their size. Proxmox VE (Virtual Environment) users are no exception to that rule, either.
The need for effective backup as a protection measure is of course high, so it’s not uncommon for platforms and environments themselves to have a built-in backup and recovery solution, even if its functionality may be somewhat limited.
First of all, the built-in Proxmox backup solutions can only perform Full backups, and this means that the inherent advantages and limitations of this backup level are present immediately. There are two main ways of initiating a built-in Proxmox backup: it can be started either with the “vzdump” command in the command line or using the original GUI.
It’s important to mention that backup scheduling can also be set up so that you can automatically perform backups of specific storages on specific days or a specific time of the day. This can be done on the datacenter level of the GUI, which in turn modifies the corresponding entries in /etc/cron.d/vzdump.
Built-in backup methods
Since Proxmox backup solutions work with both containers and VMs – there are some differences between how different backup modes work with different storage types – but the main idea remains the same. There are three general backup methods that Proxmox offers: stop, suspend, and snapshot.
Stop mode is easily the most consistent out of the three, but it’s also the one that suffers from the longest VM/container downtime. As the name suggests, for the backup to be performed, the target storage needs to be stopped, which can be critical for some businesses.
Suspend mode takes advantage of the ability to create temporary storage copies in an attempt to lessen the original downtime problems of the Stop mode. For VMs, the downtime is far less than before, but it’s still present, and the general data consistency could suffer in the process, so this option is rarely used. The container backup process, in this case, is somewhat different, copying the live container’s data to a temporary location and then replacing that temporary copy with the data from the suspended container. The downtime, in this case, is still less than with the original Stop mode, but there are some disadvantages in the form of an additional space that’s needed to hold the temporary copy of a container.
Snapshot mode is the last one out of the three, but not the least, since it’s probably the most convenient one for a lot of use cases. As the name suggests, this whole mode relies on the system’s ability to create snapshots of the active VM/container. There’s still a risk of the data being inconsistent if some file was transferred to a snapshot mid-change, this is why the snapshot usually includes commands such as guest-fsfreeze-freeze and guest-fsfreeze-thaw in an attempt to mitigate said potential problems.
Built-in restore methods
The restore process can also be initiated in two different ways – with the help of the GUI, or using the storage-specific command:
- qmrestore for VMs,
- pct restore for containers.
An important detail about the restore process is that it can drastically decrease your system’s performance since the default settings for the restoration process don’t have any limitations for the amount of bandwidth taken by the restoration. Luckily enough, these limitations can be set up manually using two specific commands:
- per-restore sets up the limitations for one specific backup archive,
- per-storage is all about limiting the entire restoration process’s capabilities for a single storage location.
Proxmox Backup configuration
The global configuration parameters are stored in the /etc/vzdump.conf and can be modified with ease. Each line is structured in the simple format – Option: value, and all of the lines that start with # are treated as commends and excluded. Command line parameters cannot overwrite any of the parameters from the config file since this one has priority. A list of possible commands includes:
- I/O bandwidth limitation – bwlimit: <integer> (0 – N)
- Dump file compression – compress: <0 | 1 | gzip | lzo | zstd>
- Dump results target location – dumpdir: <string>
- Certain file/directory exclusion – exclude-path: <string>
- CFQ ionice priority setting – ionice: <integer> (0 – 8)
- Waiting time for the global lock – lockwait: <integer> (0 – N)
- Notification via mail – mailnotification: <always | failure>
- A list of addresses that should receive notifications – mailto: <string>
- A number of backup files per guest system – maxfiles: <integer> (1 – N)
- Backup type – mode: <snapshot | stop | suspend>
- Used instead of a gzip when N>1 – pigz: <integer>
- A command to backup all of the guest systems in the list – pool: <string>
- Various retention options – prune-backups: [keep-daily=<N>] [,keep-hourly=<N>] [,keep-last=<N>] [,keep-monthly=<N>] [,keep-weekly=<N>] [,keep-yearly=<N>]
- Whether to remove older backup files or not – remove: <boolean>
- Whether to use the specified hook script – script: <string>
- Whether to exclude temporary files and logs or not – stdexcludes: <boolean>
- Maximum waiting time before the guest system is stopped – stopwait: <integer> (0 – N)
- Where to store the resulting file – storage: <string>
- Where to store all of the temp files – tmpdir: <string>
- The number of zstd threads – zstd: <integer>
Proxmox Backup Server
Another variation of the Proxmox built-in solution for backups was released recently, called Proxmox Backup Server. Proxmox Backup Server is a dedicated enterprise-grade server backup software that offers backup and restore capabilities for VMs, containers, and so on.
Aside from being specifically designed to work with Proxmox VE, Proxmox Backup Server offers a variety of features, like incremental backups, data compression, data deduplication, high-end encryption, and more. The implementation language of their choice is Rust, offering a high-quality code base with low resource consumption and high performance.
The installation process of the software is also quick and easy and combined with the intuitive user interface and the integration with the entirety of Proxmox VE, it’s a good choice for most of your Proxmox-related operations.