{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Copia de seguridad, parte 6: Comparaci\u00f3n de herramientas de copia de seguridad","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Copia
\nEn este art\u00edculo se realizar\u00e1 una comparaci\u00f3n de las herramientas de respaldo, pero primero es importante entender c\u00f3mo manejan r\u00e1pidamente y de manera efectiva la recuperaci\u00f3n de datos de las copias de seguridad.
\nPara simplificar la comparaci\u00f3n, se considerar\u00e1 la recuperaci\u00f3n de una copia de seguridad completa, especialmente porque este modo de operaci\u00f3n es compatible con todos los candidatos. Para simplificar, los n\u00fameros se toman ya promediados (media aritm\u00e9tica de varias ejecuciones). Los resultados se presentar\u00e1n en una tabla, que tambi\u00e9n incluir\u00e1 informaci\u00f3n sobre las capacidades: existencia de una interfaz web, facilidad de configuraci\u00f3n y uso, capacidad de automatizaci\u00f3n, existencia de varias caracter\u00edsticas adicionales (por ejemplo, verificaci\u00f3n de integridad de datos), etc. Los gr\u00e1ficos mostrar\u00e1n la carga del servidor donde se aplicar\u00e1n los datos (no el servidor de almacenamiento de copias de seguridad).
\n<\/a><\/noindex><\/p>\n

Recuperaci\u00f3n de datos<\/h2>\n

\nComo punto de referencia se utilizar\u00e1n rsync y tar, ya que normalmente se basan en ellos<\/a><\/noindex> los scripts m\u00e1s simples para realizar copias de seguridad.<\/p>\n

Rsync<\/i> complet\u00f3 el conjunto de datos de prueba en 4 minutos y 28 segundos, mostrando <\/p>\n

tal carga.<\/b>\"Copia
\n
\nEl proceso de recuperaci\u00f3n se vio limitado por la restricci\u00f3n del subsistema de almacenamiento del servidor de copias de seguridad (gr\u00e1ficos en forma de sierra). Tambi\u00e9n se puede ver claramente la carga de un solo n\u00facleo sin problemas significativos (bajo iowait y softirq \u2014 no hay problemas con el disco y la red respectivamente). Dado que otros dos programas, rdiff-backup y rsnapshot, se basan en rsync y tambi\u00e9n ofrecen el rsync habitual como m\u00e9todo de recuperaci\u00f3n, tendr\u00e1n un perfil de carga y tiempo de recuperaci\u00f3n de copias de seguridad similar.<\/p>\n

Tar<\/i> fue un poco m\u00e1s r\u00e1pido, logrando hacerlo en <\/p>\n

2 minutos y 43 segundos:<\/b>\"Copia
\n
\nLa carga total del sistema fue un 20% mayor de media debido al aumento del softirq \u2014 los gastos generales de la red aumentaron.<\/p>\n

Si el archivo se comprime adicionalmente, el tiempo de recuperaci\u00f3n aumenta a 3 minutos 19 segundos con
\nesta carga en el servidor principal (descompresi\u00f3n en el lado del servidor principal):<\/b>\"Copia
\n
\nEl proceso de descompresi\u00f3n utiliza ambos n\u00facleos del procesador, ya que opera dos procesos. En general, es el resultado esperado. Tambi\u00e9n se obtuvo un resultado comparable (3 minutos y 20 segundos) al ejecutar gzip en el servidor con las copias de seguridad, el perfil de carga en el servidor principal fue bastante similar al ejecutar tar sin el compresor gzip (ver el gr\u00e1fico anterior).<\/p>\n

En rdiff-backup<\/i> se puede sincronizar la \u00faltima copia de seguridad realizada utilizando el comando rsync normal (los resultados ser\u00e1n similares), pero las copias de seguridad m\u00e1s antiguas a\u00fan deben ser restauradas utilizando el programa rdiff-backup, que logr\u00f3 la restauraci\u00f3n en 17 minutos y 17 segundos, mostrando <\/p>\n

tal carga:<\/b>\"Copia
\n
\nQuiz\u00e1s as\u00ed estaba pensado, al menos para limitar la velocidad los autores sugieren esta soluci\u00f3n<\/a><\/noindex>. El proceso de restauraci\u00f3n de la copia de seguridad toma poco menos de la mitad de un n\u00facleo, con un rendimiento proporcionalmente comparable (es decir, de 2 a 5 veces m\u00e1s lento) en disco y red con rsync.<\/p>\n

Rsnapshot<\/i> para la restauraci\u00f3n sugiere utilizar rsync normal, por lo que sus resultados ser\u00e1n similares. En general, as\u00ed fue.<\/p>\n

Burp<\/i> complet\u00f3 la tarea de restauraci\u00f3n de la copia de seguridad en 7 minutos y 2 segundos con
\ntal carga:<\/b>\"Copia
\n
\nFuncion\u00f3 bastante r\u00e1pido y, al menos, es mucho m\u00e1s conveniente que rsync limpio: no hay que recordar ninguna bandera, interfaz de l\u00ednea de comandos simple e intuitiva, soporte interno para m\u00faltiples copias, aunque es aproximadamente dos veces m\u00e1s lento. Si los datos deben ser restaurados desde la \u00faltima copia de seguridad realizada, se puede utilizar rsync, con algunas salvedades.<\/p>\n

Un programa similar mostr\u00f3 una velocidad y carga BackupPC<\/i> al activar el modo de transferencia rsync, restaurando la copia de seguridad en <\/p>\n

7 minutos y 42 segundos:<\/b>\"Copia
\n
\nSin embargo, en el modo de transferencia de datos con tar, BackupPC result\u00f3 m\u00e1s lento: en 12 minutos y 15 segundos, la carga del procesador fue significativamente m\u00e1s baja <\/p>\n

en un 50%:<\/b>\"Copia
\n
\nDuplicity<\/i> sin cifrado mostr\u00f3 resultados ligeramente mejores, completando la restauraci\u00f3n de la copia de seguridad en 10 minutos y 58 segundos. Al activar el cifrado con gpg, el tiempo de restauraci\u00f3n aumenta a 15 minutos y 3 segundos. Tambi\u00e9n al crear un repositorio para almacenar copias se puede especificar el tama\u00f1o del archivo que se utilizar\u00e1 al dividir el flujo de datos entrantes. En general, en discos duros normales, as\u00ed como debido al modo de un solo hilo, no hay una diferencia significativa. Esta podr\u00eda aparecer con diferentes tama\u00f1os de bloques, cuando se utilizan almacenamiento h\u00edbrido. La carga en el servidor principal durante la restauraci\u00f3n fue la siguiente:<\/p>\n

sin cifrado<\/b>\"Copia
\n
\ncon cifrado<\/b>\"Copia
\n
\nDuplicati<\/i> mostr\u00f3 una velocidad de restauraci\u00f3n comparable, completando en 13 minutos y 45 segundos. La verificaci\u00f3n de la correcci\u00f3n de los datos restaurados tom\u00f3 aproximadamente 5 minutos (un total de alrededor de 19 minutos). La carga en este caso fue <\/p>\n

suficientemente alta:<\/b>\"Copia
\n
\nCuando el cifrado aes se activ\u00f3 mediante herramientas internas, el tiempo de restauraci\u00f3n fue de 21 minutos y 40 segundos, y la carga de la CPU fue m\u00e1xima (\u00a1ambos n\u00facleos!) durante la restauraci\u00f3n; durante la verificaci\u00f3n de los datos estaba activo solo un hilo, utilizando un n\u00facleo del procesador. La verificaci\u00f3n de los datos despu\u00e9s de la restauraci\u00f3n tom\u00f3 los mismos 5 minutos (un total de casi 27 minutos).<\/p>\n

Resultado<\/b>\"Copia
\n
\nUn poco m\u00e1s r\u00e1pido, duplicati manej\u00f3 la restauraci\u00f3n utilizando un programa externo gpg para el cifrado, pero en general las diferencias con el modo anterior son m\u00ednimas. El tiempo de trabajo fue de 16 minutos y 30 segundos, con una verificaci\u00f3n de datos de 6 minutos. La carga fue <\/p>\n

la siguiente:<\/b>\"Copia
\n
\nAMANDA<\/i>, que utiliza tar, complet\u00f3 en 2 minutos y 49 segundos, lo cual, en principio, es bastante cercano a un tar normal. La carga en el sistema en principio <\/p>\n

es la misma:<\/b>\"Copia
\n
\nDurante la restauraci\u00f3n de la copia de seguridad con zbackup<\/i> se obtuvieron los siguientes resultados:<\/p>\n

cifrado, compresi\u00f3n lzma<\/b>\"Copia
\n
\nEl tiempo de trabajo fue de 11 minutos y 8 segundos<\/p>\n

cifrado aes, compresi\u00f3n lzma<\/b>\"Copia
\n
\nEl tiempo de trabajo fue de 14 minutos<\/p>\n

cifrado aes, compresi\u00f3n lzo<\/b>\"Copia
\n
\nEl tiempo de trabajo fue de 6 minutos y 19 segundos<\/p>\n

En general, no est\u00e1 mal. Todo depende de la velocidad del procesador en el servidor de respaldo, lo que se puede ver claramente en el tiempo de ejecuci\u00f3n del programa con diferentes compresores. Desde el servidor de respaldo se ejecutaba el tar habitual, as\u00ed que compar\u00e1ndolo, la restauraci\u00f3n funciona 3 veces m\u00e1s lenta. Quiz\u00e1s valga la pena probar la operaci\u00f3n en modo multihilo, con m\u00e1s de dos hilos.<\/p>\n

BorgBackup<\/i> en modo sin cifrado, fue un poco m\u00e1s lento que tar, tardando 2 minutos y 45 segundos, sin embargo, a diferencia de tar, se ofreci\u00f3 la opci\u00f3n de deduplicaci\u00f3n del repositorio. La carga resultante fue <\/p>\n

la siguiente:<\/b>\"Copia
\n
\nSi se activa el cifrado basado en blake, la velocidad de restauraci\u00f3n de la copia de seguridad se ralentiza un poco. El tiempo de restauraci\u00f3n en este modo es de 3 minutos y 19 segundos, y la carga fue <\/p>\n

la siguiente:<\/b>\"Copia
\n
\nEl cifrado aes funciona un poco m\u00e1s lento, con un tiempo de restauraci\u00f3n de 3 minutos y 23 segundos, y la carga no <\/p>\n

cambi\u00f3 mucho:<\/b>\"Copia
\n
\nDado que Borg puede funcionar en modo multihilo, la carga del procesador es m\u00e1xima, y al activar funciones adicionales simplemente aumenta el tiempo de trabajo. Aparentemente, vale la pena investigar el multihilo de manera similar a zbackup.<\/p>\n

Restic<\/i> se encarg\u00f3 de la restauraci\u00f3n un poco m\u00e1s lento, con un tiempo de ejecuci\u00f3n de 4 minutos y 28 segundos. La carga durante este tiempo fue <\/p>\n

as\u00ed que:<\/b>\"Copia
\n
\nAparentemente, el proceso de restauraci\u00f3n funciona en varios hilos, pero la eficiencia no es tan alta como en BorgBackup, aunque es comparable en tiempo con el rsync habitual.<\/p>\n

Con UrBackup<\/i> logr\u00f3 restaurar los datos en 8 minutos y 19 segundos, y la carga durante este tiempo fue <\/p>\n

la siguiente:<\/b>\"Copia
\n
\nIgualmente se observa una carga no muy alta, incluso m\u00e1s baja que el tar. En algunos momentos hay picos, pero no m\u00e1s que la carga de un n\u00facleo.<\/p>\n

Selecci\u00f3n y justificaci\u00f3n de criterios para la comparaci\u00f3n<\/h2>\n

\nComo se mencion\u00f3 en uno de los art\u00edculos anteriores, el sistema de copias de seguridad debe cumplir con los siguientes criterios:<\/p>\n