Sauvegarde, continuité et reprise d'activité
Ce que ce chapitre apporte
- Nommer les risques qui pèsent sur les données et les hiérarchiser.
- Définir RPO et RTO, et les relier à la fréquence des sauvegardes et aux moyens de reprise.
- Distinguer sauvegarde complète, incrémentale et différentielle, et calculer une chaîne de restauration.
- Déduire un type de sauvegarde d'un RTO et d'une fenêtre de sauvegarde.
- Appliquer la règle 3-2-1 et expliquer ce que chaque chiffre protège.
- Distinguer un plan de continuité d'un plan de reprise d'activité.
- Classer les services par criticité et en déduire une politique de sauvegarde.
- Expliquer pourquoi une sauvegarde jamais restaurée ne compte pas.
Ce contre quoi on se protège
Le stockage conserve les données sur un support. La sauvegarde en est une copie destinée à permettre la restauration après un incident.
La disponibilité est la capacité d'un service ou d'une donnée à rester accessible. L'intégrité est la garantie que les données n'ont pas été altérées.
Le RAID est un ensemble de techniques qui répartissent les données sur plusieurs disques d'une même machine, de sorte que la panne de l'un d'eux n'interrompe pas le service. Selon la variante retenue, les données sont dupliquées sur un second disque ou accompagnées d'informations de contrôle permettant de les reconstituer.
Les risques sont de natures différentes, et c'est ce qui interdit une réponse unique :
| Risque | Ce qu'il détruit | Ce qui protège |
|---|---|---|
| Panne matérielle | un support | la redondance, RAID |
| Erreur humaine | des fichiers, à une date | une sauvegarde ancienne |
| Suppression accidentelle | des fichiers, récemment | une sauvegarde récente |
| Rançongiciel | tout ce qui est joignable en écriture | une copie hors ligne |
| Incendie, dégât des eaux | le site entier | une copie hors site |
| Vol | les données et leur confidentialité | le chiffrement |
Le RAID répond à la disponibilité : le service continue malgré un disque mort. La sauvegarde répond à la perte. Ce sont deux besoins distincts, et l'un ne dispense jamais de l'autre.
RPO et RTO
Deux chiffres, et ce sont eux qu'on négocie avec les métiers, jamais la technique.
Le RPO (Recovery Point Objective) est la quantité de données qu'on accepte de perdre, exprimée en temps. Il est fixé par la fréquence des sauvegardes.
Le RTO (Recovery Time Objective) est la durée d'indisponibilité acceptable. Il est fixé par le temps de restauration et par les moyens de secours.
RPO = 24 heures. Une panne à 21 h fait perdre toute la journée de travail.
RTO = 4 heures. Le service est rétabli quatre heures après le début de l'intervention.
Si le métier annonce qu'il ne peut pas perdre plus de deux heures de saisie, le RPO de 24 heures est hors des clous : il faut sauvegarder plus souvent, ou répliquer en continu. Aucune discussion sur l'outil ne réglera cela.
C'est pourquoi le RTO coûte beaucoup plus cher que le RPO, et pourquoi il faut le faire arbitrer par la direction plutôt que de le promettre.
Les trois types de sauvegarde
Le choix d'un type de sauvegarde ne se fait pas par préférence : il découle du RTO fixé par le métier et de la fenêtre de sauvegarde dont on dispose.
La fenêtre de sauvegarde est le créneau, généralement nocturne, pendant lequel les données peuvent être copiées sans gêner la production.
Elle est bornée par des faits qui ne se négocient pas : l'heure à laquelle les derniers traitements du soir se terminent, et celle à laquelle les premiers utilisateurs se connectent. Une copie qui déborde de cette fenêtre ralentit la production, et une base de données copiée pendant qu'on y écrit produit une sauvegarde incohérente.
C'est cette fenêtre qui rend une sauvegarde complète quotidienne impossible au-delà d'un certain volume. Six heures de créneau et un débit de sauvegarde de 200 mégaoctets par seconde plafonnent la copie à environ 4 téraoctets par nuit, quel que soit le budget consacré au logiciel. Au-delà, la seule issue est de ne plus copier que ce qui a changé, donc de passer en incrémental ou en différentiel, et d'accepter en échange une restauration plus longue.
Complète : copie de l'ensemble des données.
Incrémentale : copie uniquement des modifications survenues depuis la dernière sauvegarde, quelle qu'elle soit.
Différentielle : copie des modifications survenues depuis la dernière sauvegarde complète.
Le choix se joue sur un arbitrage entre le temps de sauvegarde, l'espace occupé et le temps de restauration. Les deux premières colonnes du tableau sont contraintes par la fenêtre de sauvegarde, la troisième par le RTO.
| Durée de sauvegarde | Espace | Supports nécessaires pour restaurer | |
|---|---|---|---|
| Complète | longue | important | 1 |
| Incrémentale | très courte | faible | la complète, plus toutes celles qui suivent |
| Différentielle | croissante | moyen | la complète, plus une seule |
Le second est celui qui compte, parce que c'est celui où le temps est compté et où l'entreprise est à l'arrêt. Et parce qu'une chaîne incrémentale a un défaut supplémentaire : si un seul maillon est illisible, tout ce qui suit est perdu.
Cette dernière phrase se démontre. Le calendrier ci-dessous couvre deux semaines, avec une complète le premier et le huitième jour, et un support illisible au dixième. L'incident survient le douzième jour.
Restaurer au jour 12 : impossible, le support du jour 10 est illisible
Repli au jour 9, soit 3 jours de données perdues au-delà du RPO annoncé.
- Un seul support illisible, et 5 points de restauration sur 14 deviennent inatteignables. Chaque maillon portant le suivant, la rupture emporte tout l'aval jusqu'à la complète suivante.
En incrémentale, le support du jour 10 porte tous ceux qui suivent : la restauration au jour 12 est impossible, et le repli est au jour 9. Trois journées de saisie sont perdues, alors que les sauvegardes des jours 11 et 12 existent, sont lisibles, et ne servent à rien.
En différentielle, sur exactement le même incident, la restauration au jour 12 demande deux supports, la complète du jour 8 et la différentielle du jour 12, et le support illisible du jour 10 ne coûte que sa propre journée.
Cliquer un autre jour dans la figure montre l'étendue exacte des dégâts : en incrémentale, tout l'aval jusqu'à la complète suivante ; en différentielle, la seule journée concernée.
La règle 3-2-1
3 copies des données, sur 2 supports de nature différente, dont 1 hors site.
Chaque chiffre répond à un risque précis, et c'est ainsi qu'il faut la présenter :
- 3 copies : l'original et deux sauvegardes. Une sauvegarde peut être illisible au moment où on en a besoin, et on ne le découvre qu'à ce moment.
- 2 supports différents : disque et bande, disque et cloud. Un même modèle de disque acheté le même jour tombe en panne au même âge.
- 1 hors site : incendie, dégât des eaux, vol. Une sauvegarde dans l'armoire à côté du serveur ne protège d'aucun de ces trois cas.
La copie hors ligne est ce qui manque le plus souvent. Un rançongiciel qui obtient les droits d'administration chiffre aussi la sauvegarde en ligne, puisqu'elle lui est accessible en écriture. Une bande sortie du lecteur, ou un stockage immuable, ne peut pas être réécrite.
Continuité ou reprise
Le PCA (Plan de Continuité d'Activité) vise à ce que l'activité ne s'arrête pas. Il repose sur de la redondance : le service bascule, l'utilisateur ne voit rien ou presque.
Le PRA (Plan de Reprise d'Activité) vise à redémarrer après un arrêt. Il repose sur des sauvegardes et une procédure de remontée.
| PCA | PRA | |
|---|---|---|
| Objectif | ne pas s'arrêter | redémarrer |
| Moyens | redondance, bascule automatique | sauvegardes, procédure |
| RTO visé | proche de zéro | quelques heures à quelques jours |
| Coût | élevé, permanent | modéré |
La démarche consiste à classer les services par criticité, puis à mettre en continuité les seuls services dont l'arrêt bloque l'activité, et en reprise tout le reste. La criticité se définit avec les métiers, pas dans le service informatique.
Classer par criticité
La criticité d'un service mesure l'importance de son fonctionnement pour l'entreprise. Elle se lit dans une seule question : que se passe-t-il, concrètement, s'il s'arrête une heure ? Une journée ? Une semaine ?
| Service d'Ardexia | Arrêt d'une journée | Criticité | Politique |
|---|---|---|---|
| Annuaire | plus aucune session, tout est bloqué | maximale | continuité, deux contrôleurs |
| Système de gestion du laboratoire | aucun résultat rendu, activité arrêtée | maximale | continuité |
| Serveur de fichiers | comptes rendus et procédures inaccessibles | haute | reprise rapide, RTO 4 h |
| Messagerie | gêne forte, contournable | moyenne | reprise, RTO 24 h |
| Intranet documentaire | gêne faible | basse | reprise, RTO 72 h |
C'est la raison pour laquelle la criticité s'établit avec les métiers, et se réévalue. La cartographie du premier chapitre en est le point de départ : sans elle, on classe au jugé.
Le test de restauration
Tant qu'on n'a pas restauré, on n'a pas de sauvegarde : on a une tâche planifiée qui rend un code de retour.
Un test de restauration digne de ce nom vérifie quatre choses :
- Que la restauration aboutit techniquement.
- Que les données restaurées sont complètes, et pas seulement présentes.
- Que la durée réelle correspond au RTO annoncé.
- Que la procédure est exécutable par quelqu'un d'autre que celui qui l'a écrite.
Le quatrième point est celui qu'on néglige, et c'est celui qui compte un dimanche à trois heures du matin.
Exercices type
Complète le dimanche, incrémentale les autres jours. Un incident le vendredi : que restaure-t-on ?
La complète du dimanche, puis les incrémentales du lundi, mardi, mercredi et jeudi, dans cet ordre, puis celle du vendredi si elle a eu lieu avant l'incident. Soit cinq à six supports.
Chaque support est un point de rupture : s'il en manque un seul, tout ce qui suit est inexploitable.
En différentielle, il en aurait fallu deux : la complète du dimanche et la différentielle du jeudi soir. C'est l'argument décisif en faveur de la différentielle quand le RTO est serré.
Six téraoctets, 10 % de modifications par jour, un débit de 200 Mo/s et six heures de fenêtre. La différentielle tient-elle deux semaines ?
Non, et la figure le calcule nuit par nuit.
La complète demande 8 h 32 et déborde donc d'emblée : elle ne peut se faire qu'un week-end, ou en acceptant de gêner la reprise du matin. Ensuite, la différentielle grossit de 600 gigaoctets par jour, tient jusqu'au huitième jour avec 5 h 58, et déborde à partir du neuvième avec 6 h 50. Cinq nuits sur douze ne tiennent pas.
Restaurer au jour 12 : 2 supports à relire, 17 h 04
j1 → j12
- 45 To écrits sur la période, dont 6 To par complète. 5 nuits débordent de la fenêtre de 6 h (repérées par un point orange sur la ligne du haut).
Basculer en incrémentale ramène chaque nuit à 51 minutes, quelle que soit la date : c'est la propriété qui rend l'incrémentale indispensable dès que le volume grandit. La complète, elle, déborde toujours, et c'est pourquoi on la place le week-end quelle que soit la stratégie retenue.
Le problème n'est donc pas résolu, il est déplacé : la restauration au jour 12 demande alors douze supports au lieu de deux. C'est l'arbitrage complet du chapitre sur un seul calendrier, et il n'a pas de bonne réponse générale. Il existe un RTO, une fenêtre, et soit un choix qui respecte les deux, soit aucun, ce qui impose de reprendre l'infrastructure plutôt que le paramétrage.
La sortie habituelle, quand aucun des deux ne passe, est une complète moins fréquente accompagnée de différentielles, ou une sauvegarde par instantanés qui ne relit plus les données inchangées.
Une entreprise sauvegarde chaque nuit sur un NAS dans le même local. Que manque-t-il ?
Deux des trois chiffres de la règle 3-2-1.
Le hors site manque : un incendie, un dégât des eaux ou un vol emporte le serveur et le NAS ensemble.
Le support de nature différente manque aussi : deux ensembles de disques, souvent achetés en même temps, vieillissent de la même façon.
Et il manque probablement le quatrième chiffre : une copie hors ligne. Un NAS accessible en écriture depuis le réseau est chiffré par un rançongiciel en même temps que le reste.
Le correctif minimal et réaliste : une externalisation vers un stockage distant, et une copie immuable ou déconnectée.
Le métier demande un RPO de 15 minutes. Quelles conséquences ?
Une sauvegarde quotidienne ne suffit plus, ni même horaire. Il faut :
soit une réplication continue ou des instantanés très fréquents, ce qui suppose une infrastructure adaptée ;
soit une journalisation applicative permettant de rejouer les transactions depuis la dernière sauvegarde, ce que font les bases de données.
Le coût n'est pas seulement matériel : c'est une infrastructure à exploiter et à surveiller en permanence.
La bonne réaction n'est pas de refuser, c'est de chiffrer la demande et de la faire arbitrer. Un RPO de 15 minutes sur la base de production peut être justifié ; le même sur l'intranet documentaire ne l'est pas.
Quelle différence concrète entre PCA et PRA sur le serveur de fichiers ?
En PCA : deux serveurs, données répliquées en temps réel, bascule automatique. L'utilisateur perd sa connexion quelques secondes et continue de travailler. Coût : le double de matériel, en permanence.
En PRA : un serveur, des sauvegardes, une procédure. Après un incident, on remonte les données sur un serveur de remplacement. L'utilisateur ne travaille pas pendant quatre heures. Coût : les sauvegardes et un matériel de secours.
Le choix se fait sur le RTO acceptable, qui se négocie avec les métiers. Et l'un n'exclut pas l'autre : un PCA n'exempte pas de sauvegardes, puisqu'il ne protège pas d'une erreur humaine ni d'un rançongiciel, qui se répliquent tous deux fidèlement.
Comment savoir si la politique de sauvegarde fonctionne réellement ?
En restaurant. Il n'y a pas d'autre moyen.
Le test se planifie comme une opération : à date fixe, restaurer un jeu de données représentatif sur un environnement séparé, mesurer la durée réelle, vérifier l'intégrité du contenu, et faire exécuter la procédure par quelqu'un qui ne l'a pas écrite.
Ce qu'un test révèle presque toujours : un périmètre incomplet (une base oubliée, un partage ajouté depuis et jamais inclus), et une durée réelle supérieure au RTO annoncé.
Le compte rendu du test est le seul document qui permette d'affirmer un RTO devant la direction.
Un rançongiciel a chiffré les serveurs. Que fait-on, dans quel ordre ?
- Isoler : couper les liaisons réseau pour arrêter la propagation. Avant tout le reste.
- Ne pas restaurer immédiatement sur une infrastructure encore compromise : on rechiffrerait la restauration.
- Identifier la date de compromission, pour choisir un point de restauration antérieur. C'est ici que l'audit du chapitre précédent sert.
- Reconstruire l'environnement, puis restaurer depuis une copie hors ligne, la seule dont on soit sûr.
- Changer les secrets : comptes à privilèges, clés, certificats.
- Déclarer, selon le cadre légal applicable.
Le point qui décide de tout est le troisième : sans trace, on ne sait pas à quelle date remonter, et on restaure une sauvegarde déjà compromise.
Vérification
1.Le RPO se règle par quel moyen ?
2.Que signifie le dernier zéro de la règle 3-2-1-1-0 ?
3.Une grappe RAID protège-t-elle contre la suppression accidentelle d'un fichier ?
4.Une sauvegarde jamais restaurée, que vaut-elle ?
La méthode
- Nommer le risque avant de proposer une réponse. RAID, réplication et sauvegarde ne couvrent pas les mêmes.
- Compter les supports nécessaires à la restauration avant de choisir entre incrémentale et différentielle.
- Vérifier les trois chiffres de 3-2-1, puis demander où est la copie hors ligne.
- Chiffrer le RPO et le RTO en premier, et les faire arbitrer par les métiers. Ce ne sont pas des choix techniques.
- Mesurer la fenêtre de sauvegarde réelle, et vérifier que le volume à copier y tient avant d'arrêter un type.
- Classer les services par criticité à partir de la cartographie, et n'appliquer la continuité qu'aux plus critiques.
- Planifier un test de restauration et le faire exécuter par quelqu'un d'autre.
- Ne jamais annoncer un RTO qu'on n'a pas mesuré lors d'un test.
Synthèse
- RAID : panne de disque. Réplication : disponibilité. Sauvegarde : perte de données. Trois besoins distincts.
- Incrémentale : rapide à sauvegarder, longue à restaurer, chaîne fragile. Différentielle : l'inverse, deux supports suffisent.
- 3-2-1 : trois copies, deux supports différents, une hors site. Plus une hors ligne et zéro erreur au test.
- RPO : données perdues acceptables, réglé par la fréquence. RTO : indisponibilité acceptable, réglé par les moyens.
- Le RPO et le RTO se fixent avant le type de sauvegarde : ce sont eux qui le contraignent, jamais l'inverse.
- La fenêtre de sauvegarde plafonne le volume copiable par nuit, et c'est elle qui rend la complète quotidienne impossible au-delà d'une certaine taille.
- PCA : ne pas s'arrêter, par redondance. PRA : redémarrer, par restauration.
- La criticité se définit avec les métiers, jamais depuis la technique.
- Une sauvegarde jamais restaurée n'est pas une sauvegarde.
Mettre en pratique
Chaîne de restauration, ordre des incrémentales, et volume occupé.
- Ce qu'il faut pour restaurerNiveau 3
- Débogage : des incrémentales rejouées à l'enversNiveau 3
- Le volume que la sauvegarde occupeNiveau 2