Este articulo continua
ciclo de respaldo- Copia de seguridad, parte 1: ¿Por qué necesita una copia de seguridad, una descripción general de los métodos y las tecnologías?
- Copia de seguridad, Parte 2: Descripción general y prueba de la herramienta de copia de seguridad basada en rsync
- Copia de seguridad, Parte 3: Descripción general y prueba de duplicidad, duplicación
- Copia de seguridad, Parte 4: Descripción general y prueba de zbackup, restic, borgbackup
- Backup, Parte 5: Prueba de 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, hay una gran cantidad de programas de respaldo basados en rsync.
De los que son más adecuados para 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.El primer conjunto : 10 GB de archivos multimedia y aproximadamente 50 MB: el código fuente del sitio en php, tamaños de archivo desde unos pocos kilobytes para el código fuente, hasta decenas de megabytes para archivos multimedia. El objetivo es simular un sitio con estadísticas.
El segundo conjunto : 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 copia de seguridad al cambiar el nombre de un directorio.
Tercer conjunto : obtenido del primero eliminando 3GB de archivos multimedia y agregando nuevos 3GB 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 va acompañada de un restablecimiento de las memorias caché del sistema de archivos con los
echo 3 > /proc/sys/vm/drop_caches sync y
echo 3 > /proc/sys/vm/drop_caches tanto en el servidor de prueba como en el servidor de almacenamiento de copia de seguridad.
En el servidor que será la fuente de las copias de seguridad, se instala un software de monitoreo: netdata, con el que se calculará la carga en el servidor durante la copia de seguridad, esto es necesario para evaluar la carga en el servidor mediante el proceso de copia de seguridad.
También creo que el servidor de almacenamiento de respaldo es más lento que el servidor principal, pero tiene discos más potentes con una velocidad de escritura aleatoria relativamente baja, la situación más común cuando se realiza una copia de respaldo, y debido al hecho de que el servidor de respaldo no debería hacer nada bueno No monitorearé la carga que no sea una copia de seguridad, no monitorearé su carga usando netdata.
Además, mis servidores han cambiado, en los cuales revisaré varios sistemas para realizar copias de seguridad.
Ahora tienen las siguientes característicasCPU 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, leyendo ... 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 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
Metodología de prueba
- Se prepara un sistema de archivos con el primer conjunto de prueba en el servidor de prueba, y el repositorio se inicializa en el servidor de almacenamiento de respaldo si es necesario.
El proceso de respaldo comienza y se mide su tiempo. - Los archivos se migran al segundo conjunto de pruebas en el servidor de prueba. El proceso de respaldo comienza y se mide su tiempo.
- El servidor de prueba migra al tercer conjunto de pruebas. El proceso de respaldo comienza y se mide su tiempo.
- El nuevo conjunto de pruebas resultante es aceptado por el nuevo primero; los puntos 1-3 se repiten 2 veces más.
- Los datos se ingresan en la tabla dinámica, se agregan gráficos con netdata.
- Se prepara un informe utilizando un método de copia de seguridad separado.
Resultados esperados
Dado que los 3 candidatos se basan en la misma tecnología (rsync), se espera que los resultados se aproximen al rsync habitual, incluidas todas sus ventajas, a saber:
- Los archivos en el repositorio se almacenarán "tal cual".
- El tamaño del repositorio crecerá solo incluyendo la diferencia entre las copias de seguridad.
- Habrá una carga relativamente grande en la red al transmitir datos, así como una pequeña carga en el procesador.
La ejecución de prueba de un rsync regular se usará como referencia, sus resultados
estos son
El cuello de botella se encontraba en el servidor de almacenamiento de respaldo en forma de disco basado en HDD, que es claramente visible en los gráficos en forma de sierra.
Los datos se copiaron en 4 minutos y 15 segundos.
Prueba de rdiff-backup
El primer candidato es rdiff-backup, un script de Python que realiza una copia de seguridad de un directorio en otro. Al mismo tiempo, la copia de seguridad actual se almacena "tal cual", y las copias de seguridad realizadas anteriormente se almacenan en un subdirectorio especial de forma incremental, y por lo tanto se ahorra espacio.
Comprobaremos el modo típico de operación, es decir El cliente inicia el proceso de copia de seguridad por sí mismo y, en el lado del servidor, el proceso que recibe los datos se inicia para la copia de seguridad.
Vamos a ver
¿De qué es capaz en nuestras condiciones?.
El tiempo de ejecución de cada prueba:
Rdiff-backup reacciona muy dolorosamente a cualquier gran cambio de datos, y tampoco utiliza completamente la red.
Prueba de rsnapshot
El segundo candidato, rsnapshot, es un script perl cuyo principal requisito para un trabajo efectivo es el soporte para enlaces duros. Esto ahorra espacio en disco. Al mismo tiempo, los archivos que no han cambiado desde la copia de seguridad anterior se referenciarán al archivo original mediante enlaces duros.
La lógica del proceso de copia de seguridad también se invierte: el servidor "camina" activamente sobre sus propios clientes y toma datos.
Resultados de la prueba
Funcionó muy, muy rápido, mucho más rápido que rdiff-backup y muy cerca de rsync puro.
Prueba de eructos
Otra opción es la implementación de C sobre librsync - burp, que tiene una arquitectura cliente-servidor que incluye la autorización del cliente, así como una interfaz web (no incluida en el paquete base). Otra característica interesante es la copia de seguridad sin el derecho de recuperación de los clientes.
Veamos
rendimiento.
Funcionó 2 veces más lento que rsnapshot, pero también bastante rápido, y ciertamente más rápido rdiff-backup. Los gráficos son un poco de diente de sierra: el rendimiento nuevamente descansa en el subsistema de disco del servidor de almacenamiento de respaldo, aunque esto no es tan pronunciado como el de rsnapshot.
Resultados
El tamaño de los repositorios para todos los candidatos fue aproximadamente el mismo, es decir, en un primer crecimiento de hasta 10 GB, luego un crecimiento de hasta 15 GB, luego un crecimiento de hasta 18 GB, etc., debido a la peculiaridad de rsync. También vale la pena señalar el enhebrado único de todos los candidatos (la utilización de la CPU es de aproximadamente el 50% con una máquina de doble núcleo). Los 3 candidatos brindaron la oportunidad de restaurar la última copia de seguridad "tal cual", es decir, fue posible restaurar archivos sin usar ningún programa de terceros, incluidos los utilizados para crear repositorios. Este es también el "legado genérico" de rsync.
Conclusiones
Cuanto más complejo sea el sistema de respaldo y más características diferentes tenga, más lento funcionará, pero para proyectos no muy exigentes, ninguno de ellos lo hará, excepto, posiblemente, rdiff-backup.
Anuncio
Esta nota continúa el ciclo de respaldo.
Copia de seguridad, parte 1: ¿Por qué necesita una copia de seguridad, una descripción general de los métodos y las tecnologías?Copia de seguridad, Parte 2: Descripción general y prueba de herramientas de copia de seguridad basadas en rsyncCopia de seguridad, Parte 3: Descripción general y prueba de duplicidad, duplicaciónCopia de seguridad, Parte 4: Descripción general y prueba de zbackup, restic, borgbackupBackup, Parte 5: Prueba de Bacula y Veeam Backup para LinuxCopia de seguridad: parte solicitada por los lectores: revisión de AMANDA, UrBackup, BackupPCCopia de seguridad, Parte 6: Comparación de herramientas de copia de seguridadCopia de seguridad Parte 7: ConclusionesPublicado por Finnix