Restic: バックエンドのほとんどを冗長にするRclone

これは意味がありません。 Rcloneは転送ユーティリティであり、バックアップユーティリティではありません。 Resticリポジトリを置き換えることはできません。

彼はおそらく、rcloneのコードを除いて、restic自身のバックエンドコードを捨てることを意味しているので、rclone統合はすべてのバックエンドが通過するものになります。

@jtagcat 「リポジトリ」ではなく「バックエンド」を意味していると思います。

私はこの提案に精神的に同意します。
実際には、他のすべてのバックエンドを削除するのは混乱を招く可能性がありますが、少なくともドキュメントでは、rcloneを優先バックエンドとして強調表示し、他のリモートバックエンドに「レガシー」のラベルを付けることができます。

実際、バックエンドをレガシーとしてマークすることで、もっとうまくやれると思います。
ドキュメントでは、それらをレガシーとしてマークしますが、内部の作業では、レガシーをオンザフライでrcloneに変換します。 一部のrcloneバックエンドでは、直接変換でき（頭のてっぺんからの例はhttpです）、他のrcloneバックエンドで--config /path/to/configを使用します。

あなたがresticのユーザーとして私に尋ねるなら、私はすべてのバックエンドにrcloneを使わなければならないのは恐ろしいことだと思います。 バックエンドのrclone構成をセットアップし、rcloneバイナリを保持する必要があります。前者は、非常に便利な、アドホックで構成不要のresticの性質を大幅に削除します。 私はrcloneについては好きではない一つのことは、私だけではなく、それをソースおよびターゲットとして2つのURIを与えることができるという、それを実行する前にそれを設定する必要があります。

IMOのより良い提案は、rcloneをresticに埋め込んで、今と同じようにresticを使い続けることができるかどうかですが、rcloneが提供するバックエンドサポートを使用します。 それが起こった場合、対応するrcloneコードが同じ機能を提供すると仮定して、現在のバックエンドコードを捨てることは問題ありません。

rcloneをresticにどのように埋め込みますか？ この問題を積極的に解決するためには、それを実行する必要があります。
'rclone not found、running curl https://rclone.org/install.sh | sudo bash '（curlとsudoがシステムに存在しない可能性があります）のようになりますか？ pkg managerを介してインストールしない場合は、パッケージマネージャーに依存関係として単純に追加することはできないためです。

現在のバックエンドをその場で一時的なrclone構成に変換することは可能です。純粋にrcloneを使用する場合、私自身も少しイライラします。

rcloneをresticにどのように埋め込みますか？

私はその点で何が可能かを調査していません。 それは私が数回考えただけのことです。

もう少し考えてみると、埋め込みはおそらく「依存関係としてインストールする」ことになり、rcloneを更新せずに最新の状態に保つことができます。
おそらく最善の方法は、可能であればrcloneを依存関係として追加し、「rcloneが見つからない、どこにでもインストールする」ことです（rcloneの依存関係が何らかの理由で見つからない場合、バックアップとして）。

rcloneインストーラーにはいくつかの問題がありますが。 posix互換にします。

• curl-箱から出してインストールされていないシステムを1つか2つ見たことがあります。
• sudo-上記と同じ
• 解凍/その他の解凍は、最小限のインストールでrcloneをインストールしているときに、おそらくこれを経験したことがあります。

rcloneをalライブラリなどとして埋め込み可能にして、resticに統合できるようにするという観点からもっと考えています。 新しいリリースを保証する範囲で更新された何かがrcloneにある場合、新しいresticバージョンをリリースすることは問題ではないはずです。

おそらく最善の方法は、可能であればrcloneを依存関係として追加し、「rcloneが見つからない、どこにでもインストールする」ことです（rcloneの依存関係が何らかの理由で見つからない場合、バックアップとして）。

申し訳ありませんが、ユーザーのマシンに（自動的に）ソフトウェアをインストールしようとすることは、（おそらく）私がresticの問題の議論で読んだ中で最悪の考えです。

なぜなら：

• 環境によっては、新しいソフトウェアをインストールできない場合があります。
• ユーザー（またはシステム管理者）は、新しいソフトウェアのインストールを望まない場合があります。
• 明示的な要求なしにインターネットにアクセスすることは望ましくない場合があります。
• インストーラーは、新しいソフトウェアの間違った場所を推測する可能性があります。
• 新しいソフトウェアのインストールは、環境の通常の機能を妨げる可能性があります（たとえば、ユーザー/パッケージマネージャー/管理者/監査人/他の人がそれらを見つけることを期待する通常の場所の外に実行可能ファイルを提供し、混乱を引き起こすことによって）。
• インストールが失敗するか、誤った結果が生じる可能性があります。 明白な方法で、または微妙で発見しにくい方法で。

おそらく最善の方法は、可能であればrcloneを依存関係として追加し、「rcloneが見つからない、どこにでもインストールする」ことです（rcloneの依存関係が何らかの理由で見つからない場合、バックアップとして）。

申し訳ありませんが、ユーザーのマシンに（自動的に）ソフトウェアをインストールしようとすることは、（おそらく）私がresticの問題の議論で読んだ中で最悪の考えです。

なぜなら：

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

はい、あなたは何を提案しますか？

私が意味したのはこのようなものでした：

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

後者がライブラリとして正常に埋め込まれ、したがって常にresticのディストリビューションに含まれていない限り、既存のバックエンドをrcloneに置き換えることはありません。

これが行われるまで（またはこれを行う代わりに）、これを許可するパッケージマネージャーのオプションの依存関係（aptやportageなど）をrcloneにします。 rcloneがインストールされていない場合、resticはrcloneのWebページを参照するメッセージを表示し、（1）インストール方法についてページを参照する、（2）システムのパッケージマネージャーを使用してrcloneをインストールする、（3）「curl + 「bash」コマンド。「自分が何をしているのかを確認してください」という警告が表示されます。

質問した後でも、ユーザーに代わってコマンドを実行することはありません。

依存関係のない静的バイナリとしてのRESTIC（特にLinux）の性質は、ベアメタル復元およびリカバリのシナリオでは絶対に無効です。

私は現在、社内バックアップに「rest-server」（認証にhaproxyフロントエンドを使用）を使用することを好み、それをネイティブにサポートするresticに依存しています。 タイムクリティカルな復元中にRESTICとRCLONEをいじることを余儀なくされた場合は、おそらく別の解決策を見つけるでしょう。

依存関係のない静的バイナリとしてのRESTIC（特にLinux）の性質は、ベアメタル復元およびリカバリのシナリオでは絶対に無効です。

私は現在、社内バックアップに「rest-server」（認証にhaproxyフロントエンドを使用）を使用することを好み、それをネイティブにサポートするresticに依存しています。 タイムクリティカルな復元中にRESTICとRCLONEをいじくりまわすように強制された場合は、おそらく別の解決策を見つけるでしょう。

RestバックエンドはResticに固有のものであるため、削除されません。 私もrest-serverを使用していますが、クレデンシャルを入力するだけで非常に便利です。

問題は「rcloneが埋め込まれている場合のみ」の状態にあると思います。 誰もこれを本当に必要としないので（埋め込まれたrcloneは必要ですが）。 今のところ、「新しいバックエンドを追加しないでください。rcloneでまだサポートされていないもの」と、これをわざわざ行う誰か（おそらく何ヶ月もの間、私）への機能リクエストは、rcloneを埋め込んでください。 。

必要最低限​​のことに関しては、bzipを使用しない代替リリースを入手する必要があります（私が聞いた限りでは、bzipをインストールする唯一の理由はresticです）。 それに関しては、私にとってのやることは＃2705なので、他に誰もしないなら、私はおそらくそうするでしょう。

rcloneについて私が気に入らないことの1つは、ソースとターゲットとして2つのURIを指定できるのではなく、実行する前に構成する必要があることです。

@rawtaz
rcloneは何も設定する必要がないので、まさにそれを行うことができます。
_〜 / .rclone.conf_または_〜 / .config / rclone / rclone.conf_は完全に削除できます。これらは、デフォルトまたはフォールバックオプションについて参照されるだけです。
今これを試してください：

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

これは完全に有効であり、ドキュメントで説明されています：

また、すべてのオプションを環境経由で渡すことも、CLI引数と組み合わせることもできます。

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

ライブラリとしてのrcloneの使用については、 https：//github.com/rclone/rclone/issues/633で説明されてい