2 Votre organisation a investi dans une infrastructure de sauvegarde complète. Les sauvegardes quotidiennes s’exécutent comme prévu. Mais si un incendie, une catastrophe naturelle ou une panne régionale détruit votre data center principal, toutes vos sauvegardes disparaissent avec lui. C’est pourquoi la sauvegarde hors site est indispensable : vous devez conserver des copies des données critiques en dehors de votre site principal, suffisamment loin pour qu’un même sinistre régional ne puisse pas détruire à la fois votre infrastructure principale et vos copies de sauvegarde. La sauvegarde hors site n’est pas facultative. C’est une obligation réglementaire dans de nombreux secteurs, une nécessité pratique pour la reprise après sinistre et la différence entre un incident maîtrisé et une catastrophe fatale pour l’entreprise. Pourtant, bâtir une infrastructure de sauvegarde hors site a longtemps été complexe, coûteux et lourd à exploiter. Les approches traditionnelles comme les coffres à bandes ou les répliques distantes assurent la séparation géographique, mais créent de nouveaux problèmes : logistique des bandes, latence, coûts réseau et complexité opérationnelle. Bien connaître les options de votre stratégie de sauvegarde d’entreprise (en anglais) est essentiel. Les approches modernes repensent ce problème. Cet article présente les bonnes pratiques de sauvegarde hors site pour les équipes d’infrastructure : comment choisir entre bande et cloud, les considérations réseau qui pèsent sur la sécurité et les coûts, les mécanismes de chiffrement et de protection, et comment vérifier que vos sauvegardes hors site sont réellement restaurables. Pourquoi la sauvegarde hors site compte : la séparation géographique La sauvegarde hors site protège contre les événements catastrophiques. Incendie de data center, ransomware qui compromet les sauvegardes sur site ou panne régionale du cloud : les copies hors site garantissent l’existence de données restaurables au-delà du rayon d’impact. La séparation géographique est le principe clé. Hors site ne veut pas dire hors réseau : cela signifie géographiquement séparé de votre data center principal, de sorte qu’un sinistre régional ne puisse pas toucher les deux sites. Selon votre évaluation des risques, il s’agit généralement d’une autre agglomération, d’une autre région ou d’un autre pays. Lorsque l’infrastructure principale tombe, la reprise après sinistre consiste à récupérer les sauvegardes depuis les sites distants et à restaurer les données sur une infrastructure de remplacement : site de secours, environnement cloud ou infrastructure locale reconstruite. Mettre en œuvre la stratégie de sauvegarde 3-2-1-1-0 (en anglais) donne toute sa valeur à votre sauvegarde hors site. Mais cette valeur n’existe que si la restauration est réellement possible le moment venu. La sauvegarde sur bande : atouts et compromis L’approche traditionnelle repose sur les cartouches de bande. Vous écrivez les données de sauvegarde sur bande sur votre site principal, puis transportez régulièrement les cartouches vers un coffre hors site. En cas de sinistre, vous récupérez les cartouches et restaurez les données sur l’infrastructure rétablie. La bande présente des avantages importants. Elle est exceptionnellement durable : bien stockée, une bande se conserve des décennies. Elle est hors ligne, ce qui la protège des ransomwares qui compromettent les systèmes de sauvegarde en ligne. Et elle est rentable à grande échelle : son coût par téraoctet est bien inférieur à celui du stockage en ligne. La sauvegarde sur bande pose cependant des difficultés opérationnelles qui l’emportent souvent sur les économies réalisées. Le problème logistique est bien réel. Les cartouches doivent être transportées physiquement, ce qui crée des fenêtres de vulnérabilité : si un sinistre survient pendant le transport, ces sauvegardes ne sont pas encore hors site. Le personnel doit en outre gérer les catalogues de bandes, savoir quelles données contient chaque cartouche et coordonner leur récupération lors d’une restauration. La restauration est lente. Pour restaurer depuis une bande, il faut récupérer les cartouches au coffre, les rapatrier, les charger dans un matériel compatible et restaurer les données. Cela prend des jours. Pour les organisations aux objectifs de temps de restauration (RTO) exigeants, c’est trop lent. La validation des bandes exige des tests coûteux. La bande est durable, mais des cartouches peuvent tomber en panne. S’assurer que les sauvegardes sur bande sont restaurables impose des tests réguliers : récupérer les cartouches, les charger et tester la restauration. Pour de gros volumes, des tests complets sont difficiles à organiser et coûteux. La sauvegarde dans le cloud : rapidité et automatisation Le stockage cloud est devenu l’approche dominante pour la sauvegarde hors site. AWS S3, Azure, Google Cloud et d’autres fournisseurs proposent un stockage objet réparti géographiquement et permettant une restauration rapide. La sauvegarde dans le cloud résout plusieurs problèmes de la bande. La répartition géographique devient simple. Les fournisseurs cloud exploitent des data centers dans plusieurs régions : stockez vos sauvegardes dans une région éloignée et vous obtenez la séparation hors site sans logistique de bandes. La restauration devient une opération réseau, sans récupération physique, délai de transport ni problème de compatibilité matérielle. La simplicité opérationnelle est considérable. Une fois configurée, la sauvegarde dans le cloud fonctionne de manière autonome. Les sauvegardes circulent automatiquement et les politiques de rétention s’appliquent d’elles-mêmes. Plus de cartouches, de rotation ni de logistique de coffre à gérer : la charge opérationnelle baisse fortement. La restauration est rapide. Restaurer depuis le cloud prend des heures ou des jours, et non des semaines. Selon la bande passante et le volume de données, vous restaurez rapidement des gigaoctets ou des téraoctets. Pour les organisations aux RTO stricts, la sauvegarde dans le cloud correspond à ces objectifs. Le stockage cloud implique toutefois d’autres compromis. Son coût par téraoctet est plus élevé que celui de la bande, même si les prix du cloud ont baissé avec la maturité du marché. Une connectivité réseau est nécessaire pour la sauvegarde et la restauration, ce qui a des implications de sécurité et de coût. Le stockage cloud est en ligne : une attaque qui compromet vos identifiants de sauvegarde peut compromettre vos sauvegardes. Ces compromis exigent une planification d’architecture rigoureuse. La bande passante réseau : la contrainte déterminante Transférer des données vers des sites distants implique d’importantes opérations réseau. Pour de gros volumes de sauvegarde, la bande passante est votre principale contrainte. La latence est une préoccupation secondaire. Des données qui parcourent des milliers de kilomètres jusqu’à des régions cloud éloignées subissent une latence plus élevée que les sauvegardes locales. Pour les opérations synchrones qui attendent une confirmation du site distant avant de valider la sauvegarde, cette latence rallonge les délais. Mais la plupart des architectures modernes acceptent une sauvegarde hors site asynchrone : les sauvegardes locales se terminent rapidement, et les copies hors site sont répliquées ensuite. La bande passante est le véritable goulot d’étranglement. Sauvegarder des centaines de téraoctets exige une bande passante sortante considérable. Si votre data center ne dispose que de 10 ou 100 Gb/s de bande passante internet, transférer des sauvegardes de plusieurs pétaoctets prend des semaines et pénalise souvent le trafic applicatif. Trois choix d’architecture permettent de lever ces contraintes. D’abord, préparez les sauvegardes en local. Au lieu d’envoyer toutes les sauvegardes directement vers le cloud, copiez-les d’abord sur un stockage local, puis transférez-les vers le cloud en heures creuses. Les E/S disque locales sont plus rapides que les E/S réseau, ce qui évite la congestion. Ensuite, réduisez les volumes. La déduplication et la compression diminuent le volume à transférer. Si la déduplication réduit le volume de sauvegarde de 50 %, vous divisez par deux le temps et le coût du transfert. Enfin, utilisez des services de transfert en masse. AWS Snowball est un appareil physique que vous remplissez de données et expédiez ; AWS charge ensuite les données dans votre bucket S3. Vous évitez totalement le transfert réseau. Pour l’amorçage initial des sauvegardes ou les transferts massifs, le transport physique est souvent plus pratique que le réseau. Protéger les données en transit et au repos La sauvegarde hors site transfère des données sensibles vers des sites externes, souvent via l’internet public. Le chiffrement en transit et au repos est donc indispensable. Le chiffrement en transit s’appuie sur TLS ou des protocoles similaires. Vos données de sauvegarde sont chiffrées pendant leur trajet entre votre data center et le cloud, ce qui empêche toute écoute et garantit que personne sur le réseau ne peut voir vos données. Mais TLS ne protège que pendant le transit. Si votre fournisseur de sauvegarde est compromis, ou si une personne ayant accès au stockage cloud lit vos données de manière malveillante, TLS ne vous protège pas. C’est pourquoi le chiffrement au repos est essentiel. Le chiffrement au repos signifie que vos données de sauvegarde restent chiffrées pendant leur stockage dans le cloud. Utilisez des clés de chiffrement distinctes de votre compte cloud. De nombreux fournisseurs proposent des services de chiffrement où vous fournissez vos propres clés et où ils chiffrent les données avant de les stocker : le fournisseur ne peut alors pas lire vos données. Même si l’infrastructure de stockage est compromise, les données restent chiffrées. Pour les sauvegardes les plus sensibles, adoptez le chiffrement côté client. Chiffrez les données dans vos locaux avant leur transmission. Vous obtenez un chiffrement de bout en bout : même votre fournisseur de sauvegarde ne peut pas les déchiffrer. Le chiffrement côté client exige une gestion des clés rigoureuse : vos clés doivent être protégées et récupérables pour pouvoir déchiffrer les sauvegardes hors site lors d’une restauration. Testez régulièrement la restauration : la vérification est indispensable La sauvegarde hors site peut donner une fausse impression de sécurité. Vous avez des sauvegardes hors site, donc vous vous croyez protégé. Mais si ces sauvegardes sont corrompues ou si les procédures de restauration ne fonctionnent pas, elles ne vous protègent en rien. La vérification exige des tests de restauration réguliers. Récupérez régulièrement des sauvegardes depuis le stockage hors site et testez leur restauration. Pour la bande, récupérez les cartouches au coffre et testez-les ; pour le cloud, récupérez les données et testez leur restauration sur une infrastructure de remplacement. Menez des tests de restauration réalistes. Ne vous contentez pas de restaurer quelques petits fichiers. Organisez régulièrement des tests complets qui simulent une véritable reprise après sinistre : restaurez un système ou un jeu de données complet sur une infrastructure de remplacement et vérifiez que le système restauré fonctionne correctement. Vous détecterez ainsi les problèmes d’intégrité des sauvegardes, de procédures de restauration ou de configuration de l’infrastructure que des tests partiels laisseraient passer. Tenez à jour une procédure de restauration. Documentez précisément comment restaurer depuis les sauvegardes hors site : étapes propres à votre infrastructure, emplacements des sauvegardes hors site, identifiants et autorisations nécessaires, infrastructure cible de la restauration. En cas de sinistre, votre équipe doit pouvoir suivre cette procédure sans avoir à tout réinventer. Conclusion : la sauvegarde hors site, une assurance essentielle La sauvegarde hors site est une composante indispensable de la reprise après sinistre. Mais elle n’est efficace que si elle est correctement architecturée, entretenue et vérifiée. Les organisations dont la sauvegarde hors site est digne de confiance la traitent comme un élément critique et investissent dans sa vérification continue. Choisissez entre bande et cloud en fonction de vos exigences de RTO, de vos volumes de sauvegarde, de vos contraintes réseau et de votre budget. Mettez en place un chiffrement adapté à vos besoins de sécurité. Testez régulièrement la restauration pour vous assurer que vos sauvegardes sont exploitables. Tenez à jour une documentation qui permet à votre équipe de restaurer le moment venu. La sauvegarde hors site est une assurance contre les défaillances catastrophiques. Comme toute assurance, elle n’a de valeur que si elle couvre réellement ce que vous croyez. Comprendre les différences entre RTO et RPO (en anglais) aide à aligner votre approche sur vos besoins de restauration. Intégrez la vérification à votre programme de reprise après sinistre : vous pourrez alors être sûr que vos sauvegardes hors site vous protégeront vraiment en cas de catastrophe. Pour aller plus loin La stratégie de sauvegarde 3-2-1-1-0 expliquée (en anglais) RTO ou RPO : les principales différences (en anglais) DRaaS : la reprise après sinistre en tant que service (en anglais) Survivre à une panne de data center : planifier la résilience (en anglais) Sauvegarde sur bande ou dans le cloud : guide de décision pour l’entreprise Le plan de continuité d’activité (en anglais)
