Learn Proxmox Backup Server - Verify & Integrity Check

#Introduction

Retention in episode 8 keeps storage lean — but there is a subtler threat: data that silently corrupts. Bit rot on disks, bad sectors, or chunk corruption can make snapshots unrestorable, and you only feel the problem when you need it most. Episode 9 covers verify & integrity check: how PBS ensures what is stored is still exactly what was sent.

Imagine it like a periodic warehouse audit: the staff opens every box, recounts the contents, and matches them against the list. Boxes with missing or damaged contents are flagged immediately — before the goods are actually shipped to the customer (restore).

#Verify: Validating Chunks

#The Verify Job Concept

Every PBS chunk has a checksum computed when it is written. A verify job re-reads each chunk from the datastore, recomputes its checksum, and matches it against the stored value. A match means the chunk is intact; a mismatch means corruption is detected and reported.

Verify differs from "seeing whether a file exists" — it actually reads the data from disk, so it catches bit rot and bad sectors that ls cannot see. For encrypted snapshots, verify validates chunk integrity without being able to read the contents (the server has no key — consistent with episode 7).

#Scheduling Verify

Create a verify job so it runs periodically — a healthy routine is monthly verification of the entire datastore:

Create a monthly verify job

proxmox-backup-manager verify job create \
  --datastore store1 --schedule "sun 04:00"

View verify jobs

proxmox-backup-manager verify job list

Large datastores take a long time for a full verify. A common strategy: verify-new for new snapshots plus periodic verify for old ones.

#Verify --verify-new for New Snapshots

The --verify-new option verifies a snapshot immediately after it is created — ideal for catching corruption in newly ingested data (e.g. RAM issues, full disk during writes, or flaky connections):

Verify new snapshots in a job

proxmox-backup-manager verify job update <id> --verify-new

In episode 3 we already enabled --verify-new when creating the datastore. The combination of --verify-new (immediate) + monthly verify (thorough) gives a double layer: new data is checked fast, old data is checked thoroughly.

Tip

Verify reads all data — it is a "disk read" exercise that can also reveal disk health earlier than smartctl in some cases. Do not forget to schedule verify on the remote PBS server receiving sync results too; synced snapshots need the same integrity assurance.

#Datastore Audit & Integrity

#Manual Verification and Snapshot Status

To verify a specific snapshot from a client:

Verify one snapshot via the client

proxmox-backup-client verify \
  --repository backup@pbs@10.0.1.10:store1 \
  vm/100/2026-08-13T02:00:04Z

Verify status can also be seen from the web UI: Datastore → select a snapshot shows the last verification status. Snapshots never verified are clearly flagged — a soft alarm to schedule verify soon.

#Reading the Task Log

Every PBS operation (backup, verify, GC, sync, prune) is recorded as a task with a detailed log. In the web UI: Administration → Task Log. The verify log shows which chunks were verified and any errors found:

View the task log from the CLI

proxmox-backup-manager task list --since '1 hour ago'
proxmox-backup-manager task log <upid>

proxmox-backup-manager task log opens the details of a single task. Make auditing the task log a routine: a verify failure left unaddressed is technical debt that will one day be paid with data.

#Datastore Integrity Checks

PBS provides a direct integrity check on the server side:

Verify the entire datastore from the server

proxmox-backup-manager datastore verify store1

This command verifies all snapshots in the datastore and reports the result per snapshot. Run it periodically in a maintenance window — and if you find corruption, immediately compare with the remote sync result (episode 10): a snapshot also corrupted in two locations indicates corruption from the start, not local hardware damage.

Warning

Verify detects corruption but does not repair it — damaged chunks must be restored from another source (re-backup, or sync from a healthy remote server). Make sure your sync/off-site pipeline (episode 10) works as a data recovery mechanism as well as a backup.

#Closing

Key takeaways:

Verify re-reads and validates every chunk's checksum from disk.
Schedule a monthly verify (proxmox-backup-manager verify job create) in quiet hours.
--verify-new verifies new snapshots immediately after creation.
Verification status is visible per snapshot in the web UI; manual verification via proxmox-backup-client verify.
The task log (web UI or proxmox-backup-manager task log) is the audit source for all operations.
proxmox-backup-manager datastore verify checks the integrity of the entire datastore.
Verify detects, but recovering damaged chunks comes from another source.

In the next episode, episode 10, we will reach across locations: remote sync & off-site backup — creating a sync job that pulls snapshots from the local PBS to a remote PBS encrypted, scheduling it daily, and assembling a 3-2-1 strategy so a disaster in one location does not erase the future of your data!