Como GitLab che axuda a facer copias de seguridade dos grandes almacenamentos de NextCloud

Ola Habr!

Hoxe quero falar da nosa experiencia na automatización da copia de seguridade de grandes datos dos almacenamentos de Nextcloud en diferentes configuracións. Traballo como estación de servizo en Molniya AK, onde facemos xestión de configuración de sistemas informáticos; Nextcloud úsase para almacenar datos. Incluíndo, cunha estrutura distribuída, con redundancia.

Os problemas derivados das características das instalacións son que hai moitos datos. A versión proporcionada por Nextcloud, a redundancia, os motivos subxectivos e moito máis crean moitos duplicados.

prehistoria

Ao administrar Nextcloud xorde o problema de organizar unha copia de seguridade efectiva, que debe ser encriptada, xa que os datos son valiosos.

Ofrecemos opcións para almacenar copias de seguridade no noso local ou no cliente en máquinas separadas de Nextcloud, o que require un enfoque automatizado flexible para a administración.

Hai moitos clientes, todos eles con configuracións diferentes, e todos nos seus propios sitios e coas súas propias características. Esta é unha técnica estándar cando todo o sitio che pertence e as copias de seguridade están feitas a partir de coroas; non encaixa ben.

En primeiro lugar, vexamos os datos de entrada. Necesitamos:

• Escalabilidade en termos dun ou varios nodos. Para grandes instalacións utilizamos minio como almacenamento.
• Descubra os problemas coa realización de copias de seguridade.
• Debes manter unha copia de seguridade cos teus clientes e/ou connosco.
• Tratar os problemas de forma rápida e sinxela.
• Os clientes e as instalacións son moi diferentes entre si - non se pode conseguir a uniformidade.
• A velocidade de recuperación debe ser mínima en dous escenarios: recuperación completa (desastre), un cartafol borrado por erro.
• Requírese a función de deduplicación.

Para resolver o problema da xestión das copias de seguridade, instalamos GitLab. Máis detalles por abordaxe.

Por suposto, non somos os primeiros en resolver un problema así, pero parécenos que a nosa experiencia práctica, arduamente gañada, pode ser interesante e estamos preparados para compartila.

Dado que a nosa empresa ten unha política de código aberto, buscabamos unha solución de código aberto. Á súa vez, compartimos as nosas novidades e publicalas. Por exemplo, en GitHub hai o noso complemento para Nextcloud, que proporcionamos aos clientes, mellorando a seguridade dos datos en caso de eliminación accidental ou intencionada.

Ferramentas de copia de seguridade

Comezamos a nosa busca de métodos de solución escollendo unha ferramenta de creación de copias de seguridade.

Tar + gzip normal non funciona ben: os datos duplícanse. Un incremento adoita conter moi poucos cambios reais e gran parte dos datos dun único ficheiro repítese.
Hai outro problema: a redundancia do almacenamento de datos distribuídos. Usamos minio e os seus datos son basicamente redundantes. Ou tiveches que facer unha copia de seguridade a través do propio minio: cargalo e empregar todos os espaciadores entre o sistema de ficheiros e, non menos importante, existe o risco de esquecer algúns dos depósitos e metainformación. Ou use a deduplicación.

As ferramentas de copia de seguridade con duplicación están dispoñibles en código aberto (en Habré había Artigo sobre este tema) e os nosos finalistas foron Borg и Restric. A nosa comparación das dúas aplicacións está a continuación, pero polo de agora contarémosche como organizamos todo o esquema.

Xestionar copias de seguridade

Borg e Restic son bos, pero ningún produto ten un mecanismo de control centralizado. A efectos de xestión e control, escollemos unha ferramenta que xa temos implementada, sen a cal non podemos imaxinar o noso traballo, incluída a automatización - este é o coñecido CI/CD - GitLab.

A idea é a seguinte: gitlab-runner está instalado en cada nodo que almacena os datos de Nextcloud. O corredor executa un script nunha programación que supervisa o proceso de copia de seguridade e inicia Borg ou Restic.

Que conseguimos? Retroalimentación da execución, control cómodo sobre os cambios, detalles en caso de erro.

Aquí aquí en GitHub publicamos exemplos do script para varias tarefas, e acabamos anexándoo á copia de seguridade non só de Nextcloud, senón tamén de moitos outros servizos. Tamén hai un programador alí se non queres configuralo manualmente (e nós non queremos) e .gitlab-ci.yml

Aínda non hai forma de cambiar o tempo de espera CI/CD na API de Gitlab, pero é pequeno. Hai que aumentar, digamos 1d.

GitLab, afortunadamente, pode lanzarse non só segundo un compromiso, senón só segundo unha programación, isto é exactamente o que necesitamos.

Agora sobre o guión do envoltorio.

Establecemos as seguintes condicións para este script:

• Debería ser lanzado tanto polo corredor como a man desde a consola coa mesma funcionalidade.
• Debe haber controladores de erros:
• código de retorno.
• buscar unha cadea no rexistro. Por exemplo, para nós un erro pode ser unha mensaxe que o programa non considera fatal.
• Tempo de espera de procesamento. O prazo de entrega debe ser razoable.
• Necesitamos un rexistro moi detallado. Pero só en caso de erro.
• Tamén se realizan varias probas antes de comezar.
• Pequenos bonos para comodidade que nos resultaron útiles durante o proceso de asistencia:
• O inicio e o final están rexistrados no syslog da máquina local. Isto axuda a conectar os erros do sistema e a operación de copia de seguridade.
• Parte do rexistro de erros, se o hai, móvese a stdout, o rexistro completo escribe nun ficheiro separado. É conveniente mirar inmediatamente CI e avaliar o erro se é trivial.
• Modos de depuración.

O rexistro completo gárdase como un artefacto en GitLab; se non hai erros, elimínase o rexistro. Escribimos o script en bash.

Estaremos encantados de considerar calquera suxestión e comentario sobre o código aberto. Benvido.

Chat isto

Un corredor cun executor Bash lánzase no nodo de copia de seguridade. Segundo o programador, o traballo CI/CD lánzase nun nabo especial. O corredor lanza un script de envoltura universal para tales tarefas, comproba a validez do repositorio de copia de seguridade, os puntos de montaxe e todo o que queremos, despois fai unha copia de seguridade e limpa o antigo. A copia de seguridade rematada envíase a S3.

Traballamos segundo este esquema: é un provedor externo de AWS ou un equivalente ruso (é máis rápido e os datos non saen da Federación Rusa). Ou instalamos un clúster minio separado para o cliente no seu sitio para estes fins. Adoitamos facelo por motivos de seguridade, cando o cliente non quere que os datos saian do seu circuíto.

Non usamos a función de enviar copia de seguranza a través de ssh. Isto non engade seguridade e as capacidades de rede do provedor S3 son moito máis altas que a nosa única máquina ssh.

Para protexer a túa máquina local dun hacker, xa que pode borrar datos en S3, debes activar o control de versións.
A copia de seguridade sempre cifra a copia de seguridade.

Borg ten un modo sen cifrar none, pero non recomendamos encarecidamente acendelo. Neste modo, non só non haberá cifrado, senón que non se calcula a suma de comprobación do que se está a escribir, o que significa que a integridade só se pode comprobar indirectamente mediante índices.

Un programador separado comproba as copias de seguridade da integridade dos índices e do contido. A comprobación é lenta e longa, polo que a realizamos por separado unha vez ao mes. Pode levar varios días.

Léame en ruso

Funcións principais

• prepare adestramento
• testcheck comprobación de preparación
• maincommand equipo central
• forcepostscript unha función que se executa ao final ou por erro. Usámolo para desmontar a partición.

Funcións do servizo

• cleanup Gravamos erros ou borramos o ficheiro de rexistro.
• checklog analizar o rexistro para a aparición dunha liña cun erro.
• ret controlador de saída.
• checktimeout comprobar o tempo de espera.

ambiente

• VERBOSE=1 Mostramos erros na pantalla inmediatamente (stdout).
• SAVELOGSONSUCCES=1 gardar o rexistro en caso de éxito.
• INIT_REPO_IF_NOT_EXIST=1 Crea un repositorio se non existe. Desactivado por defecto.
• TIMEOUT tempo máximo para a operación principal. Podes configuralo como "m", "h" ou "d" ao final.

Modo de almacenamento para copias antigas. Por defecto:

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

Variables dentro do guión

• ERROR_STRING — cadea para o rexistro de rexistro de erros.
• EXTRACT_ERROR_STRING — expresión para mostrar a cadea se erro.
• KILL_TIMEOUT_SIGNAL - sinal para matar se se esgota o tempo.
• TAIL — cantas cadeas con erros na pantalla.
• COLORMSG — cor da mensaxe (amarelo predeterminado).

Ese script, que se chama wordpress, ten un nome condicional, o seu truco é que tamén fai unha copia de seguridade da base de datos mysql. Isto significa que se pode usar para instalacións de Nexcloud dun só nodo, onde tamén pode facer unha copia de seguranza da base de datos. A conveniencia non é só que todo estea nun só lugar, senón que tamén o contido da base de datos está próximo ao contido dos ficheiros, xa que a diferenza horaria é mínima.

Restic vs Borg

Tamén hai comparacións entre Borg e Restic aquí en Habré, e non tiñamos a tarefa de facer só outra, senón a nosa. Era importante para nós como se verían nos nosos datos, cos nosos detalles. Traémolos.

Os nosos criterios de selección, ademais dos xa mencionados (desduplicación, recuperación rápida, etc.):

• Resistencia ao traballo inacabado. Comproba a morte -9.
• Tamaño no disco.
• Requisitos de recursos (CPU, memoria).
• Tamaño dos blobs almacenados.
• Traballando con S3.
• Comprobación de integridade.

Para probar, tomamos un cliente con datos reais e un tamaño total de 1,6 TB.
Condicións.

Borg non sabe como traballar directamente con S3, e montamos o disco como fusible, vía parvos. Restic enviouno ao propio S3.

Goofys funciona moi rápido e ben, e hai módulo de caché de disco, o que acelera aínda máis o traballo. Está en fase beta e, francamente, caeu coa perda de datos das probas (outros). Pero a conveniencia é que o procedemento de copia de seguridade en si non require moita lectura, pero sobre todo escritura, polo que usamos a caché só durante as comprobacións de integridade.

Para reducir a influencia da rede, usamos un provedor local: Yandex Cloud.

Comparación de resultados das probas.

• Kill -9 cun novo reinicio tiveron éxito.
• Tamaño no disco. Borg pode comprimir, polo que os resultados son os esperados.

Copia de seguranza
Tamaño

Borg
562Gb

Restric
628Gb

• Por CPU
  O propio Borg consome pouco, coa compresión predeterminada, pero debe ser avaliado xunto co proceso goofys. En total, son comparables e utilizan uns 1,2 núcleos na mesma máquina virtual de proba.
• Memoria. Restic é de aproximadamente 0,5 GB, Borg é de aproximadamente 200 MB. Pero todo isto é insignificante en comparación coa caché de ficheiros do sistema. Por iso é recomendable destinar máis memoria.
• A diferenza no tamaño do blob foi sorprendente.

Copia de seguranza
Tamaño

Borg
uns 500 MB

Restric
uns 5 MB

• A experiencia S3 de Restic é excelente. Traballar con Borg a través de goofys non suscita dúbidas, pero observouse que é recomendable desmontar unha vez que se complete a copia de seguridade para restablecer completamente a caché. A peculiaridade de S3 é que os anacos pouco bombeados nunca se enviarán ao balde, o que significa que os datos incompletos provocan danos importantes.
• A comprobación de integridade funciona ben en ambos os casos, pero a velocidade difire significativamente.
  Resto 3,5 horas.
  Borg, cunha caché de ficheiros SSD de 100 GB - 5 horas.Resulta aproximadamente a mesma velocidade se os datos están nun disco local.
  Borg le directamente desde S3 sen caché 33 horas. Monstruosamente longo.

A conclusión é que Borg pode comprimir e ten burbullas máis grandes, o que fai que as operacións de almacenamento e GET/PUT en S3 sexan máis baratas. Pero isto supón unha verificación máis complexa e lenta. En canto á velocidade de recuperación, non notamos ningunha diferenza. Restic leva as copias de seguridade posteriores (despois da primeira) un pouco máis, pero non de forma significativa.

Por último, pero non menos importante, na elección foi o tamaño da comunidade.

E escollemos borg.

Algunhas palabras sobre compresión

Borg ten un novo algoritmo de compresión excelente no seu arsenal: zstd. A calidade da compresión non é peor que gzip, pero moito máis rápida. E comparable en velocidade ao lz4 predeterminado.

Por exemplo, un volcado de base de datos MySQL comprime dúas veces mellor que lz4 á mesma velocidade. Non obstante, a experiencia con datos reais mostra que hai moi pouca diferenza na relación de compresión do nodo Nextcloud.

Borg ten un modo de compresión bastante extra: se o ficheiro ten alta entropía, a compresión non se aplica en absoluto, o que aumenta a velocidade. Activado por opción ao crear
-C auto,zstd
para o algoritmo zstd
Entón, con esta opción, en comparación coa compresión predeterminada, conseguimos
560 Gb e 562 Gb respectivamente. Os datos do exemplo anterior, permíteme lembrarche, sen compresión o resultado é 628Gb. O resultado dunha diferenza de 2 GB sorprendeunos un pouco, pero pensamos que o elixiríamos despois de todo. auto,zstd.

Método de verificación de copia de seguridade

Segundo o planificador, a máquina virtual lánzase directamente desde o provedor ou desde o cliente, o que reduce moito a carga da rede. Polo menos é máis barato que levantalo vostede mesmo e conducir 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 o mesmo esquema, comprobamos os ficheiros cun antivirus (despois do feito). Despois de todo, os usuarios cargan cousas diferentes a Nextcloud e non todos teñen un antivirus. A realización de inspeccións no momento de verter leva moito tempo e interfire co negocio.

A escalabilidade conséguese executando corredores en diferentes nodos con diferentes etiquetas.
O noso seguimento recolle os estados de copia de seguranza a través da API de GitLab nunha soa xanela; se é necesario, os problemas notan facilmente e localízanse facilmente.

Conclusión

Como resultado, sabemos con certeza que facemos copias de seguridade, que as nosas copias de seguridade son válidas, os problemas que xurden con elas levan pouco tempo e resólvense a nivel do administrador de obrigas. As copias de seguranza ocupan moi pouco espazo en comparación con tar.gz ou Bacula.

Fonte: www.habr.com