Migrar una web o servidor con rsync y mysqldump: guía casi sin tiempo de inactividad
Cuando cambias de centro de datos, mejoras la configuración o te mudas desde otro proveedor, lo que más preocupa es perder datos y tener una caída prolongada. Esta guía recorre un flujo de migración probado en la práctica: sincronización incremental de archivos con rsync, migración de la base de datos con mysqldump y reducción anticipada del TTL de DNS para un cambio sin sobresaltos. En la mayoría de los sitios web, esto limita el tiempo de inactividad a unos pocos minutos.
Puntos clave
- Una migración de web o servidor sin sobresaltos depende de reducir pronto el TTL de DNS, hacer una sincronización completa seguida de una incremental y probar en el nuevo servidor antes de cambiar el DNS.
- Reduce el TTL de DNS de los registros A del sitio a 300 segundos, o incluso a 60, al menos 24 horas antes de migrar, para que las cachés DNS caduquen antes del cambio.
- La primera sincronización completa con rsync puede hacerse con la web en funcionamiento, y la sincronización incremental final solo transfiere los archivos modificados, por lo que es rápida.
- En tablas InnoDB, la opción
--single-transactionde mysqldump exporta una instantánea coherente sin bloquear las tablas. - IMIDC ofrece un servicio gratuito de asistencia en la migración a los clientes que contratan un servidor cloud o un servidor dedicado en Hong Kong, Japón, Singapur, Estados Unidos u otra ubicación.
A quién va dirigida / Requisitos previos
- Tanto el servidor de origen como el de destino usan Linux (Ubuntu, Debian, Rocky Linux, AlmaLinux, etc.)
- Puedes acceder por SSH a ambos servidores como root o con un usuario sudo, y
rsyncestá instalado - El servidor de destino tiene el mismo entorno de ejecución que el de origen, o uno compatible (Nginx/Apache, PHP, MySQL/MariaDB)
Instalar rsync:
# Debian / Ubuntu
apt install -y rsync
# RHEL / Rocky / AlmaLinux
dnf install -y rsync
Checklist previa a la migración
| Elemento | Detalles |
|---|---|
| Copia de seguridad completa | Haz una copia de seguridad completa o una instantánea del servidor de origen antes de migrar |
| Espacio en disco | Usa df -h y du -sh para confirmar que el disco de destino tiene espacio suficiente |
| Versiones de software | Compara las versiones de PHP, MySQL y Nginx para evitar incompatibilidades con versiones más nuevas |
| Archivos de configuración | Anota la configuración de los hosts virtuales, las tareas cron (crontab -l) y la ubicación de los certificados SSL |
| IP escritas en el código | Comprueba si la IP del servidor antiguo está escrita directamente en tu aplicación o en la configuración |
| Correo y terceros | Confirma si los registros MX, las listas blancas de API, las URL de callback de pagos, etc. dependen de la IP antigua |
| TTL de DNS | Reduce el TTL al menos 24 horas antes |
Pasos
1. Reduce el TTL de DNS con antelación
Entra en el panel de gestión DNS de tu dominio y cambia el TTL de los registros A del sitio del valor por defecto (normalmente 3600 segundos o más) a 300 segundos, o incluso 60. Espera al menos un periodo del TTL original antes del cambio definitivo para que caduquen las cachés de los DNS recursivos en todas partes. Puedes consultar el TTL actual con:
dig example.com A +noall +answer
El número que aparece tras el nombre de dominio en la salida es el TTL restante en segundos.
2. Configura claves SSH para transferir sin contraseña
En el servidor de destino, genera una clave y cópiala al servidor de origen (usamos un esquema de «pull» para trabajar desde la máquina nueva):
ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
ssh-copy-id -p 22 root@SOURCE_SERVER_IP
Sustituye
SOURCE_SERVER_IPen los comandos por la dirección IP del servidor de origen.
3. Haz la primera sincronización completa de archivos con rsync
Ejecuta esto en el servidor de destino (ejemplo sincronizando el directorio de la web):
rsync -avzP -e "ssh -p 22" root@SOURCE_SERVER_IP:/var/www/ /var/www/
Opciones: -a modo archivo, que conserva permisos, propietarios y marcas de tiempo; -v salida detallada; -z compresión durante la transferencia; -P muestra el progreso y permite reanudar transferencias parciales. Ten en cuenta que la / final en la ruta de origen significa «sincronizar el contenido del directorio»; si la omites, se añade un nivel extra de directorio anidado.
Antes de la ejecución real, añade -n (--dry-run) para previsualizar qué archivos se transferirán. Usa --exclude para omitir directorios de caché o de logs:
rsync -avzPn --exclude 'cache/' --exclude '*.log' -e "ssh -p 22" root@SOURCE_SERVER_IP:/var/www/ /var/www/
La primera sincronización completa puede ejecutarse con la web en funcionamiento sin afectar al negocio.
4. Migra la base de datos con mysqldump
Exporta la base de datos en el servidor de origen. En tablas InnoDB, --single-transaction genera una instantánea coherente sin bloquear las tablas:
mysqldump -u root -p --single-transaction --routines --triggers --events --default-character-set=utf8mb4 dbname | gzip > /root/dbname.sql.gz
Transfiérela al servidor de destino:
rsync -avP -e "ssh -p 22" root@SOURCE_SERVER_IP:/root/dbname.sql.gz /root/
En el servidor de destino, crea la base de datos y el usuario, y luego importa:
mysql -u root -p -e "CREATE DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'dbuser'@'localhost' IDENTIFIED BY 'STRONG_PASSWORD'; GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost'; FLUSH PRIVILEGES;"
gunzip < /root/dbname.sql.gz | mysql -u root -p dbname
Sustituye
STRONG_PASSWORDpor una contraseña segura de tu elección.
Tras la importación, comprueba por muestreo que el número de tablas coincide:
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='dbname';"
5. Prueba en el nuevo servidor
En lugar de cambiar el DNS, apunta temporalmente el dominio a la nueva IP en el archivo hosts de tu ordenador (en Windows está en C:\Windows\System32\drivers\etc\hosts; en macOS/Linux es /etc/hosts):
203.0.113.20 example.com www.example.com
Revisa una a una las funciones clave, como la página de inicio, el inicio de sesión, las subidas de archivos y los callbacks de pago. Cuando todo funcione, elimina la entrada de hosts.
6. Sincronización incremental final y cambio de DNS
- Pon el sitio de origen en modo mantenimiento o detén las escrituras para que no se generen datos nuevos durante el cambio.
- Vuelve a ejecutar rsync. Esta vez solo se transfieren los archivos modificados, así que es rápido. Si necesitas que el directorio de destino sea idéntico al de origen, añade
--delete(elimina los archivos sobrantes en el destino, así que úsalo con cuidado). - Exporta e importa la base de datos una vez más.
- Cambia el registro A del DNS para que apunte a la IP del nuevo servidor. Como el TTL ya está reducido, la mayoría de los visitantes llegarán al nuevo servidor en cuestión de minutos.
- Vigila los logs de acceso del nuevo servidor y, cuando hayas confirmado que el tráfico se ha trasladado, devuelve el TTL a su valor normal.
Recomendamos conservar el servidor de origen al menos 3–7 días antes de darlo de baja, por si necesitas volver atrás.
Preguntas frecuentes
¿Qué hago si se interrumpe la transferencia de rsync?
Simplemente vuelve a ejecutar el mismo comando. rsync omite los archivos ya transferidos, y la opción -P también permite reanudar archivos grandes.
La base de datos es enorme y la exportación es demasiado lenta. ¿Qué puedo hacer?
Añade --quick para reducir el uso de memoria y comprime mediante una tubería para exportar y transferir a la vez. Para bases de datos de decenas de GB o más, plantéate herramientas de copia de seguridad física (como Percona XtraBackup o mariabackup) o migrar mediante replicación primaria/réplica.
¿Por qué mi web muestra caracteres extraños (por ejemplo, en tildes, eñes o texto chino) tras la migración?
Suele deberse a que el juego de caracteres no coincide entre la exportación y la importación. Asegúrate de indicar --default-character-set=utf8mb4 al exportar y de que la base de datos de destino también use utf8mb4.
Tras el cambio de DNS, algunos usuarios siguen llegando al servidor antiguo. ¿Por qué?
Ocurre porque las cachés DNS de algunos proveedores de internet aún no han caducado, y normalmente se resuelve solo dentro del periodo del TTL original. Por eso conviene conservar el servidor antiguo unos días.
Resumen
Las claves de una migración sin sobresaltos son: «reducir el TTL con antelación, hacer primero una sincronización completa y luego una incremental, y probar antes de cambiar». Si piensas trasladar tu web o tu negocio a IMIDC, ofrecemos un servicio gratuito de asistencia en la migración: tras contratar un servidor cloud o un servidor dedicado en Hong Kong, Japón, Singapur, Estados Unidos u otra ubicación, abre un ticket describiendo tu entorno de origen y tus necesidades de migración, y nuestros técnicos acordarán contigo un plan concreto y una ventana de tiempo. Si tienes cualquier duda durante la migración, puedes obtener ayuda en todo momento a través de nuestro sistema de tickets 24/7.