Objectif
Mettre en place une stratégie de sauvegarde qui conserve les données de production et au moins deux copies de sauvegarde sur des domaines de défaillance différents, dont une hors site, avec des objectifs RPO/RTO mesurables, une protection contre la suppression malveillante et des tests de restauration récurrents.
Prérequis
- Inventaire des données, VM, bases, configurations, annuaires et SaaS à protéger.
- RPO et RTO validés par criticité avec les responsables métiers.
- Volumétrie actuelle, croissance, fenêtre de sauvegarde et bande passante disponible.
- Deux cibles ou technologies de sauvegarde permettant un domaine de panne distinct et une copie hors site.
- Emplacement sûr pour les clés de chiffrement et identifiants de restauration.
Procédure pas à pas
Classer les workloads et leurs dépendances
Listez les systèmes critiques et ce qui est nécessaire pour les restaurer : VM, bases, fichiers, certificats, configurations de firewall, annuaire, DNS, applications SaaS et secrets. Classez-les par criticité. Une sauvegarde d’une base sans son application, ou d’une application sans son identité, peut être insuffisante pour une reprise réelle.
- Chaque service critique possède un périmètre de sauvegarde complet et un propriétaire.
Définir RPO et RTO mesurables
Le RPO définit la quantité maximale de données que l’entreprise accepte de perdre ; le RTO définit le délai de remise en service. Traduisez ces objectifs en fréquence de sauvegarde, rétention et architecture. Une sauvegarde quotidienne ne peut pas satisfaire un RPO d’une heure. Documentez aussi la priorité de restauration entre services.
Exemple de matrice :
Service;RPO;RTO;Priorité
ERP;1h;4h;P1
Fichiers;4h;8h;P2
Archives;24h;48h;P3- La fréquence et les mécanismes choisis sont cohérents avec les objectifs métier.
Construire les trois copies
Conservez la donnée de production et créez au moins deux copies de sauvegarde. La première copie doit permettre une restauration rapide locale ; la seconde doit rester disponible si le site, le stockage ou le serveur de sauvegarde principal est perdu. Pour un environnement Veeam, un Backup Copy ou une autre cible indépendante peut créer la troisième instance.
- Pour chaque workload critique, trois instances de données sont identifiées : production plus deux sauvegardes.
Séparer les supports et domaines de défaillance
Utilisez au moins deux technologies ou supports réellement indépendants selon votre environnement : disque local et objet cloud, NAS et bande, appliance et repository Linux, etc. L’objectif est de réduire la probabilité qu’une panne matérielle, une corruption logicielle ou un ransomware affecte toutes les copies simultanément. Documentez quelles dépendances sont communes.
- Les deux copies de sauvegarde ne dépendent pas du même stockage, du même serveur et du même point de panne.
Maintenir une copie hors site
Placez au moins une sauvegarde dans un autre site, une autre région ou un service cloud distinct. Vérifiez la bande passante nécessaire pour transférer les incréments et surtout pour restaurer lors d’un sinistre. Une copie hors site trop lente à récupérer peut respecter le 3-2-1 tout en échouant au RTO ; mesurez donc le temps réel.
- Une perte du site principal n’empêche pas d’accéder à au moins une copie restaurable.
Ajouter isolation ou immutabilité
Pour les menaces modernes, renforcez le 3-2-1 avec une copie immuable, offline ou administrée par des credentials distincts. Limitez les droits de suppression, utilisez MFA pour l’administration de sauvegarde et séparez les comptes du domaine de production. Si une durée d’immutabilité est configurée, dimensionnez la capacité afin de ne pas saturer le repository avant expiration.
- Un compte administrateur de production compromis ne peut pas supprimer immédiatement toutes les sauvegardes.
Chiffrer sans perdre les clés
Activez le chiffrement lorsque les sauvegardes contiennent des données sensibles ou quittent le site. Stockez les clés et mots de passe de restauration dans un emplacement distinct du serveur sauvegardé. Testez qu’au moins deux personnes autorisées savent retrouver la clé en situation d’incident. Un backup parfaitement chiffré mais sans clé disponible est inutilisable.
- Les sauvegardes sont protégées et les clés restent accessibles lors d’une perte du SI principal.
Superviser les jobs, la capacité et l’âge des restore points
Surveillez échec, warning, durée, débit, espace libre et absence de nouveau restore point. Définissez un seuil d’escalade si un workload critique n’a pas été sauvegardé dans son RPO. Un tableau simple indiquant dernière réussite, copie hors site et dernier test de restauration permet de voir immédiatement les écarts.
- Une absence de sauvegarde récente ou un repository proche de la saturation génère une action opérationnelle.
Tester des restaurations de plusieurs niveaux
Planifiez des tests de fichier, VM et application, puis mesurez le RTO réel. Testez périodiquement la copie hors site ou immuable, pas uniquement le backup primaire. Pour les systèmes complexes, utilisez un laboratoire isolé et vérifiez l’application avec le métier. Conservez les résultats, les erreurs et les actions correctives.
- Chaque classe de service possède un test récent démontrant qu’elle peut réellement être restaurée.
Réviser la stratégie après chaque changement majeur
Recalculez la volumétrie et les dépendances après ajout de VM, migration cloud, nouvel ERP ou changement de réseau. Vérifiez que les nouvelles données sont intégrées aux jobs et que la copie hors site suit toujours. Une stratégie 3-2-1 n’est pas un projet ponctuel : elle doit évoluer avec le SI et les objectifs métier.
- L’inventaire, la capacité, le RPO/RTO et les tests restent alignés sur le SI réel.
Validation
La procédure est validée lorsque :
- Chaque workload critique dispose de la production et de deux copies de sauvegarde distinctes.
- Au moins une copie se trouve hors du domaine de panne principal.
- Une copie est isolée, immuable ou protégée par une séparation forte des credentials.
- Les dernières sauvegardes respectent le RPO et des tests de restauration mesurent le RTO.
- Les clés de chiffrement et procédures de reprise restent accessibles hors du système principal.
Retour arrière
- Conserver l’ancienne stratégie pendant la période de validation de la nouvelle architecture.
- Ne supprimer aucun ancien repository avant un test complet des deux nouvelles copies.
- Si la copie hors site surcharge la liaison, réduire temporairement sa fenêtre ou son périmètre tout en maintenant le backup primaire et en corrigeant la capacité.
Dépannage / erreurs fréquentes
- Trois copies existent mais sur le même NAS : créer un second domaine de stockage et déplacer une copie avant de déclarer la règle respectée.
- Copie hors site constamment en retard : mesurer le volume changé, la bande passante et le RPO ; ajuster la fréquence, la compression ou la liaison.
- Repository immuable saturé : revoir capacité, rétention et fulls ; ne tentez pas de contourner l’immutabilité pour purger de force.
- Restore test trop lent : distinguer lecture du repository, réseau, écriture cible et étapes humaines puis adapter le plan de reprise.