Restic: Befehl hinzufügen, um alle Daten in ein anderes Repository zu kopieren

Soll damit eine einmalige Kopie von einem Repository (A) zu einem neuen (B) gehandhabt werden? Oder ist dies allgemeiner gemeint, indem eine "Synchronisierung" oder eine Aktualisierung geänderter Inhalte zwischen (A) und (B) seit der letzten Synchronisierung durchgeführt wird?

Im Moment ist dies nur für eine einmalige Kopie gedacht, damit Benutzer zu einem anderen Repository an einem anderen Ort oder mit einem neuen Hauptschlüssel migrieren können.

Bei einer langsamen Internetverbindung möchte ich die Möglichkeit haben, so effizient wie möglich auf s3 und einen anderen Ort zu sichern.

@witeshadow Ich bin mir nicht sicher, wie das effizient erfolgen kann, da die Daten in Repo A mit Master A' verschlüsselt sind und Repo B mit einem anderen Masterkey B' ausführen müssen. Wir müssen alle Daten einlesen, mit A` entschlüsseln, mit B` verschlüsseln und ausschreiben. Es gibt keine Möglichkeit, dies für langsame Bandbreite zu optimieren. Es wird weh tun...

Die einzige Optimierung, die ich mir vorstellen kann, besteht darin, ein Auswahlkriterium für das Quellrepo A zu haben, indem die Host-, Pfad- und Tag-Filter verwendet werden, damit Sie nicht alles kopieren müssen. Dies hängt jedoch von Ihrem Anwendungsfall ab.

@fd0 Ich wollte nur meine Stimme für diese Funktionsanfrage abgeben. Kann ich irgendwas tun, damit es passiert?

Sie könnten es implementieren ... Die Funktionalität selbst ist nicht schwer, die Konfiguration der beiden Backends ist das Schwierige. Wir unterstützen nicht den Zugriff auf mehr als ein Backend (zB gibt es nur ein $B2_ACCOUNT_ID )... also denke ich, dass dieses Feature von einer richtigen Konfigurationsdatei abhängt (siehe #16).

Nehmen wir an, wir haben zwei Repos, A und B, und Sie möchten A->B synchronisieren, damit nach Abschluss des Prozesses der Satz von Blobs (und Snapshots) in B eine Obermenge des Satzes von Blobs in A ist .

Sie öffnen also beide Repos und laden jeweils die Indexdateien. Dann iterieren Sie über den Index von A und prüfen für jedes Blob, ob das Blob auch in B enthalten ist. Wenn dies wahr ist, fahren Sie mit dem nächsten fort. Wenn es falsch ist, laden Sie es herunter, entschlüsseln, verschlüsseln Sie es und laden Sie es in B hoch.

Zuletzt werden die Snapshot-Dateien kopiert. Für jede Snapshot-Datei in A entschlüsseln Sie die Datei, verschlüsseln Sie sie erneut für B, speichern Sie sie dort und fertig.

Wie gesagt, die technische Umsetzung ist recht einfach :)

Groß! Danke für die Tipps. Ich habe diesen Juckreiz, also werde ich sehen, ob ich die Zeit finde, ihn zu kratzen - aber kurzfristig werde ich auf diese restic merge Funktion verzichten müssen. Wenn jemand vor mir dazu kommt, ist das in Ordnung – oder ich werde irgendwann darauf zurückkommen!

Ich glaube, ich habe das schon umgesetzt... /mir kratzt sich am Kopf und sucht danach...
... https://github.com/middelink/restic/tree/fix-323
Ich muss jedoch überprüfen, ob es immer noch kompiliert wird, dieser Zweig ist 228 Commits hinter ...

Es kann sinnvoll sein, nicht nur eine vollständige Kopie, sondern auch eine Teilmenge von Snapshots zuzulassen. Dies würde einen von #1910 vorgeschlagenen Anwendungsfall unterstützen (backup auf ein primäres Repository oft und von dort Backup auf Offsite/langsamer/teurerer Speicher seltener) und wäre meiner Meinung nach nicht viel schwieriger zu implementieren als eine vollständige Kopie. Könnte aber eine zukünftige Ergänzung sein :-)

Äh… Gibt es Neuigkeiten für einfache Benutzer ohne Entwicklerkenntnisse, um den Vorschlag von @middelink zu kompilieren und auszuprobieren?

Dies ist hauptsächlich ein "ich auch"-Kommentar, aber ich hätte gerne die Möglichkeit, nur bestimmte Snapshots von einem Repository in ein anderes zu kopieren, anstatt eine "Alles kopieren"- oder "Synchronisieren"-Semantik; Erstellen Sie beispielsweise tägliche Backups im lokalen Speicher, kopieren Sie dann einmal pro Woche nur die aktuellsten täglichen Backups in einen s3-Bucket usw.

Nun, dann haben Sie Glück, meine Kopie cmd nimmt eine oder mehrere Snapshot-IDs. Tatsächlich ist alles kopieren nicht etwas, was es tut. Sie müssten zuerst Ihre Snapshot-IDs auflisten und sie dann in der Cmdline "restic copy" verketten. Da ich dies als degenerierten Anwendungsfall sehe, bin ich gut damit.

Ohne hier zu tief einzusteigen, könnten vielleicht einige Diskussionen mit ncw/rclone von Nutzen sein...

Ich interessiere mich auch für die Merge/Copy-Funktionalität, ich habe ein Repository auf einem USB-Stick, das ich in mein zentrales Repository (gleiche Passwörter) zusammenführen/kopieren möchte.
Gibt es darüber irgendwelche Neuigkeiten?

Sieht so aus, als ob der Fork-Zweig auf master aktualisiert wurde, aber es gibt noch keinen PR dafür.

@middelink Ist Ihr Code fertig/zusammenführbar? Wenn nicht, was ist noch zu tun? Das ist eine Funktion, die ich wirklich will :)

@theoretical2019 Der Code selbst ist fertig, aber jedes Mal, wenn ich mich hinsetze, um eine offizielle PR zu erstellen, finde ich immer wieder Dinge, die ich tun muss, bevor er fertig ist. Wie Dokumentation, wie ein unveröffentlichtes/Changelog...
Oh, und Tests! Habe ich Tests erwähnt? Es braucht Tests :P

@middelink Zu
Warte auf PR :tada:

Jetzt kann ich mit dieser Funktion ein sekundäres Repository erstellen, das von den Clients nur verwendet wird, wenn das erste Repository für die Wartung gesperrt ist (zB prune). Und die Bereinigungsaufgabe kann eine Kopie von der Sekundärseite auslösen, nachdem sie abgeschlossen ist, so dass keine Backups fehlen und somit keine Ausfallzeiten des Backup-Dienstes entstehen.

@middelink Wären Sie so freundlich, eine PR Ihres Codes zu erstellen? Erlauben Sie dabei bitte auch Änderungen von Betreuern - auf diese Weise können wir Ihnen beim Changelog, der Dokumentation usw. helfen.

Wichtig ist, dass wir eine Basis-PR bekommen, an der wir arbeiten können. Ich würde gerne Ihre großartige Arbeit voranbringen, und andere, denke ich, würden es auch tun :) Lassen Sie es mich wissen, wenn Sie Hilfe bei der Erstellung der PR benötigen!

@rawtaz Klar. Lass mich synchronisieren und all das Zeug. Aus irgendeinem Grund habe ich früher nicht die Zeit dafür gefunden, aber es sieht so aus, als hätte ich jetzt etwas Zeit.

Vielen Dank an alle für Ihre Arbeit daran!

Ich habe noch eine Frage, die von den Dokumenten nicht beantwortet wird (zumindest für mich): Muss ich beide bereinigen oder reicht es aus, dies in der Quelle zu tun und Snapshot-Löschungen werden propagiert?

@lfrancke Wenn Sie den Befehl copy , listen Sie speziell die Snapshots auf, die Sie kopieren möchten. Andere, sowohl vorhandene, nicht vorhandene als auch zuvor vorhandene, aber jetzt beschnittene und nicht mehr vorhandene Snapshots sind nicht anwendbar.

Wenn Sie Snapshots von Repo A nach Repo B kopieren und sie dann in Repo A vergessen und bereinigen, werden sie nicht automatisch in Repo B vergessen und beschnitten, das müssen Sie in Repo B selbst tun.

Ausgezeichnet, vielen Dank @rawtaz für die schnelle und hilfreiche Antwort.