Le malheur des défaillances de sauvegarde est que l’on ne découvre généralement un problème que quand il est trop tard pour le corriger, comme pendant l’opération de restauration des données. Un administrateur de site Web en a fait l’amère expérience lorsqu’il a rechargé la sauvegarde pour un site e-commerce critique,
Logicide négligent

pour le compte de son employeur, après avoir déménagé le serveur Web dans un nouvel immeuble en co-location. La restauration cliqua sur des milliers de fichiers mais, quand le site fut complètement restauré, l’application d’achats en ligne refusa de fonctionner.
Appelé à la rescousse, un programmeur découvrit rapidement la faille : tout le contenu du site Web était sauvegardé de manière régulière, mais une base de données transactionnelle essentielle n’était pas touchée par la sauvegarde à cause d’un verrou de partage de fichier. A chaque sauvegarde, le logiciel de sauvegarde journalisait automatiquement un message signalant le problème de verrouillage de fichier, mais personne ne lisait le journal de près et donc personne ne sut que cette base de données critique et irremplaçable échappait à la sauvegarde.
La sauvegarde semblait fonctionner correctement. Sa durée était normale, elle consommait plusieurs volumes de sauvegarde et le fichier journal montrait des milliers de fichiers stockés. Même des restaurations ponctuelles semblaient réussir. Mais personne n’essaya vraiment d’exécuter l’application à partir des données restaurées et donc le loupé critique ne fut détecté que trop tard.
La leçon à tirer de ce cas est la suivante : « Lisez vos fichiers log ». Mais de quels fichiers log s’agit-il exactement ? Dans la plupart des entreprises, personne ne « possède » les fichiers log. Ils sont la propriété collective. Pourtant, chaque fichier log critique devrait avoir un propriétaire désigné. Les journaux de sauvegarde et de sécurité sont très certainement critiques. Le propriétaire du journal doit l’examiner régulièrement pour détecter des problèmes évidents. Il est également conseillé de changer de propriétaire périodiquement, pour éviter de succomber à la routine et à la force de l’habitude.
Aucun processus de vérification à lui seul ne peut prouver que les sauvegardes sont bonnes. Il est important de restaurer des sauvegardes périodiquement, mais le seul moyen de savoir qu’une sauvegarde est complète est de procéder à des répétitions occasionnelles du plan de reprise après sinistre.
Téléchargez cette ressource

Guide de Reporting Microsoft 365 & Microsoft Exchange
Comment bénéficier d’une vision unifiée de vos messageries, mieux protéger vos données sensibles, vous conformer plus aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Découvrez la solution de reporting complet de l’utilisation de Microsoft Exchange, en mode on-premise ou dans le Cloud.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- DPO : 5 ans après le RGPD, comment collaborer avec le RSSI ?
- EGERIE analyse les risques financiers liés aux risques cyber
- Vidéo « Accessibilité numérique » chez Microsoft
- Asklépian : des tests d’intrusion à 360° grâce à l’IA pour lutter contre les failles de sécurité
- Padok « faire du Cloud et de l’infrastructure, un véritable accélérateur business »
