Backups & Storage
Backup restore check
A backup is not trustworthy just because the schedule is green. A small restore check proves the path still works.
Who this is for
Home operators in 2026 running NAS-based backups + cloud backups + local USB rotation across Windows / macOS / NAS / phone clusters, who need to prove recovery works in the LockBit-5.0 / Cl0p / Qilin / Akira / DragonForce era — when 'job shows green' is no longer trustworthy because 2025-vintage ransomware variants explicitly kill backup agents, clear logs, and append random 16-char extensions before encrypting backup metadata.
Outcome
A restore drill against the 3-2-1-1-0 rule (3 copies, 2 media, 1 offsite, 1 immutable/offline, 0 verified errors) that proves alt-location restore on each medium, verifies file content (not just file count), measures restore-speed reality (a 5 TB Wasabi pull at 80-100 Mbps takes ~5 days; Backblaze USB ship-back is often faster), accounts for 2026 cloud pricing traps (Wasabi 90-day minimum retention, AWS Glacier retrieval + egress, Synology C2 → OneStorage migration 22 Jun 2026), and trips the silent-failure modes (OneDrive Files On-Demand stubs masquerading as full files, iCloud 'Optimize Storage' deleting full-res, Synology Snapshot retention pruning the version you wanted, QNAP HBS 3 ACL-but-not-permissions sync bug, TrueNAS Goldeye rsync SSH-keychain bug pre-25.10).
Required inputs
- Full backup inventory: every job per source (Windows File History / Time Machine / Synology Active Backup for Business / Hyper Backup / TrueNAS replication / QNAP HBS 3 / Unraid Duplicati or Kopia / restic / Veeam Community / cloud-only), each destination (local drive / NAS share / B2 / Wasabi / Glacier / iDrive / Synology C2 / Microsoft 365 OneDrive / Backblaze Personal), last successful run, encryption + immutability status, retention policy.
- Harmless test set: one small document, one photo, one folder with several files that are safe to duplicate. Optionally one large file (1-5 GB) to measure restore throughput against actual recovery scenarios.
- Temporary restore landing: a clean folder OUTSIDE the original source path (`Restore-Test-YYYYMMDD/` on desktop or a separate temp drive). Verify the backup app supports 'restore to alternate location' BEFORE starting — File History on Win11 25H2 and Time Machine on Tahoe both expose this but the UI moved.
- Cloud account verification: 2FA available + recovery codes printed, payment method current (lapsed cards silently delete backups after 30-90 days on most providers), 'restore' permission distinct from 'read' permission in IAM roles for B2/S3/Wasabi.
- Restore-speed budget: how long can the household live without the data? 4 TB Wasabi pull at 80-100 Mbps = ~3-4 days. Backblaze Personal USB ship-back: $189 deposit, 8 TB max, ~5-7 days transit but full-bandwidth restore on arrival.
Step-by-step procedure
Set the 3-2-1-1-0 baseline and identify which layer this drill exercises
Do: Map each backup job to the rule: 3 copies of the data (source + 2 backups minimum), 2 media (e.g., NAS + cloud, not 2 cloud), 1 offsite (cloud or USB drive rotated to a different physical location), 1 immutable/offline (Object Lock on B2/Wasabi/S3, or an air-gapped USB drive), 0 verified errors (this drill is the 0). Today's drill should target the layer you trust least — typically the offsite / immutable layer, because local restore is exercised implicitly every time you grab an old file. Document which jobs cover which source folders — irreplaceable data (family photos, financial records, tax archives) should have all five rule layers; convenience data (Steam library, Plex media) only needs the first three.
Expected result: A per-source mapping shows which folders have full 3-2-1-1-0 coverage and which only have partial. Today's drill target is named (e.g., 'Wasabi offsite for /Photos').
If not: If the inventory shows a single backup destination for irreplaceable data, this drill is not the priority — adding the missing layer is. Use the 3-2-1 NAS + cloud + USB guide before drilling restore.
Restore to an alt-location WITHOUT touching the live source
Do: Create `Restore-Test-YYYYMMDD/` on a temp drive or desktop OUTSIDE the original source path. Then per platform: Windows 11 25H2 File History: Control Panel → File History → Restore personal files → navigate dates with arrows → right-click selection → 'Restore to' (NOT 'Restore') → pick the alt folder. The Settings app's 'Accounts → Windows Backup' covers cloud sync only; File History remains in Control Panel. macOS Tahoe Time Machine: Enter Time Machine → Cmd+drag the file/folder out of the Time Machine view to the alt location (drag-out always copies, not move). Tahoe TM backups are only readable by Migration Assistant on Tahoe or later — a downgrade scenario fails. Synology Hyper Backup (DSM 7.3): Hyper Backup → backup task → Restore → 'Restore to a different location' → pick a temp share. Block-level dedup retains up to 65,535 versions. TrueNAS Scale 25.10 Goldeye: Storage → Snapshots → clone the relevant snapshot to a writable dataset, OR use Data Protection → Replication → manual restore. 25.10 fixed the rsync-over-SSH-keychain `UnboundLocalError` bug. QNAP HBS 3 (QTS 5.2.x): Backup Manager → restore job → pick alt destination. Known bug: HBS 3 replicates ACL but not shared-folder permissions; permission-denied on subfolders is the canonical failure mode. Unraid 7.3.0: rclone GUI for cloud destinations (config now persists across reboot — was a 7.x gotcha); Duplicati or Kopia from Community Apps for incremental — see Unraid Docker appdata backup plan. Kopia mount approach: `kopia mount <snapshot-id> /mnt/restore-test/` exposes the snapshot as a read-only filesystem — safer than full extract for verification. Cloud-only: Backblaze B2 web → File Browser → Object Lock indicator → Download; Wasabi Console → Object Browser. For Backblaze Personal, USB restore-drive ship-back is often faster than a multi-TB internet pull. New to the NAS layer? See what is a NAS and do I need one and NAS for home backups.
Expected result: Files appear in the alt-location folder. Original source untouched. Restore log captured (date, source job, file count, byte count, duration).
If not: If 'restore to alternate location' isn't an option in the backup app, do NOT restore in place. Stop and switch to an app that supports it (Veeam Community Edition free up to 10 instances, restic, Kopia, borgmatic) before drilling.
Verify file content — not just file count — and pick a version explicitly
Do: Open EACH restored file: photo viewer for image, document app for document, hash compare for the large file if integrity matters (`certutil -hashfile <path> SHA256` on Windows; `shasum -a 256 <path>` on macOS/Linux). Compare bytes + visible content against the live original. 2025-vintage ransomware variants encrypt backup metadata AFTER the source, so a file that 'opens' but shows garbled content means the backup pipeline was already compromised. Version pick discipline: most apps default to 'latest version' — explicitly drill an OLDER version (yesterday's, last week's) to confirm version retention is real. Synology Snapshot Replication retention: pruning policy can silently overwrite older snapshots; check 'Retention policy' before assuming yesterday's version exists. OneDrive 30-day rollback: 'Restore your OneDrive' rolls back to any point in the last 30 days; recycle bin holds 93 days; Microsoft can still recover 14 days after that. Microsoft 365 Backup (file-level restore from restore points) hit GA late Apr / early May 2026 for tenant-protected scenarios. OneDrive Files On-Demand stub trap: stub files appear as full files in Explorer but are placeholders — a backup tool copying the OneDrive folder grabs stubs not content. Set 'Always keep on this device' on critical folders before backup — and confirm by drilling a restore from a backup that previously stalled mid-sync.
Expected result: Each restored file opens cleanly + content matches the live version (or matches the specifically-requested older version). Version-pick is explicit, not 'latest default'.
If not: If a file opens but content is garbled, the backup pipeline was already compromised when the snapshot was taken. Preserve all backup history (don't auto-prune), isolate the source machine, and check the next-older version. If multiple older versions are garbled, the compromise is older than retention.
Test the immutable / Object Lock layer explicitly
Do: The '1 immutable' in 3-2-1-1-0 is the layer that survives ransomware on the source AND on the backup admin account. Backblaze B2 Object Lock: free with B2, supports Compliance / Governance / Legal Hold modes — Compliance is the strictest (no one, including the account owner, can delete during the retention window). Verify it's enabled on the bucket: B2 web → bucket settings → Object Lock = Enabled, retention rule set. Wasabi Object Lock: same idea, free, supports Governance + Compliance + Legal Hold. AWS S3 Object Lock: free; standard practice for enterprise-grade immutability. Synology Hyper Backup with immutable snapshots: WriteOnce (immutable) backup destinations were added in DSM 7.x. TrueNAS ZFS snapshots with hold: `zfs hold` prevents destruction. Drill the immutable layer: attempt to delete a test object during the Object Lock retention window — the API call should fail. If deletion succeeds, the lock is not enforced and the layer is fake. Air-gapped USB rotation is the operator-grade alternative when budget rules out cloud immutability: 3-drive rotation, one always disconnected and offsite, monthly swap. LTO-9 tape (18 TB native, ~$120-150/cartridge; drives expensive at $5,000+) is power-user-only but provides genuine offline air-gap.
Expected result: Immutability is verified by an attempted-delete failing. Retention window is documented (e.g., '30-day Compliance lock on B2:hometechops-photos').
If not: If no immutability layer exists, the backup plan is exposed to LockBit-class ransomware that targets backup admin accounts. Add Object Lock on the existing cloud destination (free on B2/Wasabi/S3) before the next drill.
Measure restore-speed against the actual recovery scenario
Do: Restore speed reality: download a 5-10 GB test file from the cloud destination and time it. Wasabi: typical home pull 15-40 Mbps (80-100 Mbps optimistic by region — us-east-1 is fastest from the US East Coast); a 1 TB recovery = 24-72 hours. Backblaze B2 via Cloudflare R2 / Bandwidth Alliance: free egress, ~100-300 Mbps; a 1 TB recovery = 8-24 hours. AWS Glacier Deep Archive: 12-hour Standard retrieval minimum; Expedited retrieval costs ~$0.025/GB; 10 TB restore = $200 retrieval + $0.05-0.09/GB egress on top. Backblaze Personal USB ship-back: $189 deposit for up to 8 TB drive, ~5-7 days transit, full-bandwidth on arrival — often faster than 4 TB internet pull. iDrive 5 TB Personal: ~48 hr/TB restore per user reports. Match the speed to the recovery scenario: if a fire/theft would need all data back within 7 days, plan around USB ship-back or NAS-to-NAS replication, not cold-archive cloud. Microsoft 365 OneDrive restore at scale is API-throttled — multi-TB restores can take days even on enterprise connections.
Expected result: Measured restore throughput recorded. Worst-case full-recovery time estimated for each cloud layer. Plan matches actual household need (catastrophic-loss SLA).
If not: If measured restore is slower than acceptable for catastrophic recovery, add a faster local layer (second NAS, rotated USB) rather than upgrading the cloud tier — internet pull rarely accelerates without paying for premium bandwidth.
Audit the 2026 silent-failure traps before declaring the backup plan healthy
Do: OneDrive Files On-Demand stubs — backup tools copying the OneDrive folder grab placeholders not content; set 'Always keep on this device' on critical folders. iCloud Optimize Storage — full-res photo originals live in iCloud only; device holds optimized copies; a device-side backup of the Photos library is NOT an archive of originals. Explicitly 'Download Originals to this Mac/iPhone' before Time Machine or third-party backup captures full-res — see the NAS photos backup plan for the photos-specific layer. Synology Snapshot Replication retention pruning — verify the retention policy doesn't silently remove the version you'd want during a ransomware-detection window. QNAP HBS 3 ACL-vs-permissions bug — replicates ACL but not shared-folder permissions; restored subfolders default to 0755; verify permissions explicitly after restore. TrueNAS Goldeye 25.10 fixed the rsync SSH-keychain `UnboundLocalError` — earlier Scale versions have intermittent rsync replication failures that aren't surfaced as errors — pair with the overnight backup failure runbook when investigating root cause. Synology C2 migration — legacy C2 Storage and C2 Object Storage standalone plans end 22 Jun 2026; new C2 OneStorage consolidates them. Plan migration before the cutover. Microsoft 365 30-day OneDrive restore window — the 'family 6 TB' tier is functionally a 30-day diff store, not an archive. Long-term archive needs a separate backup layer.
Expected result: Each trap is checked explicitly: stub files set to keep-on-device, iCloud originals downloaded, Snapshot retention reviewed, QNAP permissions verified, TrueNAS version current, Synology C2 migration scheduled, Microsoft 365 retention understood.
If not: If any trap is unverified, the backup plan has a silent failure mode. Don't declare healthy until each is checked — these are the patterns that surface as 'I thought I had a backup' in real recovery scenarios.
Record the drill + schedule the next cadence
Do: Log evidence in one note (date-stamped): backup job + source + destination + restore-test path + file count + byte count + duration + Object Lock state + version retention policy + any warning. Cadence: drill the offsite/immutable layer monthly; drill local NAS restore quarterly; full disaster-recovery rehearsal annually. Update after every backup-stack change — DSM major version, TrueNAS Scale major version, Unraid major version, switching cloud providers, adding a new computer, replacing a USB rotation drive. Note: drill RIGHT AFTER a major upgrade — Synology DSM 7.x point releases occasionally introduce backup-job regressions that show only on restore. Post-incident review pattern: if a real recovery ever happens, document what worked / what didn't / what you'd change. That document is more valuable than the drill log because it captures lived-failure-mode reality.
Expected result: Drill record stored outside the home network (phone note, password manager, paper). Calendar reminder for next drill. Post-upgrade drill scheduled if a NAS/backup-app major version upgrade is planned.
If not: If the drill log isn't accessible during an emergency (i.e., stored only on the NAS being recovered), it's not the backup plan it claims to be. Phone notes, encrypted password manager entries, and physical printouts in a fire-safe are durable alternates.
Commands and settings paths
Verify alt-location restore is the chosen path
Backup app > Restore > confirm destination is NOT the original source path
Where: Inside the backup application (File History / Time Machine / Hyper Backup / HBS 3 / Duplicati / Kopia / B2 web / Wasabi Console).
Expected: Destination is `Restore-Test-YYYYMMDD/` or another temp folder; original source path is untouched.
Failure means: If the app doesn't offer 'restore to alternate location', it will overwrite or merge with the live source — never safe for a drill.
Safe next step: Switch to an app that supports it (Veeam Community Edition free, restic, Kopia, borgmatic) before drilling.
Content verification (hash compare)
Windows: certutil -hashfile <path> SHA256 / macOS: shasum -a 256 <path>
Where: Terminal/PowerShell on the laptop running the drill.
Expected: Hash of restored file matches the live source (or the specifically-requested older version if drilling version retention).
Failure means: Hash mismatch means the backup pipeline was already compromised when the snapshot was taken, OR you're comparing against a newer version than intended.
Safe next step: If hash mismatches across multiple versions, preserve all backup history (don't auto-prune) and check restore against an immutable / Object Lock copy.
Object Lock retention test (B2 / Wasabi / S3)
Cloud provider CLI: b2 delete-file-version (or aws s3api delete-object --bucket X --key Y)
Where: Terminal authenticated to the cloud account.
Expected: Delete API call FAILS with 'object is under Compliance Mode retention' or similar — confirms immutability is enforced.
Failure means: If the delete succeeds, the lock is not enforced — the bucket is not actually immutable.
Safe next step: Enable Object Lock on the bucket (free on B2 / Wasabi / S3) before the next drill.
Synology Hyper Backup restore-to-alt-location
DSM > Hyper Backup > backup task > Restore > Data > 'Restore to a different location'
Where: Synology DSM 7.3 admin UI.
Expected: Restore wizard offers an alt-destination share. Block-level dedup chain stays intact during restore.
Failure means: If the wizard doesn't offer alt-destination, the backup task may be configured for in-place only — reconfigure for next backup.
Safe next step: Pick a temp share with 100+ GB free. After restore, check the restore log for any 'index missing' warning that would indicate version-chain corruption.
TrueNAS Scale snapshot clone for restore-verify
TrueNAS Scale > Storage > Snapshots > select snapshot > Clone to new dataset
Where: TrueNAS Scale 25.10 Goldeye web UI.
Expected: Snapshot clones to a writable dataset; original snapshot retained read-only. 25.10 release notes confirm rsync-over-SSH-keychain `UnboundLocalError` is fixed.
Failure means: If clone fails or rsync replication shows errors, the underlying pool may have ZFS corruption — preserve the snapshot, don't auto-prune.
Safe next step: Mount the cloned dataset, verify content, then destroy the clone to reclaim space. Schedule a `zpool scrub` if rsync replication has been throwing errors.
OneDrive Files On-Demand stub detection
PowerShell: Get-ChildItem -Path <onedrive-folder> -Recurse | Where-Object { $_.Attributes -band [System.IO.FileAttributes]::ReparsePoint }
Where: Windows 11 PowerShell on the backed-up source.
Expected: Empty output = no stub files in the OneDrive folder. Any output = stub placeholders that a folder-copy backup will grab instead of full content.
Failure means: Stubs present means the backup grabbed placeholders, not real files. Restored 'data' is empty.
Safe next step: Right-click critical folders > 'Always keep on this device' before next backup. Re-run the backup; re-drill restore.
Evidence to record
- Backup job/source/destination, last success, restored file list, restore folder, restore-check date.
- Verify, corruption, permission, quota, or retention warning text.
- 3-2-1-1-0 coverage map — which sources have full 5-layer coverage vs partial.
- Object Lock / immutability state per cloud destination (Compliance / Governance / Legal Hold / not enabled).
- Measured restore throughput per cloud layer (Mbps) + extrapolated full-recovery time.
- Version retention policy per backup job (versions retained, prune frequency, immutability window).
- Silent-failure trap audit: OneDrive stubs, iCloud Optimize Storage, Snapshot retention pruning, QNAP permissions, Synology C2 migration plan.
- 2FA + payment-method state per cloud account; recovery codes location.
Common mistakes
- Trusting 'job shows green' as proof of recovery — 2025-vintage ransomware (LockBit 5.0 cross-platform, Cl0p, Qilin) explicitly kills backup agents, clears logs, and encrypts backup metadata. Green = backup ran; healthy = restore actually works from this snapshot.
- Restoring over the original file during a drill — destroys the live version if the backup is partial/corrupted. Always restore to `Restore-Test-YYYYMMDD/`, never in-place.
- Comparing file count instead of file content — a backup that produces 1247 files when the source had 1247 files isn't proof of integrity; ransomware appends random 16-char extensions but file count stays the same. Hash-compare or content-check is the integrity proof.
- Drilling only the latest version — explicitly drill an older version (yesterday's, last week's) to confirm version retention actually works. Synology Snapshot Replication retention pruning has silently removed the version you'd want.
- Skipping the Object Lock retention test — declaring immutability without confirming the API delete actually fails. Object Lock that isn't enforced is theater, not safety.
- Backing up the OneDrive folder via robocopy / Hyper Backup without setting 'Always keep on this device' — stub files appear as full files in Explorer but are placeholders. The 'backup' is bytes-empty.
- Backing up the Photos library without 'Download Originals to this Mac / iPhone' — iCloud Optimize Storage keeps full-res in iCloud only; device holds optimized copies. A Time Machine backup of the Photos library captures optimized, not originals.
- Storing the drill log only on the NAS being recovered — if the NAS is the disaster, the log is too. Use phone notes, password manager entries, or paper printouts in a fire-safe.
- Ignoring QNAP HBS 3 ACL-vs-permissions sync bug — HBS 3 on QTS 5.2.x replicates ACL but not shared-folder permissions; restored subfolders default to 0755; permission-denied errors are the canonical failure mode on cross-system restore.
- Not budgeting restore-speed against actual recovery scenarios — a 5 TB Wasabi pull at 80-100 Mbps takes 5+ days; if the household can't survive 5 days without data, the cloud-only plan is theater. Add a faster local layer (second NAS, rotated USB) or plan Backblaze Personal USB ship-back.
- Forgetting Synology C2 migration cutover — legacy C2 Storage / C2 Object Storage plans end 22 Jun 2026; new C2 OneStorage consolidates them with TBA pricing. Plan migration before the cutover or the cloud layer goes dark.
- Triggering AWS Glacier egress without modeling cost — $1/TB/mo Deep Archive storage hides $0.025/GB Expedited retrieval + $0.05-0.09/GB egress. A 10 TB restore = $200 retrieval + ~$500 egress. Plan around the retrieval cost, not the storage cost.
- Deleting old backup history before proving a new path works — the new path may have a hidden bug; the old history is your insurance during the validation window. Keep both until the new path has been drilled twice.
Stop points
- Stop if the backup app reports corruption, missing indexes, or 'unable to read snapshot' — preserve all history (don't auto-prune), don't run more backups against that destination until the cause is identified.
- Stop if the source drive, NAS pool, or only backup drive clicks, disconnects, asks to format, or shows SMART warnings — get the data off before pushing more I/O at the failing medium.
- Stop before deleting an older backup set during the drill — the drill is the test, not the proof; keep all sets until the drill passes AND a second drill on a different day confirms it.
- Stop before sharing the drill log externally — it may reveal account paths, encryption key locations, or recovery-question answers that are part of the backup-stack threat model.
- Stop before using `--no-verify` or skipping hash checks because they're slow — the integrity proof IS the verification step; without it the drill is a copy test, not a backup test.
Last reviewed
2026-05-06
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.