Sauvegarder... un sujet (très) complexe

Dernièrement, j’ai beaucoup évoqué le sujet des sauvegardes sur mon blog, notamment à cause de l’incendie OVH et une indisponibilité de mon serveur, billets que vous pouvez retrouver ici :

Aujourd’hui, je vous propose de parler des sauvegardes, et de comprendre pourquoi c’est un domaine qui demande de l’expertise et du recul pour choisir le format le plus adapté.

Snapshot, dump ou archivage ?

La première question à se poser est de savoir ce que vous voulez sauvegarder ?

En gros, quel est le but de votre sauvegarde :

Sauvegarder un état à un instant T : c’est un snapshot, un instantané que l’on peut restaurer
Sauvegarder de manière pérenne et reconstructible : on fera dans ce cas un dump, une copie du contenu dans un format que l’on peut réinsérer (voir plus bas)
Archiver : pour des besoins légaux ou de sécurité, par exemple, on peut sauvegarder son patrimoine numérique en cas de problème majeur (y compris géopolitique)

En fonction de ce que l’on veut faire, les solutions ne sont pas forcément les mêmes. Creusons un peu ces 3 sujets.

Le snapshot

Le snapshot est le format de sauvegarde le plus couramment utilisé, pourtant ce n’est pas forcément le plus fiable en fonction de ce que l’on souhaite faire. Utilisée sur des volumes virtualisés (volumes de baies SAN, un volume Kubernetes, etc.), l’idée est de se dire qu’on va faire une "photo" du disque au global.

Le concept est plutôt bon, toutefois, souvent les snapshots ne sont pas exploités avec les pratiques qui vont avec.

En effet, pour bien faire un snapshot, il est nécessaire de limiter autant que possible les "mouvements" (écriture/modification) de bloc sur le disque. Un snapshot n’est pas instantané (sic), et on peut se retrouver avec des "demi écritures" dans le cas où l’on ne prend pas les bonnes précautions.

Par exemple, sous Linux, on fera souvent cette séquence pour limiter autant que possible les anomalies dans les snapshot :

sync     #  Ecrit le contenu éventuel du buffer sur le disque
freeze   #  Indique au système de limiter les écritures sur le disque
SNAPSHOT #  On fait notre snapshot
unfreeze #  On libère le "lock" sur l'écriture

Il faut garder en tête qu’un snapshot peut être fait à chaud, avec les risques évoqués plus tôt. Un snapshot peut prendre plusieurs minutes (en fonction de la taille du disque, les performances de la baie / de l’hyperviseur, etc.) et ces opérations peuvent donc avoir des impacts.

Les snapshots incrémentaux

Les snapshots sont généralement plus volumineux que des sauvegardes brutes vu qu’ils sauvegardent le disque complet. Il est aussi possible de faire des snapshots incrémentaux : on fait un snapshot "full" du disque et on sauvegarde ensuite uniquement les modifications depuis ce snapshot, ce qui permet de réduire la taille des snapshots suivants.

Toutefois, il faut garder en tête que :

S’il y a beaucoup d’activité, les snapshots incrémentaux peuvent être plus lourds à terme
Reconstruire depuis un snapshot incrémental prend plus de temps : la reconstruction nécessite en effet de repartir du snapshot de base et de "rejouer" les différences

On peut aussi mixer les deux types de snapshots, par exemple en faisant un snapshot "full" une fois par semaine, et de l’incrémental depuis ce snapshot tous les jours, ce qui permet d’avoir un bon compromis entre les deux modes.

Le dump

Au contraire du snapshot qui sauvegarde le contenant, le dump consiste à sauvegarder le contenu. C’est par exemple ce que j’utilise sur ce serveur, tous les jours, je fais une archive tar.gz avec tout mon contenu.

Le dump à l’avantage d’être souvent plus portable d’un outil à un autre et fonctionne souvent avec des mécanismes intégrés aux applications.

Par exemple, sur le moteur MySql, il existe mysqldump prévu pour ce besoin. Il fera nativement les opérations de lock/unlock pour avoir des données consistantes.

Un dump créé avec MySql sera donc exportable sur un autre moteur MySql, quel que soit son hébergeur (tant que la version est compatible), mais il ne portera pas MySql lui-même.

Cela signifie que si je veux restaurer mes données, j’ai tout de même besoin d’installer le moteur auparavant. L’avantage est que dans beaucoup de cas, les dumps sont des fichiers supportant un fort taux de compression (dû au format texte en grosse partie), cela permet d’avoir des données sauvegardées qui occupent peu d’espace.

Archivage

Même s’il s’agit d’un mix des deux formats précédents, j’ai choisi de mettre l’archivage dans une case à part pour une raison simple : plus que sauvegarder, il faut aussi s’assurer que l’on sera toujours en mesure de restaurer même après une très longue période.

Dans cette catégorie, on placera souvent les éléments critiques à la survie de l’entreprise, que l’on va sécuriser au maximum, que ce soit les données, mais aussi le code source, la documentation, etc.

L’idée est de se dire qu’on a un coffre-fort quelque part avec tout le nécessaire pour repartir de n’importe où en toute autonomie.

Sauvegarder : une simple histoire de vocabulaire?

Se dire qu’une sauvegarde se limite à un dump ou un snapshot est très simpliste. Il est important de se poser les bonnes questions :

Quelles sont les données que veux sauvegarder :
- Quel volume de données
- Quel format de données
Comment je veux les sauvegarder :
- Archive
- Snapshot
- Mélange des deux
Comment je veux les restaurer :
- Avec le moteur de l'application
- En recréant le disque
Combien de durée je veux sauvegarder les données
A quelle fréquence je veux sauvegarder
En combien de temps je veux pouvoir revenir en ligne en cas d'incident

Ça en fait des questions!

Toutefois ce sont normalement des informations que l'on a déjà.

Concernant les 3 premiers points, je ne vais pas revenir dessus, la description est juste au-dessus.

Pour les trois derniers points, ce sont normalement des informations qui sont censées être définies à l'initialisation du projet (et documenté), il s'agit des :

RTO (Recovery Time Objective) : En combien de temps je veux pouvoir revenir en ligne en cas d'incident majeur
RPO (Recovery Point Objective) : Quelle "durée" de données je considère que je peux perdre en cas d'incident

Pour la durée de rétention, il y a souvent une marge en cas d'une erreur que l'on ne voit que quelques jours plus tard, ou pour des besoins légaux (par exemple certains logs applicatifs doivent parfois être conservés plusieurs années).

Vous l'aurez compris, en fonction de ces informations, les solutions sont complètement différentes!

Par exemple, si je veux une restauration en moins de 6h, faire de la sauvegarde/restauration sur bande magnétique n'est pas forcément adapté : les bandes magnétiques ont une excellente durabilité (plusieurs dizaines d'années) et stockent de gros volumes, mais sont aussi très lentes en accès.

De même, sauvegarder les données dans le même datacenter (#OVH) peut être très bien pour restaurer rapidement, mais cela ne couvrira pas tous les besoins possibles, par exemple, je ne sais pas, si le datacenter brûle...

Vous l'aurez compris, en plus du format (dump/snapshot), il y a aussi la question du média de sauvegarde, on pourra citer par exemple :

Une sauvegarde externe sur un autre datacenter
Une sauvegarde chez un autre provider cloud (par exemple, si je suis chez OVH, je sauvegarde chez Scaleway, ce que je fais moi-même)
Une sauvegarde sur bande magnétique, stockée dans un environnement sécurisé (certaines sociétés comme Iron Mountain sont spécialisées dans ce domaine)

On peut aussi bien évidemment faire plusieurs niveaux de sauvegarde, par exemple :

Une sauvegarde locale pour les données de la journée
Une sauvegarde dans un autre datacenter pendant une semaine
Une sauvegarde externalisée sur bande pendant un an

Cela permet d'accéder rapidement aux données "chaudes" et d'avoir toujours accès, avec un plus grand délai aux informations plus anciennes.

De même, si je veux sauvegarder toutes les heures, je ne vais pas forcément utiliser les mêmes mécanismes que si je veux sauvegarder une fois par semaine, certains processus de sauvegardes étant plus ou moins rapides.

Temps réel et ransomware

Il y a deux cas que je n'ai pas évoqués dans le paragraphe précédent.

Le premier est le cas du temps réel : mon business est tellement critique que je ne peux pas me permettre de perdre la moindre seconde en cas d'incident majeur. C'est par exemple le cas dans l'univers bancaire. Dans ce cas, on mettra souvent en place de la réplication temps réel entre plusieurs sites. Sur une base de données, on peut par exemple imaginer des read replicas sur d'autre datacenter que l'on peut promote en lecture écriture en cas d'incident et basculer en ayant le moins de perte de données.

Attention, cela ne signifie pas qu'il ne faut pas faire de sauvegardes régulières en plus!

Le second cas que l'on voit de plus en plus souvent est le cas des ransomwares. En effet, si je sauvegarde sur le même réseau, cela signifie que j'expose donc mes sauvegardes à une compromission. D'autant plus que certains vers visent spécifiquement les sauvegardes!

Un cartouche de sauvegarde HP LTO-7 : 15 TB de donnée dans le creux de la main!

La solution n'est pas miraculeuse dans ce cas, il est nécessaire d'isoler ses sauvegardes sur des périphériques externes comme des bandes magnétiques, qui de fait ne seront connectées à rien et permettront de garantir la durabilité et l'inaltérabilité des données.

Sauvegarder, c'est bien, tester, c'est mieux!

Si vous faites régulièrement des sauvegardes, c'est très bien, maintenant, si vous ne testez pas vos sauvegardes régulièrement, c'est inutile!

Pour avoir déjà subi le coup de la sauvegarde vide... c'est un moment compliqué à vivre.

Donc, sauvegarder ses données est bien, mais il est tout aussi important d'avoir un inventaire à jour des sauvegardes et de les tester régulièrement.

Cela permet :

De vérifier que vos sauvegardes sont fonctionnelles
D'éprouver vos documentations
De rassurer les équipes sur la capacité à revenir rapidement en ligne en cas d'incident.

La sauvegarde est un élément tout aussi important de votre application du choix de la technologie utilisée pour votre framework front.

Pour résumer : tout n'est pas si simple

Pour terminer ce billet, je le résumerai simplement en disant qu'il faut choisir la méthode adaptée à votre besoin.

Pour ma part, je tolère une perte de 24h de données et je n'ai quasiment que des fichiers "plats", une simple archive exportée quotidiennement sur un object storage est suffisante.

Par contre, si j'avais une application plus critique, je sauvegarderais sans doute de manière plus adaptée.

La question de la sauvegarde des données est une question à se poser dès la conception de votre application pour éviter le moindre problème et que vos équipes puissent mettre en place les solutions adaptées.

Avoir une bonne gestion de ses sauvegardes peut aussi faire la différence entre un incident et une faillite pour certaines entreprises!

Sauvegarder... un sujet (très) complexe