Off-site & immutability¶

The honest picture of what leaves the house, what does not, and the NAS-side snapshot layer that protects everything from a compromised endpoint.

Current tiers — honestly¶

Data	On the NAS	Off-site	Notes
VM dumps (jarvis, fr24, minecraft)	Nightly 02:00 vzdump, zstd, keep 7 daily + 4 weekly	Latest dump set only → Google Drive, 04:00 rclone	One restorable copy of each VM off-site, no history
Kopia repo (MacBook, Minecraft world, ops config)	Full repo, all history	None — by choice	B2 (~$0.40/mo) is the standing fix, see below
Veeam images (Windows PCs)	Planned share	None planned yet	Machines not onboarded yet

Know what a house fire costs you

Google Drive holds only the latest VM dump set. The Kopia data (Mac documents/photos, Minecraft worlds, ops config) currently has no cloud copy — a deliberate call, not an oversight. If the NAS and the house go together, that data is gone until the B2 plan below is executed.

Run/inspect the sync by hand:

ssh pve "pct exec 104 -- systemctl start gdrive-sync"        # run now
ssh pve "pct exec 104 -- tail -20 /var/log/gdrive-sync.log"  # what happened

The Drive token lives in /root/.config/rclone/rclone.conf on ops.

The Google Drive trash lesson (and the two sacred flags)¶

Files "deleted" on Google Drive sit in its Trash for 30 days, still counting against the 100 GB quota. With nightly dump rotation that snowballs — it once filled the quota and wedged the sync entirely. The fix is that rclone now hard-deletes:

--drive-use-trash=false --delete-before

Never remove those flags

--drive-use-trash=false skips the Trash (no 30-day quota zombie); --delete-before clears the old set before uploading the new one so the transfer never needs old + new quota simultaneously. If an "off-site sync failed" alert fires and quota is full, check the Drive Trash first — history says that's the culprit.

Deadline: rclone's shared client ID retires during 2026¶

The sync currently rides rclone's shared Google Drive OAuth client ID, which Google is retiring during 2026. Before that lands, one of:

Create a personal OAuth client ID in Google Cloud Console and re-auth rclone with it (keeps the Drive leg alive as-is), or
Move the off-site leg to Backblaze B2 — which is the plan anyway.

Doing nothing means the sync eventually stops authenticating. Treat this as a 2026 calendar item, not background noise.

The B2 plan (the standing fix)¶

Backblaze B2 restores a real off-site copy for the Kopia data and dodges the client-ID retirement in one move.

Cost: ~$0.40/month at current data size.
What's needed: create a B2 bucket + an application key (keyID + applicationKey) — store both in the password manager.
Effort: the wire-in is a small session on ops (new rclone/kopia target in /etc/backup-stack/backup-targets.env, sync unit, monitor line). No endpoint changes — they only ever talk to the ops Kopia server.

NAS-side snapshots — the immutability layer¶

This is done in the Synology UI (DSM) and takes ~5 minutes. Why it matters: a compromised endpoint with SMB/NFS write access can encrypt or delete the backup files, but it cannot touch NAS-side snapshots. This is the recover-from-worst-case layer for everything above.

DSM → Snapshot Replication → Snapshots¶

For the shared folder pbs (holds dump/ vzdump archives + kopia/ repo), and later the veeam share once created:

[ ] Enable a snapshot schedule:
- pbs: daily at 06:00 (after the 02:00 vzdump and 04:00 off-site sync have finished)
- veeam share: daily at 06:00 as well
- Kopia endpoints are live and snapshotting hourly now, so add hourly snapshots on pbs with short retention (e.g. keep 24)
[ ] Retention policy: keep 7 daily, 4 weekly (matches vzdump retention; adjust after the size review)
[ ] "Make snapshot visible" = OFF — clients must not see (or delete) #snapshot dirs; restores are done from DSM
[ ] If DSM offers Immutable Snapshots (DSM 7.2+, Btrfs): enable with a 7-day protection period on both shares — the strongest setting; not even an admin login can delete those snapshots early
[ ] Test: create a file on the share, take a manual snapshot, delete the file, restore it via Snapshot Replication → Recover

When the UNAS Pro 4 arrives

Recreate the same policy on the new box (UniFi Drive has its own snapshot feature) before endpoints start writing to it. The stack itself repoints in one file: backup-targets.env + backup-stack-repoint.sh on ops — see hardware.