Aquesta nota continua
cicle de còpia de seguretat
- Còpia de seguretat Part 2: revisar i provar les eines de còpia de seguretat basades en rsync
- Còpia de seguretat Part 3: revisió i prova de duplicitat, duplicació, deja dup
- Còpia de seguretat Part 4: revisió i prova de zbackup, restic, borgbackup
- Còpia de seguretat Part 5: prova de còpia de seguretat de bacula i veeam per a Linux
- Còpia de seguretat Part 6: comparació d'eines de còpia de seguretat
- Còpia de seguretat Part 7: Conclusions
Com ja vam escriure al primer article, hi ha un nombre bastant elevat de programes de còpia de seguretat basats en rsync.
Dels més adequats per a les nostres condicions, en consideraré 3: rdiff-backup, rsnapshot i burp.
Fitxers de la suite de proves
Els fitxers de proves seran els mateixos per a tots els candidats, inclosos els treballs futurs.
Primer conjunt: 10 GB de fitxers multimèdia i uns 50 MB: el codi font del lloc en php, mides de fitxer des d'uns pocs kilobytes per al codi font, fins a desenes de megabytes per a fitxers multimèdia. L'objectiu és imitar un lloc amb contingut estàtic.
Segon set: s'obté del primer en canviar el nom d'un subdirectori amb fitxers multimèdia de 5 GB. L'objectiu és estudiar el comportament del sistema de còpia de seguretat quan es canvia el nom d'un directori.
Tercer conjunt: s'obté del primer eliminant 3 GB de fitxers multimèdia i afegint nous 3 GB de fitxers multimèdia. L'objectiu és estudiar el comportament del sistema de còpia de seguretat durant una operació típica d'actualització del lloc.
Obtenció de resultats
Qualsevol còpia de seguretat es realitza almenys 3 vegades i s'acompanya d'esborrar la memòria cau del sistema de fitxers amb les ordres sync и echo 3 > /proc/sys/vm/drop_caches tant al costat del servidor de prova com al servidor d'emmagatzematge de còpia de seguretat.
Al servidor que serà l'origen de les còpies de seguretat, s'instal·la el programari de supervisió: netdata, que s'utilitzarà per avaluar la càrrega al servidor durant la còpia, això és necessari per avaluar la càrrega al servidor mitjançant el procés de còpia de seguretat.
També crec que el servidor d'emmagatzematge de còpia de seguretat és més lent en termes de processador que el servidor principal, però té discs més amplis amb una velocitat d'escriptura aleatòria relativament baixa, la situació més comuna en fer còpies de seguretat, però a causa del fet que el servidor de còpia de seguretat en una bona manera no hauria de fer altres tasques, a excepció de la còpia de seguretat, no faré un seguiment de la seva càrrega amb netdata.
A més, els meus servidors han canviat, en els quals comprovaré la còpia de seguretat de diversos sistemes.
Ara tenen les següents característiquesProcessador
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, lectura...
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
...i gravar
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
Disc al servidor de fonts de dades
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
Disc al servidor d'emmagatzematge de còpia de seguretat
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
Velocitat de xarxa entre servidors
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y 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
Metodologia de la prova
- El sistema de fitxers amb el primer conjunt de proves es prepara al servidor de proves i el dipòsit s'inicializa al servidor d'emmagatzematge de còpia de seguretat, si cal.
S'inicia el procés de còpia de seguretat i es mesura el seu temps. - Els fitxers es migren al segon conjunt de proves al servidor de proves. S'inicia el procés de còpia de seguretat i es mesura el seu temps.
- El servidor de proves s'està migrant a la tercera suite de proves. S'inicia el procés de còpia de seguretat i es mesura el seu temps.
- El tercer cas de prova rebut s'accepta com el nou primer; els passos 1-3 es repeteixen 2 vegades més.
- Les dades s'introdueixen en una taula dinàmica, s'afegeixen gràfics a partir de netdata.
- Es genera un informe per a un mètode de còpia de seguretat concret.
Resultats previstos
Atès que els 3 candidats es basen en la mateixa tecnologia (rsync), s'espera que els resultats siguin propers a la rsync normal, inclosos tots els seus avantatges, a saber:
- Els fitxers del repositori es mantindran "tal qual".
- La mida del dipòsit només augmentarà inclosa la diferència entre les còpies de seguretat.
- Hi haurà una càrrega relativament gran a la xarxa durant la transferència de dades, així com una petita càrrega al processador.
S'utilitzarà una prova de rsync normal com a punt de referència, els seus resultats
aquests són
El coll d'ampolla es trobava al servidor d'emmagatzematge de còpia de seguretat en forma de disc basat en HDD, que es pot veure clarament als gràfics en forma de serra.
Les dades es van copiar en 4 minuts i 15 segons.
Prova rdiff-backup
El primer candidat és rdiff-backup, un script Python que fa una còpia de seguretat d'un directori a un altre. En aquest cas, la còpia de seguretat actual s'emmagatzema "tal com està", i les còpies de seguretat fetes anteriorment s'afegeixen de manera incremental a un subdirectori especial i, per tant, s'estalvia espai.
Comprovarem el mode de funcionament típic, és a dir. l'inici del procés de còpia de seguretat l'inicia el client per si mateix i, al costat del servidor, per a la còpia de seguretat, s'inicia un procés que rep dades.
Fem una ullada, de què és capaç en les nostres condicions.
Temps d'execució de cada prova:
Primer inici
Segona tirada
Tercer llançament
Primer conjunt
16 m32 s
16 m26 s
16 m19 s
Segon set
2:5 p.m.
2:10 p.m.
2:8 p.m.
Tercer conjunt
2:9 p.m.
2:10 p.m.
2:10 p.m.
Rdiff-backup reacciona de manera molt dolorosa a qualsevol canvi de dades gran i, a més, no utilitza completament la xarxa.
prova de rsnapshot
El segon candidat, rsnapshot, és un script perl el principal requisit del qual per a un funcionament eficient és el suport per a enllaços durs. Això estalvia espai al disc. En aquest cas, els fitxers que no han canviat des de la còpia de seguretat anterior faran referència al fitxer original mitjançant enllaços durs.
La lògica del procés de còpia de seguretat també s'inverteix: el servidor "camina" activament pels seus clients i recopila dades.
Resultats de l'exàmen
va obtenir el següent
Primer inici
Segona tirada
Tercer llançament
Primer conjunt
4 m22 s
4 m19 s
4 m16 s
Segon set
2 m6 s
2 m10 s
2 m6 s
Tercer conjunt
1 m18 s
1 m10 s
1 m10 s
Va funcionar molt, molt ràpidament, molt més ràpid que la còpia de seguretat rdiff i molt a prop de la rsync pura.
Prova de burp
Una altra opció és una implementació C a la part superior de librsync - burp, té una arquitectura client-servidor que inclou l'autorització del client, així com una interfície web (no inclosa al paquet bàsic). Una altra característica interessant és la còpia de seguretat sense recuperació per als clients.
Vegem-horendiment.
Primer inici
Segona tirada
Tercer llançament
Primer conjunt
11 m21 s
11 m10 s
10 m56 s
Segon set
5 m37 s
5 m40 s
5 m35 s
Tercer conjunt
3 m33 s
3 m24 s
3 m40 s
Va funcionar 2 vegades més lent que rsnapshot, però també prou ràpid, i sens dubte més ràpid que rdiff-backup. Els gràfics són una mica de dent de serra: el rendiment es basa de nou en el subsistema de disc del servidor d'emmagatzematge de còpia de seguretat, tot i que això no és tan pronunciat com amb rsnapshot.
Troballes
La mida dels dipòsits per a tots els candidats era aproximadament la mateixa, és a dir, primer creixement a 10 GB, després creixement a 15 GB, després creixement a 18 GB, etc., que es deu a la peculiaritat de rsync. També val la pena assenyalar que tots els candidats són d'un sol fil (la càrrega del processador és d'aproximadament el 50% en una màquina de doble nucli). Els 3 candidats van proporcionar la possibilitat de restaurar l'última còpia de seguretat "tal com és", és a dir, era possible restaurar fitxers sense utilitzar cap programa de tercers, inclosos els utilitzats per crear dipòsits. Aquest és també el "herència ancestral" de rsync.
Troballes
Com més complex sigui el sistema de còpia de seguretat i més opcions diferents tingui, més lent funcionarà, però per a projectes poc exigents, qualsevol d'ells, excepte potser rdiff-backup, servirà.
Anunci
Aquesta nota continua el cicle sobre la còpia de seguretat
Còpia de seguretat Part 2: revisar i provar les eines de còpia de seguretat basades en rsync
Còpia de seguretat Part 3: revisió i prova de duplicitat, duplicació, deja dup
Còpia de seguretat Part 4: revisió i prova de zbackup, restic, borgbackup
Còpia de seguretat Part 5: prova de còpia de seguretat de bacula i veeam per a Linux
Còpia de seguretat Part 6: comparació d'eines de còpia de seguretat
Còpia de seguretat Part 7: Conclusions
Autor de la publicació: Pavel Demkovich
Font: www.habr.com
