Add documentation for automated backup approach for synology

docs/status.md

@@ -130,6 +130,7 @@ Linux PC · Windows gaming PC · partner's PC · printer (optional) · Synology
   - `homes` is a reserved system share: its permissions can't be edited ("homes is reserved for the system"), and only Administrators-group accounts see it in Hyper Backup — neither is a problem.
   - Entire-system backup (restorable NAS image) isn't available to a local USB destination, only to a remote NAS / C2 — restoring means reinstalling DSM and packages and restoring data + config from the backup.
   - **Still to confirm after the first run finishes: a test restore** of a personal Drive file and a personal photo (both users) to prove the application backup really covers personal data. Later: occasional off-site copy (3-2-1).
+  - **Planned (post-NUC): power the drive via a Home Assistant smart plug** for a weekly window instead of plugging it in by hand — goal is protection against hardware failure; the slightly weaker ransomware isolation is accepted (off-site copy if that ever matters). Power-off only after a scripted clean eject. Details in todo.md.
 - Hyper Backup vs Hyper Backup Vault: Vault is only the *receiving* side on a second Synology (relevant for a future off-site copy), not needed for a local USB drive.
 
 ## Cabling & power

docs/todo.md

@@ -57,6 +57,12 @@ Setup lives in [`../ansible/`](../ansible/README.md). OctoPrint Pi is the guinea
 - [ ] **TLS certs for NPM**: same decision as the NAS's own cert (see above) — leaning `mkcert` over Let's Encrypt DNS-01/INWX for the same credential-scope reasons. Decide once NPM proxy hosts are actually being used for more than testing.
 - [ ] **Off-machine Omada Controller backups to the Synology** — set this up on the NUC after the migration rather than on the desktop. Decided approach: a scheduled **rsync** job on the Controller host copying the Controller's autobackup folder (believed to be `/opt/tplink/EAPController/data/autobackup` inside the container — verify with `docker exec omada-controller ls` once a backup has run) to the NAS. **Not** a NAS folder mounted into the container (avoids the container's startup depending on the NAS, and keeps a failed copy from affecting the Controller). Use a **dedicated Synology user with a small storage quota** and key-based auth, so the credential on the Controller host can only touch that one backup folder — check that the DS223j's volume filesystem supports user quotas, and how DSM allows a non-admin user to do rsync/SFTP (SSH is admin-only by default). Backups contain secrets (Device Account, WireGuard keys, DDNS settings), so restrict the folder to that user and keep the files out of this Git repo. Once the Synology's own Hyper Backup to the 6TB drive exists, these are covered there too.
 - [ ] Migrate Omada Controller from the desktop to the NUC once the NUC is provisioned — see [omada-controller-migration.md](omada-controller-migration.md).
+- [ ] **Automate the Hyper Backup USB drive via a Home Assistant smart plug** (needs HA on the NUC). The drive has its own power supply, so a plug can power it only for a weekly window (e.g. Sunday 03:00) and the manual plug-in/eject routine + calendar reminder go away. **Decided: fine** — the goal is protection against hardware failure; the drive now mounts itself regularly, which weakens the ransomware protection a bit, accepted (an off-site copy is the answer if that ever becomes a concern). Plan:
+  1. **Plug**: locally controlled, no vendor cloud — Zigbee (planned coordinator) or Shelly (local API), on the IoT VLAN; HA reaching it (Trusted/Servers → IoT) isn't blocked by the `IoT → !IoT` rule.
+  2. **Test first**: cut and restore wall power — the drive must come up by itself without a button press, and DSM must mount it under the same `usbshare` name (keep it the only USB device, or the task's destination path moves).
+  3. **Schedule**: plug on → ~15 min later Hyper Backup's own schedule starts the task (a missing drive then fails the task → DSM failure notification doubles as a health check). Integrity check can run in the same window.
+  4. **Power-off must follow a clean eject** — cutting power mid-write or without ejecting is exactly the unclean-unmount problem. DSM has no scheduled eject in the UI → root script in Control Panel → Task Scheduler: skip if Hyper Backup is still running, otherwise unmount the drive (**verify the exact DSM eject command over SSH on the DS223j first**). HA turns the plug off with a generous margin (4–6 h), ideally only once DSM reports the drive gone (check whether HA's Synology DSM integration exposes USB disks).
+  5. Also turn off external disk hibernation (Control Panel → Hardware & Power → HDD Hibernation) if it causes drop-outs during the run.
 
 ## Future ideas