Un exercice de restauration des sauvegardes que vous ferez vraiment

La plupart des entreprises ont une sauvegarde. Beaucoup moins ont une restauration. La différence apparaît au pire mardi de l’année, quand quelqu’un supprime un dossier partagé, qu’une mise à jour de plugiciel corrompt une base de données ou qu’un compte est compromis, et que la question passe de « avons-nous des sauvegardes? » à « dans combien de temps retrouve-t-on le travail de lundi, et à partir de quel moment? »

Un exercice de restauration répond d’avance à cette question. On choisit un élément, on le restaure depuis la sauvegarde, on chronomètre et on note ce qui s’est passé. La version qui survit dans une petite entreprise est courte, planifiée et confiée à un seul responsable. Voici cette version.

Pourquoi « Terminé » n’est pas une preuve

Un tableau de bord de sauvegarde indique qu’une tâche s’est exécutée. Il n’indique pas que :

• Les données sauvegardées sont celles dont vous avez besoin
• Vous avez les identifiants et les accès pour les rapatrier
• La restauration fonctionne dans l’ordre qu’exigent vos systèmes
• Quelqu’un sait combien de temps elle prend
• La sauvegarde n’est pas chiffrée avec une clé partie avec un ancien employé

Chacun de ces cas a mordu une entreprise chez qui nous avons été appelés. Aucun n’est apparu comme un voyant rouge. Ils sont apparus quand quelqu’un a essayé.

Nous faisons le même constat dans nos notes sur l’AMF, les journaux et les sauvegardes qu’on peut restaurer : un programme de sécurité dont personne ne restaure rien est une brochure. Ce texte en est la suite pratique, le calendrier que vous pouvez réellement suivre.

Choisir la portée en trois niveaux

Inutile de tout restaurer. Il faut une courte liste de ce dont la perte ferait mal, et quelques preuves peu coûteuses.

1. Restauration-preuve (économique). Un fichier, un élément de courriel, une petite table. Peu d’enjeux, souvent répétée.
2. Restauration d’affaires (significative). Une bibliothèque partagée entière, la boîte complète d’un utilisateur, le site et sa base de données vers une copie de préproduction, un export de CRM chargé dans une instance de test.
3. Répétition de sinistre (rare). Reconstruire un système critique à partir de rien dans un environnement propre, avec la documentation que vous avez réellement.

Le premier niveau protège l’habitude. Le deuxième prouve que vous pouvez récupérer ce qui fait tourner l’entreprise. Le troisième dit si votre procédure est un document ou un vœu pieux.

Le rythme que nous recommandons

Pour une entreprise de dix à quarante personnes, ceci fonctionne sans devenir un emploi :

• Aux deux semaines (ou chaque semaine) : une restauration-preuve, 15 minutes
• Chaque trimestre : une restauration d’affaires, planifiée dans une plage calme
• Après tout changement d’outil : une restauration de plus, la même semaine
• Une fois par an : la répétition de sinistre, ou au moins un exercice sur table

Mettez les dates au calendrier d’une personne nommée, plus un substitut. Un exercice qui dépend de « quand ça va être tranquille » n’aura pas lieu. Ce n’est jamais tranquille.

Quoi restaurer, système par système

Rendez la liste concrète. Pour une PME montréalaise typique :

• Courriel et calendrier. Récupérer un élément supprimé et un message supprimé d’une boîte partagée. Vérifier les paramètres de rétention.
• Fichiers. Restaurer une version antérieure d’un document et un dossier supprimé de la bibliothèque partagée.
• Site web. Restaurer les fichiers et la base de données vers une copie de préproduction et charger le site. Une sauvegarde d’hébergeur que vous n’avez jamais ouverte est une rumeur.
• CRM et formulaires. Restaurer ou réimporter un échantillon de fiches, comme décrit dans un seul système pour le site, le CRM et la recherche.
• Serveurs ou logiciels métier. Restaurer sur une machine ou une instance de test, pas par-dessus la production.
• Configuration. Pouvez-vous recréer le DNS, les politiques d’identité et les paramètres clés à partir de notes ou d’exports?

Restaurez toujours dans un endroit sans danger, sauf si l’exercice est explicitement le vrai événement. « Restaurer par-dessus la production pour voir si ça marche », c’est comme ça qu’un exercice devient un incident.

Chronométrer et consigner

Le but de l’exercice est l’information. Pour chaque exécution, notez :

1. La date, la personne et ce qui a été restauré
2. Le point de sauvegarde utilisé (date et heure)
3. Le temps entre la décision et des données utilisables
4. Ce qui a mal tourné, même un détail
5. Ce que vous avez changé en conséquence
6. Qui doit être informé

Gardez ça dans une page simple, pas dans une application. La première entrée sera probablement inconfortable : une permission manquante, un identifiant expiré, une rétention plus courte que prévu. Tant mieux. C’est le problème que vous vouliez trouver par un après-midi calme.

Ces entrées permettent d’énoncer honnêtement deux chiffres : jusqu’où vous pouvez reculer (point de récupération) et combien de temps il faut pour retravailler (délai de récupération). La direction peut alors décider si ces chiffres sont acceptables. Sans exercice, les deux sont des suppositions.

Les constats habituels

Les mêmes choses reviennent dans la plupart des premiers exercices :

• Le système principal est sauvegardé, mais pas l’outil SaaS auquel personne n’a pensé
• La restauration exige un compte administrateur retiré depuis, ou une clé que personne n’a
• La rétention est de 30 jours et la perte a été découverte au 45e jour
• La sauvegarde contient les données mais pas les paramètres, donc le système restauré paraît faux
• La restauration fonctionne mais prend un jour et demi, alors que l’entreprise comptait sur quelques heures
• Personne n’a écrit les étapes, donc une seule personne sait le faire

Chacun a un correctif peu coûteux une fois repéré : ajouter l’outil SaaS, ranger la clé correctement, allonger la rétention, exporter la configuration, documenter les étapes. Le correctif coûteux, c’est de le découvrir pendant un incident.

Le garder en vie après le premier trimestre

Les exercices meurent de manières prévisibles. Évitez-les :

• Un responsable et un substitut, nommés
• L’entrée au calendrier crée un billet, et le fermer exige l’entrée au journal
• Revoir le journal lors d’une courte rencontre mensuelle ou trimestrielle; les constats non réglés se reportent
• Faire tourner le système qui reçoit la restauration d’affaires, pour que chacun soit testé au moins une fois par an
• Quand quelqu’un arrive ou part, vérifier que l’exercice a encore les accès nécessaires

Si une restauration-preuve prend plus d’une heure, réduisez-la. Un exercice qui paraît lourd se fait sauter.

Comment cela s’insère dans l’ensemble

L’exercice de restauration est une boucle d’une routine plus large : l’AMF là où il faut, des journaux qu’un humain lit, et une récupération testée à une date précise. Si vous voulez que quelqu’un exécute cette routine au quotidien, la TI clé en main à Montréal est notre façon de faire, avec le journal des exercices parmi ce que nous vous remettons.

Ce qu’il faut nous envoyer

Si vous ne savez pas par où commencer, envoyez une courte liste des systèmes dont la perte ferait mal, où chacun est sauvegardé, et la date de la dernière restauration dont vous vous souvenez. Nous répondons les jours ouvrables, de 9 h à 17 h HE, à hello@aervio.io ou au +1 438-498-3913. Nous vous dirons quels deux exercices faire en premier et combien de temps chacun devrait prendre. Notre travail en alertes et renforcement de la sécurité comprend la mise en place et l’exécution de ce calendrier pour vous.

Questions

À quelle fréquence faut-il tester une restauration?

Une petite restauration chaque semaine ou aux deux semaines, une restauration significative chaque trimestre, et une de plus après tout changement d’outil de sauvegarde, d’hébergement ou de rétention. Le rythme compte moins que le fait qu’il soit au calendrier avec un responsable.

Que faut-il restaurer en premier?

Quelque chose de sans importance mais de réel : un élément de courriel, un fichier d’une bibliothèque partagée, une table de base de données. Cela prouve la chaîne complète sans risque et installe l’habitude.

Les services infonuagiques comme Microsoft 365 ou notre hébergeur sauvegardent-ils pour nous?

Les fournisseurs protègent leur plateforme, pas nécessairement vos données contre une suppression, un écrasement ou un compte compromis. Vérifiez vous-même la rétention et les options de récupération, et testez ce que vous pouvez réellement récupérer, et en combien de temps.