« On avait des sauvegardes » : anatomie d'un sinistre à 120 000 € quand la restauration échoue

Prenons un cas représentatif, reconstitué à partir de situations courantes du métier. Un administrateur de bases de données intervient en prestation pour une PME du e-commerce dont l'intégralité de l'activité repose sur une base de production : catalogue, commandes, clients, historique de facturation. Le DBA a mis en place une routine de sauvegarde nocturne, planifiée, qui s'exécute chaque nuit. Les logs affichent « succès » tous les matins. Le voyant est vert depuis des mois.

Un jour, un incident de stockage corrompt la base de production. Le DBA déclenche sereinement la procédure de restauration à partir de la dernière sauvegarde. Et c'est l'effondrement : l'archive ne se restaure pas. Le fichier est incomplet et partiellement corrompu ; les sauvegardes des nuits précédentes présentent le même défaut, hérité d'un changement de configuration passé inaperçu plusieurs semaines plus tôt. Le « succès » affiché chaque matin ne mesurait que l'exécution du job, jamais l'intégrité du fichier produit.

La base de production est inexploitable, et la sauvegarde censée la sauver l'est tout autant. L'activité du client est à l'arrêt.

C'est la grande illusion du métier : confondre l'exécution d'une sauvegarde avec sa validité. Un job de backup qui se termine sans erreur prouve une seule chose : que le processus est allé jusqu'au bout. Il ne prouve ni que le fichier produit est intègre, ni qu'il contient toutes les données, ni qu'il est restaurable sur une infrastructure donnée.

Les causes d'une sauvegarde inexploitable sont nombreuses et sournoises :

• L'archive corrompue silencieusement par un défaut de stockage ou de transfert, sans qu'aucune erreur ne remonte.
• Le jeu de sauvegarde incomplet : une base, un schéma ou une table exclus du périmètre à la suite d'une évolution non répercutée dans la configuration.
• La clé de chiffrement perdue ou non sauvegardée : l'archive existe, mais personne ne peut plus la déchiffrer.
• L'incompatibilité de version entre le moteur d'origine et celui de restauration, qui rend le fichier inutilisable.
• Le backup stocké au même endroit que la production, détruit par le même incident.

La seule preuve qu'une sauvegarde est valide, c'est une restauration testée et réussie. Tant que vous n'avez pas restauré une archive sur un environnement distinct et vérifié son intégrité, vous ne savez pas si vous avez une sauvegarde — vous avez un fichier dont vous espérez qu'il en est une.

C'est précisément ce maillon — le test de restauration — qui distingue une routine de protection d'un théâtre de protection.

Quand la restauration échoue, le préjudice ne se limite jamais au seul coût technique. Il s'empile en couches successives, et chacune se chiffre. Voici comment se décompose un sinistre type sur cette PME e-commerce.

On atteint environ 120 000 €, dont l'essentiel n'est pas le coût de la donnée elle-même mais ses conséquences immatérielles : l'activité paralysée, les ventes perdues, la confiance des clients entamée. Pour le DBA mis en cause, la question devient brutale : sur ces 120 000 €, quelle part va-t-on lui imputer, et comment va-t-il la financer ?

Le client reproche au DBA un manquement à son obligation de surveillance et de vérification des sauvegardes. Le débat indemnitaire portera sur la part réellement imputable au prestataire — mais même une fraction de ce montant suffit à mettre en péril un indépendant non assuré.

Beaucoup de DBA pensent que ce type de sinistre relève uniquement de la RC Pro. C'est en partie vrai pour la faute professionnelle, mais le cœur du dommage — l'atteinte aux données et l'indisponibilité — relève typiquement de la garantie cyber et atteinte aux données, conçue précisément pour ces situations.

Une couverture cyber adaptée au métier prend en charge plusieurs fronts simultanément :

• Les frais de récupération et de reconstitution des données, y compris l'intervention d'un prestataire spécialisé en data recovery.
• Les pertes d'exploitation liées à l'indisponibilité du système, qui constituent souvent le poste le plus lourd.
• L'expertise technique pour établir l'origine de l'incident, la nature exacte de la défaillance des sauvegardes et la part imputable à chacun.
• L'assistance d'urgence dès la déclaration : pouvoir mobiliser immédiatement des spécialistes au lieu de gérer seul une crise.

La différence entre un DBA couvert et un DBA seul ne se mesure pas qu'à l'indemnité finale. Elle se mesure dans les premières heures : face à une base perdue et un client en panique, disposer d'une cellule d'assistance qui prend la main change radicalement l'issue. Pour situer cette garantie dans l'ensemble de votre protection, consultez notre page assurance administrateur de bases de données.

La meilleure couverture ne dispense pas de réduire la probabilité du sinistre. Et sur ce risque précis, la prévention est largement à votre portée. Mieux : votre capacité à démontrer que vous testiez vos restaurations pèsera directement sur votre part de responsabilité en cas de litige.

1. Testez régulièrement la restauration, pas seulement la sauvegarde. Restaurez périodiquement une archive sur un environnement distinct et vérifiez l'intégrité et la complétude des données. C'est le seul test qui prouve quelque chose.
2. Appliquez la règle 3-2-1. Trois copies des données, sur deux supports différents, dont une hors site. Une sauvegarde détruite par le même incident que la production n'est pas une sauvegarde.
3. Surveillez l'intégrité, pas seulement l'exécution. Vérifiez les sommes de contrôle, la taille attendue des archives, la présence de tous les objets — pas uniquement le code retour du job.
4. Sécurisez et sauvegardez les clés de chiffrement séparément de l'archive. Une sauvegarde chiffrée dont la clé est perdue est définitivement morte.
5. Tracez vos tests par écrit. Conservez la date, le périmètre et le résultat de chaque test de restauration. Ce journal est, en cas de litige, la preuve que vous avez exercé votre vigilance.

Ce dernier point est décisif. Un DBA qui peut produire un historique de tests de restauration réussis démontre qu'il a rempli son obligation de vigilance et déplace la ligne de partage des responsabilités en sa faveur — exactement là où se gagnent les dossiers.

La leçon de ce sinistre type tient en une distinction. Une sauvegarde n'est pas un fichier qui se crée chaque nuit : c'est une capacité de restauration que l'on vérifie. Et le risque du DBA n'est pas seulement de commettre une faute, c'est que cette faute touche à la donnée — le bien le plus critique et le plus fragile de ses clients.

Votre protection doit donc combiner deux dimensions. D'un côté, la RC Professionnelle couvre la faute, l'erreur et l'omission dans votre prestation. De l'autre, la garantie cyber couvre l'atteinte aux données et l'indisponibilité, c'est-à-dire la conséquence la plus coûteuse de cette faute. Pour un métier dont l'activité tourne autour de l'intégrité des bases, ces deux volets ne sont pas optionnels l'un par rapport à l'autre : ils se complètent.

Le réflexe à adopter : ne jugez jamais une sauvegarde sur son exécution, jugez-la sur sa dernière restauration testée. Et calibrez votre couverture sur la valeur réelle des données dont vous avez la charge — car c'est cette valeur, et non le montant de votre prestation, qui détermine l'ampleur du sinistre le jour où l'archive refuse de se restaurer.