Playbook de reprise après sinistre pour Proxmox : reconstruire un cluster à partir de PBS, d'images VM et de configurations

Un playbook de reprise après sinistre pour Proxmox est indispensable pour tout responsable d’exploitation : ce playbook décrit de manière pragmatique comment reconstruire un cluster Proxmox après une perte totale ou une panne majeure à l’aide de Proxmox Backup Server (PBS), d’images VM et de fichiers de configuration. Il s’adresse aux administrateurs, System Engineers, opérateurs et pRESTataires techniques IT, et se concentre sur l’exploitation, les interfaces, les contrôles et les stratégies de repli. Le mot‑clé focal « Disaster‑Recovery‑Playbook für Proxmox » est placé volontairement dans l’introduction, car il reflète précisément l’intention de recherche et l’utilité pratique de l’article.

Disaster‑Recovery‑Playbook für Proxmox: Warum ein Playbook und wann es greift

Un playbook apporte de la clarté en situation de stress : il définit l’ordre des opérations, les responsabilités, le calendrier et les contrôles. Il s’applique lorsque le cluster de production ne démarre plus, que /etc/pve est perdu, que Corosync ne trouve pas le quorum ou que le stockage primaire est irréparablement endommagé. Condition centrale : vous disposez de sauvegardes PBS valides et de copies des configurations du cluster (par ex. issues d’une routine d’export automatisée).

Begriffsklärung (kurz)

Proxmox VE est la plateforme de virtualisation. Proxmox Backup Server (PBS) est l’appliance de sauvegarde dédiée pour snapshots et sauvegardes dédupliquées. pmxcfs est le système de fichiers de configuration distribué (control plane config) de Proxmox, Corosync assure le quorum et la couche de communication du cluster. Les configurations de VM se trouvent dans /etc/pve/qemu-server/ (KVM) et /etc/pve/lxc/ (LXC).

Vorbereitung: Voraussetzungen, Rollen und Prioritäten

Avant de commencer une RESTauration, clarifiez les points suivants :

• RTO/RPO pro VM‑Kategorie: définissez quelles VMs doivent être reconstruites immédiatement et lesquelles peuvent l’être ultérieurement.
• Verfügbare Medien: accès au repository PBS, copies d’archive et, le cas échéant, copies hors site.
• Rollen: Incident Lead, Storage Operator, Network Operator, PBS‑Operator, App‑Owner.
• Kommunikation: canaux, messages d’état et règles de change‑freeze pendant la récupération.

Priorisez : commencez par la RESTauration de la control‑plane, puis le stockage, ensuite les VMs critiques et enfin les systèmes moins critiques.

Erste Analyse: Scope bestimmen

Analysez systématiquement l’étendue de la panne : matériel HS, pmxcfs corrompu, partition réseau ou PBS perdu ? Vérifiez si des nœuds individuels sont joignables et si les repos PBS sont accessibles via SSH/HTTPS. Documentez l’état constaté et ouvrez un incident‑log.

Control‑Plane (pmxcfs/Corosync) wiederherstellen

La control‑plane gère les configurations du cluster. Si au moins un nœud est opérationnel, vérifiez l’état :

pvecm status
systemctl status pve-cluster
systemctl status corosync

Si aucun nœud n’est disponible, déployez un nouveau premier nœud (Seed Node). Veillez strictement au hostname et au plan d’adressage IP, car Corosync et DNS/Hosts exigent une résolution de noms cohérente. N’initialisez un cluster que si vous ne disposez d’aucune autre source pmxcfs :

pvecm create mycluster

Remarque : la création d’un nouveau cluster écrase un pmxcfs existant. Si vous disposez d’une copie sauvegardée de /etc/pve ou d’un fichier d’export, privilégiez la RESTauration de ces données plutôt que la création d’un nouveau cluster.

pmxcfs aus Backup rekonstruieren

Si vous possédez une sauvegarde cohérente de /etc/pve ou un export de pmxcfs, déployez ces fichiers sur la Seed‑Node. La procédure typique consiste en une archive tar de la structure /etc/pve que vous copiez sur la Seed‑Node, puis au redémarrage du pve‑Cluster‑Service :

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

Pourquoi : /etc/pve est le plan de contrôle ; ses fichiers définissent les VM‑IDs, les affectations de storage et le réseau. Risques : des états de version incohérents ou des Storage‑Aliases manquants peuvent empêcher les nœuds de rejoindre correctement.

Corosync, Quorum und Fencing

Les problèmes de quorum sont des pièges fréquents. Évitez le split‑brain en testant le fencing (déconnexion automatique d’un nœud que le cluster considère défaillant). Si vous utilisez un QDevice (dispositif de quorum externe), assurez‑vous de sa joignabilité.

Vérifiez l’état du quorum :

pvecm status
# oder
corosync-cmapctl | head

Si un nœud n’est plus joignable, retirez‑le proprement ou ajustez les votes attendus, mais documentez chaque étape et préparez des commandes de reprise.

PBS: Zugriff prüfen und Repository wiederherstellen

Assurez‑vous que les dépôts PBS sont disponibles. Vérifiez la connectivité, les certificats et les accès utilisateurs. Si PBS lui‑même a été détruit, réinstallez PBS et synchronisez les fichiers du datastore (rsync ou Storage‑Replica). Ne copiez des fichiers que si vous comprenez comment PBS utilise ses structures de données internes (chunks, indexes) — une copie incomplète peut corrompre les dépôts.

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

Validation : utilisez la WebUI de PBS ou la CLI pour lister les datastores et les snapshots avant de lancer des RESTaurations.

VM‑RESTore‑Strategien und detaillierte Umsetzung

Selon la situation, choisissez entre trois approches :

1. qmRESTore : RESTauration directe d’archives vzdump, qui recrée la configuration VM et les disques.
2. qm importdisk + qm set : import d’images disque brutes et configuration manuelle ultérieure de la VM.
3. pct RESTore : pour les conteneurs LXC, avec vérification des bind‑mounts.

qmRESTore – Empfehlung für getestete VMs

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

Risques : qmRESTore attend des Storage‑IDs compatibles. Si le storage cible porte un autre nom, créez des alias de stockage temporaires ou utilisez qm importdisk.

qm importdisk – flexibler bei Storage‑Mapping

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

Avantage : vous conservez le contrôle sur les Thin/Thick‑Pools et les types de storage. Après l’import, il peut manquer la méta‑configuration de la VM (cloud‑init, qemu‑agent). Complétez‑la manuellement ou via un script 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

Vérifiez les bind‑mounts, les profils AppArmor et les privilèges après la RESTauration.

Datenbanken und konsistente Backups

Les VM de bases de données nécessitent des étapes de récupération soigneusement coordonnées : soit vous disposez de snapshots cohérents (quiesced backups), soit vous effectuez des étapes supplémentaires de récupération DB (WAL‑Replay, reconstruction de réplication). Pour PostgreSQL, par exemple, vérifiez les segments WAL et exécutez, si nécessaire, les étapes PITR. Pour MySQL, vérifiez les positions du binlog et, si possible, privilégiez une réinitialisation de la réplication plutôt qu’une réparation complexe du binlog.

Chiffrement: LUKS‑Header und Schlüsselmanagement

Si les volumes disque étaient chiffrés, les LUKS‑Header et le matériel de clés sont critiques. Conservez les LUKS‑Header séparément. Si les header sont endommagés, l’accès aux données est souvent impossible. Documentez et testez les mécanismes de déverrouillage à distance (p. ex. Network‑Unlocked LUKS ou serveurs de clés).

Storage‑Typen: LVM, ZFS, Ceph – Besonderheiten

Chaque type de stockage a ses propres règles de récupération :

• LVM: activez les Volume‑Groups et vérifiez les Thin‑Pools. Utilisez lvdisplay et vgchange -ay.
• ZFS: importez les pools avec zpool import -f et vérifiez les erreurs avec zpool scrub.
• Ceph: remettez d’abord les Monitore (MON), vérifiez ceph -s et RESTaurez les OSD. La récupération d’un cluster Ceph peut être complexe ; prévoyez suffisamment de temps et suivez les Ceph‑Best‑Practices.

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

Konfigurationskonflikte: Storage‑IDs, MACs und Netzwerke

Les problèmes fréquents après RESTauration sont les Storage‑ID‑Mismatch et les adresses MAC dupliquées. Vérifiez /etc/pve/qemu-server/*.conf pour les identifiants de stockage obsolètes et adaptez‑les. Exemple d’une VM‑conf (extrait) :

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

Si des adresses MAC provoquent des conflits, modifiez‑les avant le démarrage et documentez les ajustements. Utilisez qm set pour les modifications plutôt que d’éditer directement les fichiers, si possible.

Validation und Smoke‑Tests (detailliert)

La validation n’est pas optionnelle. Pour chaque VM RESTaurée, effectuez au minimum :

1. Contrôler la console série/le journal de démarrage pour détecter les erreurs du noyau (GUI/Web ou qm monitor).
2. Tests réseau : ping, traceroute, résolution DNS et vérification des ports.
3. Smoke applicatif : contrôles HTTP/HTTPS, tests de connexion DB, vérification des jobs en arrière‑plan.
4. Intégrité des données : sommes de contrôle des répertoires critiques ou contrôles applicatifs (p. ex. SELECT COUNT(*) pour des tables avec valeur de référence).

# 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'

Automatisierung und Skripte: robust, idempotent und auditiert

Automatisez les tâches récurrentes, mais pas les décisions critiques. Un script Bash idempotent pour la RESTauration par lot réduit les erreurs, consigne les étapes et permet une exécution contrôlée. Exemple (étendu) :

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

Stratégie de repli : que faire si la RESTauration échoue ?

Ayez un plan B : si les RESTaurations échouent, vous pouvez :

• Reprovisionner manuellement les VMs (installateur + import des données) pour les services critiques.
• Revenir à des répliques en lecture seule ou à d’anciens snapshots.
• Assouplir temporairement les paramètres réseau/sécurité s’ils empêchent le démarrage (par ex. règles de pare‑feu).

Il est essentiel de définir des limites temporelles et des points de décision : après X heures de récupération, le responsable incident passe au plan B afin de respecter le RTO global.

Section spéciale Hyper‑V : enseignements transférables

Même si ce playbook est centré sur Proxmox, certains principes sont transférables à Hyper‑V. Sous Hyper‑V, les exports VHD(X), l’état de la configuration Hyper‑V (export/import) et les hôtes Hyper‑V (cluster de basculement) sont critiques. Points importants : exports VM cohérents, vérification des montages CSV/NAS/SMB et mapping réseau (vSwitch). Testez les workflows d’import/attach dans un environnement de préproduction avant de dépendre d’eux en situation d’urgence.

Post‑recovery : durcissement, retours d’expérience, documentation

Après la RESTauration, réalisez une analyse post‑mortem, documentez les changements et ajustez les sauvegardes, les tests et les responsabilités. Adaptez le RTO/RPO aux mesures réalistes issues des exercices et planifiez des exercices de suivi pour éviter les régressions.

Checklist pratique (compacte)

1. Définir le périmètre et les priorités.
2. Reconstruire le control‑plane (pmxcfs/corosync) ou créer un seed‑node.
3. Vérifier / RESTaurer le PBS‑repository.
4. Monter les targets de stockage (vérifier LVM/ZFS/Ceph).
5. RESTaurer sélectivement les VMs avec qmRESTore / qm importdisk / pct RESTore.
6. Effectuer la récupération des bases de données (WAL/Binlog/PITR).
7. Smoke‑tests, vérifications d’intégrité et contrôles applicatifs.
8. Documenter les retours d’expérience et planifier les actions de suivi.

Conclusion

Un playbook de disaster recovery pour Proxmox robuste est plus qu’une collection de commandes : c’est un document opérationnel définissant priorités, rôles, contrôles et stratégies de repli. Testez régulièrement, maintenez à jour les exports pmxcfs et les accès PBS, et automatisez les vérifications d’assistance, mais pas les décisions critiques de récupération. Ceci réduit le RTO et évite des erreurs coûteuses en cas d’incident.

Cette instruction est conçue comme un complément modulaire à votre documentation opérationnelle. Adaptez‑la à votre topologie de stockage, aux exigences RTO/RPO et aux voies de communication internes, et réalisez régulièrement des exercices de RESTauration.

Intégrations, secrets et aspects opérationnels

Souvent sous-estimées : les intégrations réseau et d’infrastructure déterminent si une RESTauration devient réellement productive. Rétablissez d’abord les infrastructures centrales — DNS, DHCP, NTP et PKI — avant de démarrer les couches applicatives. En l’absence de DNS, les VMs démarrent certes, mais RESTent introuvables pour les services ; l’absence d’horodatage (NTP) peut compromettre la réplication des bases de données.

Sauvegardez le matériel clé et les certificats séparément du PBS et documentez les procédures d’Unseal/Unlock (p. ex. HashiCorp Vault, KMIP). Les magasins de secrets externes doivent apparaître dans le playbook avec des tests d’accès explicites.

Conseil pratique : passez temporairement les alarmes de monitoring en « maintenance » pour éviter une avalanche d’alertes, et réenregistrez les hôtes de manière ciblée après des tests de fumée réussis. Pour les applications multi‑niveaux, planifiez des fenêtres de snapshot/RESTauration coordonnées afin de maintenir la cohérence entre base de données et application.

Auditez chaque étape de récupération : journaux, sommes de contrôle, états de version et qui valide les modifications — ainsi le playbook devient sûr en exploitation et résilient sur le plan organisationnel.

La RESTauration d’images VM et la récupération de clusters Proxmox sont également importantes pour ce sujet. L’article remet ces aspects en perspective de manière compréhensible et montre ce qui compte au quotidien.