Sauvegardes : l’assurance-vie numérique de l’entreprise

Une véritable stratégie de sauvegarde va beaucoup plus loin.

Son objectif est simple : permettre à l’entreprise de continuer à exister numériquement après un incident.

Un disque RAID n’est pas une sauvegarde

C’est probablement l’une des confusions les plus fréquentes.

Un serveur équipé de plusieurs disques en RAID peut continuer à fonctionner après la panne de l’un d’entre eux.

C’est très utile.

Mais si un utilisateur supprime un dossier, le RAID supprime parfaitement le fichier sur tous les disques.

Si une base de données est corrompue, la corruption est répliquée.

Si un ransomware chiffre les données, les différents disques contiennent les données chiffrées.

Le RAID apporte de la disponibilité. Il ne remplace pas une sauvegarde.

Le cloud n’est pas non plus automatiquement une sauvegarde

Autre idée reçue : « Nos données sont dans le cloud, donc elles sont sauvegardées. »

Un fournisseur cloud peut disposer d’une infrastructure extrêmement redondante. Cela protège contre certaines pannes de matériel ou de datacenter.

Mais que se passe-t-il si un utilisateur supprime volontairement un document ?

Si un compte administrateur est compromis ?

Si une synchronisation propage une suppression ?

Si l’entreprise perd l’accès à son compte ?

La haute disponibilité du fournisseur ne garantit pas nécessairement que l’entreprise pourra revenir à l’état précis qu’elle souhaite.

Production et sauvegarde doivent être considérées comme deux systèmes différents.

La première cause de restauration n’est pas forcément la panne

On imagine souvent la sauvegarde comme la solution au serveur qui prend feu.

Dans la réalité, elle peut être nécessaire pour des situations beaucoup plus banales.

Un salarié supprime un dossier.

Un fichier important est écrasé.

Une mauvaise manipulation modifie une base de données.

Une mise à jour provoque un dysfonctionnement.

Un logiciel corrompt certaines informations.

Un compte est piraté.

Un ransomware chiffre les fichiers.

Un administrateur commet une erreur.

La sauvegarde protège donc autant contre l’humain et le logiciel que contre le matériel.

Le ransomware change complètement la stratégie

Une sauvegarde accessible en permanence depuis le serveur qu’elle protège peut elle-même être attaquée.

Un attaquant qui obtient suffisamment de privilèges cherchera naturellement à supprimer ou chiffrer les sauvegardes avant d’attaquer la production.

C’est pourquoi une entreprise doit disposer d’au moins une copie suffisamment isolée de son environnement principal.

Cette copie peut être distante, protégée par des identifiants différents ou rendue immuable pendant une certaine période.

L’objectif est simple :

la compromission de la production ne doit pas permettre automatiquement de détruire toutes les sauvegardes.

La règle 3-2-1 reste une excellente base

Une stratégie classique consiste à appliquer la règle dite 3-2-1 :

3 copies des données ;

2 supports ou systèmes différents ;

1 copie située ailleurs.

Pour une PME, cela peut par exemple donner :

Données de production

↓

Sauvegarde locale rapide

↓

Sauvegarde distante dans un autre datacenter

Une copie supplémentaire protégée contre la modification peut encore améliorer la résistance aux attaques.

L’important est surtout d’éviter un point de défaillance unique.

Les VM ont considérablement amélioré les sauvegardes

La virtualisation apporte ici un avantage majeur.

Auparavant, reconstruire un serveur pouvait nécessiter de réinstaller le système d’exploitation, les logiciels, les configurations puis les données.

Avec une machine virtuelle correctement sauvegardée, il devient possible de restaurer un environnement beaucoup plus complet.

Système + configuration + applications + données

peuvent être remis en fonctionnement beaucoup plus rapidement.

Cela ne dispense pas de sauvegarder correctement les bases de données et fichiers importants, mais réduit considérablement le temps nécessaire pour reconstruire certains services.

Avec Docker, il faut surtout identifier ce qui doit survivre

Dans une architecture Docker, les conteneurs doivent généralement pouvoir être recréés.

Il n’est donc pas forcément utile de traiter chaque conteneur comme une machine irremplaçable.

Il faut surtout protéger :

les bases de données ;

les volumes persistants ;

les documents ;

les configurations ;

les secrets ;

et les fichiers permettant de reconstruire l’environnement.

Une bonne architecture distingue clairement ce qui peut être recréé de ce qui doit absolument être sauvegardé.

Sauvegarder la messagerie est également essentiel

Pour beaucoup d’entreprises, plusieurs années de mémoire se trouvent dans les mails.

Contrats.

Commandes.

Accords.

Pièces jointes.

Échanges commerciaux.

Documents administratifs.

Confier sa messagerie à un prestataire ne doit donc pas empêcher de réfléchir à une sauvegarde indépendante lorsque ces informations sont critiques.

La question à poser est très concrète :

« Si demain nous perdons l’accès à cinq années de mails, comment les récupérons-nous ? »

La réponse doit être connue avant l’incident.

Il faut sauvegarder les données, mais aussi savoir reconstruire l’entreprise

Une stratégie moderne ne doit pas uniquement copier les fichiers.

Il faut également protéger ce qui permet de remettre l’infrastructure en fonctionnement :

configurations des serveurs ;

bases de données ;

code source ;

configurations Docker ;

paramètres des applications ;

certificats lorsque nécessaire ;

documentation ;

informations permettant de reconstruire les VM ;

et procédures de restauration.

Car posséder les données sans savoir comment reconstruire les applications qui les exploitent peut considérablement rallonger une reprise d’activité.

Une sauvegarde jamais restaurée reste une hypothèse

C’est probablement la règle la plus importante.

Un logiciel peut afficher tous les matins :

« Backup successful »

Cela ne démontre pas nécessairement que l’entreprise est capable de restaurer son activité.

Il faut régulièrement effectuer de véritables tests.

Restaurer un fichier.

Restaurer une boîte mail.

Restaurer une base de données.

Restaurer une VM.

Puis vérifier que le service fonctionne.

Le succès d’une sauvegarde ne se mesure pas au moment où elle est créée. Il se mesure au moment où elle est restaurée.

Il faut définir combien de données l’entreprise accepte de perdre

Toutes les entreprises n’ont pas les mêmes exigences.

Une société peut considérer qu’elle peut perdre les données produites pendant les dernières 24 heures.

Pour une autre, perdre une heure de commandes serait déjà inacceptable.

C’est ce que l’on appelle le RPO, Recovery Point Objective.

Si une sauvegarde est réalisée toutes les 24 heures, une panne survenant juste avant la sauvegarde suivante peut théoriquement faire perdre presque une journée de modifications.

Le rythme des sauvegardes doit donc être adapté à la valeur des données.

Et combien de temps peut-elle rester arrêtée ?

Deuxième question :

combien de temps pouvons-nous travailler sans ce système ?

Une heure ?

Une journée ?

Trois jours ?

C’est le RTO, Recovery Time Objective.

Une sauvegarde peut être parfaite tout en nécessitant deux jours pour être restaurée.

Pour une application critique, cela peut être inacceptable.

Il faut donc concevoir les sauvegardes en fonction de deux objectifs :

combien pouvons-nous perdre ?

et

en combien de temps devons-nous redémarrer ?

Tout ne mérite pas le même niveau de protection

Un site vitrine et la base de données contenant toute la facturation de l’entreprise n’ont pas nécessairement besoin de la même stratégie.

Il faut classifier les systèmes.

Critiques : ERP, bases clients, facturation, portail métier.

Importants : GED, fichiers partagés, messagerie.

Reconstructibles : certains serveurs web ou conteneurs dont la configuration est déjà conservée ailleurs.

Cette classification permet d’investir intelligemment dans la sauvegarde.

Une sauvegarde coûte très peu par rapport à une perte totale

La sauvegarde possède une particularité : lorsqu’elle fonctionne correctement, elle donne l’impression de ne servir à rien.

Pendant cinq ans, l’entreprise paie du stockage et de la maintenance sans jamais restaurer un serveur complet.

Puis un jour survient un incident.

Et quelques heures peuvent suffire pour justifier plusieurs années d’investissement.

Il faut donc éviter de mesurer la rentabilité d’une sauvegarde uniquement par sa fréquence d’utilisation.

Une assurance incendie n’est pas inutile parce que le bâtiment n’a jamais brûlé.

La sauvegarde doit être conçue avant la catastrophe

Une PME devrait être capable de répondre aujourd’hui à quelques questions simples :

Quelles données sont indispensables ?

Où sont leurs sauvegardes ?

Combien de versions conservons-nous ?

Une copie est-elle située ailleurs ?

Un ransomware peut-il atteindre toutes les copies ?

Qui peut lancer une restauration ?

Combien de temps prendra-t-elle ?

Quand avons-nous testé cette restauration pour la dernière fois ?

Si certaines réponses sont inconnues, le système de sauvegarde mérite probablement d’être revu.

Une entreprise doit pouvoir perdre ses serveurs sans perdre son entreprise

C’est finalement l’objectif.

Un serveur est remplaçable.

Un disque est remplaçable.

Une VM est reconstructible.

Un hébergeur peut être remplacé.

Même un bâtiment peut disparaître.

Les données de l’entreprise, elles, peuvent être irremplaçables.

Une bonne stratégie de sauvegarde doit donc permettre d’envisager le scénario le plus radical :

« Si demain toute notre infrastructure de production disparaît, sommes-nous capables de reconstruire l’entreprise numérique ailleurs ? »

Si la réponse est oui, la sauvegarde remplit réellement son rôle.

Car une sauvegarde n’est pas simplement une copie de fichiers.

C’est la capacité de l’entreprise à survivre numériquement à un incident.