From 4b73d77803dbc2cffbbb6414fd8afa6b3644dd71 Mon Sep 17 00:00:00 2001 From: Julien Lutran Date: Sun, 23 Aug 2026 09:29:01 +0200 Subject: [PATCH] plakar-incus-integration: chain the S3 instance leg after incus-copy Co-Authored-By: Claude Fable 5 --- ks4/plakar-incus-integration.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/ks4/plakar-incus-integration.md b/ks4/plakar-incus-integration.md index f8fed1c..0ba0cb7 100644 --- a/ks4/plakar-incus-integration.md +++ b/ks4/plakar-incus-integration.md @@ -127,7 +127,14 @@ major upgrade; a mismatch surfaces at backup time, so run a manual - xattrs / ACLs / device nodes over sftp — coverage and fidelity. - VMs: file access needs a running incus-agent — out of scope for ks4 (containers only); document the limitation. -- Scheduling/locking: chain after the 01:00 incus-copy (flock on the - same lock, or a wrapper script). +- ~~Scheduling/locking~~ decided 2026-08-23: the S3 instance leg is + only as fresh as the last **completed** local incus-copy, so both + run chained in one cron entry — + `incus-copy.sh -p backup -s backup ; ` — never at + a fixed offset (a long refresh, e.g. a post-gap full re-send, would + race it). `;` not `&&`: a partially failed copy leaves stale but + internally consistent replicas, still worth uploading. Same rule + for manual test runs: check `/var/log/incus-copy.log` completed + first. - S3 hardening: scoped credentials (no delete), versioning/object lock, plakar client-side encryption passphrase storage.