A backup you don’t know is still readable is not a backup. For that, PBS has verification: a job that recalculates the SHA-256 hashes of all stored chunks and compares them against the target values stored in the manifest. If a chunk silently corrupts on disk (bit rot, hardware defect), verification catches it — before you find out in an emergency that the restore fails.
When verification runs automatically
By default, PBS does no verification — you have to configure it. With us, a default verification policy is active: every snapshot is verified once after creation, then again every 30 days.
You can create your own verify jobs if you want stricter policies.
Creating a verify job in the GUI
- Datastore → <your-datastore> → Verify Jobs
- Click Add
In the dialog:
| Field | Recommendation |
|---|---|
| Schedule | sat 06:00 — every Saturday at 6 a.m. |
| Ignore Verified Snapshots | enabled (saves time when already verified) |
| Outdated After | 30 days (after 30 days, snapshots are re-verified) |
| Worker Threads | 1 (default; more is usually only needed on a central PBS) |
Click Add.
What happens during a verification
PBS reads every chunk file, recalculates the SHA-256 hash and compares it with the hash stored in the backup index. On a mismatch, the snapshot is marked as “Failed”.
A verification is disk-I/O-intensive. On a 1 TB datastore, a full verification often takes several hours. Our datastores run on SAS HDDs in RAID 10 behind hardware RAID controllers — that spreads the read load across multiple disks. We schedule verify jobs on large datastores at night by default.
Verify status in the overview
In Datastore → Content you see a “Verify State” column per snapshot:
- OK — the backup is intact
- Failed — corruption detected
- None — not yet verified
- Outdated — last verification older than the “Outdated After” threshold
The statuses are color-coded (green/red/gray).
What to do when verification fails?
First of all, stay calm — a failed verification doesn’t necessarily mean the backup is unusable. Possible causes:
- Disk bit rot: the data on the HDD really is corrupt. A restore might be impossible.
- Hardware fault: defective RAM, defective controller — a temporarily wrong reading.
- Software bug: extremely rare, but possible.
What we do when a backup fails on our side:
- We check the RAID controller status and the SMART values of the affected disks.
- With many corruptions, we replace the affected disk and restore from the mirror location.
- We contact you if backups in your datastore are affected.
What you can do:
- Manually re-verify the failed snapshot (maybe it was temporary).
- Start a fresh backup job in PVE — most setups have multiple snapshots, and the previous one is usually fine.
- If individual important backups are Failed: open a ticket and we’ll check.
Triggering verification manually
There is no CLI path from your PVE — verify always runs on the PBS itself, and you don’t have shell access there. You can still trigger it manually:
- Single snapshot: Datastore → Content → select snapshot → Verify (the icon in the snapshot row).
- Whole datastore: under Verify Jobs, select the job and click Run now.
- For scripts: via the REST API with an API token, e.g.
POST /api2/json/admin/datastore/<datastore>/verify. The API can do everything the GUI can.
Best practices
- A weekly verify job for datastores is the standard recommendation.
- Outdated After 30 days makes sense — backups shouldn’t go longer than that without a re-check.
- Keep “Ignore Verified Snapshots” enabled: saves considerable CPU/IO.
- Set up notifications: you want a mail immediately when verification fails — see Setting up email notifications.
Frequently asked questions
How long does a verification take? Depends on datastore size and disk performance. On our hardware (SAS HDDs in RAID 10), expect roughly a few hours per TB of backup data — which is why the jobs run at night.
What does “Outdated” mean? Snapshots that haven’t been verified for longer than the threshold configured in the verify job count as Outdated. PBS marks them and the next verify job picks them up again. In practice: old backups get re-checked regularly.
Does verification cost bandwidth? No. Verification runs entirely on the PBS — no data is transferred to you.
Can I disable verification to save performance? In theory yes, but we strongly advise against it. A backup without verification is a bet that the disk stays stable — and in our experience, that goes wrong in 1–2% of cases.
What if I’ve had backups for 6 months and never seen a verification? Open a ticket. We run a default verify job on our infrastructure, but if something’s stuck there, we’ll take a look.
Can I see in the GUI exactly which chunk is corrupt? For a Failed snapshot, the task log shows the exact chunk hash that doesn’t match. With the hash, you can locate the chunk on disk — interesting for deep debugging, but not needed for most recovery scenarios.
What’s next
First login to the Proxmox Backup Server — what you see in the GUI
After ordering, the login mail arrives. Here's an overview of the most important areas of the PBS GUI — datastore, sync, tape, users, notifications.
Setting up the datastore as a backup target in Proxmox VE
Add your xaweho PBS datastore to your Proxmox VE in a few clicks — via GUI or CLI, with fingerprint and login.
Creating an encryption key for PBS and storing it safely
Enable client-side encryption with AES-256-GCM. Generate the key, store it safely and register it in the PBS storage.
Running your first backup to the PBS — step by step
A manual test backup of a single VM to check that the datastore is connected correctly and everything works.