Organizações que usam uma instância GitLab autogerenciada geralmente contam com ela para manter seu código-fonte, gerenciamento de projeto e ferramentas operacionais. É vital ter backups em funcionamento para que seus dados fiquem protegidos em caso de falha de hardware, atualização malsucedida do servidor ou comprometimento malicioso.
O GitLab possui um componente de backup integrado que pode criar um arquivo completo dos dados de instalação. O arquivo pode ser restaurado em um novo servidor executando a mesma versão do GitLab.
Veja aqui como configurar backups em seu sistema de arquivos local ou em um bucket do Amazon S3. Essas etapas devem ser usadas com as edições omnibus do GitLab. Você precisará modificar os comandos CLI do GitLab prefixando-os com bundle exec rake se sua instância foi construída a partir do código-fonte.
Fazendo um backup sob demanda
A maneira mais simples de criar um backup é com o comando de criação sob demanda. Execute o seguinte comando em seu shell:
sudo gitlab-backup criado
Isso funciona no GitLab 12.2 e mais recente. As versões mais antigas devem usar uma versão alternativa:
sudo gitlab-rake gitlab: backup: criar
Publicidade
O backup será salvo como um arquivo tar no diretório definido pelo seu arquivo de configuração GitLab. As instalações omnibus usam como padrão / var / opt / gitlab / backups. Cada arquivo de backup é nomeado com seu carimbo de data / hora de criação e versão do GitLab.
O que está incluído em um backup?
O utilitário de backup integrado do GitLab exporta dados criados por usuários em sua instância do GitLab. Isso inclui tudo no banco de dados GitLab e seus repositórios Git em disco.
Restaurar o backup irá restabelecer seus projetos, grupos, usuários, problemas, anexos de arquivos carregados e logs de trabalhos de CI / CD. O backup também cobre sites de páginas GitLab e imagens Docker carregadas no registro de contêiner integrado.
Pacotes adicionados aos registros de pacote do GitLab &’ s não são suportados. Você deve configurar sua instalação para salvar pacotes em um provedor de armazenamento de objeto externo se precisar que eles sejam recuperáveis sem uma reconstrução manual.
Criação de uma programação de backup
Não há mecanismo integrado para definir uma programação de backup automatizada. Você deve configurar sua própria tarefa cron para executar o comando de backup mostrado acima.
Execute sudo crontab -e para abrir o crontab do root e adicione o seguinte conteúdo ao arquivo:
0 21 * * * / opt / gitlab / bin / gitlab-backup criar CRON = 1
Publicidade
Salve e feche o arquivo para aplicar a alteração do crontab. Este exemplo criará um novo backup às 21h todos os dias. Definir a variável de ambiente CRON instrui o GitLab a ocultar a exibição do andamento do backup para que você não receba e-mails cron redundantes com a saída do trabalho.
Usar esta tarefa como está irá manter todos os backups indefinidamente até que você os limpe manualmente. Isso pode consumir rapidamente muito espaço de armazenamento se você estiver executando uma instância GitLab ativa contendo grandes projetos.
Uma chave de configuração opcional permite excluir arquivos antigos como parte do script de criação de backup. Abra seu arquivo de configuração GitLab em /etc/gitlab/gitlab. rb. Pesquise por backup_keep_time, descomente a linha e defina por quantos segundos você deseja manter cada backup.
gitlab_rails & # 91; ‘backup_keep_time’ & # 93; = 432000
Aqui, os backups são retidos por cinco dias. O GitLab excluirá todos os arquivos elegíveis no diretório de backup sempre que o comando de criação de backup for executado.
Você precisa reconfigurar o GitLab sempre que o arquivo de configuração for alterado. Execute sudo gitlab-ctl reconfigure para aplicar sua nova configuração.
Excluindo tipos de dados
Às vezes, você pode querer executar um backup com um subconjunto dos tipos de dados suportados. Definir a variável de ambiente SKIP permite excluir operações específicas da execução, reduzindo seu arquivo final.
Publicidade
A variável de ambiente usa uma lista separada por vírgulas de tipos de dados. Você pode encontrar as opções com suporte atualmente no wiki do GitLab.
Veja como fazer backup de tudo, exceto imagens de registro de contêiner:
sudo gitlab-backup criar SKIP = registro
Excluir o conteúdo do registro costuma ser uma maneira fácil de reduzir significativamente o tamanho do backup e acelerar a velocidade de criação. Uma equipe com vários projetos ativos construindo várias imagens Docker por dia pode rapidamente acumular gigabytes de dados de registro. Excluí-los do backup não é necessariamente um risco muito grande, pois você sempre pode reconstruir as imagens usando o Dockerfile em seu repositório.
Fazendo backup para S3
O GitLab pode salvar automaticamente seus backups em provedores de armazenamento de objetos compatíveis com S3. Remova o comentário das linhas backup_upload_connection e adicione seus detalhes de conexão:
gitlab_rails & # 91; ‘backup_upload_connection’ & # 93; = & # 123; ” provedor ” = > ” AWS & quot ;, ” região ” = ” ” eu-west-1 & quot ;, ” aws_access_key_id ” = > ” access_key & quot ;, ” aws_secret_key ” > ” chave_ secreta & quot ;, # ” ponto final ” = > ” https: //…” & # 125;
Adicione sua própria chave de acesso, chave secreta e ID da região AWS para completar a conexão. Você também deve definir o campo de endpoint se estiver se conectando a um provedor que não seja AWS. Forneça a URL do seu servidor de armazenamento de objetos para que o GitLab possa fazer upload para ele.
Você também deve definir uma chave backup_upload_remote_directory. Encontre esta linha no arquivo de configuração, descomente-o e defina um nome de intervalo S3 para carregar seus backups em:
gitlab_rails & # 91; ‘backup_upload_remote_directory’ & # 93; = ‘gitlab-backups’;
Execute sudo gitlab-ctl reconfigure para aplicar suas alterações.
O comando de criação de backup irá agora enviar seus arquivos para o balde S3 configurado. Isso dá a você uma redundância muito maior, armazenando seus backups fora do local, protegendo você contra falhas físicas de hardware.
Publicidade
Esteja ciente de que a configuração backup_keep_time não é compatível quando você está usando o armazenamento S3. Só se aplica a arquivos de backup armazenados localmente. Você pode conseguir algo semelhante usando as políticas de expiração integradas do S3 &’ para excluir automaticamente os uploads depois de decorrido um determinado período de tempo.
A estratégia de cópia de segurança
A estratégia de backup padrão do GitLab é transmitir dados continuamente para o arquivo tar. Isso geralmente funciona bem, mas pode apresentar problemas em instâncias do GitLab muito ativas. Os dados podem mudar no diretório de origem antes de chegar ao arquivo, fazendo com que o tar ignore-o com um erro de arquivo alterado conforme o lemos.
Para combater isso, o GitLab introduziu uma estratégia de cópia opcional. Isso copia todos os dados de backup elegíveis para um diretório temporário e, em seguida, transmite o conteúdo copiado para o arquivo tar final. Isso garante que o tar não esteja lendo de uma instância ativa do GitLab, mas tem o efeito colateral de aumentar temporariamente o consumo de armazenamento do GitLab. O desempenho do backup também pode sofrer um impacto perceptível, especialmente em dispositivos de armazenamento mais lentos.
A estratégia de cópia é ativada definindo a variável de ambiente STRATEGY ao executar o comando backup. Você deve verificar se há espaço em disco suficiente disponível. O GitLab executará o backup em estágios de tipo de dados, portanto, você só precisa dobrar o tamanho do seu maior tipo de dados. Por exemplo, se você tiver 5 GB de repositórios Git e 10 GB de registros de contêineres, precisará ter 10 GB de espaço extra disponível, não 15 GB.
sudo gitlab-backup criar STRATEGY = copiar
Não se esqueça: faça backup do seu arquivo de configuração!
O script de backup do
GitLab gerencia apenas dados criados pelo usuário. Existem dois outros arquivos essenciais para a operação do seu servidor GitLab. Também é necessário fazer backup deles para garantir a recuperação bem-sucedida de sua instância.
- /etc/gitlab/gitlab. rb – Este é o seu arquivo de configuração do GitLab. Todas as instalações, exceto a mais básica, geralmente adquirem muitas modificações com o tempo. Fazer backup desse arquivo permite que você o coloque em uma nova instalação do GitLab sem ter que começar do zero.
- /etc/gitlab/gitlab-secrets. json – Este arquivo deve ser copiado. Inclui sua chave de criptografia de banco de dados, segredos usados para autenticação de dois fatores e outros dados confidenciais não recuperáveis. Colocar este arquivo incorretamente pode tornar impossível qualquer esforço de recuperação, mesmo se você tiver um arquivo de backup em funcionamento disponível.
Você pode usar outra tarefa cron para fazer backup desses dois arquivos. Eles devem ser copiados de seu servidor para que você ainda possa acessá-los se enfrentar uma falha de hardware.
Conclusão
Os backups são vitais para qualquer administrador do GitLab. O software geralmente é essencial para todas as equipes em uma organização, portanto, qualquer tempo de inatividade inesperado pode causar sérios desafios operacionais.
Publicidade
O GitLab vem com tudo que você precisa para fazer backups regulares. A melhor abordagem é criar uma tarefa Cron que execute o script integrado em uma programação regular. Salve seus arquivos de backup em armazenamento de objeto externo para proteção contra perda, falha ou dano de hardware. Lembre-se de fazer backup manualmente de seus arquivos de configuração e segredos do GitLab, caso contrário, o processo de recuperação será significativamente mais complicado.
