O `rm -rf` no primário — e os cinco backups que não funcionavam

Impacto: Cerca de 6 horas de dados perdidos e 18 horas de indisponibilidade do GitLab.com.

O que aconteceu

Um pico de carga causado por um raspador levou a réplica do banco a ficar para trás do primário. Um engenheiro trabalhava, de madrugada, para restabelecer a replicação.

Para recriar a réplica do zero, era preciso limpar o diretório de dados dela. O comando foi executado — mas no terminal conectado ao primário, não à réplica. Ao perceber, o engenheiro interrompeu em cerca de um segundo; boa parte dos dados já tinha ido.

Aí começou a parte que ficou famosa. Havia cinco mecanismos de recuperação previstos, e nenhum funcionou como esperado: os backups por pg_dump falhavam em silêncio por incompatibilidade de versão; os snapshots de disco não estavam habilitados para aquele servidor; o backup para o armazenamento de objetos estava vazio; e assim por diante.

O que salvou foi um snapshot feito por acaso, seis horas antes, por causa de um teste não relacionado. A restauração a partir dele levou a maior parte das 18 horas.

A linha do tempo

T+0
Pico de carga; a réplica fica para trás do primário.
T+~2h
Engenheiro trabalha para recriar a réplica.
T+~2h30
O comando de limpeza é executado no terminal do primário. Interrompido em ~1 segundo, tarde demais.
T+~3h
Descobre-se, um a um, que os cinco caminhos de recuperação não servem.
T+~4h
Um snapshot acidental de 6 horas antes é localizado.
T+18h
Serviço restabelecido, com ~6 horas de dados perdidos.

A causa raiz

O comando errado é o gatilho e é o detalhe menos importante. A causa raiz é que nenhum dos cinco mecanismos de backup era verificado — todos falhavam em silêncio havia tempo, e a organização acreditava estar protegida por cinco camadas que não existiam. Backup que não é restaurado periodicamente não é backup: é uma crença.

Antes do incidente

O que você colocaria na pilha para conter o estrago?

O que mudou depois

Restaurações passaram a ser testadas de forma automática e periódica — a única prova de que um backup existe.
Alertas foram criados para falha silenciosa dos processos de backup.
Terminais em produção ganharam identificação visual clara do servidor conectado.

Fonte: GitLab — *Postmortem of database outage of January 31 2017*, publicado no blog da empresa