fix(cluster): retentie snapshot pe destinatie + PATH in alerta, si cauza din spatele resetarilor USB

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

proxmox/cluster/failover/pvemini-down-alert.sh

@@ -4,6 +4,11 @@
 # Stateful: alertează o dată după 2 minute consecutive DOWN, reset la UP
 set -euo pipefail
 
+# Cron rulează cu PATH minimal (/usr/bin:/bin). ha-manager e în /usr/sbin, deci
+# fără linia asta secțiunea "HA status" din alertă iese goală, tăcut:
+#   /opt/scripts/pvemini-down-alert.sh: line 38: ha-manager: command not found
+export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+
 PRIMARY_IP=10.0.20.201
 STATE=/var/run/pvemini-down-alert.state
 MAIL_TO=mmarius28@gmail.com

proxmox/cluster/incidents/2026-08-27-pveelite-down.md

@@ -5,8 +5,10 @@ dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și repli
 pveelite e oprită)
 **Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email)
 **Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică)
-**Status:** **REZOLVAT** — cauză confirmată din jurnal. Rămâne o acțiune de fond:
-mutarea rețelei de pe adaptorul USB pe `eno1`
+**Status:** **REZOLVAT** — cauză confirmată din jurnal. Pe 28.08 s-a găsit și cauza din
+spatele ei: un **mouse USB defect** care se re-enumera de ~1.000 de ori pe zi pe **același
+controller xHCI** ca adaptorul de rețea (vezi secțiunea dedicată). Portul lui e dezactivat
+din 11:24, ca experiment reversibil. Rămâne acțiunea de fond: mutarea rețelei pe `eno1`
 **Author:** Claude Code (mmarius28@gmail.com)
 
 ---
@@ -110,6 +112,66 @@ pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O.
 
 ---
 
+### DE CE se reseta adaptorul: un mouse defect (2026-08-28, ora 11:20)
+
+Secțiunea de mai sus explică *ce* s-a rupt — interfața recreată, nereatașată în punte. Nu
+explica însă **de ce adaptorul se reseta**, iar concluzia implicită („adaptoarele USB de
+rețea sunt nesigure prin natura lor") s-a dovedit greșită.
+
+**Un mouse optic defect, pe același controller xHCI, se re-enumera de o mie de ori pe zi.**
+
+| Dispozitiv | Port | Re-enumerări în boot-ul curent (43 h) |
+|---|---|---|
+| USB Optical Mouse (PixArt, `0461:4e84`) | hub `1-1`, port 1 | **1.127** — una la ~60 s |
+| USB Multimedia Keyboard (Logitech, `046d:c313`) | hub `1-1`, port 4 | **1** |
+
+Tastatura, pe **același hub**, e perfect stabilă. Asta elimină hub-ul, cablul spre hub și
+controllerul ca vinovați: defectul e în mouse (sau în cablul lui).
+
+Mouse-ul stă pe root hub-ul USB2, adaptorul LAN pe cel USB3, dar **ambele atârnă de același
+controller PCI, `xhci_hcd 0000:00:14.0`**:
+
+```
+/sys/devices/pci0000:00/0000:00:14.0   <- mouse   (usb1 / 1-1.1)
+/sys/devices/pci0000:00/0000:00:14.0   <- adaptor LAN (usb2 / 2-3)
+```
+
+Lanțul se vede curat la resetul din 28.08, ora 10:31 — mouse-ul se re-enumeră, iar
+**trei secunde mai târziu** controllerul dă eroare și placa de rețea cade colateral:
+
+```
+10:31:36  usb 1-1.1: new low-speed USB device number 90        <- mouse, a 90-a oară
+10:31:39  r8152-cfgselector 2-3: USB disconnect, device number 6
+10:31:39  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
+10:31:39  r8152 2-3:1.0 enx6c1ff71abe67: Tx status -108
+```
+
+Toate cele 3 erori `xhci_hcd ... WARN` din boot-ul curent apar lipite de câte o resetare
+r8152. Aceeași eroare deschide și citatul de la 16:01:45 din secțiunea precedentă — deci
+și căderea de 16 ore intră pe același tipar.
+
+**Mitigare aplicată la 11:24:04** — portul mouse-ului dezactivat din sysfs, fără acces fizic:
+
+```bash
+echo 1 > /sys/bus/usb/devices/1-1:1.0/1-1-port1/disable   # anulare: echo 0
+```
+
+Mouse-ul dispare din `lsusb`, tastatura rămâne. **NU e persistent la reboot** — e deliberat,
+ca să fie un experiment reversibil, nu o reparație.
+
+**De verificat înainte de a declara cauza confirmată:** dacă până la următoarea repornire nu
+mai apare nicio resetare `r8152`, ipoteza e validată și mitigarea merită făcută permanentă
+(regulă udev sau, mai bine, mouse-ul scos fizic — pveelite e nod headless).
+
+```bash
+ssh root@10.0.20.202 'journalctl --since "2026-08-28 11:24" | grep -cE "r8152.*reset|xhci_hcd 0000:00:14.0: WARN"'
+```
+
+> Mutarea pe `eno1` rămâne validă și după asta — scoate rețeaua nodului de pe magistrala USB
+> cu totul. Dar ea era tratamentul; abia acum se știe boala.
+
+---
+
 ### Ipoteza alternativă, formulată înainte de confirmare
 
 **pveelite are placă de rețea pe USB**, iar deconectarea ei e modul de defectare deja
@@ -326,9 +388,26 @@ nu era oprită, ci pornită și fără rețea. Un magic packet nu are ce trezi.
 `eno1`, WoL devine însă realmente utilizabil, pentru că e placă integrată, alimentată în
 soft-off — spre deosebire de un dongle USB.
 
-**5. Textul alertei — scos exportul NFS inexistent.**
-`/opt/scripts/pveelite-down-alert.sh` menționează `10.0.20.202:/mnt/pve/oracle-backups`, care
-nu mai e în `storage.cfg`. Cine citește alerta la 3 noaptea o ia pe o pistă falsă.
+**5. ~~Textul alertei — scos exportul NFS inexistent.~~ ALARMĂ FALSĂ, verificat 28.08.**
+Se afirmase că `/opt/scripts/pveelite-down-alert.sh` menționează un export
+`10.0.20.202:/mnt/pve/oracle-backups` care nu mai există, pentru că nu apare în
+`storage.cfg`. **Exportul există și e viu** — nu e storage Proxmox, ci export NFS la nivel
+de sistem către mașina de DR:
+
+```
+# /etc/exports pe pveelite — exportfs -v
+/mnt/pve/oracle-backups  10.0.20.37(rw,sync,no_subtree_check,no_root_squash)
+```
+
+`nfs-server` e `active`, iar datasetul a primit backup-uri RMAN pe 28.08 la 10:11 (`L0_ROA_20260828`,
+6 GB), imediat după revenirea nodului. **Textul alertei e corect, nu se atinge.** Lecția e de
+metodă: absența din `storage.cfg` nu înseamnă absența exportului.
+
+**5-bis. `ha-manager: command not found` în alerta de pe pveelite — REPARAT 28.08.**
+`/opt/scripts/pvemini-down-alert.sh` rula din cron cu PATH minimal (`/usr/bin:/bin`), iar
+`ha-manager` e în `/usr/sbin`. Secțiunea „HA status" ieșea goală la fiecare declanșare, tăcut.
+Adăugat `export PATH=...` — la fel cum avea deja `pveelite-down-alert.sh`. Verificat cu
+`env -i PATH=/usr/bin:/bin`: comanda se rezolvă și întoarce `quorum OK`.
 
 ### 🟡 Tier 2
 
@@ -339,8 +418,35 @@ mecanism care să repare sau măcar să semnaleze o cădere de rețea. Nodul ră
 sănătos și invizibil. Merită o alertă de repetiție (nu doar una la început de incident) sau
 un al doilea inel corosync pe `eno1`, care ar fi ținut nodul în cluster peste căderea USB.
 
-**7. `local-zfs` pe pvemini la 92 %.**
-Separat de incident, dar pe același nod pe care stă acum toată producția.
+**7. ~~`local-zfs` pe pvemini la 92 %.~~ REZOLVAT 28.08 — 93 % → 44 %.**
+Nu era creștere organică. Replicarea `rpool/oracle-backups` (pveelite → pvemini, la 15 min)
+**tăia snapshoturile doar pe sursă**:
+
+```bash
+KEEP_SNAPS=5   # rolling history on source side
+```
+
+Pe destinație nu curăța nimeni, niciodată. Din 25.04 se adunaseră **11.886 snapshoturi care
+țineau 941 GB** — pe nodul cu toată producția. Problema era invizibilă de pe pveelite, unde
+datasetul arăta cuminte, cu 6 snapshoturi.
+
+Reparat în [`zfs-replicate-oracle-backups.sh`](../../vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh):
+`KEEP_SNAPS_DEST=288` (288 × 15 min = 72 h de puncte de recuperare pe destinație, față de
+75 de minute pe sursă). Restanța ștearsă pe interval, cu dry-run înainte:
+
+```
+pvemini rpool:  93 % / 118 G liberi  ->  44 % / 1,01 T liberi
+rpool/oracle-backups:  955 G  ->  45,3 G     snapshoturi:  11.886  ->  288
+```
+
+Verificat în producție: rularea cron de la 11:15 a adăugat un snapshot și a tăiat cel mai
+vechi — destinația a rămas fix la 288.
+
+> **Capcană, dacă vreodată se rescrie curățarea:** ștergerea pe interval (`zfs destroy
+> ds@a%b`) prinde **toate** snapshoturile dintre capete, inclusiv `@failback_` / `@init_`,
+> nu doar cele cu prefixul căutat. De aceea scriptul șterge câte unul (`xargs -n1`), unde
+> oricum e un singur snapshot pe rulare; intervalul s-a folosit o singură dată, manual,
+> după ce s-a verificat că pe destinație nu există niciun snapshot non-`repl_`.
 
 ---
 

proxmox/vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh

@@ -27,6 +27,7 @@ DATASET="rpool/oracle-backups"
 TARGET_HOST="10.0.20.201"     # pvemini direct IP (avoids tailscale magicDNS detour)
 SNAP_PREFIX="repl"
 KEEP_SNAPS=5                  # rolling history on source side
+KEEP_SNAPS_DEST=288           # rolling history on destination (288 x 15 min = 72h)
 LOCK="/var/run/zfs-replicate-oracle-backups.lock"
 LOG="/var/log/oracle-dr/replication.log"
 SSH_OPTS="-o UserKnownHostsFile=/etc/pve/priv/known_hosts -o StrictHostKeyChecking=no -o BatchMode=yes"
@@ -70,4 +71,23 @@ zfs list -t snapshot -o name -s creation "$DATASET" \
     | head -n -${KEEP_SNAPS} \
     | xargs -r -n1 zfs destroy 2>>"$LOG" || true
 
+# Prune old snapshots on destination (keep last KEEP_SNAPS_DEST).
+#
+# Fara pasul asta destinatia nu taia nimic, niciodata. Intre 25.04 si 28.08.2026
+# s-au adunat 11886 snapshoturi care tineau 941G si urcasera rpool-ul pvemini la
+# 93% - cu productia pe acelasi pool. Sursa se curata singura de la inceput, deci
+# problema a fost invizibila pe pveelite.
+#
+# Se sterge cate un snapshot pe rulare (xargs -n1), NU pe interval (@a%b): un
+# range ar cuprinde si eventualele snapshoturi @failback_/@init_ prinse intre
+# capete, care trebuie sa supravietuiasca. In regim normal e un singur destroy
+# la fiecare rulare, deci costul e neglijabil.
+if ! ssh $SSH_OPTS root@${TARGET_HOST} \
+        "zfs list -t snapshot -o name -H -s creation -r '$DATASET' \
+            | awk -v p='${DATASET}@${SNAP_PREFIX}_' '\$0 ~ p' \
+            | head -n -${KEEP_SNAPS_DEST} \
+            | xargs -r -n1 zfs destroy" 2>>"$LOG"; then
+    log "WARNING: prune pe destinatie a esuat (replicarea a reusit)"
+fi
+
 log "Replication completed successfully"