Introduction
Les sauvegardes sont très importantes pour les serveurs cloud. Que vous exécutiez un seul projet avec toutes ses données stockées sur un seul serveur, ou que vous déployiez directement depuis Git vers des VM qui sont créées et supprimées tout en conservant un ensemble minimal de journaux, vous devez toujours prévoir un scénario d’échec. Cela peut signifier différentes choses selon les applications que vous utilisez, l’importance d’avoir une bascule immédiate et les types de problèmes que vous anticipez.
Dans ce guide, vous explorerez les différentes approches pour fournir des sauvegardes et une redondance des données. Parce que différents cas d’utilisation exigent des solutions différentes, cet article ne pourra pas vous donner une réponse universelle, mais vous apprendrez ce qui est important dans différents scénarios et quelles implémentations conviennent le mieux à votre opération.
Dans la première partie de ce guide, vous examinerez plusieurs solutions de sauvegarde et passerez en revue les mérites relatifs de chacune afin de pouvoir choisir l’approche qui convient le mieux à votre environnement. Dans la deuxième partie, vous explorerez les options de redondance.
Partie 1 — Quelle est la différence entre la redondance et la sauvegarde ?
Les définitions des termes redondant et backup se chevauchent souvent et, dans de nombreux cas, sont confondues. Ce sont deux concepts distincts qui sont liés, mais différents. Certaines solutions fournissent les deux.
Redondance
La redondance des données signifie qu’il y a une reprise automatique immédiate en cas de problème système. Une reprise automatique signifie que si un ensemble de données (ou un hôte) devient indisponible, une autre copie parfaite est immédiatement mise en production pour prendre sa place. Cela entraîne presque aucun temps d’arrêt perceptible, et l’application ou le site web peut continuer à traiter les demandes comme si rien ne s’était passé. Pendant ce temps, l’administrateur système (dans ce cas, vous) a l’opportunité de résoudre le problème et de ramener le système à un état entièrement opérationnel.
Cependant, une solution de redondance n’est généralement pas non plus une solution de sauvegarde. Le stockage redondant ne protège pas nécessairement contre une panne qui affecte l’ensemble de la machine ou du système. Par exemple, si vous avez configuré un RAID en miroir (comme le RAID 1), vos données sont redondantes dans le sens où si un lecteur tombe en panne, l’autre sera toujours disponible. Cependant, si la machine elle-même tombe en panne, toutes vos données pourraient être perdues.
Avec des solutions de redondance telles que MySQL Group Replication, chaque opération est généralement effectuée sur chaque copie des données. Cela inclut les opérations malveillantes ou accidentelles. Par définition, une solution de sauvegarde devrait également vous permettre de restaurer à partir d’un point précédent où les données sont connues comme étant bonnes.
Sauvegarde
En général, vous devez maintenir des sauvegardes fonctionnelles de vos données importantes. Selon votre situation, cela pourrait signifier sauvegarder les données d’application ou d’utilisateur, ou l’ensemble d’un site web ou d’une machine. L’idée derrière les sauvegardes est que en cas de perte de système, de machine ou de données, vous pouvez restaurer, redéployer ou accéder autrement à vos données. La restauration à partir d’une sauvegarde peut nécessiter un temps d’arrêt, mais cela peut faire la différence entre recommencer depuis un jour auparavant et recommencer à zéro. Tout ce que vous ne pouvez pas vous permettre de perdre devrait, par définition, être sauvegardé.
En termes de méthodes, il existe plusieurs niveaux de sauvegardes différents. Ces niveaux peuvent être superposés selon les besoins pour tenir compte de différents types de problèmes. Par exemple, vous pouvez sauvegarder un fichier de configuration avant de le modifier afin de pouvoir revenir à vos anciens paramètres si un problème survient. C’est idéal pour les petits changements que vous surveillez activement. Cependant, cette configuration échouerait en cas de panne de disque ou de tout problème plus complexe. Vous devriez également effectuer régulièrement des sauvegardes automatiques vers un emplacement distant.
Les sauvegardes en elles-mêmes ne fournissent pas de basculement automatique. Cela signifie que vos défaillances peuvent ne pas vous coûter de données (en supposant que vos sauvegardes sont à jour à 100 %), mais elles peuvent vous coûter du temps de disponibilité. C’est une raison pour laquelle la redondance et les sauvegardes sont souvent utilisées en combinaison l’une avec l’autre.
Partie 2 — Sauvegarde au Niveau des Fichiers
Une des formes les plus familières de sauvegarde est une sauvegarde au niveau des fichiers. Ce type de sauvegarde utilise des outils de copie de niveau de système de fichiers normaux pour transférer des fichiers vers un autre emplacement ou appareil.
Comment Utiliser la Commande cp
En théorie, vous pourriez sauvegarder une machine Linux, comme votre serveur cloud, avec la commande cp. Cela copie des fichiers d’un emplacement local à un autre. Sur un ordinateur local, vous pourriez monter un lecteur amovible, puis copier des fichiers dessus :
Cet exemple monte un disque amovible, sdc, en tant que /mnt/my-backup et copie ensuite le répertoire /etc sur le disque. Il démonte ensuite le lecteur, qui peut être stocké ailleurs.
Comment Utiliser Rsync
A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:
-azvP est un ensemble typique d’options Rsync. Voici ce que chacune d’entre elles fait :
aenables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the-rlptgoDoptions individually (yes, really). Notably, the-roption tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such ascpandscp.zcompresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.venables verbose mode, so you can read more details of your transfer while it is in progress.Ptells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.
Vous pouvez consulter d’autres options rsync sur sa page de manuel.
Bien sûr, dans un environnement cloud, vous ne monteriez pas et ne copieriez pas normalement des fichiers sur un disque monté à chaque fois. Rsync peut également effectuer des sauvegardes à distance sur un réseau en fournissant une syntaxe de type SSH. Cela fonctionnera sur n’importe quel hôte auquel vous pouvez vous connecter en SSH, tant que Rsync est installé aux deux extrémités. Étant donné que Rsync est considéré comme un outil Linux de base, c’est presque toujours une supposition sûre, même si vous travaillez localement sur une machine Mac ou Windows.
Cela sauvegardera le répertoire /etc de la machine locale dans un répertoire sur remote_host situé à /backup. Cela réussira si vous avez l’autorisation d’écrire dans ce répertoire et s’il y a de l’espace disponible.
Vous pouvez également consulter plus d’informations sur comment utiliser Rsync pour synchroniser des répertoires locaux et distants.
Comment utiliser d’autres outils de sauvegarde
Bien que cp et rsync soient utiles et omniprésents, ils ne constituent pas à eux seuls une solution complète. Pour automatiser les sauvegardes à l’aide de Rsync, vous devriez créer vos propres procédures automatisées, planifier les sauvegardes, faire tourner les journaux, etc. Bien que cela puisse être approprié pour certains déploiements très petits qui ne souhaitent pas utiliser de services externes, ou pour de très grands déploiements qui disposent de ressources dédiées pour maintenir des scripts très granulaires à diverses fins, de nombreux utilisateurs peuvent préférer investir dans une offre de sauvegarde dédiée.
Bacula
Bacula est une solution complexe et flexible qui fonctionne selon un modèle client-serveur. Bacula est conçu avec des concepts séparés de clients, d’emplacements de sauvegarde et de directeurs (le composant qui orchestre la sauvegarde effective). Il configure également chaque tâche de sauvegarde dans une unité appelée « job ».
Cela permet une configuration extrêmement granulaire et flexible. Vous pouvez sauvegarder plusieurs clients sur un seul dispositif de stockage, un client sur plusieurs dispositifs de stockage, et modifier le schéma de sauvegarde en ajoutant des nœuds ou en ajustant leurs détails. Il fonctionne bien dans un environnement réseau, est extensible et modulaire, ce qui le rend idéal pour sauvegarder un site ou une application répartis sur plusieurs serveurs.
Duplicity
Duplicity est un autre outil de sauvegarde open source. Il utilise par défaut le chiffrement GPG pour les transferts.
L’avantage évident de l’utilisation du chiffrement GPG pour les sauvegardes de fichiers est que les données ne sont pas stockées en texte clair. Seul le propriétaire de la clé GPG peut décrypter les données. Cela offre un certain niveau de sécurité pour compenser les mesures de sécurité supplémentaires nécessaires lorsque vos données sont stockées à plusieurs endroits.
Un autre avantage qui peut ne pas être évident pour ceux qui n’utilisent pas régulièrement GPG est que chaque transaction doit être vérifiée pour être entièrement exacte. GPG, comme Rsync, impose une vérification de hachage pour garantir qu’il n’y a pas eu de perte de données lors du transfert. Cela signifie que lors de la restauration de données à partir d’une sauvegarde, vous aurez beaucoup moins de chances de rencontrer une corruption de fichier.
Partie 3 — Sauvegardes au Niveau des Blocs
A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.
Un avantage des sauvegardes au niveau des blocs est qu’elles sont généralement plus rapides. Alors que les sauvegardes basées sur les fichiers initient généralement un nouveau transfert pour chaque fichier séparé, une sauvegarde basée sur les blocs transférera des blocs, ce qui signifie que moins de transferts non séquentiels doivent être initiés pour terminer la copie.
Utilisation de dd pour Effectuer des Sauvegardes au Niveau des Blocs
La méthode la plus courante pour effectuer des sauvegardes au niveau du bloc est avec l’utilitaire dd. dd peut être utilisé pour créer des images de disque entières, et est également fréquemment utilisé lors de l’archivage de supports amovibles tels que des CD ou des DVD. Cela signifie que vous pouvez sauvegarder une partition ou un disque dans un seul fichier ou un périphérique brut sans aucune étape préliminaire.
Pour utiliser dd, vous devez spécifier un emplacement d’entrée et un emplacement de sortie, comme ceci :
Dans ce scénario, l’argument if= spécifie le périphérique ou l’emplacement d’entrée. L’argument of= spécifie le fichier ou l’emplacement de sortie. Faites attention à ne pas les confondre, sinon vous pourriez effacer tout un disque par erreur.
Par exemple, pour sauvegarder une partition contenant vos documents, qui se trouve à /dev/sda3, vous pouvez créer une image de ce répertoire en fournissant un chemin de sortie vers un fichier .img:
Partie 4 — Sauvegarde avec versioning
Une des principales motivations pour sauvegarder des données est de pouvoir restaurer une version précédente d’un fichier en cas de modification ou de suppression indésirable. Bien que tous les mécanismes de sauvegarde mentionnés jusqu’à présent puissent le faire, vous pouvez également mettre en œuvre une solution plus granulaire.
Par exemple, une manière manuelle d’y parvenir serait de créer une sauvegarde d’un fichier avant de le modifier dans nano:
Vous pourriez même automatiser ce processus en créant des fichiers cachés estampillés à chaque fois que vous modifiez un fichier avec votre éditeur. Par exemple, vous pourriez placer ceci dans votre fichier ~/.bashrc, afin que chaque fois que vous exécutez nano depuis votre shell bash (c’est-à-dire $), il crée automatiquement une sauvegarde estampillée avec l’année (%y), le mois (%m), le jour (%d), et ainsi de suite :
Cela fonctionnerait dans la mesure où vous éditez manuellement les fichiers avec nano, mais cela est limité dans son ampleur et pourrait rapidement remplir un disque. Vous pouvez voir comment cela pourrait finir par être pire que de copier manuellement les fichiers que vous allez éditer.
Une alternative qui résout bon nombre des problèmes inhérents à cette conception est d’utiliser Git comme système de contrôle de version. Bien qu’il ait été développé principalement pour se concentrer sur le versionnage de texte brut, généralement du code source, ligne par ligne, vous pouvez utiliser Git pour suivre presque n’importe quel type de fichier. Pour en savoir plus, vous pouvez consulter Comment utiliser Git efficacement.
Partie 5 — Sauvegardes au niveau du serveur
La plupart des fournisseurs d’hébergement fourniront également leur propre fonctionnalité de sauvegarde facultative. La fonction de sauvegarde de DigitalOcean effectue régulièrement des sauvegardes automatisées pour les droplets ayant activé ce service. Vous pouvez activer cela lors de la création du droplet en cochant la case « Sauvegardes » :
Cela sauvegardera l’image complète de votre serveur cloud régulièrement. Cela signifie que vous pouvez le redéployer à partir de la sauvegarde, ou l’utiliser comme base pour de nouveaux droplets.
Pour l’imagerie ponctuelle de votre système, vous pouvez également créer des instantanés. Ceux-ci fonctionnent de manière similaire aux sauvegardes, mais ne sont pas automatisés. Bien qu’il soit possible de prendre un instantané d’un système en cours d’exécution dans certains contextes, ce n’est pas toujours recommandé, en fonction de la manière dont vous écrivez sur votre système de fichiers :
Vous pouvez en savoir plus sur les sauvegardes et les instantanés de DigitalOcean dans la documentation sur les Conteneurs et Images.
GitOps
Enfin, il convient de noter qu’il existe des circonstances dans lesquelles vous ne chercherez pas nécessairement à mettre en œuvre des sauvegardes sur une base par serveur. Par exemple, si votre déploiement suit les principes du GitOps, vous pouvez considérer bon nombre de vos serveurs cloud individuels comme jetables, et plutôt traiter les sources de données distantes telles que les dépôts Git comme la source de vérité effective pour vos données. Des déploiements complexes et modernes comme celui-ci peuvent être plus évolutifs et moins sujets aux défaillances dans de nombreux cas. Cependant, vous voudrez toujours mettre en place une stratégie de sauvegarde pour vos magasins de données eux-mêmes, ou pour un serveur de journalisation centralisé auquel chacun de ces serveurs jetables peut envoyer des informations. Considérez quels aspects de votre déploiement peuvent ne pas avoir besoin d’être sauvegardés, et lesquels le doivent.
Conclusion
Dans cet article, vous avez exploré différents concepts et solutions de sauvegarde. Ensuite, vous voudrez peut-être examiner les solutions pour activer la redondance.