Why Proxmox VE backup with Proxmox Backup Server needs a design, not just a schedule
If you run KVM virtual machines and LXC containers on Proxmox VE, the built-in backup tool creates consistent snapshots of running guests, and Proxmox Backup Server adds incremental backups, deduplication and encryption on top of that. Those features make the first backup job easy to set up. What fails in practice is everything around it: how many restore points you keep, where the encryption keys live, whether a copy exists outside the failure domain of your cluster, and whether anyone has ever restored a guest from it. A backup that runs every night is not evidence that you can recover from a failed host, a bad change or a ransomware event.
Retention is the first decision that deserves a written answer. Retention defines how far back you can go when a problem is found late, for example a corrupted application database that nobody noticed for a week. Ask your application owners how far back they would need to recover, then set retention per guest group rather than one value for everything. Confirm with your Proxmox Backup Server documentation how pruning rules apply to each backup group, and check that a prune job does not remove the last good copy of a guest that has been stopped or removed from the cluster.
Key custody is the second decision. Proxmox Backup Server can encrypt backups client-side, which protects data at rest on the backup target. The encryption key is then the single item that decides whether you can restore at all. If the key is stored only on the Proxmox VE node that you are trying to recover, the backups are unusable after a host loss. Decide where the key is escrowed, who can retrieve it, how it is rotated, and how that process is tested before you need it. Treat the key with the same care as the backup data itself.
The backup target is a separate system with its own storage, its own access controls and its own upgrade lifecycle. It needs patching, capacity monitoring and a plan for its own failure, and it should not share credentials or administrative paths with the hypervisors it protects. Proxmox VE supports Proxmox Backup Server as a storage type, so the integration is configured inside Proxmox VE, but that does not make the two systems one unit. Plan an off-site or otherwise isolated copy, define who may delete backups, and confirm that a compromised Proxmox VE administrator account cannot erase the backup history.
Proof of restore closes the loop. Schedule restore tests for representative guests, including at least one VM and one container, and record the time taken, the steps followed and any manual fixes needed. Include a test of restoring from the off-site copy, not only from the local target, and of restoring a guest to an isolated network so that a restored copy does not collide with production. Ask your provider or internal team to document what each test proves and what it does not, and treat a failed restore test as a design finding rather than a one-off error.
Which Proxmox VE backup components you will configure
A Proxmox VE backup with Proxmox Backup Server design depends on several components that each own a different piece of the process. Each card below names one component, what it controls, and what fails when it is set up incorrectly.
Built-in backup tool on each node
Every Proxmox VE node runs the built-in backup tool, which creates consistent snapshots of running virtual machines and containers and sends them to the storage target. Backup jobs run on whichever node hosts the guest, so each node needs network access to Proxmox Backup Server and enough time in the backup window. Check that every node can reach the server, that its clock is synchronized, and that jobs do not overlap on the same storage.
Proxmox Backup Server instance
Proxmox Backup Server is the separate system that receives, deduplicates, encrypts and stores backup data. It is installed on its own host or virtual machine, and its disk layout, memory and network capacity decide how fast backups and verification finish. If this host fails or fills up, no new backups can be written, so confirm its hardware, storage capacity and update path before go-live.
Datastore on Proxmox Backup Server
A datastore is the storage area on Proxmox Backup Server where backup chunks, indexes and snapshots are kept. Retention rules, garbage collection, verification and pruning all act on a specific datastore, so its size and location must match the retention you plan. Confirm with the Proxmox Backup Server documentation for your version which maintenance tasks exist and how often they should run.
Proxmox VE storage entry for the backup server
The storage entry in Proxmox VE is the connection record that points the cluster at a datastore on Proxmox Backup Server. It holds the server address, datastore name, and the credentials used for access, and every backup job selects its target through this entry. A wrong server address, fingerprint or datastore name will cause jobs to fail, so test the entry from each node after you create it.
Backup jobs, schedules and guest selection
Backup jobs define which virtual machines and containers are backed up, when, and to which storage entry. Schedules and guest selection must be planned together, because overlapping jobs or a guest left out after a new VM is created will leave gaps in protection. Review the job list after each change, and include new guests in the selection through a pool or explicit list.
Client-side encryption key
When encryption is enabled, the Proxmox VE client encrypts backup data before it leaves the node, using a key you generate and store. Proxmox Backup Server cannot restore encrypted data without this key, so a lost key means lost backups even when the server is intact. Store copies of the key in at least two secured locations outside the cluster, and test a restore that uses only the stored copy.
Proxmox VE user or API token
The backup connection authenticates to Proxmox Backup Server with a dedicated user or API token that has only the permissions needed to write backups to the datastore. Using a shared administrator account makes access hard to audit and risky to rotate. Create a separate identity with a narrow role, record which datastore it can reach, and confirm the token expiry and rotation process before the first backup runs.
Proxmox VE backup decisions to settle before the first job runs
This table compares the five backup decisions that shape a Proxmox VE and Proxmox Backup Server design, with the people and process cost of each option. Read each row against the restore point and recovery effort your business accepts, since those answers determine the rest of the design. Settle the encryption key process and the second copy destination before the first scheduled job runs, because both are hard to change later without re-running backups.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Backup server placement | Dedicated physical Proxmox Backup Server | Backups must survive a failure of the Proxmox VE cluster hardware, and the team wants backup isolated from guest administration. | Separate hardware to patch, monitor, and power. Needs its own runbook and an on-call owner. |
| Backup server placement | Virtual Proxmox Backup Server on separate hardware | Budget or rack space is limited, but the backup guest must run on a different host from the guests it protects. | Less hardware to manage, but the team must document how the backup guest is restored if its host fails and who has rights to it. |
| Second copy destination | Second Proxmox Backup Server through sync | The business wants a second copy in another site under its own control, with the same tooling on both ends. | Second server to operate, patch, and monitor, plus a sync schedule and a check that sync jobs are succeeding. |
| Second copy destination | Tape | Long retention or an air-gapped copy is required, and the site already runs tape handling. | Recurring media handling, rotation, off-site transport, and periodic restore tests from tape by trained staff. |
| Second copy destination | S3-compatible object storage | The organization accepts an external or separately hosted object store as the off-site target and can manage its access keys. | Recurring storage charges that grow with retention, access key rotation, and a review of who can delete or change objects. |
| Encryption keys | Client-side encryption with keys held by the operations team only | Data confidentiality must not depend on the backup server's administrators. | Key generation, storage, and rotation procedures must be written. Losing the key makes the backups unreadable. |
| Encryption keys | Key escrow with split custody or a sealed copy | Multiple roles must be able to recover backups, for example during staff absence or a site emergency. | Dual custody steps, a recorded process for retrieving and returning escrowed keys, and periodic verification that the escrow copy still works. |
| Backup scope | Per guest jobs | Each workload has different schedules, retention, or owners, and job failures must be traced to a single system. | More jobs to create and review when guests are added or removed. Naming standards and a change step keep them accurate. |
| Backup scope | Per pool or tag based jobs | Many similar guests share one policy, and new guests should be protected automatically when they join a pool or receive a tag. | Fewer jobs to maintain, but the team must enforce tagging discipline, since an untagged guest is silently left out. |
| Schedule and restore point | Frequent incremental runs | The business accepts only a short window of data loss for critical guests. | More job runs to monitor, more verification, and tighter alert handling. Failed runs must be followed up the same day. |
| Schedule and restore point | Less frequent runs with longer retention | The business accepts a larger window of data loss for lower priority guests, and storage cost or staff time is the limiting factor. | Lower monitoring load, but restores may need to recover more changes manually, so the process owner must agree the gap in writing. |
How to build Proxmox VE backup jobs with Proxmox Backup Server, step by step
This sequence takes a Proxmox VE cluster from version checks to a verified backup of a running virtual machine and an LXC container stored in a dedicated Proxmox Backup Server datastore. Each step ends with a check you can record before moving on.
Confirm Proxmox VE and Proxmox Backup Server support status
Before installing anything, the platform owner confirms which Proxmox VE release is current, which Debian release it sits on, and when that Debian release loses security support. Proxmox VE versions are supported at least as long as the matching Debian release has Debian security support, so this check sets the upgrade horizon for the backup design. Check the Proxmox VE FAQ and the press releases for release dates and support status, and confirm the Proxmox Backup Server version you plan to run against the same official sources. The step is done when the versions and their support end dates are written in the project record.
Install and patch Proxmox Backup Server on separate hardware
The backup server is installed on its own host, separate from the Proxmox VE nodes it protects, so a failure or compromise of the hypervisor does not remove the backups. Configure accurate time synchronization on this host, restrict administrative access to named operators and a management network, and apply all available updates before first use. The check is that the server is patched, time-synchronized against a source you control, and reachable only from the networks you have approved.
Create the datastore on the backup server
The platform owner creates a datastore on the Proxmox Backup Server, choosing a disk or path with enough capacity and a filesystem that suits your storage design. Backups are stored in this datastore in deduplicated chunks, so the datastore should sit on storage with its own redundancy and monitoring. Confirm the datastore appears in the server's web interface with the expected capacity and is writable by the service. The step closes when an empty datastore is listed as healthy.
Create a backup-only API token or role
Create a dedicated user or API token on the backup server and grant only the permissions needed to write and prune backups in the target datastore. Avoid reusing administrator credentials, because a leaked Proxmox VE backup credential should not allow reconfiguration of the backup server. Record the token identifier and the role assignment in your access register. The check is a test login or token request that succeeds for datastore backup operations and fails for administrative actions.
Add the backup server as a storage entry in Proxmox VE
In Proxmox VE, add the Proxmox Backup Server as a storage entry of the backup type, using the server address, datastore name, and the API token created in the previous step. Add the storage at cluster level so every node sees the same backup target. Confirm the entry shows as active on all nodes and that the server fingerprint matches the value on the backup server before accepting it. The step is done when each node reports the storage as online.
Create and record the encryption key
Create an encryption key for the backup client and store a copy of it outside the backup infrastructure, in a secure vault your recovery team can reach without the hypervisor. A backup encrypted with a key that is lost cannot be restored, so the key location is a recovery requirement, not an administrative detail. Record where the primary and secondary copies are kept and who can retrieve them. The check is a documented key location and a tested retrieval by a second person.
Define backup jobs with schedules and guest selection
Create backup jobs in Proxmox VE that point at the Proxmox Backup Server storage, select the guests to protect by VM or container ID or by pool, and set the schedule and retention rules your recovery objectives require. Keep job definitions in the cluster configuration so every node enforces the same policy. Confirm that each job appears with the intended guests and schedule and that the next run time matches your plan. The step is done when the job list matches the protection register.
Run a manual backup of a VM and a container and confirm them
Start one manual backup of a running KVM virtual machine and one of an LXC container, both targeting the Proxmox Backup Server storage. The Proxmox VE backup tool creates consistent snapshots of running guests, so the VM should stay powered on during the run. When both tasks finish without errors, open the datastore on the backup server and confirm that a snapshot for each guest is listed with the expected guest ID and time. Treat the job as not complete until both snapshots are visible in the datastore.
How retention and deduplication shape Proxmox Backup Server storage
Retention decides how many restore points survive for each guest, but it does not by itself decide how much disk space the backups consume. In Proxmox Backup Server, each backup is a snapshot that references chunks in a datastore, and deduplication means many snapshots of the same guest share the chunks they have in common. Storage use therefore depends on how much data changes between backups, not simply on the number of restore points you keep. A guest with a small daily change rate can carry a long retention window cheaply, while a database that rewrites much of its disk each night will grow the datastore much faster at the same retention setting.
Pruning and garbage collection are the two operations that return space. Pruning removes snapshots that fall outside the retention rules you have configured for a backup job or namespace. It deletes the snapshot records but does not immediately reclaim the chunks behind them. Garbage collection then scans the datastore, finds chunks that no remaining snapshot references, and removes them. Running pruning without garbage collection can leave space in use even though the snapshot count has dropped, so the two jobs should be scheduled and checked together. Confirm the exact prune and garbage collection job settings, and how they interact in your Proxmox Backup Server version, in the official documentation.
Incremental behavior sets the transfer cost. After the first full backup of a guest, later runs send only the data that has changed since the previous run, and Proxmox Backup Server checks which chunks already exist in the datastore before storing new ones. That keeps network load and backup windows down, but it also means a disk-level problem, such as a corrupted chunk or a long-running job that interrupts a run, affects how later backups behave. Plan the first full run for a realistic window, and do not assume that every later run will be short for every guest.
Encryption can change how data is handled on the client side. When backups are encrypted, the client processes and chunks data before it reaches the server, and the deduplication that works on the stored form of the data must be understood in that light. Key management also becomes part of retention planning, because a backup is only restorable if its encryption key is available. Test how encrypted backups are chunked and stored in a non-production datastore before you set long retention windows for production guests.
Set retention per business requirement, meaning the restore points your recovery objectives, legal holds and audit expectations actually need, and then test the result against real datastore growth. Run the planned schedule for several cycles on a copy of representative guests, record how the datastore size changes after pruning and garbage collection, and compare that trend with your capacity forecast. Ask the team responsible for backups to document the prune and garbage collection settings they chose and the reason for each, so the retention policy can be reviewed when guests or change rates grow.
Proxmox VE backup changes on single nodes, HA clusters and isolated networks
On a single Proxmox VE host, the backup job and the guests it protects share the same hardware. A local backup target protects against a failed guest or a bad change, but it does not protect against losing the host, its disks or the site. The first design change is therefore an off-host backup target, typically a Proxmox Backup Server instance on separate hardware or in a separate location that your team controls. The second change is a documented rebuild path, because without a cluster there is no second node to take over the workload.
- Off-host target first: Send scheduled backups to Proxmox Backup Server on different hardware, not to a second disk in the same chassis.
- Rebuild runbook: Record how to reinstall Proxmox VE, reattach storage, reconnect the backup datastore and restore guests in order.
- Configuration export: Keep copies of host configuration, network settings and storage definitions outside the host so a rebuild does not depend on memory.
- Scheduled restore tests: Restore a sample guest to a scratch host at a fixed interval and record the result.
- Access control: Use separate credentials for the backup server so a compromised hypervisor cannot delete its own backup history.
Before go-live, confirm with your team that the rebuild runbook has been run end to end on spare hardware at least once.
In a cluster with high availability, a guest can restart on a different node after a failure, so a backup job tied to one node can miss guests after they move. Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware, and watchdog-based fencing so a failed node is reset before its guests are recovered elsewhere. Backup design therefore follows the guest, not the host.
- Select by pool or tag: Build backup jobs that include guests by resource pool or tag, so a guest keeps its schedule after an HA move.
- Review coverage after moves: Check that every HA-managed guest appears in at least one backup job after adding nodes or changing HA groups.
- Shared target: Point all nodes at the same Proxmox Backup Server datastore so backups from any node land in one place.
- Quorum awareness: Do not plan backups around a two-node layout for HA, because the platform requirement is at least three nodes for quorum.
- Failover test: Trigger a controlled failover in a test window and confirm that the next scheduled backup for the moved guest completes.
Before go-live, confirm that the backup job selection survives a simulated node loss and that the backup server reachability is tested from every node.
On an isolated or air-gapped network, Proxmox VE and Proxmox Backup Server cannot reach public update or time sources, so the design has to supply those services internally. Backups can still be complete and encrypted, but the copy route off the isolated segment must be planned as deliberately as the backup schedule. Choose an internal sync or offline copy route that matches your approved transfer process, and document who performs it and how it is verified.
- Internal copy route: Replicate the backup datastore to a second internal site or to removable media under your transfer procedure.
- Local time source: Provide an internal time service so backup timestamps and log correlation remain consistent.
- Local package sources: Mirror the Proxmox repositories you approve for use, and confirm which repository your subscription or testing policy allows.
- Key custody: Store backup encryption keys separately from the datastore and record recovery steps for an isolated restore.
- Transfer evidence: Log each sync or media transfer with a checksum or verification result for your change records.
Before go-live, confirm with your security and operations teams which transfer method is approved, and perform one restore using only the offline or internally synced copy.
What drives the effort in a Proxmox VE backup project
This table lists the factors that change the scope of a Proxmox VE backup project, why each one moves the effort, and how to keep it manageable. Read it before you ask for a quote, because most of the variation in effort comes from these drivers rather than from the software itself.
| Driver | Why it changes the effort | How to keep it down |
|---|---|---|
| Number of guests and disk layouts | Each VM and container needs a backup job, a retention rule and a tested restore path. Guests with many disks, large databases or mixed LVM, ZFS and Ceph storage need more job design and more restore variants to test. | Group guests into a small number of backup classes by criticality and disk layout. Standardize disk layouts for new guests and document exceptions. |
| Number of Proxmox VE clusters and sites | Each cluster needs its own backup configuration, storage connection and monitoring. Multiple sites add network paths, off-site copies and separate restore procedures. | Use one Proxmox Backup Server design across clusters where the network allows it, and confirm which sites must hold independent copies. |
| Off-site copy method | Replicating Proxmox Backup Server datastores, syncing to a second server, or using tape or S3 targets each involve different configuration, bandwidth planning and access controls. Confirm which options your target environment supports before choosing. | Pick one off-site method early and confirm the required bandwidth, retention on the remote target and the access model for that copy. |
| Encryption key management and compliance evidence | Backup encryption keys must be generated, stored, backed up and rotated under documented control. Auditors and internal assurance teams usually ask how keys are protected and how key recovery is tested. | Define key custody and recovery roles before go-live, store key copies outside the backup host, and collect job logs and restore records as evidence. |
| Existing backup tools to retire or run in parallel | Running a legacy backup product alongside the new tool means two sets of jobs, licences, alerts and restore runbooks until the legacy copies age out or are kept for archive. | Set a retirement date for each legacy job, keep parallel running only for a defined retention period, and record which system holds each restore point. |
| Restore test scope and frequency | Restore testing is the step most often underestimated. Scope depends on how many guest types, which application checks apply and whether full VM, file-level or bare-metal recovery is tested. | Start with a representative sample across guest types, script repeatable checks, and agree the test frequency and sign-off in writing. |
| Skills available in-house | Staff familiar with Linux, ZFS or Ceph, Proxmox VE administration and Proxmox Backup Server can build and run jobs with less outside help. Gaps in these skills add training, review time and longer handover. | Assign named owners before the project, include operators in restore tests, and agree what the partner documents and hands over. |
Protecting Proxmox VE backup encryption keys and backup access
Backups protect against failures, but they also become a target. The controls below keep encryption keys and backup data out of reach of anyone who compromises the production hypervisor, and they make sure a restore is still possible after an incident.
Store encryption keys outside the protected systems
Proxmox Backup Server can encrypt backups with a client-side key, and that key must not live only on the Proxmox VE host it protects. Keep a copy in a separate custody location such as a password manager vault or sealed offline storage, and record who generated it, who holds each copy, and how access is granted and revoked. Test that a restore works using only the external copy before go-live.
Restrict read and delete rights with least-privilege roles
Create dedicated backup users and API tokens for each Proxmox VE cluster rather than reusing administrator accounts. Grant only the datastore and backup permissions each job needs, and separate the rights to read or restore backups from the rights to prune or delete them. Review role assignments and token scopes on a fixed schedule and document the owner of each token.
Block deletion of recent backups from the host
A compromised Proxmox VE host with write access to its backup target can remove the very copies needed for recovery. Limit delete and prune rights on the backup side so the production host can create backups but cannot erase them, and use retention settings on the server that the host cannot override. Confirm the exact permission model and retention behavior in the Proxmox Backup Server documentation before relying on it.
Separate the backup management interface from guests
Place the Proxmox Backup Server web interface and API on a management network reachable only from administrator workstations and the Proxmox VE nodes that write backups. Keep guest networks and general user networks away from that segment, and apply firewall rules that permit only the required ports between them. Document each allowed flow so that reviewers can check it against the network diagram.
Enforce two-factor authentication for backup administrators
Proxmox VE supports TOTP, WebAuthn, YubiKey OTP and recovery keys as second factors through its user management system. Confirm which of these methods Proxmox Backup Server supports for its administrators in its documentation, and enable the strongest supported option for every administrator account. Store recovery keys with the same custody controls as encryption keys, and check how the chosen realm handles second factors.
Keep both platforms patched
Proxmox VE and Proxmox Backup Server each receive their own updates, and a backup server that falls behind can leave the backup chain exposed even when the hypervisors are current. Track security updates for both products, apply them on a defined maintenance cadence, and check that the enterprise or no-subscription repository in use delivers them. Verify the installed versions after each change and record the results.
How to prove a Proxmox VE backup restores before you need it
A Proxmox VE backup is only a recovery plan once someone has restored a guest from it, checked that the guest works, and written down how long it took. Until then, a successful backup job shows that data was written, not that a virtual machine or container can be brought back in a usable state. Treat the restore test as a deliverable of the backup design, with its own owner, schedule and evidence, rather than an occasional check someone performs when there is time.
Start with a restore test plan that covers both guest types. Restore one KVM virtual machine and one LXC container from Proxmox Backup Server into an isolated network segment, so that restored services cannot reach production systems, address conflicts or send messages to real users. Boot each guest, then check application function (log in, run a representative transaction, confirm dependent services respond) and data integrity (compare record counts, checksums or application-level consistency checks against the source). Record the elapsed time from restore request to a usable service, and list every manual step, including any credential, network or driver change that was needed. Those manual steps are often the most valuable output of the test.
Cover the failure scenarios that a single-node restore does not exercise. Restore a guest to a different Proxmox VE node to confirm that storage, network bridges and VLAN settings are not tied to the original host. Then simulate the loss of a Proxmox VE host, for example by restoring the guest onto a node that has never run it and by rebuilding the host configuration from documentation rather than from the failed machine. Confirm that the encryption key used by Proxmox Backup Server is available to the restoring team, stored outside the backup target, and actually decrypts a restore. A key that exists but has never been tested is a common cause of failed recovery.
Use verification jobs where Proxmox Backup Server supports them, and review their results on a fixed schedule. Verification checks that stored backup data is readable and intact, which complements a full restore test but does not replace it, because it does not boot the guest or check application behavior. Confirm with your Proxmox Backup Server version and documentation which verification options are available and how failures are reported, then assign someone to review the results and open a ticket when a snapshot fails.
How often you run these tests, and how much of the estate each test covers, should follow the recovery time and recovery point objectives set by the business for each system. A tier with a short recovery time objective needs more frequent and more complete testing than a development environment that can wait days. Write every test result into a runbook: the date, the backup snapshot used, the target node, the isolated network, elapsed time, manual steps, checks passed or failed, and the actions taken. Those records show whether restores meet the targets and become the starting point for the next test.
What to monitor and document for Proxmox VE backup after go-live
Backup reliability depends on routine checks that teams often set up once and then neglect. The six items below cover job health, storage headroom, version support, key custody, documentation and change control for Proxmox VE backup with Proxmox Backup Server. Each item needs a named owner and a fixed review cadence.
Backup job results and missed runs
A backup job that fails usually reports an error, but a job that never starts may report nothing at all. Alert on failed tasks and also on the absence of a successful backup for each guest within the window set by your recovery objectives. After go-live, check the task history in the Proxmox VE web interface, confirm where job notifications are delivered, and test that a missed run reaches someone who can act on it.
Datastore capacity and garbage collection
Proxmox Backup Server keeps backups in datastores, and deduplicated chunks are only freed when prune jobs run and garbage collection completes. Track free space on each datastore and the growth trend of incremental backups, because a full datastore stops new backups. Review garbage collection results after each run to confirm expired chunks are being reclaimed, and set capacity alerts early enough to add storage before it is needed.
Update tracking and support end dates
Schedule a recurring review of Proxmox VE and Proxmox Backup Server releases, including release notes and the support statements in the official Proxmox VE FAQ. The FAQ states that a Proxmox VE version is supported at least as long as its matching Debian release has Debian security support. For example, Proxmox VE 8 on Debian 12 reached end of life in August 2026, so record the end-of-life dates that apply to each version you run and plan around them.
Encryption key custody and access reviews
Backups encrypted with a Proxmox Backup Server key cannot be restored without that key, so key location belongs in the recovery plan. Record where each encryption key is stored, who holds a copy, and how it is recovered if the backup server is lost. Review access lists for datastores, users and API tokens on a fixed schedule, and remove backup rights from accounts that no longer need them.
Job inventory, runbook and test records
Keep a current inventory of every backup job, including the guests and storage it covers, its schedule and its retention settings. Pair it with a restore runbook that gives step-by-step restore paths for virtual machines and containers, the recovery contacts for each system, and dated results of restore tests. A runbook that has not been exercised on your own hardware is an assumption, so record who ran each test and what was restored.
Backup server upgrade as a separate change
Plan each Proxmox Backup Server upgrade as its own change with a written rollback path and a verified test restore afterward. Confirm compatibility with your Proxmox VE hosts, take a current copy of the server configuration, and check that backups still complete before closing the change. Major Proxmox VE release upgrades, such as moving from version 8 to 9, are covered in the separate Proxmox VE upgrades and support topic.
Proxmox VE backup questions buyers ask before hiring help
What drives the cost of setting up Proxmox VE backup with Proxmox Backup Server?
The cost is driven by how many guests and how much data you protect, how many sites and storage targets are involved, and how much of the design is new to your team. The one-time work covers sizing the backup server and datastore, designing schedules and retention, configuring encryption and off-site copies, and writing restore runbooks. Recurring costs include storage capacity growth, the Proxmox Backup Server subscription if you choose one, and periodic restore testing and updates. Ask any partner for a written quote that separates one-time implementation from recurring operations, and check whether the Proxmox VE subscription tier you pick affects which repository your backup server receives updates from. Proxmox VE subscriptions are priced per CPU socket per year, so confirm which hosts and sockets the quote assumes.
How long does a Proxmox VE backup project take?
Duration depends on the number of hosts and guests, the storage you already have, the number of retention policies and off-site targets, and how quickly your team can approve a test window. Fixed-scope engagements agree the timeline in writing before work starts, so ask for the timeline tied to named deliverables rather than a generic estimate. Restore testing usually takes the largest share of time because each guest class must be restored and checked, and a failed test adds rework. Ask the partner to list the assumptions behind the schedule, including how many restore rounds are included and what happens if a dependency such as network access is late.
What do we need to provide before a backup engagement starts?
The partner needs administrative access to the Proxmox VE cluster and to the Proxmox Backup Server host, plus network paths between them and to any off-site or tape target. You should also provide a test window where backups and restores can run without affecting production, and a dedicated restore target with enough free capacity to bring back your largest guest. Name an owner for each area: a backup administrator, a storage or network contact, an application owner who signs off restored systems, and a security contact who approves encryption and key custody. Ask the partner to confirm this list against your environment in the scoping stage, because missing access is one of the most common causes of delay.
Can a team with Linux skills set up Proxmox VE backup on its own?
Yes, a team with solid Linux and storage skills can build a working Proxmox VE backup setup using the built-in backup tool and Proxmox Backup Server, and the software is available without a subscription. The risk sits in the parts that are easy to get wrong and hard to notice: retention rules that delete more than intended, backups that complete but cannot be restored, encryption keys that are not recoverable, and off-site copies that were never tested. Proxmox VE's no-subscription repository is described for testing and non-production use, while the enterprise repository is the recommended choice for production, so plan how your team will receive updates. A useful check is whether your team has already performed a full restore of a production-like guest from the backup server and documented the result.
How should Proxmox Backup Server encryption keys be handled, and who should hold them?
Store encryption keys separately from the backup server and the data it protects, and keep at least two controlled copies with different custodians so a single loss does not make backups unreadable. Proxmox Backup Server supports client-side encryption, which means the key is needed at restore time, so a backup without its key is effectively lost. A sound pattern is to have the infrastructure lead and the security lead each hold an escrowed copy, with access logged and recorded in a recovery procedure. Test that the key can be retrieved and used in a restore exercise, not only that it exists. Your security policy should decide custody, rotation and emergency access, and the partner should document those decisions rather than set them alone.
Does DeployOpen issue audit reports for our Proxmox VE backup controls?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can prepare the backup controls, configuration records, restore test evidence and runbooks that an assessment will examine, so your auditor has clear material to review. Independent auditors or certification bodies make the assessment and issue any report. Before engaging, confirm with your auditor which evidence they expect, such as schedule configuration, retention settings, access reviews, key custody records and dated restore test results, and ask the partner to map deliverables to those requests in the written scope.
How DeployOpen scopes and hands over Proxmox VE backup work
DeployOpen designs Proxmox VE backup around the guests, retention rules and recovery targets you set, then builds it with Proxmox Backup Server inside your own infrastructure. Each phase ends with written deliverables, restore evidence and a runbook your team can operate without us.
How we scope
- The written scope lists which clusters, nodes, VMs and LXC containers are covered by backup jobs.
- Schedules, retention periods and off-site copy targets are agreed and recorded before any build work starts.
- Encryption key handling and who holds recovery credentials are defined in the scope, not left to the build phase.
How we build
- Proxmox Backup Server datastores are sized and configured on dedicated hardware or storage you provide.
- Backup jobs are created with consistent snapshot settings for running VMs and containers and tested against each node.
- Deduplication, incremental behavior and off-site replication are verified with real job logs and storage reports.
How we hand over
- You receive a documented runbook covering job definitions, retention rules, key custody and escalation contacts.
- Restore tests are run for representative VMs and containers, and the results are delivered as written evidence.
- Your administrators are walked through daily checks, failed-job handling and how to request a full restore.
How we support
- Ongoing support, periodic restore testing and upgrades are available as a retainer after handover.
- Confirm with Proxmox Server Solutions which subscription tier matches your support and repository needs, since that is separate from our work.
- Backup policy reviews are scheduled when guests, storage or retention requirements change, with changes handled through a new written scope.
