Respuesta corta: el corte es una secuencia ensayada con tiempos medidos, un responsable que decide y un punto de no retorno definido de antemano. La regla que lo sostiene todo: la VM origen se apaga, nunca se borra. Mientras exista apagada, el rollback tarda minutos.
Si el corte se improvisa, se improvisa también el rollback. Y ese es exactamente el momento en que no querés estar improvisando.
Antes del corte
Todo esto está hecho y verificado antes de que empiece la ventana:
- ☐ Última sincronización completa, con checksum validado
- ☐ La VM destino arrancó al menos una vez en un entorno aislado
- ☐ Drivers virtio verificados
- ☐ Configuración de red del destino lista, sin conectar
- ☐ Ventana comunicada a usuarios y a la mesa de ayuda
- ☐ Responsable de la decisión, designado y presente
- ☐ Procedimiento de rollback impreso o a mano
- ☐ Backup del origen, reciente y probado
Si falta uno, el corte se posterga. No se "resuelve en el momento".
La secuencia
| # | Paso | Tiempo | Acumulado |
|---|---|---|---|
| 1 | Avisar el inicio de la ventana | 0 min | 0 |
| 2 | Detener los servicios de la aplicación ordenadamente | 2 min | 2 |
| 3 | Apagar la VM origen (shutdown, no forzado) | 2 min | 4 |
| 4 | Sincronización final del delta | 3–10 min | 14 |
| 5 | Verificar checksum | 1 min | 15 |
| 6 | Desconectar la red de la VM origen | 1 min | 16 |
| 7 | Arrancar la VM destino | 2 min | 18 |
| 8 | Validación técnica rápida (red, disco, servicios) | 3 min | 21 |
| 9 | Validación del dueño de la aplicación | 5 min | 26 |
| 10 | Decisión: seguir o rollback | — | 26 |
| 11 | Habilitar el acceso de usuarios | 1 min | 27 |
Media hora, no un fin de semana. Y todos esos tiempos salen del ensayo previo, no de una estimación.
El paso 6 no es opcional. Si la VM origen vuelve a encenderse por accidente con la red conectada, tenés dos máquinas con la misma IP y el mismo nombre escribiendo en los mismos sistemas. Es un incidente peor que el que estabas evitando.
El punto de no retorno
Es el momento a partir del cual volver atrás implica perder datos: cuando los usuarios ya escribieron en el destino.
Tiene que estar definido, escrito y comunicado antes de empezar. Habitualmente es el paso 11, cuando se habilita el acceso.
Antes de ese punto, el rollback es gratis. Después, cuesta.
Rollback
Antes del punto de no retorno
- Apagar la VM destino
- Reconectar la red de la VM origen
- Encender la VM origen
- Verificar servicios
- Comunicar
Cinco a quince minutos. Por eso el origen se conserva.
Después del punto de no retorno
Ya hay datos nuevos en destino. Las opciones, en orden de preferencia:
- Arreglar hacia adelante. Casi siempre es lo correcto: identificar el problema puntual y resolverlo.
- Rollback con pérdida acotada: volver al origen y reingresar manualmente lo que se hizo en el intervalo. Viable si fueron pocas horas.
- Rollback con exportación de datos: extraer los datos nuevos del destino e importarlos en el origen. Complejo y específico de cada aplicación.
La opción 1 gana en la mayoría de los casos reales. Por eso el criterio de aceptación del paso 9 tiene que ser exigente: es la última oportunidad barata de decir que no.
Quién decide
Una sola persona, designada de antemano. En el paso 10 no hay debate: hay una decisión.
| Rol | Responsabilidad |
|---|---|
| Responsable del corte | Toma la decisión de seguir o volver |
| Infraestructura | Ejecuta la secuencia técnica |
| Dueño de la aplicación | Valida funcionalmente en el paso 9 |
| Mesa de ayuda | Comunica a los usuarios |
Si el dueño de la aplicación no está disponible durante la ventana, el corte se reprograma. Sin validación funcional, nadie puede decidir con fundamento.
Errores en la ventana
- No desconectar la red del origen. El más peligroso de todos.
- Forzar el apagado en vez de shutdown ordenado: sistema de archivos sucio y sorpresas al arrancar.
- Saltear el checksum porque "ya sincronizamos tres veces".
- No tener al dueño de la aplicación, y validar solo que la VM ping-ea.
- Habilitar usuarios antes de validar. Cruzás el punto de no retorno sin saber si funciona.
- Extender la ventana sobre la marcha. Si no entró en el tiempo previsto, algo salió mal: rollback y reprogramar.
Ese último es el más difícil de sostener, y el que más problemas evita. La disciplina de volver atrás cuando el reloj se pasó es lo que hace que un proyecto sea previsible.
Preguntas frecuentes
¿Cuánto margen le doy a la ventana?
El doble del tiempo ensayado. Si el ensayo dio 30 minutos, pedí una hora. Terminar antes nunca es un problema.
¿Conviene cortar de madrugada?
No necesariamente. Con ventanas de 30 minutos, muchas cargas se pueden cortar en horario laboral de baja actividad, y tenés al equipo despierto y a los usuarios disponibles para validar. Es mejor que las 3 de la mañana.
¿Cuánto tiempo conservo la VM origen?
Dos semanas apagada como mínimo. Un mes para cargas críticas o con procesos de fin de mes.
¿Y si el rollback también falla?
Por eso el backup del origen, reciente y probado, está en la lista previa. Es la última red.
En resumen
El corte es una coreografía ensayada: secuencia con tiempos medidos, un responsable, un punto de no retorno explícito y un rollback probado. La regla que sostiene todo lo demás es apagar el origen sin borrarlo.
El marco completo de la migración incremental está en el artículo pilar.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.