Comprendre l'importance des données structurées pour vos sauvegardes

Si vous commencez tout juste à vous intéresser à la sauvegarde de données, vous n'avez peut-être pas encore entendu parler du terme données structurées. Ce terme joue pourtant un rôle déterminant dans la définition de votre plan de sauvegarde.

Comprenons ensemble comment différencier données structurées et données non structurées et quelle est leur implication dans le choix de votre solution de sauvegarde.

Que signifie données structurées ?

Les données structurées sont organisées dans un fichier avec une structure spécifique, compréhensible par un logiciel. Ceci afin de pouvoir être facilement interprétées par celui-ci.

C'est par exemple votre fichier tableur .csv ou .xls (Excel). Les données contenues dans ce fichier sont organisées dans un format propre et accepté par Excel.

De même, si l'on prend le cas de votre base de données SQL, la donnée structurée correspond au fichier .sql qui vous est retourné lorsque vous exportez votre base de données.

Que signifie données non structurées ?

A l'inverse, la donnée non structurée n'est pas dans un format interprétable par un logiciel. Écrivez une liste de mots dans un fichier texte. Vous ne pourrez pas directement ouvrir ce fichier avec Excel, parce qu'il n'est pas structuré comme Excel l'attendrait.

En généralisant, nous comprenons qu'il y a un lien étroit entre les extensions de fichiers (.csv, .docx, .txt, .sql) et la donnée structurée. Si votre fichier n'a pas d'extension, aucune structure de fichier n'est induite. On parle alors de donnée non structurée.

Mais alors quel est le lien avec la sauvegarde de données ? Pourquoi devrais-je plutôt sauvegarder des données structurées ?

Risques de sauvegarder de la donnée non-structurée

Pour comprendre pourquoi la sauvegarde de données non structurées est un problème, je dois vous parler de restaurabilité des données.

Garantie de restaurabilité d'une sauvegarde

La garantie quant à la restaurabilité d'une donnée est généralement offerte par le logiciel qui la produit. C'est notamment le cas quand on enregistre un fichier Excel, ou qu'on demande à son client SQL de faire un export de base de données.

Le logiciel va structurer les données dans un format qui lui est propre et les exporter en gérant les problèmes de concurrence. Ceci afin de vous garantir que les données exportées sont bien dans un état qui lui convient, et non dans un état intermédiaire.

C'est-à-dire un état intermédiaire ?

Si l'on imagine un fichier SQL, l'état intermédiaire pourrait être d'avoir la dernière requête à moitié écrite dans le fichier SQL (SELECT * FROM)

Ce bout de requête ne correspond pas au standard SQL, qui définit qu'une requête doit commencer par un mot-clé (SELECT, UPDATE, DELETE, etc...) et terminer par un point-virgule.

Le fichier SQL n'a donc pas la bonne structure et une correction est nécessaire pour être lu par votre base de données - par exemple, la suppression de la requête incomplète. On dit alors que le fichier est corrompu

Qu'est-ce que cela implique ?

Cela implique que vous ne devriez jamais sauvegarder le répertoire /var/lib/mysql (répertoire de stockage de MySQL) en pensant sauvegarder votre base de données. Rien ne vous garantie qu'au moment de votre sauvegarde, aucune autre opération d'écriture n'était en cours.

Cette autre opération était peut-être en train d'écrire dans un fichier du répertoire /var/lib/mysql. Ainsi, lorsque vous copiez le répertoire vers votre support de sauvegarde, vous avez potentiellement une opération d'écriture "à moitié" terminée, menant à une structure de fichier incorrecte.

De cette façon, le fichier sauvegardé est incohérent et ne sera pas lisible par votre base de données lors de sa restauration. Vous vous retrouvez donc avec une sauvegarde que vous ne pourrez pas restaurer. Elle est inutile.

C'est la raison pourquoi vous devriez toujours privilégier la sauvegarde des données structurées.

Comment faire une sauvegarde de données structurée ?

Pour faire une sauvegarde de données structurée, vous devez utiliser les fonctions d'export ou de sauvegarde des applicatifs que vous cherchez à sauvegarder.

Dans le cadre de votre base de données, cela revient à utiliser des outils comme mysqldump (MySQL), pg_dump (PostgreSQL) et mongodump (MongoDB).

Ces outils vont contrôler l'export des données afin de vous garantir (pour la plupart) leur restaurabilité, en veillant à leur bon formatage et à leur cohérence.

Réaliser des instantanés de vos machines virtuelles n'est pas suffisant

En prolongeant le raisonnement précédent, vous comprendrez que réaliser des instantanés (snapshots) de vos machines virtuelles n'est pas suffisant. Dès lors que les applicatifs hébergés sur vos machines virtuelles sont plus complexe qu'un simple dépôt de fichier, vous devez avoir des sauvegardes dans un format structuré.

Par conséquent, je suis en guerre ⚔️ contre les personnes qui m'expliquent qu'ils ont des sauvegardes fiables parce qu'ils ont activé l'option de sauvegarde automatique sur leur serveur virtuel (ou dédié)

En dehors du fait qu'ils n'ont aucun contrôle sur ces sauvegardes - le fournisseurs cloud restant gestionnaires de celles-ci - leur données sont à risque car ils s'agit d'une sauvegarde de données non structurées.

Les instantanés sont donc une première protection, mais ne se substituent pas à la nécessité d'avoir des sauvegardes de données structurées. Car elle n'offrent aucune garantie quant à l'intégrité des données.

Pour métaphoriser, c'est comme avoir une armure sans savoir si elle est en mousse ou en acier. Vous n'aurez pas le temps de réaliser qu'elle était en mousse avant qu'il ne soit trop tard.

Conclusion

J'espère que cet article vous aura permis de comprendre l'importance de sauvegarder des données structurées et pourquoi faire des instantanés de vos machines virtuelles n'est qu'un premier rempart pour la sécurité de vos données.

Vous avez également compris pourquoi chez Datashelter, nous mettons un point d'honneur à effectuer des sauvegardes structurées dès que cela est possible.

Notre CLI snaper s'intègre à votre base de données par l'intermédiaire du client de base de données, vous offrant ainsi des sauvegardes fiables et des garanties fortes quant à leur restaurabilité.

Une sauvegarde de donnée qui ne peut pas être restaurée, n'en est pas une