Concevoir la sauvegarde et la reprise après sinistre autour du RPO et du RTO

La plupart des dispositifs de sauvegarde sont jugés le jour où l’on en a besoin, et beaucoup échouent ce jour-là pour des raisons visibles bien avant : une tâche qui ignore silencieusement un volume, une base de données copiée en pleine écriture, une restauration qui prend des jours sur une liaison que personne n’a mesurée, ou des sauvegardes chiffrées par l’attaquant qui a chiffré la production.

Ce guide part de ces deux chiffres, l’objectif de point de reprise (RPO) et l’objectif de temps de reprise (RTO), et élargit progressivement le propos : combien de copies conserver, comment en faire survivre une à un rançongiciel, comment capturer les bases de données de manière cohérente, à quelle fréquence prouver que les restaurations fonctionnent, comment rédiger les runbooks et où va l’argent.

Commencer par le RPO et le RTO de chaque système

Le RPO est la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps. Un RPO de 24 heures signifie qu’une sauvegarde nocturne est acceptable. Un RPO de 15 minutes implique un envoi continu des journaux, une réplication ou des snapshots très fréquents. Le RTO est la durée pendant laquelle un système peut rester indisponible, mesurée de la panne jusqu’à la reprise du travail des utilisateurs.

Ces chiffres doivent venir du responsable métier de chaque système, et pas seulement de la DSI, et ils doivent être consignés par écrit. Les systèmes se répartissent généralement en quelques niveaux :

• Niveau 1. Les systèmes générateurs de chiffre d’affaires et en contact avec les clients, comme le traitement des commandes, les paiements et les bases de données principales. Objectifs typiques : RPO de quelques minutes, RTO de 1 à 4 heures.
• Niveau 2. Les systèmes internes dont les équipes dépendent au quotidien, comme l’ERP, les partages de fichiers, la messagerie et le ticketing. Objectifs typiques : RPO de 1 à 4 heures, RTO de 8 à 24 heures.
• Niveau 3. Archives, réplicas de reporting, environnements de développement et de test. Objectifs typiques : RPO de 24 heures, RTO de plusieurs jours.
• Reconstructibles. Serveurs sans état construits à partir de code ou d’images. Sauvegardez la configuration et la chaîne de build, pas les serveurs eux-mêmes.

Le RTO englobe tout : détecter la panne, décider de lancer la reprise, accéder au système de sauvegarde, provisionner le matériel, transférer les données et valider l’application.

La règle 3-2-1 et son extension moderne

La règle 3-2-1 classique consiste à conserver trois copies de vos données (la production plus deux sauvegardes), sur deux systèmes ou supports de stockage différents, dont une copie hors site.

De nombreuses équipes appliquent désormais la règle 3-2-1-1-0 : une copie est hors ligne ou immuable, et les restaurations sont vérifiées avec zéro erreur. Ces termes supplémentaires existent parce que les opérateurs de rançongiciels recherchent et suppriment les sauvegardes accessibles avant de chiffrer la production. Une sauvegarde qu’un compte administrateur peut supprimer n’est qu’une cible de plus.

En pratique, « deux supports » désigne aujourd’hui le plus souvent deux systèmes de stockage indépendants plutôt qu’un disque et une bande. Une appliance de sauvegarde locale associée à un stockage objet dans un autre site répond à la définition. Deux volumes sur la même baie n’y répondent pas, et un snapshot seul n’est pas une sauvegarde, car il partage le matériel et les identifiants des données qu’il protège.

Des copies immuables et isolées contre les rançongiciels

Une copie immuable ne peut être ni modifiée ni supprimée avant l’expiration de sa période de rétention, même par un administrateur. Les options courantes sont le stockage objet avec verrous de rétention à écriture unique en mode conformité, les appliances de sauvegarde à rétention renforcée et les supports physiquement mis hors ligne.

L’immuabilité n’est utile que si les contrôles qui l’entourent sont à la hauteur. Partez du principe qu’un attaquant détient les droits d’administrateur de domaine en production, et demandez-vous ce qu’il ne peut toujours pas atteindre :

• Identité séparée. La plateforme de sauvegarde utilise ses propres comptes, et non l’annuaire de production, avec une authentification multifacteur pour chaque connexion d’administration.
• Rétention verrouillée. Des verrous de rétention qui ne peuvent pas être raccourcis a posteriori, toute modification de la politique de rétention nécessitant l’intervention de deux personnes.
• Séparation réseau. Le stockage de sauvegarde n’est accessible que depuis les serveurs de sauvegarde, sur un réseau d’administration distinct, sans aucun accès entrant depuis les réseaux utilisateurs.
• Profondeur de rétention. Un historique suffisant pour remonter avant l’infection. Les attaquants restent souvent des semaines dans un réseau : 30 à 90 jours constituent un plancher réaliste pour le niveau immuable.
• Alertes sur les anomalies. Des alertes en cas de pic de données modifiées, de suppression de jeux de sauvegarde ou de modification de la rétention, souvent les premiers signes visibles d’une attaque.

Planifiez la restauration après rançongiciel séparément de la restauration après panne matérielle. Après un rançongiciel, vous devrez peut-être restaurer dans un environnement isolé, analyser les données, identifier le dernier point sain connu et reconstruire les identifiants avant de reconnecter quoi que ce soit.

Cohérence des bases de données : là où les sauvegardes de fichiers échouent

Copier les fichiers d’une base de données en cours d’exécution produit généralement une sauvegarde qui paraît complète mais échoue à la restauration, car les pages ont été capturées à des instants différents. Utilisez des méthodes que la base de données comprend.

• Outils de sauvegarde natifs ou à chaud. Utilisez la méthode de sauvegarde en ligne prise en charge par le moteur de base de données, ou un agent de sauvegarde qui s’y intègre, afin que la copie soit cohérente sur le plan transactionnel.
• Envoi des journaux pour un RPO court. Combinez des sauvegardes complètes périodiques avec l’archivage continu des journaux de transactions. Cela permet une restauration à un instant donné, y compris un retour juste avant un déploiement défectueux ou une modification malveillante.
• Snapshots cohérents au niveau applicatif. Si vous vous appuyez sur des snapshots de stockage ou de VM, mettez d’abord la base de données au repos ou figez-la (ou utilisez l’intégration de snapshot du moteur) pour que le snapshot capture un état cohérent.
• La réplication n’est pas une sauvegarde. Un réplica copie fidèlement, en quelques secondes, les suppressions, les corruptions et les mauvaises mises à jour. Conservez-le pour la disponibilité et un RTO court, et gardez des sauvegardes distinctes pour la capacité de restauration.

Mesurez le temps de restauration de la base de données, pas seulement le temps de sauvegarde. Une restauration implique souvent de rejouer des heures de journaux et de reconstruire des index, ce qui peut prendre plusieurs fois plus longtemps que la sauvegarde. Si une base de données de 4 TB a un RTO de 2 heures, vérifiez qu’une restauration peut le respecter ou s’il vous faut également une réplique de secours.

Une liaison de 1 Gbps à pleine charge transfère environ 125 MB par seconde, soit à peu près 10 TB par jour. En pratique, la surcharge des protocoles, la réhydratation des données dédupliquées et la vitesse de lecture du stockage limitent souvent le débit soutenu à 50 à 80 % du débit nominal de la ligne.

• Exemple. Restaurer 20 TB sur un lien 1 Gbps avec 70 pour cent d’efficacité prend environ 2,9 jours. Sur 10 Gbps, cela prend environ 7 heures, à condition que le stockage aux deux extrémités suive.
• La copie locale d’abord. Un niveau de sauvegarde local, proche de la production, assure rapidement la plupart des restaurations ; les niveaux hors site et immuable servent en cas de sinistre et d’attaque.
• Restaurer le sous-ensemble critique. Concevez le système pour que les données de niveau 1 puissent être restaurées en premier et de façon autonome, sans attendre l’ensemble des données.

Un calendrier de tests de restauration qui prouve la capacité de reprise

Une sauvegarde qui n’a jamais été restaurée est une hypothèse. Adaptez l’effort de test au niveau :

• Chaque jour. Contrôles automatisés de l’état des tâches et vérification automatisée de l’intégrité des fichiers de sauvegarde lorsque la plateforme le permet. Toute tâche en échec ou non exécutée ouvre un ticket.
• Chaque semaine. Restaurez un échantillon aléatoire de fichiers et de dossiers issus de différents systèmes et comparez-les aux sommes de contrôle ou à la source.
• Chaque mois. Restaurez au moins une base de données de niveau 1 dans un environnement isolé, effectuez un contrôle de cohérence et confirmez que l’application peut la lire. Consignez la durée écoulée.
• Chaque trimestre. Restaurez une pile applicative complète de niveau 1, dépendances comprises, depuis le niveau hors site ou immuable. Comparez le temps de reprise réel au RTO.
• Chaque année. Menez un exercice complet de reprise après sinistre, scénario de rançongiciel compris, avec les personnes qui seraient réellement d’astreinte. Incluez le processus de décision, pas seulement les étapes techniques.

Consignez chaque test : date, système, copie source, volume, durée écoulée et problèmes rencontrés. Lorsqu’un test dépasse son RTO, traitez-le comme un incident, avec un responsable et une échéance.

Des runbooks applicables sous pression

Les reprises sont généralement menées par la personne disponible, à une heure inconfortable, sous pression. Rédigez les runbooks pour cette personne : précis, numérotés et testés, avec les commandes, les noms d’hôte et les résultats attendus.

• Déclenchement et autorité. Les conditions qui déclenchent la reprise, qui peut déclarer un sinistre et qui doit être informé.
• Contacts. Responsables, fournisseurs et prestataires, avec des numéros de téléphone qui ne dépendent pas du bon fonctionnement de la messagerie.
• Accès. Comment atteindre la plateforme de sauvegarde et l’environnement de reprise si l’annuaire principal, le VPN ou le gestionnaire de mots de passe sont indisponibles. Conservez les identifiants d’urgence dans une procédure de bris de glace scellée et auditée.
• Ordre de reprise. La séquence des systèmes en fonction de leurs dépendances : réseau et DNS, identité, bases de données, puis applications.
• Procédures pas à pas. Les étapes exactes pour chaque système, avec la durée attendue de chacune et la manière de vérifier leur réussite.
• Validation et restitution. Comment le responsable métier confirme que le système est utilisable et que les données sont suffisamment à jour, et comment l’exploitation normale et les sauvegardes reprennent.

Conservez les runbooks dans un endroit qui survit au sinistre qu’ils décrivent : une copie imprimée, une copie chiffrée hors ligne et une copie hors de l’environnement de production.

Les arbitrages de coût et comment les faire

Chaque réduction du RPO ou du RTO a un coût, et la courbe est raide près de zéro. Passer d’un RPO de 24 heures à 1 heure coûte surtout des tâches plus fréquentes et du stockage de journaux. Tendre vers zéro implique généralement une réplication continue et un environnement de secours, ce qui double à peu près l’infrastructure de ces systèmes.

• Volume de stockage. La profondeur de rétention multiplie le stockage. La déduplication et la compression aident considérablement pour les sauvegardes de fichiers et de VM, moins pour les données déjà compressées ou chiffrées.
• Niveau immuable. Une rétention verrouillée signifie que vous payez toute la période, même pour des données que vous souhaiteriez supprimer plus tôt. Dimensionnez-la délibérément.
• Sortie de données et transfert. Certains services de stockage facturent les données lues ou transférées, ce qui renchérit les restaurations volumineuses et les tests fréquents. Intégrez les coûts de restauration dans votre estimation, pas seulement le stockage.
• Calcul de secours. Un environnement de secours tiède permet de tenir des RTO courts, mais coûte presque autant qu’un second environnement de production. Une architecture pilot light réplique les données et provisionne le calcul pendant la reprise : moins chère, mais plus lente.
• Personnel et temps de test. Les tests de restauration et la mise à jour des runbooks mobilisent des heures de travail chaque mois. Budgétez-les, car sans eux le reste de la dépense n’est pas prouvé.

Une règle de décision simple : pour chaque niveau, comparez la perte annuelle attendue avec les objectifs actuels au coût annuel de l’architecture qui permet d’atteindre des objectifs plus stricts. Si l’amélioration coûte moins que la perte qu’elle évite, faites-la. Sinon, documentez le risque accepté et faites-le valider par le responsable métier.

Checklist sauvegarde et restauration

• Chaque système : RPO, RTO, niveau et responsable écrits.
• Dépendances cartographiées ; l’ordre de reprise les suit.
• Trois copies par système concerné, sur au moins deux systèmes de stockage indépendants, dont une hors site.
• Au moins une copie immuable ou hors ligne, rétention de 30 jours ou plus pour les données critiques.
• Administration des sauvegardes sur comptes distincts avec MFA. Toute modification de rétention requiert deux personnes.
• Sauvegardes sur un réseau isolé, inaccessible depuis les réseaux utilisateurs.
• Sauvegardes de bases de données cohérentes et adaptées au moteur, avec archivage des journaux si le RPO est inférieur à quelques heures.
• Débit de restauration mesuré ; la plus grosse restauration Tier 1 tient dans son RTO.
• Planifiés et consignés : contrôle quotidien des tâches, restaurations hebdomadaires de fichiers, mensuelles de bases, trimestrielles d’applications et exercice complet annuel.
• Runbooks numérotés, testés, hors ligne, revus après chaque test ou changement majeur.
• Alertes : tâches en échec, sauvegardes supprimées, rétention modifiée, pics de modification des données.
• Coûts : stockage, transfert, calcul de secours, temps du personnel. Les responsables métier valident les risques acceptés.

Prochaines étapes

Commencez par renseigner le RPO, le RTO et le responsable de vos dix systèmes les plus importants, puis effectuez une restauration chronométrée du plus volumineux.

Si vous créez ou migrez des cibles de sauvegarde, Vonahost fournit des serveurs dédiés avec NVMe local ou stockage bloc réseau jusqu’à 1 PB dans la région de votre choix, et son cloud infogéré inclut les sauvegardes. Chaque proposition précise la configuration, l’emplacement, les responsabilités et le prix mensuel en dollars américains, afin d’établir clairement quelles parties du plan de reprise vous opérez et lesquelles relèvent du fournisseur.