Monitor, verify, and prune: the jobs that keep PBS trustworthy.

Verification: proving your backups are restorable

A verify job re-reads every chunk of a snapshot and re-computes its checksum against the recorded digest. It catches silent corruption — a failing disk sector, a bad cable, memory errors during the original write — while the backup history still contains good copies to fall back on. Discovering corruption during a disaster restore is the worst possible time.

Set it up under Datastore → Verify Jobs. Two options matter: outdated-after re-verifies snapshots whose last verification is older than N days (30 is a sensible default), and ignore-verified skips fresh ones so the job doesn't re-read the whole datastore weekly. Failed snapshots are flagged in the content view, and the next backup run re-uploads any chunks that failed — so a verify failure plus a healthy source usually self-heals on the next cycle.

Verification is I/O-heavy by design: it reads everything it checks. Schedule it away from your backup window — weekends work for most — and see planning backup windows for how these jobs interact.

Prune: enforcing retention

Prune applies your keep-* rules (designed in the retention guide) and removes snapshots that fall outside them. Schedule it under Datastore → Prune & GC — daily is typical, shortly after backups complete. Two behaviors surprise people:

• Prune removes the snapshot's index, not its data. Datastore usage does not drop when prune runs — that's garbage collection's job.
• Snapshots marked protected are skipped entirely, which is exactly why protecting monthly anchors is cheap insurance against a mis-typed keep rule.

Garbage collection — and the 24-hour rule everyone hits

GC walks every index, marks the chunks still referenced, then removes unreferenced chunks. The part that generates support tickets: GC only deletes chunks whose last-access time is older than 24 hours and 5 minutes. This grace window exists so a backup running concurrently with GC can't have its freshly-written chunks swept away. The practical consequence:

# the classic confusion
Day 1, 09:00  prune removes 40 old snapshots   → usage unchanged
Day 1, 10:00  GC runs                           → usage barely moves
Day 2, 10:05  GC runs again                     → 1.8 TiB freed

If you need space back, the sequence is always: prune, wait a day, GC. Not a bug — a safety property. If space still doesn't return after that, something else is holding references; our common errors guide walks the diagnosis.

Monitoring: what to actually watch

Four signals cover nearly everything that goes wrong in practice:

• Task failures. Any failed backup, verify, prune, GC, or sync task. Configure notifications under Configuration → Notifications — email or webhook — and route them somewhere humans look.
• Datastore usage trend. Not just "is it full" but "is the growth rate what my change rate predicts." A sudden slope change means a new workload, a broken prune, or an incident in progress.
• Verify results. A single failed chunk is a disk warning; a pattern of them is a storage subsystem telling you something.
• Last-successful-backup age per guest. The failure mode that hurts most isn't a loud error — it's a VM quietly missing from the job for three months. Check the content view for stale groups, or query the API if you want to alert on it.

On our hosted platform, platform-level health — disks, ZFS pools, capacity — is our job around the clock; the signals above about your jobs remain visible to you in the WebUI on Dedicated plans, and we watch them with you on Shared.