Restic: Agregar comando para copiar todos los datos a otro repositorio

¿Está destinado a manejar una copia única de un repositorio (A) a uno nuevo (B)? ¿O se pretende que sea más general al realizar una "sincronización" o actualización del contenido cambiado entre (A) y (B) desde la última sincronización?

Por el momento, esto está destinado a manejar una copia única, de modo que los usuarios puedan migrar a un repositorio diferente en una ubicación diferente, o con una nueva clave maestra.

Dada una conexión a Internet lenta, me gustaría tener la posibilidad de hacer una copia de seguridad en s3 y en otra ubicación de la manera más eficiente posible.

@witeshadow No estoy seguro de cómo se puede hacer eso de manera eficiente, ya que los datos están encriptados en el repositorio A con el maestro A ', y es necesario hacerlo para el repositorio B con una clave maestra B' diferente. Necesitamos leer todos los datos, descifrar con A`, cifrar con B` y escribir. No hay forma de optimizar esto para un ancho de banda lento. Va a doler...

la única optimización que puedo pensar es tener un criterio de selección en el repositorio de origen A, mediante el uso de los filtros de host, ruta y etiquetas para que no tenga que copiar todo. Sin embargo, eso depende de su caso de uso.

@ fd0 Solo quería agregar mi voto para esta solicitud de función. ¿Hay algo que pueda hacer para que esto suceda?

Podrías implementarlo ... La funcionalidad en sí no es difícil de hacer, configurar los dos backends es lo difícil. No admitimos el acceso a más de un backend (p. Ej., Solo hay un $B2_ACCOUNT_ID ) ... así que creo que esta función depende de un archivo de configuración adecuado (consulte el n. ° 16).

Digamos que tenemos dos repositorios, A y B, y le gustaría sincronizar A-> B para que una vez finalizado el proceso, el conjunto de blobs (e instantáneas) en B sea un superconjunto del conjunto de blobs en A .

Entonces, abre ambos repositorios y carga los archivos de índice para cada uno. Luego, itera sobre el índice de A, para cada blob, verificando si el blob también está contenido en B. Si esto es cierto, continúe con el siguiente. Si es falso, descárguelo, descifre, cifre y cárguelo en B.

Lo último es copiar los archivos de instantáneas. Para cada archivo de instantánea en A, descifre el archivo, vuelva a cifrarlo para B, guárdelo allí y listo.

Como dije, la implementación técnica es bastante fácil :)

¡Excelente! Gracias por los consejos. Tengo esta picazón, así que veré si puedo hacer tiempo para rascarme, pero a corto plazo tendré que ir sin esta función restic merge . Si alguien llega antes que yo, está bien, ¡o volveré a esto eventualmente!

Creo que ya lo tengo implementado ... / me rasco la cabeza y lo busca ...
... https://github.com/middelink/restic/tree/fix-323
Sin embargo, necesito verificar si todavía se compila, esa rama tiene 228 confirmaciones detrás ...

Puede resultar útil permitir no solo una copia completa, sino también un subconjunto de instantáneas. Esto respaldaría un caso de uso sugerido por # 1910 (respaldo a un repositorio principal a menudo, y desde allí respaldo al almacenamiento externo / más lento / más costoso con menos frecuencia) y, creo, no sería mucho más difícil de implementar que una copia completa. Sin embargo, podría ser una adición futura :-)

Err… ¿Alguna noticia para que los usuarios sin habilidades de desarrollo compilen y prueben la sugerencia de @ middelink?

Este es principalmente un comentario de "yo también", pero me gustaría tener la capacidad de copiar solo instantáneas específicas de un repositorio a otro, en lugar de una semántica de "copiar todo" o "sincronizar"; por ejemplo, realice copias de seguridad diarias en el almacenamiento local, luego una vez a la semana copie solo la más reciente a diario en un depósito s3, etc.

Bueno, entonces estás de suerte, mi copia cmd toma uno o más identificadores de instantáneas. De hecho, copiar todo no es algo que haga. Primero tendría que enumerar sus ID de instantáneas y luego concatenarlos en la línea de cmd de "copia resticulada". Como veo esto como un caso de uso degenerado, estoy bien con eso.

Sin profundizar demasiado en esto, quizás algunas discusiones con ncw / rclone podrían ser útiles ...

También estoy interesado en la funcionalidad de fusionar / copiar, tengo un repositorio en una memoria USB que me gustaría fusionar / copiar en mi repositorio central (mismas contraseñas).
¿Alguna noticia sobre esto?

Parece que la rama de la master , pero aún no hay un PR para ella.

@middelink ¿Su código está terminado / fusionable? Si no es así, ¿qué queda por hacer? Esta es una característica que realmente quiero :)

@ teórico2019 El código en sí está terminado, pero cada vez que me siento para crear un PR oficial, sigo encontrando cosas que necesito hacer antes de que esté listo. Como documentación, como un registro de cambios / inédito ...
¡Ah, y pruebas! ¿Mencioné pruebas? Necesita pruebas: P

@middelink Fyi, he probado su rama rebasando a master upstream y funciona bastante bien. Creó una nueva instantánea con el mismo host, etiquetas y fecha: +1:
Esperando PR: tada:

Ahora, con esta característica, puedo crear un repositorio secundario, que es utilizado por los clientes solo cuando el primer repositorio está bloqueado para mantenimiento (por ejemplo, podar). Y la tarea de podar puede activar una copia de la secundaria después de que finalice, por lo que no faltan copias de seguridad y, por lo tanto, no hay tiempo de inactividad en el servicio de copia de seguridad.

@middelink ¿Sería tan amable de crear un PR de su código? Al hacerlo, también permita las ediciones de los encargados del mantenimiento ; de esta manera, podemos ayudarlo con el registro de cambios, la documentación, etc.

Lo importante es que consigamos una base de relaciones públicas en la que trabajar. Me encantaría que tu gran trabajo se mueva, y creo que otros también :) ¡Avísame si necesitas ayuda para crear las relaciones públicas!

@rawtaz Seguro. Déjame sincronizar y todo eso. Por alguna razón, no he encontrado tiempo para hacerlo antes, pero parece que ahora tengo algo de tiempo.

¡Gracias a todos por su trabajo en esto!

Me queda una pregunta que no ha sido respondida por los documentos (al menos para mí): ¿Necesito podar ambos o es suficiente hacerlo en la fuente y se propagan las eliminaciones de instantáneas?

@lfrancke Cuando usa el copy , enumera específicamente las instantáneas que desea copiar. Otras, las instantáneas existentes, no existentes y previamente existentes, pero ahora eliminadas y que ya no existen, no son aplicables.

Si copia instantáneas del repositorio A al repositorio B y luego las olvida y las elimina en el repositorio A, no se olvidarán ni se eliminarán en el repositorio B automáticamente, tendrá que hacerlo usted mismo en el repositorio B.

Excelente, muchas gracias @rawtaz por la rápida y útil respuesta.