Proxmox Backup: How to properly back up your virtual machines

Proxmox Backup backs up virtual machines and containers in a Proxmox environment, ensuring they can be fully restored following a failure, misconfiguration, or attack.

In practice, recovery efforts rarely fail due to technical issues. Instead, they fail because the backup is stored on the same server as the virtual machines, the retention period is too short, or no one has ever verified how long a full recovery actually takes. Green status indicators are not proof of a successful recovery.

This article is aimed at technically savvy decision-makers in small and medium-sized enterprises. It outlines the two backup methods available in Proxmox, highlights key considerations regarding storage selection and retention, explains how to protect backups against ransomware, and describes the process of restarting operations on new hardware.

Table of contents

• vzdump, Proxmox Backup Server, or Veeam: The Three Approaches
• What to Clarify Beforehand
• Where Backups Should Go: Storage and Offloading
• Configuring Retention and Cleanup Effectively
• Protecting Backups Against Ransomware
• Restoration: From Individual Cases to New Hardware
• Monitoring and Common Errors
• Conclusion
• Proxmox Backup FAQ

vzdump, Proxmox Backup Server, or Veeam: the three options

Proxmox Virtual Environment (Proxmox VE) is a virtualization platform that enables enterprises to run virtual machines and containers on their own server hardware. There are various methods for backing up Proxmox that differ fundamentally from a technical standpoint.

• vzdump is the built-in tool. With each run, it creates a complete archive of the virtual machine. It is simple, robust, and can be used without any additional systems.
  
  
• Proxmox Backup Server (PBS) is a standalone system. It operates incrementally—transferring only changed data blocks—detects duplicate data to store it only once, and can encrypt backups directly on the source system.
  
  
• Veeam Proxmox Backup, integrating Proxmox VE into the Veeam Data Platform and the new Veeam Software Appliance (VSA)—enables enterprises to efficiently back up workloads running on Proxmox VE. This backup solution simplifies data management by providing detailed insights into Proxmox VE backups. Its user-friendly interface and comprehensive support make Veeam an excellent complement to Proxmox VE.
  

To put this in context: the distinction here is between classic file-based vzdump backups (stored locally or on network targets) and backups made to a Proxmox Backup Server. While job management may appear similar in the Proxmox interface, the underlying storage methods differ significantly.

For environments with few virtual machines and sufficient storage space, vzdump is adequate. However, the difference becomes apparent when backing up multiple machines or requiring longer retention periods: a daily full backup routine over four weeks results in 28 complete copies, whereas an incremental approach covers the same period using only a fraction of that space.

Yet, the most practically significant advantage of PBS is not storage space, but verification: the system automatically checks whether stored backups remain readable and intact. This ensures that any corrupted backup data is detected before it is actually needed.

Proxmox Backup in Practice: Backup Job and Restore

In Proxmox VE, a backup job is typically created by navigating to **Datacenter** > **Backup** > **Add**. Here, you define the target storage, schedule, selection of virtual machines, and retention rules. Crucially, the target storage must not reside on the same host as the production machines.

For the recovery process, at least one test case should be documented: restoring a single file and restoring a virtual machine to a new VM ID, followed by verifying that services, networking, logins, and applications function correctly from the user's perspective. Only then does a successful backup notification become reliable proof of recoverability.

When a comprehensive backup solution makes sense

Both methods back up only Proxmox. If you also operate other systems—such as Windows servers on a different virtualization platform, physical machines, or Microsoft 365—you end up with multiple, separate backup environments, each with its own monitoring and recovery procedures.

In such mixed environments, a cross-vendor backup solution like Veeam may be more practical if you want to centrally monitor and restore Proxmox alongside other servers, physical machines, or Microsoft 365. The advantage lies in unified management, monitoring, and reporting across all systems, rather than in the backup of Proxmox itself.

The decision is therefore less technical than operational: How many different backup systems do you want to—and can you—manage in the long term?

What needs to be clarified before the technical implementation

Before every tool decision is made, there are two questions that must be answered for each virtual machine:

1. How much work can we lose? A machine with ongoing bookings can't take a day. A test system can last for a week. This results in the backup frequency.
2. How long should the recovery take? A server, without which no one can work, needs a faster process than an archive system. This results in the storage location and connection.

These two values ​​determine costs and effort more than any product decision. They should be recorded for each machine - a simple table is sufficient.

Additionally to clarify: What happens outside the virtual machines? The Proxmox configuration itself, i.e. cluster information, network settings and firewall rules, is not in the VM backups. Without it, rebuilding a host takes significantly longer than necessary.

The article on cloud backup deals with how these questions fit into an overall concept.

Where the backup belongs: Storage and offloading

The most important rule is also the one most frequently broken: backups must not be stored in the same location as production data.

A backup stored on the local storage of the same host will not survive a hardware failure or an attack that compromises that host. It only protects against accidental deletion within a virtual machine.

Typical storage locations and their suitability:

• On-premises network storage: a solid standard for daily backups, offering fast recovery. Crucially, the share must not be accessible using the same credentials as the production system.
• Dedicated backup server: the recommended approach for PBS—ideally using dedicated hardware located in a separate fire compartment.
• Rotating external storage media: simple and effective, provided the rotation actually takes place. In practice, this is often the weakest link, as it relies on human action.
• Off-site storage: the only safeguard against fire, water damage, or theft at the primary site.

At least one copy must be stored off-site. This could be a secondary location, a partner’s backup server, or a cloud destination. It is vital that this copy is not permanently connected to the same network or accessible via the same credentials.

The article on cloud backup explains what off-site cloud storage looks like in practice. For multi-host environments, resilience is also a key factor—see the article on Proxmox clusters for details.

For small and medium-sized enterprises (SMEs) without a dedicated server team, ongoing maintenance is often the biggest hurdle: Are backups actually running? Are errors being detected? FIGULI CONSULTING plans and manages Proxmox environments—including backup systems—for SMEs; we monitor backup jobs and regularly verify that machines can indeed be restored.

Evaluate Proxmox backup solutions with FIGULI

Configure retention and cleanup settings appropriately.

The retention policy determines how far back you can go—and also the storage requirements.

A proven pattern for standard operations:

The specific values ​​depend on the requirements. More important than the exact figures is the underlying principle: the retention period must exceed the time it realistically takes to discover a problem.

This applies particularly to insidious errors. If database corruption is only detected after three weeks, fourteen daily backups are useless—they all already contain the error. That is precisely why weekly and monthly backups exist.

With PBS, the cleanup process involves a second step: after removing old backup points, the storage space must actually be freed up by running a cleanup job. If this job is not executed regularly, storage consumption continues to rise despite correct retention rules — a common reason for backup storage filling up.

Schedule backup and cleanup jobs at different times so they do not slow each other down.

Configure retention and cleanup settings appropriately.

Attackers specifically search for accessible backups and delete them before encrypting them. For Proxmox environments this means three concrete measures:

• Separate credentials. The account with which the host accesses the backup storage must only be allowed to write and read what is necessary - in particular, no deletion rights to existing backups. With PBS, this can be done using your own users with limited rights for each data storage.

• Unchangeable or separate copy. At least one backup must be stored in such a way that it cannot be deleted on the productive system even with full administrator rights - for example on a target with a write protection function or on a data medium that is physically separated after the run.
  The official functions of the Proxmox Backup Server include, among others, access control, integrity checking and external backups via remote synchronization or tape backup.

• Encryption. PBS can encrypt backups already on the source system. This protects the outsourced copy, but shifts the responsibility to the key management: without the key, the backup is worthless. The key belongs in a safe place outside the secured environment - not on the server it is intended to secure.

The overall context is described in the article on ransomware protection.

Restoration: from individual cases to new hardware

The three cases of restoration

• Individual file. The most common scenario in day-to-day operations. With PBS, you can search the contents of a backup directly and extract a single file without restoring the entire machine. With vzdump, the archive must be mounted to do this.
• Complete virtual machine. Restoring to the same host or a different one. Important: restore to a new machine ID rather than overwriting the existing one until success is confirmed. This ensures the old state is preserved just in case.
• Entire host after hardware failure. The most complex scenario—and the only one that hardly anyone tests.

Restart on new hardware

For SMEs in particular, this is a key advantage of Proxmox virtualization: virtual machines can be backed up independently of specific hardware and restored on new hardware. This makes hardware migration more predictable, provided that backups, host configuration, storage connectivity, and restore tests have been properly prepared.

If a host fails completely, the recovery process follows this sequence:

1. Install Proxmox VE on the new hardware
2. Configure network and storage connectivity
3. Mount the backup storage as a data source
4. Restore virtual machines based on priority—starting with those essential for operations
5. Check network settings and firewall rules
6. Test functionality from the user's perspective, not just the startup process

This is precisely where a saved host configuration pays off. Without it, steps 2 and 5 become a process of reconstruction based on memory.

One frequently overlooked point: the recovery process is limited by the read performance of the backup storage and the network connection.

Restoring several terabytes over a slow connection can take days. That is precisely why the recovery process needs to be measured at least once — the actual duration often differs significantly from estimates.

Monitoring and typical errors

A backup system whose notifications go unread is an unsecured system. What is required is: error notifications sent to an address that is actually monitored, regular verification of stored backups, and monitoring of storage utilization before capacity is reached.

Common errors encountered in practice:

• The backup resides on the same host as the virtual machines
• There is no off-site copy
• The cleanup process is not executed, causing storage to fill up unnoticed
• Error notifications are sent to an unmonitored mailbox
• The encryption key is stored on the system being backed up
• The host configuration is not backed up
• Recovery has never been fully tested

The last point encompasses all the others: a test would have revealed every one of these errors. A sensible schedule involves restoring a single file monthly and a full machine annually—with a log documenting the duration and outcome.

Conclusion

A robust Proxmox backup strategy rests on four pillars: a backup destination separate from the production host; a retention policy that extends beyond the time it takes to detect a problem; backups that an attacker cannot delete; and a regularly tested recovery process.

When it comes to choosing tools, *vzdump* suffices for small environments with few machines. However, as soon as multiple virtual machines require backup or longer retention periods are needed, Proxmox Backup Server or Veeam demonstrate their strengths—particularly through incremental backups and built-in verification of stored backup states. In mixed environments involving other platforms, a cross-platform solution may be the better operational choice.

The crucial point remains the same as with any data backup strategy: it is not the question "Do we have a backup?" that matters, but rather "How long will it take us to get back to work?"—and the only way to know that answer is to have measured it.

FIGULI CONSULTING helps SMEs reliably plan, operate, and secure their Proxmox environments by implementing appropriate backup strategies, sound retention policies, off-site storage, monitoring, and regularly tested recovery procedures. This ensures that Proxmox backup is not merely a technical setup, but a reliable component of IT operations.

Discuss your Proxmox environment with FIGULI

FAQ Proxmox Backup

What is the difference between vzdump and Proxmox Backup Server?

vzdump is integrated into Proxmox VE and creates a full backup every time it runs. Proxmox Backup Server is a standalone system that performs incremental backups, uses deduplication (storing duplicate data only once), can verify backups, and enables encryption on the source system.

Where should Proxmox backups be stored?

Never on the same host as the virtual machines. Suitable options include network storage or a dedicated backup server, ideally located in a separate fire compartment. At least one copy should be kept off-site, without a permanent connection to the same network and using separate access credentials.

How often should virtual machines be backed up?

This depends on how much work would need to be redone in the event of a failure. A daily backup suffices for many systems. Machines processing ongoing transactions or experiencing high rates of change require multiple backups per day, whereas test systems need far fewer.

How long should backups be retained?

A tiered approach has proven effective: daily backups for one to two weeks, weekly backups for four to six weeks, and monthly backups for six to twelve months. The crucial factor is that the retention period exceeds the time it takes to detect a latent issue.

How can Proxmox backups be protected against ransomware?

By using separate access credentials that do not grant permission to delete existing backups, maintaining at least one immutable or physically isolated copy, and using encryption with a key stored outside the backed-up environment.

Why does storage fill up despite retention rules?

With Proxmox Backup Server, deleting old backup snapshots does not immediately free up storage space; a subsequent cleanup process is required to release it. If this process is not run regularly, storage usage continues to grow despite correctly configured retention settings.

How do I restore an entire host after a failure?

Install Proxmox VE on new hardware, configure networking and storage, mount the backup storage, and restore virtual machines based on priority. A backed-up host configuration is a prerequisite; otherwise, network and firewall settings will need to be reconstructed.

How do I properly test a Proxmox backup?

A Proxmox backup should not be verified solely based on a successful status notification. Conducting regular restore tests is advisable: restore individual files, restore a virtual machine to a new VM ID, and then verify services, networking, login functionality, and applications from a user's perspective. The results should be documented, noting the duration and any anomalies.