Prepare y pruebe primero el nuevo servidor, copie los datos con un método de coherencia compatible con la aplicación, defina una ventana de conmutación y conserve el entorno antiguo. La reversión debe tener en cuenta las escrituras aceptadas en el nuevo servidor, no solo un cambio de DNS.
Inventariar el servicio antes de mover la máquina
Una migración incluye más que los archivos de la aplicación. Enumere las bases de datos, las cargas, los trabajos programados, los workers de cola, los certificados, los dominios, los secretos y las integraciones salientes. Registre las versiones de software y los supuestos operativos que importan, como los permisos de archivos y las rutas de almacenamiento. Un servidor dedicado nuevo puede exponer una dependencia olvidada que se instaló silenciosamente años antes en el entorno antiguo.
Asigne un responsable de la decisión de conmutación y defina cómo se ve el éxito. Incluya comprobaciones visibles para el usuario, coherencia de datos y capacidad de recuperar el acceso. Confirme que la nueva configuración está entregada y es utilizable antes de anunciar una fecha de migración. Una confirmación de pedido o una especificación de hardware listada no es lo mismo que un destino operativo listo para recibir datos de producción.
Construir el destino como un entorno separado
Instale la pila requerida, establezca la administración y configure el firewall previsto. Mantenga los secretos en privado y establezca los permisos de servicio deliberadamente. Verifique el nombre de host y el comportamiento del certificado esperados por la aplicación antes de que se mueva el tráfico público. La documentación de hosts virtuales de Apache ilustra por qué el enrutamiento por nombre de host es una decisión de configuración separada de la dirección del servidor. Una página predeterminada que funciona no demuestra que el host de aplicación correcto esté configurado.
Utilice un conjunto de datos restaurado representativo para el ensayo, con el correo saliente, los pagos y los trabajos programados deshabilitados o redirigidos a sistemas de prueba seguros. Esto evita que el entorno de prueba actúe sobre usuarios reales. Ejercite el inicio de sesión, las cargas, el trabajo en segundo plano y la restauración. Registre el procedimiento y su duración para que la ventana real se base en un proceso observado en lugar de en el optimismo.
Elegir un límite de datos coherente
Utilice un método de copia de seguridad o replicación compatible con la base de datos y la aplicación. PostgreSQL distingue entre volcados SQL, copias de seguridad del sistema de archivos y archivado continuo, cada uno con sus propios supuestos. Su guía sobre volcados señala que los volcados de base de datos pueden ser internamente coherentes mientras que los roles de todo el clúster y otros detalles necesitan un tratamiento aparte. Lea los requisitos del sistema exacto que ejecuta en lugar de copiar archivos de datos abiertos indiscriminadamente.
Planifique cómo se relaciona la base de datos con las cargas y el estado de la cola. Si un registro apunta a un archivo que se copió en un momento diferente, la aplicación restaurada puede quedar incompleta aunque ambas copias hayan tenido éxito individualmente. Decida si pausar brevemente las escrituras, usar una disposición de replicación probada o realizar una exportación específica de la aplicación. Mantenga esa decisión de coherencia explícita en el runbook.
| Etapa | Evidencia requerida | Decisión |
|---|---|---|
| Ensayo | La aplicación y los datos restaurados superan las comprobaciones | El destino puede considerarse para la conmutación |
| Sincronización final | Punto de recuperación coherente definido | Continuar solo con los cambios restantes comprendidos |
| Cambio de tráfico | Enrutamiento y comportamiento del certificado correctos | Supervisar ambos destinos |
| Reversión | Ubicación de todas las escrituras recién aceptadas | Conciliar los datos antes de devolver el tráfico |
Preparar el enrutamiento del tráfico sin prometer cambios instantáneos
El tiempo de vida de DNS controla cuánto tiempo pueden almacenarse en caché los registros, como se explica en la documentación de DNS de Cloudflare. Revise el TTL con antelación si DNS forma parte de la migración, y permita que los registros en caché existentes caduquen según su configuración anterior. Cambiar el valor en el momento de la conmutación no puede acortar retroactivamente todas las respuestas en caché. Distintos clientes pueden llegar a destinos diferentes durante la transición.
Mantenga disponible el entorno antiguo mientras se asientan los cambios de enrutamiento, con una política deliberada sobre si aún puede aceptar escrituras. Evite ejecutar consumidores de cola o trabajos programados duplicados a menos que la aplicación esté diseñada para ello. Supervise las solicitudes en ambos lados y confirme el nombre de host previsto, el certificado TLS y la versión de la aplicación desde clientes independientes.
Definir la reversión después de que comiencen las escrituras
Antes de que el nuevo sistema acepte cambios, el tráfico de retorno puede ser relativamente sencillo. Después, una sola reversión de DNS puede perder trabajo o crear dos historiales en conflicto. Defina cómo se preservarían o reconciliarían los registros y las cargas recién creados. Si la aplicación no puede fusionarlos de forma segura, un periodo de mantenimiento controlado puede ser preferible a un retorno improvisado a la copia antigua.
Establezca las condiciones que exigen pausar la migración y mantenga accesible al responsable de la decisión. Conserve los registros y las pruebas útiles conforme a las reglas de retención del proyecto. No elimine la máquina antigua ni su copia de recuperación independiente solo porque la página de inicio se cargó una vez. El periodo de retención debe cubrir las necesidades acordadas de verificación y reversión.
Cerrar la migración con comprobaciones operativas
Después del cambio, verifique las copias de seguridad, las alertas, la renovación de certificados, el trabajo programado y la recuperación de acceso. Confirme que el host monitorizado es el nuevo destino y que no quedan integraciones de prueba en producción. Revise los errores de la aplicación y los tiempos visibles para el usuario con tráfico normal. Actualice el inventario y el runbook para que el siguiente administrador no tenga que inferir qué cambió.
Las familias dedicadas de SwissOctet ofrecen diferentes configuraciones físicas, pero el trabajo de migración y la asistencia gestionada deben confirmarse para el servicio elegido. Use el catálogo para seleccionar recursos adecuados y luego construya un traslado probado en torno a los datos de su aplicación. Una migración está completa cuando el servicio y su proceso de recuperación funcionan en el destino, no simplemente cuando se han transferido los archivos.
Su lista de verificación práctica.
- Inventaríe los datos, las tareas, los secretos y las integraciones.
- Verifique el destino entregado antes de programar.
- Ensaye con integraciones externas seguras.
- Defina la consistencia de la base de datos y las cargas.
- Planifique la transición de enrutamiento y la prevención de tareas duplicadas.
- Especifique la reversión para las nuevas escrituras.
- Verifique las copias de seguridad y la monitorización después del cambio.
Los detalles que importan.
¿Puedo migrar copiando el directorio de la aplicación?+
Solo si eso captura todo lo que el servicio necesita y preserva la consistencia. Las bases de datos, las cargas, las tareas, los secretos y la configuración normalmente requieren atención por separado.
¿Reducir el TTL de DNS hace que el cambio sea instantáneo?+
No. Las respuestas previamente en caché pueden permanecer hasta que termine su vida útil anterior, y los clientes pueden actualizarse en momentos diferentes.
¿La reversión consiste solo en apuntar DNS al servidor antiguo?+
No después de que el nuevo servidor acepte escrituras. Debe tener en cuenta esos registros y archivos antes de devolver el tráfico.
Vaya a la fuente.
Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción.
- PostgreSQL: Copia de seguridad y restauración www.postgresql.org
- PostgreSQL: Consistencia y restauración de volcados SQL www.postgresql.org
- Apache: Documentación de host virtual httpd.apache.org
- Cloudflare DNS: Tiempo de vida developers.cloudflare.com
Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado.