Audit sauvegarde : comment vérifier qu’une restauration fonctionne vraiment ?

Pourquoi une sauvegarde en succès ne suffit pas ?

Beaucoup de PME pensent être protégées parce que leur solution de sauvegarde indique “succès”. C’est un bon début, mais cela ne prouve pas que la restauration fonctionnera réellement en cas de panne, suppression accidentelle, ransomware ou corruption de données.

Une sauvegarde peut être techniquement terminée, mais inutilisable au moment critique : données incomplètes, application non cohérente, base de données corrompue, mot de passe manquant, temps de restauration trop long ou dépendance oubliée.

C’est l’objectif d’un audit sauvegarde PRA PCA : vérifier que les sauvegardes existent, mais surtout qu’elles sont restaurables et compatibles avec les besoins de reprise de l’entreprise.

Les contrôles essentiels pour valider une restauration

Une restauration doit être vérifiée sur plusieurs niveaux. Il ne suffit pas de restaurer un fichier isolé si l’activité dépend d’un serveur complet, d’une application métier ou d’une base de données.

1. Définir ce qui doit être restauré

Avant de tester, il faut définir ce qui est réellement critique pour l’entreprise. Toutes les données n’ont pas la même priorité. Certains fichiers peuvent attendre, tandis que la messagerie, l’application métier, la comptabilité ou un serveur de production peuvent bloquer l’activité immédiatement.

• Serveur de fichiers.
• Application métier.
• Base de données.
• Messagerie ou données Microsoft 365.
• Dossiers RH, comptabilité ou clients.
• Contrôleur de domaine ou services d’authentification.
• Serveur de sauvegarde ou console d’administration.

Cette étape permet de choisir un scénario de test utile, plutôt qu’un simple essai symbolique.

2. Tester la restauration d’un fichier simple

Le premier test consiste à restaurer un fichier supprimé ou un dossier simple. C’est rapide, mais déjà très utile pour vérifier que les sauvegardes sont accessibles, que les droits fonctionnent et que les données restaurées sont exploitables.

• Choisir un fichier de test représentatif.
• Restaurer le fichier dans un emplacement sécurisé.
• Vérifier l’ouverture du fichier.
• Comparer la version restaurée avec l’original.
• Vérifier les droits d’accès après restauration.
• Documenter le temps nécessaire.

3. Tester la restauration d’un dossier complet

Restaurer un dossier complet permet de vérifier un cas plus réaliste. Il faut s’assurer que l’arborescence, les fichiers, les droits et les versions sont cohérents.

• Restaurer un dossier avec plusieurs sous-dossiers.
• Vérifier la présence des fichiers attendus.
• Contrôler les droits d’accès.
• Tester l’ouverture de plusieurs types de fichiers.
• Vérifier la date de la sauvegarde utilisée.
• Documenter les éventuelles erreurs.

4. Tester une machine virtuelle ou un serveur

Pour une PME qui utilise des serveurs ou des machines virtuelles, il faut aller plus loin. Restaurer un serveur permet de vérifier si le système redémarre réellement et si les services fonctionnent correctement.

• Restaurer la machine dans un environnement isolé.
• Vérifier le démarrage du système.
• Contrôler les services Windows ou Linux.
• Vérifier les journaux d’erreur.
• Tester les accès applicatifs.
• Mesurer le temps total de restauration.

Ce test est essentiel pour évaluer la capacité de reprise après panne serveur ou ransomware.

5. Tester une application métier

Restaurer un serveur ne suffit pas toujours. Il faut vérifier que l’application métier fonctionne réellement : connexion utilisateur, accès aux données, génération de documents, export, impression ou intégration avec d’autres services.

• L’application démarre-t-elle correctement ?
• Les utilisateurs peuvent-ils se connecter ?
• Les données récentes sont-elles présentes ?
• Les impressions ou exports fonctionnent-ils ?
• Les dépendances réseau ou base de données sont-elles disponibles ?
• Le prestataire métier doit-il être impliqué ?

Ce point est souvent oublié, alors qu’il est déterminant pour la reprise d’activité.

6. Tester la restauration d’une base de données

Les bases de données nécessitent une attention particulière. Une sauvegarde de fichiers ne garantit pas toujours une base cohérente si l’application était active pendant la sauvegarde.

• Restaurer la base dans un environnement de test.
• Vérifier son intégrité.
• Contrôler la cohérence avec l’application.
• Tester quelques enregistrements récents.
• Vérifier les journaux ou transactions si nécessaire.
• Valider avec l’éditeur ou le prestataire métier si besoin.

7. Vérifier Microsoft 365, OneDrive, SharePoint et Exchange

Les données Microsoft 365 sont souvent critiques : e-mails, fichiers OneDrive, bibliothèques SharePoint, Teams et boîtes partagées. Il faut vérifier ce qui peut être restauré et dans quels délais.

• Restauration d’un e-mail supprimé.
• Restauration d’une boîte ou d’un dossier de messagerie.
• Restauration d’un fichier OneDrive.
• Restauration d’une bibliothèque SharePoint.
• Vérification des versions de fichiers.
• Évaluation du besoin de sauvegarde Microsoft 365 dédiée.

Ce sujet peut être croisé avec un audit Microsoft 365.

8. Contrôler l’intégrité des données restaurées

Une restauration réussie techniquement doit être validée fonctionnellement. Les données doivent être lisibles, complètes et utilisables.

• Ouvrir plusieurs fichiers restaurés.
• Vérifier les dates et versions.
• Comparer avec les données attendues.
• Contrôler les droits d’accès.
• Tester les données avec l’application métier.
• Faire valider par un utilisateur métier si nécessaire.

9. Mesurer le temps réel de restauration

Le temps de restauration est un indicateur essentiel. Une sauvegarde peut être fiable, mais trop lente pour les besoins de l’entreprise. Il faut donc mesurer le temps réel nécessaire pour restaurer les données ou services critiques.

• Temps de préparation.
• Temps de téléchargement ou copie des données.
• Temps de restauration technique.
• Temps de vérification.
• Temps de remise en service.
• Temps de validation métier.

Cette mesure permet d’évaluer si l’objectif de reprise est réaliste.

10. Comparer le résultat au RTO et au RPO

Deux indicateurs sont essentiels dans un audit sauvegarde : le RTO et le RPO.

RTO : délai maximal de reprise

Le RTO correspond au temps acceptable pour redémarrer un service après un incident. Si l’entreprise ne peut pas se passer d’une application plus de quatre heures, la restauration doit être compatible avec ce délai.

RPO : perte de données acceptable

Le RPO correspond à la quantité de données que l’entreprise peut accepter de perdre. Si la dernière sauvegarde utilisable date de 24 heures, l’entreprise peut perdre jusqu’à une journée de travail sur le périmètre concerné.

• Le temps de restauration est-il acceptable ?
• La dernière sauvegarde est-elle assez récente ?
• Les données critiques sont-elles couvertes ?
• L’entreprise peut-elle continuer à travailler pendant la reprise ?

11. Tester dans un environnement isolé

Une restauration de test ne doit pas perturber la production. Il est recommandé de restaurer dans un environnement isolé, surtout pour les serveurs, bases de données ou applications métier.

• Éviter d’écraser les données de production.
• Isoler le serveur restauré du réseau principal si nécessaire.
• Utiliser un réseau de test.
• Éviter les conflits de nom ou d’adresse IP.
• Contrôler les accès pendant le test.
• Supprimer proprement l’environnement après validation.

12. Vérifier les dépendances

Une application peut dépendre de plusieurs éléments : base de données, serveur de licences, Active Directory, DNS, partage réseau, certificat, imprimante, connecteur cloud ou accès Internet.

Un test de restauration doit vérifier ces dépendances afin d’éviter les mauvaises surprises le jour d’un incident.

• Dépendance Active Directory.
• Dépendance DNS ou DHCP.
• Dépendance base de données.
• Dépendance serveur de fichiers.
• Dépendance licence ou éditeur.
• Dépendance réseau, VPN ou Internet.

13. Documenter le test de restauration

Le test doit être documenté pour être utile. Sans trace écrite, il sera difficile de savoir ce qui a été testé, quand, par qui, avec quel résultat et quelles corrections sont nécessaires.

• Date du test.
• Périmètre restauré.
• Point de restauration utilisé.
• Durée totale du test.
• Résultat obtenu.
• Problèmes rencontrés.
• Actions correctives à prévoir.
• Validation technique et métier.

14. Prévoir des tests réguliers

Un test réussi une fois ne garantit pas que la restauration fonctionnera toujours. Les données, applications, versions, serveurs et procédures évoluent. Il faut donc planifier des tests réguliers.

• Test de fichier régulier.
• Test de dossier complet.
• Test d’un serveur critique.
• Test d’une application métier.
• Test Microsoft 365 si concerné.
• Test après changement important.

Pour cadrer la fréquence, consultez l’article À quelle fréquence faut-il réaliser un audit sécurité informatique ?.

15. Corriger les écarts détectés

Un test de restauration peut révéler des problèmes. C’est justement son intérêt. Il faut ensuite corriger les écarts : périmètre incomplet, rétention insuffisante, temps trop long, droits manquants, erreur applicative ou procédure non claire.

• Ajouter des données oubliées au périmètre de sauvegarde.
• Augmenter la fréquence de sauvegarde si nécessaire.
• Modifier la rétention.
• Protéger les sauvegardes contre les ransomwares.
• Documenter la procédure de restauration.
• Former les personnes concernées.
• Prévoir une solution de reprise plus rapide si besoin.

Checklist restauration sauvegarde PME

Voici une checklist simple pour vérifier qu’une restauration fonctionne vraiment.

• Périmètre critique identifié.
• Point de restauration choisi.
• Restauration réalisée dans un environnement sécurisé.
• Fichiers ouverts et contrôlés.
• Dossier complet vérifié si nécessaire.
• Serveur ou machine virtuelle redémarré si concerné.
• Application métier testée.
• Base de données contrôlée.
• Microsoft 365 vérifié si inclus.
• Droits d’accès validés.
• Temps de restauration mesuré.
• RTO et RPO comparés aux besoins métier.
• Résultat documenté.
• Écarts corrigés.
• Prochain test planifié.

Conclusion : une restauration doit être prouvée, pas supposée

Une sauvegarde n’a de valeur que si elle peut être restaurée. Pour une PME, il est donc indispensable de tester régulièrement les restaurations : fichiers, dossiers, serveurs, applications, bases de données et données Microsoft 365.

Le test permet de valider la fiabilité des sauvegardes, de mesurer les délais de reprise et de corriger les faiblesses avant un incident réel.