Lista de verificación para la migración de VPS: copias de seguridad, DNS, TLS y reversión
Una secuencia práctica de migración para una aplicación autoalojada: inventario, copias de seguridad consistentes, un destino probado, escrituras controladas, cambio DNS y una vía de restauración.
De un vistazo
Una migración de VPS controlada inventaría los servicios y los datos, crea una copia de seguridad consistente, verifica un destino restaurado, prueba el enrutamiento de nombre de host y TLS, coordina las escrituras finales y DNS, y preserva una reversión consciente de los datos. Ninguna lista de verificación por sí sola garantiza cero tiempo de inactividad.
Inventaríe la aplicación antes de moverla
Enumere los servicios, las versiones, los puertos, las tareas programadas, las bases de datos, los archivos cargados y la configuración necesarios para que la aplicación funcione. Identifique dónde se producen las escrituras y de qué servicios externos depende. Un directorio web copiado no es una migración completa cuando los datos residen en otro lugar.
Registre los nombres actuales de DNS, los IPv4 activos y los registros IPv6, los métodos de renovación de certificados y una vía de acceso de recuperación. Guarde los secretos en sus herramientas privadas de despliegue. No coloque contraseñas, claves privadas ni volcados de bases de datos en un directorio raíz web público ni en una lista de verificación de migración compartida.
Cree una copia de seguridad consistente y compruebe que se restaura
Use el mecanismo de copia de seguridad compatible con la base de datos en lugar de copiar archivos arbitrarios mientras continúan las escrituras. Para SQLite, el Online Backup API crea una instantánea consistente de la base de datos. En modo WAL, el archivo WAL participa en el estado persistente de la base de datos, por lo que copiar solo el archivo principal de la base de datos puede omitir cambios confirmados.
Una copia de seguridad consistente de la base de datos no es automáticamente consistente con las cargas, las colas o los archivos almacenados por separado. Coordine su captura con su aplicación. Restaure en una ubicación de prueba separada y verifique los registros, las referencias a archivos y el comportamiento de la aplicación antes de considerar la copia de seguridad utilizable.
Prepare el destino antes de cambiar DNS
Cree los usuarios, los permisos, las versiones de tiempo de ejecución, los servicios y los directorios de la aplicación previstos en el nuevo servidor. Restaure la copia de seguridad de prueba en su ubicación de datos de destino, fuera del directorio raíz web público cuando corresponda. Verifique la propiedad y el acceso usando la cuenta de servicio que realmente ejecutará la aplicación.
Conserve los sitios no relacionados en un servidor compartido. Use un directorio raíz de documentos, un host virtual y un tiempo de ejecución dedicados, valide la configuración del servidor web y prepare una reversión que restaure solo los archivos y la configuración que pertenecen a este cambio.
Pruebe el nombre de host real y el certificado en el nuevo servidor
Una solicitud del navegador a una dirección IP simple no reproduce el enrutamiento basado en el nombre de host ni la validación del certificado. curl --resolve permite que una prueba use el nombre de host previsto y una IP de destino elegida, conservando las comprobaciones normales de nombre de host y TLS. Verifique también el estado HTTP y el contenido esperado de la aplicación. El ejemplo usa valores solo para documentación; reemplácelos con su propio dominio y destino verificados.
Ya debe existir un certificado válido y una ruta de red permitida para que esa prueba se supere. Nunca desactive la verificación de certificados para declarar la migración lista. La validación ACME basada en DNS puede validar un dominio sin cambiar la dirección de su servidor web; la validación basada en HTTP tiene requisitos de alcanzabilidad diferentes. Pruebe la renovación por separado de la emisión inicial.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Elija un plan de control de escrituras y sincronización final
Programe un breve período de mantenimiento u otro mecanismo de consistencia adecuado para la aplicación. Detenga o redirija los escritores que identificó, tome la copia de seguridad final consistente de la base de datos, sincronice los archivos mutables correspondientes y verifique el resultado. Los trabajadores en cola, los webhooks y las tareas cron pueden escribir incluso cuando la interfaz pública parece tranquila.
Haga una ejecución de prueba antes de una sincronización de archivos. No añada indicadores de eliminación ni copie directorios completos del sistema como atajo. Mantenga el servicio anterior recuperable hasta que haya comprobado la nueva aplicación y establecido qué ubicación es la autoritativa para las escrituras.
Cambie DNS y luego observe ambas familias de direcciones
Actualice los registros necesarios para el servicio y tenga en cuenta las cachés de resolución existentes. Verifique las respuestas autoritativas y varias rutas de cliente normales. Si permanece activo un registro AAAA obsoleto, los clientes IPv6 pueden seguir llegando al servidor antiguo mientras que los clientes IPv4 llegan al nuevo.
Pruebe el inicio de sesión, las lecturas, las escrituras, las cargas, las tareas en segundo plano y las devoluciones de llamada externas en el nuevo servicio. Evite ejecutar dos copias escribibles independientes de la misma aplicación durante la transición. Mantenga una regla clara para gestionar el tráfico que aún llega al destino antiguo.
Haga de la reversión una decisión de datos y también una decisión de DNS
Defina las condiciones de fallo que desencadenan una reversión y quién controla el cambio. Revertir solo DNS no es suficiente después de que nuevas escrituras hayan llegado al destino: debe preservar o reconciliar esos datos antes de volver a una copia anterior.
Conserve el origen y las copias de seguridad durante un período de recuperación adecuado. Elimine el acceso antiguo y desmantelas los recursos solo después de que se hayan comprobado el destino, las copias de seguridad, la renovación y el monitoreo. La retención y la eliminación deben seguir la política real del servicio, no un número fijo genérico de horas.