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

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.

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.