Réplication Proxmox VE : ZFS, Snapshots et Checklist

La réplication native de Proxmox VE 9.1 s'appuie sur ZFS pour assurer la continuité de service grâce à des snapshots delta (transfert incrémental uniquement des blocs modifiés depuis le dernier snapshot) transmis régulièrement entre nœuds du cluster. Ce guide complet présente les prérequis ZFS, la configuration via l'outil CLI pvesr, les mécanismes de snapshots différentiels, le diagnostic des erreurs de réplication et une checklist exhaustive couvrant toutes les étapes de mise en place. La réplication Proxmox diffère de la haute disponibilité (HA) : elle ne bascule pas automatiquement les VMs, mais assure qu'une copie récente existe sur un autre nœud, réduisant le RPO (Recovery Point Objective) à la fréquence de réplication (minimum 15 minutes). Ce guide couvre également les stratégies de reprise après sinistre, les pièges courants à éviter et les meilleures pratiques pour les environnements de production. Indispensable pour tout administrateur Proxmox souhaitant mettre en place une stratégie de résilience des données robuste et testée.

Prérequis ZFS pour la Réplication Proxmox

La réplication Proxmox VE exige que les disques des VMs soient stockés sur des datasets ZFS (type storage ZFS dans Datacenter → Storage). Les stockages LVM, LVM-thin, Ceph, NFS et CIFS ne supportent pas la réplication native. Sur le nœud source, le pool ZFS doit disposer de suffisamment d'espace pour maintenir les snapshots de réplication (prévoir 20-30% d'espace supplémentaire selon le taux de changement des données).

La connectivité SSH entre nœuds est utilisée pour le transfert des snapshots. Proxmox gère automatiquement les clés SSH lors de l'ajout des nœuds au cluster. Vérifier la connectivité : pvesh get /nodes/{node}/status sur chaque nœud. Le port SSH 22 doit être ouvert entre tous les nœuds dans le PVE Firewall.

Prérequis réseau : une bande passante suffisante entre les nœuds est indispensable pour la réplication initiale (peut représenter plusieurs dizaines de Go) et les réplications incrémentielles. Idéalement, utiliser un réseau dédié 10GbE distinct du réseau de gestion. Pour l'architecture réseau détaillée, consultez notre guide d'architecture cluster Proxmox.

Configuration de la Réplication via pvesr CLI

pvesr est l'outil CLI de gestion de la réplication dans Proxmox VE. La commande de base pour créer une réplication : pvesr create --id 100-0 --target node2 --schedule */15 (réplication de la VM 100 vers node2 toutes les 15 minutes). Le paramètre --schedule utilise la syntaxe systemd timer (ex: "daily", "*/30", "02:00").

Commandes essentielles pvesr :

• pvesr list : liste toutes les réplications configurées avec leur état
• pvesr run {id} : déclenche manuellement une réplication immédiate
• pvesr delete {id} : supprime une configuration de réplication
• pvesr status : affiche l'état détaillé des réplications en cours

Via l'interface web : sélectionner la VM → Replication → Add, choisir le nœud de destination et la fréquence. Proxmox crée automatiquement les snapshots ZFS nommés __replicate_{vmid}-{job}_ sur les datasets concernés.

Mécanisme des Snapshots Delta ZFS

Le processus de réplication fonctionne en deux phases. La réplication initiale transfère l'intégralité du dataset ZFS via zfs send | zfs receive sur SSH. Cette opération peut être longue selon la taille de la VM. Les réplications incrémentielles suivantes n'envoient que le différentiel entre deux snapshots consécutifs via zfs send -i snapshot1 snapshot2, ce qui les rend très rapides.

Proxmox conserve sur le nœud de destination les snapshots __replicate_ correspondant à chaque point de synchronisation. En cas de défaillance du nœud source, ces snapshots permettent de cloner la VM et de la démarrer en état cohérent. La commande zfs list -t snapshot | grep replicate liste tous les snapshots de réplication présents.

Pour une stratégie de sauvegarde complémentaire (la réplication n'est pas un remplacement des sauvegardes), consultez notre guide Proxmox Backup Server.

Diagnostic et Résolution des Erreurs de Réplication

Les erreurs de réplication sont journalisées dans /var/log/pve/tasks/. Chaque tâche de réplication génère un fichier de log avec l'identifiant de la tâche. La commande journalctl -u pve-replication -f affiche les logs en temps réel.

Erreurs courantes et solutions :

• SSH connection refused : vérifier le PVE Firewall et la clé SSH dans /etc/pve/priv/authorized_keys
• ZFS snapshot not found : la chaîne de snapshots est cassée, nécessite une resynchronisation complète via pvesr delete puis recréation
• No space left on device : augmenter le pool ZFS destination ou nettoyer les anciens snapshots
• Dataset busy : un snapshot manuel ou une sauvegarde est en cours, la réplication reprendra automatiquement

La documentation officielle pvesr Proxmox et le forum Proxmox sont des ressources précieuses pour le diagnostic avancé.

Checklist Complète : Avant, Pendant et Après la Mise en Place

Checklist Pré-Réplication

• Vérifier que les disques des VMs cibles sont sur des datasets ZFS (pas LVM, Ceph ou NFS)
• Confirmer la connectivité SSH entre nœuds source et destination
• Contrôler l'espace disponible sur le pool ZFS destination (≥ taille VM + 30%)
• Valider la bande passante réseau disponible pour la réplication initiale
• Planifier la réplication initiale en période creuse (consomme toute la bande passante)
• S'assurer que les nœuds sont dans le même cluster Proxmox

Checklist Pendant la Mise en Place

• Surveiller la progression via pvesr status ou l'interface web
• Vérifier que la réplication initiale se complète sans erreur
• Tester une réplication incrémentielle manuelle via pvesr run
• Confirmer la présence des snapshots de réplication sur le nœud destination

Checklist Post-Réplication

• Tester le failover : cloner la VM répliquée sur le nœud destination et la démarrer
• Documenter le RPO effectif (délai entre la dernière réplication et un sinistre simulé)
• Mettre en place une alerte sur les erreurs de réplication (via Zabbix ou Prometheus)
• Planifier des tests de restauration trimestriels

Live Migration vs Réplication ZFS : différences clés

Proxmox VE 9 propose trois mécanismes complémentaires pour assurer la résilience et la mobilité des machines virtuelles. Il est fondamental de distinguer leurs rôles respectifs avant de concevoir une architecture de continuité de service. La réplication ZFS, la live migration et la haute disponibilité répondent à des besoins différents et fonctionnent selon des principes distincts — même si ils peuvent être combinés dans une architecture production robuste.

Un point clé souvent mal compris : la réplication seule ne déclenche pas de failover automatique. Elle ne fait que maintenir une copie synchronisée du disque. Pour un redémarrage automatique en cas de panne, il faut obligatoirement activer HA et ajouter la VM au gestionnaire ha-manager. La réplication est une condition nécessaire au HA sans stockage partagé, mais pas suffisante.

Concernant les performances, quand une VM est déjà répliquée vers le nœud cible, la live migration devient beaucoup plus rapide : seuls les blocs delta depuis la dernière synchronisation sont transférés, pouvant réduire le temps de migration d'un facteur 10 pour les gros disques. Après migration réussie, la direction de réplication s'inverse automatiquement (node A→B devient B→A).

# Vérifier l'état des jobs avant migration
pvesr list

# Forcer une dernière synchro avant migration
pvesr schedule-now 101-0

# Vérifier l'absence de lock sur la VM
qm config 101 | grep -i lock

# Migrer la VM (beaucoup plus rapide si déjà répliquée vers node2)
qm migrate 101 node2 --online

# Vérifier l'inversion automatique après migration
pvesr list

Haute Disponibilité (HA) et réplication : combinaison et limites

La combinaison HA + réplication ZFS est l'architecture recommandée pour les clusters Proxmox sans stockage partagé (shared nothing). Elle permet d'obtenir un failover automatique en cas de panne nœud, avec un RPO limité à la fréquence de réplication. Voici le comportement exact en cas de défaillance complète du nœud source :

• Corosync détecte la perte du nœud via les heartbeats (délai configurable, typiquement 5-10 secondes)
• ha-manager identifie les VMs protégées par HA sur le nœud défaillant
• La VM est démarrée à froid sur le nœud cible à partir du dernier snapshot de réplication disponible
• Les données modifiées depuis la dernière synchronisation (RPO = fréquence configurée) sont perdues

Configuration des ressources HA depuis la CLI :

# Vérifier l'état global du gestionnaire HA
ha-manager status

# Lister les ressources HA configurées
ha-manager list

# Ajouter une VM au gestionnaire HA
ha-manager add vm:101 --group production --state started

# Vérifier la configuration HA via pvesh
pvesh get /cluster/ha/resources

# Voir les groupes HA disponibles
pvesh get /cluster/ha/groups

Les fichiers de configuration HA résident dans /etc/pve/ha/ :

# Ressources HA (VM protégées et leurs politiques)
cat /etc/pve/ha/resources.cfg

# Groupes HA (nœuds membres et priorités)
cat /etc/pve/ha/groups.cfg

# Logs ha-manager en temps réel
journalctl -u pve-ha-lrm -f
journalctl -u pve-ha-crm -f

Limites importantes à connaître. La combinaison HA + réplication ZFS n'est pas équivalente à un stockage partagé synchrone. Le RPO ne peut pas descendre en dessous de la fréquence de réplication minimale (1 minute). Toute donnée écrite après la dernière synchronisation et avant la panne est perdue. Pour un RPO proche de zéro, il faut utiliser Ceph (stockage distribué, écriture synchrone) ou un SAN partagé. En cas de perte réseau temporaire (split-brain potentiel), le mécanisme de fencing HA peut déclencher un redémarrage par sécurité même si le nœud n'est pas réellement en panne — prévoir des ressources de fencing adaptées (IPMI, PDU).

Dépannage et diagnostic avancé de la réplication

Les problèmes de réplication Proxmox se manifestent généralement de trois façons : le job passe en état ERR, la réplication est lente ou bloquée, ou les snapshots de réplication s'accumulent anormalement sur le nœud destination. Voici la procédure de diagnostic systématique à appliquer.

Étape 1 : Vérifier l'état global des jobs

# Vue d'ensemble de tous les jobs de réplication
pvesr list

# Détail d'un job spécifique (remplacer 101-0 par votre ID job)
pvesr read 101-0

# Statut via l'API REST Proxmox
pvesh get /nodes/$(hostname)/replication

# Tâches récentes du nœud (réplication comprise)
pvesh get /nodes/$(hostname)/tasks | head -20

Étape 2 : Consulter les logs de réplication

# Logs du service de réplication (dernière heure)
journalctl -u pvesr* --since "1 hour ago"

# Logs en temps réel lors d'une réplication manuelle
journalctl -u pvesr* -f &

# Déclencher manuellement une réplication pour observer les logs
pvesr schedule-now 101-0

# Logs détaillés dans les tâches Proxmox
ls -lt /var/log/pve/tasks/ | head -20
# Lire le log d'une tâche spécifique
cat /var/log/pve/tasks/UPID:node1:00001234:ABCD1234:67890123:replicate:101-0:root@pam:

Étape 3 : Diagnostics spécifiques par type d'erreur

# Erreur SSH : vérifier la connectivité inter-nœuds
ssh -i /etc/pve/priv/known_hosts root@node2 "pvecm status"
# Vérifier les clés autorisées
cat /etc/pve/priv/authorized_keys

# Erreur ZFS snapshot not found : chaîne incrémentale cassée
# → supprimer et recréer le job (force une resynchronisation complète)
pvesr delete 101-0
pvesr create-local-job 101-0 node2 --schedule "*/15"

# Erreur No space left : vérifier l'espace ZFS destination
zpool list
zfs list -o name,used,avail,refer
# Nettoyer les anciens snapshots de réplication orphelins
zfs list -t snapshot | grep __replicate_
# Destruction sélective d'un snapshot orphelin
zfs destroy rpool/data/vm-101-disk-0@__replicate_101-0_1234567890

# Erreur Dataset busy : une sauvegarde ou snapshot manuel est en cours
# Attendre la fin de l'opération ou identifier le processus
fuser /dev/zd0  # remplacer par le device ZFS concerné
qm config 101 | grep lock

Étape 4 : Surveiller les métriques ZFS pendant la réplication

# I/O ZFS en temps réel (observer pendant la réplication)
zpool iostat -v 1

# Surveiller le trafic réseau sur l'interface de réplication
iftop -i eth1  # remplacer par votre interface réseau dédiée

# Taille des snapshots de réplication accumulés
zfs list -t snapshot -o name,used | grep __replicate_

Erreurs courantes et résolutions rapides :

Questions fréquentes

Quelle est la différence entre la réplication Proxmox VE et la haute disponibilité (HA) ?

La réplication Proxmox VE crée des copies synchronisées (snapshots delta) des VMs sur d'autres nœuds, mais ne bascule pas automatiquement les VMs en cas de panne. Le failover est manuel : l'administrateur doit démarrer la VM sur le nœud de destination. La haute disponibilité (HA), en revanche, détecte automatiquement la panne d'un nœud via Corosync et redémarre les VMs protégées sur d'autres nœuds sans intervention humaine. Les deux fonctionnalités sont complémentaires : la réplication protège contre la perte de données, le HA protège contre les interruptions de service.

Comment fonctionne le transfert ZFS send/receive utilisé par Proxmox pour la réplication ?

La réplication Proxmox utilise les commandes natives zfs send et zfs receive pour transférer les snapshots entre nœuds via SSH. Lors de la première réplication (full sync), la totalité du dataset ZFS est envoyée. Les réplications suivantes utilisent zfs send -i snapshot_n snapshot_n+1 pour n'envoyer que le différentiel (blocs modifiés entre les deux snapshots). Ce mécanisme est très efficace car ZFS maintient un journal des blocs modifiés (dirty blocks). Le transfert est compressé par défaut et chiffré via SSH, garantissant la sécurité des données en transit.

Comment diagnostiquer une réplication bloquée ou échouée dans Proxmox VE ?

En cas de réplication bloquée, la première étape est de consulter les logs via journalctl -u pve-replication --since "1 hour ago" et les tâches dans /var/log/pve/tasks/. Si la chaîne de snapshots est corrompue (message "snapshot not found"), il faut supprimer la configuration de réplication avec pvesr delete {id} et la recréer pour forcer une resynchronisation complète. Pour les erreurs SSH, vérifier que les clés dans /etc/pve/priv/ sont correctes et que le port 22 est accessible. Consulter le guide CLI d'administration Proxmox pour les commandes de diagnostic avancées.

Sources et références : Proxmox VE Wiki · ANSSI

Conclusion

La réplication ZFS Proxmox VE est un outil puissant pour réduire le RPO et garantir la disponibilité des données critiques entre nœuds du cluster. La maîtrise de pvesr, la compréhension du mécanisme de snapshots delta et l'application rigoureuse de la checklist permettent de construire une stratégie de continuité d'activité robuste et testée régulièrement.

Sécurisez votre infrastructure virtualisée

Audit Proxmox, VMware, Hyper-V — durcissement hyperviseur, segmentation, protection anti-ransomware.

Demander un audit [email protected]