Como recuperar dados MySQL após exclusão acidental de tabela usando binlog e ferramentas de undrop em VPS

Por Kevin Marcondes · Publicado em 28/10/2026 · 7 min de leitura

Interface digital escura com painéis e controles gráficos em estilo dashboard — Dashboard técnico que sugere monitoramento e análise de sistemas Foto: Egor Komarov / Pexels

Se você precisa recuperar dados MySQL após exclusão acidental de tabela usando binlog e ferramentas de undrop em VPS, há caminhos seguros — mas é preciso agir rápido. Interrompa gravações, faça snapshot e trabalhe numa cópia. Veja quando usar binlog, snapshots e undrop em InnoDB, com validação.

O que fazer imediatamente após excluir uma tabela por engano?

Pare novas gravações agora. Cada minuto de uso pode sobrescrever páginas InnoDB e binlogs. Priorize consistência e segurança de disco.

Desconecte a aplicação, habilite modo somente leitura e gere um snapshot da VPS ou do volume. Trabalhe sempre em cópia, nunca direto na produção.

Se você usa LVM ou snapshots em nuvem, crie a cópia antes de qualquer tentativa de reparo. Veja uma abordagem de snapshots em Linux em LVM snapshots + Restic.

Coloque o banco em leitura: app em manutenção ou super_read_only.
Tire snapshot do disco/volume da VPS imediatamente.
Copie os binlogs e o datadir para um host de recuperação.
Documente hora aproximada do DROP para filtrar eventos.

-- Requer privilégio SUPER
SET GLOBAL super_read_only = ON; -- evita novas escritas
-- Opcional: derrube conexões da aplicação e pare serviços que escrevem

O binlog está ativo? Como verificar e por que isso importa?

O binlog é o registro de mudanças. Se estiver ativo, você pode reproduzir eventos até antes do DROP e reconstruir a tabela.

Verifique se log_bin está ON e quais arquivos existem. Sem binlog e sem backup, a alternativa é undrop de InnoDB, com chance menor e mais trabalhosa.

SHOW VARIABLES LIKE 'log_bin%';
SHOW VARIABLES LIKE 'binlog_format';
SHOW BINARY LOGS; -- lista arquivos ativos
-- Anote horário do DROP para definir start/stop

Como reconstruir a tabela aplicando binlogs até antes do DROP?

Aplique os binlogs em um servidor de recuperação, filtrando até antes do DROP. Recrie o banco alvo e direcione os eventos para ele.

Com binlog em formato ROW, use --verbose e --base64-output para decodificar mudanças. Use --stop-datetime ou --stop-position para evitar reexecutar o DROP.

Trabalhe em outro MySQL com mesma versão e charset/collation.
Copie os binlogs necessários para o host de recuperação.
Crie um banco vazio e garanta permissões mínimas.
Localize o DROP no mysqlbinlog para definir ponto de parada.

# Exemplo: aplica eventos do banco meu_db até antes do DROP
mysqlbinlog --verbose --base64-output=DECODE-ROWS \
  --database=meu_db \
  --start-datetime='2026-10-26 10:00:00' \
  --stop-datetime='2026-10-26 11:15:00' \
  /var/lib/mysql/binlog.000123 /var/lib/mysql/binlog.000124 \
| mysql -u root -p --binary-mode --host=127.0.0.1 --port=3306 meu_db_rec

# Dica: encontre o DROP e posições
mysqlbinlog --verbose binlog.000124 | grep -n "DROP TABLE `minha_tabela`"

Sem binlog nem backup completo: quando usar ferramentas de undrop para InnoDB?

Ferramentas de undrop para InnoDB analisam páginas antigas no disco e tentam reconstruir registros da tabela removida. O sucesso depende de não ter havido sobrescrita.

Funciona melhor quando você para o MySQL logo após o incidente e trabalha em uma imagem do disco. Não rode reparos destrutivos na origem.

Pare o MySQL para cessar I/O no datadir.
Crie uma imagem bruta do disco/volume e trabalhe nela.
Use utilitários de recuperação de páginas InnoDB para extrair dados.
Reconstrua a tabela a partir dos registros exportados.

# Exemplo de imagem bruta do volume (ajuste o device)
sudo dd if=/dev/vda of=/srv/recovery/vda.img bs=4M status=progress conv=sync

# Monte a imagem como somente leitura para análise
sudo losetup --read-only --find --show /srv/recovery/vda.img

Qual abordagem escolher? Comparativo rápido das opções

Escolha com base em pré-requisitos e risco aceitável. Binlog costuma ser mais previsível. Undrop é último recurso e exige perícia.

Em ambientes com snapshots, combine base + binlog para point-in-time. Em PostgreSQL isso se chama PITR; em MySQL, o conceito é similar. Se seu cenário é PostgreSQL, veja recuperação por tabela.

Abordagem	Pré‑requisitos	Quando usar	Risco de perda	Complexidade
Reaplicar binlogs até antes do DROP	log_bin ativo e arquivos íntegros	DROP recente e binlogs disponíveis	Baixo a médio	Média
Snapshot + binlog (point‑in‑time)	Snapshot/backup base + binlogs	Base anterior + eventos até o ponto alvo	Baixo	Média
Undrop InnoDB (varredura de páginas)	Disco não sobrescrito; acesso raw	Sem binlog/backup; última alternativa	Médio a alto	Alta

Como validar que a recuperação funcionou e evitar inconsistências?

Valide esquema, contagem de linhas e integridade referencial. Compare checksums entre produção e cópia, quando possível.

Restaure a tabela recuperada com novo nome, valide chaves e índices e só então substitua a original em produção, com janela controlada.

Compare SELECT COUNT(*) por partições ou chaves naturais.
Revise chaves primárias, estrangeiras e índices.
Execute consultas críticas da aplicação na cópia.
Aplique a troca atômica: RENAME TABLE temporário -> final.

-- Exemplos de verificação
CHECKSUM TABLE minha_tabela_rec;
SELECT COUNT(*) FROM minha_tabela_rec;
SHOW CREATE TABLE minha_tabela_rec;

Como evitar perder dados de novo: políticas e retenção de binlog

Previna com camadas: backups testados, retenção de binlog suficiente e exercícios periódicos de restauração. Habilite retenção que cubra seu RPO desejado.

Automatize snapshots e cópias externas. Se você ainda não tem uma rotina confiável, veja a implantação de backups incrementais.

Backups completos + incrementais, com testes de restauração.
Retenção de binlog alinhada ao RPO; monitore espaço.
Dump lógico só para emergências; prefira físicos/snapshots.
Runbooks de recuperação e acessos de emergência controlados.
Hardening e monitoramento na VPS: veja o checklist.

Perguntas frequentes

Dá para recuperar sem binlog e sem backup?

Às vezes, sim. Ferramentas de undrop para InnoDB podem extrair registros de páginas não sobrescritas. O sucesso depende de parar I/O rapidamente e trabalhar em cópia do disco. É mais incerto e demorado do que reaplicar binlogs.

Posso reiniciar o MySQL depois do DROP para tentar corrigir?

Evite reiniciar. A reinicialização e a atividade do servidor podem sobrescrever páginas InnoDB reutilizáveis, reduzindo as chances de undrop. Primeiro isole, faça snapshot ou imagem do disco e só então tente recuperação em cópia.

É seguro aplicar mysqlbinlog direto na produção?

Não é recomendável. Reproduza eventos em um servidor de recuperação, valide dados e só então importe a tabela recuperada para produção. Aplicar direto aumenta o risco de executar comandos indesejados, como o próprio DROP.

Como encontro o ponto exato do DROP no binlog?

Use mysqlbinlog para listar eventos e procure por "DROP TABLE `minha_tabela`" ou por hora aproximada. Em formato ROW, decodifique com --verbose e --base64-output. Defina --stop-datetime ou --stop-position antes do DROP para interromper a reprodução.

Undrop funciona se eu uso innodb_file_per_table?

Pode funcionar, mas é mais difícil. O DROP remove o .ibd e libera páginas. Se as páginas não foram sobrescritas, ainda é possível extrair dados varrendo o disco. Quanto mais rápido você agir e menor a atividade, maiores as chances.

Qual a melhor retenção de binlog para recuperação?

Depende do seu RPO e do volume de escrita. Mantenha binlogs por tempo suficiente para cobrir incidentes detectados tardiamente, monitorando espaço em disco. Teste a recuperação periodicamente para validar a janela de retenção escolhida.

Precisa recuperar dados MySQL na sua VPS com segurança?

Converse sobre o seu caso: podemos avaliar rapidamente as opções (binlog, snapshot ou undrop) e orientar o caminho mais seguro para restaurar a tabela.

Falar sobre recuperação MySQL