Quarante-sept minutes : c’est le délai mesuré, chronomètre en main, pour remettre un site en ligne à partir d’une sauvegarde de dix gigaoctets restaurée en conditions réelles. Ce chiffre n’a rien d’une estimation approximative fondée sur la seule taille du fichier de sauvegarde ; il vient d’un test mené jusqu’au bout, étape par étape. Ce billet ne traite pas du choix de l’outil de sauvegarde, mais de la méthode pour vérifier que la restauration tient dans le délai promis.
Une sauvegarde jamais restaurée en conditions réelles reste une hypothèse, pas une garantie. Le seul moyen de savoir si elle répond à un engagement de délai de reprise consiste à la restaurer réellement, en chronométrant chaque étape, sur une infrastructure comparable à celle de production.
Pourquoi la taille du fichier ne suffit pas à estimer le délai
Un fichier de sauvegarde de dix gigaoctets ne se restaure pas à une vitesse constante d’un serveur à l’autre. Le débit disque, la bande passante réseau disponible pour rapatrier le fichier depuis un stockage distant, la puissance de traitement disponible pour décompresser et réimporter une base de données volumineuse : chacun de ces facteurs varie fortement selon l’infrastructure réelle, et aucun ne se devine en regardant simplement la taille du fichier.
La méthode : reproduire les conditions réelles, pas les conditions confortables
Un test de restauration effectué sur un poste de travail puissant, avec une connexion fibre et un disque à haute vitesse, ne mesure rien d’utile s’il ne reflète pas les conditions réelles de la production. La restauration doit être testée sur un environnement dont les caractéristiques se rapprochent de celles du serveur cible : même type de stockage, même bande passante disponible vers la source de sauvegarde, mêmes ressources de traitement.
- Provisionner un serveur de test dont les caractéristiques matérielles se rapprochent de la production.
- Récupérer le fichier de sauvegarde depuis son emplacement de stockage réel, pas depuis une copie locale déjà présente.
- Chronométrer séparément le rapatriement du fichier, la décompression, puis l’import en base de données.
- Vérifier l’intégrité du site restauré avant de considérer le test réussi.
- Consigner le délai total obtenu et le comparer à l’engagement de délai de reprise pris auprès du client.
Ce que la mesure a révélé sur un cas réel
Sur un test mené avec une base de dix gigaoctets stockée sur un espace distant chiffré, le rapatriement du fichier a représenté à lui seul près de la moitié du délai total, largement devant l’import proprement dit en base de données. Le délai complet mesuré s’est élevé à quarante-sept minutes, du déclenchement de la restauration jusqu’à un site fonctionnel et vérifié. Ce chiffre, une fois documenté, a permis de confirmer que l’engagement de reprise sous une heure pris auprès du client était tenable, mais sans marge confortable.
- Le temps de rapatriement du fichier dépend directement de la bande passante disponible vers le stockage de sauvegarde.
- L’import en base de données ralentit fortement si les index ne sont reconstruits qu’après l’insertion complète des données.
- Un test de restauration révèle aussi des dépendances oubliées, comme un chemin de fichiers codé en dur qui casse après restauration sur un nouveau serveur.
Une checklist pour ne pas se contenter d’un test unique
Un test réalisé une seule fois, à un instant donné, ne garantit rien pour l’avenir si l’infrastructure évolue ou si le volume de données grossit. La restauration doit être retestée à intervalle régulier, et systématiquement après un changement significatif d’hébergeur ou de volume de données.
- Retester la restauration après tout changement d’hébergeur ou de configuration serveur.
- Revalider le délai lorsque le volume de la base de données augmente sensiblement.
- Documenter le délai mesuré dans un endroit accessible à toute l’équipe, pas uniquement dans la mémoire de la personne qui a mené le test.
Une sauvegarde qu’on n’a jamais restaurée en vrai n’est qu’une promesse ; seul le chronomètre transforme cette promesse en engagement tenable.
En résumé
Le seul moyen fiable de savoir si une sauvegarde répond à un engagement de délai de reprise consiste à la restaurer réellement, sur une infrastructure comparable à la production, en chronométrant chaque étape séparément. Cette mesure, refaite à intervalle régulier, transforme une hypothèse rassurante en un engagement réellement tenable envers le client.
