Restic: Rclone macht die meisten Backends überflüssig

Das macht auch keinen Sinn. Rclone ist ein Übertragungsdienstprogramm, kein Sicherungsdienstprogramm. Es kann restic Repositorys nicht ersetzen.

Er meint wahrscheinlich nur, den eigenen Backend-Code von restic zu verwerfen, mit Ausnahme desjenigen für rclone, damit die rclone-Integration diejenige wird, die alle Backends durchlaufen.

@jtagcat Ich denke du meinst "Backends" statt "Repositorys".

Ich stimme diesem Vorschlag im Geiste zu.
Tatsächlich kann das Entfernen aller anderen Backends zu störend sein, aber zumindest können Dokumentationen rclone als bevorzugtes Backend hervorheben und andere Remote-Backends als "Legacy" kennzeichnen.

Eigentlich denke ich, dass wir es besser machen können, Backends als Legacy zu markieren.
Markieren Sie sie in Dokumenten als Vermächtnis, aber in den inneren Werken übersetzen Sie Vermächtnis in rclone on the fly. Bei einigen rclone-Backends können Sie direkt übersetzen ( ein Beispiel aus meinem Kopf ist http ), bei anderen übersetzen Sie in eine temporäre Konfigurationsdatei und verwenden dann --config /path/to/config mit rclone.

Wenn Sie mich als Benutzer von restic fragen, würde ich sagen, dass es schrecklich wäre, rclone für alle Backends verwenden zu müssen. Es erfordert das Einrichten von Rclone-Konfigurationen für Ihre Backends und das Beibehalten einer Rclone-Binärdatei, wobei ersteres die Ad-hoc- und konfigurationsfreie Natur von Restic sehr weit entfernt, was wirklich nett ist. Das einzige , was ich nicht mag über rclone ist , dass ich es konfigurieren , muss es vor der Ausführung, statt nur in der Lage sein es zwei URIs als Quelle und Ziel zu geben.

Ein besserer Vorschlag IMO ist, wenn wir rclone in restic einbetten könnten, so dass Sie restic weiterhin genauso verwenden können wie jetzt, aber mit der Backend-Unterstützung, die rclone bietet. Wenn das passieren sollte, wäre es in Ordnung, den aktuellen Backend-Code zu verwerfen, vorausgesetzt, der entsprechende Rclone-Code bietet die gleichen Funktionen.

Wie würden Sie Rclone in Restic einbetten? Wenn dieses Thema positiv abgeschlossen werden sollte, müsste es getan werden.
Wären Sie wie 'rclone not found, running curl https://rclone.org/install.sh | sudo bash ' (curl und sudo sind möglicherweise nicht auf dem System vorhanden)? Weil Sie es nicht einfach als Abhängigkeit in Paketmanagern hinzufügen können, wenn Sie nicht über einen pkg-Manager installieren.

Es ist möglich , aktuelle Backends im laufenden Betrieb in temporäre Rclone-Konfigurationen zu übersetzen, wenn ich reines Rclone für Dinge verwende, ärgere ich mich selbst auch ein wenig darüber.

Wie würden Sie Rclone in Restic einbetten?

Ich habe nicht untersucht, was in dieser Hinsicht möglich ist. Es ist nur etwas, über das ich ein paar Mal nachgedacht habe.

Ein bisschen mehr darüber nachgedacht, würde die Einbettung wahrscheinlich als "Installation als Abhängigkeit" enden, damit rclone auf dem neuesten Stand ist, ohne dass restic aktualisiert werden muss.
Wahrscheinlich wäre der beste Weg, rclone als Abhängigkeit hinzuzufügen, wo möglich und 'rclone nicht gefunden, installieren' überall (wenn die rclone-Abhängigkeit aus irgendeinem Grund nicht als Backup gefunden wird).

Obwohl der rclone-Installer einige Probleme aufwirft. Machen Sie es posix-kompatibel.

• curl - Ich habe ein oder zwei Systeme gesehen, bei denen es nicht sofort installiert war.
• sudo - wie oben
• unzip/anderes dekomprimierendes Ding, Sie haben dies wahrscheinlich schon erlebt, als Sie rclone auf einer minimalen Installation installiert haben.

Ich denke eher daran, Rclone als eine Bibliothek oder was auch immer einbettbar zu machen, damit es in Restic integriert werden kann. Es sollte kein Problem sein, eine neue Restic-Version zu veröffentlichen, wenn etwas in rclone so weit aktualisiert wurde, dass es eine neue Version rechtfertigt.

Wahrscheinlich wäre der beste Weg, rclone als Abhängigkeit hinzuzufügen, wo möglich und 'rclone nicht gefunden, installieren' überall (wenn die rclone-Abhängigkeit aus irgendeinem Grund nicht als Backup gefunden wird).

Es tut mir leid, das sagen zu müssen, aber der Versuch, Software (automatisch) auf dem Computer des Benutzers zu installieren, ist (wahrscheinlich) die schlechteste Idee, die ich je in den Diskussionen von restic gelesen habe.

Weil:

• Die Umgebung lässt die Installation neuer Software möglicherweise nicht zu.
• Der Benutzer (oder der Systemadministrator) möchte möglicherweise nicht, dass neue Software installiert wird.
• Der Zugriff auf das Internet ohne ausdrückliche Aufforderung kann unerwünscht sein.
• Das Installationsprogramm kann einen falschen Ort für die neue Software erraten.
• Die Installation neuer Software kann die normalen Funktionen der Umgebung beeinträchtigen (z. B. indem ausführbare Dateien außerhalb der regulären Orte bereitgestellt werden, an denen Benutzer/Paketmanager/Administratoren/Auditoren/was auch immer sie zu finden erwarten, und dadurch Verwirrung stiften).
• Die Installation kann fehlschlagen oder zu falschen Ergebnissen führen; entweder auf offensichtliche Weise oder auf subtile und schwer zu entdeckende Weise.

Wahrscheinlich wäre der beste Weg, rclone als Abhängigkeit hinzuzufügen, wo möglich und 'rclone nicht gefunden, installieren' überall (wenn die rclone-Abhängigkeit aus irgendeinem Grund nicht als Backup gefunden wird).

Es tut mir leid, das sagen zu müssen, aber der Versuch, Software (automatisch) auf dem Computer des Benutzers zu installieren, ist (wahrscheinlich) die schlechteste Idee, die ich je in den Diskussionen von restic gelesen habe.

Weil:

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

ja, was schlagen Sie vor?

was ich meinte war so:

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

Ich würde vorhandene Backends nicht durch rclone ersetzen, es sei denn, letzteres ist erfolgreich als Bibliothek eingebettet und somit immer in der Distribution von restic enthalten.

Bis dies erledigt ist (oder stattdessen), würde ich rclone zu einer optionalen Abhängigkeit in Paketmanagern machen, die dies ermöglichen (zum Beispiel apt und portage). Wenn rclone nicht installiert ist, könnte restic eine Nachricht anzeigen, die sich auf die Webseite von rclone bezieht und vorschlägt, entweder (1) die Seite nach Möglichkeiten zur Installation zu konsultieren, (2) rclone mit dem Paketmanager des Systems zu installieren, (3) das "curl + ." auszugeben bash" mit der Warnung "Stellen Sie sicher, dass Sie wissen, was Sie tun".

Ich würde den Befehl nicht im Namen des Benutzers ausführen, auch wenn ich danach gefragt habe.

Die Natur von RESTIC (insbesondere unter Linux) als statische Binärdatei ohne Abhängigkeiten war in Bare-Metal-Wiederherstellungs- und Wiederherstellungsszenarien ABSOLUT UNBEZAHLBAR.

Ich ziehe es derzeit vor, den "rest-server" (mit Haproxy-Frontend zur Authentifizierung) für interne Backups zu verwenden und bin darauf angewiesen, dass restic ihn nativ unterstützt. Wenn ich während einer zeitkritischen Wiederherstellung gezwungen wäre , mit RESTIC und RCLONE herumzuspielen, würde ich wahrscheinlich eine andere Lösung finden.

Die Natur von RESTIC (insbesondere unter Linux) als statische Binärdatei ohne Abhängigkeiten war in Bare-Metal-Wiederherstellungs- und Wiederherstellungsszenarien ABSOLUT UNBEZAHLBAR.

Ich ziehe es derzeit vor, den "rest-server" (mit Haproxy-Frontend zur Authentifizierung) für interne Backups zu verwenden und bin darauf angewiesen, dass restic ihn nativ unterstützt. Wenn ich während einer zeitkritischen Wiederherstellung mit RESTIC _and_ RCLONE _gezwungen_ wäre, würde ich wahrscheinlich eine andere Lösung finden.

Das Rest-Back-End wird nicht entfernt, da es nur für Restic gilt. Ich benutze auch Rest-Server, es ist sehr praktisch, einfach die Anmeldeinformationen einzugeben.

Ich denke, das Problem liegt im Zustand 'nur, wenn rclone eingebettet ist'. Da dies niemand wirklich braucht (obwohl eingebetteter rclone notwendig wäre). Ich schätze im Moment ist es eher 'Keine neuen Backends hinzufügen, was noch nicht von rclone unterstützt wird' und eine Funktionsanfrage für jemanden (wahrscheinlich in vielen, vielen Monaten, ich), der sich die Mühe macht, rclone einzubetten .

Was Barebones angeht, müssen alternative Releases herausgebracht werden, die kein bzip verwenden (soweit ich gehört habe, ist der einzige Grund für die Installation von bzip restic). Was das betrifft, wenn es sonst niemand tut, werde ich es wahrscheinlich tun, da ein Todo für mich #2705 ist

Das Einzige, was ich an rclone nicht mag, ist, dass ich es konfigurieren muss, bevor ich es ausführe, anstatt nur zwei URIs als Quelle und Ziel angeben zu können.

@rawtaz
Sie können nur das tun, da rclone Sie nicht zu konfigurieren alles erfordert.
Sie können alle _~/.rclone.conf_ oder _~/.config/rclone/rclone.conf_ vollständig entfernen, sie werden nur für Standardeinstellungen oder Fallback-Optionen konsultiert.
Versuchen Sie jetzt Folgendes:

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

Es ist absolut gültig und in den Dokumenten beschrieben: https://rclone.org/docs/#backend -path-to-dir

Sie können auch alle Optionen über die Umgebung übergeben oder mit CLI-Argumenten mischen:

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

Die Verwendung von rclone als Bibliothek wird in https://github.com/rclone/rclone/issues/633 beschrieben