Files

T

Julien LutranandClaude Fable 5 d7ec780747 doc: plakar out of the current architecture, kept as reference

backup-strategy.md now leads with the three target legs (local incus
push to sdb, nuc pull over WireGuard, restic to S3 for DBs and
selected trees) and carries the plakar/ks2 story in a closing History
section. restic-backup.md, install.md, local-backup-cron.md and the
ks2 docs describe the predecessor only as 'the first S3
implementation', with one operational note that plakar is still
installed for issue #2338 reproduction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-28 16:20:20 +02:00

4.2 KiB

Raw Blame History

ks2 decommission — summary plan

Goal: release ks2.lutran.fr (164.132.173.57, SSH :2233, host ns3247221) once ks4 has a real 3-2-1 backup without it. Deadline: rental ends Sep 30, 2026.

What ks2 does today (updated 2026-08-28)

Nothing is written to ks2 any more. Both feeds are retired: the 01:00 replica push (replaced by the local leg on ks4's sdb5 pool, local-backup-cron.md) and the 04:00 incus-backup.sh rsync (replaced by restic → S3, restic-backup.md).

What remains on the box is cold history: instance replicas on pool data (last refreshed 2026-08-09) and the rsync tree /backup/ns3061243 on pool backup (last refreshed 2026-08-28), snapshotted daily there (zfs-auto-snapshot.sh, 2-month expiry).

⚠️ While the nuc leg waits for FTTH, instances have no fresh off-site copy — the ks2 push is to be re-enabled as soon as the initial restic sync finishes (decided 2026-08-28), and retired again when nuc takes over.

Inventory findings (2026-08-22)

biwiki exists only on ks2, spot only on ks2 + ks4's backup project — decision: both abandoned, safe to delete from backups.
incus-backup.db is stale (lists spot, misses livetrail, outline, login, …) — forgotten-manifest drift is exactly what the replacement had to eliminate — restic's drivers back up all instances and auto-discover all databases, opt-out instead of opt-in.
livetrail (running on ks4) is absent from ks4's local backup project — the local leg was run manually once and never again; automating its cron fixes this.
Both ks4 backup crons were commented out — no ks4 backup ran at all (hence the stale ks2 rsync data: dirs Jul 23, incus dumps Aug 9). Fixed 2026-08-22 — see local-backup-cron.md.
/backup/ns3061243 also holds pre-2023 dirs (catc, mythoughts, qcm) — those instances still exist stopped on ks4, so nothing unique expected there; spot-check before wiping.
Losing ks2 also loses its 2 months of rsync-snapshot history — acceptable: restic keeps 14 daily / 8 weekly / 6 monthly.

Target architecture (3-2-1 for ks4)

Leg	Mechanism	Status
local, 2nd disk	`incus-copy.sh -p backup -s backup` → sdb5 pool	live (01:00)
off-site, S3 (data+DB)	restic → bucket `restic-data` (restic-backup.md)	live (05:00)
off-site, S3 (instances)	restic over `incus file mount` of the `backup`-project replicas	shelved 2026-08-28 (replication covers instances)
off-site, nuc	nuc pulls `ks4:*` → pool `ks4backup` over WG (nuc-seed.md)	waiting FTTH (< Sep 30)
off-site, ks2 (interim)	`incus-copy.sh -d ks2 -m push` at 02:00 until the nuc leg seeds	to re-enable once the restic seed finishes

Actions (backup work documented in `../ks4/`, ks2-only tasks here)

~~salvage biwiki/spot~~ — decided 2026-08-22: both abandoned, deleted from ks2 and ks4's backup project
~~local-backup-cron.md~~ — done 2026-08-22: leg 1 cron re-enabled, ks2 rsync kept as stopgap; livetrail verified present in the backup project
~~first S3 leg~~ → restic is the S3 tool (restic-backup.md, live 2026-08-28; the predecessor's doc is kept as reference)
~~instance leg to S3~~ — shelved 2026-08-28: instances are protected by replication (sdb + nuc/ks2), their data and configs by restic-data
nuc-seed.md — prepared; after FTTH: seed nuc pull leg, verify all instances, test-restore one
decommission.md — prepared; cut flows, final diff of /backup/ns3061243, wipe pools, terminate at OVH

Release gates — ks2 can be dropped only when

biwiki + spot consciously abandoned (2026-08-22)
local leg cron running ≥ a few days, all instances present
nuc leg fully seeded and one instance test-restored
restic S3 data/DB backups running daily and one DB + one file tree test-restored
ks4 crons pointing at ks2 disabled

4.2 KiB Raw Blame History