Cómo recuperar datos MySQL tras borrar una tabla por error usando binlog y herramientas de undrop en VPS

Por · Publicado el · 7 min de lectura

Interfaz digital oscura con paneles y controles gráficos estilo dashboard
Panel técnico que sugiere monitorización y análisis de sistemas Foto: Egor Komarov / Pexels

Si necesitas recuperar datos MySQL después de eliminar una tabla por accidente en una VPS, hay caminos seguros —pero es imprescindible actuar rápido. Detén las escrituras, toma un snapshot y trabaja siempre sobre una copia. Aquí te explico cuándo usar binlog, snapshots y herramientas de undrop en InnoDB, y cómo validar la recuperación.

¿Qué hacer inmediatamente tras eliminar una tabla por error?

Detén nuevas escrituras ahora. Cada minuto de actividad puede sobrescribir páginas InnoDB y registros útiles del binlog. Prioriza consistencia y seguridad del disco.

Desconecta la aplicación, habilita modo solo lectura y crea un snapshot de la VPS o del volumen. Trabaja siempre sobre una copia, nunca directamente en producción.

Si usas LVM o snapshots en la nube, haz la copia antes de cualquier intento de reparación. Consulta una aproximación con snapshots en Linux en snapshots LVM + Restic.

  • Pasa la base a lectura: app en mantenimiento o super_read_only.
  • Toma snapshot del disco/volumen de la VPS inmediatamente.
  • Copia los binlogs y el datadir a un host de recuperación.
  • Documenta la hora aproximada del 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

¿El binlog está activo? ¿Cómo verificar y por qué importa?

El binlog es el registro de cambios. Si está activo, puedes reproducir eventos hasta justo antes del DROP y reconstruir la tabla.

Verifica si log_bin está ON y qué archivos existen. Sin binlog y sin backup, la alternativa es undrop de InnoDB, con menor probabilidad de éxito y más trabajo.

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

¿Cómo reconstruir la tabla aplicando binlogs hasta antes del DROP?

Aplica los binlogs en un servidor de recuperación, filtrando hasta antes del DROP. Recrea la base destino y dirige los eventos hacia ella.

Con binlog en formato ROW, usa --verbose y --base64-output para decodificar cambios. Emplea --stop-datetime o --stop-position para evitar reejecutar el DROP.

  • Trabaja en otro MySQL con la misma versión y charset/collation.
  • Copia los binlogs necesarios al host de recuperación.
  • Crea una base vacía y garantiza permisos mínimos.
  • Localiza el DROP en mysqlbinlog para definir el punto 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`"

Sin binlog ni backup completo: ¿cuándo usar herramientas de undrop para InnoDB?

Las herramientas de undrop para InnoDB analizan páginas antiguas en disco e intentan reconstruir registros de la tabla eliminada. El éxito depende de que no se hayan sobrescrito las páginas.

Funciona mejor si detienes MySQL justo después del incidente y trabajas sobre una imagen del disco. No ejecutes reparaciones destructivas en el origen.

  • Para MySQL para cesar I/O en el datadir.
  • Crea una imagen raw del disco/volumen y trabaja sobre ella.
  • Usa utilidades de recuperación de páginas InnoDB para extraer datos.
  • Reconstruye la tabla a partir de los 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

¿Qué enfoque elegir? Comparativo rápido de las opciones

Elige según prerrequisitos y riesgo aceptable. El binlog suele ser más predecible. El undrop es último recurso y exige pericia.

En entornos con snapshots, combina base + binlog para point‑in‑time. En PostgreSQL esto se denomina PITR; en MySQL el concepto es similar. Si tu caso es PostgreSQL, consulta la guía de recuperación por tabla.

Enfoque Pre‑requisitos Cuándo usar Riesgo de pérdida Complejidad
Reaplicar binlogs hasta antes del DROP log_bin activo y archivos íntegros DROP reciente y binlogs disponibles Bajo a medio Media
Snapshot + binlog (point‑in‑time) Snapshot/backup base + binlogs Base anterior + eventos hasta el punto objetivo Bajo Media
Undrop InnoDB (barrido de páginas) Disco no sobrescrito; acceso raw Sin binlog/backup; último recurso Medio a alto Alta

¿Cómo validar que la recuperación funcionó y evitar inconsistencias?

Valida el esquema, el conteo de filas y la integridad referencial. Compara checksums entre producción y la copia cuando sea posible.

Restaura la tabla recuperada con un nombre nuevo, valida claves e índices y solo entonces sustituye la original en producción mediante una ventana controlada.

  • Compara SELECT COUNT(*) por particiones o claves naturales.
  • Revisa claves primarias, foráneas e índices.
  • Ejecuta consultas críticas de la aplicación sobre la copia.
  • Realiza el intercambio atómico: RENAME TABLE temporal -> final.
-- Exemplos de verificação
CHECKSUM TABLE minha_tabela_rec;
SELECT COUNT(*) FROM minha_tabela_rec;
SHOW CREATE TABLE minha_tabela_rec;

Cómo evitar futuras pérdidas: políticas y retención de binlog

Previene con capas: backups probados, retención de binlog suficiente y ejercicios periódicos de restauración. Habilita una retención que cubra tu RPO.

Automatiza snapshots y copias externas. Si aún no tienes una rutina fiable, revisa la implementación de backups incrementales.

  • Backups completos + incrementales, con pruebas de restauración.
  • Retención de binlog alineada al RPO; monitoriza espacio en disco.
  • Dump lógico solo para emergencias; prefiere físicos/snapshots.
  • Runbooks de recuperación y accesos de emergencia controlados.
  • Hardening y monitorización en la VPS: consulta el checklist de seguridad.

Preguntas frecuentes

¿Se puede recuperar sin binlog y sin backup?

A veces sí. Las herramientas de undrop para InnoDB pueden extraer registros de páginas no sobrescritas. El éxito depende de parar I/O rápidamente y trabajar sobre una copia del disco. Es más incierto y laborioso que reaplicar binlogs.

¿Puedo reiniciar MySQL después del DROP para intentar arreglarlo?

Evita reiniciar. El reinicio y la actividad del servidor pueden sobrescribir páginas InnoDB reutilizables, reduciendo las posibilidades de undrop. Primero aísla, haz snapshot o imagen del disco y solo entonces intenta recuperar en copia.

¿Es seguro aplicar mysqlbinlog directo en producción?

No es recomendable. Reproduce eventos en un servidor de recuperación, valida datos y solo entonces importa la tabla recuperada a producción. Aplicar directamente aumenta el riesgo de ejecutar comandos indeseados, como el propio DROP.

¿Cómo encuentro el punto exacto del DROP en el binlog?

Usa mysqlbinlog para listar eventos y busca "DROP TABLE `minha_tabela`" o por la hora aproximada. En formato ROW, decodifica con --verbose y --base64-output. Define --stop-datetime o --stop-position antes del DROP para detener la reproducción.

¿Undrop funciona si uso innodb_file_per_table?

Puede funcionar, pero es más difícil. El DROP elimina el .ibd y libera páginas. Si las páginas no se han sobrescrito, aún es posible extraer datos escaneando el disco. Cuanto más rápido actúes y menor la actividad, mayores las probabilidades.

¿Cuál es la mejor retención de binlog para recuperación?

Depende de tu RPO y del volumen de escritura. Conserva binlogs el tiempo suficiente para cubrir incidentes detectados después; monitoriza el espacio en disco. Prueba la recuperación periódicamente para validar la ventana de retención elegida.

¿Necesitas recuperar datos MySQL en tu VPS con seguridad?

Cuéntanos tu caso: podemos evaluar rápidamente las opciones (binlog, snapshot o undrop) y recomendar el camino más seguro para restaurar la tabla.

Hablar sobre recuperación MySQL

Ver también