feat(replicare): LXC 102 replica pe pve1 si pveelite

Docker host-ul era singurul guest fara replicare. Adaugate job-urile 102-0
(pve1, 21:20) si 102-1 (pveelite, 21:21), in sloturi libere. Sync initial
rulat manual: ~88s fiecare, ambele OK.

Prima incercare a esuat cu "No common base snapshot": ambele noduri tinta
aveau volume orfane ramase de la o replicare stearsa candva (pve1 50 GB,
pveelite 30 GB, din epoci diferite, nefolosite). Sterse prin API, apoi sync
complet.

Documentate: capcana volumelor orfane si faptul ca SSH intre noduri trece
prin Tailscale — pentru inspectii pe alt nod se foloseste `pvesh get
/nodes/<nod>/...`, nu ssh imbricat.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv

proxmox/cluster/README.md

@@ -384,11 +384,44 @@ pvesh get /cluster/backup          # lista reala a job-urilor
 
 ### ⚠️ Replicarea ZFS NU e backup
 
-Job-urile din `pvesr status` (LXC 103 → pve1 și pveelite, seara la 21:02/21:03, plus
-celelalte) oglindesc **starea curentă**. O ștergere accidentală sau o corupție ajunge pe
-toate nodurile la următorul sync — nu există niciun punct în timp din care să revii.
-Replicarea protejează împotriva pierderii unui **nod**; backup-ul, împotriva pierderii de
-**date**. Sunt necesare amândouă, pe mecanisme și storage-uri diferite.
+Job-urile din `pvesr status` oglindesc **starea curentă**. O ștergere accidentală sau o
+corupție ajunge pe toate nodurile la următorul sync — nu există niciun punct în timp din care
+să revii. Replicarea protejează împotriva pierderii unui **nod**; backup-ul, împotriva
+pierderii de **date**. Sunt necesare amândouă, pe mecanisme și storage-uri diferite.
+
+Toate guest-urile `running` replică pe alte două noduri (verificat 2026-08-11). LXC 102 a fost
+adăugat atunci — vezi capcana de mai jos.
+
+```bash
+pvesr status                                    # toate job-urile, LastSync, FailCount
+pvesr create-local-job 102-0 pve1 --schedule 21:20
+pvesr run --id 102-0 --verbose                  # sync manual, util la prima rulare
+```
+
+**Capcană: volume orfane blochează re-crearea unei replicări.** Când un job de replicare e
+șters, volumul rămâne pe nodurile țintă. La recreare, sync-ul eșuează imediat cu:
+
+```
+No common base snapshot on volume(s) local-zfs:subvol-102-disk-0
+```
+
+Nu e o problemă de spațiu sau de rețea — pur și simplu există deja un dataset cu acel nume,
+fără snapshot comun din care să continue. Se rezolvă ștergând volumul de pe fiecare țintă,
+apoi rulând sync-ul, care va face o copie completă:
+
+```bash
+pvesh get /nodes/pve1/storage/local-zfs/content --output-format json   # ce e pe nodul tinta
+pvesh delete /nodes/pve1/storage/local-zfs/content/local-zfs:subvol-102-disk-0
+```
+
+Verifică întâi că guest-ul nu rulează pe nodul respectiv — un volum cu `vmid` care trăiește pe
+alt nod e prin definiție orfan. Aici, pve1 avea o copie de 50 GB iar pveelite una de 30 GB,
+din epoci diferite, ambele nefolosite.
+
+> **SSH între noduri trece prin Tailscale** și cere autentificare interactivă, deci
+> `ssh root@10.0.20.201 "ssh pve1 ..."` se blochează. Pentru orice inspecție pe alt nod,
+> folosește `pvesh get /nodes/<nod>/...` — merge din pvemini fără autentificare
+> suplimentară.
 
 ### Guest-uri FĂRĂ backup