Il est essentiel d’effectuer de façon rigoureuse le back-up des bases de données compte-tenu de l’importance des données qu’elles contiennent. Et dans ce cadre, on ne peut pas se dispenser de comprendre comment elles fonctionnent. Les bases de données structurées constituent une partie essentielle de tout datacenter. En pourcentage, le volume de données qu’elles stockent n’est pas nécessairement élevé par rapport au total de téraoctets hébergés par un datacenter. En revanche, ces databases contiennent souvent un fort pourcentage de données critiques pour l’activité d’une entreprise. Il est donc indispensable de comprendre leur structure particulière et leur fonctionnement pour bien les sauvegarder.

Le back-up des données structurées ne peut pas se faire de la même façon que pour les données non structurées en raison de trois difficultés très importantes. Premièrement, les databases sont typiquement stockées dans des fichiers qui changent constamment au fur et à mesure des mises à jour qui s’y font. On ne peut donc pas les sauvegarder comme on le ferait pour un autre type de fichier. Deuxièmement, la plupart d’entre elles disposent d’une sorte de journal qui peut être rejoué, soit pour restaurer les transactions à partir d’un moment précis, soit pour re-éxécuter une transaction partiellement effectuée après un crash. Troisièmement, une restauration typique commence par celle des fichiers de données du backup le plus récent, suivie par celle du journal afin de restaurer la base de données dans l’état le plus récent possible. Le RPO, Recovery point objective (qui définit le point de récupération acceptable après sinistre), que propose le mode de restauration en une seule étape de la plupart des systèmes de backup - parfois plus de 24 heures - ne convient pas pour les bases de données critiques. Pour bien sauvegarder une database, il faut comprendre comme elle prend en charge ces challenges.

13 modèles différents de base de données 

Il existe au moins 13 modèles différents de bases de données et pour bien sauvegarder les siennes, il faut déjà savoir de quels types de bases il s’agit : relationnelle (la plus courante), clé-valeur, « time series » optimisée pour stocker les données horodatées, document, graphe, moteur de recherche, wide column, orientée objet, RDF (resource description framework), multivaleur, XML natif ou, encore, bases de données navigationnelle ou d’événements. Voici les modèles les plus fréquents.

Relationnelle. Le modèle du SGBDR (en anglais RDBMS) est celui auquel on pense la plupart du temps lorsque l’on parle de base de données. Il présente un ensemble de tables avec un schéma défini (table layout), des enregistrements (rows) et des attributs (valeurs). Oracle, SQL Server, MySQL et PostgreSQL en sont les exemples les plus connus, souvent appelées databases SQL en référence au langage qu’elles utilisent.

Clé-valeur. C’est un modèle très simple de base de données NoSQL reposant sur des clés (identifiants) et des valeurs. Il permet de consulter la valeur lorsque l’on connaît la clé. Redis et DynamoDB comptent parmi les plus connues.

Time series. C’est une base de données NoSQL spécifiquement conçue pour gérer des données temporelles, chaque entrée comportant un horodatage. Prometheus est l’exemple typique, notamment utilisé par Kubernetes.

Document. C’est une base NoSQL conçue pour stocker des documents. Elle n’utilise pas de schéma, les enregistrements n’ayant pas besoin de se conformer à un standard et pouvant stocker des types de données très différents. Le format JSON est souvent mis à profit dans ces databases. MongoDB figure parmi les plus populaires supportant uniquement ce modèle document. 

Wide column. Un autre type de database NoSQL sans schéma qui peut stocker un grand nombre de colonnes de données sans schéma prédéfini est le modèle wide column. Les noms des colonnes et les clés peuvent être définis tout au long de la base de données. Cassandra est la plus connue.

De l'importance de la terminologie

La terminologie est également importante. Si les bases de données n’utilisent pas toutes les mêmes termes, elles recourent à d’autres termes équivalents signifiant la même chose. Les bases NoSQL se servent d’un vocabulaire très différent ou peuvent manquer du terme équivalent pour désigner certains éléments. 

Datafile : Le fichier de données, c’est là où la base stocke ses données. Ce peut être un équipement (par exemple /dev/hda1 dans Linux) ou un fichier constitué (par exemple /sap/datafiles/dbs06.dbf ou c:\MySQL\datafile.dbf). A ce stade, les datafiles de la plupart des databases sont des fichiers ordinaires ou constitués et il y en a généralement plus d’un par base de données.

Table : Dans une base SQL, relationnelle, une table, c’est un ensemble de valeurs liées qui se comportent un peu comme une feuille de calcul virtuelle. On peut le retrouver dans les databases NoSQL… ou pas.

Tablespace : c’est un espace où l’on met les tables et qui rassemble un ou plusieurs fichiers de données. Si une base de données n’a pas de table, elle n’a probablement pas non plus d’espace de table.

Partition : les databases modernes peuvent se partager et se propager ou partitionner une table entre plusieurs ressources, incluant différents espaces de table.

Sharding : il porte le partitionnement à un autre niveau, apportant une dimension clé pour les grandes bases de données scale-out (extension des performances par ajout de serveurs). Le sharding peut même placer des parties - shards - d’une table sur différents noeuds.

Master database ou base de données maître : elle conserve la trace du statut de toutes les bases de données et fichiers de données. Si plusieurs databases sont autorisées, elle conservera leur trace de la même façon.

Transaction : c’est une activité au sein de la base qui change un ou plusieurs attributs dans une ou plusieurs tables. Les transactions simples modifient un attribut, les complexes en modifient plusieurs dans une seule action atomique (c’est-à-dire indivisible). Les bases NoSQL recourent généralement aux transactions simples et la plupart de leurs utilisateurs ne pensent même pas à ces transactions en tant que telles.

Transaction log : il enregistre chaque transaction et les changements qui sont faits. Cette information est utilisée en cas de plantage des systèmes ou après une restauration pour ré-exécuter ou annuler ces transactions.

Modèle de cohérence forte ou décalée

Il existe dans les bases de données deux façons très différentes pour s’assurer que les vues des données insérées ou mises à jour dans la database sont les mêmes pour tous les utilisateurs qui consultent la base. C’est ce que l’on appelle les modèles de cohérence et cela affecte la sauvegarde et la restauration. Le premier est la cohérence immédiate ou cohérence forte. Il assure que tous les utilisateurs verront les mêmes données au même moment, quels que soient la façon ou l’endroit d’où ils consultent les données. La plupart des bases de données relationnelles traditionnelles suivent ce modèle.

Le second modèle est celui de la cohérence faible qui s’assure qu’un attribut donné sera à un moment donné cohérent pour tous les utilisateurs, mais cela peut prendre un certain temps. On peut citer comme exemple typique celui des DNS (systèmes de nom de domaine) qui doivent attendre que le délai de mise en cache (time-to-live) des enregistrements DNS ait expiré avant de mettre à jour les informations sur les noms de domaine. Cela peut prendre jusqu’à 72 heures.

Qu’est-ce que l’on sauvegarde, comment et pourquoi ? 

Les personnes responsables de la sauvegarde de bases de données doivent comprendre comment celles-ci sont construites et comment elles fonctionnent. Il faut comprendre où ces databases stockent leurs données, par exemple dans des fichiers de données, si elles utilisent des transactions complexes ou simples et où elles conservent les logs de ces transactions. Il faut comprendre comment obtenir un backup cohérent des données stockées et des logs de transaction. Il faut aussi savoir de quelle façon la base est distribuée. Est-elle partitionnée et comment : au sein d’un seul serveur hôte ou bien répartie et disséminée entre plusieurs dizaines ou centaines de serveurs hôtes ? Dans ce dernier cas, on est probablement en présence d’une base de données à faible cohérence.

Réaliser un snapshot (sauvegarde de l’état du système à un instant t) cohérent à travers plusieurs centaines de noeuds est une tâche particulièrement difficile et le restaurer le sera tout autant. Certains pensent peut-être qu’une base de donnée à faible cohérence utilisant la réplication à travers de nombreux noeuds n’a pas besoin d’être sauvegardée. Qu’ils se détrompent. Il faut absolument le faire. Si cela peut protéger des pannes de serveurs, cela ne protège absolument pas contre les erreurs humaines. Si l’on perd une table, peu importe la façon dont elle est répliquée. Il faudra la restaurer.