Sauvegarde, partie 7: Conclusions

Cette note termine le cycle de sauvegarde. Il parlera de l'organisation logique d'un serveur dédié (ou VPS), pratique pour la sauvegarde, et il offrira également la possibilité de restaurer rapidement le serveur à partir d'une sauvegarde sans aucun temps d'arrêt en cas d'accident.

Données source

Un serveur dédié possède le plus souvent au moins deux disques durs qui sont utilisés pour organiser une matrice RAID de premier niveau (miroir). Cela est nécessaire pour pouvoir continuer le serveur en cas de panne d'un lecteur. S'il s'agit d'un serveur dédié ordinaire, il peut y avoir un contrôleur RAID matériel séparé avec une technologie de mise en cache active sur les SSD, de sorte qu'en plus des disques durs ordinaires, un ou plusieurs SSD peuvent être connectés. Parfois, des serveurs dédiés sont proposés, dans lesquels seule SATADOM est présente à partir de disques locaux (petits disques, structurellement - un lecteur flash USB connecté au port SATA), ou même un petit lecteur flash USB ordinaire (8-16 Go) connecté à un port interne spécial, et les données sont extraites du système de stockage connectés 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 à partir du système de stockage. Je ne considérerai pas ces options, car dans de tels cas, la tâche de sauvegarder le serveur en douceur passe au spécialiste qui gère le système de stockage, il existe généralement différentes technologies propriétaires pour créer des instantanés d'état, la déduplication intégrée et d'autres joies de l'administrateur système discutées dans les parties précédentes de cette série. Le volume de la matrice de disques d'un serveur dédié peut atteindre plusieurs dizaines de téraoctets, selon le nombre et le volume de 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 plus), et les tarifs pour ces VPS peuvent facilement être plus chers que les serveurs dédiés les moins chers du même hébergeur. VPS a le plus souvent un lecteur, car en dessous se trouvera le stockage (ou quelque chose d'hyperconvergé). Parfois, VPS a plusieurs disques avec des caractéristiques différentes, à des fins différentes:

• petit système - pour installer le système d'exploitation;
• grand - stockage des données utilisateur.

Lors de la réinstallation du système à l'aide du panneau de commande, le disque contenant les données utilisateur n'est pas écrasé, mais le système est complètement rechargé. De plus, dans le cas de VPS, l'hôte peut offrir un bouton qui prend un instantané de l'état du VPS (ou du disque), cependant, si vous installez votre système d'exploitation ou oubliez d'activer le service souhaité à l'intérieur du VPS, certaines données peuvent toujours être perdues. En plus du bouton, un service de stockage de données est généralement proposé, le plus souvent très limité. Habituellement, il s'agit d'un compte avec accès FTP ou SFTP, parfois avec SSH, avec un shell tronqué (par exemple rbash), ou une restriction sur l'exécution de commandes via authorized_keys (via ForcedCommand).

Un serveur dédié est connecté au réseau par deux ports à une vitesse de 1 Gbit / s, parfois il peut s'agir de cartes à une vitesse de 10 Gbit / s. VPS a souvent une seule interface réseau. Le plus souvent, les centres de données ne limitent pas la vitesse du réseau à l'intérieur du centre de données, mais limitent la vitesse d'accès à Internet.

Une charge typique d'un tel serveur dédié ou VPS est un serveur Web, une base de données, un serveur d'applications. Parfois, divers services d'assistance supplémentaires peuvent être installés, y compris pour un serveur Web ou une base de données: moteur de recherche, système de messagerie, etc.

Un serveur spécialement préparé agit comme un espace pour stocker des copies de sauvegarde, il sera décrit plus en détail ci-dessous.

Organisation du disque logique

S'il y a un contrôleur RAID, ou s'il s'agit d'un VPS avec un disque, et il n'y a pas non plus de préférences particulières pour le sous-système de disque (par exemple, un disque rapide séparé pour la base de données) - tout l'espace libre est divisé comme suit: une partition est créée, un groupe de volumes LVM est créé par-dessus , il crée plusieurs volumes: 2 petits de la même taille qui sont utilisés comme système de fichiers racine (ils sont modifiés alternativement avec des mises à jour pour permettre une restauration rapide, l'idée a été espionnée de la distribution Calculate Linux), une autre est pour la partition de swap, le reste est gratuit cet espace est divisé en petits volumes utilisés comme système de fichiers racine pour les conteneurs pleins, disques pour les machines virtuelles, systèmes de fichiers 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 complètement autosuffisants, c'est-à-dire ne devrait pas dépendre les uns des autres et 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 d'autres services de manière à supprimer au maximum les dépendances des volumes entre eux. Par exemple, chaque site s'exécute sur son propre utilisateur, les fichiers de configuration du site se trouvent dans le répertoire de base 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, mais, par exemple, / home / /configs/nginx/*.conf

S'il y a plusieurs disques, vous pouvez créer un RAID logiciel (et configurer sa mise en cache sur SSD, s'il y a un besoin et une opportunité), en plus de pouvoir assembler LVM selon les règles suggérées ci-dessus. Dans ce cas également, vous pouvez utiliser ZFS ou BtrFS, mais ici, cela vaut la peine d'être envisagé plusieurs fois: les deux nécessitent une approche beaucoup plus sérieuse des ressources, en outre, ZFS n'est pas fourni avec le noyau Linux.

Quel que soit le schéma utilisé, il est toujours utile d'estimer à l'avance la vitesse approximative d'écriture des modifications sur les disques, puis de calculer la taille de l'espace libre qui sera réservé pour créer des 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 de la baie de données est de 10 téraoctets - le temps de synchronisation peut aller jusqu'à un jour (22 heures - ce montant sera transféré sur le réseau à 1 Gbit / s) - cela vaut la peine de réserver environ 800 Go En réalité, le nombre sera inférieur; vous pouvez le diviser en toute sécurité par le nombre de volumes logiques.

Périphérique de serveur de stockage de sauvegarde

La principale différence entre le serveur pour le stockage des sauvegardes est les disques volumineux, bon marché et relativement lents. Étant donné que les disques durs modernes ont déjà franchi la barre des 10 To dans un seul lecteur, il est nécessaire d'utiliser des systèmes de fichiers ou RAID avec des 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 échouer en raison d'une charge accrue. Sur les 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 d'environ la même taille (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 pour vérification leur sera déployée);
• les volumes utilisés comme référentiels BorgBackup (les données pour les sauvegardes seront directement récupérées ici).

Le principe de fonctionnement est que des volumes séparés sont créés pour chaque serveur sous le référentiel BorgBackup, où les données des serveurs de bataille iront. Les référentiels fonctionnent en mode add-only, ce qui élimine la possibilité de suppression intentionnelle des données, et en raison de la déduplication et du nettoyage périodique des référentiels des anciennes sauvegardes (il existe des copies annuelles, mensuelles pour la dernière année, hebdomadaires pour le dernier mois, quotidiennes pour la dernière semaine, éventuellement en spécial cas - toutes les heures pour le dernier jour: total 24 + 7 + 4 + 12 + annuel - environ 50 copies pour chaque serveur).
Dans les référentiels BorgBackup, seul le mode d'ajout n'est pas activé; à la place, ForcedCommand est utilisé dans .ssh / authorized_keys de 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....... 

Un wrapper de script est placé au-dessus du chemin spécifié au-dessus de borg, qui, en plus de lancer le binaire avec les paramètres, démarre en outre le processus de restauration de la 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 après le processus de téléchargement des données est automatiquement restaurée sur le volume logique correspondant.

Cette conception vous permet de nettoyer périodiquement les sauvegardes inutiles et ne permet pas non plus aux 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é lui-même ou VPS, car un tel schéma donne plus de contrôle sur le processus de sauvegarde à partir 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'image est démontée et supprimée.

S'il existe une petite base de données (jusqu'à 1 Go pour chaque site), un vidage de 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 pour que le vidage ne soit pas accessible via le serveur Web. Si les bases de données sont volumineuses, vous devez configurer une exploration de données "à chaud", par exemple en utilisant xtrabackup pour MySQL, ou WAL avec archive_command dans PostgreSQL. Dans ce cas, la base de données sera restaurée séparément de ces sites.

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 généralement pas nécessaires - il suffit de créer des instantanés de volumes logiques, qui sont ensuite traités de manière similaire à un instantané du système de fichiers racine. Après avoir pris les données, les photos sont supprimées.

Des travaux supplémentaires 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.
• recherche un fichier de balises indiquant que le processus de capture de 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 meurt, un serveur dédié similaire est lancé, qui est chargé à partir d'une image standard. Très probablement, le téléchargement se fera sur le réseau, cependant, le technicien du centre de données effectuant la configuration du serveur peut immédiatement copier cette image standard sur l'un des disques. Le téléchargement a lieu dans la RAM, après quoi le processus de récupération démarre:

• une demande est faite pour attacher le périphérique de bloc via iscsi \ nbd ou un autre protocole similaire du volume logique contenant le système de fichiers racine du serveur mort; car le système de fichiers racine doit être petit - cette étape doit être terminée en quelques minutes. La récupération du chargeur de démarrage est également effectuée;
• la structure des volumes logiques locaux est recréée, les volumes logiques sont attachés à partir du serveur de sauvegarde à l'aide du module de noyau dm_clone: ​​la récupération des données commence et les modifications sont écrites immédiatement sur les disques locaux
• un conteneur est lancé avec tous les disques physiques disponibles - le serveur est entièrement restauré, 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 désactivé, le serveur est redémarré;

Après le redémarrage, le serveur disposera de toutes les données qui étaient au moment de la sauvegarde, et inclura également toutes les modifications qui ont été apportées au cours du processus de récupération.

Je vous invite à discuter de l'option proposée dans les commentaires, merci de votre attention!