Cette note conclut le cycle sur la sauvegarde. Nous allons parler de l'organisation logique d'un serveur dédié (ou VPS) qui est pratique pour la sauvegarde, ainsi qu'une méthode de restauration rapide du serveur à partir d'une sauvegarde sans temps d'arrêt significatif en cas de défaillance.
Données d'origine
Un serveur dédié a généralement au moins deux disques durs, utilisés pour organiser un tableau RAID de premier niveau (miroir). Cela permet de continuer à faire fonctionner le serveur si un disque tombe en panne. S'il s'agit d'un serveur dédié classique, il peut y avoir un contrôleur RAID matériel séparé, avec une technologie de mise en cache active sur SSD, permettant de connecter un ou plusieurs SSD en plus des disques durs classiques. Parfois, des serveurs dédiés sont proposés où seuls des disques SATADOM (petits disques, structurellement des clés USB, se connectant à un port SATA) sont présents, voire une petite clé USB (8-16 Go) se connectant à un port interne spécial, les données étant récupérées d'un SAN connecté via un réseau de stockage dédié (Ethernet 10G, FC, etc.). Il existe également des serveurs dédiés qui démarrent directement à partir du SAN. Je ne vais pas examiner de telles options, car dans ces cas, la tâche de sauvegarde du serveur est généralement confiée à un spécialiste gérant le SAN, où différentes technologies propriétaires de création d'instantanés, déduplication intégrée et autres avantages pour les administrateurs systèmes, sont typiquement utilisées. La capacité du tableau de disques d'un serveur dédié peut atteindre plusieurs dizaines de téraoctets, selon le nombre et la taille des disques connectés au serveur. Dans le cas des VPS, les volumes sont plus modestes : généralement pas plus de 100 Go (mais parfois plus), et les tarifs pour ces VPS peuvent facilement dépasser ceux des serveurs dédiés les moins chers proposés par le même hébergeur. Les VPS ont souvent un seul disque, car il accueillera un SAN (ou quelque chose d'hyper-convergé). Parfois, un VPS est équipé de plusieurs disques avec des caractéristiques différentes, à des fins variées :
- petit système — pour l'installation du système d'exploitation ;
- grand — stockage des données utilisateur.
Lors de la réinstallation du système via le panneau de contrôle, le disque contenant les données utilisateur n'est pas effacé, tandis que le système est complètement réécrit. De plus, dans le cas des VPS, l'hébergeur peut proposer un bouton permettant de créer une image de l'état du VPS (ou du disque), mais si vous installez votre propre système d'exploitation ou oubliez d'activer le service nécessaire au sein du VPS, certaines données peuvent tout de même être perdues. En plus du bouton, un service de stockage de données est généralement proposé, mais souvent de manière très limitée. Cela se traduit généralement par un compte avec un accès via le protocole FTP ou SFTP, parfois accompagné de SSH, avec un shell restreint (par exemple rbash), ou une limitation dans l'exécution des commandes via authorized_keys (par ForcedCommand).
Un serveur dédié est connecté au réseau par deux ports à une vitesse de 1 Gbit/s, parfois ce sont des cartes à 10 Gbit/s. Pour un VPS, l'interface réseau est généralement unique. Les centres de données ne limitent souvent pas la vitesse du réseau à l'intérieur du centre, mais restreignent la vitesse d'accès à Internet.
La charge typique d'un serveur dédié ou d'un VPS comprend un serveur web, une base de données et un serveur d'applications. Parfois, différents services auxiliaires peuvent être installés, y compris pour le serveur web ou la base de données : moteur de recherche, système de messagerie, etc.
L'espace de stockage pour les sauvegardes est représenté par un serveur spécialement préparé, dont il sera question plus en détail par la suite.
Organisation logique du système de fichiers
S'il y a un contrôleur RAID, ou s'il s'agit d'un VPS avec un seul disque, et qu'il n'y a pas de préférence particulière pour le fonctionnement du sous-système de disque (par exemple, un disque rapide dédié à la base de données) — tout l'espace libre est divisé comme suit : un partition est créé, au-dessus de laquelle un groupe de volumes LVM est constitué, dans lequel plusieurs volumes sont créés : 2 petits volumes de même taille, utilisés comme système de fichiers racine (ils sont alternés lors des mises à jour pour permettre un retour rapide, une idée inspirée de la distribution Calculate Linux), un autre volume pour la partition d'échange, le reste de l'espace libre est divisé en petits volumes, utilisés comme systèmes de fichiers racine pour des conteneurs complets, des disques pour des machines virtuelles, des systèmes de fichiers pour des comptes dans /home (chaque compte ayant son propre système de fichiers), et des systèmes de fichiers pour des conteneurs d'applications.
Remarque importante : les volumes doivent être totalement autonomes, c'est-à-dire ne pas dépendre les uns des autres, ni du système de fichiers racine. Dans le cas des machines virtuelles ou des conteneurs, ce point est respecté automatiquement. Cependant, s'il s'agit de conteneurs d'applications ou de répertoires personnels, il convient de considérer la séparation des fichiers de configuration du serveur Web et d'autres services de manière à minimiser au maximum les dépendances entre les volumes. Par exemple, chaque site fonctionne sous son propre utilisateur, les fichiers de configuration du site se trouvent dans le répertoire personnel de l'utilisateur, dans les paramètres du serveur Web, les fichiers de configuration des sites sont inclus non pas via /etc/nginx/conf.d/.conf, mais, par exemple, /home//configs/nginx/*.conf
S'il y a plusieurs disques — il est possible de créer un tableau RAID logiciel (et de configurer son cache sur SSD, si cela est nécessaire et possible), au-dessus duquel construire LVM selon les règles mentionnées ci-dessus. Dans ce cas également, il est possible d'utiliser ZFS ou BtrFS, mais il faut y penser à plusieurs reprises : tous deux nécessitent une approche beaucoup plus sérieuse en termes de ressources, et de plus, ZFS n'est pas inclus dans le noyau Linux.
Peu importe le schéma utilisé, il est toujours bon d'estimer à l'avance la vitesse d'écriture des modifications sur les disques, puis de calculer la taille de l'espace libre qui sera réservé pour la création de snapshots. Par exemple, si notre serveur écrit des données à une vitesse de 10 mégaoctets par seconde, et que la taille totale du volume de données est de 10 téraoctets — le temps de synchronisation peut atteindre un jour (22 heures — c'est le temps nécessaire pour transférer ce volume via un réseau à 1 Gbit/s) — il vaut donc mieux réserver environ 800 Go. Dans la réalité, ce chiffre sera plus bas, on peut le diviser sans souci par le nombre de volumes logiques.
Serveur de stockage de sauvegardes
La principale différence d'un serveur de stockage de sauvegardes réside dans le fait qu'il utilise de grands disques, peu coûteux et relativement lents. Étant donné que les disques durs modernes ont déjà dépassé la barre des 10 To chacun, il est impératif d'utiliser des systèmes de fichiers ou des RAID avec des sommes de contrôle, car pendant la reconstruction du volume ou la restauration du système de fichiers (qui peut durer plusieurs jours !), il est possible qu'un deuxième disque tombe en panne sous une charge accrue. Sur des disques de jusqu'à 1 To, cela n'était pas si critique. Pour simplifier la description, supposons que l'espace disque est divisé en deux parties de taille à peu près égale (encore une fois, par exemple, à l'aide de LVM) :
- volumes correspondants sur les serveurs utilisés pour stocker les données utilisateur (c'est là que la dernière sauvegarde réalisée sera déployée pour vérification) ;
- volumes utilisés comme dépôts BorgBackup (c'est ici que les données pour les sauvegardes seront directement envoyées).
Le principe de fonctionnement est que des volumes séparés sont créés pour chaque serveur à des fins de dépôts BorgBackup, où les données des serveurs en production seront envoyées. Les dépôts fonctionnent en mode d'ajout uniquement, ce qui exclut la possibilité de suppression intentionnelle des données, et grâce à la dé-duplication et au nettoyage régulier des dépôts de sauvegardes anciennes (il reste des copies annuelles, mensuelles de l'année précédente, hebdomadaires du dernier mois, quotidiennes de la dernière semaine, possiblement — dans des cas particuliers — horaires pour le dernier jour : un total de 24 + 7 + 4 + 12 + des copies annuelles — environ 50 copies pour chaque serveur).
Dans les dépôts de BorgBackup, le mode append-only n'est pas activé, à la place, on utilise ForcedCommand dans .ssh/authorized_keys d'un schéma similaire :
from="adresse du serveur",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/nom_du_serveur/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......À l'emplacement spécifié, un script wrapper pour borg est placé, qui, en plus de lancer le binaire avec les paramètres, lance également le processus de restauration de la sauvegarde après la fin de la capture des données. Pour cela, le script wrapper crée un fichier indicateur à côté du dépôt correspondant. La dernière sauvegarde effectuée après la fin du processus de transfert des données est automatiquement restaurée sur le volume logique correspondant.
Cette construction permet de nettoyer périodiquement les sauvegardes inutiles et empêche également les serveurs en production de supprimer quoi que ce soit sur le serveur de stockage des sauvegardes.
Le processus de sauvegarde
Le serveur dédié ou le VPS est l'initiateur de la sauvegarde, car ce schéma donne plus de contrôle sur le processus de sauvegarde depuis ce serveur. Tout d'abord, un instantané de l'état du système de fichiers racine actif est pris, qui est ensuite monté et téléchargé à l'aide de BorgBackup sur le serveur de stockage des sauvegardes. Une fois la capture des données terminée, l'instantané est démonté et supprimé.
En cas de petite base de données (jusqu'à 1 Go pour chaque site), un dump de la base de données est effectué, qui est enregistré dans le volume logique correspondant, où se trouvent les autres données du même site, mais de manière à ce que le dump ne soit pas accessible via le serveur web. Si les bases de données sont grandes, il convient de configurer la capture de données « à chaud », par exemple, à l'aide de xtrabackup pour MySQL ou d'un travail WAL avec archive_command dans PostgreSQL. Dans ce cas, la base de données sera restaurée séparément des données des sites.
Si des conteneurs ou des machines virtuelles sont utilisés, il convient de configurer qemu-guest-agent, CRIU ou d'autres technologies nécessaires. Dans les autres cas, aucune configuration supplémentaire n'est généralement requise — il suffit de créer des instantanés des volumes logiques, qui sont ensuite traités de la même manière que l'instantané de l'état du système de fichiers racine. Après la capture des données, les instantanés sont supprimés.
Le travail ultérieur se déroule sur le serveur de stockage des sauvegardes :
- La dernière sauvegarde effectuée est vérifiée dans chaque dépôt.
- La présence d'un fichier de balise, indiquant que le processus de sauvegarde est terminé, est vérifiée.
- Le déploiement des données sur le volume local correspondant est effectué.
- Le fichier de balise est supprimé.
Processus de restauration de la fonctionnalité du serveur.
Si le serveur principal échoue, un serveur dédié similaire est lancé, chargé à partir d'une image standard. La charge se fait probablement sur le réseau, mais le technicien du centre de données, qui configure le serveur, peut également copier immédiatement cette image standard sur l'un des disques. Le chargement se fait en mémoire vive, après quoi le processus de restauration commence :
- Une demande pour connecter un périphérique de bloc via iscsinbd ou un autre protocole similaire de volume logique contenant le système de fichiers racine du serveur défaillant est effectuée ; étant donné que le système de fichiers racine doit être petit, cette étape doit être terminée en quelques minutes. Le chargeur de démarrage est également restauré.
- La structure des volumes logiques locaux est recréée, les volumes logiques du serveur de sauvegarde sont connectés à l'aide du module noyau dm_clone : le processus de restauration des données commence, et les modifications sont immédiatement enregistrées sur les disques locaux.
- Un conteneur avec tous les disques physiques disponibles est lancé - le serveur est complètement restauré, mais avec une performance réduite.
- Après la synchronisation des données, les volumes logiques du serveur de sauvegarde sont détachés, le conteneur s'éteint, et le serveur redémarre.
Après le redémarrage, le serveur disposera de toutes les données qui étaient présentes au moment de la création de la sauvegarde, ainsi que des modifications apportées lors du processus de restauration.
Autres articles de la série
Sauvegarde, partie 7 : Conclusions
Je vous invite à discuter de la proposition dans les commentaires, merci de votre attention !
Source : habr.com
