Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est une hypothèse. Des sauvegardes fiables tiennent à trois décisions : combien de copies existent, à quelle distance de l'original elles vivent, et à quelle date remonte la dernière restauration menée jusqu'au bout. Tout le reste est du réglage.
8 min de lecture · mis à jour le 19 septembre 2026
Une sauvegarde non testée n'est qu'une hypothèse
La plupart des sauvegardes qui échouent n'échouent pas le jour de l'incident. Elles ont cessé de fonctionner des semaines plus tôt, sans bruit, et personne ne l'a vu parce que personne ne regardait autre chose que la présence d'un fichier dans un dossier.
Les causes sont prévisibles. Un script planifié tombe après une mise à jour du système sans envoyer d'alerte, parce qu'un script qui ne démarre plus ne produit pas d'erreur. Le disque de destination se remplit et les archives sortent tronquées. L'export de la base est pris pendant des écritures et ressort incohérent : il se restaure, mais avec des lignes orphelines qu'on ne découvrira qu'à l'usage. Les fichiers téléversés ne sont pas inclus, parce que la sauvegarde a été écrite au lancement du projet, quand ce dossier était vide.
Aucun de ces échecs ne se voit depuis le serveur de production. Ils se voient uniquement quand on tente une restauration complète, ailleurs, sur une machine vide. Tant qu'une restauration n'a pas été menée jusqu'à une application qui répond, il n'y a pas de sauvegarde, il y a un espoir stocké.
La règle 3-2-1, et ce que chaque chiffre achète
La règle tient en une ligne : trois copies des données, sur deux types de support différents, dont une hors site. Ce n'est pas une incantation, chaque chiffre couvre un mode de défaillance précis, et retirer un chiffre revient à accepter la panne correspondante.
- Trois copies — l'original et deux sauvegardes — parce que la seconde copie sert précisément aux cas où la première est illisible. Une sauvegarde unique transforme toute erreur de sauvegarde en perte définitive.
- Deux supports ou deux technologies distincts, parce qu'une défaillance frappe rarement un fichier isolé : elle frappe un modèle de disque, un système de fichiers, une version de logiciel, un compte. Deux copies sur le même type de stockage partagent le même défaut latent.
- Une copie hors site, parce que l'incendie, le dégât des eaux, la coupure prolongée et la fermeture d'un compte ne distinguent pas les serveurs d'une même salle.
- La variante que l'on croise souvent y ajoute une copie immuable ou déconnectée, et zéro erreur au contrôle de vérification. L'immuabilité répond à un rançongiciel, qui cherche les sauvegardes avant de chiffrer le reste. Le zéro répond au fait qu'une archive corrompue occupe le même espace disque qu'une archive saine.
Pourquoi une sauvegarde sur le même serveur ne protège de rien
Un dossier de sauvegardes posé sur le disque du serveur protège contre un seul scénario : la suppression accidentelle d'un fichier par quelqu'un qui s'en aperçoit tout de suite. C'est le scénario le moins coûteux de la liste, et le seul.
Tous les autres emportent la sauvegarde avec l'original. L'instance est supprimée par erreur, le compte est suspendu pour un moyen de paiement expiré, la machine est compromise et le rançongiciel chiffre d'abord les dossiers accessibles en écriture, la partition est corrompue, la salle brûle. À chaque fois, la copie partageait le destin de la source. C'est ce mode de défaillance partagé que la règle 3-2-1 sert à éliminer.
Les instantanés proposés par les hébergeurs souffrent d'une version atténuée du même problème. Ils sont utiles : ils ramènent une machine à l'état d'avant une mise à jour ratée en quelques minutes, ce qu'aucune restauration de fichiers ne fait aussi vite. Mais ils vivent dans la même console, sous le même compte, sur la même facture, et un accès administrateur volé les efface en même temps que le serveur. Un instantané est un outil d'exploitation, jamais un remplacement.
Au moins une copie doit donc partir vers une destination où les identifiants du serveur de production ne suffisent pas à effacer quoi que ce soit : autre fournisseur, droits en écriture seule ou rétention verrouillée.
RPO et RTO : combien vous perdez, combien de temps vous restez à l'arrêt
Deux questions distinctes se cachent derrière le mot sauvegarde, et les confondre produit des dispositifs coûteux qui ne répondent à aucune des deux.
Le RPO — point de reprise — est la quantité de données que vous acceptez de perdre, exprimée en temps. Une sauvegarde lancée chaque nuit à trois heures et une panne à dix-huit heures donnent un RPO effectif de quinze heures : tout ce qui a été saisi dans la journée est perdu. Pour un site vitrine dont le contenu change une fois par mois, c'est sans conséquence. Pour une boutique, ce sont les commandes d'une journée, avec des clients débités et des commandes introuvables. Le RPO fixe la fréquence des sauvegardes, rien d'autre.
Le RTO — durée de reprise — est le temps pendant lequel vous acceptez que le service reste arrêté. Il dépend peu de la fréquence des sauvegardes : il dépend du téléchargement de l'archive, de la réinstallation, de l'import de la base et du délai pour retrouver qui détient l'accès au registrar. Il ne s'estime pas au jugé, il se mesure au chronomètre pendant un test.
Le déséquilibre le plus fréquent est d'acheter un RPO très court sans avoir jamais regardé son RTO : des sauvegardes horaires, chiffrées, hors site, et une remise en service de deux jours parce que personne n'a la procédure et que la zone DNS n'a jamais été documentée. La perte de données était d'une heure, l'arrêt a duré quarante-huit. Ces deux valeurs se décident avec la personne qui supporte le coût de l'arrêt, pas entre techniciens.
Ce qu'on oublie de sauvegarder
L'objet d'une sauvegarde n'est pas un serveur, c'est ce qui ne peut pas être reconstruit. Cette distinction règle la question de ce qu'on inclut et de ce qu'on laisse dehors.
- La base de données, par un export cohérent produit par son propre outil, pas par une copie de ses fichiers pendant qu'elle tourne — une copie à chaud donne une archive qui se restaure et se corrompt ensuite.
- Les fichiers déposés par les utilisateurs et les médias de l'administration du site : ils ne sont dans aucun dépôt de code et sont irremplaçables.
- Les variables d'environnement et les secrets applicatifs, stockés à part et chiffrés, sans quoi la restauration produit une application qui démarre et ne se connecte à rien.
- La configuration du serveur : serveur web, proxy inverse, tâches planifiées, règles de pare-feu, comptes système. Cette partie se reconstruit, mais la reconstruire sous pression prend des heures.
- La zone DNS exportée et la liste des accès fournisseurs — registrar, hébergeur, service d'envoi d'e-mails. Une restauration techniquement réussie reste invisible tant que le nom de domaine pointe ailleurs.
- Ce qu'on n'inclut pas : les dépendances installées, les caches, les fichiers compilés et tout ce qui vit déjà dans le dépôt de code. Leur place est dans une procédure de reconstruction, pas dans une archive qu'on transporte chaque nuit.
Comment tester une restauration pour de vrai
Un test de restauration sérieux a quatre propriétés, et toutes les quatre comptent. Il part d'une machine neuve et vide. Il n'ouvre à aucun moment le serveur d'origine pour aller y chercher un fichier manquant. Il suit uniquement la procédure écrite. Et il est conduit par quelqu'un qui n'a pas écrit cette procédure, parce que son auteur comble les trous sans s'en rendre compte.
On chronomètre du début à la fin, et on note chaque point où le test s'est arrêté : un identifiant introuvable, une version de logiciel différente, un chemin absolu codé en dur, une extension absente. Ce n'est pas la réussite du test qui a de la valeur, c'est cette liste. Un premier test qui échoue à la troisième étape vous apprend infiniment plus qu'un test réussi par quelqu'un qui connaissait déjà le serveur par cœur.
Les vérifications à faire à l'arrivée sont concrètes : comparer le nombre de lignes des tables principales avec la production, contrôler que l'enregistrement le plus récent correspond bien à l'heure de la sauvegarde, ouvrir un fichier téléversé au hasard, se connecter avec un compte utilisateur réel, déclencher un envoi d'e-mail. Une base restaurée qui répond à une requête n'est pas une preuve suffisante.
Un contrôle automatique quotidien reste utile, à condition qu'il vérifie les bonnes choses : l'intégrité de l'archive, sa taille comparée à la veille, et surtout son âge. L'alerte la plus importante n'est pas celle qui signale un échec, c'est celle qui se déclenche quand aucune sauvegarde n'est arrivée — un script qui ne s'exécute plus ne signale jamais rien de lui-même. Le test complet, lui, se refait à date fixe et après chaque changement d'infrastructure : migration, changement de version majeure de la base, nouveau fournisseur de stockage.
Rétention, chiffrement et données personnelles
Une rétention de sept jours ne rattrape que les incidents visibles dans la semaine. Or les pires ne le sont pas : une suppression d'anciens enregistrements par un script mal paramétré, une corruption progressive, une erreur de configuration qui dégrade les données au fil des écritures se découvrent souvent bien après. C'est la raison d'être de la rotation classique — des points quotidiens récents, des points hebdomadaires, des points mensuels plus anciens — et cette raison-là est plus convaincante que la règle apprise par cœur.
Les sauvegardes se chiffrent, et la clé se stocke ailleurs que sur la machine sauvegardée. Une clé qui n'existe que sur le serveur perdu transforme des archives intactes en fichiers inutiles ; c'est un des échecs les plus frustrants qui soient, parce que tout avait fonctionné jusqu'à la dernière étape. La clé a donc sa propre procédure de conservation, distincte du reste.
Enfin, une sauvegarde contient les mêmes données personnelles que la production. Le pays où elle est stockée compte autant que celui du serveur principal, sa durée de conservation doit être décidée et écrite plutôt que subie, et une demande d'effacement doit être traitée en cohérence avec le cycle de rotation plutôt qu'ignorée. Ces questions se traitent au moment du choix de la destination des sauvegardes, pas après.