Das wäre wirklich schön.

Es würde auch das Entfernen sensibler Daten ermöglichen, die unwissentlich aufgenommen wurden.

Das wäre eine tolle Funktion!

Gibt es Feedback von den Entwicklern zu dieser Idee? Es wäre sehr nett. Zum Beispiel habe ich gerade entdeckt, dass ein Programm, das ich aus git checkouts baue, riesige Binärdateien erstellt (fast 100 MB) und diese unnötigerweise in meinen Restic-Backups gesichert wurden. Ich benutze Restic noch nicht sehr lange, da ich mich noch in einer Testphase befinde, daher ist es kein Problem, die betreffenden alten Snapshots zu löschen. Aber dieses Problem kann ganz einfach passieren, und es wäre gut, langfristige Lösungen dafür zu haben, außer jeden Schnappschuss zu vergessen.

Ich nehme an, es wäre möglich, ein Skript zu schreiben, um jeden Snapshot wiederherzustellen, unerwünschte Dateien zu löschen und den Snapshot erneut zu sichern, indem das Datum manuell eingestellt wird, aber das würde natürlich sehr lange dauern. Es wäre toll, wenn Restic dies nativ tun könnte.

Vielen Dank.

Ich denke, dafür gibt es mehrere gültige Anwendungsfälle. Scheint ein wirklich gutes Feature zu sein. Ich würde es wahrscheinlich irgendwann selbst benutzen.

Es ändert wahrscheinlich nicht wirklich den Implementierungsaufwand, aber aus UX-Sicht könnte dies mit einem eher geringen Profil erfolgen, indem der Befehl backup anstatt einen völlig neuen Befehl hinzuzufügen:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

Anstatt also einen Befehl anzubieten, der Snapshots ändert, würde dies das Erstellen eines neuen Backups basierend auf einer vorhandenen Snapshot-ID ermöglichen. Das Löschen einer Datei würde mit Ausschlussregeln erreicht.
Die gesamte Dokumentation zu restic backup könnte im Grunde "wiederverwendet" werden (dh für diese neue Funktion müsste fast nichts hinzugefügt werden).

@dnnr Siehe https://github.com/restic/restic/issues/1550#issuecomment -358536554

Allerdings folge ich dir hier nicht. Das Entfernen von Daten aus alten Snapshots ist definitiv ein eigenständiger Vorgang und sollte über einen eigenen Befehl verfügen. Etwas wie:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

Und --snapshots sollte wahrscheinlich ein all Schlüsselwort akzeptieren, um mit allen Snapshots (oder allen Snapshots mit dem angegebenen --tag ) zu arbeiten. Und der Befehl sollte wahrscheinlich eine Bestätigung durch Eingabe von yes erfordern.

Es wäre auch gut, wenn es eine Option --patterns , die Pfade löscht, die den angegebenen Mustern entsprechen.

purge ist eine Möglichkeit für den Befehlsnamen. erase könnte auch eine gute Wahl sein, ebenso wie delete . Was auch immer gewählt wird, es sollte deutlich machen, dass der Vorgang Daten dauerhaft löscht . Dies ist Backup-Software, über die wir sprechen, und alle gefährlichen Vorgänge sollten eindeutig und eindeutig sein und eine Bestätigung erfordern.

Nun, ich habe den Schritt ausgelassen, in dem Sie den Quell-Snapshot anschließend löschen (mit forget , dann vielleicht prune ), weil ich dachte, das wäre offensichtlich.

Meiner Meinung nach würde eine solche Vorgehensweise den Befehlssatz orthogonaler halten als das Hinzufügen eines neuen Befehls, der sich mit der Funktionalität bestehender Befehle überschneidet. Im Moment gibt es backup , forget und prune und sie alle tun völlig unterschiedliche Dinge. Das Hinzufügen eines purge wie Sie es beschreiben, ändert dies. Mein Vorschlag nicht.

Da wir eine Dateioperation vorschlagen, wäre es schön, sie umbenennen zu können.

Ich stimme @alphapapa zu, dass es für diese Art von Operation einen eigenen Befehl geben sollte. Es könnte purge , das ist kein schlechter Name, dann könnte es in Zukunft auch andere ähnliche Operationen geben, zB hat @alvarolm bereits vorgeschlagen, Dateien umbenennen zu können.

Aus diesem Grund denke ich, dass das Hinzufügen eines rewrite Befehls in diesem Fall die beste Alternative ist und dieser Befehl beispielsweise die Optionen --purge und --rename , vorausgesetzt, letzteres ist relevant für implementieren. Die letzten Befehle wären also zB restic -r foo rewrite --purge snap1,snap2 path1 path2 ... und restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

Ich bin mir jedoch nicht ganz sicher, ob das Umbenennen etwas ist, das vernünftig zu implementieren ist - es geht ziemlich weit davon entfernt, worum es bei einem Backup-Programm geht. Aber klar, warum nicht.

Ich denke nicht, dass es ratsam ist, das Bereinigungsmaterial als Teil des Backup-Befehls zu verwenden. Aus einer Perspektive könnten Sie argumentieren, dass es in Ordnung ist – Sie führen eine Operation an Ihrem Backup durch. Aber aus diesem Grund sollten die Aktionen zum Bereinigen und Entsperren und Vergessen auch Teil des Backup-Befehls sein, da es auch bei ihnen darum geht, Dinge in Ihrem Backup zu verwalten. Ich denke nicht, dass das Sinn macht, daher denke ich, dass es tatsächlich eine separate Operation/ein separater Befehl sein sollte, zB rewrite oder purge .

@dnnr

Nun, ich habe den Schritt ausgelassen, in dem Sie den Quell-Snapshot anschließend löschen (mit vergessen, dann vielleicht beschneiden), weil ich dachte, das wäre offensichtlich.

Es ist definitiv nicht offensichtlich. Es ist auch besser, wenn Restic dies für den Benutzer übernimmt, anstatt dass der Benutzer nachverfolgen muss, welche Snapshot-IDs sich geändert haben und vergessen werden müssen - was eine ziemliche Belastung wäre, wenn der Benutzer alle Snapshots im Repository neu schreiben würde.

Meiner Meinung nach würde eine solche Vorgehensweise den Befehlssatz orthogonaler halten als das Hinzufügen eines neuen Befehls, der sich mit der Funktionalität bestehender Befehle überschneidet.

Ich verstehe nicht, was du meinst. Das Gegenteil ist der Fall. Dieser vorgeschlagene Befehl zum Löschen/Löschen/Umschreiben überschneidet sich überhaupt nicht mit backup – er löscht Daten aus vorhandenen Snapshots . Es ist orthogonal zu bestehenden Befehlen.

Im Moment gibt es Backup, Forget und Prune und sie alle tun völlig unterschiedliche Dinge. Das Hinzufügen einer Bereinigung, wie Sie sie beschreiben, ändert dies. Mein Vorschlag nicht.

Wieder keine Ahnung, was du hier denkst. purge ist komplett getrennt von Backup, Forget und Prune:

• backup : Erstellt einen neuen Snapshot der angegebenen Pfade.
• forget : Entfernt vorhandene Snapshots.
• prune : Garbage sammelt ungenutzte Blobs aus vergessenen Snapshots.
• purge / rewrite /was auch immer: Löscht Dateien aus vorhandenen Snapshots.

Sie schlagen vor, den Befehl backup in zwei Modi auszuführen, von denen einer Daten sichert und der andere Daten löscht.

@rawtaz Ja, rewrite ist ein guter Vorschlag, weil es bestehende Snapshots buchstäblich umschreibt. Ich würde eine Benutzeroberfläche vorschlagen wie:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

Ich rate davon ab, Kommas als Trennzeichen zu verwenden, da dies das Erstellen von Befehlszeilen in Skripten viel komplizierter macht.

backup: Erstellt einen neuen Snapshot der angegebenen Pfade.

Nun, in gewisser Weise ist das Ändern des Inhalts eines Snapshots das Erstellen eines neuen Snapshots (weil es nicht derselbe Snapshot wie zuvor ist). Denken Sie an git commit --amend , das einen neuen Commit basierend auf einem vorhandenen Commit erstellt. Die Analogie ist eigentlich ziemlich passend, da sich dieses Ticket schnell in Richtung einer Neuerfindung von Git zu bewegen scheint.

Sie schlagen vor, den Sicherungsbefehl in zwei Modi auszuführen, von denen einer Daten sichert und der andere Daten löscht.

Das habe ich nicht gesagt. Warum sollte es? Es gibt forget und prune , die zum Entfernen von Dingen vollkommen in Ordnung sind.

Nun, in gewisser Weise ist das Ändern des Inhalts eines Snapshots das Erstellen eines neuen Snapshots (weil es nicht derselbe Snapshot wie zuvor ist). Denken Sie an git commit --amend, das einen neuen Commit basierend auf einem vorhandenen Commit erstellt. Die Analogie ist eigentlich ziemlich passend, da sich dieses Ticket schnell in Richtung einer Neuerfindung von Git zu bewegen scheint.

Du hast recht. Gleichzeitig ist Restic jedoch kein Git, und es ist nicht darauf ausgelegt, Kenntnisse über inhaltsbasierte Adressierung zu erfordern, um zu funktionieren. Unabhängig davon, wie es unter der Haube funktioniert, denke ich, dass der Befehl, den wir vorschlagen, für Benutzer in Betracht gezogen werden sollte, einen vorhandenen Snapshot zu ändern und nicht einen neuen zu erstellen, daher sollte es sich um einen eigenen Befehl handeln.

Das habe ich nicht gesagt. Warum sollte es?

Nun, du sagtest:

aus UX-Sicht könnte dies mit einem eher unauffälligen Profil erfolgen, indem der Backup-Befehl erweitert wird, anstatt einen völlig neuen Befehl hinzuzufügen

Vielleicht solltest du es genauer erklären.

Es gibt Vergessen und Beschneiden, die zum Entfernen von Dingen völlig in Ordnung sind.

Seien wir konkret. forget entfernt Snapshots und prune entfernt Blobs . Wir schlagen einen Befehl vor, um Dateien in Snapshots zu entfernen. Es sollte ein eindeutiger Befehl sein.

Ich möchte meine Meinung hinzufügen:

Ich denke, es ist wertvoll, Snapshots im Repo zu ändern, basierend auf dem Feedback, wie viele Leute so etwas haben möchten.

Der Befehl sollte unabhängig vom Befehl backup , nicht nur aus Gründen der Orthogonalität (was ziemlich Go-like ist), sondern auch aus praktischen Erwägungen: Der Befehl backup ist bereits komplex genug, sodass ich 'möchte den anderen Befehl davon trennen.

Ich mag den Namen purge wegen der Ähnlichkeit mit prune . Was ist mit change ? Dann haben wir restic backup , restic restore und restic change .

Für die unterstützten Operationen des Befehls habe ich Anfragen gesehen für:

• Dateien löschen, zB --delete
• Dateien umbenennen, zB --rename

Bei ersterem geht es (ursprünglich) genau um dieses Problem, aber gibt es wirklich Anwendungsfälle für das Umbenennen von Dateien?

Ich denke, change klingt eher so, als würde man etwas herausnehmen und hineinlegen, anstatt den Inhalt von etwas zu ändern.

Stellen Sie sich vor, das Repo/Backup/Snapshot ist ein Bucket. Veränderung ist eher so, als würde man den Eimer selbst gegen etwas anderes austauschen oder etwas herausnehmen und ein anderes Ding hineinlegen, anstatt etwas aus dem Eimer aufzuheben, ein wenig zu modifizieren und zurückzulegen.

Vielleicht weiß ein englischer/amerikanischer Muttersprachler, was richtiger ist :) Es läuft auf die Linguistik hinaus, denke ich.

Hm, modify ?

modify ist definitiv besser als change . Also entweder rewrite oder modify von dem, was bisher vorgeschlagen wurde. Neugierig was andere denken :)

Wenn es nur um das Löschen von Dateien geht, wäre es dann sinnvoll, den Befehl forget für die Arbeit mit Snapshots und Dateien zu erweitern? Oder wäre das zu komplex?

Wenn es bei dieser neuen Funktion um das Löschen und Umbenennen (oder etwas anderes) geht, würde ich für modify stimmen.

Danke für deinen Input @dimejo 👍

Ich denke, dass Sie beim Umbenennen und / oder Löschen nicht forget ting sind (zumindest nicht im ersteren Fall).

IMHO "rewrite" vermittelt die Bedeutung am besten.

Der Befehl forget ist auch sehr komplex, wir werden nichts hinzufügen, wenn wir ihm helfen können ;)

Wenn es ein separater Befehl sein soll, wäre es auch mein Favorit, es modify zu nennen (ich hätte auch gerne modify-snapshot , obwohl es ziemlich lang ist). Es ist auch generisch genug, um ein geeigneter Ort für alle Arten von Änderungen an Dateioperationen (Umbenennen, vielleicht sogar Hinzufügen) zu sein. Ich denke jedoch immer noch, dass alles, was über das Entfernen von Dateien hinausgeht, stark nach Feature-Creep riecht.

Übrigens denke ich, dass restic von Befehlskategorien profitieren würde, ähnlich wie bei Git mit seinen Sanitärbefehlen. Im Moment listet restic -h alle Befehle in lexikalischer Reihenfolge auf und mischt Low-Level-Befehle (zB cat , list , die von "normalen" Benutzern nie benötigt werden) mit die primären High-Level-Befehle.

Sie könnten auch update Betracht ziehen.

+1 für rewrite , es hat einen schönen Orwellschen Klang. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? 😄

Ich möchte einen neuen edit Befehl vorschlagen. Basierend auf all das Feedback Wieder dieser Ausgabe erscheint es mir , dass wir vielleicht bis mit mehreren Aktionen beenden edit ein oder mehrere Snapshots.

Vorerst könnte es nur etwa so lauten:

$ restic edit 40dc1520 remove dir/file

In Zukunft könnten wir das Löschen einer Datei aus mehreren Snapshots implementieren (Eingabeliste der Snapshot-ID oder des Datumsbereichs).

Andere Befehle im Bearbeitungskontext könnten sein:

• rename um Dateien und Ordner umzubenennen
• move um Datei-/Verzeichnisstrukturen zu korrigieren, die sich möglicherweise geändert haben

Ich halte es für wichtig, dass wir diese Aktionen auf einem oder mehreren Snapshots ausführen lassen (nach ID oder möglicherweise einer Anzahl von Daten oder einem Bereich).

Ich bin mir immer noch nicht sicher, wie viel Restic mit gesicherten Daten auskommen sollte. Ich meine, es ist dazu gedacht, Daten zu sichern, um zu bewahren, wie die Dinge zu einem bestimmten Zeitpunkt aussahen. Es soll kein NAS sein.

Ich sehe insbesondere die Gültigkeit im Anwendungsfall des Umbenennens und Entfernens von Dateien nicht. Ich meine, warum sollten Sie Dateien auf Ihrer lokalen Festplatte ändern und dann mit Ihren Backups herumspielen, um den Dateibaum mit Ihren aktuellen Daten synchron zu halten. Es macht für mich keinen Sinn. Können Sie diesen Anwendungsfall näher erläutern?

@rawtaz
Meine Gedanken (fast) genau.

Ich würde argumentieren, dass die Gültigkeit des Entfernens von Dateien in dem Szenario liegt, in dem Sie einen Fehler in Ihren Ausschlussregeln entdecken, nachdem Sie bereits Backups mit diesen Regeln erstellt haben. Das Entfernen von Dateien dient also im Grunde der rückwirkenden Anwendung von Ausschlussregeln. Unabhängig von der Kontroverse in diesem Thread scheinen sich alle in diesem speziellen Anwendungsfall einig zu sein.

Bezüglich darüber hinausgehender Operationen (zB Umbenennen, Hinzufügen) teile ich Ihre Zweifel. Es ist Feature Creep und nicht im Rahmen eines Backup-Tools, IMHO.

Ich stimme zu: Das Löschen von Dateien aus Snapshots ist wichtig, da es sehr einfach ist, versehentlich Dateien zu sichern, die man nicht beabsichtigte. Dies ist häufig sowohl aus Sicherheits- als auch aus Gründen der Festplattennutzung erforderlich. Diese Funktion könnte den Unterschied bedeuten, ob man alte Backup-Daten behalten kann oder das Baby mit dem Bade ausschütten muss.

Aber das Umbenennen oder Verschieben von Dateien innerhalb eines Snapshots ist wahrscheinlich keine gute Idee. Um ehrlich zu sein, habe ich noch nie von einer Backup-Software gehört, die dies kann, und es scheint eine seltsame Funktion zu sein. Wenn ein Benutzer dies unbedingt benötigt, könnte es außerhalb von Restic implementiert werden, indem der Snapshot wiederhergestellt, die Dateien neu angeordnet und mit dem explizit festgelegten Datum erneut gesichert wird (obwohl dies in Zukunft komplizierter werden könnte, wenn Restic anfängt, absolute Pfade zu verwenden). .

Zugegeben, die Funktion zum Entfernen von Pfaden aus Schnappschüssen könnte auch auf diese Weise implementiert werden, aber da sie viel wahrscheinlicher benötigt wird, halte ich es für vernünftig, sie in Restic aufzunehmen.

Also, vielen Dank für Ihr Feedback, wir haben einen klaren Weg nach vorne: Implementieren Sie einen Befehl, der es ermöglicht, Dateien aus einem vorhandenen Snapshot zu entfernen. Der Name des Befehls wird festgelegt, wenn wir dort ankommen. Wir können die anderen Anwendungsfälle bei Bedarf erneut aufgreifen.

Ich glaube nicht, dass wir hier mehr Diskussion brauchen, danke fürs Mitmachen!

Vorschlag für den Befehlsnamen: restic purge .

Ich freue mich auf diese Funktion. Vielen Dank

@fd0
Irgendein Update zu dieser Funktion? Würde es gerne benutzen :)
Wir verwenden restic in einer Regierungsumgebung und das Löschen einer einzelnen Datei aus einem Backup ist für sie erforderlich. Bei Bedarf könnten wir einen Teil der Arbeit finanzieren!

Darauf freue ich mich auch! Ich schlage vor, so etwas wie die Basisstruktur für restic find .

restic purge [flags] PATTERN

Wo Sie die purge auf host (-H) snapshots (-s) or paths (--path) begrenzen könnten

Dann würde vielleicht ein restic prune danach das eigentliche Löschen durchführen

Dies wäre soooo hilfreich , wenn ein unvorhergesehenes Datei durch Fehler (ein großes Video in einem Dokumentenordner oder vielleicht eine etwas vertrauliche Datei) jetzt Rechte gesichert wird, laufe ich ein restic find dann jeden Snapshot löschen Sie die Datei enthält .. Dies ist weniger wünschenswert, wenn sich die Datei weit im Repo befindet (in der Zeit).

Vielen Dank !

Kein Update, tut mir leid. Sie werden benachrichtigt, indem Sie diese Ausgabe abonnieren, wenn etwas passiert.

Es hört sich so an, als würden die meisten Leute in der Lage sein, die Metadaten eines Backups clone speichern, aber anstößige Dateien auszuschließen - ohne sie alle an einem Scratch-Speicherort wiederherstellen zu müssen. Die Idee, ein Backup zu klonen, würde Metadaten mit der Möglichkeit kopieren, bestimmte Zeiger zu entfernen.

Ist das der Anwendungsfall?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite und modify könnten Makros für den obigen Prozess sein.

Für mich würde das in der Tat ausreichen @nullcake

Nicht schlecht, @nullcake.

Aufgrund meiner bisherigen Erfahrungen stelle ich jedoch normalerweise erst Tage oder Wochen später fest, dass ich eine Menge wertloses Zeug sichere. Wenn ich etwas Zeit zum Nachforschen habe. Dies bedeutet, dass, wenn ich verstehe, dass ich einige spezifische --exclude benötige, wahrscheinlich ein Dutzend oder mehr Backups betroffen sind.

Selbst wenn, wie von Ihnen vorgeschlagen, eine Bereinigung basierend auf einem einzigen Backup durchgeführt wird, wäre dies natürlich immer noch ein großer Schritt nach vorne. Wir wissen natürlich, wie man schreibt. ;)

Also Daumen hoch. :)

Obwohl dies eine interessante Idee ist, befürchte ich, dass der Befehl backup bereits viel zu komplex ist, und das Hinzufügen einer weiteren "Quelle" für ein Backup wird es noch komplizierter machen. Außerdem würde diese Funktion nur mit Daten arbeiten, die sich bereits im Repository befinden (nur auf Metadaten, um genau zu sein). Ein separater Befehl (zB purge oder so) könnte die Funktionalität gut kapseln.

CrashPlan hatte ein interessantes Verhalten, dass, wenn eine Datei ausgeschlossen wird, sie aus allen vorhandenen Snapshots gelöscht wird. Das könnte man sich überlegen.

Dies wäre eine großartige Funktion. Wurde es hinzugefügt?

Nö.

@fd0 gab es

Noch ein Vorschlag für einen Befehlsnamen: scrub (obwohl ich auch mit purge einverstanden bin, würde mir das Flag --rename seltsam vorkommen). Meine Gedanken:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

Wo --replace=clean alle modifizierten Snapshots entfernt, prune bereinigt und führt prune danach aus. --diff zeigt einen Diff für alle geänderten Snapshots an. --dry-run vermeidet Änderungen am Repository.

Ebenfalls gültig sind alle --exclude Flags aus restic backup . Ich denke, --host und --time auch sinnvoll (jeweils ersetzt die Werte des bereits vorhandenen Snapshots); --tag Bearbeitung wird bereits von restic tag .

Haben Entwickler eine Anleitung, wie dies implementiert werden könnte? Es scheint mir (bei einem flüchtigen Blick), dass der größte Teil des Codes in einer cmd_scrub.go Datei abgelegt werden kann; vielleicht sind nur ein paar API-Ergänzungen zur internen Bibliothek erforderlich, da es sich hauptsächlich um Indexoperationen handelt, aber das ist vielleicht naiv. Irgendeine geschätzte Schwierigkeit (ich gehe davon aus, dass das Testen auf jeden Fall den Großteil ausmacht)?

da dies ein sehr, sehr altes Problem ist.. Gibt es eine Chance, diese Funktion zu erhalten?

Für alle, die dies auf Updates überwachen und von Google darauf zugreifen, müssen Sie nicht warten, bis dieses Problem nie zum Tragen kommt. Verwenden Sie in der Zwischenzeit einfach duplicati. Es bietet erstklassige Unterstützung zum Entfernen von Dateien nach dem Fakt aus Snapshots.

Für alle, die dies auf Updates überwachen und von Google darauf zugreifen, müssen Sie nicht warten, bis dieses Problem nie zum Tragen kommt. Verwenden Sie in der Zwischenzeit einfach duplicati. Es bietet erstklassige Unterstützung zum Entfernen von Dateien nach dem Fakt aus Snapshots.

Ich benutze Restic jetzt seit ungefähr einem Jahr und habe aufgehört, auf die Implementierung von Funktionen zu warten. Ich meine nicht, dass alles in Restic hinzugefügt werden sollte, aber es gibt grundlegende Dinge, die da sein sollten. Ich überlege, mich von Restic zu entfernen: Das Repository ist sehr zerbrechlich und kann sehr leicht kaputt gehen.

Gestern habe ich einen Snapshot gelöscht, weil er Dateien enthielt, die nicht im Backup hätten sein sollen (ich habe vergessen, einen Ausschluss hinzuzufügen). Seitdem habe ich Fehler in meinem Repository und konnte es noch nicht reparieren. Ich sollte nicht ganze Snapshots löschen müssen, weil einige Dateien versehentlich eingefügt wurden.

@MorgothSauron Ich habe normalerweise nur Snapshots entfernt, die es auch enthielten, was die einzige Lösung ist, die restic scheint, aber auch hier kann Duplicati dies seit einiger Zeit über einen einzigen Befehl tun, also habe ich mich seitdem geändert und hatte keine Probleme.

Ich möchte allen für ihren Beitrag zu diesem Thema danken. Wie wir gesehen haben, haben sich viele Leute insbesondere die Möglichkeit gewünscht, Dateien aus einem Snapshot zu entfernen. Ich denke, wir alle machen ab und zu Fehler beim Sichern ;)

Zu diesem Zeitpunkt wird die verfügbare Betreuer- und Entwicklerzeit für andere Teile von restic benötigt, daher sehe ich nicht voraus, dass dieses Problem in absehbarer Zeit implementiert wird. Ich werde auch so bald wie möglich einen neuen Rest-Server veröffentlichen und dann anfangen, mich mit einigen anderen Problemen zu befassen.

Das heißt, wenn jemand eine solide PR erstellt, die schön und klar geschrieben, gut getestet und fehlerfrei ist und in Abstimmung mit den Betreuern erstellt wird, wird sie definitiv für die Aufnahme in Betracht gezogen. Dieses spezielle Problem ist eines, bei dem @fd0 bereits seinen Segen für die Richtung

Eine solche PR sollte grundlegend sein und als Ausgangspunkt dienen, auf dem bei Bedarf aufgebaut werden kann. Ein Beispiel dafür, was ich damit meine, ist es für den Anfang:

• Geben Sie einfach einen neuen Befehl ein (zB rewrite da dieser in dieser Ausgabe am häufigsten gewählt wurde).
• Nehmen Sie eine Liste von Snapshots als Hauptargument(e) (einschließlich Unterstützung für all ), zB all oder 098db9d5 oder 098db9d5 af92db33 .
• Nehmen Sie eine Liste mit einem oder mehreren --exclude <pattern> um die Pfade aufzulisten, die aus dem Snapshot ausgeschlossen/entfernt werden sollen (mit anderen Worten, hier sind die --exclude , die beim Sichern gefehlt haben), zB --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

Der Grund dafür ist, einen minimalen Start als Proof of Concept und minimal tragfähiges Produkt zu erhalten. Nach dem Test können wir es nach Bedarf anpassen, indem wir zB die anderen --exclude-* Argumente aus dem backup Befehl hinzufügen. Wenn wir einen rewrite Befehl wie diesen machen, hat er so ziemlich die gleiche Schnittstelle wie der backup Befehl, den er "korrigieren" soll:

~restic -r /some/repo rewrite all --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storerestic -r /some/repo rewrite 098db9d5 af92db33 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Store~

In diesem Zusammenhang könnte vielleicht die Arbeit von @middelink in https://github.com/restic/restic/issues/323 als Inspiration oder Grundlage für die Implementierung verwendet werden, da sie eine gewisse Verarbeitung bestehender Snapshots übernimmt. Ich werde sehen, ob wir mit diesem hier zu früh anfangen können.

@rawtaz

Danke für das nachdenkliche Feedback!

Hi.

Ich habe den Entwurf der rewrite Implementierung in der Nähe des Kommentars von @rawtaz hinzugefügt

Es funktioniert hier mit Test-Repo, passiert restic check --read-data ohne Fehler, habe es aber nicht viel getestet. Daher empfehle ich dringend, es nicht mit wichtigen Daten zu verwenden.

Ich habe versucht, die Syntax dem Befehl backup sehr nahe zu bringen. Also werden --exclude , --iexclude und --exclude-file unterstützt (aber nicht getestet). Idealerweise möchte ich auch die Option --exclude-if-present (der ideale Workflow für mich ist so etwas wie 'oops, nicht zum Sichern benötigt, füge CACHEDIR.TAG und restic rewrite '). Aber es ist ziemlich komplex, weil wir in einem solchen Fall rewrite auf demselben Host, auf dem das Backup erstellt wurde, benötigen und auf das Dateisystem zugreifen müssen, um diese Dateien zu sammeln (plus jede Menge Magie mit relativen Pfaden). Also jetzt nicht...

Außerdem mag ich keine Idee, Snapshots standardmäßig zu ersetzen, daher besteht derzeit das Standardverhalten darin, einfach einen neuen Snapshot mit dem Tag rewrite zu erstellen. Ersetzen ist aber auch durch --inplace arg möglich.

Jedes Feedback wäre sehr dankbar.

Hallo Dmitri,

Danke für diese Umsetzung, tolle Arbeit!

Bisher funktioniert es perfekt unter Linux mit einem kleinen Test-Repo von 600 Dateien + mehreren Test-Snapshots. Wiederherstellung funktioniert und diff zeigt korrekt ausgeschlossene Ordner an. Ich werde intensivere Tests an einem echten "Klon"-Repo mit vielen GB Daten mit mehr Hunderten von Snapshots durchführen. Ich werde auch Windows-Source-Repos ausprobieren.

Ein Vorschlag: Sie haben die Möglichkeit, ein Tag für die Snapshots anzugeben, die die Ausschlüsse bei einem Umschreibedurchgang enthielten. (Behalten Sie das Tag " rewrite " auf neu erstellten Snapshots bei.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

Dies würde helfen, die Snapshots zu identifizieren, die noch "_thisfileshouldberemoved.txt_" enthalten. Auf der anderen Seite funktioniert das direktere --inplace wie erwartet.

Wieder sehr gute Arbeit.

@NovacomExperts Ja, meine ursprüngliche Motivation war es, die Bearbeitung der Geschichte so sicher wie möglich zu halten. Es ist sehr einfach, etwas Wichtiges mit --exclude * auszuschließen und fast keine Möglichkeit, sich davon zu erholen (mit Backup muss man nur ein neues Backup starten). Etwas wie --dry-run aber mit der Möglichkeit, den tatsächlichen Snapshot zu erhalten und den Quell-Snapshot explizit zu löschen, nachdem überprüft wurde, dass es in Ordnung ist.

Ich stimme voll und ganz zu, dass dies derzeit nicht vollständig erreicht wird. Es ist einfach, neue Schnappschüsse zu „beobachten“, aber zu schwierig, alte zu löschen. Außerdem mag ich keinen hartcodierten rewrite Snapshot-Namen. Vielleicht ist es besser, standardmäßig --inplace und ---keep-source-tagged before-rewrite --tag-destination after-rewrite oder so ähnlich zu haben. ( --add-tag ist etwas unklar, ob es sich um einen alten oder einen neuen Schnappschuss handelt).

Auf jeden Fall warte ich auf Rückmeldungen von Betreuern. Ich möchte nicht viel Zeit verbringen, wenn es sich in die falsche Richtung bewegt.

PS. Mein primäres Restic-Repository ist jetzt etwa 2 TB groß. Werde es später ausprobieren, nachdem ich einen LVM-Snapshot erstellt habe.

@dionorgua Deine anfängliche Motivation ist völlig richtig. Ich gebe meine Stimme ab, damit es so bleibt, mit der "gefährlichen" Option --inplace so weit wie möglich vom Benutzer entfernt (definitiv nicht standardmäßig). Ich würde einen fehlenden Argumentfehler bei --keep-source-tagged / --tag-destination als standardmäßig --inplace vorziehen.

Aber ich stimme zu, warten wir auf Feedback dazu.

Gestern habe ich das geklonte Test-Repository (65 GB) in einem Ordner vergessen, der über Nacht von restic gesichert wurde. Ich könnte den Snapshot von forget gestern haben, bin aber "all-in" gegangen und habe Ihre Implementierung ausprobiert. Nach forget + prune ich die 65GB erfolgreich aus einem 400GB Repository entfernt. Alles gut, kein Fehler gefunden.

Ich teste intensiver mit Daten, die sich über mehrere Snapshots erstrecken.

Danke schön

Ich habe diese falsche Pull-Anfrage #2720 durch eine neue ersetzt, weil die alte aus dem Master-Zweig erstellt wurde. Habe gerade eine fehlende Fehlerprüfung hinzugefügt. Sorry für zusätzlichen Lärm

Hm, modify ?

Sehr spät dafür, aber _rectify_ ist mein Vorschlag für den Befehl delete-specific-file-from-backup.

2731 ist aufregend, vielen Dank!

Sehr spät dafür, aber korrigieren ist mein Vorschlag für den Befehl delete-specific-file-from-backup.

Ich muss sagen, das ist kein toller Name dafür. Korrigieren impliziert, dass etwas nicht stimmt, das korrigiert/berichtigt werden muss. Dies mag in einem der Anwendungsfälle zutreffen, ist jedoch nicht immer der Fall. Ein Benutzer möchte möglicherweise nur einige Daten aus vorhandenen Snapshots entfernen, um Speicherplatz für alles, was wir wissen, freizugeben, während der Rest des Snapshots beibehalten wird. Die Formulierung muss eher neutral sein als korrigieren, denke ich.