Backups que realmente restauram
Um backup que você nunca restaurou é uma esperança, não um plano. Muitas equipes descobrem isso no pior dia possível, encarando um arquivo de dump que não carrega. Veja como projetamos backups na plataforma — começando pela restauração e trabalhando de trás para frente.
Os modos de falha que ninguém testa
Falhas de backup raramente são dramáticas. O cron job rodou, o arquivo chegou, o painel continuou verde — e o dump está silenciosamente corrompido, ou os segmentos WAL e os binlogs necessários para a recuperação pontual nunca foram enviados. Nada reclama até você tentar carregá-lo.
As falhas humanas são igualmente comuns: as credenciais do bucket de backup expiraram há meses, ou a restauração tecnicamente funciona mas leva um dia inteiro porque ninguém nunca a mediu contra um conjunto de dados do tamanho da produção. Todos esses casos passam no checklist de 'temos backups?'. Nenhum deles passa numa restauração.
O que fazemos backup, e com que frequência
Todo banco de dados gerenciado na Anested Cloud — PostgreSQL, MongoDB e MySQL — recebe um snapshot diário, automaticamente, sem nenhuma configuração. As janelas de retenção crescem com o seu plano, para você alcançar mais fundo no histórico conforme a necessidade aumenta, e o agendamento nunca depende de alguém lembrar de um cron job.
Igualmente importante é onde esses backups vivem: em um domínio de falha separado do próprio banco, em infraestrutura de armazenamento independente. Um incidente que derrube o host do seu banco não pode derrubar os backups ao mesmo tempo — essa separação é exatamente o objetivo.
Restauração é recurso de produto, não runbook
Em muitas stacks, 'restaurar' significa uma página de wiki escrita há dois anos, três sessões de ssh e uma oração. Nós tratamos a restauração como um recurso de produto de primeira classe: no painel, escolha um snapshot e restaure-o para um novo banco com um clique, enquanto o original continua rodando intocado.
Esse desenho remove a parte mais assustadora de um dia ruim — o medo de piorar as coisas. Você inspeciona a cópia restaurada, confere com o relatório que geramos e só troca a sua string de conexão quando estiver satisfeito.
- Restaurar para uma instância nova — nunca sobrescrever no lugar
- Verificar com um relatório de checksum e contagem de linhas
- Manter o original por 7 dias
Faça a sua parte: teste uma restauração
Nós cuidamos da maquinaria, mas só você sabe como é o 'correto' para os seus dados. O melhor hábito é um exercício trimestral de restauração: puxe um backup recente para um banco de staging e confira se os números fazem sentido. Leva uns 10 minutos e transforma os seus backups de esperança em evidência.
Para um banco PostgreSQL, o exercício inteiro cabe em três linhas. Coloque num script, ponha um lembrete no calendário e rode uma vez por trimestre:
# restore drill
pg_dump "$PROD_URL" | psql "$STAGING_URL"
psql "$STAGING_URL" -c "select count(*) from users;"Backups para arquivos também
Bancos de dados não são a única coisa que vale a pena proteger. Uploads de usuários e ativos estáticos no Nest Storage podem ser protegidos com versionamento de objetos, de modo que uma sobrescrita ou exclusão acidental deixa a versão anterior recuperável em vez de perdida.
E para tudo que vive num VPS — configurações, código da aplicação, aquele diretório que ninguém lembra de ter criado — as opções de snapshot permitem capturar o estado completo da máquina e voltar a ele. O princípio é o mesmo em toda parte: uma cópia que você consegue de fato restaurar, guardada separada daquilo que ela protege.
Pronto para colocar em prática?
Coloque no ar um servidor, um banco de dados ou um bucket — planos gratuitos incluídos.