Cette note poursuit
le cycle sur la sauvegarde
- Sauvegarde, partie 2 : Aperçu 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
Comme nous l'avons déjà mentionné dans le premier article, il existe un grand nombre de programmes de sauvegarde basés sur rsync.
Parmi ceux qui conviennent le mieux à nos conditions, je vais examiner 3 : rdiff-backup, rsnapshot et burp.
Ensembles de fichiers
Les ensembles de fichiers pour les tests seront identiques pour tous les candidats, y compris les futurs articles.
Premier ensemble: 10 Go de fichiers multimédias, et environ 50 Mo — le code source du site en php, des tailles de fichiers allant de quelques kilooctets pour le code source à des dizaines de mégaoctets pour les fichiers multimédias. L'objectif est d'imiter un site statique.
Deuxième ensemble: dérivé du premier en renommant le sous-répertoire contenant des fichiers multimédias de 5 Go. L'objectif est d'étudier le comportement du système de sauvegarde lors du renommage d'un répertoire.
Troisième ensemble: dérivé du premier en supprimant 3 Go de fichiers multimédias et en ajoutant 3 Go de nouveaux fichiers multimédias. L'objectif est d'étudier le comportement du système de sauvegarde lors d'une opération typique de mise à jour d'un site.
Obtention des résultats
Toute sauvegarde est effectuée au moins 3 fois et accompagnée d'une vidange des caches du système de fichiers via les commandes sync et echo 3 > /proc/sys/vm/drop_caches , tant côté serveur de test que côté serveur de stockage de sauvegardes.
Sur le serveur qui sera la source des sauvegardes, un logiciel de surveillance est installé — netdata, qui sera utilisé pour évaluer la charge sur le serveur lors de la sauvegarde, ce qui est nécessaire pour évaluer la charge serveur par le processus de sauvegarde.
Je considère également que le serveur de stockage de sauvegardes est plus lent au processeur que le serveur principal, mais possède des disques plus volumineux avec une vitesse d'écriture aléatoire relativement faible — situation la plus courante lors de la sauvegarde, et parce que le serveur de sauvegarde ne devrait en principe pas effectuer d'autres tâches que la sauvegarde, je ne suivrai pas sa charge avec netdata.
J'ai également modifié les serveurs sur lesquels je vais tester différents systèmes de sauvegarde.
Voici maintenant leurs caractéristiquesProcesseur
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (utilisant system LuaJIT 2.0.4)
Exécution du test avec les options suivantes :
Nombre de threads : 2
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 CPU :
événements par seconde : 1081.62
Statistiques générales :
temps total : 30.0013s
nombre total d'événements : 32453
Latence (ms) :
min : 1.48
moyen : 1.85
max : 9.84
95e percentile : 2.07
somme : 59973.40
Équité des threads :
événements (moyenne/écart type) : 16226.5000/57.50
temps d'exécution (moyenne/écart type) : 29.9867/0.00
Mémoire vive, lecture…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (utilisant system LuaJIT 2.0.4)
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 de bloc : 1KiB
taille totale : 102400MiB
opération : lecture
portée : globale
Initialisation des threads de travail...
Threads démarrés !
Opérations totales : 104857600 (5837637.63 par seconde)
102400.00 MiB transférés (5700.82 MiB/sec)
Statistiques générales :
temps total : 17.9540s
nombre total d'événements : 104857600
Latence (ms) :
min : 0.00
moyen : 0.00
max : 66.08
95e percentile : 0.00
somme : 18544.64
Équité des threads :
événements (moyenne/écart type) : 26214400.0000/0.00
temps d'exécution (moyenne/écart type) : 4.6362/0.12
… et écriture
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (utilisant system LuaJIT 2.0.4)
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 de bloc : 1KiB
taille totale : 102400MiB
opération : écriture
portée : globale
Initialisation des threads de travail...
Threads démarrés !
Opérations totales : 91414596 (3046752.56 par seconde)
89272.07 MiB transférés (2975.34 MiB/sec)
Statistiques générales :
temps total : 30.0019s
nombre total d'événements : 91414596
Latence (ms) :
min : 0.00
moyen : 0.00
max : 1022.90
95e percentile : 0.00
somme : 66430.91
Équité des threads :
événements (moyenne/écart type) : 22853649.0000/945488.53
temps d'exécution (moyenne/écart type) : 16.6077/1.76
Disque sur le serveur source de données
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (utilisant LuaJIT 2.0.4 du système)
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 fichier supplémentaires : (aucun)
128 fichiers, 8MiB chacun
1GiB taille totale des fichiers
Taille de bloc 4KiB
Nombre de requêtes IO : 0
Ratio 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 I/O synchrone
Réalisant un test r/w aléatoire
Initialisation des threads de travail...
Threads démarrés !
Opérations sur les fichiers :
lectures/s : 4587.95
écritures/s : 3058.66
fsyncs/s : 9795.73
Débit :
lecture, MiB/s : 17.92
écrit, MiB/s : 11.95
Statistiques générales :
temps total : 60.0241s
nombre total d'événements : 1046492
Latence (ms) :
min : 0.00
avg : 0.23
max : 14.45
95e centile : 0.94
somme : 238629.34
Équité des threads :
événements (moy./écart-type) : 261623.0000/1849.14
temps d'exécution (moy./écart-type) : 59.6573/0.00
Disque sur le serveur de stockage de sauvegardes
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (utilisant LuaJIT 2.0.4 du système)
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 fichier supplémentaires : (aucun)
128 fichiers, 8MiB chacun
1GiB taille totale des fichiers
Taille de bloc 4KiB
Nombre de requêtes IO : 0
Ratio 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 I/O synchrone
Réalisant un test r/w aléatoire
Initialisation des threads de travail...
Threads démarrés !
Opérations sur les fichiers :
lectures/s : 11.37
écritures/s : 7.58
fsyncs/s : 29.99
Débit :
lecture, MiB/s : 0.04
écrit, MiB/s : 0.03
Statistiques générales :
temps total : 73.8868s
nombre total d'événements : 3104
Latence (ms) :
min : 0.00
avg : 78.57
max : 3840.90
95e centile : 297.92
somme : 243886.02
Équité des threads :
événements (moy./écart-type) : 776.0000/133.26
temps d'exécution (moy./écart-type) : 60.9715/1.59
Vitesse du réseau entre les serveurs
iperf3 -c backup
Connexion au serveur backup, port 5201
[ 4] adresse locale x.x.x.x port 59402 connectée à y.y.y.y port 5201
[ ID] Intervalle Transfert Bande passante Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalle Transfert Bande passante Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 expéditeur
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec récepteur
Méthodologie de test
- Le système de fichiers est en cours de préparation sur le serveur de test avec le premier ensemble de tests, et le dépôt est initialisé sur le serveur de sauvegarde si nécessaire.
Le processus de sauvegarde est lancé et son temps est mesuré. - Les fichiers sont migrés sur le serveur de test vers le deuxième ensemble de tests. Le processus de sauvegarde est lancé et son temps est mesuré.
- Les fichiers sont migrés sur le serveur de test vers le troisième ensemble de tests. Le processus de sauvegarde est lancé et son temps est mesuré.
- Le troisième ensemble de tests obtenu est pris comme le nouveau premier ; les étapes 1-3 sont répétées deux fois supplémentaires.
- Les données sont saisies dans un tableau récapitulatif, des graphiques avec netdata sont ajoutés.
- Un rapport est rédigé sur la méthode de sauvegarde distincte.
Résultats attendus
Étant donné que les 3 candidats sont basés sur la même technologie (rsync), il est prévu que les résultats soient proches de ceux de rsync classique, y compris tous ses avantages, à savoir :
- Les fichiers dans le dépôt seront conservés « tels quels ».
- La taille du dépôt n'augmentera que d'une partie des différences entre les sauvegardes.
- Il y aura une charge relativement importante sur le réseau lors de la transmission des données, ainsi qu'une petite charge sur le processeur.
Un essai du rsync classique sera utilisé comme référence, ses résultats
sont les suivants
Le goulet d'étranglement se trouvait sur le serveur de stockage de sauvegardes sous la forme d'un disque basé sur HDD, ce qui est clairement visible sur les graphiques en forme de scie.
Les données ont été copiées en 4 minutes et 15 secondes.
Test de rdiff-backup
Le premier candidat est rdiff-backup, un script Python qui effectue la sauvegarde d'un répertoire vers un autre. La sauvegarde actuelle est conservée « telle quelle », tandis que les sauvegardes précédentes sont stockées dans un sous-répertoire spécial de manière incrémentale, économisant ainsi de l'espace.
Nous allons vérifier le mode de fonctionnement typique, c'est-à-dire que le client initie lui-même le processus de sauvegarde, et un processus est lancé côté serveur pour réaliser la sauvegarde en acceptant les données.
Voyons de quoi il est capable dans nos conditions.
Temps d'exécution de chaque lancement de test :
Premier lancement
Deuxième lancement
Troisième lancement
Premier ensemble
16m32s
16m26s
16m19s
Deuxième ensemble
2h5m
2h10m
2h8m
Troisième ensemble
2h9m
2h10m
2h10m
Rdiff-backup réagit très mal à tout gros changement de données, et n'exploite pas complètement le réseau.
Test de rsnapshot
Le deuxième candidat est rsnapshot, qui est un script Perl, dont la principale exigence pour un fonctionnement efficace est la prise en charge des liens durs. Cela permet d'économiser de l'espace disque. Les fichiers qui n'ont pas changé depuis la dernière sauvegarde feront référence au fichier original à l'aide de liens durs.
De plus, la logique du processus de sauvegarde est inversée : le serveur va activement chercher ses clients et récupérer les données.
Résultats des tests
nous avons obtenu les suivants
Premier lancement
Deuxième lancement
Troisième lancement
Premier ensemble
4m22s
4m19s
4m16s
Deuxième ensemble
2m6s
2m10s
2m6s
Troisième ensemble
1m18s
Il a fonctionné très, très rapidement, beaucoup plus vite que rdiff-backup et très près de rsync pur.
Il a fonctionné très, très rapidement, beaucoup plus vite que rdiff-backup et très près de rsync pur.
Test de burp
Une autre option est l'implémentation en C utilisant librsync - burp, qui a une architecture client-serveur comprenant l'authentification des clients, ainsi qu'une interface web (non incluse dans la livraison de base). Une autre caractéristique intéressante est la possibilité de sauvegarde sans droit de restauration pour les clients.
Voyons
11m21sla performance.
Premier lancement
Deuxième lancement
Troisième lancement
Premier ensemble
11m10s
10m56s
5m37s
Deuxième ensemble
3m33s
5m40s
5m35s
Troisième ensemble
3m24s
3m40s
Il a été deux fois plus lent que rsnapshot, mais également assez rapide, et certainement plus rapide que rdiff-backup. Les graphiques sont légèrement dentelés - la performance dépend à nouveau du sous-système de disque du serveur de stockage des sauvegardes, même si cela n'est pas aussi prononcé que pour rsnapshot.
A fonctionné deux fois plus lentement que rsnapshot, mais reste assez rapide, et certainement plus rapide que rdiff-backup. Les graphiques présentent quelques irrégularités — la performance est de nouveau limitée par le système de stockage des sauvegardes, bien que cela ne soit pas aussi marqué qu'avec rsnapshot.
Résultats
La taille des dépôts de tous les candidats était à peu près similaire, c'est-à-dire une augmentation jusqu'à 10 Go, puis jusqu'à 15 Go, puis jusqu'à 18 Go, etc., ce qui est lié aux caractéristiques du fonctionnement de rsync. Il convient également de noter que tous les candidats fonctionnaient en mode mono-thread (charge sur le processeur d'environ 50 % sur une machine à deux cœurs). Tous les 3 candidats offraient la possibilité de restaurer la dernière sauvegarde "telle quelle", c'est-à-dire qu'il était possible de restaurer des fichiers sans utiliser de programmes tiers, y compris ceux utilisés pour créer les dépôts. C'est également un "héritage" de rsync.
Conclusions
Plus un système de sauvegarde est complexe et plus il a de fonctionnalités différentes, plus il fonctionnera lentement, mais pour des projets peu exigeants, n'importe lequel d'entre eux conviendra, sauf peut-être rdiff-backup.
Annonce
Cet article poursuit le cycle sur la sauvegarde.
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
Auteur de la publication: Pavel Demkovitch
Source : habr.com
