La sauvegarde automatique en entreprise est un sujet réglé sur le papier dans presque toutes les organisations. Un outil tourne, une tâche s'exécute la nuit, un voyant est vert quelque part. La question qui compte n'est pourtant pas de savoir si la sauvegarde tourne, mais si la restauration fonctionne. Ce sont deux problèmes différents, et le second n'est presque jamais traité.
Les sinistres le rappellent toujours de la même façon : au moment de restaurer, on découvre que la base était sauvegardée à chaud sans cohérence transactionnelle, que le fichier de configuration nécessaire au redémarrage n'était pas dans le périmètre, que la clé de chiffrement est stockée sur le serveur détruit, ou que les archives sont saines mais que personne ne sait comment les remonter.
Cet article décrit une mise en place réaliste pour une PME : les quatre décisions à prendre, la surveillance des échecs silencieux, et surtout l'exercice de restauration à planifier deux fois par an. Rien d'exotique, mais chaque point manquant transforme un incident en arrêt d'activité.
La règle 3-2-1, et ce qu'elle ne dit pas
La règle 3-2-1 de sauvegarde tient en une phrase : trois copies des données, sur deux supports différents, dont une hors site. Elle reste un excellent point de départ, parce qu'elle traite les trois modes de défaillance les plus courants : la suppression accidentelle, la panne matérielle, et le sinistre local comme un incendie ou un dégât des eaux.
Elle a été étendue pour couvrir la menace principale des dernières années, le rançongiciel, qui chiffre aussi les sauvegardes accessibles depuis le réseau. Deux exigences s'ajoutent :
- Une copie hors ligne ou non modifiable. Support déconnecté, ou stockage à conservation verrouillée, sur lequel une donnée écrite ne peut être ni modifiée ni supprimée avant la fin de sa durée de rétention, y compris par un compte administrateur.
- Zéro erreur de vérification. Chaque sauvegarde doit être contrôlée automatiquement, et le contrôle doit être remonté.
Ce que la règle ne dit pas, et qui provoque l'essentiel des échecs : elle ne définit ni le périmètre, ni la fréquence, ni la procédure de retour. Trois copies d'un périmètre incomplet restent un périmètre incomplet.
Sauvegarde automatique en entreprise : quatre décisions à prendre
Le périmètre
Listez ce qui doit être restauré pour que l'activité reprenne, pas ce qui est facile à sauvegarder. L'exercice fait toujours apparaître trois oubliés : les configurations d'infrastructure, les secrets d'accès, et les données hébergées chez des tiers. Un service en ligne qui héberge votre messagerie, votre gestion commerciale ou vos fichiers partagés reste votre responsabilité en matière de sauvegarde : la plupart des contrats couvrent la disponibilité du service, pas la récupération d'une suppression que vous avez faite vous-même.
La fréquence, c'est-à-dire la perte acceptable
La fréquence de sauvegarde détermine ce que vous acceptez de perdre. Posez la question dans ce sens : combien d'heures de travail pouvons-nous refaire ?
| Type de données | Perte acceptable | Fréquence | Délai de remise en service visé |
| Base de production, gestion commerciale | 1 heure | Sauvegarde continue ou horaire | 4 heures |
| Fichiers de travail partagés | 24 heures | Quotidienne | 1 jour ouvré |
| Postes de travail | 24 à 72 heures | Quotidienne, différentielle | 2 jours ouvrés |
| Archives et documents figés | 1 semaine | Hebdomadaire | 1 semaine |
La rétention
Un rançongiciel ou une corruption de données peut rester invisible plusieurs semaines. Une rétention de sept jours ne protège de rien dans ce cas. Un schéma classique et suffisant : sept sauvegardes quotidiennes, quatre hebdomadaires, douze mensuelles. Vérifiez la cohérence avec vos obligations de conservation et de suppression, un sujet que nous traitons pour les données traitées par l'IA dans notre article sur la préparation des données avant leur envoi à un outil d'IA.
Le chiffrement, et l'endroit où vit la clé
Toute sauvegarde sortant du site doit être chiffrée. La question critique n'est pas l'algorithme, c'est la conservation de la clé : elle ne doit pas se trouver uniquement sur le système sauvegardé, ni uniquement dans la tête d'une personne. Une copie scellée hors ligne, avec une procédure d'accès écrite, est le minimum.
Détecter l'échec silencieux, le vrai sujet
Une sauvegarde ne tombe presque jamais en panne bruyamment. Elle se dégrade : un répertoire exclu par erreur, un disque de destination plein, un jeton d'accès expiré, une base verrouillée pendant la copie. La tâche se termine, le voyant reste vert, et l'archive est inutilisable.
Quatre contrôles automatiques couvrent la quasi-totalité des cas.
- L'alerte sur absence de succès. Le principe est contre-intuitif mais décisif : ne surveillez pas les échecs, surveillez l'absence de succès. La tâche de sauvegarde signale sa réussite à un système externe ; si ce signal n'arrive pas dans la fenêtre attendue, une alerte part. C'est le seul contrôle qui détecte une tâche qui ne s'est pas lancée du tout.
- La vérification d'intégrité de l'archive. La plupart des outils de sauvegarde modernes savent relire leurs données et vérifier les empreintes de chaque bloc. Programmez cette vérification une fois par semaine sur un échantillon, une fois par mois sur l'ensemble.
- Le contrôle de volumétrie. Comparez la taille de la sauvegarde du jour à celle de la veille. Une variation supérieure à 30 % dans un sens ou dans l'autre déclenche une alerte : elle signale une exclusion accidentelle, un chiffrement malveillant en cours, ou une purge non prévue.
- Le contrôle de contenu. Vérifiez la présence de trois à cinq fichiers témoins connus dans l'archive. C'est trivial à mettre en place, et c'est ce qui attrape les erreurs de périmètre.
Ces contrôles reposent sur des workflows planifiés dont le comportement en cas de panne doit lui-même être pensé. Les principes que nous détaillons pour gérer les erreurs dans les workflows automatisés valent ici mot pour mot : une chaîne de surveillance qui échoue en silence est plus dangereuse qu'une absence de surveillance, parce qu'elle produit de la confiance sans fondement.
Tester une restauration : l'exercice à planifier
C'est l'étape que tout le monde saute, et c'est la seule qui prouve quelque chose. Deux fois par an, une demi-journée, avec un scénario écrit à l'avance.
- Choisir un scénario réaliste : perte complète du serveur de fichiers, ou base de production corrompue à une date donnée. Un scénario par exercice, pas trois.
- Restaurer sur un environnement séparé, jamais par écrasement de la production. Une machine virtuelle temporaire suffit.
- Chronométrer. C'est la donnée la plus utile de l'exercice : le délai réel de remise en service est presque toujours deux à quatre fois supérieur à l'estimation initiale.
- Vérifier fonctionnellement, pas seulement techniquement. L'application redémarre-t-elle ? Les utilisateurs peuvent-ils se connecter ? Les derniers enregistrements sont-ils présents ?
- Faire l'exercice sans la personne qui a construit le dispositif. C'est le test le plus révélateur, et le plus inconfortable. Si personne d'autre ne sait restaurer, vous n'avez pas de sauvegarde, vous avez une dépendance.
- Écrire ce qui a manqué et corriger dans la semaine, tant que le souvenir est frais.
Consignez le résultat dans une fiche d'une page : date, scénario, durée constatée, écarts, actions correctives. Ce document a une valeur double : il sert de procédure le jour du sinistre, et de preuve de diligence face à un assureur ou à un client.
Documenter la procédure là où elle sera lisible
Une procédure de restauration stockée uniquement sur le serveur de fichiers qui vient de brûler ne sert à rien. Elle doit exister en dehors du système qu'elle protège : version imprimée dans un lieu sûr, ou copie hors ligne conservée avec la clé de chiffrement.
Son contenu tient en une page : où se trouvent les sauvegardes, qui a les accès, dans quel ordre remonter les systèmes, quels contrôles faire avant de rouvrir aux utilisateurs, et qui prévenir. Le même principe de rangement s'applique que celui décrit dans notre article sur l'automatisation de la gestion documentaire : un document introuvable au moment où on en a besoin équivaut à un document inexistant.
Ce qu'il faut retenir
Une sauvegarde automatique en entreprise se juge sur trois preuves, pas sur un voyant vert : une alerte se déclenche quand la sauvegarde n'a pas eu lieu, une vérification d'intégrité passe chaque semaine, et une restauration complète a été réalisée avec succès dans les six derniers mois par quelqu'un d'autre que le concepteur.
Si l'une de ces trois preuves manque, vous avez un dispositif de sauvegarde, pas un dispositif de reprise d'activité. Le plus rentable des trois chantiers, si vous n'en menez qu'un : l'alerte sur absence de succès. Une heure de mise en place, et elle attrape le mode de défaillance le plus fréquent, celui de la tâche qui ne tourne plus depuis des semaines sans que personne s'en aperçoive.
Laisser un commentaire