Guía de migración de Borg Backup para trasladar un repositorio a un nuevo almacenamiento

El enfoque seguro consiste en pausar los procesos de escritura, copiar o transferir mediante el método adecuado para la versión, verificar el destino y realizar el cambio con posibilidad de reversión como una secuencia de comprobaciones observables, no como un único comando.

En un repositorio de BorgBackup almacenado localmente, en un NAS o en almacenamiento accesible mediante SSH, el riesgo práctico consiste en mover un repositorio de Borg sin crear una copia dividida o incompleta de forma silenciosa. Registra la identidad actual y el punto de recuperación, empieza por el criterio menos invasivo, interpreta los resultados satisfactorios y fallidos antes de cambiar otra variable y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable quede expuesta. El flujo de trabajo siguiente solo termina cuando la carga de trabajo original funciona correctamente o las pruebas llegan a un límite que requiere escalación.

Registra el contrato del repositorio antes de copiar

Guarda la versión de Borg, la URL del repositorio, el ID del repositorio, el modo de cifrado, la ubicación de la clave, el proceso de recuperación de la frase de contraseña, la lista de archivos, el tamaño, el espacio libre, la configuración de solo adición y cada cliente o tarea automatizada que pueda escribir. El repositorio no se puede recuperar únicamente a partir de una caché local, y los repositorios cifrados pueden depender de material de clave almacenado fuera del destino.

El artículo de ZimaSpace sobre una guía de recuperación tras perder la caché de Borg diferencia el estado de la caché, que se puede reconstruir, de las claves ausentes o los daños en el repositorio. Realiza esa comprobación antes de la migración para no descubrir un problema con la clave solo después de que el almacenamiento antiguo haya desaparecido.

Decide si se trata de una reubicación byte por byte del mismo repositorio o de una transferencia a un repositorio recién inicializado. La versión y el formato de Borg determinan qué métodos existen; no mezcles ejemplos de comandos de Borg 1 y Borg 2 ni des por hecho que la identidad del repositorio debe cambiar.

Pausa las escrituras y crea un punto de origen coherente

Desactiva los temporizadores, las tareas cron, los contenedores y los clientes remotos; después, confirma que no haya ningún proceso de Borg ni bloqueo del repositorio activo. Ejecuta borg list y un borg check adecuado antes de copiar. Si la comprobación del origen falla, consérvalo y diagnostica esa condición en lugar de clonar la incertidumbre en el destino.

Un debate de Super User destaca el riesgo de copiar un repositorio activo con rsync mientras cambia un repositorio de Borg deduplicado. La regla segura es copiar un repositorio cuyo acceso de escritura esté pausado o utilizar una instantánea del sistema de archivos tomada después de detener todas las escrituras de Borg, para que los índices, segmentos, el estado de los nonces y los datos pertenezcan a un mismo punto.

Mantén desactivadas las programaciones de copia de seguridad hasta que termine la validación del destino. Si el tiempo de inactividad es demasiado largo, realiza una copia inicial mientras el repositorio esté inactivo, detén las escrituras y ejecuta después una sincronización final; nunca permitas que el origen y el destino acepten copias de seguridad independientes durante el cambio.

Copia mediante el método compatible con tu versión de Borg

Para reubicar el mismo repositorio, conserva todos los archivos, permisos, el comportamiento de los archivos dispersos y la propiedad mediante una herramienta de copia local o remota adecuada, y revisa su registro de errores. Copia la raíz del repositorio como una unidad, no archivos seleccionados ni directorios de datos aparentemente grandes. Mantén intacto el origen después de la sincronización final.

Para crear un repositorio nuevo o migrar de formato, utiliza la capacidad de transferencia solo cuando sea compatible con las versiones instaladas de Borg y con el plan de cifrado. Una respuesta de Server Fault describe la transferencia de repositorios de Borg como el flujo de repositorio a repositorio asociado con Borg 2, que no es intercambiable con una copia del sistema de archivos de Borg 1.

Después de copiar, monta o expón inicialmente el destino a los clientes en modo de solo lectura. Si el ID del repositorio, el acceso a la clave, los permisos o el formato no son los esperados, detente y corrige el destino; no lo «inicialices» sobre los datos copiados ni ejecutes una reparación para forzar su reconocimiento.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica los archivos, cambia los clientes y conserva la posibilidad de reversión

Ejecuta borg list, borg info y las comprobaciones adecuadas del repositorio y los archivos en el destino. Extrae archivos de prueba de un archivo reciente y de otro antiguo en un directorio independiente; después, compara el contenido, los metadatos y los permisos. Realiza la prueba con el mismo binario de Borg y la misma ruta remota que utilizará la automatización.

Actualiza un cliente para que utilice la nueva URL, borra o reconstruye únicamente el estado de la caché que Borg identifique como necesario y crea un archivo de prueba pequeño. Restaura ese archivo y confirma que la programación de poda o compactación siga desactivada hasta que todos los clientes utilicen la nueva ubicación.

El cambio se considera correcto cuando el inventario de archivos coincide, las comprobaciones se completan correctamente, dos restauraciones son utilizables y una nueva copia de seguridad se realiza correctamente después de reiniciar el sistema o el programador. Mantén el origen en modo de solo lectura durante al menos un ciclo normal; elimínalo únicamente cuando venza el plazo de reversión o escala el problema si las comprobaciones difieren entre el origen y el destino.