Stockage : comprendre la différence entre snapshots et sauvegardes

Les principes fondamentaux des snapshots

Un snapshot est un enregistrement de données et de métadonnées qui indiquent ensemble l’état des blocs et des fichiers d’une unité de stockage. Bien souvent, les snapshots sont une fonctionnalité interne des baies de stockage NAS ou SAN et, à ce titre, ils sont créés et conservés sur ces équipements.

Ils permettent à l’utilisateur de récupérer des versions précédentes d’un volume, d’un disque, d’un système de fichier, d’une base de données, etc. Il est ainsi possible de rétablir l’état antérieur d’une unité de stockage à partir de n’importe quel snapshot précédemment effectué.

Un snapshot est moins une copie ponctuelle qu’une table des matières indiquant quels blocs ou quels fichiers existaient à quel endroit à quel moment précis.

Un snapshot est moins une copie ponctuelle qu’une table des matières indiquant quels blocs ou quels fichiers existaient à quel endroit à quel moment précis. Lors d’une restauration vers un état antérieur, l’état du volume ou de l’unité de stockage concerné change pour refléter celui du snapshot ; les blocs qui ont évolué entretemps sont remis à leur position initiale, voire effacés, tandis que ceux qui n’ont pas changé sont laissés tels quels – ils ne sont pas réécrits. La version restaurée peut contenir à la fois des blocs qui étaient préservés dans le snapshot de la date à laquelle on souhaite revenir, mais aussi des données issues de snapshots plus récents, car elles n’avaient été effacées que récemment.

Les snapshots ne sont pas considérés comme des sauvegardes, car il ne s’agit pas de copies. En fait, les seules données qu’ils contiennent sont celles qui ont été effacées des volumes de production depuis le précédent snapshot. Individuellement, les snapshots n’occupent que peu d’espace, mais leur volume total peut croître, en particulier quand il y a beaucoup de blocs ou de fichiers supprimés en production. Pour éviter que cette taille totale atteigne de grandes proportions, les fournisseurs limitent généralement la quantité possible de snapshots à conserver.

Avantages et inconvénients des snapshots

Le principal avantage des snapshots, par rapport aux sauvegardes, est la rapidité avec laquelle ils permettent de rétablir l’état antérieur d’une unité de stockage.

Ils permettent en outre une protection beaucoup plus fréquente que les sauvegardes. Par exemple, il est possible de définir la prise de snapshots toutes les heures, alors que les sauvegardes sont généralement exécutées une fois par jour et en dehors des heures de production, car leur activité ralentit les ressources des utilisateurs.

La bonne pratique est de combiner des snapshots avec des sauvegardes.

Revers de la médaille, les snapshots sont stockés localement sur la baie de stockage. Non seulement cela les rend vulnérables aux pannes éventuelles du système, mais ils consomment aussi de la capacité de production, ce qui est d’autant plus ennuyeux s’il s’agit d’une coûteuse baie de stockage primaire. Les sauvegardes, elles, sont stockées sur une unité de stockage dédiée et n’ont donc pas ces inconvénients.

Par conséquent, la bonne pratique est de combiner des snapshots avec des sauvegardes. On utilise les snapshots pour avoir de nombreux points de restauration, définis à la minute ou à l’heure. On utilise les sauvegardes pour avoir des points de restauration quotidiens. Les périodes de rétention des snapshots reflètent généralement cette caractéristique : il est souvent question de les supprimer de la baie de production au bout de 48 heures, un intervalle qui laisse le temps d’effectuer une ou deux sauvegardes.

Les types de snapshots

Il existe principalement deux méthodes de création de snapshots : « copy-on-write » (préserver une copie en cas d’écriture) et « redirect-on-write » (attribuer automatiquement cette écriture au snapshot en cours).

Il existe principalement deux méthodes de création de snapshots : « copy-on-write » et « redirect-on-write ».

Copy-on-write. Avec la méthode copy-on-write, lorsqu’une baie de stockage enregistre un nouveau bloc, celui-ci est enregistré en double : sur le volume de production, bien entendu, mais aussi dans la zone réservée au snapshot en cours. Ainsi, quoiqu’il arrive à l’avenir à ce bloc, il en existe automatiquement une copie restaurable. Lorsque le snapshot est terminé pour la période qu’il concerne, il contient donc les derniers blocs écrits et des liens vers ceux qui n’ont pas changé depuis le snapshot précédent. En clair, les snapshots de type copy-on-write n’occupent peu d’espace qu’à la condition que peu de blocs aient été écrits depuis le snapshot précédent.

L’inconvénient de cette méthode, surtout, est une dégradation possible des performances en production, car chaque demande d’écriture sur la baie déclenche une seconde écriture vers la zone réservée au snapshot en cours.

Redirect-on-write. Avec la méthode redirect-on-write, tout nouveau bloc créé est automatiquement affecté au snapshot en cours. En fait, les blocs en production sont tous des blocs qui appartiennent à tel ou tel snapshot. Et quand un ancien snapshot est effacé, les blocs qui lui étaient affectés sont réaffectés au snapshot suivant pour continuer à être accessibles en production. Ce fonctionnement a l’inconvénient de réduire les performances des accès en production. En revanche, il limite mieux la consommation de capacité sur l’unité de stockage.

Ces méthodes de création de snapshots se conjuguent avec d’autres :

La protection continue des données (CDP, Continuous Data Protection) est un mode qui crée un nouveau snapshots non pas à intervalle régulier, mais à chaque fois qu’une modification est apportée à l’unité de stockage : la création, la modification ou la suppression d’un fichier. La CDP permet de récupérer des données à n’importe quel instant dans le temps. En revanche, son fonctionnement est celui qui impacte le plus les performances. Sans CDP, les snapshots sont créés toutes les heures environ, par comparaison avec les snapshots précédents, entraînant une dégradation des performances seulement au moment de leur création.

La mise en miroir, le clonage et la réplication renvoient à l’utilisation des snapshots, mais n’ont techniquement rien à voir. Pour l’essentiel, un clone est, comme son nom l’indique, une copie à l’identique d’une unité de stockage. Il ne s’agit pas d’un original avec, à côté, les snapshots des données modifiées, mais d’une copie telle quelle de l’unité de stockage actuellement en production. Le but est d’avoir une copie de secours prête à l’emploi.

On parle plus précisément de clone quand cette copie est générée sur une baie de secours à partir d’un snapshot. On parle d’une mise en miroir quand elle est générée de manière synchrone, avec un système qui écrit les données en même temps sur la baie de production et sur la baie de secours.
Et l’on parle d’une réplique quand la copie est générée de manière asynchrone, via une réplication de ce qui vient d’être écrit sur la baie de production vers celle de secours. Cette forme très efficace de protection des données est utilisée dans les secteurs d’activité où les transactions constituent un élément stratégique, car, en cas d’incident, elle permet de basculer sur la copie de secours sans aucune interruption de service.

Les clones ne sauraient remplacer les sauvegardes. En effet, les copies immédiates peuvent embarquer des fichiers corrompus ou infectés en production.

Cependant, les clones ne sauraient remplacer les sauvegardes. En effet, les copies immédiates peuvent embarquer des fichiers corrompus ou infectés en production ; dans ce cas, il est impératif de pouvoir revenir à une version antérieure, qui précède le problème. Et cette version peut dater de plusieurs jours.

Il faut par ailleurs noter que les clones ne bénéficient d’aucune fonction de réduction de leur taille pour optimiser l’espace de stockage occupé, au contraire des systèmes de sauvegarde. Ils coûtent donc plus cher. De fait, une bonne pratique est de limiter les clones, les réplications ou les mises en miroir, à certains jeux de données les plus critiques pour continuer l’activité en cas d’incident.