L'audit demande la politique de sauvegarde : RPO 24 h, rétention 30 jours, « snapshots automatiques inclus ». Puis : montrez la dernière restauration réussie. Dernière tentative : il y a deux ans, partielle, personne ne se souvient du mot de passe de la base de test.
Une politique de sauvegarde sans preuve de restauration est un document de confiance — pas un contrôle opérationnel. En hébergement mutualisé comme en cloud, les échecs silencieux sont fréquents : sauvegardes vides, dumps corrompus, clés KMS révoquées, restauration possible en théorie mais jamais mesurée. L'auditeur ou le client enterprise ne demandera pas si vous sauvegardez — il demandera quand vous avez restauré pour la dernière fois, et combien de temps cela a pris.
Pourquoi les backups échouent sans qu'on le voie
Espace disque saturé — le script tourne, le fichier est tronqué. Permissions changées — la tâche planifiée s'exécute, l'écriture est refusée depuis la mise à jour. Chiffrement — la sauvegarde est présente, la clé perdue ou la rotation non documentée.
Périmètre incomplet — fichiers oui, base non ; production oui, buckets annexes non. Restauration hors SLA support — l'hébergeur restaure le disque, pas votre logique applicative.
| Test | Ce qu'il valide | Fréquence suggérée |
|---|---|---|
| Fichier unique | Accès backup, intégrité | Mensuel |
| Base complète | Cohérence SQL, RPO | Trimestriel |
| Machine virtuelle / volume | RTO infrastructure | Annuel |
| Inter-région | Reprise d'activité réelle | Annuel si DR |
Une sauvegarde qui n'a jamais été restaurée est une loterie — pas une assurance.
Dérouler un exercice crédible en quatre étapes
Préparer un environnement isolé, un jeu de données de référence, un chronomètre et un responsable nommé. Restaurer depuis la même source qu'en crise : snapshot hébergeur, restic, dump S3.
Valider par checksum, requêtes métier et connexion applicative — pas seulement « le service démarre ». Documenter dans un rapport d'une page : écarts par rapport au RTO/RPO, tickets correctifs ouverts.
Invoquez le support hébergeur si le scénario inclut leur brique — notez le délai de réponse : c'est aussi une preuve.
Contractualiser avec l'hébergeur
Demandez la fréquence des snapshots, la rétention, si la restauration est incluse ou facturée, le délai de support et l'immuabilité anti-ransomware. Comparez via l'annuaire et Sauvegardes : ce que recouvre l'inclus si disponible.
Alignez sauvegarde hébergeur et sauvegarde client (export hors compte) — une seule copie chez le même prestataire ne suffit pas toujours. Croisez avec Localisation des sauvegardes pour la cartographie des copies.
Scénarios à inclure dans le plan de test
Au minimum : restauration d'un fichier unitaire, dump complet de base, remontée d'une machine virtuelle ou d'un volume, et — si reprise d'activité inter-région — restauration depuis la région de secours. Chaque scénario produit un rapport daté avec RPO constaté et écarts par rapport à l'objectif contractuel. Sans variété, vous validez seulement le chemin le plus facile — pas celui dont vous aurez besoin en crise. Intégrez le résultat du test dans votre plan de continuité et communiquez-le au DPO ou à l'auditeur interne : une date et une durée mesurée valent mieux qu'une promesse de RPO sur papier.
Le sommet : le jour du ransomware
Décider et avancer sans angle mort
Planifiez un test de restauration sous trente jours avec au moins un scénario base de données complet et un scénario fichier critique. Publiez le rapport interne daté, assignez les actions correctives et intégrez le résultat dans votre plan de continuité. Liez l'exercice avec Localisation des sauvegardes et utilisez le comparateur si vous changez d'offre backup — la preuve datée vaut plus qu'un SLA imprimé.
Questions fréquentes
À quelle fréquence tester une restauration ?
Annuel minimum pour données critiques ; trimestriel si traitement sensible ou changements fréquents.
Restaurer un fichier suffit-il comme preuve ?
Non — variez les scénarios fichier, base, machine virtuelle et reprise d'activité inter-région.
L'hébergeur teste-t-il nos backups à notre place ?
Rarement la lisibilité de vos sauvegardes chiffrées — le test reste chez vous.
Que mettre dans le rapport de preuve ?
Date, source, durée, RPO constaté, anomalies, prochaine échéance et responsable.
Une politique de backup crédible commence par une phrase : dernière restauration réussie le … en … minutes. Affichez cette date dans votre documentation interne de continuité — pas seulement dans un PDF de politique que personne n'ouvre.