Cómo migrar un servidor a un VPS nuevo

Migre un servidor a un VPS nuevo como un cambio planificado

Para migrar un servidor a un VPS nuevo, trate el traslado como un cambio planificado y ensayado, no como una simple copia. Prepare el nuevo sistema desde cero, sincronice los datos dos veces, compruebe que el nuevo sistema funciona con su propia dirección IP antes de modificar el DNS y, después, cambie los registros. Mantenga el servidor antiguo en funcionamiento hasta tener certeza de que todo está correcto. Copiar los datos es la parte sencilla. El orden de las operaciones determina si el traslado será tranquilo o costoso.

Esta guía cubre un servidor Linux que ejecuta una aplicación web, una base de datos y un certificado TLS (seguridad de la capa de transporte). Esto incluye la mayoría de las configuraciones de un solo servidor. Hay dos hosts implicados, por lo que cada ejemplo indica en un comentario en qué host se ejecuta. Las direcciones pertenecen a los rangos reservados para documentación: 198.51.100.10 es el servidor antiguo y 203.0.113.20 es el nuevo.

Lea todo el procedimiento antes de empezar. El primer paso, reducir el TTL del DNS, debe hacerse varios días antes del paso que realmente le interesa.

Haz el inventario antes de construir nada

No puedes reconstruir un servidor que no has descrito. Dedica una hora a documentar qué hace el servidor antiguo, porque lo que falla después de una migración siempre es lo que nadie recordó: un trabajo de cron, una excepción del firewall o un archivo de entorno ubicado fuera del directorio de la aplicación.

Ejecuta estos comandos en el servidor antiguo y guarda la salida en un lugar que puedas consultar desde el nuevo.

# old server: packages you asked for, not the dependencies they pulled in
apt-mark showmanual > ~/inv-packages.txt

# old server: what runs now, and what starts at boot
systemctl list-units --type=service --state=running --no-pager > ~/inv-services.txt
systemctl list-unit-files --state=enabled --no-pager >> ~/inv-services.txt
systemctl list-timers --all --no-pager > ~/inv-timers.txt

# old server: what is listening, on which address and port
sudo ss -tulpn > ~/inv-ports.txt

# old server: human accounts, skipping the system ones
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd

apt-mark showmanual es la lista que conviene conservar porque incluye todo lo que llegó como dependencia. Un dpkg --get-selections completo en un servidor con cinco años de antigüedad devuelve dos mil líneas y no indica nada sobre la finalidad de los paquetes.

Las tareas programadas se encuentran en dos ubicaciones, así que comprueba ambas. Una tarea que sólo se ejecuta una vez al mes es la que descubrirás seis semanas después de la migración.

# old server: per-user crontabs, then the system drop-ins
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -lu "$u" 2>/dev/null | sed "s/^/$u: /"; done
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

Después, revisa los elementos que no son archivos normales: las reglas del firewall, los certificados, las bases de datos y la cantidad de datos que vas a mover realmente.

# old server
sudo ufw status verbose        # or: sudo nft list ruleset
sudo certbot certificates
sudo -u postgres psql -c '\l'  # or: sudo mysql -e 'SHOW DATABASES;'
sudo du -xh --max-depth=1 / | sort -h

certbot certificates muestra el nombre de cada certificado, los dominios que cubre, su fecha de caducidad y las rutas de los archivos en disco. Esa salida es tu lista de comprobación de TLS. du -x permanece en un solo sistema de archivos, por lo que no entrará en un volumen de copias de seguridad montado ni informará de un valor diez veces mayor.

Hay dos elementos que están fuera del servidor y se olvidan siempre. Primero, cualquier tercero que incluya en una lista de permitidos la dirección IP de tu servidor: una pasarela de pagos, una base de datos gestionada, un relay SMTP o una API de un socio. El servidor nuevo tiene una dirección distinta, así que debes añadir la nueva IP a esas listas antes del cambio, no después. Segundo, los registros DNS que no creaste tú mismo, como un registro MX o un registro SPF que incluya la IP antigua en su texto.

Por qué debe reconstruir en lugar de clonar el sistema de archivos raíz antiguo

Clonar todo el sistema de archivos raíz en el VPS nuevo parece más rápido, y lo es, hasta que deja de serlo. Un sistema de archivos raíz que ha estado en producción durante años contiene configuraciones editadas manualmente que nadie documentó, paquetes de un repositorio que ya no existe y una configuración de arranque creada para el hardware virtual de la plataforma antigua. Importa todo eso, incluido el motivo por el que estaba migrando.

La reconstrucción es más lenta el primer día y más económica todos los días posteriores. Instale la versión actual y aplique el endurecimiento base. Después, copie sólo los datos: el directorio de la aplicación, las configuraciones de los sitios, el volcado de la base de datos, los certificados y las cargas de los usuarios. Todo lo que no pueda explicar se queda fuera. Prepare el servidor nuevo como prepararía cualquier servidor, con los primeros diez minutos en un VPS nuevo. Después, añada los servicios del inventario de uno en uno y confirme cada uno antes de añadir el siguiente.

Cuándo es adecuado restaurar una imagen o una snapshot

Hay una excepción válida a la reconstrucción. Si el servidor antiguo no arranca o la aplicación ya no se puede reconstruir desde el código fuente, restaurar una imagen o una snapshot del proveedor es la opción más práctica. Tiene limitaciones reales: funciona dentro de un solo proveedor y, a menudo, sólo dentro de una familia de planes. El disco restaurado espera los dispositivos virtuales y los nombres de red de esa plataforma.

Una snapshot de un servidor en ejecución también presenta el mismo problema de coherencia que cualquier otra copia a nivel de archivo de una base de datos activa. Considere la restauración de una imagen como una vía de recuperación, no como un plan de migración, y lea por qué una snapshot no equivale a una copia de seguridad antes de basar un plan en ella.

Cómo se transfieren los archivos: rsync mediante SSH

Ejecute rsync desde el servidor antiguo para enviar los datos al nuevo. El envío suele ser más sencillo porque el servidor antiguo ya contiene los datos y puede leerlos todos mediante sudo.

# old server: dry run first, and read what it says it will do
sudo rsync -aHAX --dry-run --itemize-changes \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

# old server: the real bulk pass
sudo rsync -aHAX --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

Los indicadores son importantes. -a conserva los permisos, las marcas de tiempo, los enlaces simbólicos y la propiedad. -H conserva los enlaces físicos como enlaces físicos, en lugar de expandirlos en copias independientes. -A copia las ACL POSIX (listas de control de acceso) y -X copia los atributos extendidos. Sin estos dos últimos indicadores, un archivo que parece idéntico puede comportarse de forma diferente, porque las etiquetas de SELinux y las ACL se almacenan en atributos extendidos y ningún otro mecanismo las registra.

Dos detalles provocan la mayoría de los fallos.

La barra final determina dónde se escriben los datos. /srv/app/ significa el contenido de ese directorio. /srv/app significa el directorio en sí. Si se indica mal, en el servidor nuevo se obtiene /srv/app/app y la aplicación se inicia, pero después informa de que faltan archivos, porque las rutas configuradas ahora tienen un nivel de profundidad menos.

Con sudo, la tilde representa el directorio personal de root. Escribir -e 'ssh -i ~/.ssh/id_ed25519' dentro de un sudo rsync busca la clave en /root/.ssh, no en su propio directorio personal. Si la clave no está allí, SSH muestra Permission denied (publickey), rsync muestra rsync: connection unexpectedly closed y termina con un código distinto de cero. Escriba la ruta completa de la clave. Si ese mensaje de autenticación sigue apareciendo después de corregir la ruta, el fallo de publickey tiene una lista breve de causas y los permisos de los directorios del servidor nuevo son el siguiente punto que debe comprobar.

La propiedad requiere una decisión. Al ejecutarse como root, rsync asigna el propietario y el grupo por nombre de forma predeterminada. Por tanto, un archivo cuyo propietario es www-data en el servidor antiguo pasa a pertenecer a www-data en el servidor nuevo, aunque el UID numérico (ID de usuario) sea diferente. Esto es lo que se necesita en una reconstrucción. Añada --numeric-ids sólo cuando copie un sistema de archivos cuyas cuentas no existan en el destino. Después, compruebe el resultado con ls -ln, porque un archivo cuyo propietario es un UID sin una cuenta correspondiente se muestra como un número sin más, y todos los servicios que intenten leerlo recibirán un acceso denegado.

Ejecute la copia inicial varios días antes, mientras el servidor antiguo siga atendiendo tráfico. Repítala tantas veces como sea necesario: rsync sólo envía los cambios, por lo que la segunda ejecución tarda minutos en lugar de horas. La ejecución final, dentro de la ventana de cambio, añade --delete para que los archivos eliminados del servidor antiguo también desaparezcan del nuevo.

# old server: final pass, inside the window, after the app has stopped writing
sudo rsync -aHAX --delete --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

--delete elimina del destino los archivos que ya no existen en el origen. Por tanto, una ruta de origen incorrecta combinada con --delete puede vaciar el directorio de destino. Ejecútelo primero con --dry-run, todas y cada una de las veces. Las transferencias largas también pueden interrumpirse si se pierde la sesión SSH del portátil. Por eso, inícielas dentro de tmux o screen en el servidor antiguo. Añada --bwlimit=20M si la copia satura el enlace mientras el servidor antiguo sigue atendiendo a los usuarios.

Cómo se mueve la base de datos: un volcado nativo

Una base de datos no es un directorio de archivos, aunque lo parezca. Es un conjunto de archivos, estado en memoria y un registro de escritura anticipada, y sólo es coherente en los instantes que define la propia base de datos. Use su herramienta específica.

PostgreSQL necesita dos volcados porque los roles son globales al clúster y pg_dump no los incluye:

# old server
sudo -u postgres pg_dumpall --globals-only -f /var/backups/globals.sql
sudo -u postgres pg_dump -Fc -f /var/backups/appdb.dump appdb

# new server: restore in this order
sudo -u postgres psql -f /var/backups/globals.sql
sudo -u postgres createdb -O appuser appdb
sudo -u postgres pg_restore -d appdb --no-owner /var/backups/appdb.dump

Si omite globals.sql, se restaurarán todas las tablas, pero ningún rol de la aplicación podrá leerlas, porque las instrucciones GRANT hacen referencia a un usuario que no existe. -Fc escribe el formato de archivo de archivo personalizado, que sólo pg_restore puede leer y que permite restaurar tablas seleccionadas más adelante. Restaure en la misma versión principal o en una posterior. No se admite retroceder, por ejemplo, de 17 a 16, y pg_restore rechaza el archivo con un error de versión no compatible en la cabecera antes de escribir nada.

MySQL y MariaDB usan un comando, con cuatro opciones que no están activadas de forma predeterminada:

# old server
sudo mysqldump --single-transaction --routines --triggers --events \
  --databases appdb > /var/backups/appdb.sql

# new server
sudo mysql < /var/backups/appdb.sql

--single-transaction toma una instantánea coherente sin bloquear las escrituras, pero sólo para tablas InnoDB. Una tabla MyISAM de la misma base de datos se copia sin esa garantía, así que compruebe los motores de almacenamiento antes de confiar en el volcado. --routines, --triggers y --events están desactivadas de forma predeterminada, por lo que un volcado normal restaura los datos y deja atrás silenciosamente los procedimientos almacenados y los eventos programados. Los usuarios de la base de datos y sus privilegios se encuentran en la base de datos del sistema mysql, que un volcado de --databases appdb nunca incluye, así que recréelos en el servidor nuevo con CREATE USER y GRANT. MariaDB 11 distribuye la misma herramienta con el nombre mariadb-dump y mantiene mysqldump como enlace simbólico, por lo que ambos nombres funcionan desde agosto de 2026.

SQLite es un solo archivo y copiarlo mientras la aplicación escribe produce un archivo inconsistente. Tiene un método seguro específico:

# old server
sqlite3 /var/lib/app/app.db ".backup '/var/backups/app.db'"

Independientemente del motor, compruebe el volcado antes de confiar en él. Un volcado que terminó antes de tiempo porque el disco se quedó sin espacio se restaurará sin mostrar errores, hasta llegar exactamente al punto en el que quedó truncado.

# old server: a complete mysqldump ends with a line reading "-- Dump completed on ..."
tail -n 3 /var/backups/appdb.sql

# new server: after restore, count rows in a table whose size you know
sudo mysql -e 'SELECT COUNT(*) FROM appdb.orders;'

Por qué no puede usar rsync con una base de datos en ejecución

rsync copia los archivos uno por uno. Una base de datos en ejecución escribe en varios archivos al mismo tiempo, por lo que, cuando rsync llega al último archivo, el primero ya está desactualizado. La copia contiene páginas de distintos momentos, un estado que la base de datos nunca tuvo. El resultado puede ser un servidor que se niega a iniciar o, en el peor de los casos, uno que inicia, responde correctamente durante una semana y después falla cuando una consulta finalmente llega a la página dañada. No aparece ningún aviso intermedio.

Hay dos formas seguras de mover los propios archivos. Detenga la base de datos, copie los archivos y vuelva a iniciarla: es correcto y sencillo, pero el tiempo de inactividad será igual a la duración de la copia. La otra opción es usar la herramienta diseñada para realizar una copia física de un servidor en ejecución. En PostgreSQL, esa herramienta es pg_basebackup, que coordina la operación con el servidor para que la copia sea coherente:

# new server: pull a physical copy from the old one
pg_basebackup -h 198.51.100.10 -U replicator -D /var/lib/postgresql/16/main -X stream -P

Necesita un rol con el atributo REPLICATION y una entrada pg_hba.conf correspondiente en el servidor antiguo, por lo que requiere más configuración que un volcado. Merece la pena cuando la base de datos es lo bastante grande como para que un volcado y una restauración no quepan en la ventana disponible. Para una migración normal de un único servidor, es preferible usar el volcado.

Reconstruya los certificados antes del cambio, no después

Un certificado TLS está vinculado al nombre de dominio, no a la dirección IP, por lo que el archivo del certificado se puede trasladar sin problemas. Lo que no se traslada correctamente es la renovación. El desafío HTTP-01 predeterminado de Certbot pide a la autoridad certificadora que descargue un archivo mediante el puerto 80 en el nombre que se está certificando. Hasta que el DNS apunte al servidor nuevo, esa descarga llega al servidor antiguo y la renovación del servidor nuevo falla.

La primera opción es copiar los certificados existentes y su estado de renovación. Siguen siendo válidos hasta la fecha de caducidad, independientemente del servidor que los tenga.

# old server
sudo rsync -aHAX -e 'ssh -i /root/.ssh/id_ed25519' \
  /etc/letsencrypt/ root@203.0.113.20:/etc/letsencrypt/

Cada archivo de /etc/letsencrypt/renewal/ indica el plugin de autenticación que emitió el certificado. Instale el mismo plugin en el servidor nuevo (python3-certbot-nginx, por ejemplo), o la primera renovación fallará con un mensaje sobre un autenticador desconocido. Compruebe que la renovación funciona antes de depender de ella:

# new server, after DNS has moved
sudo certbot renew --dry-run

La segunda opción es emitir un certificado nuevo en el servidor nuevo mediante el desafío DNS-01. Este demuestra el control mediante un registro TXT y nunca accede al puerto 80. Funciona antes de la migración, mientras el nombre todavía resuelve al servidor antiguo. Por eso es la opción más sencilla si puede automatizar el proveedor DNS. Emisión de certificados con el desafío DNS-01 describe la configuración del plugin y de las credenciales.

En ambos casos, compruebe qué presenta realmente el servidor nuevo sin cambiar el DNS:

# your laptop
echo | openssl s_client -connect 203.0.113.20:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

-servername envía SNI (indicación del nombre del servidor), que permite al servidor web seleccionar el host virtual correcto. Si lo omite, obtendrá el certificado predeterminado de esa IP y una discrepancia que parece un problema real, pero no lo es.

Reduce los días de TTL de DNS antes del cambio

DNS es un punto donde incluso una migración cuidadosa puede fallar, porque la demora forma parte del funcionamiento y no se puede acortar el mismo día. Un resolver que haya almacenado en caché su registro A seguirá sirviéndolo durante el tiempo de vida (TTL, time to live) que recibió. Reducir el TTL ahora no cambia nada para un resolver que almacenó el registro hace diez minutos con el valor anterior: mantiene el valor antiguo durante el resto del TTL anterior y sólo después aprende el nuevo valor, más corto. Por tanto, reduzca el TTL al menos un periodo completo del TTL anterior antes del cambio. Hacerlo con un día de antelación es la opción más cómoda. Si estos componentes son nuevos para usted, la explicación detallada de registros, resolvers y almacenamiento en caché proporciona el contexto.

Las cifras siguientes son cálculos basados en el propio TTL, no mediciones.

[
  {
    "label": "TTL 3600 s (common default)",
    "ttl_seconds": 3600,
    "worst_case_stale_minutes": 60
  },
  {
    "label": "TTL 900 s",
    "ttl_seconds": 900,
    "worst_case_stale_minutes": 15
  },
  {
    "label": "TTL 300 s (lowered for cutover)",
    "ttl_seconds": 300,
    "worst_case_stale_minutes": 5
  },
  {
    "label": "TTL 60 s (short window)",
    "ttl_seconds": 60,
    "worst_case_stale_minutes": 1
  }
]

Un registro A publicado con un TTL de 3600 segundos puede seguir dirigiendo a los usuarios a la IP antigua durante 60 minutos después de cambiarlo. Redúzcalo a 300 segundos y ese peor caso bajará a 5 minutos. Considere estas cifras como un mínimo, no como una garantía. Algunos resolvers aplican su propio TTL mínimo e ignoran cualquier valor inferior. Además, algunos runtimes de aplicaciones almacenan en caché una dirección resuelta durante toda la vida del proceso. Por eso, un cliente que se inició antes del cambio puede no volver a consultar hasta que se reinicie.

Consulte la respuesta autoritativa, no su propia caché, para comprobar que el TTL reducido está activo:

# your laptop: ask the zone's own nameserver, so no cache is involved
dig +short NS example.com
dig +noall +answer @$(dig +short NS example.com | head -n1) example.com A

El segundo campo de esa línea de respuesta es el TTL en segundos. Después, revise los registros que suelen olvidarse: el registro AAAA si el servidor antiguo tenía IPv6, el nombre www cuando es un registro A independiente en lugar de un CNAME, cualquier registro MX que apunte al propio servidor, un registro SPF que incluya la IP antigua y el registro DNS inverso (PTR) de la dirección nueva. Configure el PTR desde el panel de control de su proveedor antes del cambio si el servidor envía correo, porque los servidores de correo receptores lo comprueban y la ausencia de un PTR se convierte en correo rechazado varias horas después de que todo lo demás pareciera funcionar correctamente.

Verifique el servidor nuevo mediante su IP antes de cambiar el DNS

Puede probar toda la aplicación en el servidor nuevo mientras el DNS todavía apunta al antiguo. Anule la resolución del nombre para una sola petición:

# your laptop: force one name to the new IP, for this request only
curl -sS --resolve example.com:443:203.0.113.20 \
  -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/

--resolve sólo cambia el destino de la conexión. El certificado TLS se sigue comprobando con el nombre real, por lo que esto valida tanto el certificado como el servicio. %{ssl_verify_result} muestra 0 cuando la cadena se ha validado correctamente.

Para recorrer el sitio en un navegador, anule la resolución del nombre para todo el equipo añadiendo una línea a /etc/hosts en el portátil, o a C:\Windows\System32\drivers\etc\hosts en Windows:

203.0.113.20 example.com www.example.com

A continuación, use la aplicación como lo haría un usuario. Inicie sesión. Cargue una página que lea datos de la base de datos. Envíe un formulario que escriba datos en ella. Suba un archivo y confirme que se guarda en el disco. Ejecute cualquier función que envíe correo electrónico y compruebe que llega, porque el SMTP saliente desde una IP nueva suele causar sorpresas. Elimine la línea de hosts en cuanto termine. Si la deja, puede pasar una hora depurando un sitio que todos los demás ven correctamente.

El cambio, paso a paso

1. Días antes: reduzca el TTL, ejecute el rsync masivo, prepare el servidor nuevo y pruébelo mediante una sobrescritura de hosts.
2. El día del cambio, antes de la ventana: añada la nueva IP a todas las listas de permitidos de terceros y confirme que el trabajo de backup del servidor nuevo esté configurado y apunte a su repositorio.
3. Abra la ventana: active el modo de mantenimiento de la aplicación en el servidor antiguo para que deje de aceptar escrituras.
4. Cree el volcado final de la base de datos y ejecute después la pasada final de rsync con --delete.
5. Restaure el volcado en el servidor nuevo e inicie los servicios.
6. Vuelva a probar mediante --resolve y la sobrescritura de hosts, incluida una escritura real.
7. Cambie los registros A y AAAA para que apunten a la nueva IP.
8. Supervise ambos servidores. El registro de acceso del servidor antiguo muestra quién sigue llegando allí, y la cifra debería acercarse a cero durante el TTL.
9. Desactive la página de mantenimiento.
10. Deje el servidor antiguo en ejecución y sin modificar durante al menos una semana.

El paso del modo de mantenimiento es el que más se omite, y es el que le protege. Una vez que la nueva base de datos ha aceptado una escritura, revertir el cambio implica perder esa escritura o volcar la nueva base de datos y cargarla de nuevo en la antigua. Una ventana de solo lectura de unos minutos tiene un coste bajo. Dos bases de datos que han aceptado escrituras generan días de conciliación manual.

El plan de reversión

La reversión consiste en una sola acción: volver a cambiar los registros DNS a 198.51.100.10. Sólo funciona porque antes hizo cuatro cosas.

• El servidor antiguo sigue funcionando, con sus servicios activos y los datos intactos. Detuvo las escrituras allí, pero no lo retiró de servicio.
• El TTL sigue siendo bajo, por lo que la vuelta atrás es tan rápida como lo fue el cambio inicial.
• Añadió la nueva IP a las listas de permitidos de terceros en lugar de sustituir la anterior. Si elimina la dirección antigua, la reversión falla en la pasarela de pagos.
• El servidor nuevo no ha recibido escrituras que no pueda identificar, porque hasta ahora las únicas escrituras fueron sus propias transacciones de prueba.

Antes de abrir la ventana de mantenimiento, determine qué desencadenará una reversión. Bastan dos condiciones: cualquier error que no pueda diagnosticar dentro de un número fijo de minutos y cualquier pérdida de datos. Dejarlas por escrito de antemano evita la hora de conjeturas que convierte una interrupción de diez minutos en una interrupción prolongada.

Comprobar que la migración funciona

Una migración no termina cuando el sitio carga. Compruebe los elementos que sólo fallan más tarde.

# new server
systemctl --failed
journalctl -p err -b --no-pager | tail -n 40
sudo certbot certificates
sudo systemctl list-timers --all --no-pager

systemctl --failed reporting 0 loaded units listed es el resultado que necesita. certbot certificates debe mostrar las fechas de vencimiento esperadas, y list-timers debe mostrar todos los trabajos programados de su inventario con una hora real de la próxima ejecución, no un valor vacío.

Después, reinicie una vez el servidor nuevo de forma intencionada mientras lo supervisa. Un servicio que alguien inició manualmente y nunca habilitó funciona perfectamente hasta el primer reinicio no planificado a las tres de la mañana.

# new server
sudo reboot

# your laptop, once it comes back
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Si la aplicación se ejecuta en contenedores, el mismo problema tiene otra forma, porque una pila de compose necesita una política de reinicio explícita para volver a iniciarse después de un reinicio.

La última comprobación es la más fácil de posponer y la más importante: el trabajo de backup. Una migración que termina con un servidor sin backup cambia un riesgo por otro. Ejecute manualmente el backup en el servidor nuevo y, después, restaure un solo archivo desde él en un directorio temporal. Un repositorio de restic cuya restauración haya probado realmente es lo que necesita cuando llegue el momento. Si mantiene los servidores antiguo y nuevo en paralelo durante una semana, una forma coherente de acceder a cada host y configurarlo evita que se desvíen mientras ambos están activos.

Después del cambio: el servidor antiguo y las últimas tareas

Conserve el servidor antiguo durante una o dos semanas. Tendrá el coste de un mes de un plan que estaba a punto de cancelar, pero es la única opción de reversión disponible. Después, complete las tareas restantes.

• Reutilizar el mismo nombre de host en su ~/.ssh/config para el nuevo equipo genera WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! en la primera conexión, porque ese nombre ahora responde con una clave de host diferente. Elimine la entrada obsoleta con ssh-keygen -R example.com cuando haya confirmado el motivo del cambio. No lo haga de forma automática, porque la misma advertencia también indica cómo se presenta un ataque de interceptación. Una migración también es un buen momento para revisar qué claves pueden acceder a cada recurso. Para eso sirve gestión de claves SSH en una flota pequeña.
• Cree una última instantánea o copia de seguridad del servidor antiguo y almacénela en una ubicación que no pertenezca al proveedor antiguo.
• Elimine la IP antigua de las comprobaciones de monitorización, de los registros SPF y de las listas de permitidos de terceros, en ese orden y como última tarea.
• Cancele el plan antiguo sólo después de confirmar que la copia final se puede leer desde otra ubicación.

FAQ

¿Cuánto tiempo se tarda en migrar un servidor a un VPS nuevo?

La interrupción visible para el usuario suele limitarse al volcado final de la base de datos, la pasada final de rsync y el arranque del servicio. Para una aplicación pequeña, suele durar entre diez y treinta minutos. El tiempo total de preparación es mayor, porque debe reducir el TTL de DNS al menos un periodo completo del TTL anterior antes del cambio. Hacerlo con un día de antelación es más seguro. Planifique también con varios días de antelación la copia masiva de datos. Esta copia se ejecuta con el servidor activo. Si la repite más adelante, sólo transferirá los cambios realizados desde la pasada anterior.

¿Puedo usar rsync con una base de datos MySQL o PostgreSQL en ejecución en lugar de crear un volcado?

No. rsync copia archivo por archivo mientras la base de datos escribe en varios archivos a la vez. Por tanto, la copia contiene páginas de momentos distintos y representa un estado que la base de datos nunca tuvo. Es posible que no arranque, o que arranque y falle más adelante cuando una consulta acceda a una página dañada. Use pg_dump con pg_dumpall --globals-only, o mysqldump --single-transaction, o detenga primero la base de datos y copie después los archivos. Para un clúster grande de PostgreSQL, pg_basebackup crea una copia física coherente de un servidor en ejecución.

¿Cómo pruebo el VPS nuevo antes de cambiar el DNS?

Sobrescriba la resolución del nombre en su propio equipo. Para una sola petición, curl --resolve example.com:443:203.0.113.20 https://example.com/ dirige la conexión a la nueva IP y sigue comprobando el certificado contra el nombre real. Para probarlo con el navegador, añada 203.0.113.20 example.com a /etc/hosts en su portátil. Después, pruebe el inicio de sesión, una lectura de la base de datos, el envío de un formulario y la carga de un archivo. A continuación, elimine la línea. Para inspeccionar sólo el certificado, ejecute openssl s_client -connect 203.0.113.20:443 -servername example.com.

¿Qué TTL debo configurar y cuándo debo reducirlo?

Reduzca los registros A y AAAA a 300 segundos. Hágalo al menos un periodo completo del TTL anterior antes del cambio. Un resolvedor que almacenó el registro antes del cambio conserva el valor anterior durante el tiempo restante del TTL anterior. Por eso, reducirlo una hora antes no sirve de nada si el TTL anterior era 86400. Restablezca después su valor habitual unos días después de la migración, cuando el registro de acceso del servidor anterior haya dejado de recibir peticiones.

¿Debo copiar el certificado TLS o emitir uno nuevo en el servidor nuevo?

Cualquiera de las dos opciones funciona. Copiar /etc/letsencrypt/ mantiene la validez del certificado hasta su fecha de caducidad actual. Sin embargo, debe instalar el mismo plugin autenticador de certbot en el servidor nuevo. De lo contrario, la primera renovación fallará. Ejecute certbot renew --dry-run después del cambio de DNS para confirmarlo. Emitir un certificado nuevo es más limpio cuando puede usar el desafío DNS-01, porque demuestra el control mediante un registro TXT y funciona antes de que el DNS apunte al servidor nuevo. El desafío HTTP-01 no puede usarse en el servidor nuevo hasta que se haya cambiado el DNS, porque la petición de validación llegaría al servidor anterior.