Pourquoi faut-il faire des sauvegardes ? L'équipement est en effet très fiable, et il existe aussi des "nuages" qui sont plus fiables que les serveurs physiques : avec une bonne configuration, un serveur "cloud" peut facilement survivre à une panne du serveur physique, et pour les utilisateurs des services, il y aura une légère, à peine perceptible, augmentation du temps de service. De plus, la duplication d'informations nécessite souvent de payer pour un "température" processeur supplémentaire, une charge de disque, et du trafic réseau.
Un programme idéal fonctionne rapidement, ne fuit pas la mémoire vive, n'a pas de failles et n'existe pas.
—Inconnu
Puisque les programmes sont encore écrits par des développeurs, et que le processus de test est souvent absent, de plus, la livraison des programmes se fait très rarement selon des "meilleures pratiques" (qui sont elles-mêmes des programmes, et donc imparfaits), les administrateurs systèmes doivent le plus souvent résoudre des problèmes qui sont formulés de manière concise, mais évocatrice : «retourner à l'état précédent», «ramener la base à un fonctionnement normal», «ça fonctionne lentement — on revient en arrière», ainsi que ma préférée, «je ne sais pas quoi, mais réparez cela».
En dehors des erreurs logiques qui apparaissent en raison du travail négligent des développeurs, ou de circonstances, ainsi que d'une connaissance ou d'une compréhension incomplète des subtilités des programmes — y compris ceux qui sont liés aux systèmes, incluant les systèmes d'exploitation, les pilotes et les firmwares — il existe aussi d'autres erreurs. Par exemple, la majorité des développeurs comptent sur le runtime, oubliant complètement les lois physiques, qu'il est encore impossible de contourner par des programmes. Cela inclut la fiabilité infinie des sous-systèmes de disques et de tout sous-système de stockage de données (y compris la mémoire vive et le cache du processeur !), un temps de traitement nul sur le processeur, aucune erreur lors de la transmission sur le réseau ou lors du traitement sur le processeur, et des délais réseau égaux à 0. Il ne faut pas négliger le fameux délai, car si l’on ne respecte pas celui-ci, des problèmes dépasseront de loin les subtilités du fonctionnement du réseau et du disque.
Que faire face aux problèmes qui surgissent brusquement et menacent des données précieuses ? Il est impossible de remplacer des développeurs vivants, et il n'est même pas certain qu'on pourra le faire dans un avenir proche. D'autre part, prouver que le programme fonctionnera comme prévu n'a été réalisé que par quelques projets, et il n'est pas forcément garanti que ces preuves puissent être utilisées pour d'autres projets similaires. De plus, ces preuves prennent énormément de temps et nécessitent des compétences et des connaissances particulières, ce qui minimise pratiquement leur applicabilité compte tenu des délais. De surcroît, nous n'avons pas encore maîtrisé la technologie de stockage, de traitement et de transmission de l'information qui soit ultra-rapide, peu coûteuse et infiniment fiable. De telles technologies, si elles existent, le sont sous forme de concepts, ou - plus souvent - seulement dans des livres et films de science-fiction.
Les bons artistes copient, les grands artistes volent.
—Pablo Picasso.
Les solutions les plus réussies et les choses étonnamment simples se produisent généralement là où se rencontrent des concepts, technologies, savoirs, domaines scientifiques apparemment complètement incompatibles.
Par exemple, les oiseaux et les avions ont des ailes, mais malgré leur similitude fonctionnelle — le principe de fonctionnement coïncide dans certains modes, et les problèmes techniques sont résolus de manière similaire : os creux, utilisation de matériaux résistants et légers, etc. — les résultats sont absolument différents, même s'ils sont très semblables. Les meilleurs exemples que nous observons dans notre technologie sont également pour la plupart empruntés à la nature : compartiments étanches pour les navires et sous-marins — une analogie directe avec les vers annelés ; constitution de tableaux raid et vérification de l'intégrité des données — duplication de la chaîne ADN ; ainsi que des organes pairs, l'indépendance de la fonction de différents organes vis-à-vis du système nerveux central (automatisme du travail du cœur) et les réflexes — systèmes autonomes sur Internet. Certes, prendre et appliquer des solutions prêtes à l'emploi peut être source de problèmes, mais qui sait, peut-être qu'il n'y a pas d'autres solutions.
Si seulement je savais où je tomberais, je mettrais des paillettes !
—Proverbe populaire biélorusse.
Ainsi, des sauvegardes sont vitales pour ceux qui souhaitent :
- Avoir la possibilité de restaurer le fonctionnement de leurs systèmes avec un minimum d'interruptions, voire sans interruptions.
- Agissez sans crainte, car en cas d'erreur, il y a toujours la possibilité d'un retour en arrière.
- Minimiser les conséquences de la dégradation intentionnelle des données.
Voici un peu de théorie.
Toute classification est arbitraire. La nature ne classe pas. Nous classons parce que c'est plus pratique pour nous, et nous le faisons en nous basant sur des données que nous choisissons également de manière arbitraire.
— Jean Bruyère
Quel que soit le moyen de stockage physique, le stockage logique des données peut être grossièrement divisé selon 2 modes d'accès à ces données : par blocs ou par fichiers. Cette division est devenue assez floue ces derniers temps, car il n'existe pas de systèmes de stockage purement block ou purement file. Cependant, pour simplifier, nous considérerons qu'ils existent.
Le stockage de données par blocs signifie qu'il existe un dispositif physique où les données sont enregistrées par portions fixes, appelées blocs. L'accès aux blocs se fait selon une certaine adresse, chaque bloc ayant sa propre adresse dans le dispositif.
Une sauvegarde est généralement réalisée par la copie des blocs de données. Pour garantir l'intégrité des données au moment de la copie, l'enregistrement de nouveaux blocs ainsi que la modification des blocs existants sont suspendus. Pour prendre une analogie du monde réel : la plus proche est une armoire avec des compartiments numérotés identiquement.
Le stockage de données par fichiers, en raison de son principe de dispositif logique, est proche du stockage par blocs et est souvent organisé en superposition. Les différences importantes sont la présence d'une hiérarchie de stockage et des noms compréhensibles pour l'homme. Une abstraction sous forme de fichier est mise en évidence - une zone de données nommée, ainsi qu'un répertoire - un fichier spécial contenant des descriptions et des accès à d'autres fichiers. Les fichiers peuvent être dotés de métadonnées supplémentaires : date de création, drapeaux d'accès, etc. En général, la sauvegarde se fait ainsi : les fichiers modifiés sont recherchés, puis copiés dans un autre espace de stockage de fichiers ayant une structure identique. L'intégrité des données est généralement réalisée par l'absence de fichiers en cours d'enregistrement. Les métadonnées des fichiers sont sauvegardées de la même manière. L'analogie la plus proche est une bibliothèque, où il y a des sections avec différents livres, ainsi qu'un catalogue avec des noms de livres compréhensibles.
Dernièrement, une autre variante a été décrite, celle qui a en fait marqué le début du stockage de fichiers et qui possède les mêmes caractéristiques archaïques : le stockage d'objets.
Il se distingue du stockage de fichiers en ce sens qu'il n'a pas de profondeur de hiérarchie supérieure à un (schéma plat), et bien que les noms de fichiers soient lisibles par l'homme, ils sont davantage conçus pour le traitement par des machines. Lors des sauvegardes, les systèmes de stockage d'objets sont généralement traités de la même manière que les systèmes de fichiers, bien qu'il existe parfois d'autres options.
— Il y a deux types d'administrateurs systèmes, ceux qui ne font pas de sauvegardes, et ceux qui en font déjà.
— En réalité, il y a trois types : il y a aussi ceux qui vérifient que les sauvegardes peuvent être restaurées.—Inconnu
Il est également important de comprendre que le processus de sauvegarde des données est réalisé par des programmes, et qu'il présente donc tous les mêmes inconvénients qu'un autre programme. Pour éliminer (pas exclure !) la dépendance au facteur humain, ainsi qu'à certaines particularités — qui à elles seules n'ont pas un grand impact, mais qui ensemble peuvent avoir un effet significatif — on applique ce qu'on appelle la règle 3-2-1. Il existe de nombreuses interprétations de cela, mais je préfère celle-ci : il faut conserver 3 ensembles des mêmes données, 2 de ces ensembles doivent être conservés dans différents formats, et 1 ensemble doit être stocké dans un emplacement géographiquement éloigné.
Par format de stockage, on entend ce qui suit :
- S'il existe une dépendance au moyen physique de stockage, on change le moyen physique.
- S'il existe une dépendance au moyen logique de stockage, on change le moyen logique.
Pour maximiser l'effet de la règle 3-2-1, il est recommandé de changer le format de stockage par les deux méthodes.
En termes de disponibilité de la sauvegarde pour son but principal — la restauration de la fonctionnalité — on distingue les sauvegardes « chaudes » et « froides ». Les sauvegardes chaudes se distinguent des froides par un seul point : elles sont immédiatement prêtes à être utilisées, tandis que les sauvegardes froides nécessitent des actions supplémentaires pour la restauration : décryptage, extraction de l'archive, etc.
Il ne faut pas confondre les copies chaudes et froides avec les copies en ligne et hors ligne, qui impliquent une isolation physique des données et constituent en réalité un autre critère de classification des méthodes de sauvegarde. Ainsi, une copie hors ligne – non connectée directement au système où elle doit être restaurée – peut être à la fois chaude et froide (en termes de préparation à la restauration). Une copie en ligne peut être accessible directement là où elle doit être restaurée et est le plus souvent chaude, bien qu'il existe aussi des copies froides.
De plus, il ne faut pas oublier que le processus de création de sauvegardes ne se limite généralement pas à la création d'une seule sauvegarde, et qu'il peut y avoir un nombre considérable de copies. Par conséquent, il est nécessaire de distinguer 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 par elles-mêmes et nécessitent la restauration préalable d'une ou plusieurs autres sauvegardes.
Les copies incrémentales différentielles tentent d'économiser de l'espace de stockage pour les sauvegardes. Ainsi, seules les données modifiées depuis la dernière sauvegarde sont écrites dans la nouvelle sauvegarde.
Les copies décrémentales différentielles sont créées avec le même objectif, mais par un moyen légèrement différent : une sauvegarde complète est réalisée, mais seule la différence entre la copie fraîche et la précédente est réellement conservée.
Il convient d'examiner séparément le processus de sauvegarde sur un stockage qui prend en charge l'absence de stockage de doublons. Ainsi, si l'on écrit des sauvegardes complètes dessus, seule la différence entre les sauvegardes sera réellement enregistrée, cependant le processus de restauration des sauvegardes se déroulera de manière similaire à la restauration à partir d'une sauvegarde complète et sera totalement transparent.
Quis custodiet ipsos custodes?
(Qui gardera les gardiens eux-mêmes ? — latin)
Il est très désagréable de ne pas avoir de sauvegardes, mais il est encore pire de constater qu'une sauvegarde a été réalisée, mais qu'elle ne peut pas être restaurée car :
- L'intégrité des données d'origine a été compromise.
- Le stockage des sauvegardes est endommagé.
- La récupération fonctionne de manière plutôt lente, il n'est pas possible d'utiliser des données qui ont été partiellement récupérées.
Un processus de sauvegarde correctement conçu doit tenir compte de telles remarques, en particulier les deux premières.
L'intégrité des données d'origine peut être garantie de plusieurs manières. Les plus couramment utilisées sont : a) la création de snapshots de système de fichiers au niveau bloc, b) la "congélation" de l'état du système de fichiers, c) un dispositif de bloc spécial avec stockage de versions, d) l'écriture séquentielle de fichiers ou de blocs. Des sommes de contrôle sont également utilisées pour assurer la vérification des données lors de la récupération.
Les dommages au stockage peuvent également être détectés à l'aide de sommes de contrôle. Une méthode supplémentaire consiste à utiliser des dispositifs spécialisés ou des systèmes de fichiers 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, un processus de récupération de données avec plusieurs processus peut être utilisé, à condition qu'il n'y ait pas de "goulot d'étranglement" tel qu'un réseau lent ou un système de disque non rapide. Pour éviter la situation avec des données partiellement récupérées, il est possible de diviser le processus de sauvegarde en sous-tâches relativement petites, chacune étant exécutée séparément. Cela permet de restaurer la fonctionnalité de manière séquentielle tout en prévoyant le temps de récupération. Ce problème réside le plus souvent dans le domaine organisationnel (SLA), donc nous ne nous attarderons pas sur ce point.
Connaître les épices ne signifie pas les ajouter à chaque plat, mais plutôt ne jamais ajouter quoi que ce soit de superflu.
—V. Sinyavsky
La pratique en ce qui concerne les logiciels utilisés par les administrateurs système peut varier, mais les principes généraux restent les mêmes, notamment :
- Il est fortement recommandé d'utiliser des solutions prêtes à l'emploi.
- Les programmes doivent fonctionner de manière prévisible, c'est-à-dire qu'il ne doit pas y avoir de particularités non documentées ou de goulets d'étranglement.
- La configuration de chaque programme doit être suffisamment simple pour que l'on ne soit pas obligé de lire le manuel ou une note de rappel à chaque fois.
- La solution doit être aussi universelle que possible, car les serveurs peuvent varier considérablement en termes de caractéristiques matérielles.
Les programmes les plus répandus pour effectuer des sauvegardes à partir de périphériques en mode bloc sont les suivants :
- dd, bien connue des vétérans de l'administration système, ainsi que d'autres programmes similaires (comme dd_rescue, par exemple).
- Des programmes intégrés à certains systèmes de fichiers qui créent une image (dump) du système de fichiers.
- Des utilitaires polyvalents ; par exemple, partclone.
- Des solutions propriétaires, souvent exclusives ; par exemple, NortonGhost et ses versions plus récentes.
Pour les systèmes de fichiers, la sauvegarde est en partie gérée par des méthodes applicables aux périphériques en mode bloc, mais elle peut aussi être résolue de manière plus efficace en utilisant, par exemple :
- Rsync, un programme et un protocole universels pour la synchronisation des états des systèmes de fichiers.
- Les outils intégrés pour l'archivage (ZFS).
- Des outils tiers pour l'archivage ; le plus populaire étant tar. Il en existe d'autres, comme dar — un remplacement de tar orienté vers les systèmes modernes.
Il est également important de mentionner les outils logiciels assurant la cohérence des données lors de la création de sauvegardes. 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) — méthode applicable de manière limitée.
- Créer des instantanés de l'état des systèmes de fichiers ou des dispositifs en mode bloc (LVM, ZFS).
- Utiliser des outils tiers pour organiser des instantanés, même lorsqu'il est impossible de garantir les points précédents pour des raisons diverses (programmes de type hotcopy).
- La technique de copie lors de la modification (CopyOnWrite), mais elle est le plus souvent liée au système de fichiers utilisé (BTRFS, ZFS).
Ainsi, pour un petit serveur, il est nécessaire de mettre en place un schéma de sauvegarde répondant aux exigences suivantes :
- Facile à utiliser — aucune action particulière n'est requise lors de l'utilisation, avec des actions minimales pour créer et restaurer des copies.
- Universelle — fonctionne aussi bien sur de grands que sur de petits serveurs ; cela est important lors de l'augmentation du nombre serveurs ou de l'échelonnement.
- Elle peut être installée via un gestionnaire de paquets, ou en une à deux commandes de type « télécharger et décompresser ».
- Stable — utilise un format de stockage standard ou déjà bien établi.
- Rapide dans son fonctionnement.
Les candidats qui répondent plus ou moins aux exigences :
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
Un serveur virtuel (basé sur XenServer) avec les caractéristiques suivantes sera utilisé comme banc d'essai :
- 4 cœurs à 2,5 GHz,
- 16 Go de RAM,
- 50 Go de stockage hybride (stockage avec cache SSD représentant 20 % de la taille du disque virtuel) sous forme de disque virtuel séparé sans partitionnement,
- un canal Internet de 200 Mbit/s.
Pour le serveur récepteur des sauvegardes, une machine pratiquement identique sera utilisée, mais avec un disque dur de 500 Go.
Système d'exploitation — Centos 7 x64 : structure standard, une partition supplémentaire sera utilisée comme source de données.
Comme données sources, nous prendrons un site WordPress avec des fichiers multimédias de 40 Go et une base de données MySQL. Étant donné que des serveurs virtuels les caractéristiques varient considérablement, et pour une meilleure reproductibilité, ici se trouvent
les résultats des tests du serveur à l'aide de sysbench.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3)
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
Initialisation des threads de travail…
Threads démarrés !
Vitesse du processeur :
événements par seconde : 836,69
Débit :
événements/s (eps) : 836,6908
temps écoulé : 30,0039 s
nombre total d'événements : 25104
Latence (ms) :
min : 2,38
moy : 4,78
max : 22,39
95ème percentile : 10,46
somme : 119923,64
Équité des threads :
événements (moy/écart-type) : 6276,0000/13,91
temps d'exécution (moy/écart-type) : 29,9809/0,01
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=read memory run
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3)
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 du test de vitesse mémoire avec les options suivantes :
taille de bloc : 1Ko
taille totale : 102400MiB
opération : lecture
portée : globale
Initialisation des threads de travail…
Threads démarrés !
Nombre total d'opérations : 50900446 (1696677,10 par seconde)
49707,47 MiB transférés (1656,91 MiB/sec)
Débit :
événements/s (eps) : 1696677,1017
temps écoulé : 30,0001 s
nombre total d'événements : 50900446
Latence (ms) :
min : 0,00
moy : 0,00
max : 24,01
95ème percentile : 0,00
somme : 39106,74
Équité des threads :
événements (moy/écart-type) : 12725111,5000/137775,15
temps d'exécution (moy/écart-type) : 9,7767/0,10
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (utilisant LuaJIT 2.1.0-beta3)
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 du test de vitesse mémoire avec les options suivantes :
taille de bloc : 1Ko
taille totale : 102400MiB
opération : écriture
portée : globale
Initialisation des threads de travail…
Threads démarrés !
Nombre total d'opérations : 35910413 (1197008,62 par seconde)
35068,76 MiB transférés (1168,95 MiB/sec)
Débit :
événements/s (eps) : 1197008,6179
temps écoulé : 30,0001 s
nombre total d'événements : 35910413
Latence (ms) :
min : 0,00
moy : 0,00
max : 16,90
95ème percentile : 0,00
somme : 43604,83
Équité des threads :
événements (moy/écart-type) : 8977603,2500/233905,84
temps d'exécution (moy/écart-type) : 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)
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
Drapeaux d'ouverture de fichiers supplémentaires : (aucun)
128 fichiers, 8MiB chacun
Taille totale des fichiers : 1Go
Taille de bloc 4Ko
Nombre de requêtes d'E/S : 0
Ratio de lecture/écriture pour le test d'E/S aléatoire combiné : 1,50
FSYNC périodique activé, appelant fsync() tous les 100 requêtes.
Appel à fsync() à la fin du test, activé.
Mode I/O synchrone utilisé
Réalisation d'un test d'E/S aléatoire
Initialisation des threads de travail…
Threads démarrés !
Débit :
lecture : IOPS=3868,21 15,11 MiB/s (15,84 Mo/s)
écrire : IOPS=2578.83 10.07 MiB/s (10.56 Mo/s)
fsync : IOPS=8226.98
Latence (ms) :
min : 0,00
moy : 0.27
max : 18.01
95e percentile : 1.08
somme : 238469.45
Cet article marque le début d'une
série d'articles sur la sauvegarde
- Sauvegarde, partie 1 : Pourquoi faire des sauvegardes, aperçu des méthodes et technologies
- Sauvegarde, partie 2 : Revue et test des outils de sauvegarde basés sur rsync
- Sauvegarde, partie 3 : Aperçu et test de duplicity, duplicaty, deja dup
- Sauvegarde, partie 4 : Aperçu et test de zbackup, restic, borgbackup
- Sauvegarde, partie 5 : Test de bacula et veeam backup for linux
- Sauvegarde, partie 6 : Comparaison des outils de sauvegarde
- Sauvegarde, partie 7 : Conclusions
Source : habr.com
