Sauvegarder son serveur ne suffit pas : préparer et tester la restauration

Une notification « sauvegarde réussie » prouve qu’une opération s’est terminée. Elle ne prouve pas que l’application pourra redémarrer avec les bonnes données au moment où vous en aurez besoin.

La vraie mesure d’une sauvegarde est la capacité à restaurer un service exploitable. C’est un test technique, mais aussi une décision business : combien de temps peut-on s’arrêter et quelle quantité de travail peut-on perdre ?

Définir deux objectifs compréhensibles

Le RPO représente la perte de données maximale acceptable, exprimée en durée. Le RTO représente le délai visé pour rétablir le service. Ces deux objectifs orientent la fréquence des sauvegardes et les moyens de reprise.

Dans un exemple fictif, une application interne peut accepter une reprise des données de la veille. Un service qui reçoit des commandes en continu demandera peut-être une protection plus rapprochée. Les objectifs se décident avec les utilisateurs, pas uniquement avec l’hébergeur.

Il ne suffit pas d’écrire « RTO une heure » dans un document. Il faut mesurer si les accès, les données et les ressources permettent réellement de le tenir.

Sauvegarder un ensemble cohérent

Une application peut dépendre d’une base, de fichiers téléversés, de configurations, de clés de chiffrement et de services externes. Oublier l’un de ces éléments peut rendre les autres inutilisables.

Identifiez ce qui doit être sauvegardé ensemble et comment obtenir une copie cohérente de la base. Copier arbitrairement des fichiers pendant des écritures n’équivaut pas nécessairement à une sauvegarde applicative valide.

Les secrets indispensables à la reprise doivent être protégés et récupérables par les personnes autorisées. Une sauvegarde chiffrée dont la clé a disparu ne permettra pas la restauration.

Séparer les risques

Une copie stockée sur le même serveur ne protège pas contre toutes les pertes. Examinez la séparation des emplacements et des accès, ainsi que les protections contre l’effacement ou la modification des sauvegardes.

Ces choix doivent servir un objectif concret : remettre l’activité en route avec des données utilisables. La solution dépend du système et des risques couverts, pas seulement de la capacité de stockage disponible.

Tester sans abîmer la production

Restaurez d’abord dans un environnement isolé. Neutralisez les envois d’e-mails, les paiements, les webhooks et les tâches planifiées susceptibles d’agir sur de vrais dossiers.

Puis contrôlez :

1. l’ouverture de l’application et la connexion autorisée ;
2. la présence de dossiers récents et de leurs pièces jointes ;
3. la cohérence des liens entre les données ;
4. un parcours métier représentatif ;
5. le temps réel de remise en service.

Conservez le résultat, les écarts et les corrections à apporter. L’exercice doit tester la procédure écrite, pas uniquement les connaissances de la personne qui a installé le système.

Ne pas confondre restauration et retour de version

Un retour à une ancienne version applicative peut être rapide. Restaurer une ancienne base peut supprimer des opérations intervenues depuis la sauvegarde. La décision doit tenir compte de cette différence.

Avant un déploiement, vérifiez donc la compatibilité des données et la stratégie de reprise. Pour le quotidien, associez sauvegarde, alertes et responsabilité d’exploitation dans votre organisation Linux et cloud.

Le meilleur moment pour découvrir une procédure incomplète est pendant un exercice, pas pendant une panne.