Cinco técnicas de backup e nenhuma confiável: a noite em que o GitLab apagou o próprio banco de dados

Ter backups não é o mesmo que conseguir restaurar. A diferença só aparece no dia em que se precisa deles, e nesse dia já é tarde para descobri-la. Em janeiro de 2017, um serviço em nuvem de hospedagem de código descobriu isso ao vivo, com milhares de pessoas assistindo.

Um esclarecimento antes de começar: a Hábil não participou deste caso. Contamos o caso com o que o GitLab publicou no postmortem público e com o que a imprensa especializada reportou.

Terça-feira, passadas as onze da noite

É 31 de janeiro de 2017. O GitLab.com, o serviço em nuvem onde equipes de software guardam o código, as tarefas pendentes e as revisões, está há horas com problemas. Desde a tarde, o banco de dados principal está sob uma carga anormal. A equipe suspeita de spam. Os usuários não conseguem publicar comentários [1][2].

Por trás dessa carga há uma coincidência que ninguém tinha previsto. Além do spam, um processo para apagar os dados de um funcionário da própria empresa foi agendado por engano, disparado por uma denúncia de abuso [1]. As duas coisas juntas sufocam o banco.

Por volta das onze da noite (horário UTC), a pressão deixa uma consequência mais séria. O banco principal tem uma réplica: uma segunda cópia que se mantém em dia recebendo cada alteração, pronta para assumir o lugar da primeira se ela falhar. Com a carga, a réplica fica para trás. E quando tenta se atualizar, as alterações de que precisava já não estão lá: o banco principal as descartou antes que a réplica as recebesse [1].

Não há saída automática dali. A réplica precisa ser reconstruída à mão [1].

Um engenheiro põe mãos à obra. Apaga o diretório de dados da réplica para copiá-lo de novo a partir do principal. Executa a ferramenta que faz essa cópia, e a ferramenta não responde. Parece travada. Ele ajusta parâmetros. O banco se recusa a reiniciar. Ajusta outros [1].

O que ninguém sabe naquele momento é que a ferramenta não estava travada: estava esperando em silêncio que o banco principal começasse a enviar dados, algo que pode levar vários minutos. Esse comportamento não constava nos procedimentos da equipe nem na documentação oficial [1][2].

É noite na Holanda, onde o engenheiro trabalha [4]. O problema já dura horas. Ele acredita que a cópia que falhou deixou lixo no diretório da réplica e decide limpá-lo mais uma vez.

Digita o comando de exclusão. Executa.

Um ou dois segundos depois, percebe: não está na réplica. Está no banco principal [1][2].

Interrompe o comando. Mas o comando de exclusão não pede confirmação e não pode ser desfeito. De cerca de 300 GB de dados, restam uns 4,5 GB [2][4].

A busca

Nesse momento, a pergunta de todos é a mesma: de onde vamos restaurar?

O GitLab não era uma empresa improvisada. Tinha, no papel, várias camadas de proteção. A equipe começa a revisá-las uma por uma e as anota em um documento do Google que torna público para que qualquer pessoa acompanhe o andamento [1][3].

O backup diário na nuvem. A cada 24 horas, uma tarefa agendada devia extrair um dump completo do banco e guardá-lo em um armazenamento da Amazon (S3). A equipe abre o armazenamento. Está vazio [1][2][4].

Por quê? A tarefa rodava a ferramenta de dump na versão 9.2 contra um banco na versão 9.6. A ferramenta escolhia a versão de acordo com o diretório de dados do servidor onde rodava, e essa tarefa rodava em um servidor de aplicação, que não tinha diretório de dados. Então pegava a versão antiga e falhava [1].

Falhava todos os dias. E ninguém ficava sabendo? A tarefa enviava, sim, um e-mail quando falhava. Mas esses e-mails eram rejeitados: o servidor que os recebia os devolvia porque os e-mails das tarefas agendadas não tinham o DMARC ativado, um mecanismo que os servidores de e-mail usam para verificar se uma mensagem é legítima [1][5]. O alarme existia. Nunca chegou a ninguém.

Os snapshots de disco da nuvem. O GitLab rodava na época sobre o Microsoft Azure, que pode tirar fotos periódicas de um disco inteiro. Estavam ativados para os servidores de arquivos, mas não para os de banco de dados: a equipe supôs que os outros backups bastavam [1].

A réplica. É a primeira coisa em que qualquer um pensaria. Mas uma réplica não é um backup: copia tudo, inclusive os erros, e serve para substituir um servidor que caiu, não para voltar no tempo. Além disso, neste caso ela já não existia: o diretório dela tinha sido apagado minutos antes, como parte da reconstrução [1].

Os snapshots do servidor. Restava uma última camada: fotos do disco tiradas com o LVM, o gerenciador de volumes lógicos do sistema. Eram tiradas a cada 24 horas, e não como backup, mas para copiar os dados reais para um ambiente de testes (staging). O mais recente agendado tinha quase um dia [1].

Naquela madrugada, o documento público, que contava separadamente os dumps diários e a cópia deles no S3, resumiu a situação em uma frase que correu a internet:

«De cinco técnicas de backup e replicação implantadas, nenhuma funciona de forma confiável, ou sequer estava configurada.» (tradução própria) [2][4]

Seis horas de sorte

E então aparece a única boa notícia da noite, e ela é quase um acidente.

Naquele mesmo dia, por volta das 17h20 UTC, um engenheiro tinha tirado à mão um snapshot do banco para carregá-lo no ambiente de testes. Tirou-o para ter dados recentes nos testes de uma ferramenta para distribuir a carga do banco de dados [1]. Essa cópia, feita para outra coisa, era agora a única com seis horas de idade, e não vinte e quatro.

A equipe escolhe essa cópia. A alternativa era perder quase um dia inteiro [1].

Falta trazê-la de volta. E aí surge outra decisão que alguém tomou tempos antes, por boas razões. O ambiente de testes rodava em discos econômicos do Azure, sem armazenamento de alto desempenho, para economizar. Esses discos estavam limitados a cerca de 60 Mbps. Copiar os dados do ambiente de testes para o servidor principal levou cerca de 18 horas. O gargalo não era a rede nem o processador: eram os discos [1].

Dezoito horas de cópia, com o GitLab.com fora do ar.

A recuperação, ao vivo

O que o GitLab fez durante essas horas é a outra metade desta história, e é ela que o distingue.

Em vez de fechar as portas e publicar um comunicado lacônico no fim, informou em público o que acontecia enquanto se recuperava. A conta de status no Twitter disse sem rodeios: «Apagamos por acidente dados de produção e talvez tenhamos de restaurar a partir de um backup» (tradução própria) [1][2]. O documento de trabalho, com as anotações da equipe e a lista do que tinha falhado, ficou à vista de todos [1][3]. E a recuperação foi transmitida no YouTube. Chegou a ter cerca de 5.000 espectadores simultâneos e foi, durante várias horas, a segunda transmissão ao vivo mais assistida da plataforma [1].

Em 1º de fevereiro, por volta das 17h00 UTC, o banco estava restaurado, ainda sem os webhooks (os avisos automáticos que o GitLab envia a outros sistemas quando algo muda). Por volta das seis da tarde, o serviço estava de volta, com os últimos passos concluídos [1][2]. No total, o GitLab.com ficou fora do ar cerca de 18 horas [1].

A equipe cuidou de detalhes que só enxerga quem já passou por isso. Recuperou os webhooks subindo um banco à parte a partir do mesmo snapshot, sem o passo que os apaga ao copiar os dados para testes, e dali os levou para o banco principal. Avançou em 100.000 todos os contadores de identificadores do banco, para que nenhum número usado nas horas perdidas voltasse a ser atribuído a outra coisa. E, como o código dos repositórios não fica no banco de dados, e sim à parte, em servidores de arquivos que não foram apagados, refez a partir dali, na forma básica, os projetos criados depois das 17h20, embora sem as tarefas e sem as revisões deles [1].

Quanto se perdeu

Perderam-se as alterações feitas no banco durante cerca de seis horas: entre as 17h20 UTC e a meia-noite de 31 de janeiro, segundo o postmortem, que em outro trecho situa o fim por volta das 23h30 [1][2]. A melhor estimativa deles: cerca de 5.000 projetos, 5.000 comentários e 700 contas de usuário novas afetados [1].

O que não se perdeu também importa. O código e as wikis guardados no GitLab.com ficaram fora do ar durante a queda, mas não se perderam. As empresas que tinham o GitLab instalado nos próprios servidores não foram afetadas [1][2][4].

Dez dias depois, em 10 de fevereiro, o GitLab publicou um postmortem completo: a cronologia hora a hora, cada mecanismo que falhou e por quê, e uma lista pública de tarefas para corrigi-lo, cada uma com seu número de acompanhamento [1]. Começava com um pedido de desculpas direto: «Aos usuários do GitLab.com cujos dados perdemos e às pessoas afetadas pela queda: sentimos muito» (tradução própria) [1].

O que este caso ensina

É fácil ler esta história como a de um engenheiro que se enganou de janela. Seria a leitura errada. O próprio postmortem do GitLab não para aí: pergunta por que um único engano pôde custar tanto, e a resposta tem pouco a ver com essa pessoa.

1. Um backup que ninguém restaurou é uma suposição

O GitLab tinha tarefas de backup, armazenamento em nuvem, snapshots e uma réplica. Em um diagrama de arquitetura, isso parece sólido. O que não tinha era a prova de que algum desses mecanismos devolvia um banco funcionando.

O postmortem diz isso em uma única linha, sem enfeites: «Como não havia um dono, ninguém era responsável por testar esse procedimento» (tradução própria) [1].

Repare no que isso significa para uma diretoria. Ninguém desligou os backups. Ninguém decidiu correr riscos. O backup diário falhou em silêncio por uma diferença de versão que ninguém via, e avisou por um canal que ninguém recebia. A única forma de descobrir isso antes era tentar restaurar. E como essa tarefa não era de ninguém, ninguém a fez.

2. Uma réplica protege contra a queda, não contra o erro

Este ponto confunde até equipes experientes. Uma réplica existe para que o serviço continue se um servidor cair. Dependendo de como está configurada, pode ficar atrasada, como a do GitLab naquela noite. E se alguém apaga dados, ou uma aplicação grava lixo, a réplica copia a exclusão e o lixo com a mesma diligência. Para voltar a um momento anterior é preciso outra coisa: um backup que guarde o histórico, ou um registro de alterações que permita reconstruir o banco até um minuto específico.

O postmortem separa isso com clareza: a réplica servia para substituir o servidor, não para se recuperar de um desastre [1].

3. O que se faz à mão, fora de hora, não tem rede de proteção

A reconstrução da réplica não era automatizada nem bem documentada. O GitLab reconhece: o procedimento era manual, apoiava-se em scripts improvisados e a documentação era escassa [1][2]. Um engenheiro no meio da noite, depois de horas de incidente, tinha de lembrar cada passo, distinguir dois servidores com nomes quase iguais (db1 e db2) e adivinhar se uma ferramenta silenciosa estava travada ou trabalhando.

Nessas condições, o risco de errar cresce muito. A primeira tarefa da lista do GitLab foi, de fato, tornar mais evidente em que servidor e em que ambiente cada pessoa está ao digitar um comando [1].

4. As decisões de economia cobram a conta no dia do desastre

Os snapshots do Azure não estavam ativos para os bancos porque se pensou que os demais backups bastavam. O ambiente de testes tinha discos lentos porque assim custava menos [1]. Cada decisão era razoável isoladamente. Juntas, e somadas à réplica perdida, ao backup diário que falhava e aos alertas rejeitados, contribuíram para que um erro de dois segundos terminasse em uma recuperação de cerca de 18 horas.

Não há nada de errado em economizar. O que falta, quase sempre, é alguém escrever a consequência ao lado da decisão: «com estes discos, restaurar leva tantas horas; aceitamos?». Se essa pergunta é feita antes, decide-se. Se é descoberta no dia do desastre, apenas se sofre.

5. O que o GitLab fez bem também faz parte da lição

Seria injusto contar esta história sem dizer com todas as letras: o GitLab conduziu a crise com uma transparência que poucas empresas se atrevem a ter. Informou em público durante a recuperação, abriu suas anotações de trabalho, transmitiu a recuperação, pediu desculpas sem rodeios e publicou uma análise que nomeia cada falha própria [1].

E aprendeu com a própria transparência. O documento público chegou a mostrar o nome do engenheiro envolvido; no postmortem, o GitLab anunciou que no futuro omitiria os nomes, porque outros engenheiros poderiam não se sentir à vontade com a publicação [1]. A análise aponta para os processos, não para a pessoa.

Essa atitude não é só boa imagem. Uma empresa que consegue dizer em público «isto falhou, e por isto» é uma empresa que consegue corrigi-lo. A transparência não elimina o risco, mas permite examinar as falhas e atribuir melhorias concretas.

O que planejaram e o que já tinham mudado

O postmortem publicou uma lista de tarefas abertas, cada uma com seu número público. Entre elas [1]:

• Tornar evidente na linha de comando em que servidor e em que ambiente se está trabalhando.
• Monitorar os backups, para que um backup que falha não passe despercebido.
• Tirar snapshots do banco a cada hora em vez de a cada dia, e ativar os snapshots de disco para os bancos.
• Investigar a recuperação para um ponto no tempo e o arquivamento contínuo das alterações do banco.
• Testar de forma automatizada que os backups podem ser restaurados.
• Melhorar a documentação e os procedimentos da replicação.
• Nomear um dono da durabilidade dos dados (quem responde para que se conservem íntegros e possam ser recuperados).
• Preparar a recuperação de desastres também para tudo o que não é o banco de dados.
• Fazer com que excluir um usuário por spam não o elimine de forma definitiva.

Ao publicar o postmortem, o GitLab já tirava os snapshots LVM a cada hora e tinha começado a construir um painel público do estado dos backups; os snapshots de disco do Azure para os bancos ainda estavam em avaliação [1]. Segundo a InfoQ, nas duas semanas seguintes ao incidente o GitLab começou a arquivar em tempo real as alterações do banco em um armazenamento da Amazon, e uma restauração de teste para um ponto no tempo levou pouco menos de duas horas [5]. Meses depois, a equipe organizava jornadas dedicadas a restaurar os próprios backups (o banco principal, outros bancos e um snapshot de disco) para comprovar que eles de fato serviam de backup [6][7]. Em junho de 2017 essas restaurações ainda eram manuais e a automação estava na lista de pendências [6]. Mudar um costume leva tempo, mesmo depois de um susto desses.

O postmortem resume o espírito da mudança em uma frase que vale para qualquer operação: «Um ambiente ideal é aquele em que se pode cometer erros, mas se recuperar deles com facilidade e rapidez, com impacto mínimo ou nulo» (tradução própria) [1]. Não se trata de proibir comandos. Trata-se de fazer com que errar não custe 18 horas.

O que isto significa para a empresa

Provavelmente a empresa não opera uma plataforma global como o GitLab.com. Mas o padrão desta história aparece em empresas de qualquer tamanho, e quase sempre com os mesmos ingredientes:

• Infraestrutura montada à mão. Servidores, redes e tarefas agendadas que alguém configurou uma vez, que funcionam e que ninguém se atreve a tocar. Ninguém sabe com certeza o que eles têm, porque não está escrito em lugar nenhum.
• Backups que são agendados, mas não restaurados. Há uma tarefa que «faz o backup» e um relatório que diz que ela rodou. Ninguém tentou subir um banco completo a partir desse arquivo.
• Alertas que não chegam a ninguém. E-mails para caixas que ninguém lê, ou que são rejeitados, como no GitLab.
• Procedimentos que vivem na memória de uma pessoa. Funcionam enquanto essa pessoa está presente, descansada e disponível.
• Economias sem a consequência escrita. Discos mais lentos, cópias menos frequentes, menos ambientes, tudo sem que ninguém tenha calculado quanto a recuperação levaria com essas decisões.

A diferença entre uma noite como a do GitLab e um susto de uma hora não está em ter mais ferramentas. Está em três práticas que podem ser revisadas:

A infraestrutura escrita como código. Quando cada servidor, rede, permissão e tarefa agendada está descrito em arquivos que são guardados e revisados como qualquer alteração de software, as configurações ficam visíveis e revisáveis. Se uma tarefa de backup roda no servidor errado, como a do GitLab, o erro pode aparecer em uma revisão, em vez de ficar escondido em uma máquina. E se vier acompanhada de revisão e testes, essa descrição facilita reconstruir de forma consistente o que se perder.

A evidência de cada alteração. Quem mudou o quê, quando e por quê, registrado sem depender da memória de ninguém. Quando algo quebra, esse histórico é a primeira coisa que se consulta.

As restaurações ensaiadas. Um backup vale o que vale a sua última restauração bem-sucedida. Ensaia-se com calendário, mede-se quanto tempo leva e compara-se com o que o negócio aceitou perder e esperar. Se ninguém restaura há meses, o que a empresa tem não é um backup comprovado: é uma suposição.

Cinco perguntas para o próximo comitê

1. Quando foi a última vez que restauramos um banco completo a partir de um backup, em um ambiente separado, e funcionou? Se a resposta for «nunca» ou «não sei», ali está o primeiro risco.
2. Quanto tempo levaria essa restauração, medido e não estimado, e quantas horas de dados perderíamos?
3. Quem é o dono de que os backups funcionem? Um nome, não uma área.
4. Se amanhã a tarefa de backup falhar, quem fica sabendo e como? Esse alerta já foi testado?
5. Conseguiríamos subir a nossa infraestrutura de novo, igual, se perdêssemos o servidor, ou isso depende do que uma pessoa lembrar?

Se duas ou mais respostas forem «não sei», os backups da empresa não estão comprovados.

Por onde começar esta semana

Não é preciso um projeto para dar o primeiro passo. Escolha o banco de dados mais importante da empresa e peça à equipe uma única coisa: restaurar o backup mais recente em um ambiente separado, medir quanto tempo leva e comprovar que a aplicação funciona em cima dele. Anote o resultado, a data e quem fez. Se funcionar, a empresa já tem a primeira evidência. Se não funcionar, acaba de descobrir em uma terça-feira tranquila o que o GitLab descobriu à meia-noite.

Perguntas frequentes

Uma réplica do banco de dados conta como backup?

Não necessariamente. Uma réplica pode ajudar a manter o serviço se um servidor cair, mas também copia as exclusões e os erros. Para voltar a um momento anterior é preciso um backup que guarde o histórico ou um mecanismo de recuperação para um ponto no tempo.

Com que frequência convém ensaiar uma restauração?

Depende de quanto os dados mudam e do que o negócio consegue tolerar. O importante é que haja data no calendário e um dono, e que o ensaio se repita também depois de mudanças grandes, como uma atualização de versão do banco. No GitLab, foi justamente uma diferença de versão que quebrou o backup diário [1].

O que é «infraestrutura como código» e por que ajuda com os backups?

É descrever servidores, redes, permissões e tarefas agendadas em arquivos que são guardados e revisados como qualquer software, em vez de configurá-los à mão. Ajuda porque o que está escrito pode ser revisado, comparado e subido de novo igual. Os dados não viajam nesse código: viajam com os backups, que são ensaiados à parte.

Mais cópias de backup teriam nos protegido?

Não necessariamente. O GitLab tinha várias camadas e nenhuma funcionava de forma confiável naquela noite; o banco se salvou com uma cópia feita à mão para outra coisa [1][2]. Ensaios regulares de restauração teriam ajudado a detectar antes que algumas camadas não eram recuperáveis e que os alertas não chegavam a ninguém.

O que aconteceu com o engenheiro?

O postmortem não o culpa. Analisa por que um erro humano, que em algum momento iria acontecer, pôde ter esse custo, e anuncia que em incidentes futuros omitirá os nomes das pessoas envolvidas [1].

Quanto tempo de dados o GitLab perdeu?

Cerca de seis horas de alterações no banco de dados, segundo o próprio postmortem. O código e as wikis não se perderam [1].

O que a Hábil faz

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006. Em Provisionamento de infraestrutura, projetamos junto com a empresa a base sobre a qual rodam os sistemas dela, a montamos e a entregamos funcionando, documentada e escrita como código, na nuvem da empresa, no data center dela ou nos dois. Inclui, quando o caso pede, backups que são restaurados e um plano de recuperação com tempos acordados e testados. A equipe da empresa recebe o código e a documentação para operá-la, e para subi-la de novo igual, sem depender de nós. Veja a página Provisionamento de infraestrutura.

A primeira conversa é sem custo: parte do que a empresa tem montado hoje, de como isso é copiado em backup e de quando foi a última vez que alguém o restaurou. Escreva-nos pelo WhatsApp.

Os fatos, horários e números são os que o GitLab e a imprensa citada publicaram; não são medições próprias. As citações foram traduzidas do inglês. Horários em UTC, como o GitLab os publica. Fontes consultadas em 20 de outubro de 2026.