La sauvegarde ne suffira pas

Sauvegarder, c'est bien. Mais croire que ça suffit, c'est risqué.

On l'entend tous les jours (et c'est bien) : 

« Sauvegardez vos données, c’est vital ! » Alors oui, sauvegarder est essentiel et c'est la base. 

Mais attention, une sauvegarde ne fait pas tout.

On se rassure souvent en se disant : « Mes données sont copiées, dans le cloud ou sur un disque dur, donc je suis couvert. ».
La réalité est un peu plus nuancée : sauvegarder ne veut pas dire redémarrer.

On peut penser qu'un snapshot remplace la sauvegarde, ou que la réplication suffit à se passer de tout le reste. En réalité, ces trois approches ont chacune leur rôle, avec des forces et des limites bien distinctes. Elles sont plus souvent complémentaires que concurrente

C’est parti ! Quelques chiffres avant de commencer ? 
Pas de soucis ! 

C'est quoi une sauvegarde ? 

(Désolé de repartir sur les bases, mais c’est important pour qu’on se comprenne bien.)

Pour être très factuel, faire une sauvegarde c'est faire une copie de vos données pour les stocker sur un support distinct (disque dur, cloud, bande, clé USB, disquette, etc.), afin d’être sûr de pouvoir les récupérer si votre système était compromis.  

Pour être précis, quand on parle données sauvegardées, on parle principalement de :

• Fichiers (documents, images, etc.)
• Bases de données (CRM, ERP, e-commerce…)
• Et éventuellement les VM (machines virtuelles) → On en parlera un peu plus bas. 

Pourquoi une sauvegarde est nécessaire ? Parce que sans sauvegarde, toute perte de données est définitive.
Mais ne nous emballons pas : Posséder une sauvegarde, c’est un peu comme avoir un double des clés de votre bureau en cas de perte c’est indispensable pour entrer à nouveau, mais si l’intérieur est ravagé il faudra bien plus qu'un double de clés pour reprendre l'activité.

Mais une sauvegarde, ca ne fait pas tout

• Vous ne sauvegardez pas votre infrastructure (serveurs, réseau, applications)
• Vous ne sauvegardez pas tous les paramètres ni la configuration de vos machines

En d’autres termes, vous avez les données, mais pas le « cadre » pour les exploiter. Il faudra tout réinstaller et reconfigurer avant de pouvoir redémarrer.

Et c’est souvent à ce moment là qu'on comprend : restaurer ne veut pas dire reprendre.

Les limites de la sauvegarde 

Maintenant, prenons un cas plus grave : un incendie dans la salle serveur. Vous êtes stressé, vous ne comprenez pas ce qui se passe, jusqu’à ce que j’arrive vers vous, sourire rassurant : « Ne vous inquiétez pas, j’ai tout sauvegardé ! » Je vous tends un disque dur avec toutes vos données que j'avais stocké hors de cette salle.

Alors là, vous soufflez, soulagé. Ouf !! Mais à partir de là … comment on redémarre ? 

• Vous avez vos données, mais il vous faut des serveurs (ou un ordinateur) 
• Il faut réinstaller tout le système (l’OS, les applications, la base de données).
• Reconfigurer la connexion réseau, la sécurité …
• Réimporter les données sauvegardées.

Et la question, c’est : combien de temps cela prendra-t-il pour que tout soit de nouveau opérationnel ?

Et c'est la qu'on commence à voir arriver les limites de la sauvegarde : Faire des sauvegardes, c’est la base, mais ca ne vous permet pas de relancer votre activité dans la minutes.

Et si vous rêvez d’un moyen de « figer » votre système exactement comme il était ce matin, puis de le restaurer en 2 minutes, il existe une autre option : le snapshot.
Génial non ? 

C'est quoi un Snapshot ?

Un snapshot est un « instantané » d’une machine virtuelle (ou d’un volume de stockage) à un moment T. Comme si on prenait une photo de l’état exacte de votre serveur (son OS, ses fichiers, ses réglages) : si un patch ou une manipulation tourne mal, vous pouvez revenir quasi instantanément à cet état précédent en quelque minutes.

C'est pratique surtout pour les mises à jour : Vous prenez un snapshot de votre VM à 9 h 00. À 9 h 05, une mise à jour plante ? Vous restaurez instantanément le snapshot de 9 h 00 et en quelques minutes, votre machine redevient opérationnelle, comme si rien ne s’était passé. Simple, efficace, pas cher.

Je fais un snapshot toutes les heures, à la place des sauvegardes c’est parfait, non ?

Sur le papier, oui, vous auriez un retour ultra précis à chaque heure de la journée. Mais comme souvent en pratique, c’est un peu plus complexe :
En clair, les snapshots ne sont pas une solution d’archivage ou de conservation long terme. Ce sont des points de sauvegarde locaux et éphémères.

Le système note un « point de passage » et journalise les changements postérieurs. C’est rapide à créer, mais :

•    Si l'hyperviseur est détruit (incendie, ransomware…), vous perdez le serveur ET ses snapshots.
•    Plus vous faites de snapshots, plus vous stockez des deltas (différences), ce qui peut vite remplir l’espace disque.
•    La multiplication de snapshots ralenti les performances de votre VM (il faut gérer de multiples “branches” de modifications).

Un snapshot remet toute la machine dans un état antérieur. Si vous voulez juste récupérer un petit fichier, vous devrez quand même manipuler l’instantané complet (par exemple, monter le snapshot séparément pour extraire le fichier). 

🛑 A noter l'important ici : le Snapshot est (souvent) stocké sur le même serveur que la machine virtuelle. En cas de défaillance ou perte du serveur (hyperviseur) , le snapshot est aussi compromis / détruits.

Si vous voulez récupérer un unique petit fichier que vous avez supprimer il y a un mois, un snapshot n’est pas la meilleure option. Il faudra monter l’intégralité du snapshot (s’il existe encore !), puis extraire le fichier. Mais s'il est est effacé, c’est perdu.

C’est là que la sauvegarde “classique” (complète, incrémentale, etc.) entre en jeu, avec une politique de rétention pour conserver des points de restauration plus anciens.

Tout est une question de rétention

Sauvegarde et snapshot se rejoignent sur la nécessité de définir un intervalle (combien de fois par jour/semaine) et une durée de conservation (1 semaine, 1 mois, 6 mois…).

   Snapshots : On recommande de n’en garder que quelques-uns, très récents (1 jour, 2-3 jours max).
   Sauvegarde : On peut conserver plusieurs versions (journalières, hebdomadaires, mensuelles…), selon la réglementation ou l’importance des données.

Cette notion de “politique de rétention” est cruciale :

   « Combien de temps, et à quelle fréquence, dois-je garder des points de restauration ? »

Trop peu, et vous n’aurez pas l’historique nécessaire. Trop, et vous risquez d’exploser vos coûts de stockage et de complexifier vos procédures de restauration. Le choix est Cornélien. 

RPO RTO ?  

Juste un petit détour rapide sur deux notions essentielles : Le RTO et le RPO (Recovery Time Objective et Recovery Point Objective).
Quand votre IT tombe en panne à cause d’un incendie, d’un ransomware ou d’une erreur humaine. Deux questions se posent :

•    Combien de temps faut-il pour tout redémarrer ? (C’est le RTO, Recovery Time Objective.)
•    Jusqu’à quel point dans le passé peut-on récupérer les données ? (C’est le RPO, Recovery Point Objective.)

   🔥 RTO : Si votre RTO est de 2 heures, cela signifie que votre entreprise estime qu’elle ne peut pas supporter une interruption de plus de 2 heures avant que tout soit remis en état de marche.
   🔥 RPO : Si votre RPO est de 30 minutes, cela signifie que vous acceptez une perte maximale de 30 minutes de données. Tout ce qui est antérieur à ces 30 minutes est disponible, mais ce qui a été produit juste avant l’incident est perdu.

La réplication : une copie en quasi temps réel

Maintenant qu’on a posé les bases, passons à la réplication.
L’idée est simple : au lieu de stocker une sauvegarde de vos données à un instant donné, on copie chaque changement en quasi temps réel vers un autre site ou serveur.

Pour faire simple, c'est un miroir de votre serveur avec plein d'avantages :

Comme les données sont répliquées en permanence, vous perdez très peu d’informations en cas d’incident. Contrairement à une sauvegarde qui pourrait dater de la veille ou de plusieurs heures, ici, on parle de secondes. ET l'avantage, c'est que si votre infrastructure principale tombe, vous pouvez passer sur votre environnement répliqué (quasiment) instantanément.

Mais bien sur, comme toutes les bonnes choses, il y a des limites : 

C'est coûteux ! Maintenir un site répliqué en permanence nécessite de la bande passante, des serveurs secondaires et une infrastructure solide. Ce n’est pas à la portée de toutes les entreprises.
Il ne faut oublier que ça réplique aussi les erreurs ! Si un fichier est supprimé ou chiffré , il sera répliqué sur le site distant. Contrairement à une sauvegarde classique qui permet de récupérer des versions précédentes, la réplication ne protège pas contre les erreurs humaines ou les cyberattaques.

La réplication est parfaite pour minimiser l’interruption d’activité, mais elle ne remplace pas une sauvegarde qui permet de récupérer des versions plus anciennes des fichiers.

Sauvegarde, snapshot, réplication… et ensuite ?

La vraie question n’est pas "Quelle est la meilleure solution ?", mais "Quelle est la meilleure combinaison pour mon entreprise ?"
Il n’y a pas de solution unique, mais une stratégie mixte qui répond aux besoins spécifiques de chaque structure.

Nous avons vu que sauvegarde, snapshot et réplication sont trois solutions complémentaires pour protéger vos données et assurer une reprise rapide.
Mais si votre infrastructure tombe, comment s’assurer que l’activité reprenne dans les meilleurs délais, voire ne s’arrête jamais ?

C’est là qu’interviennent deux concepts importants:
🔹 Le PRA (Plan de Reprise d’Activité), qui vise à relancer votre système après un sinistre.
🔹 Le PCA (Plan de Continuité d’Activité), qui garantit que votre entreprise continue de fonctionner même en cas de panne majeure.

👉 Sauvegarder, c'est bien. Pouvoir redémarrer instantanément, c'est mieux.