Restic: copia de seguridad a múltiples destinos al mismo tiempo

¿Por qué en una carrera? ¿Por qué no puedes hacer una copia de seguridad dos veces con diferentes destinos?

Si los datos subyacentes cambian, es posible que no obtenga exactamente las mismas instantáneas.

Eso me parece un riesgo aceptable... No vale la pena la complejidad adicional que esto agregaría al código base, en mi humilde opinión. Pero tal vez estoy sobreestimando esto.

Ya he pensado en tener algo como una función de "sincronización" que pueda copiar datos de un repositorio a otro, tal vez eso sea interesante...

Sería bueno poder agrupar una copia de seguridad en múltiples destinos con espacio limitado, pero a menudo desea pasar el menor tiempo posible cargando la copia de seguridad desde sus máquinas principales (especialmente si se trata de una computadora portátil o una máquina de producción que necesita manejar recursos). carga). Sería útil un demonio de replicación con reconocimiento de firmas/capacidades que pudiera realizar operaciones de equilibrio de solo anexar o "mantener los más nuevos, purgar los objetos innecesarios".

Creo que el n.° 256 sobre ECC podría ser relevante para la discusión de los casos de uso de esta función.

Esta solicitud de función podría ser reemplazada por #323

@fw42

¿Por qué en una carrera? ¿Por qué no puedes hacer una copia de seguridad dos veces con diferentes destinos?

Como mencionó fd0, es esencialmente porque solo quiero _una_ copia de seguridad en dos lugares diferentes; Quiero _una_ instantánea, no dos. Sin embargo, otra razón es porque no quiero usar toda la CPU para dos copias de seguridad cuando solo una es suficiente.

@fd0 : si me lo permite, me gustaría intentar implementar esto, si no es demasiado difícil. Aunque necesitaría alguna orientación. ¿Qué crees que estará involucrado?

Mientras pienso en esto, me pregunto si es posible hacerlo de manera confiable. Por supuesto, es posible si los múltiples destinos/repositorios de back-end están en el mismo estado _exactamente_, entonces es muy fácil. Pero si, por alguna razón, uno de los repositorios está en un estado diferente, por ejemplo, la red estaba inactiva, por lo que solo se realizó una copia de seguridad del destino local la última vez, entonces me pregunto si es posible hacer una copia de seguridad de los dos. destinos "al mismo tiempo" incluso vale la pena. ¿Tiene sentido? Restic estaría comparando dos conjuntos diferentes de diferencias y realizando esencialmente operaciones de copia de seguridad duales, y combinarlas en una sola invocación suena complicado. ¿Qué piensas?

Pero si es posible lograr que los repositorios sean idénticos antes de comenzar con la parte "difícil" o "costosa" de la copia de seguridad, ¿quizás valdría la pena? ¿Puedo obtener sus pensamientos sobre esto?

Me gustaría investigar primero si esto se puede lograr con solo rclone. Realice una copia de seguridad en un backend (por ejemplo, local), luego sincronice los cambios con todos los demás. Entonces terminará con instantáneas y datos idénticos.

Cuando sincroniza eliminaciones de archivos, también puede ejecutar forget y prune en su backend local y sincronizar los cambios con los otros backends.

Es un proceso de dos pasos, pero se mantendrá mucho más simple, y no puedo ver ninguna desventaja...

@ fd0 Lo apoyaría completamente. He estado pensando más en esto y estoy de acuerdo, no veo por qué Restic debería intentar hacer esto. Si los repositorios son diferentes, serán efectivamente dos copias de seguridad diferentes de todos modos.

Siempre que rclone también se pueda usar en una configuración de proxy similar a restic -> rclone -> backend (y para el segundo paso de sincronización, sería rclone -> rclone -> backend entonces creo que estaríamos bueno para ir.

Ya estoy haciendo esto manualmente cuando ejecuto copias de seguridad automáticas en un destino local y luego las sincronizo con la nube (menos el proxy, ¡pero lo necesitaré para los miembros de mi familia!), así que sé que funciona. Una buena pregunta a considerar es si la sincronización debe ocurrir justo ANTES o justo DESPUÉS de que se realice una copia de seguridad.

Si rclone puede pasar a otra instancia de sí mismo y estamos de acuerdo con el proceso de dos pasos, entonces estoy de acuerdo con cerrar este problema. :+1:

Editar: si esto va por la ruta rclone , y creo que lo hará, podría ser bueno que los documentos tengan una entrada de preguntas frecuentes sobre la forma recomendada de hacer esto.

Hm. No estoy seguro de que estemos hablando de lo mismo aquí. Mi sugerencia fue:

• Haz una copia de seguridad en local:/srv/backup
• Use rclone (localmente) para sincronizar /srv/backup con S3 y B2

Cuando rclone se ejecuta en otro lugar, es un poco diferente:

• Ejecute localmente restic backup rclone:/foo , en el otro extremo en un servidor esto ejecuta rclone serve restic /data/storage/repo
• En el servidor, a través de cron, llama a rclone copy /data/storage/repo b2:bucketname:/ y luego a rclone copy /data/storage/repo s3:otherbucket:/

Entonces terminará con tres copias del repositorio, una en su servidor, una en S3 y otra en B2.

Si desea que las personas puedan acceder a los repositorios en la nube, bríndeles una forma de acceder a un proceso rclone iniciado con el control remoto correcto, como rclone serve restic s3:otherbucket:/ .

No estoy seguro de lo que quieres decir con rclone -> rclone -> backend ...

Tal vez sea útil discutir la situación concreta que le gustaría resolver en el foro más o menos.

Claro, lo publicaré en el foro, aunque, dado que se trata de rclone, lo publiqué en el foro de rclone: ​​https://forum.rclone.org/t/proxying-through-a-remote-rclone- instancia/5318/1

Básicamente, mi escenario es su primera sugerencia:

• Hacer una copia de seguridad en local:/srv/backup
• Use rclone (localmente) para sincronizar /srv/backup con S3 y B2

Excepto que usar rclone localmente para sincronizar directamente con S3 y B2 requiere que rclone tenga credenciales, que en este caso, la computadora que realiza la copia de seguridad no puede tener acceso a las credenciales. Por lo tanto, necesito una forma de rclone a otro rclone remoto que _sí_ tenga las credenciales.

Su segunda sugerencia casi hace lo que necesito, excepto que implica que el servidor almacene la copia de seguridad antes de copiarla en B2 y S3. Si bien eso podría ser deseable para algunos, estoy tratando de evitar un lugar de almacenamiento intermedio.

¡Gracias de nuevo! Espero que aclare algo de mi caso de uso.

Oigan todos,

así que también me gustaría mucho la característica de tener múltiples repositorios para una sola ejecución.

Las razones son:

• escenario "copia de seguridad restic al servidor de copia de seguridad y rclone desde allí" : no necesariamente confío en la ubicación de copia de seguridad uno o dos. Cualquiera de ellos podría tener un disco duro corrupto, un conjunto de chips de red, un ransomware para cifrar todos mis datos sobre la marcha, etc.
• el escenario "hacer una copia de seguridad restic local y luego rclone" simplemente no funciona debido al espacio limitado en el disco. También nuevamente la pregunta: ¿qué sucede si el ransomware codifica toda la copia de seguridad y no me doy cuenta antes de volver a clonar? ¿Destruiré simultáneamente ambas copias de seguridad remotas?
• por último: todavía me gustaría abordar el tema #16.
  Sin embargo, debido a las razones mencionadas anteriormente y también a la idea de que una configuración con múltiples repositorios podría hacer _todo_ el trabajo (en lugar de que yo tenga que crear otro script que luego encadenará rclone a restic), creo que esto debería hacerse antes.

Trataré totalmente de crear un PR, pero quería asegurarme de que no fuera un trabajo discutible, así que me gustaría escuchar su opinión primero @fd0 y otros.

salud :)

Cerrar esto como el nuevo comando copy se puede usar para sincronizar instantáneas entre repositorios, lo que también verifica la integridad de la instantánea mientras lo hace. Para limpiar las instantáneas, por ejemplo, es posible simplemente ejecutar forget --keep-something 42 ... para ambos repositorios. El uso activo de varios repositorios en una sola ejecución de copia de seguridad se trata en el n.º 679.

@mholt Si esto sigue siendo relevante, para su caso de uso, restic -o rclone.program="ssh remote-host rclone" -r rclone:target-path-passed-to-rclone podría funcionar (posiblemente usando un comando forzado en el lado del servidor).