Caso práctico de recuperación de copias de seguridad: 6 horas atrás
Publicado el 10 de julio de 2026
A las 02:14 UTC, la tienda dejó de escribir pedidos en la base de datos. A las 02:19, el sitio seguía sirviendo páginas en caché, pero el proceso de compra ya se había convertido en ficción. Este caso práctico de recuperación de copias de seguridad explica lo que ocurrió después en un VPS de producción para un pequeño negocio de comercio electrónico, qué restauramos, qué no restauramos a ciegas y por qué el servicio volvió a estar estable antes del amanecer.
El cliente ejecutaba una pila bastante estándar para una tienda en línea en crecimiento: Nginx, PHP-FPM, MariaDB, Redis y un panel de control utilizado por dos miembros del personal que no eran administradores de sistemas. El tráfico no era enorme, pero el momento fue doloroso. Una campaña de ventas había elevado el volumen de pedidos, las escrituras en la base de datos estaban alcanzando su punto máximo y un problema de almacenamiento en la capa del filesystem empezó a corromper tablas activas de la base de datos. No fue dramático al estilo de Hollywood, pero sí lo bastante serio como para que cada minuto importara.
La primera tarea no fue la restauración. La primera tarea fue evitar que el daño se propagara. Pusimos la aplicación en modo de mantenimiento, preservamos el estado actual del disco para su revisión y comprobamos si la replicación, los snapshots o los logical dumps nos daban el punto de recuperación más limpio. Esto importa más de lo que a la gente le gusta admitir. Una recuperación rápida está bien. Una recuperación rápida hacia datos dañados solo es una decepción rápida.
Qué falló y cómo lo supimos
Los registros ya contaban la misma historia. MariaDB empezó a informar errores de checksum de páginas de InnoDB, seguidos de fallos de tablas con mucha escritura de pedidos y sesiones. El propio hipervisor estaba en buen estado. El comportamiento de CPU, RAM y red se mantuvo normal. Esto alejó el incidente de una caída amplia de la plataforma y lo orientó hacia la integridad del almacenamiento a nivel del guest.
Verificamos tres cosas antes de tocar las copias de seguridad. Primero, si el problema estaba aislado a un pequeño conjunto de tablas y podía repararse in situ. Segundo, si las copias de seguridad recientes eran válidas y podían montarse. Tercero, si cualquier transacción completada después de la última copia de seguridad conocida como buena podía reconstruirse a partir de los registros de la aplicación, las confirmaciones por correo electrónico o los registros de la pasarela de pago.
Esa tercera comprobación a menudo se omite. No debería hacerse. Restaurar una copia de seguridad no es toda la recuperación. A las empresas les importan los pedidos perdidos, los registros de clientes y el estado de las facturas, no solo si MySQL vuelve a arrancar.
La ruta de recuperación que elegimos
Este caso práctico de recuperación de copias de seguridad es útil porque la opción obvia no era la mejor opción. Teníamos tres rutas candidatas.
Una reversión completa de snapshot de la VM habría sido la más rápida en términos de cantidad de clics, pero también habría descartado varias horas de cambios legítimos en el contenido, actualizaciones de plugins y ediciones en cuentas de clientes. Reparar las tablas in situ implicaba demasiado riesgo porque la corrupción ya había afectado a datos transaccionales esenciales. La mejor ruta era una restauración a nivel de archivos y de base de datos en una instancia nueva, seguida de una conciliación selectiva de datos.
Así que primero aprovisionamos un entorno de recuperación limpio. El mismo tamaño de VPS, la misma familia de SO, la misma versión del panel, la misma rama de PHP. Reconstruir en una instancia paralela da margen para respirar. También protege el sistema original para la revisión forense, lo que resulta útil si el cliente necesita entender la causa raíz o verificar que el problema no fue causado por el comportamiento de la aplicación.
Recuperamos la última copia de seguridad automática correcta de las 23:00 UTC. Luego la probamos antes del cambio. Suena básico, pero muchos equipos solo descubren problemas con las copias de seguridad en la peor hora posible. El archivo se montó correctamente, los checksums coincidían, la importación de la base de datos se completó sin errores y la aplicación arrancó de forma aislada. Bien. La calma empieza ahí.
Restaurar el servicio sin crear nuevos problemas
La recuperación tuvo cuatro etapas. Primero, la infraestructura. Reconstruimos la pila web, aplicamos actualizaciones del sistema que ya estaban aprobadas e igualamos las versiones del runtime para que la aplicación no fallara por un desajuste inesperado de dependencias.
Segundo, los datos. La restauración de la base de datos se completó en 11 minutos. Los archivos web se restauraron en menos de 4 minutos. Los recursos multimedia estaban intactos, lo que evitó al cliente imágenes de productos rotas y molestos cuadros vacíos en el navegador. Redis no se restauró desde la copia de seguridad porque los datos en caché son desechables por diseño. Volver a introducir caché obsoleta en un entorno nuevo es uno de esos pequeños errores que luego provocan un gran desastre.
Tercero, la validación. Comprobamos el inicio de sesión de la aplicación, el flujo de compra, las escrituras del panel de administración, la ejecución de cron, la validez del SSL, el correo saliente y el comportamiento de callback de la pasarela de pago. También comparamos los recuentos de registros de pedidos, clientes y tablas de catálogo con las curvas de crecimiento esperadas de la semana anterior. Los números no necesitan ser poesía perfecta, pero no deberían parecer extraños.
Cuarto, la conciliación. Entre las 23:00 UTC y las 02:14 UTC, se habían procesado algunos pagos correctos. Esos registros no existían en la base de datos restaurada porque ocurrieron después del punto de copia de seguridad. Los reconstruimos a partir de confirmaciones del proveedor de pagos, notificaciones de pedidos por correo electrónico y registros de acceso web. Aquí es donde un operador experimentado ahorra mucho dolor empresarial. Una restauración técnicamente correcta que pierde pedidos pagados no es realmente un éxito.
A las 03:41 UTC, la aplicación estaba disponible para la revisión interna del cliente. A las 04:06 UTC, el DNS y el enrutamiento en el edge redirigieron el tráfico de producción de vuelta a la instancia recuperada. La interrupción total del proceso de compra de cara al cliente fue de poco menos de dos horas, mientras que el acceso de lectura a la mayor parte del sitio permaneció disponible durante buena parte del incidente.
Qué hizo que la recuperación fuera rápida
No fue suerte, ni fue un botón mágico de copia de seguridad. La rapidez vino de la preparación y de reducir las decisiones durante el incidente.
El cliente ya tenía copias de seguridad programadas automáticas con retención, comportamiento del servidor monitorizado y una ruta de soporte que no desaparecía en el silencio de los tickets. Eso cambió la forma de la noche. No estábamos debatiendo si existía una copia de seguridad. Estábamos eligiendo el punto de restauración más seguro y validándolo.
La consistencia del entorno también importó. Como la pila de hosting estaba estandarizada, no pasamos 45 minutos de nervios descubriendo que la aplicación restaurada necesitaba una extensión antigua de PHP o una biblioteca del sistema ausente. La gente suele subestimar cuánto tiempo de recuperación se quema en la deriva de configuración.
También hubo una ventaja menos visible: separar lo que tiene estado de lo que es desechable. El contenido de la base de datos, los archivos multimedia subidos, la configuración y los recursos SSL se trataron con cuidado. La caché, los archivos temporales y las sesiones generadas se reconstruyeron de forma limpia. Esto hace que la recuperación sea más ligera y evita arrastrar ruido antiguo a un arranque nuevo.
Lo que enseña este caso práctico de recuperación de copias de seguridad
La lección principal no es simplemente hacer una copia de seguridad de tu servidor. La mayoría de las empresas ya conocen esa frase. La lección más difícil es diseñar la recuperación en torno a la función de negocio, no solo a los objetos de infraestructura.
Un snapshot de VM es útil, pero puede ser demasiado tosco. Un volcado de base de datos es útil, pero no suficiente si los archivos subidos están separados. Una copia de seguridad del panel de control es cómoda, pero esa comodidad también debe probarse. La estrategia correcta de copia de seguridad depende de cómo se comporta la aplicación, con qué frecuencia cambian los datos y qué cantidad de pérdida es realmente aceptable.
Para un sitio de comercio electrónico, las imágenes de productos normalmente pueden tolerar puntos de recuperación algo más antiguos que los registros de pedidos. Para una aplicación SaaS, el estado de la base de datos de clientes puede importar más que el contenido del filesystem local. Para una agencia digital que aloja varios sitios de clientes en un solo servidor, el aislamiento se vuelve crítico porque un sitio ruidoso no debería convertir la recuperación en un dolor de cabeza de todo el rack.
Las pruebas también merecen más respeto. Las copias de seguridad son promesas hasta que se restauran. Después de restaurarse, se convierten en evidencia. La diferencia es costosa.
Qué cambió después del incidente
No tratamos la recuperación como la línea de meta. Después de estabilizar el servicio, revisamos el comportamiento del almacenamiento, la salud del filesystem, las comprobaciones de integridad de la base de datos y la temporización de la política de copias de seguridad. La causa técnica inmediata apuntaba a una inconsistencia del disco a nivel del guest bajo presión de escritura, pero la cuestión más amplia era cómo reducir el radio de impacto la próxima vez.
Se ajustó la frecuencia de las copias de seguridad para la capa de base de datos con el fin de acortar la exposición del punto de recuperación durante las campañas. Se endurecieron los umbrales de alerta para la espera de E/S y los patrones de errores de la base de datos. El cliente también pasó de una mentalidad de restauración única a una por capas: copias de seguridad automáticas, rutinas de restauración verificadas y un manejo más claro de la conciliación transaccional.
Aquí es donde el soporte operativo gestionado demuestra su valor. No porque los incidentes nunca ocurran, sino porque cuando ocurren, alguien ya sabe dónde mirar primero y qué no romper mientras lo arregla. Esa pequeña diferencia suele ser toda la diferencia.
Si ejecutas cargas de trabajo que generan ingresos, la pregunta útil no es si tienes copias de seguridad. La pregunta útil es si, a las 2 a. m., puedes restaurar los datos correctos en el lugar correcto, verificarlos rápido y dar cuenta de lo que ocurrió después de que se hiciera la copia de seguridad. Si la respuesta es incierta, el sistema sigue pidiendo atención. Es mejor responderla en una tarde tranquila que durante un fallo del proceso de compra.
Andres Saar Ingeniero de Atención al Cliente