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 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 DisqusComentários arquivados