Backup Strategy¶
Last Updated: 2026-09-22 Purpose: What's backed up, where, how, and what to do when things fail.
Philosophy¶
The goal is multiple independent recovery paths for critical data. Not everything follows strict 3-2-1, but the most critical data (Home Assistant, photos, documents) has both local and cloud copies.
What's Backed Up¶
| Data | Method | Destination | Tested? |
|---|---|---|---|
| Home Assistant config | HA built-in backup (automated) | Nabu Casa Cloud + Lotus share | ⚠️ No |
| Home Assistant VM | Proxmox Backup Server | Lotus (PBS container) | ⚠️ No |
| Pacific LXC containers | Proxmox Backup Server | Lotus (PBS container) | ⚠️ No |
| Docker appdata (Lotus) | Appdata Backup plugin | Cooper | ⚠️ No |
| Unraid flash/USB (Lotus) | Appdata Backup plugin (flash backup) | Cooper | ⚠️ No |
| Docker appdata (Cooper) | Appdata Backup plugin | Lotus | ⚠️ No |
| Data shares (Lotus) | LuckyBackup | Cooper | ⚠️ No |
| Desktop PC (Brabham) | Veeam Agent for Windows | Lotus (backups/brabham) |
⚠️ No |
| Offsite | — | None configured | ❌ |
Home Assistant Backups (Detail)¶
HA is the most critical service and has two independent backup methods:
Method 1 — HA built-in backup:
- Automated, runs on a schedule from within Home Assistant
- Copies stored in two locations:
- Nabu Casa Cloud (offsite) — 5 GB limit; retains one backup only, so each run overwrites the last
- Lotus (local) — habackups share on Lotus NAS; retains multiple backups
- Restoring from this recovers HA config, automations, integrations, add-ons
- Restore time: ~45 minutes
- Use this if HA is broken but Pacific is working fine
Method 2 — Proxmox Backup Server: - Full VM snapshot of the Home Assistant OS VM (VM 112) - Stored on Lotus via the PBS Docker container - Restoring from this brings back the entire VM — OS + config + add-ons - Restore time: ~90 minutes - Use this if the HA VM itself is corrupt or won't boot
See Home Assistant Recovery for step-by-step restore procedures.
Appdata Backup Plugin (Detail)¶
The Appdata Backup plugin (by Robin Kluth) on Lotus handles two things:
1 — Docker appdata backup:
- Backs up /mnt/cache/appdata/ to Cooper nightly
- Destination on Cooper: //192.168.1.60/backups → lotus/ab_YYYYMMDD_HHmmss/
- Retains rolling daily backups; older ones are automatically pruned
2 — Unraid flash (USB) backup:
- Creates a ZIP of the Unraid boot USB config (the flash drive contents)
- Copies it to Cooper at: //192.168.1.60/backups/lotus/justtheusb/
- Restoring from this recovers Unraid array config, plugin list, Docker templates, and network settings without a full reinstall
Important: The Appdata Backup plugin connects to Cooper via Unassigned Devices remote share mounted at /mnt/remotes/COOPERDOMAIN_backups. This share must be configured with Cooper's IP address (192.168.1.60), not its hostname — hostnames like COOPER.LOCALDOMAIN can resolve incorrectly on Lotus (see Lessons Learned).
Desktop PC (Brabham) — Veeam Agent (Detail)¶
Veeam Agent for Microsoft Windows on Brabham, backing up to Lotus over SMB. Brabham is a hobbyist/gaming PC that is only on sometimes — every setting below is chosen around that, not around a 24/7 server.
| Item | Value |
|---|---|
| Job name | Job Brabham (created 2025-07-21) |
| Agent version | 13.1.1.700 (upgraded from 13.0.2.1102 on 2026-09-22) |
| Backup mode | Volume level |
| Volumes | Operating system (C:) + AI (O:) only — 429.6 GB, ~360 GB after the 2026-09-23 cleanup |
| Target | \\192.168.1.80\backups\brabham\ (Lotus), no credentials required |
| Schedule | Daily 05:30, every day |
| If powered off at that time | Back up once powered on |
| After a backup | Keep running |
| Active full | Monthly, first Monday (was weekly Saturday until 2026-09-23) |
| Health check | Monthly, last Friday |
| Retention | 10 days, excluding days with no backup (was 21 until 2026-09-23) |
| Compression / optimisation | Optimal / 1MB |
| Encryption | Enabled — password in Bitwarden as veeam backups |
| Recovery media | SanDisk 61.5 GB USB, FAT32, label VEEAMRE — rebuilt 2026-09-22 |
Measured sizes (2026-09-25, after Docker/WSL moved off C:): a full is 291 GB; the first incremental of the new era covered two days of change in 21 GB, against historical incrementals of 28–259 GB. A true daily should settle at 10–15 GB. Steady state is projected at 400–500 GB — one full plus ~10 incrementals.
Deliberately excluded: NVME (E:) (games), Downloads&Work (D:),
VideoEditing (V:), New Volume (F:). Confirmed intentional 2026-09-22 — backing up
the games drive is not a good use of space, and the rest is not wanted.
Storage layout and what lives on which volume: Workstation — Brabham.
Restoring Brabham¶
- Boot Brabham from the
VEEAMREUSB stick. - The recovery environment includes this machine's Realtek PCIe GbE and NVMe drivers, so the LAN comes up automatically.
- Point it at
\\192.168.1.80\backups\brabham\Job Brabhamand pick a restore point. - Enter the encryption password — Bitwarden entry
veeam backups.
⚠️ The backups are encrypted, and the restore happens from a USB stick with no access to anything on Brabham. Without that password every restore point is unusable. It is the single point of failure for the whole backup set.
The recovery environment has no Tailscale. A restore must come from Lotus on the LAN at
192.168.1.80— the tailnet address will not work.Recreate the recovery media after every agent upgrade. Veeam raises a notification asking for this, and the media must match the installed agent version.
How retention actually behaves¶
"Keep restore points for the last 21 days" counts days on which a backup ran, not calendar days. On a machine used sporadically, 21 of those can take a year to accumulate.
Retention can also only ever delete a whole chain — a full plus every incremental depending on it. As of 2026-09-22 there were 28 restore points in two chains (17 + 11), so deleting the older chain would have left 11, below the 21 floor. Nothing was eligible, and 1.8 TB accumulated from 13 months of backups.
The lever is the number of fulls, not the retention number. More fulls means shorter chains, more of them, and something retention is allowed to drop.
Changed 2026-09-23: retention 21 → 10. The floor was higher than what remained after the only deletable chain, so it was permanently deadlocked — dropping the 17-point chain would have left 11, under 21. At 10 it clears, freeing ~719 GB plus a redundant 291 GB full. The cliff edge is exactly 11; 10 gives a point of headroom.
✅ Confirmed working 2026-09-25. The first run after the change deleted the whole Aug 2025 chain — all 17 points, ~700 GB — taking the folder from 2.3 TB to 1.6 TB and 29 restore points to 13. Two behaviours worth knowing:
- Only one chain is collapsed per run. The lone 22 Sep full was equally eligible and survived; it should go on the next run.
- A chain stays blocked until the live chain can replace it. The Feb 2026 chain (10 points, ~1023 GB) cannot drop until the current chain reaches 10 points.
Because retention counts backup-days, an intermittently-used machine gets more calendar coverage from the same number — 10 backup-days spans roughly 3–6 weeks here.
Troubleshooting: a full fails partway with "A device which does not exist was specified"¶
This is VSS, not a failing disk. Veeam reads a shadow copy of C:, and Windows destroys it when the shadow-copy diff area hits its cap. Check the System event log:
- Volsnap 36 —
shadow copies of volume C: were aborted because the shadow copy storage could not grow due to a user imposed limit← the cause, in one line - Volsnap 33 — older shadow copies being deleted to stay under the cap, just before
Check and raise the cap (elevated):
vssadmin list shadowstorage
vssadmin resize shadowstorage /For=C: /On=C: /MaxSize=30GB
C: was capped at 9.29 GB / 1% against a Windows default of 10%; raised to 30 GB on 2026-09-22. The maximum is a cap, not a reservation — only 575 MB stays allocated.
Duration is the tell, not size. A 50-minute incremental survived; the ~2-hour full did not. A full is the operation most likely to trip this, so run fulls when C: is quiet. C: is also tight at 57.6 GB free of 464.7 GB (12.4%), which is the underlying squeeze.
Known weaknesses¶
- Single copy. The
copy lotus brabham backup to cooperUser Script on Lotus exists but its schedule isdisabled, so Brabham's backups live only on Lotus. Unlike appdata, there is no second copy on Cooper. - Restore has never been tested.
- Active fulls are pinned to a weekday, which on an intermittently-used machine is
fragile — weekly-on-Saturday produced exactly two fulls in thirteen months because the
machine was never on at 05:30 on one. Moved to monthly, first Monday on 2026-09-23.
Veeam appears to catch up a missed active full on the next run (observed 2026-09-23, a
Wednesday), so a missed Monday should slide rather than skip. Review after a month;
if no new
.vbkappears, run an active full by hand. - Why monthly rather than never: an active full is the only operation that re-reads every block from the source machine. Incrementals, merges and synthetic fulls all trust the data already on the NAS, so a silently corrupted block propagates forward indefinitely. The monthly health check catches and repairs what it detects; a monthly full guarantees the whole image is re-read from source twelve times a year.
Critical Data Priority¶
- Home Assistant config — automations, integrations, years of setup
- Photos — via Immich on Lotus (no offsite backup yet — high priority gap)
- Documents — via Paperless-NGX on Lotus (no offsite backup yet)
- Application configs — Docker appdata backed up to Cooper
- Media — Plex library (can be re-acquired, lowest priority)
Physical Separation¶
Lotus and Cooper are not in the same building:
- Lotus (primary NAS) — office outbuilding
- Cooper (backup NAS) — living room (house)
This provides meaningful protection against localised incidents — a fire, flood, or theft affecting one building is unlikely to affect both. It is not true offsite backup (same property, same power supply, same catastrophic weather risk) but it is significantly better than two devices in the same room.
For true offsite resilience, a cloud backup of critical data (photos, documents) would be the next step.
Known Gaps¶
- HA backups only go to Lotus, not Cooper — if Lotus is unavailable, only the single Nabu Casa cloud copy exists. HA backups should also be sent to Cooper as a second local destination
- HA cloud backup retention — Nabu Casa keeps only one backup; consider adding a second cloud provider (e.g. Backblaze B2, Storj) for a more durable offsite copy
- No cloud/offsite backup for photos (Immich) or documents (Paperless-NGX) — physical separation helps but does not cover all scenarios
- Backup restoration has not been tested for any service
- Brabham’s Veeam backup has no second copy — the Lotus→Cooper User Script for it is
disabled, so it is the only backup here with a single copy - No monitoring alerts for failed backup jobs — partly addressed 2026-09-22 for Brabham/Veeam via a backup-age check on Lotus feeding Home Assistant; every other job is still unmonitored
Restore Testing Schedule¶
- [ ] Last HA backup restore test: never
- [ ] Last Proxmox VM restore test: never
- [ ] Last Docker appdata restore test: never
- [ ] Last file share restore test: never
A backup you've never restored from is an untested backup.