Respuesta corta: en vez de copiar el disco entero durante la ventana de mantenimiento, se replica la mayor parte de los datos con la VM funcionando normalmente y se sincronizan solo los bloques modificados. La ventana de corte deja de depender del tamaño del disco y pasa a depender de cuánto cambió desde la última sincronización: de horas a minutos.
Es la diferencia entre una migración que el negocio tolera y una que no.
El problema que resuelve
Migración tradicional de una VM de 500 GB:
`
Apagar VM → copiar 500 GB → convertir → importar → arrancar → validar
└─────────────── 4 a 8 horas de servicio caído ───────────────┘
`
Con discos grandes o aplicaciones con mucha escritura, esa ventana no entra en ningún fin de semana razonable. Y multiplicada por 50 VMs, el proyecto se vuelve inviable.
Los cuatro principios
1. Replicar por adelantado
La copia inicial —la más pesada— se hace con la VM encendida y funcionando. Puede tardar horas o días: no importa, porque nadie está esperando.
2. Sincronizar solo los deltas
Después de la copia inicial, se transfieren únicamente los bloques que cambiaron. Cada sincronización es más chica y más rápida que la anterior.
Se puede repetir tantas veces como haga falta hasta que el delta sea lo suficientemente chico.
3. Mantener los dos lados alineados
Origen y destino conviven en estados cada vez más parecidos. En cualquier momento podés hacer el corte, y también cancelar: el origen nunca se tocó.
4. Cortar con downtime mínimo
La ventana real queda reducida a: apagar la VM, sincronizar el último delta, arrancar en destino y validar. Minutos, no horas.
`
[VM en producción] ──── copia inicial (horas, sin impacto) ────►
[VM en producción] ──── delta 1 ────► delta 2 ────► delta 3 ───►
[VM apagada] ─ delta final ─► arrancar en destino ─► validar
└──────────── 10 a 20 minutos ────────────┘
`
La cuenta que define la ventana
La ventana de corte es, aproximadamente:
`
tiempo = (tasa de cambio × tiempo desde la última sync) / ancho de banda
+ tiempo de arranque
+ tiempo de validación
`
Lo importante: el tamaño del disco desaparece de la ecuación. Una VM de 2 TB con poca escritura puede tener una ventana más corta que una de 100 GB con mucha actividad.
Por eso conviene programar la última sincronización lo más cerca posible del corte.
Cuándo se justifica
| Situación | ¿Incremental? |
|---|---|
| Disco de más de 200 GB | Sí |
| Aplicación crítica con ventana corta | Sí |
| Base de datos activa | Sí, y con cuidado extra |
| Muchas VMs a migrar | Sí, es lo que hace viable el proyecto |
| VM chica de desarrollo | No hace falta, copia directa y listo |
| Servidor que se apaga los fines de semana | No hace falta |
Lo que hay que tener en cuenta
No todas las aplicaciones toleran la copia en caliente. Bases de datos y sistemas transaccionales necesitan quiesce —congelar la escritura un instante— o una estrategia propia de replicación. Para una base de datos, muchas veces la respuesta correcta no es replicar el disco sino usar la replicación nativa del motor.
El delta puede crecer más rápido de lo que sincronizás. Si la VM escribe más de lo que el enlace transfiere, nunca converge. Se resuelve con más ancho de banda, o sincronizando en horarios de baja actividad.
Ocupa el doble de espacio durante toda la transición. Hay que planificarlo.
Preguntas frecuentes
¿Cuánto dura la ventana de corte real?
Con la sincronización bien hecha, entre 5 y 20 minutos por VM. La mayor parte se va en el arranque y la validación, no en la transferencia.
¿Puedo cancelar a mitad de camino?
Sí, y esa es una de sus mejores propiedades. Mientras no hagas el corte, el origen sigue intacto y en producción. Cancelar no cuesta nada más que el tiempo invertido.
¿Sirve para bases de datos?
Sirve, con cuidado. Para bases muy activas suele ser mejor la replicación nativa del motor: levantar una réplica en destino, sincronizar y promoverla. Es otro procedimiento y a veces más simple.
¿Necesito herramientas comerciales?
No necesariamente. Se puede armar con CBT, snapshots y rsync. Las herramientas comerciales agregan orquestación y reportes, que a escala valen la pena. Los métodos disponibles.
En resumen
La migración incremental cambia la pregunta: ya no es "cuánto tarda copiar 500 GB" sino "cuánto cambió en la última hora". Eso saca el tamaño del disco de la ecuación y convierte ventanas de horas en ventanas de minutos.
Es lo que hace posible migrar producción sin pedirle al negocio un fin de semana entero.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.