Cómo migrar VPS de otro proveedor a Hostini sin downtime
Guía técnica para migrar VPS de Vultr, DigitalOcean o Contabo a Hostini con rsync, TTL de DNS bajo y cutover sin ventana de indisponibilidad.
Migrar una VPS entre proveedores parece arriesgado cuando tienes una aplicación en producción, pero la operación es determinista cuando sigue un runbook. El riesgo real no está en los comandos — está en saltar validaciones o subestimar el TTL del DNS. Este tutorial cubre el proceso completo para mover tu VPS de Vultr, DigitalOcean, Contabo o similares a Hostini, con ventana de downtime medida en segundos.
El enfoque usa rsync incremental para sincronizar archivos mientras la aplicación antigua sigue sirviendo tráfico, reduce el TTL del DNS para acelerar la propagación en el cutover, y valida todo vía /etc/hosts local antes de hacer pública la modificación. Persona objetivo: tienes una VPS corriendo Linux (Ubuntu/Debian/Rocky) con aplicación web, base de datos, y tal vez un stack tipo Nginx + PHP-FPM, Node.js o Docker.
Tiempo estimado: 2-4 horas, con 30-45 minutos de ejecución activa y el resto esperando rsync y propagación de DNS. La ventana de indisponibilidad percibida por el usuario final queda típicamente por debajo de 2 minutos.
Prerrequisitos
Acceso SSH con sudo en la VPS de origen (proveedor actual) y en la VPS Hostini de destino. Panel de control de tu DNS (Cloudflare, Registro.br, etc) para ajustar TTL y registros A. Lista de lo que está corriendo: servicios systemd, puertos abiertos, paths de datos (web root, base de datos, configs).
Antes de tocar cualquier servidor, documenta el estado actual. Ejecuta systemctl list-units --type=service --state=running en el origen y guárdalo. Anota versiones: nginx -v, php -v, mysql --version, node -v. Lista los cron jobs con crontab -l y ls /etc/cron.d/. Ese inventario es lo que vas a replicar.
60s 24h antes 30s-2min rsync incremental Provisiona la VPS de destino en Hostini
La VPS nueva debe replicar el sistema operativo del origen en la misma versión mayor. Si el origen corre Ubuntu 22.04, elige Ubuntu 22.04 — saltar versión de SO en medio de la migración añade variables de incompatibilidad (libs, paths de config) que no necesitas cargar.
En el panel de Hostini, contrata la VPS con specs iguales o superiores al origen. Misma familia de SO (Ubuntu/Debian/Rocky) y misma versión LTS. Anota la IP pública nueva.
ssh root@IP_NUEVA_HOSTINIConfirma conectividad y cambia a un usuario no-root para el trabajo posterior.
Instala en la nueva VPS exactamente los mismos paquetes del origen. En Ubuntu/Debian, usa la lista que documentaste:
sudo apt update
sudo apt install -y nginx mysql-server php8.3-fpm php8.3-cli redis-serverPara Rocky/AlmaLinux, ajusta a dnf install. Garantiza versión exacta de PHP, Node, o cualquier runtime crítico — una diferencia de minor version puede romper dependencias de la aplicación.
Configura el firewall con los mismos puertos del origen. Si usas UFW:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableNo olvides puertos custom (ej: 8080 para una app, 6379 para Redis expuesto). Comparar con ss -tlnp en el origen es la fuente de verdad.
Reduce el TTL del DNS
Este paso debe hacerse 24 horas antes del cutover. El TTL actual de tu registro A determina cuánto tiempo los resolvers de DNS por el mundo van a cachear la IP antigua después de que apuntes a la IP nueva. TTL por defecto de 3600s (1 hora) o 86400s (1 día) significa downtime medido en horas para parte de los visitantes.
En tu proveedor de DNS (Cloudflare, Registro.br, Route53, etc), edita los registros A y AAAA del dominio. Cambia el TTL a 60 segundos.
Si usas Cloudflare con proxy naranja activo, el TTL es controlado por Cloudflare (no por tu valor) — pero aun así ajusta a “Auto” y deshabilita el proxy temporalmente en el día del cutover para ver propagación real.
Reducir TTL no tiene efecto inmediato — los resolvers solo van a tomar el valor nuevo después de que expire el TTL antiguo. Si el registro tenía TTL 3600s, espera al menos 1 hora. Para TTL antiguo de 86400s, espera 24h para garantizar.
Sincroniza datos con rsync
rsync con aplicación corriendo es seguro para archivos estáticos (web root, uploads, configs), pero exige cuidado con bases de datos — sincroniza archivos de base de datos con mysqldump/pg_dump, no con copia directa de los archivos de tabla.
Desde la VPS de origen, transfiere el web root y configs de nginx a Hostini:
rsync -avz --progress \
/var/www/ \
root@IP_NUEVA_HOSTINI:/var/www/
rsync -avz --progress \
/etc/nginx/ \
root@IP_NUEVA_HOSTINI:/etc/nginx/La flag -a preserva permisos, owners y timestamps. -v muestra progreso. -z comprime durante la transferencia — útil para archivos texto, neutro para binarios ya comprimidos.
Para base de datos MySQL/MariaDB, usa dump + restore (nunca copies /var/lib/mysql directamente entre servidores diferentes):
mysqldump --single-transaction --routines --triggers \
--all-databases > /tmp/backup.sql
rsync -avz /tmp/backup.sql root@IP_NUEVA_HOSTINI:/tmp/En la VPS nueva:
ssh root@IP_NUEVA_HOSTINI
mysql < /tmp/backup.sqlLa flag --single-transaction evita lock de tablas durante el dump en engines transaccionales (InnoDB), permitiendo que la aplicación siga respondiendo.
Copia certificados TLS de Let’s Encrypt manteniendo permisos originales:
rsync -avz --progress \
/etc/letsencrypt/ \
root@IP_NUEVA_HOSTINI:/etc/letsencrypt/Los certificados siguen válidos en la IP nueva porque están vinculados al dominio, no a la IP. Después del cutover, instala certbot en Hostini y el cron de renovación asume normalmente.
Habilita e inicia los servicios en la VPS nueva con la configuración migrada:
sudo systemctl enable --now nginx php8.3-fpm mysql
sudo systemctl status nginxVerifica logs de cada servicio con journalctl -u nginx --since "5 min ago" para confirmar que nada explotó en el boot.
Valida antes del cutover
Este es el paso que separa migración tranquila de migración caótica. Vas a probar la VPS nueva como si ya fuera producción, sin tocar el DNS público — solo en tu /etc/hosts local.
En tu computadora (no en el servidor), edita /etc/hosts agregando una línea que apunte tu dominio a la IP nueva:
sudo nano /etc/hostsAgrega al final:
IP_NUEVA_HOSTINI tudominio.com www.tudominio.comAhora tu navegador va a resolver tudominio.com a la IP nueva solo para ti. Abre el sitio en un navegador anónimo, prueba login, navegación, formularios. Si algo se rompe, todavía tienes la producción antigua corriendo intacta.
Prueba en Chrome, Firefox y Safari. Cada uno cachea DNS de forma diferente. En mobile, configura el /etc/hosts vía apps tipo “Hosts Editor” en Android o conexión SSH local para validar la UX real.
Cutover: apunta el DNS a la nueva IP
Este es el momento de transición. Antes del switch, ejecuta un rsync final para capturar cambios desde la última sincronización. Idealmente, pon la aplicación en modo mantenimiento por 30-60 segundos durante ese rsync final para garantizar consistencia.
Rsync incremental final de los archivos que pueden haber cambiado:
rsync -avz --delete --progress \
/var/www/ \
root@IP_NUEVA_HOSTINI:/var/www/La flag --delete remueve archivos en el destino que ya no existen en el origen — útil si borraste caches o logs.
Dump final de la base de datos con la aplicación en mantenimiento:
mysqldump --single-transaction --routines --triggers \
--all-databases > /tmp/final.sql
rsync -avz /tmp/final.sql root@IP_NUEVA_HOSTINI:/tmp/
ssh root@IP_NUEVA_HOSTINI "mysql < /tmp/final.sql"En el panel de DNS, cambia el registro A del dominio para apuntar a la IP de Hostini. Guarda. Remueve la línea del /etc/hosts local que agregaste para prueba — ahora quieres ver propagación real.
Acompaña la propagación:
dig +short tudominio.com @8.8.8.8
dig +short tudominio.com @1.1.1.1Cuando ambos retornen la IP nueva, la mayoría de los visitantes ya están llegando a la VPS Hostini.
Verificación post-cutover
Confirma que todo está respondiendo en la infraestructura nueva y que nada sigue dependiendo del servidor antiguo.
curl -I https://tudominio.comLa respuesta debe incluir Server: nginx (o lo que hayas configurado) y la IP del TCP socket debe ser la de Hostini. Verifica con curl -v para ver el handshake TLS y confirmar que el certificado está correcto.
Monitorea logs por algunas horas:
sudo tail -f /var/log/nginx/access.logTráfico entrando = cutover funcionó. Si los logs siguen vacíos después de 30 minutos, la propagación de DNS puede estar lenta — algunos ISPs ignoran TTL.
Resolución de problemas
El certificado TLS da error después de la migración
Verifica si el path del certificado en nginx aún apunta a /etc/letsencrypt/live/tudominio.com/. Si renombraste directorios durante la migración, ajusta ssl_certificate y ssl_certificate_key en el config. Prueba con sudo nginx -t antes de recargar.
La aplicación no conecta a la base de datos
Confirma que el usuario de la base de datos existe en la VPS nueva con las mismas contraseñas. mysqldump exporta datos pero no importa usuarios de mysql.user por defecto — agrega --all-databases (ya incluido en los comandos arriba) o haz un dump separado de mysql.user. Verifica /etc/mysql/my.cnf para garantizar que bind-address está correcto.
El tráfico sigue llegando a la VPS antigua
Resolvers que ignoran TTL pueden cachear por horas. Mantén la VPS antigua encendida por 48-72 horas post-cutover como red de seguridad. Configúrala para hacer 301 redirect a la IP nueva vía Nginx — así incluso los visitantes con cache antiguo llegan a donde necesitan.
Próximos pasos
Con la migración concluida, enfócate en consolidar la operación en la nueva infraestructura:
- Configura backups automáticos de la VPS nueva — snapshots programados protegen contra errores operacionales
- Actualiza monitoreo (UptimeRobot, Better Stack) para apuntar a los nuevos endpoints
- Documenta el runbook ejecutado para la próxima migración — evoluciona con cada ejecución
- Después de 7 días estables en Hostini, cancela la VPS antigua y remueve los redirects de seguridad
- Restaura el TTL del DNS a un valor por defecto (3600s o 86400s) — mantener 60s permanentemente aumenta la carga en los resolvers
Si estás poniendo carga de producción en una VPS, una VPS Hostini ofrece SSD NVMe, IPv6 nativo y red con protección contra ataques volumétricos — vale la pena correr benchmarks comparativos durante la ventana de paralelismo de los dos servidores para confirmar ganancia real de performance.
Preguntas frecuentes
¿Cuánto tiempo de downtime se espera en una migración bien hecha?
Con TTL de DNS reducido a 60 segundos 24h antes del cutover y los servicios ya replicados, el downtime real queda entre 30 segundos y 2 minutos. La mayor parte es la propagación de DNS hacia los resolvers que respetaron el TTL — algunos ISPs lo ignoran y cachean por más tiempo, pero la ventana vista por la mayoría de los usuarios es corta.
¿rsync o snapshot completo? ¿Cuál es el método más seguro?
rsync es más seguro para migración entre proveedores diferentes porque sincronizas archivos en el mismo sistema operativo, sin importar imágenes de disco incompatibles. Snapshot/imagen solo funciona bien cuando ambos lados usan el mismo formato (raw/qcow2) y versión de kernel compatible. Para Vultr → Hostini o DigitalOcean → Hostini, rsync gana.
¿Necesito detener la aplicación durante el rsync inicial?
No. El primer rsync copia el estado actual con la aplicación corriendo — puede captar archivos inconsistentes (base de datos, sesiones), pero es solo para mover el volumen de bytes. Después haces rsyncs incrementales que reconcilian diferencias, y el último (con la aplicación detenida por 30-60s) garantiza consistencia final.
¿Cómo evitar que la IP nueva sea bloqueada por mala reputación?
IPs de VPS recién creadas a veces heredan reputación del dueño anterior. Antes del cutover, prueba en herramientas como MXToolbox y Spamhaus. Si la IP está en blacklist, abre un ticket pidiendo cambio antes de migrar — toma minutos y evita problemas de entrega de email post-migración.
¿Puedo probar la nueva VPS sin tocar el DNS?
Sí. Agrega una línea en tu /etc/hosts local apuntando el dominio a la IP nueva de Hostini. Tu navegador va a resolver hacia esa IP solo para ti, mientras el resto del mundo sigue accediendo al servidor antiguo. Permite validar TLS, aplicación y base de datos antes de hacer el switch público.
¿Cómo manejo certificados Let's Encrypt en la transición?
Copia /etc/letsencrypt/ entero vía rsync — incluye claves privadas y certificados activos. Siguen válidos hasta la fecha de expiración y pueden usarse en ambos servidores en paralelo. Después del cutover, instala certbot en la VPS nueva y deja que la renovación automática asuma el ciclo.