Restic: Daten aus unvollständigem Schnappschuss.

Ah, hm. Benötigen Sie eine bestimmte Datei oder nur "alle Daten, die es gibt"? Die Daten sind vorhanden, und Restic verfügt über alle Mittel, um sie herauszuholen. Dies würde jedoch bedeuten, dass entweder Restic-Skripte erstellt werden (was sehr langsam sein wird) oder benutzerdefinierten Code für Restic hinzugefügt werden.

Ehrliche Frage: Wie wichtig sind die Daten für Sie? Ich könnte heute einige Zeit damit verbringen, etwas für Sie zusammen zu hacken, was Ihnen Zugriff auf fast alle Daten geben sollte, die in das Repo hochgeladen wurden, aber es ist wahrscheinlich nicht so "produktionsbereit" wie der größte Teil des Codes. :) :)

Die Daten sind mir sehr wichtig und leider gibt es keine andere Kopie. Ich weiß, dass das nicht ideal ist, aber es war ein Problem, das ich zu lösen versuchte. Ich verfolge einen Hardware-Fix, um zu versuchen, das Volume wieder online zu schalten, aber das sieht im Moment nicht allzu hoffnungsvoll aus. Wenn es für mich eine Möglichkeit gäbe, ein Verzeichnis anzugeben und auf alles in diesem Verzeichnis zugreifen und es herunterladen zu können, wäre dies ein ernsthafter Lebensretter. Es sind viele Daten (viele davon sind Videoprojekte), daher wäre die schnellere Option vorzuziehen. Davon abgesehen weiß ich nicht wirklich, wie viel Arbeit es kosten würde, und ich schätze, dass dies freie Software ist, aber ich wäre äußerst dankbar, wenn dies möglich wäre.

ok, ich werde sehen, was ich tun kann.

Ich danke dir sehr.

Sie können beginnen, indem Sie restic rebuild-index ausführen. Wir haben also einen neuen Index, der alle Packs im Repo abdeckt.

Erste Schritte jetzt.

Wow, das ist super großzügig von dir @ fd0.

Wenn ich beim Testen helfen kann, lassen Sie es mich wissen.

Sollte restic rebuild-index mich nach dem Repo-Passwort fragen? Es hat noch nicht. Ich vermute, dass es aufgrund der Datenmenge im Repo ziemlich lange dauern kann. Ich bin vollkommen zufrieden damit, es das ganze Wochenende laufen zu lassen oder bei Bedarf bis zur nächsten Woche. Ich möchte nur sichergehen, dass ich kein Passwort benötige, bevor ich es längere Zeit unbeaufsichtigt lasse.

Hm, es sollte früh nach einem Passwort fragen. Es muss alle Header aller Dateien im Repo entschlüsseln. Haben Sie möglicherweise die Umgebungsvariable RESTIC_PASSWORD exportiert, sodass Sie kein Kennwort benötigen?

Es sollte so etwas schon früh drucken:

repository ed6136ad opened successfully, password is correct

Zumindest bei interaktiver Ausführung (keine Umleitung von stdout in eine Protokolldatei).

Sie können auch rebuild-index überspringen, wenn die letzten 15 Minuten der hochgeladenen Daten nicht so wichtig sind. Dies können wir später jederzeit tun.

Ich habe nicht die Umgebungsvariable RESTIC_PASSWORD gesetzt, aber ich werde sie setzen und einfach den Befehl laufen lassen. Es gab ungefähr 10 Minuten lang nichts zurück, also gab ich ihm ein ctrl-c und versuchte es erneut. Meine Syntax ist richtig, oder? restic -r b2:MY_BUCKET_NAME:/ rebuild-index In jedem Fall sollten die letzten 15 Minuten der Daten im Vergleich zu den insgesamt hochgeladenen Daten sehr klein sein, daher würde ich gerne später darauf zurückkommen.

ok, dann lass noch nicht rebuild-index laufen, damit wir den Wiederherstellungscode ausprobieren können :)

Ich habe ein Commit an den Zweig recover-data gesendet, einfach ein Restic erstellt ( go run build.go ) und es so genannt:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Anschließend sollten alle Bäume im Repo aufgelistet, die Stammbäume gefunden und ein neuer Snapshot erstellt werden, der auf alle Stammbäume verweist:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Dann haben Sie einen Schnappschuss (in diesem Fall 26f25bf1 ), den Sie wiederherstellen können, oder verwenden Sie einfach restic mount , um darin zu stöbern. Sie können es auch einfach auflisten:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

Die Verzeichnisse der obersten Ebene sind nach den Baum-IDs benannt, daher sind sie etwas kryptisch, aber die nächsthöhere Ebene hat normale Namen.

Lass es mich wissen, wenn dir das hilft!

Um ein bisschen Hintergrundgeschichte hinzuzufügen: Ich las die Github-Ausgabe, ging dann duschen und dachte mir: "Hm, das ist nicht so schwer zu tun." Es stellte sich heraus, dass ich recht hatte und es nicht war. Wenn diese Funktionalität für andere hilfreich ist, können wir sie später in einen richtigen Befehl umwandeln. Ich hoffe jedoch, dass sie für Sie funktioniert und Sie auf die Daten zugreifen können, die bereits auf B2 hochgeladen wurden.

Wie viele Daten waren es? Wie viel hast du erholt?

Viel Glück!

Beeindruckend! Das war schnell! Ich danke dir sehr! Ich habe gerade das Repo geklont und werde jetzt versuchen, es zu bauen. Ich habe auch herausgefunden, warum der Wiederherstellungsindex nicht funktioniert. Es war ein DNS-Problem im Netzwerk, in dem sich unser Server befindet. Ich habe das behoben und Fatal: unable to create lock in backend: repository is already locked by PID 41208 sodass mein Upload anscheinend doch nicht ordnungsgemäß gestoppt wurde. Der Befehl unlock scheint das geklärt zu haben und der Wiederherstellungsindex wird derzeit ausgeführt.

Ich werde so viel wie möglich tun, aber ich fahre für das Wochenende in ungefähr 15 Minuten nach Nord-Michigan und denke nicht, dass mein Internetzugang dort sehr gut sein wird. Dies wird meine volle Aufmerksamkeit am Montag bekommen, wenn ich zurück bin und ich werde dir mehr Details geben :-)

Vielen Dank dafür! Es tut mir leid, Sie hängen zu lassen, aber ich werde mich am Montag bei Ihnen melden.

Wenn diese Funktionalität für andere hilfreich ist, können wir sie später in einen richtigen Befehl umwandeln

Ich würde gerne dabei helfen, so gut ich kann. Meine Upload-Geschwindigkeit beträgt hier 1 Mbit / s, sodass meine ersten Backups bis zu 3-6 Monate dauern können. Eine Möglichkeit zur Wiederherstellung vor Abschluss zu haben, wäre eine hervorragende Funktion, insbesondere wenn es nicht zu schwierig ist, wie Sie sagen. Lassen Sie mich wissen, wie ich Ihnen behilflich sein kann! Vielen Dank, dass Sie daran gearbeitet haben! : D.

Außerdem ist Ihre Lösung meiner Meinung nach ziemlich brillant. Elegant und ziemlich einfach.

Es tut mir leid, Sie hängen zu lassen, aber ich werde mich am Montag bei Ihnen melden.

Mach dir darüber keine Sorgen, ich bin nur neugierig, ob es funktioniert: Sonnenbrille:

Die Daten sind bei B2 sicher und gehen nicht verloren. Selbst der Befehl recover ändert keine Daten, er liest sie nur, fügt eine weitere Datei und einen Schnappschuss hinzu und fertig.

Um Ihnen ein wenig Hintergrundwissen zu geben (vielleicht werde ich dies später in einen Blog-Beitrag erweitern): Unter der Haube enthält ein Restic-Repository verschiedene Dateitypen, zum Beispiel snapshot und data files:

• data Dateien enthalten eine Reihe kürzerer tree oder data Blobs, wobei am Ende eine Kopfzeile beschreibt, was in der Datei enthalten ist und wo genau
• snapshot -Dateien enthalten nur ein winziges JSON-Dokument, das einen Schnappschuss beschreibt, der auf ein tree verweist

Wenn eine Datei mit restic gespeichert wird, wird sie in data Blobs geschnitten, die gesammelt und zusammen in einer oder mehreren Dateien im Repository gespeichert werden. Der Name der Datei wird dann zusammen mit der Liste der Verweise (IDs) auf die data -Blobs in einem Baum gespeichert. Wenn die Archivierung des Verzeichnisses abgeschlossen ist, wird die Liste der Dateien (Namen und Referenzen für data Blobs) als tree Blob in einer anderen data Datei gespeichert.

Bei Unterverzeichnissen speichert restic den Namen des Unterverzeichnisses zusammen mit der Referenz des Blobs tree , der den Inhalt in einem anderen tree .

Am Ende des Laufs restic backup haben wir einen Stamm tree , auf den kein anderer Baum verweist, der jedoch alle Verweise auf alle Bäume der obersten Ebene und daher (indirekt) auf alle Dateien enthält und Unterverzeichnisse in der Sicherung. Als letzten Schritt erstellt restic eine neue snapshot -Datei, die auf das Stammverzeichnis tree verweist.

Wenn Sie restic anweisen, einen bestimmten Snapshot zu vergessen, wird der Stammbaum nicht mehr referenziert. restic prune erkennt dies und entfernt den Baum und alle anderen nicht benötigten tree und data Blobs.

Im Allgemeinen wird ein tree nur dann im Repository gespeichert, wenn alle darin enthaltenen Dateien und Unterverzeichnisse erfolgreich gespeichert wurden. Sobald also ein tree -Blob vorhanden ist, können wir davon ausgehen, dass die darin enthaltenen Daten (einschließlich Unterverzeichnisse) ebenfalls vorhanden sind.

Wenn restic während der Sicherung abgebrochen wird, enthält das Repo eine Reihe von tree Blobs zusammen mit den Daten in den Dateien, auf die sie verweisen. Um die Daten wiederherzustellen, muss restic nur Folgendes tun:

• Erstellen Sie eine Liste aller Baum-IDs. Notieren Sie, auf welche Bäume verwiesen wurde (anfangs: keine).
• für jeden Baum:
  
  
  
  • Laden Sie den Baum
  
  
  • für jeden Eintrag im Baum:
    
    
    
    
    
    • Wenn es sich um ein Verzeichnis handelt, verweist es auf einen anderen Baum. Markieren Sie diesen Baum als in der Liste referenziert
    
    
    
  
  

Gehen Sie als nächstes die Liste der Bäume noch einmal durch und werfen Sie alle weg, für die wir Referenzen gesehen haben. Die verbleibenden Bäume sind die Stammbäume, dh entweder Bäume, auf die in einem Schnappschuss direkt verwiesen wird (oder wurde) oder die als Ergebnis eines abgebrochenen Laufs von restic backup "baumeln".

Erstellen Sie als letzten Schritt einen neuen Baum, in dem alle Stammbäume aufgelistet sind, speichern Sie ihn im Repo und erstellen Sie dann einen neuen Snapshot, der auf diesen neuen Baum verweist.

Sie können diesen neuen Snapshot dann einfach normal verwenden, mit Ausnahme der kryptischen Namen der Verzeichnisse (die nur die kurzen Baum-IDs der gefundenen Stammbäume sind).

Bevor wir dies zu Master zusammenführen, sollten wir Folgendes tun:

• Fügen Sie recover eine Option hinzu, die Stammbäume ausschließt, auf die durch vorhandene Snapshots verwiesen wird, sodass wir nur wirklich baumelnde Wurzelbäume erhalten. Vielleicht sollte dieses Verhalten sogar die Standardeinstellung sein. Die meisten Benutzer sind wahrscheinlich nicht so interessiert an Daten, auf die sie über vorhandene Snapshots zugreifen können.
• Stellen Sie im neuen Snapshot auch nicht referenzierte data -Blobs zur Verfügung, damit Benutzer Teile von Dateien zusammenfügen können, die noch nicht in einem tree -Objekt enthalten waren.
• Legen Sie sinnvolle Metadaten sowohl für den neuen Baum als auch für den neuen Snapshot fest. Im Moment ist das sehr hässlich (nur genug, dass es funktioniert).
• Bessere Fortschrittsberichte, das ist momentan sehr hackig

Kleines Update dazu: Ich habe ein rebuild-index gestartet, bevor ich letzten Donnerstag abgereist bin. Das ist gestorben, bevor ich mit einem read: connection reset by peer zurückgekommen bin. Ich habe es gestern mit einer höheren Anzahl paralleler Verbindungen zu b2 neu gestartet und es scheint gut zu laufen. Es ist jetzt nur bei 5%, aber ich erwarte, dass es eine Weile dauern wird. Der b2-Bucket enthält ungefähr 90 TB und die Verzeichnisse, die ich gesichert habe, hatten wahrscheinlich ungefähr 110-120 TB.

Ich bin ehrlich gesagt sehr beeindruckt, dass Restic während des Uploads so stabil geblieben ist. Ich habe Cloudberry für Mac ausprobiert, bevor ich Restic ausprobiert habe, und ich konnte es nicht dazu bringen, mit so vielen Daten zu arbeiten. Ich benutze Restic, um meinen Laptop zu Hause zu sichern, und ich liebe es, also dachte ich, ich würde es versuchen. Da ich meinen ersten Upload noch nicht abgeschlossen habe, habe ich keine Ahnung, wie so etwas wie ein prune ablaufen wird, aber ich werde Sie gerne auf dem Laufenden halten, wenn Sie Daten darüber benötigen, wie sich Restic bei großen Datenmengen verhält . Wenn ich es schaffen kann, alle Vorgänge abzuschließen, die für die Aufrechterhaltung eines wöchentlichen Backups in weniger als einer Woche erforderlich sind, ist es meiner Meinung nach ein großartiger Kandidat für die Handhabung dieser Backups.

Vorerst habe ich ein paar Fragen: Soll ich dieses rebuild-index vollständig laufen lassen, bevor ich ein recover versuche? Verliere ich etwas, wenn ich es nicht tue? Ich habe darüber nachgedacht und ich denke, ich möchte, wenn möglich, auf Anhieb so viel wie möglich wiederherstellen, da es eine Weile dauert, bis so viele Daten ausgeführt werden. Wenn es jedoch besser ist, dies zu beenden, führen Sie recover zuerst und rebuild-index später kann ich das tun. Wird das Ausführen von rebuild-index oder recover mit einem --quiet -Flag die Dinge beschleunigen, wie dies mit dem Befehl backup Fall ist?

OK Cool! Ich würde Folgendes empfehlen:

• Brechen Sie die rebuild-index
• Führen Sie restic recover
• Schauen Sie sich an, welche Daten der neu erstellte Snapshot enthält

Wenn Sie es versuchen möchten, können Sie rebuild-index erneut ausführen und die verbleibenden Megabyte an Daten aus dem Repo entfernen. Wahrscheinlich sind das weniger als ein paar hundert Megabyte, und es ist wahrscheinlich, dass dadurch keine neuen Daten angezeigt werden, die noch nicht im Snapshot enthalten sind. Aber du kannst es versuchen :)

Während rebuild-index wird, können Sie nicht auf das Repository zugreifen.

Wird das Ausführen des Wiederherstellungsindex oder die Wiederherstellung mit dem Flag --quiet die Dinge beschleunigen, wie dies mit dem Befehl backup der Fall ist?

Nee.

Ich habe die Dinge über Nacht laufen lassen und es scheint die Festplatte gefüllt zu haben und ist fehlgeschlagen:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

Gibt es eine einfache Möglichkeit, festzustellen, wie viele Daten dieser Vorgang herunterladen muss, oder die Anzahl der heruntergeladenen Daten zu reduzieren?

Wenn ich diesen Speicherplatz freigeben möchte, ist restic cache --cleanup der richtige Weg, dies zu tun?

Nein, das entfernt nur Cache-Verzeichnisse, die seit 30 Tagen nicht mehr verwendet wurden. Entfernen Sie einfach das Cache-Verzeichnis, das sich irgendwo in Ihrem Home-Verzeichnis befinden sollte.

Welchen Befehl haben Sie genau ausgeführt? Sowohl rebuild-index als auch recover sollten nicht viele Daten auf der Festplatte speichern, außer im Metadaten-Cache ...

Im Moment nicht an meinem Schreibtisch. aber es war so etwas wie: ./restic -o b2.connections=x -r b2:mybucket:/ recover Ich glaube, ich hatte x auf etwas Großes eingestellt. Das könnte ein Teil des Problems gewesen sein. Ich kann es ohne das Bit -o b2.connections=x neu starten. Ich habe das Cache-Verzeichnis gefunden und gelöscht.

Zuallererst ein großartiges Werkzeug.
Ich muss auch Terabyte an Daten über eine langsame Verbindung sichern und die Möglichkeit haben, dass die Sicherung fehlschlägt, solange sie noch nicht abgeschlossen ist. Gibt es eine empfohlene Methode, um nur wenige Dateien gleichzeitig zu sichern?

Gibt es eine empfohlene Methode, um nur wenige Dateien gleichzeitig zu sichern?

Was normalerweise funktioniert (wie ich gehört habe), ist das Speichern einzelner Teile der Quelldaten (z. B. einzelne Verzeichnisse) und wenn dies abgeschlossen ist, werden alle Verzeichnisse zusammen gespeichert. Wenn sich die Quelldaten nicht geändert haben, sollte restic aufgrund der integrierten Deduplizierung fast nichts hochladen.

Ein besserer Ort für solche Fragen wäre das Forum unter https://forum.restic.net , die Fragen (und Antworten!) Sind dort viel besser auffindbar.

@ Pauletg also, wie ist es

Ich habe den neuen Befehl recover in # 2056 vorgeschlagen.

Ich habe seit meinem letzten Beitrag nicht viel Fortschritte bei der Erholung gemacht. Die gute Nachricht ist, dass wir es geschafft haben, den Server wiederzubeleben und die Daten beim Absturz nicht beschädigt wurden, also habe ich meine Daten. Der Wiederherstellungsbefehl scheint die Festplatte meines Computers zu füllen, bevor er abgeschlossen werden kann. Dies könnte durch mehrere Faktoren verursacht worden sein: Mein Backup war riesig und ich verwendete eine große Anzahl von Verbindungen zu b2 für den Upload und die Festplatte auf dem Computer, den ich für die Wiederherstellung verwendete, war relativ klein. Ich bin sicher, es würde wahrscheinlich großartig funktionieren, wenn mein Backup eine vernünftigere Größe hätte. Lassen Sie mich wissen, ob es weitere Informationen gibt, die für Sie hilfreich wären. Ich weiß es wirklich zu schätzen, dass Sie daran arbeiten, und es ist wirklich schön, diese Funktion für meine Laptop-Backups zur Verfügung zu haben.

Danke für die Rückmeldung! Wenn Sie möchten (und viel Zeit haben), können Sie dies mit --no-cache wiederholen, aber das dauert noch länger. Ich werde dieses Problem schließen, wenn # 2056 zusammengeführt wird.

Bitte lassen Sie uns wissen, wenn Sie zusätzliches Feedback haben! :) :)