Faut-il sauvegarder ses données en continu pour se protéger des risques ?

La règle face au risque informatique est de savoir ce que l’on est prêt à perdre. Les sauvegardes sont une bonne réponse, à condition toutefois de faire preuve de flexibilité. Trop de sauvegardes sont réalisées de façon mécanique (une fois par semaine, à heure fixe et pour tous les postes de l’entreprise), sans tenir compte des situations particulières.

Il faut avoir le réflexe de lancer une sauvegarde complète après une opération d’importance, comme un inventaire. Il faut également penser à sauvegarder avec plus de fréquence les documents critiques, comme le plan d’un projet majeur, dont la création induit de nombreuses modifications quotidiennes.

La sauvegarde, hors jeu ?

La direction informatique ne peut que rarement prendre en compte les situations particulières qui pourraient nécessiter de pousser des sauvegardes intermédiaires. Et les équipes métiers n’ont que rarement le réflexe ou l’envie de lancer une sauvegarde ponctuelle.

Un autre problème met à mal les sauvegardes traditionnelles : notre dépendance au numérique. Parce que l’informatique est devenue essentielle dans la plupart des organisations, les périodes de récupération (allant de la restauration des données à la recréation ex nihilo des documents perdus) se traduisent de facto par une rupture d’activité. La question cruciale n’est donc plus « que suis-je prêt à perdre ? », mais « pendant combien de temps suis-je prêt à ne pas travailler ?».

Les exigences réglementaires rebattent également les cartes. Des textes comme le règlement RGPD (protection des données personnelles) ne pardonnent pas les fuites de données… et guère plus leur perte. La question n’est donc plus « que suis-je prêt à perdre ? », mais « qu’est-ce que la loi m’autorise à perdre ?».

Réplication avec historique : la solution ?

Pour répondre à ces défis, les sauvegardes doivent devenir toujours plus fréquentes. Mais les outils disponibles ne sont que rarement adaptés au temps réel, alors qu’une autre technique a fait ses preuves dans ce domaine : la mise en miroir des données. Elle consiste à répliquer le contenu d’un poste de travail sur une machine tierce, par exemple, un système de stockage en réseau. Un processus de synchronisation demandant moins de ressources processeur et réseau qu’une sauvegarde complète.

Attention toutefois, car la réplication n’est pas une sauvegarde : si vous effacez un fichier de la source, il disparaîtra aussi de la cible. Pire, si vous faites face à un ‘ransomware’ (ou rançongiciel), les données qu’il a chiffrées et bloquées seront dupliquées à l’identique. Le miroir sera donc lui aussi chiffré et bloqué.

Certains acteurs ont solutionné cette problématique en ajoutant une dimension temporelle au processus de réplication. Ainsi, si le miroir est bien l’exacte copie de ce qui est sur l’ordinateur source à l’instant T, il est possible de demander à accéder à une version plus ancienne de ce miroir, qui sera le reflet d’un état antérieur de l’ordinateur source. Cette réplication avec historique est accessible, aujourd’hui, dans un nombre croissant d’outils et de services en ligne.

Mixez les deux !

Malheureusement, tous les systèmes de stockage en réseau ne proposent pas encore la réplication en temps réel des données avec historique. Une solution possible consiste alors à cascader les deux méthodes : les postes de travail répliquent leur contenu sur l’unité de stockage (l’aspect temps réel) laquelle va sauvegarder les données à intervalles serrés sur une autre unité de stockage (l’aspect historique), par exemple un serveur distant. Une méthode qui permet de combiner le meilleur des deux mondes : réplication et sauvegarde.

David FEUGEY