An untested backup is not a backup. Cloud-PBS does it for you.

Every backup dashboard is green until the day you need it. The job ran, the size looks right, the retention is healthy, and everyone moves on. Then a VM dies, you launch the restore, and the backup does not boot: no bootloader, a broken filesystem, and so on. The backup exists but cannot be restored, and the green checkmark is worth nothing.

This is the uncomfortable situation at the centre of most backup strategies: a successful backup job proves that data was written, not that it can be brought back to life. Those are two different claims, and only one of them matters during an incident.

What a “successful” backup actually proves

When Proxmox Backup Server finishes a job and reports success, it tells you the chunks were transferred, the index was written, and the server stored what it was sent. PBS even goes further than most systems and lets you run a verification job, which re-reads the stored chunks and compares them against their hashes. That catches silent storage corruption, which is genuinely valuable.

But verification checks the integrity of the backup as it is stored. It does not test whether the backup can actually be restored and made functional. A backup can be perfectly intact and still fail to restore, because restorability depends on things the backup job never looks at:

• the guest’s bootloader and filesystem survived the backup and restore round-trip,
• the target host has the storage type, CPU instructions and machine type the guest expects,
• for encrypted datastores, the restoring host holds the right key.

None of that is visible from a job log. The only way to know is to actually restore and boot the machine.

Why almost nobody tests restores

It is not unusual to meet teams and ask whether they test their restores. The answer is usually an honest, slightly guilty “not as often as we should”. The reason is not negligence, it is cost. A real restore test means finding spare compute, restoring a full VM onto it, booting it in isolation so it does not fight the production machine for an IP or a name, running the restore, cleaning everything up, and finally producing the report. Doing that by hand for one VM can take a lot of person-hours. Doing it for a fleet, on a schedule, is a project nobody has time for.

So it does not happen. The restore is tested for the first time during the incident, which is exactly the wrong moment to discover that it does not work.

What restore validation actually requires

Proper validation is not “can I download the backup”. It is a sequence:

1. Restore the VM or container from a specific snapshot onto real hardware.
2. Boot the machine in a dedicated environment.
3. Confirm that it actually boots, not just that the hypervisor started the process.
4. Capture proof that survives the test: something you can show an auditor, an insurer or your management months later.

Step 4 is the one people forget: a restore test that leaves no trace is a personal reassurance, not a control. If you cannot produce, on demand, evidence that VM-100 booted from its 2 a.m. backup on a given date, then for compliance purposes the test never happened.

How Cloud-PBS proves it

This is the part of managed backup nobody else does. Cloud-PBS is, as far as we know, the only managed backup service for Proxmox that validates restorability end to end and hands you the proof.

From the dashboard, you pick a backup and launch a restore test. We allocate the resources, restore the VM or container from that exact snapshot, and boot it. Then we capture what happened:

• a screenshot of the booted machine,
• the boot log,
• a signed PDF report tying it all together: which datastore, which snapshot, the outcome, the timestamps, and a cryptographic signature so the report cannot be altered later.

When the test finishes, we tear the whole thing down automatically. No leftover machine, no cleanup on your side. What you keep is the proof: a dated, signed artifact showing that this specific backup, on this specific day, restored and booted. That is the document you want in your hand during an audit, a cyber-insurance renewal, or a real disaster.

Restorability is the only backup metric that matters

Let us be blunt. Storage used, job success rate, retention depth: that is operational hygiene, not an outcome. The only question a backup strategy has to answer is “when I need this back, will it work”.

Restore validation is how you turn that question from a hope into a fact, and repeat it regularly so the answer stays true as your infrastructure changes underneath it. If you run Proxmox and your backups have never been tested, you do not actually know whether they work. You know a file exists.

Cloud-PBS is built to close that gap: Restore Verification is built into your instance, and the 7-day free trial lets you prove a restore on your own workload before you commit to anything.