Son las 11:47.
Un desarrollador está trabajando sobre la base de datos de un cliente.
Necesita limpiar unos registros.
Ejecuta una consulta.
Y, unos segundos después, llega el mensaje:
“Creo que acabo de borrar una tabla de producción.”
Silencio.
Después vienen las preguntas.
¿Cuándo fue el último backup?
¿Dónde está?
¿Está completo?
¿Cuánto tardamos en restaurarlo?
¿Vamos a perder todo lo que ha ocurrido desde esta madrugada?
¿Tenemos binary logs?
¿Funcionan?
¿Alguien ha probado alguna vez una restauración?
Y probablemente la más incómoda:
¿Tenemos realmente una estrategia de backup o simplemente tenemos una tarea programada que dice que hace backups?
Son dos cosas muy diferentes.
Los errores humanos también forman parte de producción
Cuando hablamos de pérdida de datos solemos imaginar escenarios extremos:
- un ransomware;
- un fallo de disco;
- una región cloud caída;
- corrupción de datos;
- un ataque;
- un fallo grave de infraestructura.
Pero muchas incidencias empiezan de una forma mucho menos espectacular.
DELETE FROM customers;cuando querías ejecutar:
DELETE FROM customers
WHERE id = 12345;O un:
DROP TABLE orders;sobre la base de datos equivocada.
O un script de migración que tenía un comportamiento que nadie esperaba.
O una automatización que se ejecutó contra producción en lugar de staging.
No hace falta que nadie sea incompetente.
Solo hace falta una consola abierta, permisos suficientes y unos segundos de despiste.
Por eso una estrategia de backups no debería diseñarse pensando únicamente en que “un servidor puede romperse”.
También debería asumir algo mucho más sencillo:
las personas se equivocan.
Tener backups no significa poder recuperar
Este es probablemente uno de los errores más peligrosos.
Alguien pregunta:
¿Tenemos backups?
Y la respuesta es:
Sí, se hacen todas las noches.
Perfecto.
Ahora vienen las preguntas importantes.
¿Cuándo fue la última restauración que probaste?
¿Cuánto tardó?
¿Comprobaste que los datos eran válidos?
¿Sabes exactamente cuánto perderías si ocurre una incidencia ahora mismo?
Porque un archivo de backup almacenado en algún sitio no es todavía una estrategia de recuperación.
Puede estar incompleto.
Puede estar corrupto.
Puede que las credenciales necesarias para acceder a él ya no funcionen.
Puede que el procedimiento de restauración no esté documentado.
Puede que tarde seis horas cuando el negocio esperaba recuperar el servicio en treinta minutos.
Puede incluso que todo funcione correctamente… excepto que el último backup sea de hace 23 horas.
Y entonces la pregunta deja de ser:
“¿Tenemos backup?”
y pasa a ser:
“¿Podemos recuperar el servicio y los datos al punto que necesitamos?”
Ese es el problema que realmente importa.
El backup de esta madrugada puede no ser suficiente
Supongamos que haces un backup completo todas las noches a las 02:00.
A las 15:36 alguien elimina accidentalmente una tabla crítica.
Puedes restaurar el backup.
Pero acabas de descubrir otro problema.
El estado de la base de datos volverá a las 02:00.
¿Qué ocurre con las operaciones realizadas durante las siguientes 13 horas y 36 minutos?
- Clientes creados.
- Pedidos y compras.
- Facturas generadas.
- Cambios de configuración.
- Transacciones críticas.
- Información introducida por usuarios.
En algunos sistemas perder unas horas de datos puede ser asumible.
En otros puede ser una catástrofe.
Por eso existen mecanismos de Point-in-Time Recovery (PITR).
MySQL Binary Log: esos pequeños archivos que pueden salvarte el día
En MySQL existe una herramienta especialmente útil para estos escenarios: el binary log, normalmente conocido como binlog.
MySQL registra en estos archivos los cambios realizados sobre los datos.
Esto permite utilizar un backup completo como punto de partida y posteriormente reproducir los cambios registrados hasta alcanzar un momento concreto. MySQL documenta precisamente esta combinación de backup completo y binary logs para realizar recuperación punto en el tiempo.
Imagina:
- 02:00 → backup completo
- 02:00–15:36 → cambios registrados en binary logs
- 15:36:42 → operación destructiva
En lugar de aceptar perder todo desde las 02:00, podemos plantear una recuperación hasta, por ejemplo:
15:36:41
Un segundo antes del desastre.
Conceptualmente:
Backup completo + Binary Logs → estado inmediatamente anterior al incidente
Los binary logs permiten seleccionar los eventos que queremos reproducir utilizando tiempo o posiciones dentro del propio log.
Eso cambia completamente el impacto de una incidencia.
Pero hay una aclaración importante.
Los binary logs no sustituyen al backup
El binlog no debería entenderse como “ya no necesito backups”.
La recuperación punto en el tiempo normalmente parte de un backup y después utiliza los logs para reconstruir los cambios posteriores.
Necesitas ambas piezas de la estrategia.
Y necesitas conservarlas correctamente.
Si el servidor desaparece y tus backups y logs estaban exclusivamente en el mismo almacenamiento que acabas de perder, la estrategia tenía un problema bastante serio desde el principio.
En cloud tampoco deberías darlo por hecho
Usar una base de datos gestionada no elimina esta responsabilidad.
Servicios como Azure Database for MySQL permiten realizar restauraciones punto en el tiempo dentro del periodo de retención configurado. Microsoft indica que el servicio utiliza backups completos y logs de transacciones y permite configurar el periodo de retención de backups.
Google Cloud SQL también dispone de PITR para recuperar una instancia hasta un momento específico.
Otros proveedores ofrecen mecanismos equivalentes.
Pero que la funcionalidad exista no significa necesariamente que esté configurada como necesitas.
Hay que revisar:
- retención,
- frecuencia,
- PITR,
- ubicación,
- cifrado,
- permisos,
- dependencias,
- tiempos de restauración
- y procedimientos.
El botón de “Enable automated backups” es el principio de la conversación, no el final.
RPO y RTO: dos siglas bastante menos aburridas cuando acabas de perder datos
Hay dos preguntas que toda empresa debería poder responder.
RPO — Recovery Point Objective
¿Cuántos datos estamos dispuestos a perder?
Si haces únicamente un backup diario, tu pérdida potencial puede acercarse a 24 horas.
Con backups, snapshots, replicación y mecanismos de recuperación punto en el tiempo correctamente configurados, ese intervalo puede reducirse considerablemente.
Pero el RPO no debería descubrirse durante una incidencia.
Debería decidirse antes.
RTO — Recovery Time Objective
¿Cuánto podemos tardar en recuperar?
Puedes tener un backup perfecto.
Pero si restaurarlo requiere:
- localizarlo;
- descargar cientos de gigabytes;
- levantar una nueva instancia;
- recuperar la base de datos;
- configurar usuarios;
- actualizar conexiones;
- validar los datos;
- cambiar DNS o configuración;
- y hacerlo siguiendo una documentación de hace dos años…
quizás técnicamente tienes backup.
Operativamente tienes otro problema.
“El backup terminó correctamente” no demuestra demasiado
Esta línea en un dashboard:
Backup completed successfully
da tranquilidad.
Pero únicamente demuestra que una operación terminó.
No demuestra necesariamente que puedas recuperar tu sistema completo.
La única forma seria de saberlo es restaurando.
En un entorno aislado.
De forma periódica.
Y comprobando el resultado.
Una prueba de recuperación debería permitir responder, como mínimo:
- ¿El backup puede restaurarse?
- ¿Cuánto tarda?
- ¿Los datos están íntegros?
- ¿Podemos recuperar hasta el punto temporal esperado?
- ¿Tenemos todos los secretos y configuraciones necesarios?
- ¿El procedimiento está documentado?
- ¿Puede realizarlo alguien distinto de quien diseñó originalmente el sistema?
- ¿Cumplimos nuestros RPO y RTO?
Porque el peor momento para aprender a restaurar una base de datos es cuando producción ya está caída.
No restaures directamente sobre producción si puedes evitarlo
Aquí aparece otro detalle importante.
Ante una pérdida accidental de datos, la reacción inmediata puede ser restaurar producción cuanto antes.
Pero hacerlo directamente sobre el sistema afectado puede complicar todavía más las cosas.
Cuando sea viable, suele ser mucho más seguro recuperar el backup o realizar PITR sobre una instancia independiente.
Así puedes:
- reconstruir el estado anterior al incidente;
- comprobar qué información se ha perdido;
- validar que la recuperación es correcta;
- extraer únicamente los datos necesarios si procede;
- decidir después cómo reincorporarlos a producción.
Eso reduce el riesgo de transformar un error original en dos.
Y no, una réplica tampoco es necesariamente un backup
Otro error habitual:
Tenemos una réplica, estamos cubiertos.
No necesariamente.
Si ejecutas:
DROP TABLE customers;y esa operación se replica correctamente…
ahora tienes una fantástica réplica en la que también falta customers.
La alta disponibilidad y los backups resuelven problemas diferentes.
La replicación puede ayudarte ante fallos de infraestructura.
Los backups y la recuperación punto en el tiempo protegen frente a escenarios distintos, incluida la eliminación o modificación accidental de información.
Una arquitectura madura suele necesitar varias capas.
La estrategia que importa es la que puedes ejecutar bajo presión
Una política razonable debería contemplar, como mínimo:
- Backups automáticos: No depender de que alguien recuerde ejecutar un comando los viernes.
- Retención adecuada: Siete días, treinta, noventa o lo que determine el negocio, la regulación y el tipo de información.
- Recuperación punto en el tiempo cuando sea necesaria: Especialmente en bases de datos con modificaciones continuas.
- Copias fuera del dominio de fallo principal: Un problema en una infraestructura no debería llevarse también por delante todas las posibilidades de recuperación.
- Monitorización: Si un backup deja de ejecutarse hoy, alguien debería enterarse hoy. No dentro de cuatro meses.
- Pruebas periódicas de restauración: Automatizadas cuando sea posible.
- Runbooks: Qué restaurar, desde dónde, en qué orden, quién tiene permisos, qué validar y cómo realizar el cutover.
- RPO y RTO definidos: No “lo antes posible”. Números.
Haz una prueba esta semana
Hay una comprobación sencilla que dice muchísimo sobre el estado de una infraestructura.
Pregunta a tu equipo:
Si ahora mismo alguien borra accidentalmente la tabla más importante de producción, ¿a qué punto exacto podemos recuperar y cuánto tardaríamos?
Si la respuesta es clara:
bien.
Si empieza con:
“En teoría…”
conviene revisar algunas cosas.
Y si nadie sabe dónde están los backups:
ya tienes una prioridad para esta semana.
Los backups son aburridos hasta el día que dejan de serlo
Nadie celebra tener un buen backup.
Nadie publica en Slack:
“Otro fantástico martes en el que no hemos necesitado restaurar la base de datos.”
Es infraestructura invisible.
Hasta que un día alguien ejecuta el comando equivocado.
Y entonces unos buenos backups, unos binary logs correctamente conservados, PITR configurado, procedimientos probados y alguien que sabe exactamente qué hacer pueden convertir una posible catástrofe en una incidencia controlada.
Un rato incómodo.
Algún sudor frío.
Y una buena historia para contar después.
En lugar de llamadas a clientes, pérdida de datos y una conversación bastante menos agradable.
En Nubyron ayudamos a equipos a revisar precisamente este tipo de puntos: mantenimiento cloud, auditoría de infraestructura, continuidad, recuperación ante desastres, observabilidad y operativa.
Porque la pregunta importante no es si tu infraestructura hace backups.
Es esta:
¿Estás seguro de que podrías recuperarla mañana?
