A backup that verifies is a backup you can trust. A backup you have never verified is a hope. This article explains what macup’s integrity check actually does, when it runs automatically, how to force one manually, and what to do if it finds something.
What verification actually checks
Every chunk of data macup writes to a destination has a cryptographic hash — SHA-256 — calculated at snapshot time and stored alongside the chunk. Verification re-reads chunks from the destination, recomputes the hash, and compares.
If the hashes match, the chunk is byte-exact with what was written. If they don’t match, something has changed since the snapshot — bit rot on a drive, a storage provider returning the wrong bytes, a network flip that corrupted a chunk in transit, a faulty cable. Verification is how you catch silent corruption before it becomes a restore that doesn’t work.
Because macup deduplicates, most chunks are referenced by many snapshots. A single verification pass covers the whole backup history, not just the latest snapshot.
Automatic verification
macup runs verification on every destination once a month, by default. The schedule is staggered per destination and runs in low-traffic hours so it does not interfere with active backups or your working day.
Results are logged under macup > Preferences > Destinations > [destination] > Health. You can see the last verification date, the scope, the number of chunks checked, and the result. If anything fails, the destination shows a warning badge in the main window.
Step 1 — Force a manual verify
Open macup. Open Preferences, click Destinations, select the destination you want to verify. Click Verify now.
Useful moments to force a manual verify:
- Before decommissioning a destination (selling the drive, closing the cloud account).
- After a suspected infrastructure incident (drive dropout, ISP event, cloud provider status notice).
- Before a major restore, when you want confirmation the source is healthy.
- On a schedule stricter than monthly, for high-value archives.
Step 2 — Pick the scope
Two scope options.
Sampled (default)
Verifies a statistically significant random subset of chunks. Runs in minutes, not hours. Good enough to catch systemic corruption — if the destination has a problem, it almost certainly shows up in a sampled pass.
Full
Verifies every chunk. Takes hours for multi-terabyte destinations. Worth running before decommissioning a destination, or after an incident where you want zero doubt.
Step 3 — Wait
A progress bar shows chunks checked versus total. Verification runs in parallel across your CPU cores and is bounded by I/O — disk read speed for local destinations, network throughput for cloud.
You can use the Mac normally during a verify. You can pause it (⌘ + . or the Pause button) and resume later; macup picks up where it stopped.
Step 4 — Read the result
Clean result:
No corruption detected across 1,247,318 chunks.
Corrupt result:
3 chunks failed verification across 2 snapshots. Affected files listed below.
The list shows each affected file and the snapshots it appears in. macup flags these files for re-snapshot on the next backup run, which writes fresh chunks in a new snapshot.
What to do if verify finds corruption
Do not panic.
Step 1 — Understand the blast radius
Corruption in one chunk does not mean one snapshot is gone. Dedup means the same chunk is referenced by many snapshots, and macup stores redundancy on cloud destinations. A handful of bad chunks typically affect a handful of files, not the whole backup.
Step 2 — Re-snapshot the affected source files
If the source files still exist on your Mac and are healthy, just trigger a fresh backup. macup writes new chunks for the affected files, and the new snapshot is clean. The old corrupt chunks stay flagged; macup stops referencing them in new snapshots.
Step 3 — Treat wide corruption as a destination fault
If verify flags many chunks spread across many files, the destination itself is suspect — a dying drive, a storage-provider incident, a corrupt filesystem. Treat that destination as compromised. Restore any current needs from a different destination, then retire the suspect one and replace it.
This is exactly why the macup recommendation is two destinations minimum: one local for speed, one offsite for resilience. Verification catches problems early; redundancy means you have somewhere to turn when it does.
The habit
Glance at the Destinations Health panel once a quarter. If every destination shows a recent clean verify, your backups are doing what they promised. That is the whole point.