Cet article continue
cycle de sauvegarde- Sauvegarde, partie 1: Pourquoi avez-vous besoin d'une sauvegarde, un aperçu des méthodes, des technologies
- Sauvegarde, partie 2: présentation et test de l'outil de sauvegarde basé sur rsync
- Sauvegarde, Partie 3: Présentation et test de la duplicité, duplicati
- Sauvegarde, Partie 4: Présentation et test de zbackup, restic, borgbackup
- Sauvegarde, Partie 5: Test de Bacula et Veeam Backup pour Linux
- Sauvegarde, partie 6: comparaison des outils de sauvegarde
- Sauvegarde, partie 7: Conclusions
Comme nous l'avons déjà écrit dans le premier article, il existe un très grand nombre de programmes de sauvegarde basés sur rsync.
Parmi ceux qui conviennent le mieux à nos conditions, j'en considérerai 3: rdiff-backup, rsnapshot et burp.
Ensembles de fichiers de test
Les ensembles de fichiers de test seront les mêmes pour tous les candidats, y compris les futurs articles.Le premier ensemble : 10 Go de fichiers multimédias et environ 50 Mo - le code source du site en php, des tailles de fichier de quelques kilo-octets pour le code source, à des dizaines de mégaoctets pour les fichiers multimédias. Le but est de simuler un site avec de la statique.
Le deuxième ensemble : obtenu à partir du premier lors du renommage d'un sous-répertoire avec des fichiers multimédias de 5 Go. L'objectif est d'étudier le comportement du système de sauvegarde lors du changement de nom d'un répertoire.
Troisième ensemble : obtenu à partir du premier en supprimant 3 Go de fichiers multimédias et en ajoutant de nouveaux 3 Go de fichiers multimédias. L'objectif est d'étudier le comportement du système de sauvegarde lors d'une opération typique de mise à jour de site.
Obtenir des résultats
Toute sauvegarde est effectuée au moins 3 fois et s'accompagne d'une réinitialisation des caches du système de fichiers avec les commandes
sync et
echo 3 > /proc/sys/vm/drop_caches sur le serveur de test et le serveur de stockage de sauvegarde.
Sur le serveur qui sera la source des sauvegardes, un logiciel de surveillance est installé - netdata, avec lequel la charge sur le serveur sera estimée pendant la sauvegarde, cela est nécessaire pour évaluer la charge sur le serveur par le processus de sauvegarde.
Je pense également que le serveur de stockage de sauvegarde est plus lent que le serveur principal, mais qu'il a des disques plus volumineux avec une vitesse d'écriture aléatoire relativement faible - la situation la plus courante lors de la sauvegarde, et du fait que le serveur de sauvegarde ne devrait rien faire de bien Je ne surveillerai pas la charge autre que la sauvegarde, je ne surveillerai pas sa charge à l'aide de netdata.
De plus, mes serveurs ont changé, sur lesquels je vais vérifier différents systèmes pour la sauvegarde.
Maintenant, ils ont les caractéristiques suivantesCPU sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.62 General statistics: total time: 30.0013s total number of events: 32453 Latency (ms): min: 1.48 avg: 1.85 max: 9.84 95th percentile: 2.07 sum: 59973.40 Threads fairness: events (avg/stddev): 16226.5000/57.50 execution time (avg/stddev): 29.9867/0.00
RAM, 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 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: read scope: global Initializing worker threads... Threads started! Total operations: 104857600 (5837637.63 per second) 102400.00 MiB transferred (5700.82 MiB/sec) General statistics: total time: 17.9540s total number of events: 104857600 Latency (ms): min: 0.00 avg: 0.00 max: 66.08 95th percentile: 0.00 sum: 18544.64 Threads fairness: events (avg/stddev): 26214400.0000/0.00 execution time (avg/stddev): 4.6362/0.12
... et enregistrement 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 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: write scope: global Initializing worker threads... Threads started! Total operations: 91414596 (3046752.56 per second) 89272.07 MiB transferred (2975.34 MiB/sec) General statistics: total time: 30.0019s total number of events: 91414596 Latency (ms): min: 0.00 avg: 0.00 max: 1022.90 95th percentile: 0.00 sum: 66430.91 Threads fairness: events (avg/stddev): 22853649.0000/945488.53 execution time (avg/stddev): 16.6077/1.76
Disque sur le serveur de 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 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 4587.95 writes/s: 3058.66 fsyncs/s: 9795.73 Throughput: read, MiB/s: 17.92 written, MiB/s: 11.95 General statistics: total time: 60.0241s total number of events: 1046492 Latency (ms): min: 0.00 avg: 0.23 max: 14.45 95th percentile: 0.94 sum: 238629.34 Threads fairness: events (avg/stddev): 261623.0000/1849.14 execution time (avg/stddev): 59.6573/0.00
Disque sur le serveur de stockage de sauvegarde sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 11.37 writes/s: 7.58 fsyncs/s: 29.99 Throughput: read, MiB/s: 0.04 written, MiB/s: 0.03 General statistics: total time: 73.8868s total number of events: 3104 Latency (ms): min: 0.00 avg: 78.57 max: 3840.90 95th percentile: 297.92 sum: 243886.02 Threads fairness: events (avg/stddev): 776.0000/133.26 execution time (avg/stddev): 60.9715/1.59
Vitesse du réseau entre les serveurs iperf3 -c backup Connecting to host backup, port 5201 [ 4] local xxxx port 59402 connected to yyyy port 5201 [ ID] Interval Transfer Bandwidth 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] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
Méthodologie de test
- Un système de fichiers avec le premier jeu de test est préparé sur le serveur de test et le référentiel est initialisé sur le serveur de stockage de sauvegarde si nécessaire.
Le processus de sauvegarde démarre et son heure est mesurée. - Les fichiers sont migrés vers la deuxième suite de tests sur le serveur de test. Le processus de sauvegarde démarre et son heure est mesurée.
- Le serveur de test migre vers la troisième suite de tests. Le processus de sauvegarde démarre et son heure est mesurée.
- Le troisième ensemble de tests résultant est accepté par le nouveau premier; les points 1-3 sont répétés 2 fois de plus.
- Les données sont entrées dans le tableau croisé dynamique, des graphiques avec des données nettes sont ajoutés.
- Un rapport est préparé à l'aide d'une méthode de sauvegarde distincte.
Résultats attendus
Étant donné que les 3 candidats sont basés sur la même technologie (rsync), les résultats devraient être proches du rsync habituel, y compris tous ses avantages, à savoir:
- Les fichiers du référentiel seront stockés "tels quels".
- La taille du référentiel augmentera uniquement en incluant la différence entre les sauvegardes.
- Il y aura une charge relativement importante sur le réseau lors de la transmission de données, ainsi qu'une petite charge sur le processeur.
Le test d'une rsync régulière sera utilisé comme référence, ses résultats
ce sont
Le goulot d'étranglement se trouvait sur le serveur de stockage de sauvegarde sous la forme d'un disque à disque dur, ce qui est assez clairement visible dans 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 sauvegarde un répertoire dans un autre. Dans le même temps, la copie de sauvegarde actuelle est stockée «en l'état» et les sauvegardes effectuées précédemment sont stockées de manière incrémentielle dans un sous-répertoire spécial, ce qui permet d'économiser de l'espace.
Nous vérifierons le mode de fonctionnement typique, c'est-à-dire le démarrage du processus de sauvegarde est initié par le client lui-même, et côté serveur, le processus qui reçoit les données est lancé pour la sauvegarde.
Voyons voir
de quoi est-il capable dans nos conditions.
Le temps d'exécution de chaque test:
Rdiff-backup réagit très douloureusement à tout changement important de données et n'utilise pas complètement le réseau.
Test de rsnapshot
Le deuxième candidat, rsnapshot, est un script perl dont la principale exigence pour un travail efficace est le support des liens durs. Cela économise de l'espace disque. Dans le même temps, les fichiers qui n'ont pas été modifiés depuis la sauvegarde précédente seront référencés au fichier d'origine à l'aide de liens physiques.
La logique du processus de sauvegarde est également inversée: le serveur «marche» activement sur ses clients lui-même et prend les données.
Résultats des tests
Cela a fonctionné très, très rapidement, beaucoup plus rapidement que rdiff-backup et très proche de rsync pur.
Test de burp
Une autre option est l'implémentation C au-dessus de librsync - burp, qui a une architecture client-serveur incluant l'autorisation client, ainsi qu'une interface Web (non incluse dans le package de base). Une autre fonctionnalité intéressante est la sauvegarde sans droit de récupération auprès des clients.
Regardons
performance.
Cela a fonctionné 2 fois plus lentement que rsnapshot, mais aussi assez rapide, et certainement plus rapide rdiff-backup. Les graphiques sont un peu en dents de scie - les performances reposent à nouveau sur le sous-système de disque du serveur de stockage de sauvegarde, bien que ce ne soit pas aussi prononcé que celui de rsnapshot.
Résultats
La taille des référentiels pour tous les candidats était approximativement la même, c'est-à-dire d'abord une croissance jusqu'à 10 Go, puis une croissance jusqu'à 15 Go, puis une croissance jusqu'à 18 Go, etc., en raison de la particularité de rsync. Il convient également de noter le caractère unique de tous les candidats (l'utilisation du processeur est d'environ 50% avec une machine à double cœur). Les 3 candidats ont fourni 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 des référentiels. C'est aussi «l'héritage générique» de rsync.
Conclusions
Plus le système de sauvegarde est complexe et plus ses fonctionnalités sont diverses, plus il fonctionnera lentement, mais pour les projets peu exigeants, aucun d'entre eux ne fonctionnera, sauf, éventuellement, rdiff-backup.
Annonce
Cette note poursuit le cycle de sauvegarde.
Sauvegarde, partie 1: Pourquoi avez-vous besoin d'une sauvegarde, un aperçu des méthodes, des technologiesSauvegarde, Partie 2: Présentation et test des outils de sauvegarde basés sur rsyncSauvegarde, Partie 3: Présentation et test de la duplicité, duplicatiSauvegarde, Partie 4: Présentation et test de zbackup, restic, borgbackupSauvegarde, Partie 5: Test de Bacula et Veeam Backup pour LinuxSauvegarde: pièce demandée par les lecteurs: revue AMANDA, UrBackup, BackupPCSauvegarde, partie 6: comparaison des outils de sauvegardeSauvegarde, partie 7: ConclusionsPublié par Finnix