Sauvegarde, partie 1 : Finalité, revue des méthodes et technologies

Pourquoi devez-vous faire des sauvegardes ? Après tout, l'équipement est très, très fiable, et en plus, il existe des « cloud » qui sont plus fiables que les serveurs physiques : avec une configuration appropriée, un serveur « cloud » peut facilement survivre à la panne d'un serveur physique d'infrastructure, et de du point de vue des utilisateurs du service, il y aura un petit saut, à peine perceptible, dans le temps de service. De plus, la duplication des informations nécessite souvent de payer pour du temps processeur, de la charge disque et du trafic réseau « supplémentaires ».

Un programme idéal s’exécute rapidement, ne perd pas de mémoire, ne présente aucun trou et n’existe pas.

-Inconnu

Étant donné que les programmes sont encore écrits par des développeurs de protéines et qu'il n'y a souvent aucun processus de test, et que les programmes sont rarement livrés en utilisant les « meilleures pratiques » (qui sont elles-mêmes également des programmes et donc imparfaites), les administrateurs système doivent le plus souvent résoudre des problèmes qui semblent brefs mais succinctement : « revenir à ce qu'elle était », « amener la base à un fonctionnement normal », « fonctionne lentement - revenir en arrière », et aussi mon préféré « Je ne sais pas quoi, mais répare-le ».

En plus des erreurs logiques résultant d'un travail négligent des développeurs, ou d'une combinaison de circonstances, ainsi que d'une connaissance incomplète ou d'une incompréhension des petites fonctionnalités des programmes de construction - y compris celles de connexion et du système, y compris les systèmes d'exploitation, les pilotes et les micrologiciels - il y a aussi d'autres erreurs. Par exemple, la plupart des développeurs s'appuient sur le runtime, oubliant complètement les lois physiques, qui restent impossibles à contourner à l'aide de programmes. Cela inclut la fiabilité infinie du sous-système de disque et, en général, de tout sous-système de stockage de données (y compris la RAM et le cache du processeur !), le temps de traitement nul sur le processeur et l'absence d'erreurs lors de la transmission sur le réseau et lors du traitement sur le processeur et la latence du réseau, qui est égale à 0. Il ne faut pas négliger le fameux délai, car si vous ne le respectez pas à temps, des problèmes pires que les nuances du fonctionnement du réseau et du disque surviendront.

Que faire des problèmes qui surgissent de plein fouet et pèsent sur des données précieuses ? Rien ne remplace les développeurs vivants, et ce n’est pas un fait que cela sera possible dans un avenir proche. D’un autre côté, seuls quelques projets ont réussi à prouver pleinement que le programme fonctionnera comme prévu, et il ne sera pas nécessairement possible de prendre en compte et d’appliquer ces preuves à d’autres projets similaires. En outre, de telles preuves prennent beaucoup de temps et nécessitent des compétences et des connaissances particulières, ce qui minimise pratiquement la possibilité de leur utilisation compte tenu des délais. De plus, nous ne savons pas encore utiliser une technologie ultra-rapide, bon marché et infiniment fiable pour stocker, traiter et transmettre l’information. Ces technologies, si elles existent, se présentent sous la forme de concepts ou – le plus souvent – ​​uniquement dans des livres et des films de science-fiction.

Les bons artistes copient les grands artistes volent.

-Pablo Picasso.

Les solutions les plus efficaces et les choses étonnamment simples se produisent généralement là où se rencontrent des concepts, des technologies, des connaissances et des domaines scientifiques qui, à première vue, sont absolument incompatibles.

Par exemple, les oiseaux et les avions ont des ailes, mais malgré la similitude fonctionnelle, le principe de fonctionnement dans certains modes est le même et les problèmes techniques sont résolus de la même manière : os creux, utilisation de matériaux solides et légers, etc. les résultats sont complètement différents, bien que très similaires. Les meilleurs exemples que nous voyons dans notre technologie sont également largement empruntés à la nature : les compartiments pressurisés des navires et des sous-marins sont une analogie directe avec les annélides ; construire des matrices de raid et vérifier l'intégrité des données - dupliquer la chaîne d'ADN ; ainsi que des organes appariés, l'indépendance du travail des différents organes du système nerveux central (automatisation du cœur) et des réflexes - systèmes autonomes sur Internet. Bien sûr, adopter et appliquer de front des solutions toutes faites pose de nombreux problèmes, mais qui sait, peut-être qu’il n’y a pas d’autres solutions.

Si seulement j'avais su où tu tomberais, j'aurais disposé des pailles !

—Proverbe populaire biélorusse

Cela signifie que les copies de sauvegarde sont vitales pour ceux qui souhaitent :

• Être capable de restaurer le fonctionnement de vos systèmes avec un temps d'arrêt minimal, voire même sans aucun temps d'arrêt
• Agissez avec audace, car en cas d'erreur, il y a toujours la possibilité d'un retour en arrière
• Minimiser les conséquences de la corruption intentionnelle des données

Voici une petite théorie

Toute classification est arbitraire. La nature ne classe pas. Nous classons parce que c'est plus pratique pour nous. Et nous classons selon des données que nous prenons également arbitrairement.

—Jean Brûler

Quelle que soit la méthode de stockage physique, le stockage logique des données peut être divisé en deux manières d'accéder à ces données : par bloc et par fichier. Cette division est récemment devenue très floue, car le stockage logique purement en bloc, ni purement en fichiers, n'existe pas. Cependant, par souci de simplicité, nous supposerons qu'ils existent.

Le stockage de données par blocs implique qu'il existe un périphérique physique sur lequel les données sont écrites dans certaines parties fixes, des blocs. Les blocs sont accessibles à une certaine adresse ; chaque bloc a sa propre adresse dans l’appareil.

Une sauvegarde est généralement effectuée en copiant des blocs de données. Pour garantir l'intégrité des données, l'enregistrement des nouveaux blocs, ainsi que les modifications apportées aux blocs existants, sont suspendus au moment de la copie. Si nous prenons une analogie avec le monde ordinaire, la chose la plus proche est un placard avec des cellules numérotées identiques.

Le stockage de données de fichiers basé sur le principe du périphérique logique est proche du stockage en bloc et est souvent organisé par-dessus. Les différences importantes sont la présence d'une hiérarchie de stockage et de noms lisibles par l'homme. Une abstraction est attribuée sous la forme d'un fichier - une zone de données nommée, ainsi que d'un répertoire - un fichier spécial dans lequel sont stockés les descriptions et l'accès à d'autres fichiers. Les fichiers peuvent être fournis avec des métadonnées supplémentaires : heure de création, indicateurs d'accès, etc. Les sauvegardes sont généralement effectuées de cette manière : elles recherchent les fichiers modifiés, puis les copient vers un autre stockage de fichiers avec la même structure. L'intégrité des données est généralement mise en œuvre par l'absence de fichiers en cours d'écriture. Les métadonnées des fichiers sont sauvegardées de la même manière. L’analogie la plus proche est celle d’une bibliothèque, qui comporte des sections contenant différents livres, ainsi qu’un catalogue avec des noms de livres lisibles par l’homme.

Récemment, une autre option est parfois décrite, à partir de laquelle, en principe, est né le stockage de données de fichiers, et qui présente les mêmes caractéristiques archaïques : le stockage de données objet.

Il diffère du stockage de fichiers en ce sens qu'il ne comporte pas plus d'une imbrication (schéma plat) et que les noms de fichiers, bien que lisibles par l'homme, sont néanmoins plus adaptés au traitement par des machines. Lors de l'exécution de sauvegardes, le stockage d'objets est le plus souvent traité de la même manière que le stockage de fichiers, mais il existe parfois d'autres options.

— Il existe deux types d'administrateurs système, ceux qui ne font pas de sauvegardes et ceux qui le font DÉJÀ.
- En fait, il y en a trois types : il y a aussi ceux qui vérifient que les sauvegardes peuvent être restaurées.

-Inconnu

Il convient également de comprendre que le processus de sauvegarde des données lui-même est effectué par des programmes et présente donc les mêmes inconvénients que tout autre programme. Pour supprimer (et non éliminer !) la dépendance à l'égard du facteur humain, ainsi que les caractéristiques - qui individuellement n'ont pas d'effet important, mais qui, ensemble, peuvent donner un effet notable - ce qu'on appelle règle 3-2-1. Il existe de nombreuses options pour le déchiffrer, mais je préfère l'interprétation suivante : 3 ensembles des mêmes données doivent être stockés, 2 ensembles doivent être stockés dans des formats différents et 1 ensemble doit être stocké dans un stockage géographiquement distant.

Le format de stockage doit être compris comme suit :

• S'il y a une dépendance à la méthode de stockage physique, nous changeons de méthode physique.
• S'il existe une dépendance à la méthode de stockage logique, nous changeons de méthode logique.

Pour obtenir l'effet maximal de la règle 3-2-1, il est recommandé de modifier le format de stockage dans les deux sens.

Du point de vue de l'état de préparation d'une sauvegarde pour son objectif prévu - restauration de la fonctionnalité - une distinction est faite entre les sauvegardes « à chaud » et « à froid ». Les chauds ne diffèrent des froids que sur une chose : ils sont immédiatement prêts à l'emploi, tandis que les froids nécessitent quelques étapes supplémentaires de récupération : décryptage, extraction de l'archive, etc.

Ne confondez pas les copies à chaud et à froid avec les copies en ligne et hors ligne, qui impliquent un isolement physique des données et, en fait, sont un autre signe de classification des méthodes de sauvegarde. Ainsi, une copie hors ligne - qui n'est pas directement connectée au système où elle doit être restaurée - peut être chaude ou froide (en termes de préparation à la récupération). Une copie en ligne peut être disponible directement là où elle doit être restaurée, et le plus souvent elle est chaude, mais il en existe aussi des froides.

De plus, n'oubliez pas que le processus de création de copies de sauvegarde lui-même ne se termine généralement pas par la création d'une copie de sauvegarde et qu'il peut y avoir un assez grand nombre de copies. Il faut donc faire la distinction entre les sauvegardes complètes, c'est-à-dire celles qui peuvent être restaurées indépendamment des autres sauvegardes, ainsi que les copies différentielles (incrémentales, différentielles, décrémentales, etc.) - celles qui ne peuvent pas être restaurées indépendamment et nécessitent la restauration préalable d'une ou plusieurs autres sauvegardes.

Les sauvegardes incrémentielles différentielles constituent une tentative d'économiser de l'espace de stockage de sauvegarde. Ainsi, seules les données modifiées de la sauvegarde précédente sont écrites sur la copie de sauvegarde.

Les décrémentations différentielles sont créées dans le même but, mais d'une manière légèrement différente : une copie de sauvegarde complète est effectuée, mais seule la différence entre la nouvelle copie et la précédente est réellement stockée.

Séparément, il convient de considérer le processus de sauvegarde sur stockage, qui prend en charge l'absence de stockage de doublons. Ainsi, si vous écrivez des sauvegardes complètes par-dessus, seules les différences entre les sauvegardes seront réellement écrites, mais le processus de restauration des sauvegardes sera similaire à la restauration à partir d'une copie complète et totalement transparent.

Quis custodiet ipsos custodes ?

(Qui gardera les gardiens eux-mêmes ? - lat.)

C'est très désagréable lorsqu'il n'y a pas de copies de sauvegarde, mais c'est bien pire si une copie de sauvegarde semble avoir été faite, mais lors de la restauration, il s'avère qu'elle ne peut pas être restaurée car :

• L'intégrité des données sources a été compromise.
• Le stockage de sauvegarde est endommagé.
• La restauration fonctionne très lentement, vous ne pouvez pas utiliser les données partiellement récupérées.

Un processus de sauvegarde correctement construit doit prendre en compte ces commentaires, en particulier les deux premiers.

L'intégrité des données sources peut être garantie de plusieurs manières. Les plus couramment utilisés sont les suivants : a) créer des instantanés du système de fichiers au niveau du bloc, b) « geler » l'état du système de fichiers, c) un périphérique de bloc spécial avec stockage de versions, d) l'enregistrement séquentiel de fichiers ou blocs. Des sommes de contrôle sont également appliquées pour garantir que les données sont vérifiées pendant la récupération.

La corruption du stockage peut également être détectée à l’aide de sommes de contrôle. Une méthode supplémentaire consiste à utiliser des appareils ou des systèmes de fichiers spécialisés dans lesquels les données déjà enregistrées ne peuvent pas être modifiées, mais de nouvelles peuvent être ajoutées.

Pour accélérer la récupération, la récupération des données est utilisée avec plusieurs processus de récupération - à condition qu'il n'y ait pas de goulot d'étranglement sous la forme d'un réseau lent ou d'un système de disque lent. Pour contourner la situation des données partiellement récupérées, vous pouvez diviser le processus de sauvegarde en sous-tâches relativement petites, chacune étant effectuée séparément. Ainsi, il devient possible de restaurer systématiquement les performances tout en prédisant le temps de récupération. Ce problème réside le plus souvent au niveau du plan organisationnel (SLA), nous ne nous y attarderons donc pas en détail.

Un expert en épices n’est pas celui qui en ajoute à chaque plat, mais celui qui n’y ajoute jamais rien de plus.

-DANS. Siniavski

Les pratiques concernant les logiciels utilisés par les administrateurs système peuvent varier, mais les principes généraux restent, d'une manière ou d'une autre, les mêmes, notamment :

• Il est fortement recommandé d'utiliser des solutions toutes faites.
• Les programmes doivent fonctionner de manière prévisible, c'est-à-dire Il ne devrait y avoir aucune fonctionnalité ou goulot d’étranglement non documenté.
• La configuration de chaque programme doit être si simple que vous n'avez pas besoin de lire le manuel ou l'aide-mémoire à chaque fois.
• Si possible, la solution devrait être universelle, car les caractéristiques matérielles des serveurs peuvent varier considérablement.

Il existe les programmes courants suivants pour effectuer des sauvegardes à partir de périphériques bloqués :

• dd, familier aux vétérans de l'administration système, cela inclut également des programmes similaires (le même dd_rescue, par exemple).
• Utilitaires intégrés à certains systèmes de fichiers qui créent un dump du système de fichiers.
• Utilitaires omnivores ; par exemple partclone.
• Décisions propres, souvent exclusives ; par exemple, NortonGhost et versions ultérieures.

Pour les systèmes de fichiers, le problème de sauvegarde est partiellement résolu en utilisant des méthodes applicables aux périphériques bloc, mais le problème peut être résolu plus efficacement en utilisant, par exemple :

• Rsync, un programme et un protocole à usage général pour synchroniser l'état des systèmes de fichiers.
• Outils d'archivage intégrés (ZFS).
• Outils d'archivage tiers ; le représentant le plus populaire est le goudron. Il y en a d'autres, par exemple Dar - un remplacement de tar destiné aux systèmes modernes.

Il convient de mentionner séparément les outils logiciels permettant d'assurer la cohérence des données lors de la création de copies de sauvegarde. Les options les plus couramment utilisées sont :

• Monter le système de fichiers en mode lecture seule (ReadOnly) ou geler le système de fichiers (freeze) - la méthode est d'applicabilité limitée.
• Création d'instantanés de l'état des systèmes de fichiers ou des périphériques de bloc (LVM, ZFS).
• L'utilisation d'outils tiers pour organiser les impressions, même dans les cas où les points précédents ne peuvent pas être fournis pour une raison quelconque (programmes comme hotcopy).
• La technique de copie sur modification (CopyOnWrite), cependant, est le plus souvent liée au système de fichiers utilisé (BTRFS, ZFS).

Ainsi, pour un petit serveur, vous devez fournir un schéma de sauvegarde qui répond aux exigences suivantes :

• Facile à utiliser - aucune étape supplémentaire particulière n'est requise pendant le fonctionnement, des étapes minimes pour créer et restaurer des copies.
• Universel – fonctionne aussi bien sur les grands que sur les petits serveurs ; c’est important à mesure que le nombre de serveurs augmente. les serveurs ou mise à l'échelle.
• Installé par un gestionnaire de packages, ou en une ou deux commandes comme « télécharger et décompresser ».
• Stable - un format de stockage standard ou établi de longue date est utilisé.
• Rapide au travail.

Les candidats parmi ceux qui répondent plus ou moins aux exigences :

• rdiff-sauvegarde
• instantané
• rot
• duplicata
• duplicité
• laissez dup
• donner
• zsauvegarde
• restique
• sauvegarde borg

Une machine virtuelle (basée sur XenServer) présentant les caractéristiques suivantes servira de banc de test :

• 4 cœurs 2.5 GHz,
• 16 Go de RAM,
• Stockage hybride de 50 Go (système de stockage avec mise en cache sur SSD 20% de la taille du disque virtuel) sous forme de disque virtuel séparé sans partitionnement,
• Canal Internet 200 Mbps.

Presque la même machine sera utilisée comme serveur récepteur de secours, uniquement avec un disque dur de 500 Go.

Système opérateur - Centos 7 x64 : partitionnement standard, une partition supplémentaire sera utilisée comme source de données.

Comme données de départ, nous utiliserons un site WordPress avec 40 Go de fichiers multimédias et une base de données MySQL. Serveurs virtuels leurs caractéristiques diffèrent considérablement, et pour une meilleure reproductibilité, il existe

résultats des tests du serveur à l'aide de sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 exécution du processeur
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3 fourni)
Exécution du test avec les options suivantes:
Nombre de threads: 4
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Limite des nombres premiers : 20000 XNUMX

Initialisation des threads de travail…

Les discussions ont commencé!

Vitesse CPU:
événements par seconde : 836.69

Débit:
événements/s (eps): 836.6908
temps écoulé : 30.0039s
nombre total d'événements : 25104

Latence (ms) :
min : 2.38
moyenne : 4.78
max : 22.39
95e centile : 10.46
somme: 119923.64

Équité des threads:
événements (moy/stddev) : 6276.0000/13.91
temps d'exécution (moyenne/stddev) : 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=lire la mémoire exécutée
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3 fourni)
Exécution du test avec les options suivantes:
Nombre de threads: 4
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Exécution d'un test de vitesse de mémoire avec les options suivantes :
taille du bloc : 1 Ko
taille totale : 102400 XNUMX Mo
opération : lire
portée : mondiale

Initialisation des threads de travail…

Les discussions ont commencé!

Opérations totales : 50900446 (1696677.10 par seconde)

49707.47 1656.91 Mio transférés (XNUMX XNUMX Mio/sec)

Débit:
événements/s (eps): 1696677.1017
temps écoulé : 30.0001s
nombre total d'événements : 50900446

Latence (ms) :
min : 0.00
moyenne : 0.00
max : 24.01
95e centile : 0.00
somme: 39106.74

Équité des threads:
événements (moy/stddev) : 12725111.5000/137775.15
temps d'exécution (moyenne/stddev) : 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=écriture de la mémoire
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3 fourni)
Exécution du test avec les options suivantes:
Nombre de threads: 4
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Exécution d'un test de vitesse de mémoire avec les options suivantes :
taille du bloc : 1 Ko
taille totale : 102400 XNUMX Mo
opération : écrire
portée : mondiale

Initialisation des threads de travail…

Les discussions ont commencé!

Opérations totales : 35910413 (1197008.62 par seconde)

35068.76 1168.95 Mio transférés (XNUMX XNUMX Mio/sec)

Débit:
événements/s (eps): 1197008.6179
temps écoulé : 30.0001s
nombre total d'événements : 35910413

Latence (ms) :
min : 0.00
moyenne : 0.00
max : 16.90
95e centile : 0.00
somme: 43604.83

Équité des threads:
événements (moy/stddev) : 8977603.2500/233905.84
temps d'exécution (moyenne/stddev) : 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3 fourni)
Exécution du test avec les options suivantes:
Nombre de threads: 4
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Indicateurs d'ouverture de fichier supplémentaire : (aucun)
128 fichiers, 8 Mo chacun
Taille totale du fichier de 1 Go
Taille du bloc 4 Ko
Nombre de requêtes IO : 0
Rapport lecture/écriture pour le test IO aléatoire combiné : 1.50
FSYNC périodique activé, appelant fsync() toutes les 100 requêtes.
Appel de fsync() à la fin du test, activé.
Utilisation du mode E/S synchrone
Faire un test r/w aléatoire
Initialisation des threads de travail…

Les discussions ont commencé!

Débit:
lire : IOPS = 3868.21 15.11 15.84 Mio/s (XNUMX Mo/s)
écriture : IOPS=2578.83 10.07 10.56 Mio/s (XNUMX Mo/s)
fsync : IOPS = 8226.98 XNUMX

Latence (ms) :
min : 0.00
moyenne : 0.27
max : 18.01
95e centile : 1.08
somme: 238469.45

Cette note commence un grand

série d'articles sur la sauvegarde

1. Sauvegarde, partie 1 : pourquoi la sauvegarde est nécessaire, un aperçu des méthodes, des technologies
2. Sauvegarde Partie 2 : Examiner et tester les outils de sauvegarde basés sur rsync
3. Sauvegarde Partie 3 : Examiner et tester la duplicité, la duplication, déjà dup
4. Sauvegarde Partie 4 : Examen et test de zbackup, restic, borgbackup
5. Sauvegarde Partie 5 : Tester la sauvegarde bacula et veeam pour Linux
6. Sauvegarde Partie 6 : Comparaison des outils de sauvegarde
7. Sauvegarde Partie 7 : Conclusions

Source: habr.com