romfast/ROMFASTSQL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Marius
2026-08-11 09:33:07 +03:00
parent 96311413a6
commit a19af545a7
1 changed files with 38 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
proxmox/cluster/README.md
View File

@@ -384,11 +384,44 @@ pvesh get /cluster/backup # lista reala a job-urilor
### ⚠️ Replicarea ZFS NU e backup ### ⚠️ Replicarea ZFS NU e backup
Job-urile din `pvesr status` (LXC 103 → pve1 și pveelite, seara la 21:02/21:03, plus Job-urile din `pvesr status` oglindesc **starea curentă**. O ștergere accidentală sau o
celelalte) oglindesc **starea curentă**. O ștergere accidentală sau o corupție ajunge pe corupție ajunge pe toate nodurile la următorul sync — nu există niciun punct în timp din care
toate nodurile la următorul sync — nu există niciun punct în timp din care să revii. să revii. Replicarea protejează împotriva pierderii unui **nod**; backup-ul, împotriva
Replicarea protejează împotriva pierderii unui **nod**; backup-ul, împotriva pierderii de pierderii de **date**. Sunt necesare amândouă, pe mecanisme și storage-uri diferite.
**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 ### Guest-uri FĂRĂ backup