Esta nota continúa
ciclo sobre copia de seguridad
- Copia de seguridad Parte 2: Revisión y prueba de herramientas de copia de seguridad basadas en rsync
- Copia de seguridad Parte 3: revisión y prueba de duplicidad, duplicación, deja dup
- Backup Parte 4: Revisión y prueba de zbackup, restic, borgbackup
- Copia de seguridad Parte 5: Probando bacula y veeam backup para linux
- Copia de seguridad Parte 6: Comparación de herramientas de copia de seguridad
- Copia de seguridad Parte 7: Conclusiones
Como ya escribimos en el primer artículo, existe una gran cantidad de programas de copia de seguridad basados en rsync.
De los que mejor se adaptan a nuestras condiciones, consideraré 3: rdiff-backup, rsnapshot y burp.
Conjuntos de archivos de prueba
Los conjuntos de archivos de prueba serán los mismos para todos los candidatos, incluidos los artículos futuros.
Primer set: 10 GB de archivos multimedia y aproximadamente 50 MB: el código fuente del sitio en PHP, tamaños de archivo desde varios kilobytes para el código fuente hasta decenas de megabytes para archivos multimedia. El objetivo es imitar un sitio estático.
segundo set: obtenido del primero al cambiar el nombre de un subdirectorio con archivos multimedia de 5 GB. El objetivo es estudiar el comportamiento del sistema de respaldo al cambiar el nombre de un directorio.
Tercer set: obtenido del primero eliminando 3 GB de archivos multimedia y agregando nuevos 3 GB de archivos multimedia. El objetivo es estudiar el comportamiento del sistema de respaldo durante una operación típica de actualización del sitio.
Obteniendo resultados
Cualquier copia de seguridad se realiza al menos 3 veces y se acompaña de un restablecimiento de las cachés del sistema de archivos con los comandos sync и echo 3 > /proc/sys/vm/drop_caches tanto en el lado del servidor de prueba como en el servidor de almacenamiento de respaldo.
En el servidor que será la fuente de las copias de seguridad, se instala un software de monitoreo: netdata, con la ayuda del cual se evaluará la carga en el servidor durante la copia, esto es necesario para evaluar la carga en el servidor durante el proceso de copia de seguridad.
También creo que el servidor de almacenamiento de respaldo es más lento en términos de procesador que el servidor principal, pero tiene discos más espaciosos con una velocidad de escritura aleatoria relativamente baja, la situación más común durante las copias de seguridad, y debido al hecho de que el servidor de respaldo no debería correctamente, no realizaré un seguimiento de otras tareas excepto la copia de seguridad, su carga mediante netdata.
También cambié los servidores en los que verificaré varios sistemas para realizar copias de seguridad.
Ahora tienen las siguientes características.procesador
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
...y grabando
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
Disco en el servidor de origen de datos
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
Disco en el servidor de almacenamiento de respaldo
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
Velocidad de red entre servidores
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
Metodología de prueba
- En el servidor de prueba, se prepara un sistema de archivos con el primer conjunto de prueba y, en el servidor de almacenamiento de respaldo, si es necesario, se inicializa el repositorio.
Se inicia el proceso de copia de seguridad y se mide su tiempo. - En el servidor de prueba, los archivos se migran al segundo conjunto de prueba. Se inicia el proceso de copia de seguridad y se mide su tiempo.
- En el servidor de prueba, la migración se realiza hasta el tercer conjunto de prueba. Se inicia el proceso de copia de seguridad y se mide su tiempo.
- El tercer conjunto de pruebas resultante se acepta como el nuevo primero; Los pasos 1-3 se repiten 2 veces más.
- Los datos se ingresan en una tabla dinámica y se agregan gráficos con datos de red.
- Se genera un informe para el método de copia de seguridad individual.
Resultados esperados
Dado que los 3 candidatos se basan en la misma tecnología (rsync), se espera que los resultados sean cercanos al rsync normal, incluidas todas sus ventajas, a saber:
- Los archivos en el repositorio se almacenarán "tal cual".
- El tamaño del repositorio solo crecerá incluyendo la diferencia entre las copias de seguridad.
- Habrá una carga relativamente grande en la red al transferir datos, así como una pequeña carga en el procesador.
Se utilizará como referencia una ejecución de prueba de rsync normal, sus resultados
estos son
El cuello de botella estaba en el servidor de almacenamiento de datos de respaldo en forma de disco basado en HDD, lo cual es claramente visible en los gráficos en forma de dientes de sierra.
Los datos se copiaron en 4 minutos y 15 segundos.
Prueba de copia de seguridad rdiff
El primer candidato es rdiff-backup, un script en Python que realiza una copia de seguridad de un directorio en otro. En este caso, la copia de seguridad actual se almacena "tal cual" y las copias de seguridad realizadas anteriormente se almacenan de forma incremental en un subdirectorio especial y, por lo tanto, ahorran espacio.
Comprobaremos el modo de funcionamiento típico, es decir. El inicio del proceso de copia de seguridad lo inicia el propio cliente y, en el lado del servidor, se inicia un proceso de copia de seguridad que recibe datos.
Vamos a ver ¿De qué es capaz en nuestras condiciones?.
Tiempo de ejecución de cada prueba:
Первый запуск
Segunda carrera
Tercer lanzamiento
Primer set
16m32s
16m26s
16m19s
segundo set
2h5m
2h10m
2h8m
Tercer set
2h9m
2h10m
2h10m
Rdiff-backup reacciona de manera muy dolorosa ante cualquier cambio importante en los datos y tampoco utiliza completamente la red.
prueba de instantáneas
El segundo candidato, rsnapshot, es un script Perl cuyo principal requisito para un funcionamiento eficaz es la compatibilidad con enlaces físicos. Esto ahorra espacio en disco. En este caso, los archivos que no han cambiado desde la copia de seguridad anterior se vincularán al archivo original mediante enlaces físicos.
La lógica del proceso de copia de seguridad también se invierte: el servidor "camina" activamente entre sus clientes y toma datos.
Resultados de la prueba
resultó lo siguiente
Первый запуск
Segunda carrera
Tercer lanzamiento
Primer set
4m22s
4m19s
4m16s
segundo set
2m6s
2m10s
2m6s
Tercer set
1m18s
1m10s
1m10s
Funcionó muy, muy rápido, mucho más rápido que rdiff-backup y muy cerca de rsync puro.
prueba de eructo
Otra opción es una implementación en C además de librsync - burp, que tiene una arquitectura cliente-servidor que incluye autorización del cliente, así como una interfaz web (no incluida en el paquete básico). Otra característica interesante son las copias de seguridad sin recuperación del lado del cliente.
Echemos un vistazo aпроизводительность.
Первый запуск
Segunda carrera
Tercer lanzamiento
Primer set
11m21s
11m10s
10m56s
segundo set
5m37s
5m40s
5m35s
Tercer set
3m33s
3m24s
3m40s
Funcionó 2 veces más lento que rsnapshot, pero también fue bastante rápido y ciertamente más rápido que rdiff-backup. Los gráficos son un poco dientes de sierra: el rendimiento nuevamente depende del subsistema de disco del servidor de almacenamiento de respaldo, aunque esto no es tan pronunciado como con rsnapshot.
resultados
El tamaño de los repositorios para todos los candidatos fue aproximadamente el mismo, es decir, primero creció a 10 GB, luego a 15 GB, luego a 18 GB, etc., lo cual se debe a la peculiaridad de rsync. También vale la pena señalar que todos los candidatos son de un solo subproceso (la carga del procesador es aproximadamente del 50% en una máquina de doble núcleo). Los 3 candidatos ofrecieron la capacidad de restaurar la última copia de seguridad "tal cual", es decir, era posible restaurar archivos sin utilizar ningún programa de terceros, incluidos los utilizados para crear repositorios. Este es también el "legado ancestral" de rsync.
Hallazgos
Cuanto más complejo sea el sistema de respaldo y más capacidades diferentes tenga, más lento funcionará, pero para proyectos no muy exigentes cualquiera de ellos será adecuado, excepto, quizás, rdiff-backup.
anuncio
Esta nota continúa el ciclo sobre el respaldo.
Copia de seguridad Parte 2: revisión y prueba de herramientas de copia de seguridad basadas en rsync
Copia de seguridad Parte 3: revisión y prueba de duplicidad, duplicación, deja dup
Backup Parte 4: Revisión y prueba de zbackup, restic, borgbackup
Copia de seguridad Parte 5: Probando bacula y veeam backup para linux
Copia de seguridad Parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad Parte 7: Conclusiones
autores: Pavel Demkovich
Fuente: habr.com
