2 publicaciones etiquetados con "recuperación de copias de seguridad"

Publicado el 6 de agosto de 2026

Un despliegue fallido de un plugin dejó fuera de servicio el checkout de un pequeño minorista en línea a las 09:13. Este ejemplo de recuperación de copias de seguridad de ecommerce muestra qué restauró el equipo de operaciones, qué no restauró y por qué la tienda volvió a aceptar pedidos a las 10:00 sin eliminar silenciosamente compras válidas de clientes.

El síntoma inmediato fue un error 502 en el checkout, mientras que las páginas de categoría seguían cargando desde la caché. La monitorización del servidor mostró un uso normal de CPU, memoria y disco. En cambio, los registros apuntaban a un error fatal de PHP introducido por los nuevos archivos del plugin de pagos. Esa distinción importa. Reiniciar un servidor o restaurarlo todo desde una copia de seguridad puede empeorar una mala situación si la base de datos en producción sigue registrando pedidos.

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.