2 publicaciones etiquetados con "pruebas"

Publicado el 10 de septiembre de 2026

Para migrar un sitio de cPanel a un VPS sin una caída inesperada, trata el DNS como el cambio final, no como la primera tarea. Prepara el servidor de destino, copia la cuenta, pruébala en la nueva dirección IP, reduce el TTL del DNS y luego cambia los registros solo después de que las comprobaciones de la aplicación, el correo y el SSL se hayan completado correctamente. El sitio permanece disponible mientras el trabajo ocurre en segundo plano.

Para el sitio de una pequeña empresa, una cuenta de agencia o una tienda con pedidos en vivo, la migración consiste menos en mover archivos y más en preservar el comportamiento del servicio. Las versiones de PHP, los permisos de base de datos, los cron jobs, el enrutamiento del correo, las redirecciones y las reglas del firewall deben llegar todos en un estado conocido y correcto. Los archivos suelen ser la parte fácil. Las pequeñas configuraciones ocultas a su alrededor son donde las migraciones se ganan las canas.

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.