Playbook di Disaster Recovery per Proxmox: ricostruire il cluster da PBS, immagini VM e configurazione

Un Disaster‑Recovery‑Playbook per Proxmox è indispensabile per ogni responsabile delle operazioni: questo playbook descrive in modo pratico come ricostruire un cluster Proxmox dopo una perdita totale o un guasto grave utilizzando Proxmox Backup Server (PBS), immagini VM e file di configurazione. È rivolto ad amministratori, System Engineers, operatori e fornitori di servizi IT tecnici e si concentra su esercizio operativo, interfacce, verifiche e strategie di fallback. La parola chiave focus Disaster‑Recovery‑Playbook für Proxmox è posta intenzionalmente nell’introduzione, perché corrisponde con precisione all’intento di ricerca e al valore pratico dell’articolo.

Playbook di Disaster Recovery per Proxmox: perché un playbook e quando entra in gioco

Un playbook crea chiarezza in situazioni di stress: definisce sequenze, responsabilità, tempistiche e verifiche. Scatta quando il cluster produttivo non avvia più, /etc/pve è perso, Corosync non trova quorum o lo storage primario è danneggiato in modo irreparabile. Presupposto centrale è che disponiate di backup PBS validi e di copie delle configurazioni del cluster (ad es. provenienti da routine di esportazione automatizzata).

Definizione dei termini (breve)

Proxmox VE è la piattaforma di virtualizzazione. Proxmox Backup Server (PBS) è l’appliance di backup dedicata per snapshot e backup deduplicati. pmxcfs è il filesystem di configurazione distribuito (control plane config) di Proxmox, Corosync è lo strato di comunicazione/quorum del cluster. Le configurazioni delle VM si trovano in /etc/pve/qemu-server/ (KVM) e /etc/pve/lxc/ (LXC).

Preparazione: prerequisiti, ruoli e priorità

Prima di avviare un RESTore, chiarite i seguenti punti:

• RTO/RPO per categoria VM: definite quali VM devono essere ricostruite immediatamente e quali in seguito.
• Supporti disponibili: accesso al repository PBS, copie di archivio e, se presente, copie offsite.
• Ruoli: Incident Lead, Storage Operator, Network Operator, PBS‑Operator, App‑Owner.
• Comunicazione: canali, report di stato e regole di change‑freeze durante il recovery.

Stabilite le priorità: iniziate con il ripristino della control plane, poi lo storage, successivamente le VM critiche e infine i sistemi meno critici.

Analisi iniziale: definire l’ambito

Analizzate sistematicamente l’entità del guasto: hardware spento, pmxcfs corrotto, partizione di rete o PBS perso? Verificate se singoli node sono raggiungibili e se i repository PBS sono accessibili via SSH/HTTPS. Documentate lo stato riscontrato e create un incident log.

Ripristino della control plane (pmxcfs/Corosync)

La control plane gestisce le configurazioni del cluster. Se almeno un node è integro, verificate lo stato:

pvecm status
systemctl status pve-cluster
systemctl status corosync

Se nessun node è disponibile, predisponete un nuovo nodo iniziale (seed node). PRESTate attenzione esatta a hostname e piano IP, poiché Corosync e DNS/hosts richiedono una risoluzione dei nomi coerente. Inizializzate un cluster solo se non disponete di un’altra fonte pmxcfs:

pvecm create mycluster

Nota: la creazione di un nuovo cluster sovrascrive un pmxcfs esistente. Se disponete di una copia sicura di /etc/pve o di un file di export, preferite il ripristino di questi dati invece della creazione ex novo.

Ricostruire pmxcfs da backup

Se possedete un backup consistente di /etc/pve o di un export di pmxcfs, ripristinate questi file sulla seed node. Procedura tipica: un archivio tar della struttura /etc/pve che copiate sulla seed node e quindi riavviate il servizio pve-cluster:

# auf Seed‑Node
rsync -av --progress /mnt/backup/etc-pve-backup/ /etc/pve/
systemctl RESTart pve-cluster
systemctl RESTart corosync

Perché: /etc/pve è la Control‑Plane; i suoi file definiscono gli ID delle VM, le assegnazioni di storage e la rete. Rischi: stati di versione incoerenti o alias di storage mancanti possono impedire ai nodi di partecipare correttamente al cluster.

Corosync, Quorum e Fencing

I problemi di quorum sono insidie frequenti. Evitate lo split‑brain testando il fencing (separazione automatica di un nodo che il cluster considera difettoso). Se utilizzate un QDevice (dispositivo di quorum esterno), assicuratevi della sua raggiungibilità.

Verificate lo stato del quorum:

pvecm status
# oder
corosync-cmapctl | head

Se un nodo non è più raggiungibile, rimuovetelo in modo ordinato o adeguate i voti attesi, ma documentate ogni passaggio e tenete pronti i comandi di rollback.

PBS: Verificare l’accesso e ripristinare il repository

Assicuratevi che i repo PBS siano disponibili. Verificate raggiungibilità, certificati e accessi utente. Se PBS è stato distrutto, reinstallate PBS e sincronizzate i file del datastore (rsync o Storage‑Replica). Copiate i file solo se comprendete come PBS utilizza le sue strutture dati interne (chunks, indexes): una copia incompleta può corrompere i repository.

# Beispiel: rsync eines PBS‑Datastores (nur, wenn Storage‑Kopie valide ist)
rsync -av --progress /mnt/offsite/pbs-datastore/ /var/lib/proxmox-backup/datastore/

Validazione: utilizzate la WebUI di PBS o la CLI per elencare i datastore e gli snapshot prima di avviare i ripristini.

Strategie di ripristino delle VM e implementazione dettagliata

Scegliete, a seconda della situazione, tra tre opzioni:

1. qmRESTore: ripristino diretto di archivi vzdump; crea la configurazione della VM e i dischi.
2. qm importdisk + qm set: importazione di immagini disco raw e successiva configurazione manuale della VM.
3. pct RESTore: per container LXC con controllo dei bind‑mount.

qmRESTore – raccomandazione per VM testate

qmRESTore /backup/vzdump-qemu-101-2026_01_01.vma.zst 101 --storage local-lvm
# optional: sofort starten
qm start 101

Rischi: qmRESTore si aspetta ID di storage corrispondenti. Se lo storage di destinazione ha un nome diverso, create alias di storage temporanei o usate qm importdisk.

qm importdisk – più flessibile nel mapping dello storage

qm create 101 --name RESTored-101 --memory 4096 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 101 vm-101-disk-1.qcow2 local-lvm
qm set 101 --scsi0 local-lvm:vm-101-disk-1
qm set 101 --boot c --bootdisk scsi0

Vantaggio: mantenete il controllo su pool Thin/Thick e tipi di storage. Dopo l’import potrebbe mancare la configurazione meta della VM (cloud‑init, qemu‑agent). Integratela manualmente o tramite script di template.

Container (LXC) – pct RESTore

pct RESTore 102 /backup/vzdump-lxc-102-2026_01_01.tar.lzo --storage local
pct set 102 --net0 name=eth0,bridge=vmbr0,ip=dhcp
pct start 102

Verificate bind‑mount, profili AppArmor e privilegi dopo il ripristino.

Basi dati e backup consistenti

Le VM di database richiedono procedure di recovery accuratamente coordinate: o disponete di snapshot consistenti (quiesced backups) oppure eseguite passaggi di DB‑recovery aggiuntivi (WAL‑Replay, Replikations‑Rebuild). Per PostgreSQL, ad esempio, verificate i segmenti WAL ed eventualmente eseguite i passaggi di PITR. Per MySQL verificate le posizioni del Binlog e, se possibile, preferite una reinizializzazione della replica rispetto a complesse riparazioni del Binlog.

Crittografia: Header LUKS e gestione delle chiavi

Se i volumi disco erano cifrati, gli Header LUKS e il materiale delle chiavi sono critici. Conservate gli Header LUKS separatamente. Se gli header sono danneggiati, l’accesso ai dati è spesso impossibile. Documentate e testate i meccanismi di sblocco remoto (p. es. Network‑Unlocked LUKS o server di chiavi).

Tipi di storage: LVM, ZFS, Ceph – particolarità

Ogni tipo di storage ha regole di recovery proprie:

• LVM: attivate le Volume‑Group e verificate i Thin‑Pools. Usate lvdisplay e vgchange -ay.
• ZFS: importate i pool con zpool import -f e verificate errori con zpool scrub.
• Ceph: avviate prima i monitor (MON), verificate con ceph -s e ripristinate gli OSD. Il recupero di un cluster Ceph può essere complesso; prevedete tempo sufficiente e seguite le best practices di Ceph.

# Beispiel: LVM aktivieren
vgchange -ay
lvdisplay
# Beispiel: Ceph Status prüfen
ceph -s

Conflitti di configurazione: Storage‑IDs, MACs und Netzwerke

I problemi comuni dopo un RESTore sono Storage‑ID‑Mismatch e indirizzi MAC duplicati. Controllate /etc/pve/qemu-server/*.conf per identificatori di storage obsoleti e adeguateli. Esempio di una VM‑conf (estratto):

# /etc/pve/qemu-server/101.conf
boot: cdn
cores: 4
memory: 4096
scsi0: local-lvm:vm-101-disk-1,size=50G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0

Se gli indirizzi MAC causano conflitti, modificateli prima dell’avvio e documentate le modifiche. Usate qm set per le modifiche invece di manipolare direttamente i file, se possibile.

Validazione e Smoke‑Tests (dettagliato)

La validazione non è opzionale. Per ogni VM ripristinata eseguite almeno:

1. Controllare la console seriale/log di boot per errori del kernel (GUI/Web o qm monitor).
2. Test di rete: ping, traceroute, risoluzione DNS e verifiche delle porte.
3. Smoke applicativo: controlli HTTP/HTTPS di health, test di connessione DB, verificare i job in background.
4. Integrità dei dati: checksum delle directory critiche o controlli applicativi (p. es. SELECT COUNT(*) per tabelle con valore di riferimento).

# Beispiel Smoke‑Test
ssh admin@vm-ip 'systemctl is-active postgresql && curl -sfS http://localhost:8080/health'
# Prüfsummevergleich
ssh admin@vm-ip 'sha256sum /var/lib/app/data/important.db | cut -d" " -f1'

Automazione e script: robusti, idempotenti e auditati

Automatizzate i task ricorrenti, ma non le decisioni critiche. Uno script Bash idempotente per il batch‑RESTore riduce gli errori, registra i passaggi e consente un’esecuzione controllata. Esempio (esteso):

#!/bin/bash
# batch_RESTore_checked.sh
set -euo pipefail
MAPFILE=${1:-RESTore-map.csv}
LOG=/var/log/proxmox-recovery.log
exec &> >(tee -a "$LOG")
while IFS=, read -r backup vmid storage ; do
  echo "[INFO] RESToring $backup to VM $vmid on $storage"
  if [ ! -f "$backup" ]; then
    echo "[WARN] Backup $backup missing, skipping"
    continue
  fi
  # Quick storage check
  if ! pvesm status | grep -q "$storage" ; then
    echo "[ERROR] Storage $storage not present, aborting for $vmid"
    continue
  fi
  qmRESTore "$backup" "$vmid" --storage "$storage" || { echo "[ERROR] qmRESTore failed for $vmid"; continue; }
  echo "[OK] RESTore triggered for $vmid"
done < "$MAPFILE"

Strategia di fallback: cosa fare se il RESTore fallisce?

Abbiate un piano B: se i RESTore falliscono, potete:

• Provisionare manualmente le VM (installer + import dati) per servizi critici per il business.
• Fare ricorso a repliche in sola lettura o a snapshot precedenti.
• Allentare temporaneamente impostazioni di rete/security se impediscono l’avvio (es. regole firewall).

È fondamentale definire limiti di tempo e punti decisionali: dopo X ore di recovery il responsabile dell’incidente passa al Piano B per rispettare il RTO complessivo.

Sezione speciale Hyper‑V: lezioni trasferibili

Anche se questo playbook è focalizzato su Proxmox, alcuni principi sono trasferibili a Hyper‑V. Su Hyper‑V sono critici gli export VHD(X), lo stato della configurazione Hyper‑V (export/import) e gli host Hyper‑V (failover cluster). Importante è: export VM consistenti, verifica di CSV/NAS/SMB mount e mappatura di rete (vSwitch). Testate i workflow di import/attach in un ambiente preprod prima di doverci fare affidamento in emergenza.

Post‑Recovery: hardening, lezioni apprese, documentazione

Dopo il RESTore eseguite un’analisi post‑mortem, documentate le modifiche e regolate backup, test e responsabilità. Adeguate RTO/RPO ai valori misurati durante il drill e pianificate drill successivi per evitare regressioni.

Checklist pratica (compatta)

1. Definire scope e priorità.
2. Ricostruire il control‑plane (pmxcfs/corosync) o predisporre un seed node.
3. Verificare/ripristinare il repository PBS.
4. Montare i target di storage (verificare LVM/ZFS/Ceph).
5. Ripristinare selettivamente le VM con qmRESTore/qm importdisk/pct RESTore.
6. Eseguire il ripristino del database (WAL/Binlog/PITR).
7. Smoke test, verifiche di integrità e controlli applicativi.
8. Documentare le lezioni apprese e pianificare il follow‑up.

Conclusione

Un playbook di disaster recovery affidabile per Proxmox è più di una raccolta di comandi: è un documento operativo con priorità, ruoli, verifiche e strategie di fallback. Testate regolarmente, mantenete aggiornati pmxcfs‑Exports e accessi PBS e automatizzate i controlli di supporto, ma non le decisioni critiche di recovery. In questo modo ridurrete l’RTO ed eviterete errori costosi in situazione reale.

Questa guida è pensata come integrazione modulare della vostra documentazione operativa. Adattatela alla topologia di storage, ai vincoli RTO/RPO e alle vie di comunicazione interne e svolgete RESTore‑drill regolari.

Integrazioni, segreti e aspetti operativi

Spesso sottovalutate: le integrazioni di rete e infrastruttura determinano se un ripristino diventerà effettivamente operativo. Ripristinate prima le infrastrutture centrali — DNS, DHCP, NTP e PKI — prima di avviare gli strati applicativi. In assenza di DNS le VMs possono anche avviarsi, ma risultano irrintracciabili per i servizi; timestamp mancanti (NTP) possono compromettere la replica del database.

Conservate il materiale chiave e i certificati separatamente dal PBS e documentate le procedure di Unseal/Unlock (es. HashiCorp Vault, KMIP). I secret store esterni dovrebbero comparire nel Playbook con test di accesso espliciti.

Nota pratica: impostate gli allarmi di monitoring temporaneamente su «maintenance» per evitare ondate di allarmi, e re-registrate gli host in modo mirato dopo smoke test riusciti. Per applicazioni multi-tier pianificate finestre di snapshot/RESTore coordinate, affinché database e applicazione RESTino coerenti.

Auditate ogni passo di recovery: log, checksum, stati di versione e chi autorizza le modifiche — in questo modo il Playbook diventa affidabile in esercizio e robusto dal punto di vista organizzativo.

Per questo tema sono inoltre importanti il ripristino di immagini VM e il recupero di cluster Proxmox. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.