Niveau : débutant

Vous aurez remarqué en tant qu'administrateur qu'il est impossible de sauvegarder via la même méthode des documents, des bases de données ou des banques Exchange.
Il y a des raisons liées au système, très concrètes et logiques, qui font qu'il est impossible d'avoir recours aux méthodes traditionnelles pour les fichiers multi-utilisateur.
C'est principalement les notions de "granularité des données" et de "concurrence" qui interviennent.
Et c'est aussi ces notions qui font qu'il est impossible de sauvegarder les machines virtuelles, ou VMs, sans utiliser des outils adaptés.
C'est une erreur de débutant que je vois assez souvent sur les forums, à savoir des administrateurs qui veulent passer par rsync ou d'autres utilitaires de copie de fichier, pour sauvegarder leur infrastructure virtuelle.
J'essaierai donc, dans cet article, de vous expliquer pourquoi ce n'est pas envisageable, et quels sont les éléments minimaux à prendre en compte lorsque vous avez à choisir un système de sauvegarde cohérent.

Les fichiers

Si vous avez fait un peu de programmation, vous savez que lorsque vous ouvrez un fichier, il y a trois modes possibles : la lecture, l'écriture, et les deux combinés.
Souvent, le développeur débutant néglige cette information, et pour plus de souplesse, a tendance à ouvrir tous les fichiers en lecture/écriture.
Pourtant, c'est un choix capital, qui influencera le bon fonctionnement de votre programme, que ça soit au niveau fonctionnel ou au niveau système.

Lorsqu'on ouvre un fichier en lecture, il est lu au moment de l'ouverture, à un instant "t".
S'il est modifié par la suite, le programme ne verra pas la nouvelle version du fichier.
Si vous décidez de l'ouvrir en écriture, un verrou est posé sur ce fichier ("lock" en anglais), interdisant toute autre ouverture en écriture concurrente.
Au mieux, un message d'erreur vous avertira que le fichier n'a pas pu être ouvert en écriture et qu'il est en "lecture seule".
Cela empêche toute incohérence à l'enregistrement.

Imaginons deux personnes qui sont parties du même fichier et qui le modifieraient d'une façon différente : puisque le fichier ne peut être fusionné sans risques d'incohérences, une seule version du fichier pourra donc être enregistrée, celle du premier programme / utilisateur qui a ouvert le fichier.
C'est typiquement le problème qui se pose lorsque plusieurs comptables / contrôleurs de gestion travaillent sur le même fichier tableur, pour boucler un bilan.
Le premier comptable qui ouvre en premier le fichier peut le modifier, mais les autres non.
C'est source d'énervement et d'incompréhensions, mais on n'y peut rien, un fichier tableur n'est pas adapté pour des modifications simultanées, c'est un fichier.

Lorsqu'on met en place un système de sauvegarde sur un serveur de fichiers simples, nous partons du principe que la granularité des données à sauvegarder, c'est le fichier.
Les opérations de modification sur les fichiers ne sont pas instantanées, pas plus que la sauvegarde.
Afin d'éviter toute incohérence, nous traitons facilement les fichiers non ouverts ou en lecture, et nous pouvons être certains que leur sauvegarde sera cohérente.
Toutefois, nous ne pouvons pas dire la même chose des fichiers verrouillés en modification : soit l'utilisateur est parti en W-E tout en laissant son application ouverte, soit il travaille actuellement en VPN, soit il vient juste d'appuyer sur le bouton "enregistrer".
Il n'est pas possible d'avoir plus détails sur son activité réelle, et donc il a une incertitude quant à la cohérence du fichier contenu dans la sauvegarde.
Les logiciels vous rapportent alors des erreurs ou des alertes, en précisant les fichiers qui étaient ouverts en écriture lors de la sauvegarde.

Notons d'ailleurs que les fichiers ont tous des dates de sauvegarde différente, si une sauvegarde est déjà passée sur un fichier, elle ne verra pas les modifications ultérieures.
Bien que la sauvegarde ne soit pas un "instantané" pris à un instant "t", on considère que la plupart des fichiers sont ouverts pour de la lecture, et qu'il y a en fin de compte suffisamment peu d'écritures pour que les données soient considérées comme cohérentes.

Les données multi-utilisateurs

Ayant pris conscience des limitations inhérentes aux fichiers, et confrontés aux nouvelles méthodes de travail collaboratif, en réseau, les développeurs ont contourné d'une façon élégante le problème :
un logiciel "serveur" ouvre et verrouille les fichiers dont il a besoin en modification  (granularité : fichier), et gère les écritures d'une façon plus fine en interne, avec une granularité "transactionnelle" adaptée à son fonctionnement.
Par exemple, dans une base de données InnoDB MySQL, la granularité est l'enregistrement ("row" ou "record" en anglais) : un utilisateur peut très bien modifier le stock d'un produit disponible, tandis qu'un autre peut modifier le prix d'un autre produit.
Ce sont deux transactions différentes, bien qu'elles soient contenues dans la même banque de données.
Les valeurs qui en découlent, comme les valeurs du stock, seront calculées, à un instant t, lorsqu'un utilisateur en fera la demande.

C'est exactement le même principe qui s'applique sur un serveur de mails. La demande de suppression d'un mail est indépendante de la demande de modification d'un autre.
La granularité est donc ici l'objet mail.

Il est alors évident qu'il n'est pas possible de sauvegarder les données de la même façon que pour un fichier : le fichier étant ouvert en permanence en écriture, et la seule façon d'avoir une sauvegarde cohérente serait d'éteindre le service, et donc de refuser l'accès à tous les utilisateurs (j'ai vu faire ça sur de vieux serveurs de bases de données Sun ... ;-)

L'informatique a évolué depuis quelques décennies, et il est juste impensable de mettre des services utilisateur hors-ligne pour plusieurs heures par semaine, afin de pouvoir les sauvegarder : services mail, outils de productivité, sites internet, réseaux sociaux, jeux en ligne, etc.

Pour aider l'administrateur dans les tâches de sauvegarde, un certain nombre d'utilitaires spécifiques à chaque service ont vu le jour.
C'est par exemple le cas de mysqldump, que vous avez certainement déjà utilisé : comme on ne peut obtenir une sauvegarde des fichiers stockant les bases de données, sauf à les mettre hors ligne, l'utilitaire mysqldump duplique en live les données qu'elles contiennent, dans la granularité voulue, à savoir la transaction.
Puisqu'un enregistrement pourrait être modifié à tout moment de la sauvegarde, y compris après qu'elle soit passée sur l'enregistrement, l'utilitaire transforme toutes les données en suite d'instructions élémentaires SQL.
La création des tables, l'insertion de chacun des enregistrements, et tout autre modification sur le contenu (modification, création, suppression) qui pourrait avoir lieu entre le début et la fin de la sauvegarde.

En outre, il élimine les risques d'incohérence liés aux transactions ACID, qui sont une suite d'actions qui doivent obligatoirement être exécutées comme une seule, indivisible. On peut aussi parler "d'instructions atomiques".
Imaginons qu'un visiteur sur le site marchand commande un produit, et que le serveur crashe juste au moment de la sauvegarde de sa transaction.
Lors de la restauration des données, sa transaction aura été entièrement annulée (elle n'a pu être validée dans son intégralité), mais vous ne risquez pas de lui envoyer le produit alors qu'il ne l'a pas payé, pas plus qu'il ne risque de ne pas recevoir un produit alors qu'il a été débité.
Et si les choses sont faites proprement, la base de données n'ayant pas pu compléter la transaction, il en sera tenu au courant par le site web, et pourra recommander sa commande.

Notons d'ailleurs que le système de réplication sur plusieurs serveurs MySQL fonctionne exactement de la même manière : ce sont les requêtes SQL qui sont transmises entres les serveurs, et non pas des fichiers, qui n'ont pas une granularité suffisante.
Si l'on a plusieurs serveurs MySQL qui sont mis en réplication, il est alors possible d'en mettre un hors ligne, afin de le sauvegarder selon la méthode traditionnelle de copie de fichiers, puisque le contenu des bases ne risque pas d'être modifié.
Le serveur utilisé pour la sauvegarde remettra à jour son contenu lorsqu'il sera remis dans le cluster, en "rattrapant" les transactions qu'il aura manqué pendant la sauvegarde.

Les données VM

Nous avons vu que méthodes de sauvegarde devaient être adaptées à la granularité, pour être cohérentes.
Les images disque des machines virtuelles ne doivent pas contenir de données "corrompues", alors qu'elles aussi doivent souvent tourner 24h/24.
Hors, le problème, c'est que la sauvegarde d'une image VM prend quelques minutes à plusieurs heures, et la granularité, ici, est le disque tout entier !!!
Si l'on commence à sauvegarder le début du disque, rien ne dit que le système ne va pas demander sa modification pendant que la sauvegarde sera passée à la suite.

C'est là que les développeurs spécialisés dans la virtualisation ont du inventer un nouveau système transactionnel dont la granularité est le disque tout entier, ce que l'on appelle les instantanés (ou snapshots en anglais).
Imaginons un disque virtuel de quelques gigaoctets.
Lorsque l'instruction de snapshot est lancée, le système de virtualisation arrête toute écriture sur le disque virtuel, afin de préserver son contenu tel quel, à l'instant "t".
Les opérations d'écriture ou de modification ultérieures sont basculées, dans un nouveau fichier, qui gardera les modifications du disque (ou delta) entre le moment du début du snapshot, et sa fin.
Le contenu sauvegardé est alors le disque "de base", mais pas le snapshot, puisque la sauvegarde concerne l'état du disque à l'instant précis "t", moment de création du snapshot.
Il est alors facile de sauvegarder le contenu de base, puisqu'il ne change plus et que l'on a tout le temps de le transférer.
Le fichier supplémentaire augmente à fur à mesure de la sauvegarde.
Une fois que la sauvegarde est terminée, les données sont consolidées, en fusionnant le disque de base avec le snapshot, qui représente son "delta".
Et alors le disque de base est rebasculé en écriture, et le snapshot effacé, puisque nous n'en avons plus besoin.

C'est un système relativement complexe et lourd, mais qui permet de s'assurer de la cohérence du disque sauvegardé, de façon tout à fait transparente pour la machine virtuelle.
Celle-ci peut continuer de fonctionner, avec un impact minimal sur les performances, et le basculement au début de la sauvegarde et à sa fin se fait en "live" !

Conclusion

Nous avons vu que pour chaque type de données, il y a une façon "intelligente" de les sauvegarder, et que la copie de fichiers ne suffit plus lorsque l'on désire maintenir les services ou les systèmes online.
Qu'il faut des outils adaptés, s'intégrant avec l'infrastructure de production, en tenant compte de la granularité de chaque donnée.
Pour sauvegarder des machines virtuelles, les principes restent les mêmes, bien que certains produits vous promettent des raffinements supplémentaires.
Par exemple, pouvoir gérer la sauvegarde en haute disponibilité, autrement dit celle des machines virtuelles qui ne sont plus attachées à des machines physiques en particulier, mais qui se "baladent" sur le réseau au gré de la disponibilité des ressources.
Selon le type d'hyperviseur dont vous disposez (ESXi, KVM, Xen, HyperV), il existe des logiciels adaptés, certains gratuits, et d'autres payants.
La question est bien trop vaste pour que je puisse les détailler dans cet article.
Toutefois, vous avez maintenant suffisamment de connaissances pour commencer à mettre au point une stratégie de sauvegarde.

L'utilisation des snapshots Vmware ESXi ainsi que ses applications, est quant à elle, expliquée en détail dans l'article suivant :
Best practices pour les snapshots VMware ESXi

Installation du script de sauvegarde ghettoVCB :
Sauvegarde d'un hôte VMware ESXi grâce au script ghettoVCB

Partager l'article

• Précédent
• Suivant