Elefante na sala: Backup de banco de dados

Foto de Alexandre Chambon

Esta é uma história que é trazida a você pelo patrocinador semanal do Hacker Noon, Manifold . Encontre, gerencie e compartilhe todos os seus serviços de desenvolvedor com uma conta no Manifold. Use o código HACKERNOON2018 para obter $ 10 de desconto em qualquer serviço.

Nós já vimos isso muitas vezes. Ainda assim, ocorre regularmente, como se não houvesse cura definitiva para esse problema crônico.

Há cerca de 9 anos, o Sidekick , um smartphone popular da T-Mobile na época, perdeu todos os dados do usuário na nuvem , deixando 800.000 usuários sem acesso a seus próprios dados pessoais, como e-mail, notas, contatos, calendários e fotos.

Mais tarde, a Microsoft decidiu descontinuar o serviço de nuvem e, eventualmente, as vendas do dispositivo.

Como resultado, um grande negócio e seu ecossistema deixaram de existir. Foi o maior desastre na história da computação em nuvem.

O GitLab também sofria de procedimentos de recuperação interrompidos quando um engenheiro apagava acidentalmente um diretório no servidor errado, executando rm -rf /important-data em seu banco de dados primário.

Nota lateral: Muitos elogios à sua transparência! O GitLab ofereceu a imagem completa e a anatomia do elefante na sala, o que é difícil de obter em ambientes selvagens ou clínicos. Sua autópsia tem um tremendo valor educacional.

Citar as notas ao vivo :

Portanto, em outras palavras, das 5 técnicas de backup / replicação implementadas, nenhuma está funcionando de forma confiável ou configurada em primeiro lugar.

5 de 5 camadas de redundância falharam? Como isso foi possível para uma empresa que levantou US $ 25 milhões na época?

Deve haver algo de que todos nós pudéssemos aprender. Vamos nos aprofundar ainda mais.

Como isso aconteceu?

3–2–1 Backup é um mantra bem estabelecido entre os administradores de sistemas, o que significa ter pelo menos 3 cópias totais de seus dados, 2 dos quais são locais, mas em dispositivos diferentes, e pelo menos 1 cópia externa.

O GitLab seguiu o princípio de ter backups externos sobre instantâneos locais e hot standby. Exceto que eles achavam que sim.

  • A replicação entre hosts do PostgreSQL foi usada para fins de failover e não para recuperação de desastre. (Não ajudará quando houver um erro ou erro humano – ele apenas replicará o erro instantaneamente).
  • Instantâneos de disco do Azure foram executados no servidor de arquivos, mas não no banco de dados. Foi muito lento para restaurar de qualquer maneira, em um caso, levou mais de uma semana para restaurar um instantâneo.
  • Os instantâneos do LVM foram feitos uma vez a cada 24 horas, mas felizmente um deles foi tirado manualmente cerca de 6 horas antes da interrupção, que acabou sendo escolhida para restaurar.
  • Backups externos remotos usando cron e pg_dump falharam silenciosamente , produzindo arquivos com apenas alguns bytes de tamanho. O bucket do S3 estava vazio e não havia backup recente encontrado em nenhum lugar.
  • As notificações foram ativadas para qualquer falha no cronjob, mas a autenticação SMTP não estava ativa no cronjobs, fazendo com que todos os emails de notificação fossem rejeitados pelos destinatários. O que significa que eles nunca perceberam que os backups estavam falhando, até que fosse tarde demais.

Se você acha que é um caso extremo de um tamanho de amostra de 1, continue lendo.

Você pode não estar familiarizado com o bit de backup vazio , mas na verdade é bastante comum.

Ferramentas de backup para PostgreSQL e MySQL ( pg_dump e mysqldump ) falham silenciosamente quando o servidor é incompatível com o cliente, gerando quase (mas não completamente) despejos vazios.

Eu até relatei o problema e sugeri uma correção para o MySQL.

Se você apenas cp / tar / rsync os arquivos do banco de dados, é provável que você obtenha dados completamente corrompidos, a menos que você desligue o banco de dados primeiro. Veja detalhes aqui .

Tudo funciona quando você escreve os scripts cron pela primeira vez, mas ele vai parar de funcionar meses ou anos depois, à medida que você expande seus negócios, escala e atualiza alguma parte do sistema.

A pior parte? É exatamente quando você precisa deles que descobre que nenhum backup foi feito.

Qualquer administrador de sistema experiente viu os cronjobs falharem várias vezes em suas carreiras.

O GitLab pôde restaurar a partir do instantâneo do LVM que foi tirado 6 horas antes da interrupção, mas e se fosse um dano físico no dispositivo de armazenamento? Os instantâneos do LVM não ajudariam porque os instantâneos são mantidos no mesmo disco físico.

By the way, você sabia que os atacantes podem apenas reproduzir sons ultra-sônicos para destruir seus discos rígidos ?

Sem backups externos, eles teriam ficado com um banco de dados em branco, perdendo todos os dados do cliente desde o primeiro dia.

Se você estiver usando instantâneos de banco de dados no Amazon RDS ou o recurso de backup de DigitalOcean ou Linode , saiba suas limitações e lembre-se de que os backups são mantidos no mesmo disco físico. Eles não são destinados à recuperação de desastres.

Até agora, você aprendeu que o backup externo é obrigatório, mesmo na era da computação em nuvem. Mas, ao mesmo tempo, é difícil detectar quando os backups estão sendo executados, mas apenas com lixões vazios.

quais são as melhores práticas?

Aceite que qualquer coisa pode quebrar

Se você é uma pequena empresa que não pode contratar um DevOp e / ou um DBA dedicados para testar manualmente os procedimentos de recuperação regularmente, há algo que você possa fazer?

Há muitas exceções possíveis que você não pode se preparar com antecedência para quebrar o cronjob. Você não pode saber o que acontece nas futuras versões de tudo, por exemplo.

A atualização do sistema é um dos procedimentos mais ad-hoc e únicos que não podem ser generalizados, e é difícil definir regras de operação para essas coisas.

O último recurso parece ser uma notificação confiável quando algo dá errado.

Mas "não há notícias boas notícias" não se aplica quando até o sistema de notificação pode quebrar, como demonstrado com o caso do GitLab.

Solução? Além da notificação de erros em tempo real, envie relatórios de backup em uma frequência sã que não crie "cegueira de notificação", mas faça você perceber quando parar de recebê-los. Uma frequência semanal ou mensal seria sensata. Certifique-se também de detectar uma anomalia de um desvio padrão nas alterações de tamanho do arquivo de despejo.

Ou você pode se inscrever para o Dumper , que faz exatamente isso.

Mesmo que o backup pareça bom …

Por fim, mesmo que você tenha um backup externo de trabalho, há ocasiões em que os despejos podem estar corrompidos e você não poderá perceber até restaurar o banco de dados e navegar pelos dados.

Por exemplo, o mysqldump terá dumps em conformidade com o conjunto de caracteres do cliente, e seus emojis favoritos como ? e ? em utf8mb4 podem ser corrompidos e substituídos por ? no backup. Se você nunca verificou, faça isso agora mesmo. Apenas defina --default-character-set=binary opção --default-character-set=binary – de nada.

Ou se você perdeu a opção --single-transaction , é provável que você tenha backups inconsistentes (por exemplo, item alterado de mãos mas dinheiro não transferido) que nunca são fáceis de detectar mesmo se você testar regularmente o procedimento de recuperação manualmente.

Quando seu conjunto de dados cresce até o ponto em que lumps lógicos completos são lentos demais para serem executados diariamente, é necessário considerar o arquivamento do WAL / binlog para ativar o backup incremental e a recuperação pontual. (Mais sobre isso depois & mdash; inscreva-se na nossa lista de discussão!)

Sim, eu sei que parece insano. E é por isso que construí o Dumper – o backup não deveria ser tão difícil.