Cómo migrar un VPS sin downtime

Mueve un VPS sin cortes: dos servidores en paralelo, replicación continua, TTL cortos, traspaso guiado por guion y plan de vuelta atrás. Core desde $6/mes, $4,80 anual.

El corte vive en el cambio de escritura, no en la copia de archivos

Dos cronómetros gobiernan cualquier mudanza: el intervalo que tardan los bytes en cruzar y el intervalo durante el cual el servicio se tambalea. El primero se mide en horas y no humilla a nadie; el segundo se mide en segundos y define el proyecto en la memoria de todo el que lo tocó. Mantén ambos servidores vivos, transmite los deltas desde la máquina veterana hacia su sucesora y limita el tropiezo al instante en que rediriges las escrituras nuevas: una promoción, una edición de registro DNS, un cambio de configuración. Ningún volumen necesita jamás desmontarse, crearse una imagen ni viajar en físico.

Tres vías pueden absorber el traspaso, y una mudanza disciplinada se compromete con exactamente una. La vía del resolvedor edita una dirección (A o AAAA) tras acortar su tiempo de vida en caché; la vía del almacenamiento promueve un seguidor y deja que las aplicaciones descubran por sí solas al líder ascendente; la vía del software conmuta un endpoint dentro de la propia aplicación. Cuál encaje depende de cómo te localizan los clientes: RFC 1034 describe el mundo de nombres y cachés que habita la primera vía, y su lección es contundente: cualquier respuesta que publicaste ayer sigue sirviéndose hasta que su arrendamiento caduque, según el calendario que tú mismo le concediste.

La transmisión continua es la maquinaria que vuelve barata cualquiera de esas conmutaciones. La sucesora ingiere una dieta constante de deltas: árboles de archivos mediante recorridos repetidos de rsync, transacciones mediante el propio flujo de cambios del motor de base de datos (WAL en PostgreSQL, el binlog en MySQL), eventos mediante la cola que el stack ya opere. La distancia respecto al líder se convierte en el signo vital: segundos de retraso significan un standby caliente; minutos, que algo se atascó aguas arriba; horas, que todo el calendario se derrumbó en silencio mientras nadie miraba la aguja.

El error que convierte mudanzas en fines de semana es retirar primero la máquina productiva. Congelarlo todo para copiar un disco suena concienzudo, pero transforma cada defecto latente (versiones desalineadas, librerías ausentes, credenciales caducadas) en un incidente en vivo con público incluido. Copiar y verificar pertenecen a la fase de ensayo, mientras el veterano todavía responde; solo la conmutación y las pruebas que la siguen merecen una ventana de mantenimiento con nombre propio.

Lleva un modelo mental a través de todo lo que viene: dos máquinas vivas, deltas en un sentido, una única redirección. Cada sección restante disecciona una de esas piezas bajo tráfico real y impaciencia real.

Acondiciona la sucesora antes de que llegue nada valioso

Un servidor vacío es una trampa armada con cuenta atrás. Endúrelo a fondo (acceso, filtro de paquetes, automatización de parches, sincronización horaria) mientras no contiene nada, porque la llegada de los datos marca el momento en que tus horas libres se acaban. Reproduce las configuraciones base como hábitos, no como archivos muertos: dentro de unos años reconstruirás este mismo montaje en otra máquina, así que haz que cada decisión sea legible, documentada y guardada en un sitio que sobreviva a la flota. Todo lo de esta página asume root en ambos extremos: un panel gestionado que oculta la shell también oculta los modos de fallo que este manual existe para resolver.

La paridad de paquetes va primero: generaciones idénticas de daemons, no solo nombres idénticos. Una versión menor desalineada reproduce un comportamiento que el origen nunca exhibió y no sabe explicar. Iguala la propiedad numérica (uid 1000 es una convención, no un estatuto) para que los archivos transferidos conserven permisos coherentes a la llegada. Expresa el filtro de paquetes como un archivo y cárgalo con nft -f /etc/nftables.conf; apunta la máquina a unattended-upgrades; luego interrogua al cronómetro con chronyc tracking, porque todo protocolo de replicación mide distancias en marcas de tiempo y un reloj desviado fabrica retrasos fantasma a partir de un flujo perfectamente sano.

El acceso merece un ritual privado antes de que lleguen las cargas: genera un par de claves dedicado (ssh-keygen -t ed25519), instala la mitad pública en el authorized_keys de la sucesora y elimina la entrada por contraseña (PasswordAuthentication no) como prescribe el manual de sshd. Hacerlo con el disco vacío convierte cada error en gratis; hacerlo durante el traspaso convierte cada error en caro, público e inscrito para siempre en el canal de incidentes de alguien.

La prueba vale más que la intención: arranca la máquina vacía, despliega contenido sintético y ejercita el stack completo una vez: intérprete, base de datos, caché, planificador. Las extensiones ausentes y los módulos del kernel que faltan afloran aquí, en una máquina donde reinstalar cuesta diez minutos y un encogimiento de hombros, en vez de aflorar durante las pruebas con espectadores. Este único pase en seco elimina la mayoría de las sorpresas de mudanza antes de que puedan costar nada.

Cuando el host vacío ejecuta la carga sintética sin fisuras y supera la revisión de su postura de seguridad, ha dejado de ser un servidor en blanco y se ha graduado en destino certificado.

Transmite deltas hasta que el seguidor quede a latidos de distancia

Una copia masiva única congela el tiempo; la replicación se niega a hacerlo. La distinción decide si el destino termina coherente: un solo pase sobre una base de datos viva la rebana en estratos inconsistentes, mientras que el propio flujo de cambios del motor reproduce las transacciones en orden de confirmación y concluye con un gemelo fiel al byte. Los árboles de directorios toleran la copia ingenua con alegría; los motores relacionales se niegan rotundamente: entrega a un motor vivo un duplicado bruto de archivos y se vengará en la primera escritura, sin negociar.

Los sistemas de archivos toman el camino fácil: un bucle programado de rsync -aAX --delete --info=progress2 /srv/ root@new:/srv/ cada 5 minutos mantiene el desfase superficial, con la referencia de rsync detallando qué interruptores de archivado preservan propiedad, atributos extendidos y archivos dispersos. PostgreSQL viaja más lejos: pg_basebackup -R siembra un gemelo físico y primary_conninfo sostiene el flujo, mientras que pg_stat_replication en el líder revela el replay_lag de cada suscriptor, tal como documenta exhaustivamente el capítulo de standby.

El dialecto de MySQL difiere; su gramática corresponde. Arranca desde una instantánea coherente, alístrate con CHANGE REPLICATION SOURCE TO llevando las coordenadas del líder y lee Seconds_Behind_Source hasta que se asiente en un solo dígito, según la guía de replicación oficial. Donde exista un canal a nivel de aplicación (diarios de solo anexado, topics de colas, hooks de exportación), prefiérelo: el software mismo sabe qué bytes cambiaron, y ese conocimiento sobrevive a refactorizaciones que destrozan por completo los supuestos del sistema de archivos.

Las catástrofes aquí llevan firma. Un duplicado bruto de tablespace en vivo produce un volumen de aspecto plausible que se corrompe en el primer INSERT: las magnitudes coinciden, los checksums no. Un destino con --delete invertido aniquila los archivos del propio destino con exquisita cortesía. Y un cronograma que expiró en silencio el martes pasado solo se anuncia cuando el retraso cruza a horas: alerta sobre la distancia medida, nunca sobre la mera existencia de una entrada del temporizador.

Cuando el peor momento de un día rutinario del seguidor se mantiene a segundos de su líder, el destino ha dejado de ser una copia y se ha convertido en un standby caliente: la precondición que todo paso posterior da por supuesta.

Acorta la memoria del resolvedor un día antes de la mudanza

Publicar una dirección nueva es instantáneo; que el público aterrice en ella, no. Todo resolvedor recursivo entre tus visitantes y la zona retiene la respuesta anterior hasta que su arrendamiento caduca, así que un registro editado al mediodía sigue despachando a parte de tu audiencia hacia una máquina que ya degradaste. La magnitud y duración de esa multitud rezagada quedaron fijadas en el momento en que la zona se tocó por última vez: por ti, hace semanas, sin que se notara. Los registros publican los tiempos de vida; las cachés los imponen.

Una sola regla vuelve determinista el calendario: los tiempos de vida en caché no pueden acortarse retroactivamente. Un campo que hoy lee 86400 sigue obedeciéndose a sí mismo hasta un día después de que lo bajes, y por eso la reducción va 24 horas antes, no junto a la conmutación. Escalona: 300 el día previo, 60 la mañana de la mudanza, e interrogua la respuesta en vivo con dig +norecurse para observar lo que las cachés exteriores realmente guardan en lugar de fiarte de tus suposiciones sobre ellas.

Dos RFC delimitan el territorio. RFC 2181 desenreda la semántica de los tiempos de vida para respuestas afirmativas; RFC 2308 cubre las negativas: los resolvedores también memorizan fallos, y una sola consulta fallida durante el cambio instruye a miles de cachés a persistir en fallar durante el intervalo de la respuesta obsoleta. Mantén las respuestas negativas cortas durante la ventana y aflojalas cuando el retiro concluya.

Dominan dos formas de fallo. Editar los tiempos de vida en el momento de la conmutación deja a una fracción de visitantes varados horas en el host degradado: la versión de manual, recitada en cada postmortem. La variante más silenciosa: los servidores de correo, los socios de integración y los proveedores de monitorización operan resolvedores con políticas privadas, así que la convergencia llega como una curva y no como un instante. Verifica desde varias redes y al menos un operador móvil; tu propia estación de trabajo no prueba nada, y su caché la purgaste tú personalmente.

Un día de respuestas de vida corta no cuesta nada perceptible para el visitante, y convierte la edición de la dirección del gesto más arriesgado de la mudanza en su partida más aburrida.

El traspaso en sí: cinco movimientos, diez minutos, cero drama

Un traspaso ensayado es administrativo; uno sin ensayar es teatro. Cinco acciones, unos 10 minutos: suspende las escrituras nuevas en el titular, drena los deltas finales, redirige las escrituras, prueba los caminos que importan y observa la convergencia global. Toda historia de catástrofe del folclore de las mudanzas nace de que una de esas cinco se improvisó en escena en lugar de ensayarse dos veces sobre un gemelo desechable. Aquí nada es ingenioso; toda la disciplina consiste en negarse a improvisar.

Suspender las escrituras es la piedra angular. Aplaca el almacén de datos del titular (read_only=ON en MySQL, un permiso de escritura revocado o el modo mantenimiento de la propia aplicación en otros casos) para que los deltas de cierre aterricen sobre una fuente quieta y el destino termine coherente en lugar de casi coherente. Sáltate la congelación y has fabricado un split-brain: dos primarios aceptando alegremente historias divergentes, una herida reconciliada después con hojas de cálculo exportadas, disculpas avergonzadas y una semana de conciliación que nadie presupuestó.

Redirige por el camino que elegiste al principio: edita el registro, o promociona al seguidor (SELECT pg_is_in_recovery(); respondiendo f certifica que la sucesora ya lidera), o repunta el endpoint de la aplicación. Luego prueba como un adversario: curl -fk https://example.com/health para la entrada principal, claro, pero envía también el formulario de inicio de sesión, pasa un artículo por la compra y lanza a mano el lote nocturno. Los caminos de escritura son los que la replicación estresó; una portada no prueba ninguno y tranquiliza precisamente a nadie que importe.

Tropezones recurrentes: trabajadores del planificador en el titular que sobrevivieron y escribieron durante horas tras la congelación; alertas aletándose durante toda la ventana hasta que todos silenciaron el canal, incluso durante el fallo genuino; pruebas que cubrían la landing mientras los endpoints POST ardían en privado. Para el destino, asegúrate el plan Core a $6/mes de lista ($4,80 en el término anual) y mantén ambas facturas vivas durante toda la ventana: un ritmo deliberado cuesta céntimos al día y rescata veladas.

Ensaya la secuencia dos veces contra una máquina de sacrificio y el evento real colapsa en memoria muscular: diez minutos sin prisa cuya única tensión es ver cómo la aguja de retraso se asienta en cero.

El titular es tu seguro; cancélalo tarde

El retiro pertenece al mismo proyecto que la mudanza, en un calendario medido en ciclos de tráfico. Deja al veterano encendido como mínimo 7 días completos: bastante para los trabajos semanales, los resúmenes mensuales y ese único cliente cuyo resolvedor honra respuestas antediluvianas con devoción religiosa. Semanas, si el servicio lleva ciclos mensuales; los días son el suelo, no el objetivo. Cada descubrimiento de este tipo es trivial mientras el host veterano responde; tras la cancelación degenera en un ticket de soporte dirigido a un volumen borrado y a un humano arrepentido.

Observa al veterano durante todo su retiro, no solo al recién llegado. Los horarios huérfanos se delatan como correo saliente sin destino: mailq imprime la cola de un vistazo; crontab -l enumera lo que aún se agita cada noche. Los trabajos de renovación pueden seguir refrescando certificados en la raíz web del veterano, dividiendo en silencio las visitas entre dos orígenes; las marcas de tiempo de certbot renew revelan qué caja visitan todavía los extraños de verdad. Los cortafuegos de socios y los balanceadores aguas arriba señalan el origen durante semanas si nadie les avisa, y ese alguien eres tú.

Antes de desenchufar, guarda la ruta de escape: una instantánea completa almacenada lejos de ambas máquinas, verificada con sha256sum para que el archivo pueda atestiguar su propia integridad después, más la minucia propensa a huérfanos: inventarios de trabajos, reglas del filtro de paquetes, configuración de renovación según la documentación de Let's Encrypt. La instantánea viaja como complemento del checkout; la tranquilidad que compra es que restaurar gana a reconstruir de memoria a medianoche.

El impulso purificador es el fallo notorio: el traspaso triunfa el martes, la cancelación aterriza el jueves y el viernes alberga el trabajo de conciliación mensual que solo se ejecutó allí nunca. Su gemelo es el bucle de reenvío: una regla de balanceador heredada que sigue redirigiendo hacia el recién llegado mientras el recién llegado hace proxy de una ruta heredada, dos máquinas cortésmente pasándose a los visitantes entre sí hasta que alguien lee los registros de acceso línea por línea. Los registros, no la memoria, deciden cuándo dejó de existir el bucle en realidad.

Retira la infraestructura como los auditores retiran credenciales: en una fecha anunciada de antemano, desde un plan escrito, con el archivo de ayer descansando verificado en almacenamiento frío.

Las direcciones no emigran; planifica en torno a la que dejas atrás

El espacio IPv4 pertenece a las redes, no a los patronos: la dirección en la que responde tu servicio es un préstamo del bloque del titular y se queda atrás al partir. Toda mudanza contiene por tanto una migración de dirección embebida, y los equipos que se niegan a reconocerla se topan con literales codificados a mano (en scripts de cron, listas blancas de socios, sondas de monitorización) durante las pruebas finales en lugar de durante la planificación, que es el escenario concebible más caro para semejante descubrimiento.

A la mayoría del público no le hace falta nada exótico: la edición de registro con vida acortada de la sección anterior reubica el nombre, y la dirección de la sucesora simplemente difiere. Para el cliente excepcional que depende duramente de un endpoint constante (un socio que filtra por origen, un aparato heredado que ignora los nombres), levanta mejor un porche frontal: una entrada de proxy o túnel que administras tú, estacionada delante de ambas máquinas, que transmuta la dirección inamovible del proveedor en una portátil que posees tú. Las dependencias porosas afloran ahora, baratas, mientras ambas puertas aún funcionan.

Reconstruye la plomería de identidad deliberadamente: registros inversos desde el panel si el correo participa, marcos de remitente que nombren la dirección nueva, objetivos de sondas y filtros de socios revisados mediante tickets en lugar de disculpas. Tu propia terminal se queja primero: expulsa la huella obsoleta con ssh-keygen -R old.example.com (manual) y resiste el hábito de campus de -o StrictHostKeyChecking=no, que cambia una edición de una línea en known-hosts por una credulidad permanente y sin examen.

Donde los equipos tropiezan: la cacería de literales recorre el código de la aplicación pero pasa de largo por la periferia: horarios en servidores vecinos, el corredor de integración, el archivador en un portátil. Peina /etc, todo crontab legible y los tickets antiguos; la mayoría de los operadores recuperan así dos o tres literales olvidados. Especímenes documentales como 203.0.113.10 sirven como patrones de búsqueda solo tras sustituirlos por la auténtica dirección que se va.

Trata la mutación de dirección como un entregable propio con sus propias pruebas de aceptación, y el tramo que todos temen se convierte en el tramo que nadie recuerda.

Ensayo general de toda la obra contra un gemelo desechable

Una mudanza ejecutada sin ensayo es un borrador corregido por tus usuarios. El ensayo es asequible precisamente porque el objetivo de práctica es prescindible: levanta un gemelo de sacrificio, ejecuta la secuencia completa (acondicionamiento, transmisión, ediciones de tiempos de vida, congelación, redirección, pruebas) y cronometra cada movimiento en lugar de adivinarlo. Las cifras con las que entres al evento real deben ser mediciones con barras de error, nunca optimismo con coma decimal.

Sellalo todo con marcas de tiempo: date -u +%s estampado en el runbook, y el runbook mismo versionado en git para que cada ensayo deje un diff fechado de qué corrió largo, qué falló y cómo se dobló de verdad la curva de retraso. Un plan que reside en la memoria de un único administrador se ensaya exactamente una vez, en el instante de máxima presión, lo cual es indistinguible de no haber ensayado jamás.

El resultado del ensayo se convierte en el calendario auténtico: si los deltas de cierre consumen 12 minutos y la convergencia mundial necesita 45, la ventana de mantenimiento es una cifra defendible en lugar de un deseo. Presupuesta antes la fase de árboles con rsync --dry-run (referencia), y ensaya también la retirada: restaura el archivo, repunta el registro, certifica que el veterano sigue sirviendo, porque una vuelta atrás sin probar es un cuento para dormir, no un procedimiento que nadie pueda ejecutar bajo presión.

Dos trampas socavan los ensayos. Practicarlo todo menos la congelación de escrituras, porque pausar una carga imaginaria parece teatral, dejando la cerradura más consecuente de todas sin probar hasta que la realidad provea el público. Y saltarse las pruebas del destino porque los datos sintéticos son patentemente sólidos, lo que entrena al equipo a tratar las pruebas como ceremonia. El impulso, no la malicia, causa ambas; ensaya más fuerte los pasos tediosos, porque son los que fallan a gritos.

Si el destino merece bare metal desde el primer arranque (cómputo de núcleo completo, consola integrada), pide Forge a $49/mes de lista, $39,20 en el término anual, y ensaya contra él igual; la coreografía sobrevive, solo cambia el escenario debajo.

La migración, en el orden en que hay que ejecutarla

Recitado de principio a fin: acondiciona y endúreza a la sucesora mientras el titular aún rinde; abre los flujos de delta y vigila el retraso; acorta los tiempos de vida del resolvedor un día antes; ejecuta el traspaso de cinco movimientos; cobija al veterano una semana; archiva; retira. La secuencia es estructural: cada etapa fabrica las precondiciones de la siguiente, y avanzar a saltos convierte minutos de trabajo en noches de recuperación. Esta página la escribió alguien que vio un cutover sin ensayar convertirse en un fin de semana; ese alguien ahora está alerta, y puedes tomar prestada su cautela al por mayor.

Orden concreto: línea base: pares de claves dedicados mediante ssh-keygen -t ed25519, filtro de paquetes como archivo, automatización de parches, cronómetros sincronizados. Luego movimiento: bucles de rsync -aAX para árboles, pg_basebackup más transmisión sostenida para PostgreSQL, alistamiento con coordenadas del líder para MySQL, alarmas ancladas al retraso medido para que el silencio signifique salud y no muerte. El seguidor alcanza rango de standby cuando su peor retraso rutinario se lee en segundos, no cuando concluye la copia inicial.

Víspera del cambio: los tiempos de vida descienden a 300, anunciado a todo socio que opere resolvedores privados. Mañana del cambio: congela escrituras, drena restos, redirige (registro, promoción o endpoint), luego prueba los caminos que mutan como un intruso y observa la convergencia desde redes que no comandas personalmente. La congelación es sacrosanta; primarios divergentes son la única herida que este método no puede sanar barato, y todo lo demás del inventario existe para volver la congelación breve.

La semana posterior: el veterano permanece encendido, con sus colas y horarios vigilados, renovaciones intactas, mientras los rezagados entran y los trabajos olvidados se confiesan. Antes del apagado: instantánea más los sueltos (reglas del filtro, configuraciones de renovación, inventarios de trabajos) sellados en un único archivo. La comparación de VPS frente a bare metal orienta dónde debe residir el sucesor de la sucesora; la coreografía entre ambos queda idéntica.

Ejecútalo dos veces, una contra un gemelo de sacrificio y otra para la historia, y la segunda función se dirige sola: diez minutos sin prisa que se sienten exactamente como se ensayaron, que es toda la ambición de esta página.