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>
This commit is contained in:
Julien Lutran
2026-08-28 16:20:20 +02:00
co-authored by Claude Fable 5
parent b5aef914f5
commit d7ec780747
6 changed files with 78 additions and 64 deletions
+34 -15
View File
@@ -4,25 +4,29 @@ Audience: anyone with root on ks4 who needs to know **what is protected,
where, by which tool, and how to check it**. Details live in the linked
docs; this page is the map.
## Two tools, no more
## Two tools, three legs
| tool | job | why this one |
| leg | mechanism | protects |
|---|---|---|
| **`incus copy --refresh`** | replicate whole instances (ready-to-start copies) | ZFS-incremental, native to the platform, restores are `incus start` |
| **restic** | off-site backups to S3 (files, database dumps, instance trees) | dedup + encryption, local metadata cache → a night costs only the churn ([restic-backup.md](ks4/restic-backup.md)) |
| **local replication** | `incus copy --refresh` → pool `backup` on ks4's second disk (sdb) | instances, against losing the `data` pool |
| **remote replication** | nuc pulls the same replicas over WireGuard → pool `ks4backup` | instances, against losing ks4 or the site |
| **remote backup** | **restic** → S3 bucket `restic-data`: database dumps + selected filesystem trees | the data itself, versioned and encrypted, independent of every disk above |
plakar was evaluated first and replaced (its nightly cost scaled with
tree size — [PlakarKorp/plakar#2338](https://github.com/PlakarKorp/plakar/issues/2338));
the old backup server **ks2 is being retired** (decommission by
Sep 30, 2026 — [ks2/plan.md](ks2/plan.md)): it still holds an ageing
copy of the instances until the nuc leg below takes over.
Only two tools are involved: `incus copy` (ZFS-incremental, native to
the platform — a restore is `incus start`) and restic (dedup +
encryption, local metadata cache, so a night costs only the churn —
[ks4/restic-backup.md](ks4/restic-backup.md)).
**Status 2026-08-28**: the local replica leg and the S3 data leg are
live. The **nuc pull leg is waiting for FTTH** (expected before end of
September); until it lands, the ks2 push is re-enabled as an interim
off-site copy of the instances. Backing up instance *images* to S3 was
designed and shelved — S3 holds the data, the databases and the incus
configuration, which is what a rebuild needs.
The old backup server **ks2 is being retired** (decommission by
Sep 30, 2026 — [ks2/plan.md](ks2/plan.md)); until FTTH enables the nuc
leg it still receives an interim replica push.
**Status 2026-08-28**: local replication and the S3 backup leg are
live. The **nuc pull leg waits for FTTH** (expected before end of
September); until then the ks2 push stands in. Backing up whole
instance *images* to S3 was considered and left out — S3 holds the
data, the databases and the incus configuration, which is what a
rebuild needs.
## The map
@@ -120,3 +124,18 @@ New instances are picked up automatically by the replica and
instance legs (all instances, opt-out only). Databases are
auto-discovered. Only **data trees** need one line in
[`restic-paths`](https://git.lutran.fr/julien/scripts/src/branch/main/restic-paths) — see [new-container.md](new-container.md).
## History (reference only)
The road to the setup above, kept for the measurements rather than for
operations: an rsync-based leg to ks2
([ks2/plan.md](ks2/plan.md)) and a first S3 implementation with
**plakar** ([ks4/plakar-s3-data.md](ks4/plakar-s3-data.md), plus a
self-written incus connector,
[ks4/plakar-incus-integration.md](ks4/plakar-incus-integration.md)).
plakar was dropped because its nightly cost scaled with the size of
the tree rather than with the churn
([PlakarKorp/plakar#2338](https://github.com/PlakarKorp/plakar/issues/2338)).
It is still installed on ks4 and its `plakar-data` bucket still exists
— kept only so the upstream issue can be reproduced; nothing schedules
it any more.