Proxmox backup verification and restore test checklist

A successful backup job is a useful starting point. A restore exercise checks whether you can recover a selected workload and confirm it does what you need.

Proxmox Backup Server (PBS) has verification jobs that check backup data for integrity. Its official verification guidance recommends reverifying all backups at least monthly, including backups that passed an earlier check. You can configure whether previously verified snapshots are skipped and when they are checked again.

That verification result does not establish that your guest boots or that its application works. Use the checklist below to plan a separate restore exercise. A pass applies to the selected snapshot and checks you actually performed, not every workload or future outage.

1. Choose one workload and write the acceptance checks

Pick a workload you are authorized to test. Record the source guest, the exact backup snapshot and its timestamp. Write a short set of checks before starting:

• The guest boots and the required filesystems mount without errors.
• The main service starts and a representative application task works.
• The expected files or records are present from the selected recovery point.

For example, checking that an expected file is present and can be opened is more useful than stopping at a login prompt. Choose checks appropriate to your workload; these are examples, not evidence that a particular restore has passed.

Record when restoration begins, when the guest boots and when the application is usable. A completed file transfer and a usable application are different milestones.

2. Prepare a separate restore target

Identify a non-production destination with enough capacity and a new, unused scratch VMID. Check for both VM and container ID conflicts before restoring. Record the source and target explicitly so you cannot mistake one for the other.

Plan isolation before starting the guest. A restored workload may retain addresses, credentials and scheduled jobs from the original. It must not duplicate production addresses, send notifications or run jobs against live services. Use a verified isolated network or disconnected interfaces, and check whether any other network path remains.

Follow the documentation for your installed Proxmox VE/PBS versions and workload. If the source, destination or isolation boundary is unclear, resolve that before running the restoration. This checklist does not prescribe a command for every installation.

3. Review the backup and verification evidence

Record the selected snapshot, its verification result and the result timestamp. Check whether backup and verification jobs actually ran when expected. An old successful result needs its date and scope alongside it.

For PBS, review the datastore's Verify Jobs and the selected snapshot's verification status. Plan new-backup checks and periodic reverification to suit the storage and job duration. A verification pass checks backup integrity; application acceptance still belongs to the restore exercise.

4. Restore and check the agreed result

Carry out the authorized restoration using the procedure for your installed versions. Keep the restored guest isolated throughout the acceptance checks. Watch the boot and look for mount errors or failed services, then check the application and data against the conditions you wrote in step 1.

Record failures as well as successes. A guest that boots but cannot complete the representative application task has not met that acceptance condition. If a database check fails, review the application's backup consistency requirements before the next drill rather than assuming a readable disk image is sufficient.

5. Check whether retention covers the recovery point you need

Compare the snapshots actually available with the configured retention policy. Think about how long it could take to discover a bad change or corruption. Restoring the latest snapshot does not show that the older recovery point you might need still exists or works.

Review independent and off-site copies as part of your recovery plan. One successful restore from one datastore gives evidence about that path, not about every backup copy.

6. Keep an evidence record and confirm cleanup

Keep a short record somewhere you can still reach if the tested environment is down:

• Date, workload and exact source snapshot.
• Verification result, timestamp and scope.
• Scratch target and the isolation checks performed.
• Restore, boot and application-ready times.
• Each acceptance check, its result and the evidence supporting it.
• Failures, corrective actions, cleanup status and the next planned drill.

Keep credentials, tokens and sensitive application data out of public screenshots. Agree cleanup before deleting anything. Confirm the exact scratch guest and preserve the evidence you need; do not remove the source guest or backup snapshot as part of scratch cleanup. Rotate workloads over successive drills so the easiest guest is not the only one you ever test.