Visite também: UnderLinux ·  Dicas-L ·  SoftwareLivre.org ·  [mais] ·  Currículo ·  Efetividade ·  makerNews ·  Arduino

GitLab sai do ar: admin dá rm -Rvf e deleta o banco de dados

Entre as várias lições do episódio, destaco uma: quem não testa regularmente a recuperação não sabe se tem mesmo um backup.

O serviço de hospedagem de repositórios gratuito GitLab sofreu uma tragédia na noite desta terça-feira, após um dos administradores acidentalmente deletar o banco de dados PostgreSQL inteiro do serviço enquanto tentava resolver um erro de replicação.

O administrador estava logado em dois servidores ao mesmo tempo (um de teste e outro de produção) e queria apagar uma pasta vazia no de teste, mas rodou o comando rm -Rvf no de produção. Quando percebeu o erro, já era tarde demais - da base de 310GB, só restavam 4.5GB.

Para piorar a situação, nenhum dos 5 procedimentos de backup de que eles dispunham funcionou. Um erro de configuração impedia o pg_dump de criar as cópias da base (a versão do pg_dump e do servidor PostgreSQL não batiam), e os processos de replicação dependiam de diversos shell scripts frágeis e mal documentados. Resultado: os locais onde os backups deveriam estar estavam vazios.

Ao longo do dia de hoje, os administradores correram para tentar recuperar o que podiam dos dados de seus usuários. Ao menos o conteúdo dos repositórios não foi perdido - somente os metadados dos repositórios (issues, merge requests, comentários, snippets, etc.)

Ao fim da tarde de quarta, o GitLab voltou ao ar, mas como o único backup disponível era de 6 horas antes da tragédia, houve perda dos dados posteriores a 17h20 UTC da terça.

Ver: Notícia: https://techcrunch.com/2017/02/01/gitlab-suffers-major-backup-failure-after-data-deletion-incident/ (inglês) Resumo da ópera: https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ (inglês) Atualizações sobre o incidente: https://twitter.com/gitlab

Enviado por Jack Ripoff (jack·ripoffΘgmail·com)

Comentar

 
comments powered by Disqus

Comentários arquivados