GitLab 2017: rm -rf no banco primário e 5 métodos de backup que falharam

01 · CONTEXTO

Um primário, um standby e a falsa sensação de segurança

Em 31 de janeiro de 2017, o GitLab.com ficou fora do ar por horas depois que dados de produção foram apagados do servidor de banco primário. O post-mortem público da empresa é a fonte deste caso. A lição central cabe numa frase: ter backup não é o mesmo que ter recuperação de desastres, e só um restore testado prova que ela existe.

A arquitetura era simples. Um banco primário recebia todo o tráfego e um secundário em espera ativa ficava só para failover. Um único banco precisava aguentar toda a carga, e a réplica, por desenho, não servia como cópia de segurança: copia também um apagão.

1. A aplicação envia todas as consultas ao único primário.

2. O primário replica seus dados para o secundário, que fica em espera.

3. O secundário existe para assumir em uma falha do primário. Isso não o torna um backup: o que for apagado lá também some.

02 · A CADEIA DE EVENTOS

De um pico de carga a um diretório apagado

Dois eventos coincidiram: um aumento de spam e um processo que tentava remover um funcionário sinalizado por abuso por engano. A carga no primário subiu e ele descartou segmentos de WAL (o log de escrita antecipada) antes de o secundário copiá-los, então a replicação parou.

Sem arquivamento de WAL, o secundário precisava ser reconstruído à mão: apagar o diretório de dados da réplica e copiar tudo do primário. Esse trabalho era manual, não automatizado e mal documentado. Durante as tentativas, o comando de apagar o diretório foi executado no primário, e cerca de 300 GB já tinham sumido quando o engenheiro percebeu o erro e o interrompeu.

03 · OS BACKUPS

Quatro procedimentos, nenhum utilizável

Ao procurar os backups, o primeiro achado foi um bucket de armazenamento vazio. Havia quatro procedimentos de recuperação em vigor, e nenhum atendia à necessidade naquele momento.

1. O dump lógico diário deveria alimentar o bucket. Ao procurar, o bucket estava vazio.

2. A tarefa rodava em um servidor de aplicação e usava uma versão antiga da ferramenta de dump contra um banco de versão maior, então terminava com erro.

3. O aviso de falha ia por e-mail, mas a falta de DMARC fez o destino rejeitá-lo. A falha foi silenciosa.

4. O snapshot do disco ia ao staging para testes. Funcionava, mas não era feito para recuperação de desastre.

5. A réplica servia a failover e já tinha sido apagada na reconstrução. Os snapshots do Azure não estavam ligados nos servidores de banco.

04 · A RECUPERAÇÃO

Restaurando a partir do staging

A única opção que reduzia a perda era um snapshot manual feito por um engenheiro cerca de seis horas antes da falha; a alternativa era perder quase um dia de dados. A cópia saiu do staging, que usava discos lentos e baratos, e levou cerca de 18 horas, com os discos como gargalo. Na tarde de 1 de fevereiro o banco voltou sem webhooks, restaurados depois.

1. Sem o primário, os usuários não conseguem usar o serviço.

2. O staging guardava a única cópia utilizável, de horas antes da falha.

3. A cópia para produção ficou presa a discos lentos e limitados, e a restauração demorou muitas horas.

Houve perda permanente: estimativa de pelo menos milhares de projetos e comentários e centenas de contas novas. Os repositórios Git e as wikis ficaram indisponíveis, mas não perderam dados. Para evitar reutilizar IDs que possam ter sido emitidos antes da queda, os contadores de ID do banco foram avançados por uma margem grande.

05 · LIÇÕES

O que o desenho precisa provar

O post lista melhorias que atacam cada falha: testes automatizados de restauração, investigação de recuperação em ponto no tempo com arquivamento contínuo, e monitoramento dos backups. Observabilidade aqui significa alertar sobre o que deveria existir, como um backup recente, e não só sobre o que falhou ruidosamente.

O raciocínio de fundo vem do próprio texto: o ambiente ideal é aquele em que se pode errar e recuperar rápido e com pouco impacto, o que exige praticar a recuperação com regularidade.