Rulare detasata din dashboard/Discord: nssh local fara ssh la sine, CT 171
ramane pornit si moare odata cu pvemini (HA freeze il reporneste), email cu
instructiunile de pornire, pauza si pentru testul DR si fereastra de patch.
Garda CT 171 nu mai depinde de /proc/1/environ (era sarita fara root).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KddsXCqEbKMhdFJDYbAsx8
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
Runbook nou pentru oprirea controlata a celor 3 noduri (lucrari electrice,
mutare rack, mentenanta UPS) fara ca HA sa relocheze resursele si fara ca
watchdog-ul sa reseteze hard nodul ramas fara quorum.
Doua capcane documentate:
- /etc/pve/datacenter.cfg nu exista => shutdown_policy implicit `conditional`
=> poweroff pe nod declanseaza FAILOVER, nu freeze
- watchdog-ul face reset hard dupa ~60s pe nodul care pierde quorumul cu
servicii HA inca active
Corectii in failover/README.md, verificate pe clusterul live:
- VM 201 ESTE in HA (grup ha-prefer-pvemini), docul spunea ca nu e
- CT 108 e in ha-prefer-pvemini (pvemini:100, pve1:50, pveelite:10),
nu in ha-group-main cu pveelite:50/pve1:33
- replicare CT 108 si VM 201 la */15 min, nu */5 => RPO real 15 min
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
VM 201 (Windows critical) stays out of HA by design. Added:
- failover-vm201.sh: interactive failover pvemini -> pveelite with ZFS replication state
- recover-vm201-to-pvemini.sh: interactive reverse migration with uptime + split-brain checks
- pvemini-down-alert.sh: cron watchdog on pveelite, emails full runbook after 2min DOWN
Replication RPO tightened: CT 108 + VM 201 to 5min, CT 171 to 15min.
CT 171 added to HA (ha-group-main) for continuous Claude Code access.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
