Migre datos de VPS de forma segura con rsync

Inventariar antes de copiar

Enumerar archivos de la aplicación, propietarios, ACL, atributos extendidos, bases de datos, secretos, tareas programadas, servicios, reglas de firewall, DNS, certificados y almacenamiento externo. Confirmar que existe suficiente capacidad de destino y compatibilidad de usuarios, sistemas de archivos, paquetes del sistema operativo y versiones de la aplicación. Reducir el TTL de DNS antes de la transición final solo cuando dicho cambio se ajuste a su plan de DNS; los registros en caché pueden persistir más tiempo de lo previsto.

Cree y verifique una copia de seguridad independiente del origen. Mantenga el origen inalterado y disponible durante la transferencia inicial. Defina criterios de éxito y una decisión de reversión antes de anunciar una ventana de mantenimiento.

• No copie sistemas de archivos virtuales como /proc, /sys, /dev o /run como si fueran datos ordinarios.
• Utilice herramientas nativas de copia de seguridad, replicación o volcado de bases de datos cuando proceda.
• Nunca incluya claves privadas en el historial de comandos ni en notas compartidas.

Prepare los datos de la aplicación realizando una ejecución de prueba (*dry run*).

Para un directorio como /srv/app/, pruebe la operación desde el origen con sudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/. Sustituya el usuario, la ruta de la clave, el destino y las rutas de los datos. La barra diagonal final indica que se debe copiar el contenido del directorio de origen en lugar de crear un nivel de directorio adicional.

Revise todas las rutas y errores. Asegúrese de que la cuenta remota pueda escribir en el destino de forma segura; iniciar sesión como *root* es innecesario y a menudo está deshabilitado. Cuando la salida de la ejecución de prueba sea correcta, repita el comando sin --dry-run. No añada --delete simplemente para igualar los directorios: un origen o destino incorrecto podría eliminar datos valiosos.

• Ejecute el comando dentro de una sesión de terminal persistente para transferencias de gran tamaño.
• Limite el ancho de banda si la copia pudiera afectar al tráfico de producción.
• Registre las opciones del comando y las versiones de las herramientas en el historial de la migración.

Suspenda las operaciones de escritura y realice la pasada final.

Ponga la aplicación en un estado de mantenimiento o de solo lectura documentado. Detenga exactamente los servicios que realizan escrituras mediante el procedimiento admitido y, después, haga la copia de seguridad final de la base de datos o complete la replicación. Vuelva a ejecutar el mismo comando rsync para transferir únicamente los datos de archivos modificados. Mantenga el estado de mantenimiento hasta finalizar la validación.

Inicie los servicios en el destino con la configuración prevista; restrinja inicialmente el acceso público si es posible y realice comprobaciones de estado, inicio de sesión, escritura, colas, certificados, registros y dependencias. Actualice el DNS o el enrutamiento solo después de superar dichas pruebas. Evite cambiar la versión de la aplicación y la ubicación de alojamiento en la misma ventana de mantenimiento, a menos que se acepte explícitamente el riesgo combinado.

• Registre la hora exacta en que cesó la escritura y el resultado de la sincronización.
• Valide la propiedad de los archivos y los controles de acceso obligatorio.
• Supervise los puntos de conexión antiguos y nuevos durante la transición del DNS.

Verifique, observe y conserve el procedimiento de reversión (rollback).

Para una comparación de archivos más exhaustiva, ejecute el comando rsync original con --checksum --dry-run durante una ventana de tiempo adecuada; la verificación mediante sumas de comprobación (*checksums*) lee ambos conjuntos de datos y puede consumir muchos recursos. Para bases de datos y almacenes de objetos, es preferible utilizar comprobaciones de integridad a nivel de aplicación. Supervise los errores, la latencia, el uso de recursos, las tareas en segundo plano y las devoluciones de llamada (*callbacks*) externas tras la migración definitiva (*cutover*).

Mantenga intacto el origen, pero impida escrituras que provoquen una situación de *split-brain* (inconsistencia por escritura simultánea en ambos sistemas) hasta que finalice el periodo de reversión (*rollback*). A continuación, siga el plan de retención y eliminación segura. La migración solo se considera completa cuando las copias de seguridad, la supervisión, la documentación y los procedimientos de recuperación hacen referencia al destino.