Le niveau de protection dépend de la panne à laquelle l’entreprise doit résister. La sauvegarde fournit un état des données restaurable. La haute disponibilité locale peut absorber la panne d’un hôte. Un second site étend la protection au-delà du domaine de panne initial, mais exige ses propres capacités, réseaux et bascules répétées. Aucune option ne remplace la validation fonctionnelle de l’application.
Le test de restauration et la différence entre HA Proxmox et sauvegarde font déjà l’objet d’articles. Ici, la décision porte sur la combinaison de sauvegarde, de ressources locales de remplacement et d’exploitation de secours distante adaptée à un service et à un domaine de panne. La présentation des plateformes publique ne remplace pas non plus cette analyse applicative.
Définir d’abord le processus et deux objectifs temporels
Notre exemple explicitement fictif est un ERP avec VM applicative, base de données et fichiers de factures. En cas de perte de l’ensemble du site , le métier souhaite reprendre les commandes en quatre heures et perdre au maximum 15 minutes de données cohérentes. Ce sont des objectifs RTO et RPO, pas un engagement DAXS ni un résultat mesuré. Une panne d’hôte isolée pourrait viser un délai plus court ; une opération effacée par erreur exige en revanche un point de restauration antérieur et intact.
L’analyse d’impact métier doit donc distinguer panne d’hôte, perte du site et données corrompues ou supprimées. Le service n’est rétabli que si connexion, opération en base et pièce jointe associée fonctionnent en secours. Électricité, réseau du site, DNS, identité, clés et interfaces externes sont des dépendances. S’il manque un élément, démarrer un serveur de remplacement ne suffit pas à rendre le service utilisable.
Trois niveaux de protection aux limites différentes
| Niveau | Ce qu’il permet | Ce qui reste à résoudre |
|---|---|---|
| A · Sauvegarde et restauration | Des sauvegardes séparées permettent de revenir à un état vérifié ; l’application est restaurée lorsqu’un système cible est disponible. | Capacité de remplacement, durée de restauration et cohérence métier déterminent le RTO. Après la perte du site, aucun engagement fiable de quatre heures n’est possible sans destination prête. |
| B · Redondance locale et sauvegarde | Plusieurs hôtes avec stockage, quorum et réseau correctement dimensionnés peuvent redémarrer une VM sur d’autres ressources après une panne d’hôte. | Électricité, compartiment coupe-feu ou accès au site partagés restent un domaine de panne. Suppressions et corruptions peuvent être répliquées ; une sauvegarde séparée reste nécessaire. |
| C · Second site et sauvegarde | Des capacités de secours préparées et géographiquement séparées, avec données applicatives répliquées, peuvent couvrir la perte du site si bascule et processus métier ont été répétés. | Retard de réplication, identités partagées, liaisons, clés et bascule défaillante peuvent empêcher de respecter les objectifs de 15 minutes/quatre heures. Des sauvegardes séparées restent nécessaires. |
La HA locale peut donc répondre à une panne d’hôte, sans assurer automatiquement la reprise de tout le site. Microsoft distingue expressément redondance et réplication de la sauvegarde : une erreur ou suppression répliquée reste une erreur. AWS décrit sauvegarde/restauration, pilot light, warm standby et modèles multisites actifs avec un effort croissant. Ces modèles cloud constituent une logique de décision, pas des RPO/RTO universels pour l’ERP propre envisagé ici.
Périmètre équivalent : calcul explicite sur trois et cinq ans
Chaque niveau compare le même service ERP de production et le même socle de sauvegarde séparée. La plateforme de production existante est donc exclue de toutes les options. Le runbook de sauvegarde et la base de test exigent initialement 24 heures-personnes ; les hypothèses annuelles sont 3 600 € de sauvegarde/stockage externe, 12 × 4 heures-personnes d’exploitation et deux exercices de restauration de 16 heures-personnes chacun. Le coût complet librement supposé est de 80 € par heure-personne : 1 920 € initialement et, par an, 3 600 + (48 + 32) × 80 = 10 000 €. Il ne s’agit pas de tarifs fournisseurs.
Le niveau B ajoute initialement 60 heures-personnes de conception et validation hôtes/stockage/réseau, puis annuellement 7 800 € de capacité locale supplémentaire indicative, énergie et support compris, 12 × 4 heures d’exploitation et deux exercices HA de huit heures-personnes supplémentaires chacun. Le niveau C ajoute à la place 96 heures-personnes initiales pour sites, données et bascule, puis chaque année 18 000 € de capacité de secours et réseau préparés, 3 600 € de transfert de données, 12 × 8 heures d’exploitation et deux exercices de site de 24 heures-personnes supplémentaires chacun. Les heures d’exercice sont les totaux de l’équipe ; le socle commun de sauvegarde n’est compté qu’une fois par option.
| Niveau | Initial | Annuel | 3 ans | 5 ans |
|---|---|---|---|---|
| A · Sauvegarde/restauration | 24 × 80 = 1 920 € | 10 000 € de base | 31 920 € | 51 920 € |
| B · Redondance locale | 1 920 + 60 × 80 = 6 720 € | 10 000 + 7 800 + 3 840 + 1 280 = 22 920 € | 75 480 € | 121 320 € |
| C · Second site | 1 920 + 96 × 80 = 9 600 € | 10 000 + 18 000 + 3 600 + 7 680 + 3 840 = 43 120 € | 138 960 € | 225 200 € |
Sensibilité : Si la capacité préparée du second site coûte 500 € de plus par mois, le niveau C augmente de 6 000 € par an : 156 960 € sur trois ans ou 255 200 € sur cinq ans. Avant tout achat, ajouter pièces de rechange, taxes, devis réels de liaisons et sites, droits de licence, exploitation au-delà des heures prévues et coût d’un sinistre réel. Aucune option ne promet d’économie ni de reprise garantie.
Décider par le test
Pour l’objectif supposé de quatre heures/15 minutes en cas de perte du site , A et B ne suffisent pas seules tant qu’un autre lieu utilisable avec données, identité et réseau n’est pas prêt. C n’est qu’un candidat : l’équipe doit mesurer réplication, cohérence base/fichiers, accès, décision de bascule, capacité en charge et retour en situation réelle de test. Si le métier accepte un secours prolongé avec saisie manuelle des commandes, une solution moins coûteuse peut suffire. Ce choix doit être explicitement décidé, consigné et exercé.
DAXS peut inventorier le service et ses dépendances, définir le secours minimal utile au métier et comparer les trois options à partir de devis réels et de résultats de restauration/bascule. Contacter DAXS.
Sources : Microsoft Learn : redondance, réplication et sauvegarde · AWS Well-Architected : stratégies de reprise après sinistre · Proxmox VE : fonctions HA et sauvegarde.
