Migrar de un servidor viejo a uno nuevo con minutos de corte

Por qué apagar y copiar es la peor opción

El método obvio, apagar el viejo, copiar todo y encender el nuevo, tiene un problema: el corte dura lo que tarda la copia completa, más lo que tarde en aparecer el primer error. Con cientos de gigas o una base grande, eso es una noche entera, y si algo sale mal a las cuatro de la mañana no hay vuelta atrás rápida.

La alternativa es trabajar en paralelo. El viejo sigue atendiendo mientras el nuevo se llena de datos, y el corte queda reducido a la diferencia entre la última copia y el momento del cambio. Si lo que movés es un sitio en un hosting y no un servidor entero, el proceso es más simple y está en cómo migrar tu sitio sin que se caiga.

Antes de copiar nada: el inventario

Lo que rompe una migración casi nunca son los datos, que se copian fácil, sino lo que nadie anotó. Armá una lista antes de empezar:

• Servicios y versiones: servidor web, PHP, base de datos, lenguajes, con sus números de versión.
• Tareas programadas de cada usuario (crontab -l) y temporizadores de systemd (systemctl list-timers).
• Puertos que están escuchando, con ss -tlnp, y las reglas del firewall.
• Usuarios del sistema, claves SSH autorizadas y permisos especiales.
• Terceros que autorizaron la IP vieja: pasarelas de pago, APIs, bases remotas, y el registro SPF del dominio si el servidor manda correo.
• Certificados y cómo se renuevan.
• Todo lo que se configuró una sola vez y nadie documentó: recorré /etc con calma.

El cronograma, día por día

El TTL se baja con anticipación porque los servidores DNS de internet guardan la respuesta anterior durante el TTL viejo: si era de un día, hay que esperar un día para que todos tomen el valor nuevo.

Copiar los archivos con rsync

rsync copia todo la primera vez y, en las pasadas siguientes, solo lo que cambió. Corrido desde el servidor nuevo, trae los datos del viejo por SSH:

rsync -aHAX --numeric-ids --info=progress2 root@IP_VIEJA:/var/www/ /var/www/
# pasadas siguientes: además borra en destino lo que ya no existe en origen
rsync -aHAX --numeric-ids --delete root@IP_VIEJA:/var/www/ /var/www/

• La barra final en /var/www/ importa: copia el contenido de la carpeta y no la carpeta dentro de otra.
• -H, -A y -X conservan enlaces duros, permisos extendidos y atributos; --numeric-ids mantiene los dueños aunque los nombres de usuario no coincidan entre los dos servidores.
• Si los dos servidores están en el mismo datacenter, usá la red privada entre ellos: la copia va más rápido y no consume el ancho de banda público.
• Para el correo, imapsync copia casilla por casilla entre dos servidores IMAP y se puede repetir: la segunda pasada trae solo lo nuevo.

La base de datos: réplica en lugar de volcado

Si la base pesa unos pocos gigas, un volcado final durante el congelamiento puede alcanzar. Si es más grande, o si no tolera ni media hora de corte, conviene que la base nueva sea réplica de la vieja: recibe cada cambio en el momento y el día del corte ya está al día.

En MySQL y MariaDB, la réplica se arma a partir de un volcado consistente que anota la posición del registro binario, con --single-transaction y --master-data=2 (en MySQL 8.0.26 o posterior se llama --source-data=2), y después se configura el servidor nuevo para que siga desde esa posición. La réplica tiene que tener la misma versión que el origen o una más nueva. En PostgreSQL, pg_basebackup arma una réplica física si los dos servidores tienen la misma versión mayor; si cambiás de versión, la replicación lógica sirve para pasar de una a otra.

Probar el servidor nuevo antes de que nadie lo vea

Antes del cambio, entrá al servidor nuevo con el dominio de verdad, sin tocar el DNS público. Para que tenga certificado desde el primer minuto, copiá los certificados vigentes del viejo o emitilos con validación por DNS: la validación por HTTP no funciona hasta que el dominio apunte al servidor nuevo. Hay dos formas de probar:

• Agregá una línea con la IP nueva y el dominio al archivo hosts de tu computadora: /etc/hosts en Linux y macOS, C:\Windows\System32\drivers\etc\hosts en Windows. Tu navegador va al nuevo; el resto del mundo sigue en el viejo.
• Desde una terminal, sin tocar nada: curl --resolve tudominio.com.ar:443:IP_NUEVA -I https://tudominio.com.ar/ le pide la página al servidor nuevo y muestra la respuesta.

El día del corte

1. Avisá con anticipación y elegí la franja de menos tráfico.
2. Poné el sitio en mantenimiento o en solo lectura: nadie compra, publica ni sube archivos hasta que termine.
3. Corré la última pasada de rsync, que con todo sincronizado tarda poco.
4. Comprobá que la réplica esté al día, detenela y dejala como base principal, con STOP REPLICA; y RESET REPLICA ALL; (en versiones viejas se escribe SLAVE en lugar de REPLICA).
5. Cambiá los registros DNS a la IP nueva y actualizá el SPF si cambió la IP que manda correo.
6. En el viejo, reenviá al nuevo el tráfico que todavía llegue, por ejemplo con un proxy inverso en el servidor web. Así nadie escribe en la base vieja por tener el DNS anterior guardado.
7. Sacá el mantenimiento y recorré la lista de control.

La lista de control después del cambio

• El sitio abre por https sin advertencias, con y sin www.
• Los formularios envían y el correo sale y entra; fijate que no caiga en spam.
• Las tareas programadas corrieron a su hora: revisá sus registros al día siguiente.
• Los registros de errores del servidor web y de la aplicación no muestran nada nuevo.
• Las copias de seguridad del servidor nuevo ya están configuradas y la primera terminó bien.
• Los terceros que autorizaban la IP vieja ya tienen la nueva.

Dónde aterrizar

Si el servidor viejo es propio y está al final de su vida útil, es un buen momento para dejar de mantener hardware. Los servidores cloud de InHosting corren sobre hardware dedicado con Proxmox VE, discos en RAID 10 con disco de reserva, IP pública fija, consola de rescate y red privada entre servidores del mismo datacenter, en Buenos Aires. El sistema operativo lo administrás vos, y te acompañamos en la puesta en marcha. Si el equipo todavía tiene años por delante, también podés traerlo en housing.

Con el 10 % de descuento del código INH, que ya va en los enlaces de contratación. Los precios se leen de la tienda. Ver el detalle de cada plan.