Haute disponibilité, sauvegardes et pare-feu

01Haute disponibilité et groupes

La haute disponibilité de Proxmox VE redémarre automatiquement une machine virtuelle sur un autre noeud lorsque son noeud d'origine disparaît. Elle exige un stockage partagé, donc Ceph ou une baie externe.

Depuis Proxmox VE 9, les groupes HA ont cédé la place aux règles d'affinité, plus expressives. Les groupes définis sous Proxmox VE 8 sont convertis automatiquement en règles d'affinité de noeud une fois tous les noeuds passés en version 9. La commande ha-manager groupadd répond encore, mais elle est en sursis et disparaîtra avec Proxmox VE 10.

Deux familles de règles coexistent.

• Affinité de noeud : où une ressource doit tourner. C'est l'équivalent direct des anciens groupes, avec les mêmes priorités.
• Affinité de ressource : quelles ressources doivent rester ensemble ou au contraire séparées. Sans équivalent avant la version 9, et précieux pour écarter deux serveurs de bases de données répliqués sur des noeuds différents.

# le retour automatique sur le noeud préféré est actif par défaut,
# failback 0 remplace l'ancien nofailback 1
ha-manager add vm:101 --max_restart 2 --max_relocate 2 --failback 0

# priorités décroissantes, comme les anciens groupes
ha-manager rules add node-affinity prod-critique \
  --resources vm:101 \
  --nodes "pve-01:2,pve-02:1,pve-03:1"

# --strict 1 interdit tout autre noeud, au risque de ne pas redémarrer
ha-manager rules set node-affinity prod-critique --strict 1

ha-manager rules add resource-affinity bases-separees \
  --affinity negative \
  --resources vm:101,vm:102

# affinity positive pour au contraire les garder sur le même noeud
ha-manager rules config
ha-manager status

02Watchdog et isolation d'un noeud

Proxmox VE n'utilise pas de dispositif d'isolation externe. Chaque noeud s'auto-isole : un watchdog matériel ou logiciel le redémarre s'il perd le quorum. C'est ce qui garantit qu'une machine virtuelle ne tournera jamais deux fois en même temps.

• Par défaut, le watchdog logiciel softdog est utilise. Il suffit dans la plupart des cas.
• Un watchdog matériel via IPMI est plus fiable, car il résiste à un noyau bloqué. À configurer dans /etc/default/pve-ha-manager.
• Le délai total avant redémarrage est d'environ deux minutes après la perte du quorum. Une machine sous HA redémarre donc typiquement en deux à trois minutes.

03Proxmox Backup Server

PBS réalise des sauvegardes incrémentielles avec déduplication au niveau du bloc, ce qui rend possible une rétention longue pour un coût de stockage raisonnable.

Ou l'installer

• Sur une machine physique distincte, avec son propre stockage. Un PBS virtualisé sur le cluster qu'il sauvegarde ne protège de rien.
• Magasin de données sur ZFS, en RAIDZ2 pour la capacité ou en miroirs pour la performance de vérification.
• Un espace de noms par client ou par environnement, avec des jetons d'accès limités à cet espace.

Politique de rétention

proxmox-backup-manager prune-job create quotidien \
  --store principal \
  --schedule "daily 03:30" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --keep-yearly 3

# le ramasse-miettes libere réellement l'espace, sinon rien n'est récupère
proxmox-backup-manager garbage-collection create principal --schedule "daily 05:00"

Vérification et copie distante

• Tâches de vérification : PBS relit les blocs et contrôle les sommes. Sans elles, une sauvegarde corrompue reste indétectée jusqu'au jour où l'on en a besoin.
• Synchronisation vers un second PBS sur un autre site, ou export sur bande. C'est le troisième exemplaire de la règle 3-2-1.
• Chiffrement côté client lorsque la destination n'est pas sous votre contrôle exclusif. Conservez la clé ailleurs que sur le cluster : sans elle, les sauvegardes ne valent rien.

04La restauration, seule preuve valable

Une sauvegarde qui n'a jamais été restaurée est une hypothèse. Deux scénarios doivent être testés et chronométrés, puis reproduits chaque trimestre.

• Restauration complète d'une machine virtuelle, sur un noeud différent, avec mesure du temps total. Ce chiffre est votre engagement de rétablissement réel.
• Restauration d'un fichier unique, le besoin le plus fréquent au quotidien.

proxmox-backup-client list --repository sauv@pbs@pbs.exemple.fr:principal

proxmox-backup-client restore \
  vm/101/2026-08-28T02:00:00Z \
  drive-scsi0.img.fidx /mnt/restauration \
  --repository sauv@pbs@pbs.exemple.fr:principal

05Pare-feu et cloisonnement

Le pare-feu Proxmox VE s'applique à trois niveaux : centre de données, noeud, et machine virtuelle. Les règles se cumulent, du plus général au plus spécifique.

• Activez-le au niveau du centre de données avec une politique d'entrée par défaut en rejet, puis ouvrez explicitement ce qui est nécessaire.
• Utilisez des alias et des ensembles d'adresses pour les réseaux d'administration, plutôt que de répéter des adresses dans chaque règle.
• Créez des groupes de sécurité réutilisables : un pour les serveurs web, un pour les bases de données, applicables à chaque machine concernée.
• Les réseaux corosync et Ceph doivent être joignables uniquement entre noeuds. Aucune machine virtuelle n'a de raison d'y accéder.
• L'accès à l'administration passe par un VPN ou une machine rebond, avec double authentification et journalisation.