docs(kb): document VM 109 SSH-key gap in DR failover, restore correct host

VM 109 a ajuns pe pvemini pe 27 aug fara ca root-ul de acolo sa aiba cheia
SSH autorizata pe Windows guest, ceea ce a stricat testul DR saptamanal
(eroare de auth SSH mascata drept "NFS/restore failed"). Migrat inapoi pe
pveelite (unde cheia originala functioneaza) si documentat gap-ul structural
din procedura de failover/migrare pentru viitor.

memory/kb/tools/infrastructure.md

@@ -283,9 +283,13 @@ ssh echo@10.0.20.202 "sudo pct exec 171 -- df -h /"
 
 - **VMID:** 109 | **Host:** pveelite | **Status:** Stopped (pornit doar pentru DR/test)
 - **IP:** 10.0.20.37 | **OS:** Windows Server + Oracle 19c
-- **HA group:** ha-prefer-pveelite | state=stopped, nofailback=1
+- **HA:** e în HA — grup `ha-prefer-pveelite`, resource `vm:109`, `state=stopped` (pornit doar de test-ul săptămânal). Verificat 29 aug 2026 cu `pvesh get /cluster/ha/resources/vm:109`.
+- **Replicare ZFS:** job standing `oracle-dr-windows` (109-0, 109-1): `pveelite → pve1` și `pveelite → pvemini`, zilnic 20:00 (`pvesh get /cluster/replication`). Asta ține câte o copie caldă a discului pe toate 3 nodurile — de-asta o migrare `qm migrate` între noduri e rapidă (refolosește replica existentă ca bază incrementală).
 - **Scop:** Disaster Recovery pentru Oracle Database (backup RMAN de pe server Windows extern)
 
+**Incident 2026-08-27 → 2026-08-29 (rezolvat):** VM 109 a ajuns migrat pe pvemini (motiv exact neclar — posibil legat de evenimentele UPS din jurul datei de 27 aug, vezi `/opt/scripts/ups-battery-trend-backfill.sh` cu timestamp similar). Testul DR de sâmbătă (29 aug) a eșuat cu `Permission denied` / `Too many authentication failures` la SSH către `romfast@10.0.20.37:22122` — **nu pentru că NFS sau restore-ul chiar ar fi stricate**, ci pentru că root-ul de pe pvemini nu are cheia SSH privată care se potrivește cu singura cheie autorizată în `C:\Users\romfast\.ssh\authorized_keys` (`ssh-rsa ... mmarius28@gmail.com`) — cheia aia există doar în `/root/.ssh` pe pveelite. **Gap structural:** procedura de failover/migrare (`failover-dr-to-pvemini.sh`, `DR_VM_MIGRATION_GUIDE.md`) mută storage-ul NFS și scripturile de transfer, dar nu sincronizează niciodată cheia SSH root între noduri — orice migrare reală (nu doar failover de storage) către alt nod decât pveelite va rupe din nou testul DR în același fel, până nu se copiază manual `/root/.ssh/id_rsa{,.pub}` de pe pveelite pe nodul țintă (necesită acces root — contul `echo` cu care rulează automatizările nu are voie, sudo e restrâns la `qm`/`pct`/`pvesh`/`crontab -l`).
+Fix aplicat: `qm migrate 109 pveelite --with-local-disks` (offline, VM era oprit) — a mutat config-ul înapoi pe pveelite, unde cheia originală funcționează deja. Verificat după: guest agent răspunde, `Test-Path F:\ROA\autobackup` → `True`, `authorized_keys` neschimbat. Testul SSH complet ca root (identic cu ce rulează cron-ul) nu a putut fi verificat direct (același motiv de acces), dar pveelite nu a fost atins deloc în tot incidentul, deci ar trebui să funcționeze ca înainte de 27 aug — confirmare finală abia sâmbăta viitoare (05 sep, 06:00) sau printr-o rulare manuală a scriptului ca root.
+
 **Oracle Database:**
 - DB Name: ROA | Dimensiune: ~80 GB | Tabele: 42.625
 - Strategie: full backup zilnic (6-7 GB) + cumulative incremental (200-300 MB)
@@ -357,6 +361,8 @@ ssh echo@10.0.20.201 "sudo qm status 302"
 - `ups-monthly-test.sh` — 1 ale lunii, test baterie UPS
 - `ups-maintenance-shutdown.sh` — shutdown mentenanță UPS
 - `vm107-monitor.sh` — monitorizare VM 107
+- `failover-dr-to-pvemini.sh` / `failback-dr-to-pveelite.sh` — failover manual storage NFS Oracle DR (vezi § VM 109); NU sincronizează cheia SSH root
+- `weekly-dr-test-proxmox.sh` — instalat aici și pe pveelite; guard intern rulează testul doar pe host-ul cu `/etc/pve/qemu-server/109.conf` local — de obicei sărit aici, doar dacă VM 109 chiar rulează pe pvemini
 
 ### pveelite (10.0.20.202)
 - **Resurse:** 16GB RAM, 557GB disk (+ 8GB ZFS swap — adăugat 2026-04-20 anti-OOM)
@@ -366,7 +372,7 @@ ssh echo@10.0.20.201 "sudo qm status 302"
 
 **Scripturi `/opt/scripts/`:**
 - `oracle-backup-monitor-proxmox.sh` — zilnic 21:00, verifică backup Oracle
-- `weekly-dr-test-proxmox.sh` — sâmbătă 06:00, test restore Oracle DR (VM 109)
+- `weekly-dr-test-proxmox.sh` — sâmbătă 06:00, test restore Oracle DR (VM 109) — rulează efectiv de aici cât timp config-ul VM 109 e local
 
 ### pve1 (10.0.20.200)
 - **Resurse:** 32GB RAM, 1.3TB disk