Cómo GitLab te ayuda a realizar copias de seguridad de grandes almacenamientos de NextCloud

¡Hola, Habr!

Hoy quiero hablar sobre nuestra experiencia en la automatización de la copia de seguridad de big data desde los almacenamientos de Nextcloud en diferentes configuraciones. Trabajo como estación de servicio en Molniya AK, donde gestionamos la configuración de los sistemas de TI; Nextcloud se utiliza para el almacenamiento de datos. Incluso, con estructura distribuida, con redundancia.

El problema que surge por las características de las instalaciones es que hay muchos datos. El control de versiones proporcionado por Nextcloud, la redundancia, motivos subjetivos y más crean muchos duplicados.

Prehistoria

A la hora de administrar Nextcloud surge el problema de organizar una copia de seguridad eficaz, la cual debe estar cifrada, ya que los datos son valiosos.

Ofrecemos opciones para almacenar copias de seguridad en nuestra casa o en la del cliente en máquinas separadas de Nextcloud, lo que requiere un enfoque automatizado flexible para la administración.

Hay muchos clientes, todos ellos con diferentes configuraciones, y todos en sus propios sitios y con sus propias características. Esta es una técnica estándar cuando todo el sitio te pertenece y las copias de seguridad están hechas de coronas; no encaja bien.

Primero, veamos los datos de entrada. Nosotros necesitamos:

• Escalabilidad en términos de un nodo o varios. Para grandes instalaciones utilizamos minio como almacenaje.
• Obtenga información sobre los problemas al realizar copias de seguridad.
• Necesitas mantener un respaldo con tus clientes y/o con nosotros.
• Resuelva los problemas de forma rápida y sencilla.
• Los clientes y las instalaciones son muy diferentes entre sí, no se puede lograr la uniformidad.
• La velocidad de recuperación debe ser mínima en dos escenarios: recuperación completa (desastre), una carpeta borrada por error.
• Se requiere función de deduplicación.

Para solucionar el problema de la gestión de copias de seguridad, instalamos GitLab. Más detalles por tackle.

Por supuesto, no somos los primeros en resolver este problema, pero nos parece que nuestra experiencia práctica, obtenida con tanto esfuerzo, puede ser interesante y estamos dispuestos a compartirla.

Dado que nuestra empresa tiene una política de código abierto, buscábamos una solución de código abierto. A su vez, compartimos nuestros desarrollos y los publicamos. Por ejemplo, en GitHub hay nuestro complemento para Nextcloud, que proporcionamos a los clientes, mejorando la seguridad de los datos en caso de eliminación accidental o intencional.

Herramientas de respaldo

Comenzamos nuestra búsqueda de métodos de solución eligiendo una herramienta de creación de copias de seguridad.

Tar + gzip normal no funciona bien: los datos están duplicados. Un incremento suele contener muy pocos cambios reales y gran parte de los datos de un único archivo se repiten.
Hay otro problema: la redundancia del almacenamiento de datos distribuido. Usamos minio y sus datos son básicamente redundantes. O tuvo que hacer una copia de seguridad a través del propio minio: cárguela y use todos los espaciadores entre el sistema de archivos y, no menos importante, existe el riesgo de olvidarse de algunos de los depósitos y la metainformación. O utilice la deduplicación.

Las herramientas de copia de seguridad con duplicación están disponibles en código abierto (en Habré había Artículo sobre este tema) y nuestros finalistas fueron Borg и descanso. Nuestra comparación de las dos aplicaciones se encuentra a continuación, pero por ahora le diremos cómo organizamos todo el esquema.

Administrar copias de seguridad

Borg y Restic son buenos, pero ninguno de los productos tiene un mecanismo de control centralizado. Para la gestión y el control, elegimos una herramienta que ya tenemos implementada, sin la cual no podemos imaginar nuestro trabajo, incluida la automatización: este es el conocido CI/CD: GitLab.

La idea es la siguiente: gitlab-runner se instala en cada nodo que almacena datos de Nextcloud. El ejecutor ejecuta un script según un cronograma que monitorea el proceso de copia de seguridad e inicia Borg o Restic.

¿Qué obtuvimos? Comentarios sobre la ejecución, control conveniente sobre los cambios, detalles en caso de error.

aquí está aquí en GitHub Publicamos ejemplos del script para varias tareas y terminamos adjuntándolo a la copia de seguridad no solo de Nextcloud, sino también de muchos otros servicios. También hay un programador allí si no desea configurarlo manualmente (y nosotros no queremos) y .gitlab-ci.yml

Todavía no hay forma de cambiar el tiempo de espera de CI/CD en la API de Gitlab, pero es pequeño. Es necesario aumentarlo, digamos a 1d.

GitLab, afortunadamente, puede iniciarse no solo según un compromiso, sino también según un cronograma, esto es exactamente lo que necesitamos.

Ahora sobre el script contenedor.

Establecemos las siguientes condiciones para este script:

• Debe lanzarse tanto por el corredor como manualmente desde la consola con la misma funcionalidad.
• Debe haber controladores de errores:
• código de retorno.
• busque una cadena en el registro. Por ejemplo, para nosotros un error puede ser un mensaje que el programa no considera fatal.
• Tiempo de espera de procesamiento. El plazo de entrega debe ser razonable.
• Necesitamos un registro muy detallado. Pero sólo en caso de error.
• También se realizan una serie de pruebas antes de comenzar.
• Pequeñas bonificaciones por comodidad que nos resultaron útiles durante el proceso de soporte:
• El inicio y el final se registran en el syslog de la máquina local. Esto ayuda a conectar los errores del sistema y la operación de copia de seguridad.
• Parte del registro de errores, si lo hay, se envía a la salida estándar y el registro completo se escribe en un archivo separado. Es conveniente observar inmediatamente el CI y evaluar el error si es trivial.
• Modos de depuración.

El registro completo se guarda como un artefacto en GitLab; si no hay ningún error, el registro se elimina. Escribimos el script en bash.

Estaremos encantados de considerar cualquier sugerencia y comentario sobre el código abierto: bienvenido.

¿Cómo funciona esto

Se inicia un corredor con un ejecutor Bash en el nodo de respaldo. Según el programador, el trabajo CI/CD se inicia en un nabo especial. El ejecutor inicia un script contenedor universal para tales tareas, verifica la validez del repositorio de respaldo, los puntos de montaje y todo lo que queremos, luego realiza una copia de seguridad y limpia el anterior. La copia de seguridad terminada se envía al S3.

Trabajamos de acuerdo con este esquema: es un proveedor externo de AWS o un equivalente ruso (es más rápido y los datos no salen de la Federación de Rusia). O instalamos un clúster minio separado para el cliente en su sitio para estos fines. Normalmente hacemos esto por motivos de seguridad, cuando el cliente no quiere que los datos salgan de su circuito en absoluto.

No utilizamos la función de enviar copias de seguridad a través de ssh. Esto no agrega seguridad y las capacidades de red del proveedor S3 son mucho mayores que las de nuestra única máquina ssh.

Para proteger su máquina local de un pirata informático, ya que puede borrar datos en S3, debe habilitar el control de versiones.
La copia de seguridad siempre cifra la copia de seguridad.

Borg tiene un modo no cifrado none, pero no recomendamos encarecidamente encenderlo. En este modo, no sólo no habrá cifrado, sino que tampoco se calcula la suma de comprobación de lo que se está escribiendo, lo que significa que la integridad sólo se puede comprobar indirectamente, utilizando índices.

Un programador separado verifica las copias de seguridad para verificar la integridad de los índices y el contenido. La verificación es lenta y larga, por lo que la realizamos por separado una vez al mes. Pueden pasar varios días.

Léame en ruso

La función principal

• prepare formación
• testcheck verificación de preparación
• maincommand equipo central
• forcepostscript una función que se ejecuta al final o por error. Lo usamos para desmontar la partición.

Funciones de servicio

• cleanup Registramos errores o borramos el archivo de registro.
• checklog analizar el registro para detectar la aparición de una línea con un error.
• ret controlador de salida.
• checktimeout comprobar el tiempo de espera.

Entorno

• VERBOSE=1 Mostramos errores en la pantalla inmediatamente (stdout).
• SAVELOGSONSUCCES=1 guarde el registro en caso de éxito.
• INIT_REPO_IF_NOT_EXIST=1 Cree un repositorio si no existe. Deshabilitado por defecto.
• TIMEOUT tiempo máximo para la operación principal. Puede configurarlo como 'm', 'h' o 'd' al final.

Modo de almacenamiento para copias antiguas. Por defecto:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Variables dentro del script

• ERROR_STRING — cadena para el registro de entrada en caso de error.
• EXTRACT_ERROR_STRING — expresión para mostrar cadena en caso de error.
• KILL_TIMEOUT_SIGNAL — señal para matar si se agota el tiempo.
• TAIL — cuántas cadenas con errores aparecen en la pantalla.
• COLORMSG — color del mensaje (amarillo predeterminado).

Ese script, que se llama wordpress, tiene un nombre condicional, su truco es que también realiza una copia de seguridad de la base de datos mysql. Esto significa que se puede utilizar para instalaciones Nexcloud de un solo nodo, donde también puede realizar una copia de seguridad de la base de datos. La conveniencia no es solo que todo esté en un solo lugar, sino que también el contenido de la base de datos esté cerca del contenido de los archivos, ya que la diferencia horaria es mínima.

Restic contra Borg

También hay comparaciones entre Borg y Restic. aquí en Habré, y no teníamos la tarea de hacer uno más, sino el nuestro. Para nosotros era importante cómo se vería en nuestros datos, con nuestros detalles. Nosotros los traemos.

Nuestros criterios de selección, además de los ya mencionados (deduplicación, recuperación rápida, etc.):

• Resistencia al trabajo inacabado. Comprueba si hay muerte -9.
• Tamaño en disco.
• Requisito de recursos (CPU, memoria).
• Tamaño de los blobs almacenados.
• Trabajando con S3.
• Verificación de integridad.

Para las pruebas, tomamos un cliente con datos reales y un tamaño total de 1,6 TB.
Condiciones.

Borg no sabe cómo trabajar directamente con S3, y montamos el disco como fusible, a través de tontos. Restic lo envió al propio S3.

Goofys funciona muy rápido y bien, y hay módulo de caché de disco, lo que agiliza aún más el trabajo. Está en la etapa beta y, francamente, tuvimos un problema con la pérdida de datos durante las pruebas (otras). Pero la conveniencia es que el procedimiento de copia de seguridad en sí no requiere mucha lectura, sino principalmente escritura, por lo que usamos el caché solo durante las comprobaciones de integridad.

Para reducir la influencia de la red, utilizamos un proveedor local: Yandex Cloud.

Resultados de pruebas comparativas.

• Matar a -9 con un reinicio adicional fue exitoso.
• Tamaño en disco. Borg puede comprimir, por lo que los resultados son los esperados.

Backuper
tamaño

Borg
562Gb

descanso
628Gb

• Por CPU
  Borg en sí consume poco, con compresión predeterminada, pero debe evaluarse junto con el proceso de Goofys. En total, son comparables y utilizan aproximadamente 1,2 núcleos en la misma máquina virtual de prueba.
• Memoria. Restic tiene aproximadamente 0,5 GB, Borg tiene aproximadamente 200 MB. Pero todo esto es insignificante en comparación con el caché de archivos del sistema. Por eso es recomendable asignar más memoria.
• La diferencia en el tamaño de las burbujas fue sorprendente.

Backuper
tamaño

Borg
alrededor de 500 MB

descanso
alrededor de 5 MB

• La experiencia S3 de Restic es excelente. Trabajar con Borg a través de Goofys no plantea ninguna pregunta, pero se ha observado que es recomendable desmontarlo una vez completada la copia de seguridad para restablecer completamente el caché. La peculiaridad de S3 es que los fragmentos insuficientemente bombeados nunca se enviarán al depósito, lo que significa que los datos no completados por completo provocan daños importantes.
• La verificación de integridad funciona bien en ambos casos, pero la velocidad difiere significativamente.
  restico 3,5 horas.
  Borg, con un caché de archivos SSD de 100 GB – 5 horas.Aproximadamente la misma velocidad resulta si los datos están en un disco local.
  Borg lee directamente desde S3 sin caché 33 horas. Monstruosamente largo.

La conclusión es que Borg puede comprimir y tiene blobs más grandes, lo que hace que el almacenamiento y las operaciones GET/PUT en S3 sean más baratos. Pero esto tiene el costo de una verificación más compleja y más lenta. En cuanto a la velocidad de recuperación, no notamos ninguna diferencia. Restic tarda un poco más en realizar copias de seguridad posteriores (después de la primera), pero no de forma significativa.

Por último, pero no menos importante a la hora de elegir, estaba el tamaño de la comunidad.

Y elegimos borg.

Algunas palabras sobre la compresión.

Borg tiene un nuevo y excelente algoritmo de compresión en su arsenal: zstd. La calidad de la compresión no es peor que la de gzip, pero sí mucho más rápida. Y comparable en velocidad al lz4 predeterminado.

Por ejemplo, un volcado de base de datos MySQL se comprime dos veces mejor que lz4 a la misma velocidad. Sin embargo, la experiencia con datos reales muestra que hay muy poca diferencia en la relación de compresión del nodo Nextcloud.

Borg tiene un modo de compresión bastante adicional: si el archivo tiene una entropía alta, entonces no se aplica compresión en absoluto, lo que aumenta la velocidad. Habilitado por opción al crear
-C auto,zstd
para el algoritmo zstd
Entonces con esta opción, en comparación con la compresión predeterminada, obtuvimos
560Gb y 562Gb respectivamente. Los datos del ejemplo anterior, déjame recordarte, sin compresión el resultado es 628Gb. El resultado de una diferencia de 2GB nos sorprendió un poco, pero pensamos que después de todo lo elegiríamos. auto,zstd.

Método de verificación de respaldo

Según el programador, la máquina virtual se inicia directamente desde el proveedor o desde el cliente, lo que reduce en gran medida la carga de la red. Al menos es más barato que crearlo usted mismo y generar tráfico.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Usando el mismo esquema, verificamos los archivos con un antivirus (después del hecho). Después de todo, los usuarios suben cosas diferentes a Nextcloud y no todos tienen un antivirus. Realizar inspecciones en el momento del vertido lleva demasiado tiempo e interfiere con el negocio.

La escalabilidad se logra ejecutando corredores en diferentes nodos con diferentes etiquetas.
Nuestro monitoreo recopila estados de respaldo a través de la API de GitLab en una ventana; si es necesario, los problemas se detectan fácilmente y se localizan con la misma facilidad.

Conclusión

Como resultado, sabemos con certeza que hacemos copias de seguridad, que nuestras copias de seguridad son válidas, los problemas que surgen con ellas toman poco tiempo y se resuelven a nivel del administrador de turno. Las copias de seguridad ocupan muy poco espacio en comparación con tar.gz o Bacula.

Fuente: habr.com