Restic: Rclone rendant la plupart des backends redondants

Cela n'a même pas de sens. Rclone est un utilitaire de transfert, pas un utilitaire de sauvegarde. Il ne peut pas remplacer les référentiels restic.

Il veut probablement simplement abandonner le code des backends de restic, à l'exception de celui de rclone, afin que l'intégration de rclone devienne celle par laquelle tous les backends passent.

@jtagcat Je pense que vous voulez dire "backends" au lieu de "dépôts".

Je suis d'accord avec cette proposition dans l'esprit.
En fait, supprimer tous les autres backends peut être trop perturbateur, mais au moins les documentations peuvent mettre en évidence rclone comme backend préféré et étiqueter les autres backends distants comme « anciens ».

En fait, je pense que nous pouvons faire mieux, puis marquer les backends comme héritage.
Dans les documents, marquez-les comme héritage, mais dans les travaux internes, traduisez l'héritage en rclone à la volée. Sur certains backends rclone, vous pouvez directement traduire ( un exemple du haut de ma tête est http ), d'autres vous traduisez en un fichier de configuration temporaire, puis utilisez --config /path/to/config avec rclone.

Si vous me demandez en tant qu'utilisateur de restic, je dirais que devoir utiliser rclone pour tous les backends serait horrible. Cela nécessite de configurer des configurations rclone pour vos backends et de conserver un binaire rclone, le premier qui supprime beaucoup la nature ad hoc et sans configuration de restic qui est vraiment sympa. La seule chose que je n'aime pas à propos de rclone, c'est que je dois le configurer avant de l'exécuter, au lieu de simplement pouvoir lui donner deux URI comme source et cible.

Une meilleure suggestion IMO est que nous puissions intégrer rclone dans restic, de sorte que vous puissiez continuer à utiliser restic comme vous le faites maintenant, mais avec le support backend fourni par rclone. Si cela devait se produire, ce serait bien d'abandonner le code backend actuel en supposant que le code rclone correspondant fournit les mêmes fonctionnalités.

Comment intégreriez-vous rclone dans restic? Si cette question devait être résolue positivement, il faudrait le faire.
Seriez-vous comme « rclone introuvable, exécutant curl https://rclone.org/install.sh | sudo bash » (curl et sudo pourraient ne pas exister sur le système) ? Parce que vous ne pouvez pas simplement l'ajouter en tant que dépendance dans les gestionnaires de packages, si vous n'installez pas via un gestionnaire de pkg.

Il est possible de traduire les backends actuels en configurations de rclone temporaires à la volée, lorsque j'utilise purement rclone pour des trucs, cela me dérange un peu moi aussi.

Comment intégreriez-vous rclone dans restic?

Je n'ai pas étudié ce qui est possible à cet égard. C'est juste quelque chose auquel j'ai pensé quelques fois.

En y réfléchissant un peu plus, l'intégration se terminerait probablement par une «installation en tant que dépendance», pour permettre à rclone d'être à jour sans que restic ait besoin d'être mis à jour.
Le meilleur moyen serait probablement d'ajouter rclone en tant que dépendance, dans la mesure du possible et d'avoir 'rclone introuvable, installation' partout (lorsque la dépendance rclone n'est pas trouvée pour une raison quelconque, en tant que sauvegarde).

Bien que le programme d'installation de rclone présente quelques problèmes. Rendez-le compatible posix.

• curl - J'ai vu un système ou deux, où il n'a pas été installé hors de la boîte.
• sudo - comme ci-dessus
• unzip/autre chose de décompression, vous en avez probablement déjà fait l'expérience lors de l'installation de rclone sur une installation minimale.

Je pense plus à rendre rclone intégrable en tant que bibliothèque al ou autre afin qu'il puisse être intégré dans restic. La publication d'une nouvelle version restic ne devrait pas poser de problème lorsqu'il y a quelque chose dans rclone qui est mis à jour dans la mesure où cela justifie une nouvelle version.

Le meilleur moyen serait probablement d'ajouter rclone en tant que dépendance, dans la mesure du possible et d'avoir 'rclone introuvable, installation' partout (lorsque la dépendance rclone n'est pas trouvée pour une raison quelconque, en tant que sauvegarde).

Désolé de le dire, mais essayer d'installer (automatiquement) un logiciel sur la machine de l'utilisateur est (probablement) la pire idée que j'aie jamais lue dans les discussions sur les problèmes de restic.

Parce que:

• L'environnement peut ne pas permettre l'installation de nouveaux logiciels.
• L'utilisateur (ou l'administrateur système) peut ne pas vouloir installer de nouveau logiciel.
• L'accès à Internet sans demande explicite peut être indésirable.
• Le programme d'installation peut deviner un mauvais endroit pour le nouveau logiciel.
• L'installation de nouveaux logiciels peut interférer avec les fonctions normales de l'environnement (par exemple, en fournissant des exécutables en dehors des endroits habituels où les utilisateurs/gestionnaires de packages/administrateurs/auditeurs/tout ce qui s'attendent à les trouver, créant ainsi une confusion).
• L'installation peut échouer ou produire des résultats incorrects ; soit d'une manière évidente, soit d'une manière subtile et difficile à découvrir.

Le meilleur moyen serait probablement d'ajouter rclone en tant que dépendance, dans la mesure du possible et d'avoir 'rclone introuvable, installation' partout (lorsque la dépendance rclone n'est pas trouvée pour une raison quelconque, en tant que sauvegarde).

Désolé de le dire, mais essayer d'installer (automatiquement) un logiciel sur la machine de l'utilisateur est (probablement) la pire idée que j'aie jamais lue dans les discussions sur les problèmes de restic.

Parce que:

* 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.

oui, que proposez-vous ?

ce que je voulais dire était comme ça :

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

Je ne remplacerais pas les backends existants par rclone, à moins que ce dernier ne soit intégré avec succès en tant que bibliothèque, et donc toujours inclus dans la distribution de restic.

Jusqu'à ce que cela soit fait (ou au lieu de le faire), je ferais de rclone une dépendance facultative dans les gestionnaires de packages qui le permettent (par exemple, apt et portage). Si rclone n'est pas installé, restic peut afficher un message faisant référence à la page Web de rclone, suggérant soit (1) de consulter la page pour savoir comment installer, (2) d'installer rclone à l'aide du gestionnaire de packages du système, (3) d'émettre le "curl + bash", avec un avertissement "assurez-vous de savoir ce que vous faites".

Je n'exécuterais pas la commande au nom de l'utilisateur, même après avoir posé des questions à ce sujet.

La nature de RESTIC (en particulier sous Linux) en tant que binaire statique sans dépendances a été ABSOLUMENT INESTIMABLE dans les scénarios de restauration et de récupération sans système d'exploitation.

Je préfère actuellement utiliser le "rest-server" (avec l'interface haproxy pour l'authentification) pour les sauvegardes internes et dépendre de restic qui le prend en charge nativement. Si j'étais obligé de jouer avec RESTIC et RCLONE lors d'une restauration critique, je trouverais probablement une autre solution.

La nature de RESTIC (en particulier sous Linux) en tant que binaire statique sans dépendances a été ABSOLUMENT INESTIMABLE dans les scénarios de restauration et de récupération sans système d'exploitation.

Je préfère actuellement utiliser le "rest-server" (avec l'interface haproxy pour l'authentification) pour les sauvegardes internes et dépendre de restic qui le prend en charge nativement. Si j'étais _forcé_ de jouer avec RESTIC _et_ RCLONE lors d'une restauration critique, je trouverais probablement une autre solution.

Le backend Rest ne serait pas supprimé, car il est unique à Restic. J'utilise également rest-server, il est très pratique de simplement déposer les informations d'identification.

Je pense que le problème est dans l'état "seulement, si rclone est intégré". Comme personne n'en a vraiment besoin (bien qu'un rclone intégré soit nécessaire). Je suppose qu'en ce moment, c'est plus "n'ajoutez pas de nouveaux backends, ce qui n'est pas déjà pris en charge par rclone", et une demande de fonctionnalité pour quelqu'un (probablement dans de nombreux mois, moi), qui prend la peine de le faire, intégrez rclone .

En ce qui concerne le bare-bones, il faut sortir des versions alternatives, qui n'utilisent pas bzip (d'après ce que j'ai entendu, la seule raison d'installer bzip est restic). Quant à ça, si personne d'autre ne le fait, je le ferai probablement, car une tâche pour moi est #2705

La seule chose que je n'aime pas à propos de rclone, c'est que je dois le configurer avant de l'exécuter, au lieu de simplement pouvoir lui donner deux URI comme source et cible.

@rawtaz
Vous êtes en mesure de le faire que depuis rclone ne vous oblige pas à quoi que ce soit de configuration.
Vous pouvez supprimer complètement n'importe quel _~/.rclone.conf_ ou _~/.config/rclone/rclone.conf_, ils sont simplement consultés pour les valeurs par défaut ou les options de secours.
Essayez maintenant ceci :

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

C'est parfaitement valide et décrit dans la doc : https://rclone.org/docs/#backend -path-to-dir

Vous pouvez également passer toutes les options via l'environnement ou les mélanger avec des arguments CLI :

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

L'utilisation de rclone en tant que bibliothèque est discutée dans https://github.com/rclone/rclone/issues/633