Trei lucruri gasite continuand handoff-ul de la incidentul pveelite.
1. Replicarea oracle-backups taia snapshoturile doar pe sursa. Pe destinatie
nu curata nimeni, deci din 25.04 se adunasera 11.886 snapshoturi tinand
941G pe pvemini - nodul cu toata productia, ajuns la 93%. Adaugat
KEEP_SNAPS_DEST=288 (72h). Dupa curatarea restantei: 93% -> 44%,
1,01T liberi. Verificat ca rularea cron urmatoare pastreaza fix 288.
Stergerea pe interval (ds@a%b) prinde si snapshoturile @failback_/@init_
dintre capete, deci scriptul sterge cate unul; intervalul s-a folosit o
singura data, manual, dupa ce s-a verificat ca nu exista non-repl_.
2. pvemini-down-alert.sh rula din cron fara PATH, iar ha-manager e in
/usr/sbin: sectiunea "HA status" iesea goala tacut la fiecare alerta.
3. Resetarile adaptorului USB LAN nu erau intamplatoare. Un mouse optic
defect se re-enumera de ~1000 de ori pe zi pe acelasi controller xHCI
(0000:00:14.0) ca adaptorul de retea; tastatura de pe acelasi hub are o
singura enumerare. Erorile "xhci_hcd WARN Set TR Deq Ptr" apar lipite de
fiecare resetare r8152, la 3 secunde dupa cate o re-enumerare a mouse-ului.
Portul mouse-ului dezactivat din sysfs ca experiment reversibil.
Punctul cu exportul NFS "inexistent" din planul de preventie era alarma
falsa: exportul e viu, doar ca nu e storage Proxmox. Marcat ca atare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Convert /mnt/pve/oracle-backups from a directory on the pveelite
rootfs into a dedicated ZFS dataset rpool/oracle-backups so it can be
incrementally replicated to pvemini. zfs-replicate-oracle-backups.sh
runs every 15 minutes from cron on pveelite and uses zfs send/recv
over the cluster's internal SSH (direct IP, /etc/pve/priv/known_hosts)
to avoid Tailscale magicDNS detours that broke the first attempt.
The destination dataset is set readonly=on so accidental writes on
pvemini cannot diverge it. Snapshot pruning keeps 5 rolling copies.
nightly-backup-mirror.sh ships a third copy nightly to pve1's
backup-ssd (ext4 SATA) — different physical disk, different
filesystem, different node — guarding against the failure mode where
both pveelite and pvemini are simultaneously unavailable. The same
script tars /etc/pve and rotates 14 days of cluster config archives,
since pmxcfs is in-RAM and a multi-node quorum loss would otherwise
take cluster config with it.
The old directory is kept as oracle-backups.old-DELETE-AFTER-2026-05-02
on pveelite for one week as a safety net.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
