albok: move closed — acceptance passed, old nh3-docker store deleted, first VM 110 backup taken

This commit is contained in:
vh
2026-10-05 00:21:15 -07:00
parent 94ca792a97
commit a7a068f56f
3 changed files with 10 additions and 3 deletions
@@ -30,7 +30,11 @@ mode/mtime/type identical. ⚠ **A full-manifest digest that includes `%s` will
st_size reflects blocks once allocated, so it is not data. Split the manifest by field before deciding a copy is bad.
New host healthy at 2331:25: 4 wings ready, drift 0, needs_reindex 0, so no reindex was needed. Then DNS moved.
**Still open (as of 2332):** albok-dev's acceptance (albok-check + one Nemi walk); the first manual PBS backup of VM
**CLOSED 2026-10-05 0021.** Acceptance passed at 0018 (albok-check at 2350 and 0018; the Nemi walk 0003–0016 exited 0. Its 1,187
updates were the restamped source_commit from memory commits, not the move). The old `/srv/albok` (1.4 G) was deleted at 0018.
First VM 110 backup 0019–0021 to pbs-ana ns nh3-pve-2. The albok user/groups on nh3-docker remain, unused.
**Was open (as of 2332):** albok-dev's acceptance (albok-check + one Nemi walk); the first manual PBS backup of VM
110 after acceptance; deleting the old `/srv/albok` on nh3-docker. **Prime approved the deletion directly at 2349,
conditional on albok-dev's acceptance passing** (it cannot be undone, so it needed his word, not the relay). Until then it
sits under the same 2375 exposure as before, with nothing reading it. Delete with literal paths only, and leave the renamed
+1 -1
View File
@@ -119,7 +119,7 @@ _As of 2026-10-04 ~2300 PT. The newest subsection is first; older subsections ca
### 2026-10-04: live now (as of 2026-10-04 ~2300 PT)
- **albok-service now on nh3-albok (VM 110, nh3-pve-2, 10.100.50.44) since 2332; DNS moved.** Open: albok-dev acceptance, then the first manual PBS backup of VM 110 and deleting the old `/srv/albok` on nh3-docker — **Prime approved that deletion 2026-10-04 2349, conditional on acceptance passing** (container gone, compose renamed). → `persistent-memory.d/2026-10-04-albok-service-moved-to-nh3-albok.md`
- **albok-service now on nh3-albok (VM 110, nh3-pve-2, 10.100.50.44) since 2332; DNS moved. CLOSED 2026-10-05 0021:** albok-dev acceptance passed 0018, the old `/srv/albok` on nh3-docker was deleted on Prime's approval, and the first VM 110 backup is on pbs-ana. The compose tombstone stays on nh3-docker. → `persistent-memory.d/2026-10-04-albok-service-moved-to-nh3-albok.md`
- **Nothing is mid-action.** Every hypervisor is on PVE 9.2.21 / 7.0.14-20 (pfi-pve 0656, esh-pve 0742, nh3-pve + esh-nas-pve 10-03, nh3-pve-2 fresh) and both PBS on 4.2.7 (1144). → `persistent-memory.d/2026-10-04-fleet-on-pve-9-and-pbs-4.md`
- **Scheduled with infra-hermes (do not redo):** 10-05 0815 PT check that sfsrv-ana's (PVE 8) 04:00 backup reached pbs-ana, then `qm delsnapshot` 100/105 `pre-pbs4` (if stale/errored he sends infra-ops URGENT and keeps them); on/after 10-05 0900 drop `pve/root-pre-pve9` on pfi-pve + esh-pve (job `pve9-drop-pre-snapshot`); 10-11 0900 delete the two one-off PBS VM vzdumps. esh-nas-pve `nvme/ROOT@pre-pve9`: destroy ~10-10 (ours). Never `zpool upgrade` any pool yet.
- **Weekly sudo-io archiver** first scheduled run Sun 2026-10-11 05:40 (nh3-dev user timer); bulk data no longer recorded fleet-wide. → `services/sudo-io-archive/README.md`
+4 -1
View File
@@ -54,4 +54,7 @@ Only digests were printed, so the restricted wings' paths never reached a termin
On nh3-docker the container was removed and `compose.yaml` renamed to
`compose.yaml.moved-to-nh3-albok-2026-10-04`, so a stray `compose up` there cannot start a second writer on a stale
copy. **`/srv/albok` is still on nh3-docker** until Prime approves deleting it after acceptance.
copy. albok-dev's acceptance passed at 0018 on 2026-10-05 (albok-check twice, then a clean Nemi walk), and the old
`/srv/albok` on nh3-docker was deleted at 0018 on Prime's approval. Old nh3-docker backups still hold that copy until
their retention ages it out. The personal vault was never ingested there, so those backups do not contain it.
First backup of VM 110: 2026-10-05 0019–0021 by hand, 1 m 55 s, guest-agent freeze/thaw OK.