Restic: Rclone hace que la mayoría de los backends sean redundantes

Esto ni siquiera tiene sentido. Rclone es una utilidad de transferencia, no una utilidad de respaldo. No puede reemplazar los repositorios restos.

Probablemente solo se refiera a deshacerse del propio código de backends de restic, excepto el de rclone, para que la integración de rclone se convierta en la que atraviesan todos los backends.

@jtagcat Creo que te refieres a "backends" en lugar de "repositorios".

Estoy de acuerdo con esta propuesta en espíritu.
En realidad, eliminar todos los demás backends puede resultar demasiado perjudicial, pero al menos la documentación puede destacar a rclone como el backend preferido y etiquetar otros backends remotos como "heredados".

De hecho, creo que podemos hacerlo mejor y luego marcar los backends como heredados.
En los documentos, márquelos como heredados, pero en las obras internas, traduzca legacy a rclone sobre la marcha. En algunos backends de rclone, puedes traducir directamente ( un ejemplo de la parte superior de mi cabeza es http ), otros los traduces a un archivo de configuración temporal, luego usas --config /path/to/config con rclone.

Si me preguntas como usuario de restic, diría que tener que usar rclone para todos los backends sería horrible. Requiere configurar rclone configs para sus backends y mantener un binario rclone, el primero que elimina en gran medida la naturaleza ad-hoc y libre de configuración de restic que es realmente agradable. Lo único que no me gusta de rclone es que tengo que configurarlo antes de ejecutarlo, en lugar de solo poder darle dos URI como origen y destino.

Una sugerencia mejor, en mi opinión, es si pudiéramos incrustar rclone en restic, de modo que pueda seguir usando restic de la misma manera que lo hace ahora, pero con el soporte de backend que proporciona rclone. Si eso sucediera, estaría bien deshacerse del código de backend actual asumiendo que el código rclone correspondiente proporciona las mismas características.

¿Cómo incrustarías rclone en restic? Si esta cuestión se iba a cerrar de forma positiva, tendría que hacerse.
¿Sería como 'rclone no encontrado, ejecutando curl https://rclone.org/install.sh | sudo bash ' (curl y sudo podrían no existir en el sistema)? Porque no puede simplemente agregarlo como una dependencia en los administradores de paquetes, si no está instalando a través de un administrador de paquetes.

La traducción de backends actuales para configuraciones rclone temporales sobre la marcha es posible, cuando se utiliza exclusivamente para la materia rclone, estoy un poco molesto por eso mismo también.

¿Cómo incrustarías rclone en restic?

No he investigado qué es posible en ese sentido. Es algo en lo que he pensado varias veces.

Pensándolo un poco más, la incrustación probablemente terminaría como 'instalar como una dependencia', para permitir que rclone esté actualizado sin necesidad de actualizar restic.
Probablemente la mejor manera sería agregar rclone como una dependencia, donde sea posible y tener 'rclone not found, instalándose' en todas partes (cuando la dependencia rclone no se encuentre por alguna razón, como respaldo).

Aunque el instalador de rclone presenta algunos problemas. Hágalo compatible con Posix.

• curl: he visto uno o dos sistemas, en los que no estaba instalado de fábrica.
• sudo - igual que arriba
• descomprimir / descomprimir otra cosa, probablemente haya experimentado esto, al instalar rclone en una instalación mínima.

Estoy pensando más en términos de hacer rclone incrustable como una biblioteca o lo que sea para que pueda integrarse en restic. No debería ser un problema lanzar una nueva versión restic cuando hay algo en rclone que se actualiza en la medida en que justifica una nueva versión.

Probablemente la mejor manera sería agregar rclone como una dependencia, donde sea posible y tener 'rclone not found, instalándose' en todas partes (cuando la dependencia rclone no se encuentre por alguna razón, como respaldo).

Lamento decir eso, pero intentar instalar (automáticamente) software en la máquina del usuario es (probablemente) la peor idea que he leído en las discusiones sobre problemas de restic.

Porque:

• Es posible que el entorno no permita la instalación de software nuevo.
• Es posible que el usuario (o el administrador del sistema) no desee que se instale un nuevo software.
• El acceso a Internet sin una solicitud explícita puede ser indeseable.
• El instalador puede adivinar un lugar incorrecto para el nuevo software.
• La instalación de nuevo software puede interferir con las funciones normales del entorno (por ejemplo, al proporcionar ejecutables fuera de los lugares habituales donde los usuarios / gestores de paquetes / administradores / auditores / cualquier otra cosa esperan encontrarlos, creando así confusión).
• La instalación puede fallar o producir resultados incorrectos; ya sea de una manera obvia, o de una manera sutil y difícil de descubrir.

Probablemente la mejor manera sería agregar rclone como una dependencia, donde sea posible y tener 'rclone not found, instalándose' en todas partes (cuando la dependencia rclone no se encuentre por alguna razón, como respaldo).

Lamento decir eso, pero intentar instalar (automáticamente) software en la máquina del usuario es (probablemente) la peor idea que he leído en las discusiones sobre problemas de restic.

Porque:

* The environment may not allow installation of new software.

* The user (or the system administrator) may not want new software to be installed.

* Accessing the Internet without explicit request may be undesirable.

* The installer may guess a wrong place for the new software.

* Installation of new software may interfere with the normal functions of the environment (for example, by providing executables outside of regular places where users/package managers/administrators/auditors/whatever else expect to find them, and thus creating confusion).

* The installation may fail or produce incorrect results; either in an obvious manner, or in a subtle and hard-to-discover way.

si, que sugieres?

lo que quise decir fue así:

restic rclone not found...
Install 'rclone' with command 'curl https://rclone.org/install.sh | sudo bash'  to provide rclone backends? [Y/n]

No reemplazaría los backends existentes con rclone, a menos que este último se incruste correctamente como biblioteca y, por lo tanto, siempre se incluya en la distribución de restic.

Hasta que se haga esto (o en lugar de hacerlo), haría de rclone una dependencia opcional en los administradores de paquetes que lo permitan (por ejemplo, apt y portage). Si rclone no está instalado, restic podría mostrar un mensaje que hace referencia a la página web de rclone, sugiriendo (1) consultar la página para conocer las formas de instalación, (2) instalar rclone usando el administrador de paquetes del sistema, (3) emitir el "curl + comando bash ", con una advertencia de que" asegúrese de saber lo que está haciendo ".

No ejecutaría el comando en nombre del usuario, incluso después de preguntar al respecto.

La naturaleza de RESTIC (especialmente en Linux) como un binario estático sin dependencias ha sido ABSOLUTAMENTE INVALUABLE en escenarios de restauración y recuperación bare-metal.

Actualmente prefiero usar el "servidor de descanso" (con interfaz haproxy para la autenticación) para las copias de seguridad internas y dependo de que restic lo soporte de forma nativa. Si me viera obligado a meterme con RESTIC y RCLONE durante una restauración de tiempo crítico, probablemente encontraría otra solución.

La naturaleza de RESTIC (especialmente en Linux) como un binario estático sin dependencias ha sido ABSOLUTAMENTE INVALUABLE en escenarios de restauración y recuperación bare-metal.

Actualmente prefiero usar el "servidor de descanso" (con interfaz haproxy para la autenticación) para las copias de seguridad internas y dependo de que restic lo soporte de forma nativa. Si me obligara a meterme con RESTIC y RCLONE durante una restauración de tiempo crítico, probablemente encontraría otra solución.

El backend de descanso no se eliminaría, ya que es exclusivo de Restic. Yo también uso rest-server, es muy conveniente colocar las credenciales.

Creo que el problema está en el estado de 'solo, si rclone está integrado'. Como nadie realmente necesita esto (aunque rclone incrustado estaría bien). Supongo que en este momento, es más 'no agregue nuevos backends, lo que ya no es compatible con rclone', y una solicitud de función para alguien (probablemente en muchos, muchos meses, yo), que se moleste en hacer esto, incrustar rclone .

En cuanto a lo básico, es necesario obtener versiones alternativas que no utilicen bzip (por lo que he oído, la única razón para instalar bzip es restic). En cuanto a eso, si nadie más lo hace, probablemente yo lo haga, ya que un todo para mí es # 2705

Lo único que no me gusta de rclone es que _ tengo_ que configurarlo antes de ejecutarlo, en lugar de solo poder darle dos URI como origen y destino.

@rawtaz
Usted es capaz de hacer eso ya rclone no le requiere que configurar nada.
Puede eliminar por completo cualquier _ ~ / .rclone.conf_ o _ ~ / .config / rclone / rclone.conf_, solo se consultan para conocer los valores predeterminados o las opciones de respaldo.
Ahora prueba esto:

rclone copy ./file.txt :sftp:subdir --sftp-host=localhost --sftp-key-file=~/.ssh/id_rsa

Es perfectamente válido y se describe en los documentos: https://rclone.org/docs/#backend -path-to-dir

También puede pasar todas las opciones a través del entorno o mezclarlas con argumentos CLI:

export RCLONE_SFTP_HOST=localhost
export RCLONE_SFTP_KEY_FILE=~/.ssh/id_rsa
rclone ls :sftp:

El uso de rclone como biblioteca se analiza en https://github.com/rclone/rclone/issues/633