Migra un VPS a otro host sin caídas

Los tres relojes, y por qué la “caída cero” es el objetivo equivocado#

Lo que el host antiguo se queda después de que te vayas#

El reloj del TTL empieza a correr una semana antes de la mudanza#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

Dimensionar la máquina nueva, y qué comprobar antes de comprometerte con ella#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

Paso a paso#

1. Baja cada TTL, días antes de que planees mudarte

   Este va primero porque es el único paso con un período de espera obligatorio. Todo lo demás se puede hacer en una tarde; este no se puede acelerar, y saltárselo es lo que convierte un corte de cinco minutos en uno de dos días.

   Entra donde viva tu zona y pon el TTL a 300 en cada registro que vaya a cambiar: el A del ápice, el AAAA, www, mail, y cualquier otro que apunte a un literal de IP. Luego confírmalo desde fuera, porque los paneles de control y la realidad a veces no coinciden:

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   El número antes de IN es el TTL restante. Consulta otra vez un minuto después: debería estar contando hacia atrás desde 300, no desde algo mayor. Si todavía cuenta hacia atrás desde 3600, el valor antiguo está en caché y toca esperar — que es exactamente por qué esto pasa el día menos siete y no la mañana de la mudanza.

   Deja el TTL en 300 durante toda la migración y durante una semana después, para que tu reversión también sea rápida. Vuelve a ponerlo en algo razonable — 3600 está bien — en cuanto la máquina antigua haya desaparecido.

2. Haz inventario del servidor antiguo antes de copiar nada

   No estás migrando un disco, estás migrando un sistema en marcha, y las partes que la gente olvida nunca están en /var/www. Son la tarea cron que corre el día cuatro del mes, la regla de cortafuegos añadida durante un incidente, el paquete instalado desde un repositorio de terceros hace dos años. Captura el estado de la máquina como texto, y copia ese texto junto con todo lo demás:

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   Ahora lee listening.txt línea a línea y da cuenta de cada puerto. Ese archivo es la respuesta definitiva a “qué hace esta máquina en realidad”, y suele ser una sorpresa — un exportador de métricas, una copia de staging olvidada, una base de datos escuchando en una interfaz pública que nunca debió estarlo.

   Escribe tu lista de exclusión al mismo tiempo, para que la primera sincronización no se pase una hora con datos que no quieres:

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   Fíjate en que los directorios de las bases de datos están excluidos a propósito. Tienen su propio paso, y copiarlos aquí es el error que el paso seis existe para evitar.

3. Despliega el servidor nuevo y endurécelo antes de que aloje nada

   Pide la máquina, elige la ubicación y usa la misma versión mayor del sistema operativo que la antigua si puedes. Migrar de host y cambiar de Debian 12 a Debian 13 en la misma operación significa que, cuando algo se rompa, no sabrás qué cambio lo causó. Muévete primero, actualiza después.

   Antes de que aterrice en ella nada sensible, dale a la máquina la pasada de endurecimiento de diez minutos: SSH solo con clave, inicio de sesión de root desactivado, un cortafuegos que deniega por defecto, actualizaciones de seguridad desatendidas. Ahora mismo cuesta diez minutos, y es genuinamente tedioso aplicarlo después alrededor de un servicio ya en marcha.

   Luego crea una clave que exista solo para esta migración, en el servidor antiguo, para que revocar el acceso de migración después nunca signifique tocar tu propio inicio de sesión:

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   Pon esa clave pública en /root/.ssh/authorized_keys en el servidor nuevo, y luego confirma el sentido del viaje — de la antigua empuja hacia la nueva, así que la credencial vive en la máquina que estás dejando y muere con ella:

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   Por último, pon la IP nueva en el /etc/hosts del servidor antiguo, bajo un nombre como newbox. Cada comando que venga después se vuelve más corto y, más útil todavía, más difícil de apuntar a la máquina equivocada a la una de la madrugada.

4. Comprueba la IP nueva antes de confiarle nada

   Ahora tienes una dirección que nadie ha usado antes para tu servicio, y este es el último momento en el que encontrarle un problema sale gratis. Tres comprobaciones, cinco minutos:

   Listas negras. Pasa la dirección por las comprobaciones multi-RBL — aquí está el procedimiento completo y cómo leer los resultados. Un acierto en una lista de políticas como la PBL de Spamhaus es normal para una IP de centro de datos y significa poco para el tráfico web. Un acierto en la SBL o la XBL es real, y el momento de plantearlo es ahora, no después de que tus usuarios ya estén en ella.

   DNS inverso. Comprueba con qué responde la dirección hoy:

   dig +short -x NEW_IP

   Si la máquina va a enviar correo, solicita el registro PTR que quieras y asegúrate de que coincide con un nombre de host cuyo registro A apunte de vuelta a la misma IP. Lo directo y lo inverso deben coincidir; un desajuste es peor que un nombre genérico.

   Alcanzabilidad y ruta. Confirma que los puertos que necesitas están realmente abiertos de extremo a extremo, desde fuera, en lugar de asumir que tu cortafuegos es lo único que hay en el camino:

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   La salida de mtr es la que merece la pena guardar. La pérdida en el último salto importa; la pérdida en un salto intermedio suele ser un router despriorizando el ICMP y no significa nada. Si la latencia desde la zona del mundo de tus usuarios es notablemente peor que la del host antiguo, mejor averiguarlo ahora, mientras cambiar de opinión solo cuesta un pedido y ningún dato.

5. Copia el sistema de archivos con rsync — simúlalo antes de ejecutarlo

   Ahora la transferencia masiva. Hazlo en dos pasadas: una primera copia completa con días de antelación, tardando lo que tenga que tardar, y luego pasadas delta cortas más adelante que solo mueven lo que haya cambiado. Simula siempre la ejecución antes — la salida es una lista exacta de lo que está a punto de suceder, y leerla una vez ha salvado más migraciones que cualquier otro hábito de esta guía.

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   Luego el mismo comando sin --dry-run. Repítelo para cada directorio que importe: /etc de forma selectiva y no entero, /home, /srv, /opt, y dondequiera que tu aplicación guarde de verdad sus archivos subidos.

   Los flags se ganan su sitio. -a preserva permisos, propietario, marcas de tiempo y enlaces simbólicos; -H conserva los enlaces duros; -A y -X llevan las ACL y los atributos extendidos, que es lo que necesita tu directorio de subidas si alguna vez se los pusieron; -x evita que rsync se adentre en otros sistemas de archivos montados. --numeric-ids es el que la gente se deja fuera y luego lamenta: sin él, rsync asigna la propiedad por nombre, y si www-data tiene un UID distinto en las dos máquinas, cada archivo llega con el propietario equivocado, de una forma tediosa de desenredar.

   Dos advertencias. Copiar /etc entero sobre un sistema en marcha sobrescribirá la configuración de red de la máquina nueva, su fstab y sus claves de host SSH — copia la configuración concreta que necesites, no el directorio. Y reserva --delete solo para la pasada final: es correcto para que la máquina nueva coincida exactamente con la antigua, y destructivo si ya has creado algo en el destino.

   Cuando termine la primera pasada completa, compara los dos lados para saber que hizo lo que crees:

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. Mueve la base de datos con un volcado, nunca con una copia de archivos

   Este es el paso que decide si tu migración es aburrida o memorable. El directorio de datos de una base de datos solo es consistente cuando el servidor está detenido. Cópialo en caliente y obtienes un conjunto de archivos que parecen correctos, se transfieren bien, y restauran en una base de datos sutil y permanentemente corrupta — a menudo sin ningún error hasta semanas después.

   Vuélcala como es debido. Para MySQL o MariaDB, --single-transaction es lo que te da una instantánea consistente sin bloquearlo todo:

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   Para PostgreSQL, el formato personalizado merece la pena — comprime, y te permite restaurar de forma selectiva si lo necesitas:

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   Envíalo y restaura:

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   Luego verifica, porque “la restauración ha terminado” y “los datos están ahí” son afirmaciones distintas. Compara el recuento de filas en las tablas que importan, en los dos lados:

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   Dos cosas que se esconden en los volcados: el juego de caracteres y el collation, que es de donde vienen los caracteres acentuados corruptos — si la base de datos antigua está en utf8 en lugar de utf8mb4, decide deliberadamente si la mudanza es también el momento de arreglar eso; y los usuarios y permisos de la base de datos, que mysqldump --databases no incluye. Recrea explícitamente el usuario y la contraseña de la aplicación en la máquina nueva, y luego recuerda que la cadena de conexión de tu configuración tiene que coincidir.

   Si tu aplicación usa SQLite, el archivo es la base de datos y se aplica la misma regla — no lo copies en caliente. Usa sqlite3 app.db ".backup /root/mig/app.db", que hace una copia consistente de forma segura.

7. Levanta la pila y ensáyala mediante una anulación con el archivo hosts

   El servidor nuevo ya tiene los archivos y los datos. Arranca todo y pruébalo bajo su nombre de host real — mientras el resto del mundo sigue usando tranquilamente la máquina antigua. Este es el truco más valioso de todo el procedimiento y cuesta una sola línea.

   En tu propio portátil, añade la IP del servidor nuevo a /etc/hosts (o a C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10   example.com www.example.com

   Tu navegador ahora resuelve el dominio real hacia el servidor nuevo, y el de nadie más lo hace. Cada URL es correcta, cada dominio de cookie coincide, cada ruta de redirección y de callback se comporta como lo hará después del corte — que es precisamente lo que no detecta probar contra un subdominio temporal new.example.com, porque la mitad de lo que se rompe en una migración depende del nombre de host.

   Para una comprobación rápida y puntual sin editar nada, curl puede hacer lo mismo al vuelo:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   Recorre la aplicación entera, no solo la portada: inicia sesión, envía un formulario, sube un archivo, dispara un correo de restablecimiento de contraseña, carga una página de administración, golpea el endpoint que llama un procesador de pagos. Luego lee los registros de error aunque todo parezca correcto — extensiones de PHP que faltan, un modo de archivo incorrecto en un directorio de caché y un usuario de base de datos que todavía no existe, todo eso aparece ahí antes de aparecer en pantalla.

   Recuerda quitar después esa línea del archivo hosts. Todo el mundo se olvida una vez, y luego se pasa veinte minutos preguntándose por qué la reversión parece no haber funcionado.

8. Consigue que el TLS funcione en la máquina nueva antes de cambiar nada

   Los certificados están ligados a nombres, no a direcciones IP, así que nada de una migración invalida un certificado que ya tengas. Lo que se rompe es la emisión: el desafío HTTP-01 habitual le pide a Let's Encrypt que descargue un archivo por el puerto 80 en el nombre que se está certificando, y ese nombre todavía apunta al servidor antiguo. El dilema del huevo y la gallina es toda la dificultad, y hay tres salidas limpias.

   Copia los certificados existentes. La más simple y normalmente la correcta. La clave privada y la cadena se mueven como cualquier otro archivo:

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   El servidor nuevo puede servir TLS válido de inmediato, y la renovación empieza a funcionar por sí sola en cuanto el DNS apunte a él. Confirma que el temporizador está activado ahí: systemctl list-timers | grep certbot.

   Usa un desafío DNS-01. Demuestra el control del dominio mediante un registro TXT en lugar de una petición HTTP, así que funciona desde un servidor al que todavía nada apunta. Ideal si quieres un certificado genuinamente independiente en la máquina nueva antes del corte, y la única opción para un comodín.

   Emítelo después del cambio. Válido, pero deja un hueco en el que el sitio está en marcha en la IP nueva sin certificado, lo que para cualquier cosa con HSTS no es una advertencia que tus visitantes puedan sortear con un clic. Solo tiene sentido para un dominio totalmente nuevo que nadie ha visitado.

   Elijas lo que elijas, verifícalo contra la IP nueva directamente antes del corte, usando el mismo truco de --resolve:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   Comprueba las fechas y que el subject cubre cada nombre que sirves, www incluido. Y si usas HSTS con un max-age largo, trata el certificado como lo único que tiene que estar bien antes del cambio y no después — esa cabecera es una promesa que ya le hiciste a cada visitante recurrente.

9. El corte: congela las escrituras, delta final, cambia el registro

   Diez minutos de trabajo real, y la única parte con un reloj corriendo. Hazlo por la mañana, en tu propia zona horaria, un día en el que no estés ocupado por otro lado. Nunca en viernes.

   Congela. Pon la aplicación antigua en modo de mantenimiento o de solo lectura. Detén los workers, los consumidores de colas y las tareas cron — cualquier cosa que escriba sin un navegador de por medio. A partir de aquí, no se escribe nada nuevo en la máquina antigua, que es lo que hace seguro todo lo que viene después:

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   Delta final. Un rsync más, ahora con --delete para que el destino coincida exactamente, y un volcado más. Con la primera pasada hecha días antes, esto mueve muy poco y tarda segundos:

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   Comprueba. El recuento de filas en los dos lados, un repaso más de la aplicación mediante la anulación con el archivo hosts, y quita el flag de mantenimiento en la máquina nueva.

   Cambia. Cambia el registro A a la IP nueva. Cambia también el registro AAAA — esta es la forma más habitual en que un corte se queda a medias. Confírmalo desde un resolutor que no controles:

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   Luego vigila las dos máquinas. El tráfico debería aparecer en la nueva en uno o dos minutos, y desvanecerse de la antigua en los cinco siguientes:

   tail -f /var/log/nginx/access.log        # on both, side by side

   Deja la aplicación antigua en modo de mantenimiento en lugar de apagarla. Un rezagado que llegue hasta ahí verá una página educada en lugar de un error de conexión, y mantienes la máquina disponible para la reversión que probablemente no vayas a necesitar.

10. Vigila una semana y luego retira el servidor correctamente

    La migración no termina cuando el DNS resuelve. Termina cuando ha pasado un ciclo completo de facturación y de cron sin ninguna sorpresa.

    Durante las primeras horas, vigila las tasas de error en lugar del uptime — un servidor puede estar perfectamente arriba y devolviendo 500 a un tercio de las solicitudes:

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    Luego repasa una lista corta, porque esto es lo que de verdad se rompe después de una mudanza y nada de ello se anuncia solo: tareas cron y temporizadores de systemd corriendo en la máquina nueva (systemctl list-timers contra el inventario que hiciste en el paso dos); correo saliente que llega y no cae en spam; copias de seguridad programadas apuntando a la máquina nueva en lugar de seguir archivando la antigua; cualquier tercero con tu dirección IP en una lista de permitidos — un procesador de pagos, una API, el cortafuegos de un socio; y la tarea mensual que solo se demuestra a sí misma el día uno del mes.

    Deja el servidor antiguo en marcha, en modo de mantenimiento, sin tocar, durante al menos una semana. Es tu reversión y tu copia de referencia, y vale más que los pocos dólares que cuesta. Luego ciérralo en orden: rota cada secreto que pudiera haber leído, haz un último archivo cifrado hacia una tercera ubicación, sobrescribe los directorios de la aplicación y de la base de datos, ejecuta la rutina de destrucción o reinstalación del proveedor, y solo entonces cancela — después de comprobar la fecha de renovación, porque un mes extra de seguro de reversión suele ser el mejor cambio.

    Por último, vuelve a subir el TTL a 3600 ahora que ya no necesitas reversibilidad de cinco minutos, y actualiza la documentación que conserves con la dirección nueva. El tú del futuro, en alguna madrugada posterior, te lo agradecerá muchísimo cuando el runbook coincida con el servidor.

El correo no migra con el resto#

Revertir sin empeorar las cosas#

Dar de baja: rota, borra, verifica y luego cancela#

Un calendario que funciona#

Preguntas frecuentes#