Como o GitLab ajuda você a fazer backup de grandes armazenamentos NextCloud

Oi, Habr!

Hoje quero falar sobre nossa experiência em automatizar o backup de big data de armazenamentos Nextcloud em diferentes configurações. Trabalho como posto de serviço em Molniya AK, onde fazemos gerenciamento de configuração de sistemas de TI; Nextcloud é usado para armazenamento de dados. Inclusive, com estrutura distribuída, com redundância.

Os problemas decorrentes das características das instalações são que há muitos dados. O controle de versão fornecido pelo Nextcloud, redundância, motivos subjetivos e muito mais criam muitas duplicatas.

Pré-história

Ao administrar o Nextcloud surge o problema de organizar um backup eficaz, que deve ser criptografado, pois os dados são valiosos.

Oferecemos opções para armazenar backups em nossa casa ou no cliente em máquinas separadas do Nextcloud, o que requer uma abordagem automatizada e flexível para administração.

São muitos clientes, todos com configurações diferentes, e todos em sites próprios e com características próprias. Esta é uma técnica padrão quando todo o site pertence a você e os backups são feitos a partir de coroas; não se encaixa bem.

Primeiro, vamos dar uma olhada nos dados de entrada. Nós precisamos:

• Escalabilidade em termos de um ou vários nós. Para grandes instalações utilizamos o minio como armazenamento.
• Descubra mais sobre problemas ao realizar backups.
• Você precisa manter um backup com seus clientes e/ou conosco.
• Lide com problemas de forma rápida e fácil.
• Os clientes e as instalações são muito diferentes entre si – a uniformidade não pode ser alcançada.
• A velocidade de recuperação deve ser mínima em dois cenários: recuperação total (desastre), uma pasta apagada por engano.
• A função de desduplicação é necessária.

Para resolver o problema de gerenciamento de backups, instalamos o GitLab. Mais detalhes por tackle.

É claro que não somos os primeiros a resolver tal problema, mas parece-nos que a nossa experiência prática e arduamente conquistada pode ser interessante e estamos prontos para partilhá-la.

Como nossa empresa tem uma política de código aberto, procurávamos uma solução de código aberto. Por sua vez, compartilhamos nossos desenvolvimentos e os publicamos. Por exemplo, no GitHub existe nosso plugin para Nextcloud, que disponibilizamos aos clientes, reforçando a segurança dos dados em caso de eliminação acidental ou intencional.

Ferramentas de backup

Começamos nossa busca por métodos de solução escolhendo uma ferramenta de criação de backup.

Tar + gzip regular não funciona bem - os dados são duplicados. Um incremento geralmente contém poucas alterações reais e muitos dos dados em um único arquivo são repetidos.
Há outro problema: a redundância do armazenamento distribuído de dados. Usamos minio e seus dados são basicamente redundantes. Ou você teve que fazer um backup através do próprio minio - carregá-lo e usar todos os espaçadores entre o sistema de arquivos e, não menos importante, corre-se o risco de esquecer alguns buckets e metainformações. Ou use a desduplicação.

Ferramentas de backup com duplicação estão disponíveis em código aberto (em Habré havia artigos sobre este tema) e nossos finalistas foram Borg и Resto. Nossa comparação dos dois aplicativos está abaixo, mas por enquanto contaremos como organizamos todo o esquema.

Gerenciando backups

Borg e Restic são bons, mas nenhum dos produtos possui um mecanismo de controle centralizado. Para efeitos de gestão e controlo, escolhemos uma ferramenta que já implementámos, sem a qual não conseguimos imaginar o nosso trabalho, incluindo a automação - este é o conhecido CI/CD - GitLab.

A ideia é a seguinte: o gitlab-runner é instalado em cada nó que armazena dados do Nextcloud. O executor executa um script em um agendamento que monitora o processo de backup e inicia o Borg ou Restic.

O que conseguimos? Feedback da execução, controle conveniente sobre alterações, detalhes em caso de erro.

aqui é aqui no GitHub postamos exemplos do script para diversas tarefas e acabamos anexando-o ao backup não só do Nextcloud, mas também de muitos outros serviços. Também existe um agendador se você não quiser configurá-lo manualmente (e nós não queremos) e .gitlab-ci.yml

Ainda não há como alterar o tempo limite de CI/CD na API do Gitlab, mas é pequeno. Precisa ser aumentado, digamos 1d.

Felizmente, o GitLab pode ser lançado não apenas de acordo com um commit, mas apenas de acordo com um cronograma, é exatamente disso que precisamos.

Agora sobre o script wrapper.

Definimos as seguintes condições para este script:

• Deve ser lançado tanto pelo corredor quanto manualmente a partir do console com a mesma funcionalidade.
• Deve haver manipuladores de erros:
• Código de retorno.
• procure uma string no log. Por exemplo, para nós um erro pode ser uma mensagem que o programa não considera fatal.
• Tempo limite de processamento. O prazo de entrega deve ser razoável.
• Precisamos de um registro muito detalhado. Mas apenas em caso de erro.
• Vários testes também são realizados antes de começar.
• Pequenos bônus por conveniência que achamos úteis durante o processo de suporte:
• O início e o fim são registrados no syslog da máquina local. Isso ajuda a conectar erros do sistema e operação de backup.
• Parte do log de erros, se houver, é enviada para stdout, todo o log é gravado em um arquivo separado. É conveniente olhar imediatamente para o CI e avaliar o erro se for trivial.
• Modos de depuração.

O log completo é salvo como um artefato no GitLab; se não houver erro, o log será excluído. Escrevemos o script em bash.

Teremos prazer em considerar quaisquer sugestões e comentários sobre código aberto - bem-vindos.

Как это работает

Um executor com um executor Bash é iniciado no nó de backup. De acordo com o agendador, o job CI/CD é lançado em um nabo especial. O executor inicia um script wrapper universal para tais tarefas, verifica a validade do repositório de backup, pontos de montagem e tudo o que desejamos, depois faz backup e limpa o antigo. O backup finalizado é enviado para o S3.

Trabalhamos de acordo com este esquema - é um provedor externo da AWS ou equivalente russo (é mais rápido e os dados não saem da Federação Russa). Ou instalamos um cluster minio separado para o cliente em seu site para esses fins. Geralmente fazemos isso por questões de segurança, quando o cliente não deseja que os dados saiam do seu circuito.

Não utilizamos o recurso de envio de backup via ssh. Isso não adiciona segurança e os recursos de rede do provedor S3 são muito superiores aos de nossa máquina ssh.

Para proteger sua máquina local de um hacker, já que ele pode apagar dados no S3, você deve habilitar o versionamento.
O backup sempre criptografa o backup.

Borg tem um modo não criptografado none, mas não recomendamos ativá-lo. Neste modo, além de não haver criptografia, o checksum do que está sendo escrito não é calculado, o que significa que a integridade só pode ser verificada indiretamente, por meio de índices.

Um agendador separado verifica os backups quanto à integridade dos índices e do conteúdo. A verificação é lenta e demorada, por isso a executamos separadamente uma vez por mês. Pode demorar vários dias.

leia-me em russo

A função principal

• prepare treinamento
• testcheck verificação de prontidão
• maincommand equipe principal
• forcepostscript uma função que é executada no final ou por erro. Nós o usamos para desmontar a partição.

Funções de serviço

• cleanup Registramos erros ou apagamos o arquivo de log.
• checklog analisar o log para a ocorrência de uma linha com um erro.
• ret manipulador de saída.
• checktimeout verifique o tempo limite.

Meio Ambiente

• VERBOSE=1 Exibimos erros na tela imediatamente (stdout).
• SAVELOGSONSUCCES=1 salve o log em caso de sucesso.
• INIT_REPO_IF_NOT_EXIST=1 Crie um repositório se ele não existir. Desativado por padrão.
• TIMEOUT tempo máximo para a operação principal. Você pode defini-lo como 'm', 'h' ou 'd' no final.

Modo de armazenamento para cópias antigas. Padrão:

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

Variáveis ​​dentro do script

• ERROR_STRING — string para o log de check-in em busca de erros.
• EXTRACT_ERROR_STRING — expressão para mostrar string em caso de erro.
• KILL_TIMEOUT_SIGNAL - sinal para matar se o tempo limite.
• TAIL — quantas strings com erros na tela.
• COLORMSG — cor da mensagem (amarelo padrão).

Esse script, que se chama wordpress, tem um nome condicional, o truque é que ele também faz backup do banco de dados mysql. Isso significa que pode ser usado para instalações Nexcloud de nó único, onde você também pode fazer backup do banco de dados. A comodidade não é só que tudo está em um só lugar, mas também o conteúdo do banco de dados está próximo do conteúdo dos arquivos, já que a diferença de horário é mínima.

Restic contra Borg

Também há comparações entre Borg e Restic aqui em Habré, e não tivemos a tarefa de fazer apenas mais um, mas sim o nosso. Era importante para nós como ficaria em nossos dados, com nossas especificidades. Nós os trazemos.

Nossos critérios de seleção, além dos já mencionados (desduplicação, recuperação rápida, etc.):

• Resistência ao trabalho inacabado. Verifique se há morte -9.
• Tamanho no disco.
• Requisito de recursos (CPU, memória).
• Tamanho dos blobs armazenados.
• Trabalhando com S3.
• Verificação de integridade.

Para teste, pegamos um cliente com dados reais e tamanho total de 1,6 TB.
Condições.

Borg não sabe trabalhar diretamente com S3, e montamos o disco como fusível, via patetas. Restic enviou para o próprio S3.

O Pateta funciona muito rápido e bem, e há módulo de cache de disco, o que agiliza ainda mais o trabalho. Está em fase beta e, francamente, travamos com perda de dados durante os testes (outros). Mas a conveniência é que o procedimento de backup em si não requer muita leitura, mas principalmente gravação, por isso usamos o cache apenas durante as verificações de integridade.

Para reduzir a influência da rede, utilizamos um provedor local - Yandex Cloud.

Resultados de testes de comparação.

• Kill -9 com nova reinicialização foram ambos bem-sucedidos.
• Tamanho no disco. Borg pode compactar, então os resultados são os esperados.

Backup
Tamanho

Borg
562Gb

Resto
628Gb

• Por CPU
  O Borg em si consome pouco, com compactação padrão, mas deve ser avaliado junto com o processo pateta. No total, eles são comparáveis ​​e utilizam cerca de 1,2 núcleos na mesma máquina virtual de teste.
• Memória. Restic tem aproximadamente 0,5 GB, Borg tem aproximadamente 200 MB. Mas tudo isso é insignificante em comparação com o cache de arquivos do sistema. Portanto é aconselhável alocar mais memória.
• A diferença no tamanho do blob foi impressionante.

Backup
Tamanho

Borg
cerca de 500 MB

Resto
cerca de 5 MB

• A experiência com o S3 da Restic é excelente. Trabalhar com Borg por meio de goofys não levanta dúvidas, mas foi observado que é aconselhável fazer umount após a conclusão do backup para redefinir completamente o cache. A peculiaridade do S3 é que pedaços insuficientemente bombeados nunca serão enviados para o balde, o que significa que dados preenchidos de forma incompleta levam a grandes danos.
• A verificação de integridade funciona bem em ambos os casos, mas a velocidade difere significativamente.
  Restico 3,5 horas.
  Borg, com cache de arquivo SSD de 100 GB – horas 5.Aproximadamente o mesmo resultado de velocidade se os dados estiverem em um disco local.
  Borg lê diretamente do S3 sem cache 33 horas. Monstruosamente longo.

O resultado final é que o Borg pode compactar e ter blobs maiores - o que torna o armazenamento e as operações GET/PUT no S3 mais baratos. Mas isso tem o custo de uma verificação mais complexa e mais lenta. Quanto à velocidade de recuperação, não notamos nenhuma diferença. O Restic leva um pouco mais de tempo para os backups subsequentes (depois do primeiro), mas não significativamente.

Por último, mas não menos importante, na escolha estava o tamanho da comunidade.

E escolhemos Borg.

Algumas palavras sobre compressão

Borg tem um excelente novo algoritmo de compressão em seu arsenal - zstd. A qualidade da compactação não é pior que a do gzip, mas muito mais rápida. E comparável em velocidade ao lz4 padrão.

Por exemplo, um dump de banco de dados MySQL é compactado duas vezes melhor que lz4 na mesma velocidade. No entanto, a experiência com dados reais mostra que há muito pouca diferença na taxa de compressão do nó Nextcloud.

Borg tem um modo de compactação bastante bônus - se o arquivo tiver alta entropia, a compactação não será aplicada, o que aumenta a velocidade. Habilitado por opção ao criar
-C auto,zstd
para o algoritmo zstd
Então com esta opção, em comparação com a compactação padrão, obtivemos
560 GB e 562 GB respectivamente. Os dados do exemplo acima, lembro, sem compactação o resultado é 628Gb. O resultado de uma diferença de 2 GB nos surpreendeu um pouco, mas pensamos que iríamos escolhê-lo afinal. auto,zstd.

Método de verificação de backup

De acordo com o agendador, a máquina virtual é lançada diretamente do provedor ou do cliente, o que reduz bastante a carga da rede. Pelo menos é mais barato do que aumentar você mesmo e direcionar o tráfego.

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, verificamos os arquivos com um antivírus (após o fato). Afinal, os usuários carregam coisas diferentes no Nextcloud e nem todo mundo tem antivírus. A realização de inspeções no momento do vazamento leva muito tempo e atrapalha os negócios.

A escalabilidade é alcançada executando executores em nós diferentes com tags diferentes.
Nosso monitoramento coleta status de backup por meio da API do GitLab em uma janela; se necessário, os problemas são facilmente percebidos e localizados com a mesma facilidade.

Conclusão

Como resultado, temos a certeza de que fazemos backups, que os nossos backups são válidos, os problemas que surgem com eles demoram pouco e são resolvidos ao nível do administrador de plantão. Os backups ocupam muito pouco espaço em comparação com tar.gz ou Bacula.

Fonte: habr.com