PRA / PCA : cluster distant, sync PBS, test de bascule¶
Un plan de reprise ne vaut que s'il a été testé : fixez avec le métier la perte de données admissible (RPO) et la durée d'arrêt admissible (RTO) de chaque application, choisissez le mécanisme Proxmox qui les tient, puis prouvez-le par un test de bascule au moins une fois par an.
Notions clés¶
| Terme | Définition | Exemple |
|---|---|---|
| PCA (continuité) | Le service continue pendant la panne, sans action humaine | HA Proxmox sur le même site |
| PRA (reprise) | Le service est redémarré ailleurs après un sinistre, par une procédure | Restauration sur un site distant |
| RPO | Perte de données maximale admise, mesurée en temps | 24 h avec une sauvegarde nocturne |
| RTO | Durée maximale d'interruption admise | 4 h pour l'ERP |
| Site distant | Second lieu, assez éloigné pour ne pas subir le même sinistre | Second datacenter, ou PBS du MSP |
Quel mécanisme pour quel RPO / RTO¶
| Mécanisme | Protège contre | RPO typique | RTO typique | Remarque |
|---|---|---|---|---|
| HA Proxmox (Ceph, SAN) | Panne d'un nœud | 0 | 2 à 5 min (redémarrage de la VM) | Même site : ne protège pas d'un sinistre |
Réplication ZFS (pvesr) + HA |
Panne d'un nœud | Intervalle de réplication (15 min par défaut, 1 min minimum) | 2 à 5 min | Même cluster, donc même site (RB-11) |
| PBS local | Erreur humaine, corruption, ransomware | Fréquence des sauvegardes (souvent 24 h) | Minutes à heures selon le volume (RB-12) | Perdu avec le site s'il est dans la même salle |
| Sync PBS vers le MSP | Perte du site ou du PBS local | 24 h + délai de sync | Heures à jours : rapatriement ou matériel de secours | Socle du contrat (RB-15) |
| Cluster distant + PBS distant | Perte du site principal | 24 h (ou moins avec des sauvegardes plus fréquentes) | 1 à 4 h si les restaurations sont préparées | Second cluster indépendant, pas un cluster étiré |
| Réplication Ceph RBD (mirroring) vers un cluster distant | Perte du site principal | Minutes | Rapide, mais procédure de bascule complexe | Conception et exploitation par le MSP |
Pas de cluster étiré entre deux sites
Corosync exige une latence inférieure à 5 ms entre tous les nœuds (documentation PVE). Un cluster réparti sur deux sites distants perd le quorum à la moindre coupure du lien. Le PRA multi-site repose sur deux clusters indépendants, gérables ensemble avec Proxmox Datacenter Manager.
Architecture de référence¶
flowchart LR
subgraph A["Site principal"]
C1["Cluster PVE pve01-pve03"] -->|"sauvegarde nocturne"| P1["PBS local pbs-local"]
end
subgraph B["Site de secours"]
P2["PBS distant"] --> C2["Cluster PVE de secours"]
end
subgraph M["MSP"]
P3["PBS du MSP"]
end
P1 -->|"sync job push ou pull"| P2
P1 -->|"sync job vers le MSP"| P3
P3 -.->|"rapatriement si besoin"| P2- Le PBS distant reçoit les sauvegardes par sync job : voir Sync jobs pull et push.
- Le cluster de secours déclare le PBS distant comme stockage et peut restaurer à tout moment, ou utiliser le live-restore pour redémarrer vite les VMs critiques.
- La copie MSP couvre le cas où les deux sites du client sont touchés (ransomware avec propagation, par exemple). Voir Stratégie 3-2-1-1-0.
Rôle du MSP¶
| Activité | Client | MSP |
|---|---|---|
| Fixer RPO et RTO par application | Décide avec le métier | Conseille, vérifie la faisabilité |
| Conception (second cluster, réseau, réplication Ceph) | Valide | Conçoit et met en œuvre |
| Surveillance des sync jobs | Routine hebdomadaire | Supervise sa propre copie (N2/N3) |
| Test de bascule annuel | Participe, valide les applications | Pilote (N2/N3), assiste (N1) |
| Déclenchement réel du PRA | Décide (direction) | Exécute ou guide selon le contrat |
Le détail par contrat figure dans la matrice de responsabilité et dans le périmètre de votre contrat.
Runbook : test de bascule annuel¶
Avant de toucher la prod
- Date validée par la direction et le métier, ticket iTop de planification ouvert (P4) au moins un mois avant.
- Liste des VMs du périmètre, ordre de démarrage (AD/DNS, bases de données, applications) et RTO cible de chacune.
- Réseau isolé prévu sur le cluster de secours (VLAN ou bridge sans uplink) : les copies ne doivent jamais voir la production.
- Clé de chiffrement des sauvegardes disponible hors des nœuds de production.
- Dernier sync vers le PBS distant en OK (Last Sync de moins de 24 h).
Étapes¶
- Noter l'heure de début et l'horodatage de la dernière sauvegarde disponible sur le PBS distant (RPO mesuré).
-
Restaurer chaque VM du périmètre sur le cluster de secours, sous un nouvel ID, Unique coché, Start after restore décoché.
-
Isoler : rattacher chaque carte réseau au réseau isolé avant le premier démarrage (VM → Hardware → Network Device → Bridge).
- Démarrer dans l'ordre prévu ; vérifier la résolution DNS, l'authentification, puis les applications avec un référent métier.
- Mesurer le RTO réel : de l'heure de début à l'application validée.
- Nettoyer : arrêter et supprimer les VMs de test (
qm destroy 9101 --purge), supprimer le réseau isolé si temporaire. - Rédiger le PV : RPO et RTO mesurés par application, écarts, actions correctives. Modèle : PV de test de restauration.
Vérifications
- Toutes les VMs du périmètre ont démarré et ont été validées par le métier.
- RTO mesuré inférieur ou égal au RTO cible ; sinon, action corrective notée (live-restore, sauvegardes plus fréquentes, réplication).
- Aucune VM de test n'a été connectée au réseau de production (vérifier les tables ARP ou le journal du pare-feu).
Rollback
Le test ne touche pas la production : arrêter et détruire les VMs restaurées suffit. En cas de conflit réseau constaté, arrêter immédiatement les copies (qm stop 9101) et ouvrir un ticket P2.
Pièges vus en support
- Copie d'un contrôleur de domaine démarrée sur le réseau de production : conflits et réplication AD corrompue.
- Clé de chiffrement PBS stockée uniquement sur les nœuds du site principal : restauration impossible le jour du sinistre.
- RTO estimé sur une VM de 50 Go, alors que la base de 4 To met huit heures à revenir.
- Option Remove vanished active sur le sync : une suppression sur le site principal efface aussi la copie distante.
- Plan jamais mis à jour après l'ajout de nouvelles applications.
Quand ouvrir un ticket iTop
Planification du test annuel : P4, un mois avant. Sinistre réel (site perdu, PBS local inaccessible) : P1 immédiat, en précisant les applications prioritaires. Joindre la liste des VMs, la date visée et l'état des sync jobs.
Testez-vous¶
-
La réplication ZFS toutes les 15 minutes suffit-elle comme PRA ?
Réponse
Non. Elle reste à l'intérieur du même cluster, donc du même site, et réplique aussi les suppressions ou un chiffrement par ransomware. C'est un mécanisme de continuité face à la panne d'un nœud, pas de reprise après sinistre.
-
Pourquoi ne pas étendre le cluster existant sur le site de secours ?
Réponse
Corosync demande moins de 5 ms de latence entre nœuds. Sur deux sites, une coupure du lien fait perdre le quorum et peut provoquer le redémarrage des nœuds par la HA. On préfère deux clusters indépendants reliés par la sauvegarde.
-
Le métier demande un RPO de 1 h pour l'ERP. Que proposer ?
Réponse
Des sauvegardes horaires de cette VM vers PBS (incrémentales, rapides grâce au dirty bitmap) synchronisées vers le site distant, ou une réplication Ceph RBD conçue par le MSP. À valider en charge réseau et en rétention avec le MSP.
-
Quelle preuve apporter à un auditeur que le PRA fonctionne ?
Réponse
Le PV du dernier test de bascule : date, périmètre, RPO et RTO mesurés par application, écarts et actions correctives.