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.

Les groupes HA permettent de contraindre le placement. Un groupe associé des noeuds à des priorités, et deux options en modifient le comportement.

• restricted : la ressource ne démarre que sur les noeuds du groupe. Utile pour une licence liée à un processeur, ou pour une contrainte de localisation des données.
• nofailback : la machine ne revient pas automatiquement sur son noeud préférentiel après réparation. Nous l'activons presque toujours, pour choisir nous-mêmes le moment du retour.

ha-manager groupadd prod-critique \
  --nodes "pve-01:2,pve-02:1,pve-03:1" \
  --nofailback 1

ha-manager add vm:101 --group prod-critique --max_restart 2 --max_relocate 2
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'àu 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.