Cette note termine le cycle sur la sauvegarde. Il abordera l'organisation logique d'un serveur dédié (ou VPS), pratique pour la sauvegarde, et proposera également une option permettant de restaurer rapidement un serveur à partir d'une sauvegarde sans trop de temps d'arrêt en cas de sinistre.
Données initiales
Un serveur dédié dispose le plus souvent d'au moins deux disques durs qui servent à organiser une matrice RAID de premier niveau (miroir). Ceci est nécessaire pour pouvoir continuer à faire fonctionner le serveur en cas de panne d'un disque. S'il s'agit d'un serveur dédié classique, il peut y avoir un contrôleur RAID matériel distinct avec une technologie de mise en cache active sur SSD, de sorte qu'en plus des disques durs ordinaires, un ou plusieurs SSD puissent être connectés. Parfois, des serveurs dédiés sont proposés, dans lesquels les seuls disques locaux sont SATADOM (petits disques, structurellement un lecteur flash connecté à un port SATA), ou même un petit lecteur flash ordinaire (8-16 Go) connecté à un port interne spécial, et le les données sont extraites du système de stockage, connecté via un réseau de stockage dédié (Ethernet 10G, FC, etc.), et il existe des serveurs dédiés qui sont chargés directement depuis le système de stockage. Je n'envisagerai pas de telles options, car dans de tels cas, la tâche de sauvegarde du serveur passe en douceur au spécialiste qui gère le système de stockage ; il existe généralement diverses technologies propriétaires pour créer des instantanés, une déduplication intégrée et d'autres joies de l'administrateur système. , discuté dans les parties précédentes de cette série. Le volume de la baie 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 il y en a aussi plus), et les tarifs de tels VPS peuvent facilement être plus chers que les serveurs dédiés les moins chers du même hébergeur. Un VPS a le plus souvent un disque, car il y aura un système de stockage (ou quelque chose d'hyperconvergé) en dessous. Parfois un VPS dispose de plusieurs disques avec des caractéristiques différentes, pour des usages différents :
- petit système - pour installer le système d'exploitation ;
- grand - stockage des données utilisateur.
Lorsque vous réinstallez le système à l'aide du panneau de configuration, le disque contenant les données utilisateur n'est pas écrasé, mais le disque système est complètement rempli. De plus, dans le cas d'un VPS, l'hébergeur peut proposer un bouton qui prend un instantané de l'état du VPS (ou du disque), mais si vous installez votre propre système d'exploitation ou oubliez d'activer le service souhaité à l'intérieur du VPS, certains des données peuvent encore être perdues. En plus du bouton, un service de stockage de données est généralement proposé, le plus souvent très limité. Il s'agit généralement d'un compte avec accès via FTP ou SFTP, parfois avec SSH, avec un shell simplifié (par exemple, rbash) ou une restriction sur l'exécution de commandes via des clés_autorisées (via ForcedCommand).
Un serveur dédié est connecté au réseau par deux ports avec un débit de 1 Gbps, il peut parfois s'agir de cartes avec un débit de 10 Gbps. Le VPS possède le plus souvent une seule interface réseau. Le plus souvent, les centres de données ne limitent pas la vitesse du réseau au sein du centre de données, mais limitent la vitesse d'accès à Internet.
La charge typique d'un tel serveur dédié ou VPS est un serveur Web, une base de données et un serveur d'applications. Parfois, divers services auxiliaires supplémentaires peuvent être installés, notamment pour un serveur web ou une base de données : moteur de recherche, système de messagerie, etc.
Un serveur spécialement préparé fait office d'espace de stockage des copies de sauvegarde, nous en parlerons plus en détail plus tard.
Organisation logique du système de disques
Si vous disposez d'un contrôleur RAID ou d'un VPS avec un disque et qu'il n'y a pas de préférences particulières pour le fonctionnement du sous-système de disque (par exemple, un disque rapide séparé pour une base de données), tout l'espace libre est divisé comme suit : une partition est créé, et un groupe de volumes LVM est créé dessus, plusieurs volumes y sont créés : 2 petits de même taille, utilisés comme système de fichiers racine (modifiés un par un lors des mises à jour pour possibilité de restauration rapide, l'idée a été reprise de la distribution Calculate Linux), une autre est destinée à la partition d'échange, le reste de l'espace libre est divisé en petits volumes, utilisé comme système de fichiers racine pour les conteneurs à part entière, les disques pour les machines virtuelles, les fichiers systèmes pour les comptes dans /home (chaque compte a son propre système de fichiers), systèmes de fichiers pour les conteneurs d'applications.
Remarque importante : les volumes doivent être entièrement autonomes, c'est-à-dire ne doivent pas dépendre les uns des autres ni du système de fichiers racine. Dans le cas de machines virtuelles ou de conteneurs, ce point est automatiquement observé. S'il s'agit de conteneurs d'applications ou de répertoires personnels, vous devez penser à séparer les fichiers de configuration du serveur Web et des autres services de manière à éliminer autant que possible les dépendances entre les volumes. Par exemple, chaque site s'exécute depuis 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 du site ne sont pas inclus via /etc/nginx/conf.d/.conf et, par exemple, /home//configs/nginx/*.conf
S'il y a plusieurs disques, vous pouvez créer une matrice RAID logicielle (et configurer sa mise en cache sur un SSD, si besoin et opportunité), sur laquelle vous pouvez construire LVM selon les règles proposées ci-dessus. Dans ce cas également, vous pouvez utiliser ZFS ou BtrFS, mais vous devriez y réfléchir à deux fois : les deux nécessitent une approche beaucoup plus sérieuse des ressources, et de plus, ZFS n'est pas inclus dans le noyau Linux.
Quel que soit le schéma utilisé, il vaut toujours la peine d'estimer à l'avance la vitesse approximative d'écriture des modifications sur les disques, puis de calculer la quantité d'espace libre qui sera réservée à la création d'instantanés. Par exemple, si notre serveur écrit des données à une vitesse de 10 mégaoctets par seconde et que la taille de l'ensemble des données est de 10 téraoctets, le temps de synchronisation peut atteindre un jour (22 heures - c'est combien un tel volume sera transféré sur le réseau 1 Gbps) - cela vaut la peine de réserver environ 800 Go . En réalité, le chiffre sera plus petit, vous pouvez le diviser en toute sécurité par le nombre de volumes logiques.
Périphérique du serveur de stockage de sauvegarde
La principale différence entre un serveur de stockage de copies de sauvegarde réside dans ses disques volumineux, bon marché et relativement lents. Étant donné que les disques durs modernes ont déjà franchi la barre des 10 To sur un disque, il est nécessaire d'utiliser des systèmes de fichiers ou RAID avec sommes de contrôle, car lors de la reconstruction de la matrice ou de la restauration du système de fichiers (plusieurs jours !), le deuxième disque peut tomber en panne en raison de à une charge accrue. Sur des disques d'une capacité allant jusqu'à 1 To, ce n'était pas si sensible. Pour simplifier la description, je suppose que l'espace disque est divisé en deux parties de taille à peu près égale (encore une fois, par exemple, en utilisant LVM) :
- les volumes correspondant aux serveurs utilisés pour stocker les données des utilisateurs (la dernière sauvegarde effectuée y sera déployée pour vérification) ;
- volumes utilisés comme référentiels BorgBackup (les données pour les sauvegardes iront directement ici).
Le principe de fonctionnement est que des volumes distincts sont créés pour chaque serveur pour les référentiels BorgBackup, où iront les données des serveurs de combat. Les référentiels fonctionnent en mode ajout uniquement, ce qui élimine la possibilité de supprimer intentionnellement des données, et grâce à la déduplication et au nettoyage périodique des référentiels à partir d'anciennes sauvegardes (des copies annuelles restent, mensuellement pour la dernière année, hebdomadaires pour le dernier mois, quotidiennes pour le la semaine dernière, éventuellement dans des cas particuliers - horaire pour le dernier jour : total 24 + 7 + 4 + 12 + annuel - environ 50 exemplaires pour chaque serveur).
Les référentiels BorgBackup n'activent pas le mode ajout uniquement ; à la place, une ForcedCommand dans .ssh/authorized_keys est utilisée quelque chose comme ceci :
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Le chemin spécifié contient un script wrapper au-dessus de borg, qui, en plus de lancer le binaire avec des paramètres, démarre en outre le processus de restauration de la copie de sauvegarde après la suppression des données. Pour ce faire, le script wrapper crée un fichier de balises à côté du référentiel correspondant. La dernière sauvegarde effectuée est automatiquement restaurée sur le volume logique correspondant une fois le processus de remplissage des données terminé.
Cette conception vous permet de nettoyer périodiquement les sauvegardes inutiles et empêche également les serveurs de combat de supprimer quoi que ce soit sur le serveur de stockage de sauvegarde.
Processus de sauvegarde
L'initiateur de la sauvegarde est le serveur dédié ou VPS lui-même, car ce schéma donne plus de contrôle sur le processus de sauvegarde de la part de ce serveur. Tout d'abord, un instantané de l'état du système de fichiers racine actif est pris, qui est monté et téléchargé à l'aide de BorgBackup sur le serveur de stockage de sauvegarde. Une fois la capture des données terminée, l'instantané est démonté et supprimé.
S'il existe une 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 approprié, où se trouvent le reste des données du même site, mais de manière à ce que le dump soit non accessible via le serveur Web. Si les bases de données sont volumineuses, vous devez configurer la suppression des données « à chaud », par exemple en utilisant xtrabackup pour MySQL, ou travailler avec WAL avec archive_command dans PostgreSQL. Dans ce cas, la base de données sera restaurée séparément des données du site.
Si des conteneurs ou des machines virtuelles sont utilisés, vous devez configurer qemu-guest-agent, CRIU ou d'autres technologies nécessaires. Dans d'autres cas, des paramètres supplémentaires ne sont le plus souvent pas nécessaires - nous créons simplement des instantanés de volumes logiques, qui sont ensuite traités de la même manière qu'un instantané de l'état du système de fichiers racine. Une fois les données prises, les photos sont supprimées.
D'autres travaux sont effectués sur le serveur de stockage de sauvegarde :
- la dernière sauvegarde effectuée dans chaque référentiel est vérifiée,
- la présence d'un fichier de marque est vérifiée, indiquant que le processus de collecte des données est terminé,
- les données sont étendues au volume local correspondant,
- le fichier de balises est supprimé
Processus de récupération du serveur
Si le serveur principal tombe en panne, un serveur dédié similaire est lancé, qui démarre à partir d'une image standard. Le téléchargement s'effectuera très probablement via le réseau, mais le technicien du centre de données qui configure le serveur peut immédiatement copier cette image standard sur l'un des disques. Le téléchargement s'effectue dans la RAM, après quoi le processus de récupération démarre :
- une demande est faite pour attacher un périphérique bloc via iscsinbd ou un autre protocole similaire à un volume logique contenant le système de fichiers racine du serveur décédé ; Étant donné que le système de fichiers racine doit être petit, cette étape devrait être effectuée en quelques minutes. Le chargeur de démarrage est également restauré ;
- la structure des volumes logiques locaux est recréée, les volumes logiques sont attachés depuis le serveur de sauvegarde à l'aide du module noyau dm_clone : la récupération des données commence et les modifications sont immédiatement écrites sur les disques locaux
- un conteneur est lancé avec tous les disques physiques disponibles - les fonctionnalités du serveur sont entièrement restaurées, mais avec des performances réduites ;
- une fois la synchronisation des données terminée, les volumes logiques du serveur de sauvegarde sont déconnectés, le conteneur est éteint et le serveur est redémarré ;
Après un redémarrage, le serveur disposera de toutes les données qui étaient présentes au moment de la création de la sauvegarde et inclura également toutes les modifications apportées au cours du processus de restauration.
Autres articles de la série
Sauvegarde Partie 7 : Conclusions
Je vous invite à discuter de l'option proposée dans les commentaires, merci de votre attention !
Source: habr.com