From f363ad70db0f4d4df27a7b8c9e96e21ef7aa45d4 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Mon, 20 Jul 2026 22:41:54 +0300 Subject: =?UTF-8?q?f3s-storage=20skill:=20backups.md=20=E2=80=94=20reflect?= =?UTF-8?q?=20reality=20(no=20zdata=20daily=20S3=20cron)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The only live S3 offsite backup is the zusb quarterly workflow, which backs up zusb/data/* (not the f-host zdata pool). Verified no aws/s3/ backup cron in root crontab on any f-host and no pre-existing /root/.aws. zdata redundancy is via zrepl replication, not S3. Also corrected the aws-credentials caveat (symlink is deliberately dangling on non-zusb hosts until zusb is replugged there) and noted the 2026-07-20 install across all f-hosts. --- prompts/skills/f3s-storage/references/backups.md | 39 +++++++++++++++++++++--- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/prompts/skills/f3s-storage/references/backups.md b/prompts/skills/f3s-storage/references/backups.md index 2181ebc..0ed86b8 100644 --- a/prompts/skills/f3s-storage/references/backups.md +++ b/prompts/skills/f3s-storage/references/backups.md @@ -2,9 +2,28 @@ ## AWS S3 Glacier Deep Archive Backups -Encrypted incremental ZFS snapshots from `zdata` pool backed up daily to **AWS S3 Glacier Deep Archive** via cron. Scripts adapted from FreeBSD Home NAS setup. Also performs periodic zpool scrubbing. - -The **`zusb` quarterly backup** (`/opt/snonux/bin/backup/backup`, which travels on the `zusb` pool — see [USB Key Mounting](usb-keys.md) → "Removable backup pool (`zusb`)") also uploads to the same S3 Glacier Deep Archive bucket (`s3://org-buetow-backup//`). Both workflows need the AWS CLI on the host that runs them. +The offsite backup is the **`zusb` quarterly workflow**. The removable `zusb` +pool (see [USB Key Mounting](usb-keys.md) → "Removable backup pool (`zusb`)") +is plugged into an f-host roughly once per quarter, and +`/opt/snonux/bin/backup/backup` — which travels on the pool under +`zusb/data/opt` — exports dated `zfs send` snapshots of the `zusb/data/*` +datasets into encrypted archive chunks on `zusb/backup///` +(`gzip` → `openssl enc -aes-256-cbc -pbkdf2 -pass file:/opt/snonux/secrets/.backup.phrase` → `split`), then `aws s3 sync ... --storage-class DEEP_ARCHIVE` +uploads them to `s3://org-buetow-backup//`. The script's `HOSTNAME=t450` +override keeps the S3 key prefix stable across the t450→f-hosts migration. + +The backup runs `aws` as root on whichever f-host currently hosts `zusb`, so the +AWS CLI must be installed there and credentials wired in. + +**Reality note (2026-07-20):** there is **no daily `zdata`→S3 cron** on any +f-host — the old "zdata daily to S3 via cron" setup is no longer present +(verified: no aws/s3/backup cron entries in root's crontab on f0/f1/f2/f3, and +no `/root/.aws` pre-existed on any of them). The `zusb` quarterly workflow +above is the only live S3 offsite backup. It backs up the `zusb/data/*` +personal datasets, **not** the f-host `zdata` pool; `zdata` redundancy comes +from zrepl replication (f0→f1), not S3. If a daily `zdata`→S3 cron is ever +reinstated, it would need its own always-available aws credentials (not the +zusb-pool symlink below), since it must run without `zusb` imported. ### AWS CLI setup on a FreeBSD host @@ -27,7 +46,12 @@ sudo chmod 600 /root/.aws/config sudo ln -sf /opt/snonux/secrets/aws.credentials /root/.aws/credentials ``` -Because the credentials are a symlink into `/opt` (`zusb/data/opt`), `aws` only resolves them while `zusb` is imported on that host. That is fine for the quarterly backup workflow (load `zusb` → run backup → export `zusb`); it is **not** suitable for the `zdata` daily-cron S3 backup on an f-host that does not normally have `zusb` imported — that host would need its own credentials copy (out of scope here). +Because the credentials are a symlink into `/opt` (`zusb/data/opt`), `aws` only +resolves them while `zusb` is imported on that host. That is exactly right for +the quarterly workflow (load `zusb` → run backup → export `zusb`); on the other +f-hosts the symlink is deliberately **dangling until `zusb` is replugged there**, +at which point `/opt` mounts and it resolves. No secret material lives on host +disks or in git. Verify (read-only): @@ -37,7 +61,12 @@ aws sts get-caller-identity # expect Arn arn:aws:iam::634617747016:user/o aws s3 ls s3://org-buetow-backup/ # expect the per-host prefixes (e.g. t450/) ``` -Installed 2026-07-20 on f1 (`py312-awscli-1.42.44`), matching the t450 setup (`py39-awscli-1.29.81`, same `/root/.aws/config` region and the same credentials symlink). +Installed 2026-07-20 on **all f-hosts** (f0/f1/f2/f3, `py312-awscli-1.42.44`), +matching the t450 setup (`py39-awscli-1.29.81`, same `/root/.aws/config` region +and the same credentials symlink). Verified working on f1 (where `zusb` is +hosted) via `aws sts get-caller-identity` → `org-buetow-backup-user`; on +f0/f2/f3 the symlink is dangling until `zusb` is imported there. (f0 previously +had a stale, never-configured `py311-awscli` package, now replaced by `py312`.) ## Local-Path Storage for SQLite Workloads -- cgit v1.2.3