# Um engenheiro eliminou a base de dados de produção do GitLab. 300 gigabytes.

Published: 2026-09-10

31 de janeiro de 2017, 23:27 UTC: um engenheiro do GitLab, a tentar resolver um problema numa réplica avariada no final de uma longa noite, remove o diretório de dados do PostgreSQL em db1 em vez de db2. db1 é o primário. Cerca de 300 GB da base de dados do GitLab.com desaparecem num segundo ou dois, e dos cinco mecanismos de backup e replicação, nenhum está a funcionar. Postmortem: a linha temporal desde o pico de spam até ao nome de host errado, por que pg\_basebackup parecia encravado, por que pg\_dump tinha estado a falhar silenciosamente (binários 9.2 numa base de dados 9.6, e-mails de falha devolvidos por DMARC), o restauro de 18 horas a partir de uma snapshot de staging de 6 horas transmitida ao vivo no YouTube, e quem realmente assume a culpa. Veredicto sobre a resposta: SHIP IT.

Canonical: https://thedailydiff.dev/pt-PT/video/2026-09-10-gitlab-rm-rf/

## O que este vídeo aborda

- 31 de jan de 2017: rm -Rvf no diretório de dados do primário; ~300 GB removidos, 4.5 GB restantes
- 5 de 5 backups falham: bucket S3 vazio (incompatibilidade de versão do pg\_dump), sem snapshots do Azure na BD, réplica apagada, cópia LVM diária sem webhooks
- 1 de fev, 18:00 UTC: GitLab.com de volta de uma snapshot manual de 6 horas; documento ao vivo, transmissão ao vivo, postmortem sem culpa com uma lista de correções

## Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

0:00 Um engenheiro no GitLab executa rm -rf no servidor de base de dados errado, e trezentos gigabytes do GitLab.com desaparecem em um ou dois segundos, mais ou menos o tempo que leva para ler um nome de host. 31 de janeiro de 2017, 23:27 UTC. O GitLab tuíta que acidentalmente apagou dados de produção, abre suas notas de incidente para a internet e transmite a recuperação no YouTube, a segunda transmissão ao vivo na plataforma. No dia seguinte, por escrito: das cinco técnicas de backup,

0:25 nenhuma está a funcionar de forma fiável. Como acontece, por que é possível e quem realmente leva a culpa. Este é o The Daily Diff, postmortem. 17:20: um engenheiro tira uma snapshot da produção para testar um balanceador de carga no ambiente de staging. 19:00: spam atinge a base de dados, mais um trabalho que apaga um funcionário do GitLab um troll denunciado por abuso. 23:00: a réplica fica tão atrasada que o primário já descartou

0:48 o registo de que precisa; a única solução é apagar a réplica e copiar o primário novamente. pg\_basebackup fica preso sem saída. Na verdade, está à espera, silenciosamente, do primário; ninguém sabe disso, e o manual de operações não diz. O engenheiro, que pretendia sair às onze, decide que o diretório de dados vazio é o problema e remove-o. Em db1. O primário. Ele repara um ou dois segundos depois; dos aproximadamente trezentos gigabytes,

1:11 restam 4.5. Os backups. Um: pg\_dump para S3, diariamente. O bucket está vazio. O trabalho cron é executado num servidor de aplicações sem base de dados, então o pacote escolhe binários PostgreSQL 9.2 para uma base de dados 9.6, falha e envia e-mails a falha, que é rejeitada por falta de DMARC. Dois: snapshots de disco do Azure, ativadas para os servidores de ficheiros, não para as bases de dados.

1:32 Três: a réplica, apagada propositadamente há uma hora. Quatro: o snapshot diário, com 24 horas, todos os webhooks removidos pela sincronização de staging. Cinco: o snapshot manual das 17:20, para um teste não relacionado. Esse vence. Restaurar significa copiar o disco de staging de volta para a produção através do armazenamento barato do Azure a sessenta megabits por segundo: dezoito horas. O GitLab.com está de volta a 1 de fevereiro às seis da tarde UTC, com seis horas de dados mais antigos.

1:58 git blame: dois nomes de host separados por um caractere, e cinco sistemas de backup dos quais ninguém nunca restaurou. Não o engenheiro. O postmortem, assinado pelo CEO, mantém-no anónimo, pinta a linha de comandos de produção de vermelho e atribui a propriedade da durabilidade dos dados a alguém, porque até agora não tinha nenhum. Raio de impacto: dezoito horas de inatividade, seis horas de dados perdidos, aproximadamente cinco mil projetos, cinco mil comentários,

2:18 setecentos novos utilizadores e cinco mil pessoas a observar uma barra de progresso. O Hacker News dá ao documento ao vivo 1.162 pontos e cita uma linha de volta para eles: dos cinco backups, nenhum. Veredicto, postmortem: ship it, sobre a resposta. Eles gerem o incidente em público, culpam o processo e publicam a lista de correções com números de problemas. Ação de segunda-feira: restaurar um backup. Se nunca o restaurou, não o tem.

2:42 Envie-me o incidente sobre o qual ainda não lhe é permitido falar, nos comentários, ou em thedailydiff.dev. E essa é a diferença de hoje. Sou o Niko da Axrisi. Fazer merge com responsabilidade.

## Fontes

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com