{"id":35003,"date":"2019-10-31T22:01:46","date_gmt":"2019-10-31T19:01:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup\/"},"modified":"2019-10-31T22:01:46","modified_gmt":"2019-10-31T19:01:46","slug":"rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Copia de seguridad, parte 4: Revisi\u00f3n y prueba de zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Copia<\/p>\n

<\/p>\n

En este art\u00edculo se discutir\u00e1n las herramientas de software para la copia de seguridad, que, dividiendo el flujo de datos en componentes individuales (chunks), forman un repositorio.<\/p>\n

<\/p>\n

Los componentes del repositorio pueden comprimirse y cifrarse adicionalmente, y lo m\u00e1s importante, pueden reutilizarse en procesos de copia de seguridad posteriores.<\/p>\n

<\/p>\n

Una copia de seguridad en un repositorio como este es una cadena nombrada de componentes interconectados, por ejemplo, basada en diferentes funciones hash.<\/p>\n

<\/p>\n

Existen varias soluciones similares; me detendr\u00e9 en 3: zbackup, borgbackup y restic.<\/p>\n

<\/a><\/noindex><\/p>\n

Resultados esperados<\/h3>\n

<\/p>\n

Dado que todos los candidatos requieren de alguna manera la creaci\u00f3n de un repositorio, uno de los factores m\u00e1s importantes ser\u00e1 evaluar el tama\u00f1o del repositorio. En un caso ideal, su tama\u00f1o no debe exceder los 13 GB seg\u00fan la metodolog\u00eda adoptada, y posiblemente menos, en caso de una buena optimizaci\u00f3n.<\/p>\n

<\/p>\n

Tambi\u00e9n es muy deseable tener la capacidad de crear copias de seguridad de archivos directamente, sin utilizar archivadores como tar, as\u00ed como trabajar con ssh\/sftp sin herramientas adicionales como rsync y sshfs.<\/p>\n

<\/p>\n

Comportamiento al crear copias de seguridad:<\/strong><\/p>\n

<\/p>\n

    \n
  1. El tama\u00f1o del repositorio ser\u00e1 igual al tama\u00f1o de los cambios, o menor.<\/li>\n
  2. Se espera una carga elevada en la CPU al utilizar compresi\u00f3n y\/o cifrado, y tambi\u00e9n es probable que haya una carga considerable en la red y en el subsistema de discos, si el proceso de archivado y\/o cifrado se realiza en el servidor de almacenamiento de copias de seguridad.<\/li>\n
  3. Si el repositorio se da\u00f1a, es probable que se presenten errores diferidos tanto al crear nuevas copias de seguridad como al intentar restaurarlas. Se deben planificar medidas adicionales para garantizar la integridad del repositorio o utilizar herramientas integradas para verificar su integridad.<\/li>\n<\/ol>\n

    <\/p>\n

    Como valor de referencia se tom\u00f3 el trabajo con tar, tal como se mostr\u00f3 en uno de los art\u00edculos anteriores.<\/p>\n

    <\/p>\n

    Pruebas de zbackup<\/h3>\n

    <\/p>\n

    El mecanismo general de funcionamiento de zbackup consiste en que el programa encuentra en el flujo de datos proporcionado zonas que contienen los mismos datos, luego opcionalmente las comprime, las cifra y guarda cada \u00e1rea solo una vez.<\/p>\n

    <\/p>\n

    Para la deduplicaci\u00f3n se utiliza una funci\u00f3n hash de 64 bits en forma de anillo con una ventana deslizante para verificar byte a byte si coincide con bloques de datos ya existentes (similar a lo que se implementa en rsync).<\/p>\n

    <\/p>\n

    Se utiliza lzma y lzo para la compresi\u00f3n en ejecuci\u00f3n multihilo, y aes para el cifrado. En las versiones m\u00e1s recientes, hay una opci\u00f3n para eliminar datos antiguos del repositorio en el futuro.
    \nEl programa est\u00e1 escrito en C++ con dependencias m\u00ednimas. El autor aparentemente se inspir\u00f3 en el estilo unix-way, por lo que el programa toma datos de stdin al crear copias de seguridad, generando un flujo de datos similar en stdout al restaurar. As\u00ed, zbackup se puede utilizar como un excelente peque\u00f1o 'ladrillo' para crear soluciones de copia de seguridad personalizadas. Por ejemplo, para el autor de este art\u00edculo, el programa ha sido la principal herramienta de respaldo para m\u00e1quinas dom\u00e9sticas desde aproximadamente 2014.<\/p>\n

    <\/p>\n

    Se utilizar\u00e1 un tar est\u00e1ndar como flujo de datos, a menos que se indique lo contrario.<\/p>\n

    \nVeamos cu\u00e1les ser\u00e1n los resultados:<\/b><\/p>\n

    La prueba se realiz\u00f3 en 2 variantes:<\/p>\n

    <\/p>\n

      \n
    1. se crea un repositorio y se ejecuta zbackup en un servidor con datos originales, luego el contenido del repositorio se transfiere al servidor de almacenamiento de copias de seguridad.<\/li>\n
    2. se crea un repositorio en el servidor de almacenamiento de copias de seguridad, se ejecuta zbackup a trav\u00e9s de ssh en el servidor de almacenamiento de copias de seguridad, y se le proporcionan datos a trav\u00e9s de un pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Los resultados de la primera variante fueron: 43m11s \u2014 al usar un repositorio no cifrado y el compresor lzma, 19m13s \u2014 al cambiar el compresor a lzo.<\/p>\n

      <\/p>\n

      La carga en el servidor con los datos originales fue la siguiente (se muestra un ejemplo con lzma, con lzo fue una imagen similar, pero la parte de rsync fue aproximadamente un cuarto del tiempo):<\/p>\n

      <\/p>\n

      \"Copia<\/a><\/noindex><\/p>\n

      <\/p>\n

      Queda claro que este proceso de copia de seguridad es adecuado solo para cambios relativamente raros y peque\u00f1os. Tambi\u00e9n es muy recomendable limitar el funcionamiento de zbackup a 1 hilo, de lo contrario, habr\u00e1 una carga bastante alta en el CPU, ya que el programa es bastante eficiente en la ejecuci\u00f3n multihilo. La carga en el disco fue baja, lo que en general, con un sistema de discos basado en ssd moderno, ser\u00e1 imperceptible. Tambi\u00e9n se observa claramente el inicio del proceso de sincronizaci\u00f3n de datos del repositorio en un servidor remoto, la velocidad de funcionamiento es comparable a un rsync normal y est\u00e1 limitada por el rendimiento del sistema de discos del servidor de almacenamiento de copias de seguridad. Una desventaja de este enfoque es el almacenamiento de un repositorio local y, como consecuencia, la duplicaci\u00f3n de datos.<\/p>\n

      <\/p>\n

      El segundo enfoque, que consiste en iniciar zbackup directamente en el servidor de almacenamiento de copias de seguridad, es m\u00e1s interesante y aplicable en la pr\u00e1ctica.<\/p>\n

      <\/p>\n

      Primero, se comprobar\u00e1 el funcionamiento sin usar cifrado con el compresor lzma:<\/p>\n

      <\/p>\n

      \"Copia<\/a><\/noindex><\/p>\n

      <\/p>\n

      El tiempo de cada ejecuci\u00f3n de prueba:<\/p>\n

      <\/p>\n

      Ejecuci\u00f3n 1
      \nEjecuci\u00f3n 2
      \nEjecuci\u00f3n 3<\/p>\n

      39m45s
      \n40m20s
      \n40m3s<\/p>\n

      7m36s
      \n8m3s
      \n7m48s<\/p>\n

      15m35s
      \n15m48s
      \n15m38s<\/p>\n

      <\/p>\n

      Si se activa el cifrado utilizando aes, los resultados est\u00e1n bastante cerca:<\/p>\n

      <\/p>\n

      \"Copia<\/a><\/noindex><\/p>\n

      <\/p>\n

      El tiempo de ejecuci\u00f3n con los mismos datos, con encriptaci\u00f3n:<\/p>\n

      <\/p>\n

      Ejecuci\u00f3n 1
      \nEjecuci\u00f3n 2
      \nEjecuci\u00f3n 3<\/p>\n

      43m40s
      \n44m12s
      \n44m3s<\/p>\n

      8m3s
      \n8m15s
      \n8m12s<\/p>\n

      15m0s
      \n15m40s
      \n15m25s<\/p>\n

      <\/p>\n

      Si se combina el cifrado con la compresi\u00f3n en lzo, queda as\u00ed:<\/p>\n

      <\/p>\n

      \"Copia<\/a><\/noindex><\/p>\n

      <\/p>\n

      Tiempo de ejecuci\u00f3n:<\/p>\n

      <\/p>\n

      Ejecuci\u00f3n 1
      \nEjecuci\u00f3n 2
      \nEjecuci\u00f3n 3<\/p>\n

      18m2s
      \n18m15s
      \n18m12s<\/p>\n

      5m13s
      \n5m24s
      \n5m20s<\/p>\n

      8m48s
      \n9m3s
      \n8m51s<\/p>\n

      <\/p>\n

      El tama\u00f1o del repositorio resultante fue relativamente constante, de 13 GB. Esto significa que la deduplicaci\u00f3n est\u00e1 funcionando correctamente. Adem\u00e1s, la aplicaci\u00f3n de lzo en datos ya comprimidos tiene un efecto notable. En t\u00e9rminos de tiempo total de ejecuci\u00f3n, zbackup se aproxima a duplicity\/duplicati, aunque todav\u00eda queda atr\u00e1s de las basadas en librsync de 2 a 5 veces.<\/p>\n

      <\/p>\n

      Las ventajas son evidentes: ahorro de espacio en disco en el servidor de almacenamiento de copias de seguridad. En cuanto a las herramientas para verificar el repositorio, el autor de zbackup no las ha previsto, se recomienda utilizar un conjunto de discos tolerante a fallos o un proveedor en la nube.<\/p>\n

      <\/p>\n

      En general, la impresi\u00f3n es bastante buena, a pesar de que el proyecto ha estado estancado durante aproximadamente 3 a\u00f1os (la \u00faltima solicitud de funciones fue hace alrededor de un a\u00f1o, pero sin respuesta).<\/p>\n

      <\/p>\n

      Pruebas de borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup es un fork de attic, otro sistema similar a zbackup. Est\u00e1 escrito en Python, tiene una lista de capacidades similar a la de zbackup, pero adicionalmente puede:<\/p>\n

      <\/p>\n