home-ops: Skill for Claude Code

kopiur backups (and the VolSync dual-engine overlap)

Relocated verbatim from AGENTS.md on 2026-09-01 so it loads only when this subsystem is in play. The text below is unchanged; only line breaks were inserted. AGENTS.md keeps a one-sentence pointer. Add new findings here or to the owning document, not back into AGENTS.md - see its "Maintaining this file" section for the rule.

• kopiur is live on all 29 of the fleet's 29 VolSync-protected claims, VolSync has been RETIRED from 27 of them (migration Stage 5, waves on 2026-09-01, 2026-09-02 and 2026-09-04 - the migration is COMPLETE for every eligible claim), and deleting kopiur's CRs can delete backup data. The fleet was 30 until the downloads/autobrr APP was removed on 2026-09-02 (captain decision - unused). That is a distinct operation from a Stage 5 retirement, which removes an ENGINE and always leaves the claim: removing the app removed the claim, the overlay and the kopiur onboarding together. Its kopia snapshots were deliberately KEPT - docs/backups/autobrr-removal-2026-09-02.md, which also records the measured Retain semantics below. system/kopiur (operator + two cluster-scoped ClusterRepository objects: ceph and r2, each on its own new kopiur bucket - MinIO is deliberately not a kopiur destination) is the staged replacement for VolSync. Stage 3 (2026-08-30) put 27 further claims on kubernetes/components/kopiur alongside an untouched components/volsync, one commit per namespace, so those claims now have two independent backups each.

27 volumes were made kopiur-ONLY, in three waves; 26 still are (autobrr left the fleet with its app). Wave one, retired 2026-09-01 as a deliberate low-stakes pilot (regenerable or reconstructible content, clean restore proofs): ai/repo-wiki, downloads/recyclarr-config, downloads/sabnzbd-config, media/seerr. Wave two, retired 2026-09-02 on the deeper proofs in docs/backups/kopiur-wave-two-reproof-2026-09-02.md part 4: downloads/prowlarr-config, selfhosted/ntfy, downloads/autobrr (app since removed), selfhosted/obsidian-livesync - and these are not all regenerable, so the authorising argument is different: completeness of proof (100% of claim content, destination-identical in content and metadata) plus, for the two 2Gi selfhosted claims, a PVC that cannot outgrow its restore cache. selfhosted/obsidian-livesync is a genuine Obsidian vault and was retired on an explicit captain decision after firstmate objected and recommended keeping it dual-engine. Wave three, retired 2026-09-04, took the remaining 19 eligible claims in three risk-tiered commits - tier A database/pgadmin, downloads/{bazarr,lidarr,radarr,readarr,sonarr}, home-automation/{esphome,matter-server,zigbee2mqtt}, media/tdarr, selfhosted/changedetection; tier B ai/{hermes,opencode}, media/{plex,calibre-web-automated}; tier C home-automation/home-assistant, selfhosted/{n8n,linkwarden,syncthing}. Same evidence standard for all 19 (every one a destination-identical PASS row in the fleet proof); the tiering is a sequencing device so a surprise stops one tier rather than the fleet. Record, exposure table and open follow-ups: docs/backups/kopiur-wave-three-retirement-2026-09-04.md. Only three claims remain dual-engine, and that is the END STATE, not a backlog: selfhosted/paperless-ngx is a permanent carve-out; selfhosted/syncthing-data (5 files / 531 B) and selfhosted/paperless-ngx-media (1 file / 0 B) were assessed in wave two, re-measured unchanged on 2026-09-04, and found NOT ready (proofs cover nothing meaningful, and both sit behind a restore cache they would cross the first time they hold real data). Assume a claim is kopiur-only unless you have checked - the dual-engine safety net that made earlier kopiur mistakes survivable is gone almost everywhere. Note selfhosted/syncthing (1Gi config claim, RETIRED) and selfhosted/syncthing-data (15Gi synced files, NOT retired) are different claims sharing one overlay file. Stage 4 (2026-08-31) onboarded both previously deferred claims: selfhosted/changedetection-config, which turned out not to need the 0:1000 root mover its deferral assumed (the app shipped no securityContext at all, so it ran as its image default (root) and wrote 2292 mode-0600 root-owned files while its overlay declared an APP_UID/APP_GID of 2000:2000 that no manifest in this repo consumes; giving it the 1000:1000 identity its data already carried and re-owning the volume removed the need for a root mover, so it onboarded with no KOPIUR_PUID/PGID override and no namespace-wide privileged-mover grant), and home-automation/matter-server with an explicit root mover (KOPIUR_PUID/PGID: 0) - the component already parameterises that, so inheritSecurityContextFrom was not used (it would not flow to the standing Restore) - plus the namespace-wide kopiur.home-operations.com/privileged-movers=true annotation.