1c6ab0fa68
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