Vos sauvegardes peuvent-elles vraiment être restaurées?
Une sauvegarde peut fonctionner chaque nuit pendant des mois et tout de même échouer au moment où l’entreprise en a réellement besoin.
Le problème n’est pas toujours que les données n’ont pas été copiées. Il peut s’agir d’une clé de chiffrement introuvable, d’un compte administrateur inaccessible, d’une machine virtuelle qui ne démarre pas, d’une dépendance réseau oubliée ou d’une sauvegarde Microsoft 365 qui ne contient pas l’élément attendu.
La question utile n’est donc pas seulement : « Est-ce que la sauvegarde a réussi? »
La question utile est : « Que pouvons-nous restaurer, dans quel ordre, avec quels accès et dans combien de temps réaliste? »
Une sauvegarde réussie et une reprise réussie ne sont pas la même chose
Un tableau de bord de sauvegarde indique généralement qu’un agent a copié des données vers une destination et que le travail n’a pas signalé d’erreur critique.
C’est important, mais incomplet.
Une reprise réelle exige souvent beaucoup plus :
- retrouver le bon point de restauration;
- confirmer que la copie n’est pas corrompue;
- disposer des mots de passe et clés nécessaires;
- reconstruire ou démarrer la machine cible;
- reconnecter le stockage, le réseau et les services d’identité;
- vérifier que les applications ouvrent leurs données;
- rétablir les utilisateurs dans un ordre raisonnable;
- confirmer que la restauration n’introduit pas de nouveau un logiciel malveillant.
Le résultat attendu n’est pas un fichier de sauvegarde. C’est un service utilisable.
1. Le point de restauration existe réellement
Le test doit identifier une date et une charge de travail précises, puis confirmer que les données attendues sont présentes.
Pour un serveur de fichiers, cela peut signifier retrouver plusieurs dossiers et versions. Pour Microsoft 365, cela peut vouloir dire restaurer un message, un fichier OneDrive ou un élément SharePoint. Pour une machine virtuelle, cela peut exiger un démarrage contrôlé dans un environnement isolé.
2. Les accès nécessaires sont disponibles
Une sauvegarde peut être intacte mais inutilisable si personne ne possède :
- les identifiants de la console;
- les clés de chiffrement;
- les comptes infonuagiques;
- les accès au stockage;
- les informations de licence;
- les mots de passe administratifs du serveur ou de l’hyperviseur.
Ces accès doivent être documentés, protégés et testés avant l’incident.
3. La copie est suffisamment indépendante
Une sauvegarde accessible au moyen des mêmes comptes qu’un attaquant pourrait compromettre peut être supprimée ou chiffrée avec le reste de l’environnement.
Le plan devrait examiner :
- la séparation des identités administratives;
- les droits de suppression;
- l’immuabilité lorsque pertinente;
- la présence de copies dans plus d’un emplacement;
- la protection des consoles de sauvegarde par MFA;
- la rétention nécessaire pour revenir avant un incident découvert tardivement.
4. Le système restauré démarre et fonctionne
Restaurer des fichiers n’est qu’une partie du travail. Un test plus complet peut devoir vérifier :
- le démarrage du système d’exploitation;
- les services Windows ou Linux;
- la base de données;
- l’application métier;
- les permissions;
- les tâches planifiées;
- les certificats;
- la communication avec d’autres serveurs;
- les fonctions critiques pour les utilisateurs.
Une machine qui démarre mais ne peut pas authentifier les utilisateurs n’est pas une reprise complète.
5. Le délai correspond au besoin de l’entreprise
Un système récupérable en quatre jours peut être techniquement protégé, mais inutilisable pour une entreprise qui ne peut tolérer que quatre heures d’arrêt.
Le test doit mesurer :
- le temps pour trouver le bon point de restauration;
- le temps de transfert des données;
- le temps de démarrage ou de reconstruction;
- le temps de validation;
- le temps pour remettre les utilisateurs au travail.
Ce délai réel doit être comparé au délai que l’organisation peut accepter.
Quels systèmes doivent être testés en premier?
Il n’est pas toujours réaliste de restaurer l’environnement complet chaque mois. Il faut commencer par les dépendances qui déterminent si le reste peut fonctionner.
Pour plusieurs PME, les priorités sont :
1. identité et comptes administratifs; 2. connexion Internet, pare-feu et VPN; 3. serveurs de fichiers ou applications métier; 4. machines virtuelles essentielles; 5. données Microsoft 365; 6. documentation, mots de passe et licences; 7. postes nécessaires aux fonctions critiques.
L’ordre exact dépend de l’organisation. Une clinique, un immeuble, un atelier et un bureau professionnel n’ont pas les mêmes dépendances.
Microsoft 365 mérite sa propre vérification
Exchange Online, OneDrive, SharePoint et Teams offrent des mécanismes de rétention et de récupération, mais ils ne répondent pas automatiquement à tous les scénarios de perte, d’erreur administrative, de suppression ou de conservation à long terme.
Un test utile devrait préciser :
- quelles charges de travail sont sauvegardées indépendamment;
- combien de temps les données sont conservées;
- qui peut lancer une restauration;
- si un élément peut être restauré vers son emplacement d’origine ou ailleurs;
- comment les comptes d’anciens employés sont traités;
- comment les fichiers partagés et permissions sont validés.
Le service de sauvegarde et reprise doit être conçu autour des données et délais réels de l’organisation, pas autour d’une simple liste de produits.
Signes qu’un plan de sauvegarde doit être revu
Une révision est justifiée lorsque :
- aucune restauration récente n’est documentée;
- une seule personne comprend la console;
- les sauvegardes utilisent les mêmes comptes administratifs que la production;
- les mots de passe ou clés sont difficiles à retrouver;
- les serveurs, VMs et Microsoft 365 sont protégés dans des systèmes sans vue commune;
- personne ne connaît le temps de restauration réel;
- un changement de fournisseur ou d’employé a laissé des accès incertains;
- les copies sont toutes dans le même emplacement;
- le volume de données a fortement augmenté;
- l’entreprise a ajouté une nouvelle application critique sans mettre à jour son plan.
Ce qu’il faut éviter pendant un incident
Lorsqu’une panne ou une attaque survient :
- ne supprimez pas les journaux utiles;
- ne réinitialisez pas tous les comptes sans conserver l’accès nécessaire aux sauvegardes;
- ne restaurez pas immédiatement par-dessus la seule copie existante;
- ne reconnectez pas un système potentiellement compromis sans validation;
- ne supposez pas que le point le plus récent est nécessairement le plus sain;
- ne lancez pas plusieurs réparations non documentées sur un stockage défaillant.
Une intervention précipitée peut transformer un incident récupérable en perte plus importante. Lorsqu’un disque, un RAID, un NAS ou une image devient illisible, consultez aussi notre approche de récupération de données.
Une routine raisonnable de validation
Une organisation peut adopter un cycle simple :
- vérification quotidienne des travaux et alertes;
- examen mensuel des échecs, capacités et rétentions;
- restauration régulière de fichiers ou éléments Microsoft 365;
- test trimestriel ou semestriel d’une charge de travail représentative;
- exercice annuel de reprise plus large;
- nouveau test après une migration, un changement de stockage ou une modification majeure.
La fréquence doit refléter le risque et la vitesse à laquelle l’environnement change.
Le résultat attendu
Après un bon test, l’organisation devrait pouvoir répondre clairement :
- quelles données sont protégées;
- où se trouvent les copies;
- qui peut y accéder;
- quel point de restauration a été vérifié;
- combien de temps la reprise a pris;
- quelles dépendances ont échoué;
- quelles corrections doivent être réalisées;
- quand le prochain test aura lieu.
Faire vérifier votre préparation à la reprise
Une évaluation de sauvegarde et de préparation à la reprise peut examiner une portée définie, les échantillons approuvés et les restaurations réellement testées. Les conclusions restent limitées aux systèmes, aux données et aux exercices examinés.
UNITECH peut prendre en charge la protection, la surveillance, la documentation et les tests de restauration dans le cadre d’un service de TI gérée ou cogérée.
Parler de votre capacité de reprise
Vous n’avez pas besoin d’attendre une panne pour découvrir les limites de votre sauvegarde.
Apportez la liste de vos systèmes importants, vos contraintes d’arrêt et ce que vous savez déjà de vos copies. Nous pourrons séparer les risques urgents des améliorations qui peuvent être planifiées.