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/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"