Ich bin mir nicht sicher, ob ich den Header nach vorne verschieben soll. Ich weiß, dass dies derzeit nicht implementiert ist, aber für ein lokales Repository bedeutet der Header am Ende, dass wir eine Dateikopie speichern können.

Interessanter Punkt, danke. Ich bin mir noch nicht sicher, wie ich beurteilen soll, was besser ist. Für Remote-Backends könnten wir dann (nach ein paar Änderungen an der Backend-Schnittstelle) auch einfach ein io.Reader übergeben und dann kann die stdlib vielleicht sendfile verwenden, um die Datei direkt von der Festplatte zu streamen. Hm.

Nur zu Ihrer Information, ich habe mich gefragt, warum Sie GCM nicht verwenden, also habe ich die Benchmarks ausgeführt. AES-CTR + Poly1305 ist ziemlich schnell, wenn die CPU kein AES-NI hat (50 % schneller als das in Go integrierte GCM). Mit AES-NI ist der optimierte Assembler-Code von Go für GCM wahrscheinlich unschlagbar.

Intel Xeon E312xx

restic:
BenchmarkEncrypt-4        50      32470322 ns/op     258.35 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-4     200000         10620 ns/op     385.67 MB/s
Benchmark4kEncGoGCM-4         300000          5540 ns/op     739.22 MB/s

Intel Pentium G630 (kein AES-NI)

restic:
BenchmarkEncrypt-2            10     108468078 ns/op      77.34 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-2          50000         24182 ns/op     169.38 MB/s
Benchmark4kEncGoGCM-2              20000         96391 ns/op      42.49 MB/s

Das gehört nicht in dieses Thema, aber ich antworte trotzdem:

Ich glaube, als ich mit restic anfing, hatte Go keine optimierte Version von GCM. Außerdem fühlte ich mich bei der Verwendung von GCM nicht wohl, weil ich es nicht verstand, während das Poly1305-Papier viel einfacher zu lesen und zu verstehen war.

Ich denke, Ihr Benchmark verarbeitet viel kleinere Datenkleckse, vielleicht kommt es näher, wenn die Kleckse größer sind.

Ich verstehe. Ja, das optimierte GCM ist ziemlich neu, ich glaube, Cloudflare hat es für Go 1.5 gespendet.

In Bezug auf die Blockgröße verwendet der Restic-Benchmark 8 MiB , während stupidgcm 4 KiB verwendet . Ich habe es mit einer Blockgröße von 8 MiB für stupidgcm erneut versucht, aber die Ergebnisse sind praktisch identisch.

Verschwenden wir also keine Zeit damit, ich denke, CTR+Poly1305 ist schnell genug.

Ist es wichtig, eine unkomprimierte Größe in der Indexdatei oder in der Fußzeile des Pakets zu haben? Ich denke, es wäre in Ordnung, es nur innerhalb des Blobs zu kennen, dann sind weniger Änderungen in Restic erforderlich. Ermöglicht es, neue Funktionen an diesem zusätzlichen Ort bekannt zu machen?

Meiner Meinung nach zeigt das Repository-Format 2 == das erste Byte der Blob-Daten das Komprimierungsformat an, es ist alles, was benötigt wird. Vielleicht könnte eines von 255 möglichen Formaten {64-Bit unkomprimierte Länge} {komprimierte Daten} sein.

Ich denke, die Fehlerkorrektur ist eine gute Idee für die Sicherung. Aber ich denke, es ist eine Verantwortung des Dateisystems. Möchten Sie auch RAID innerhalb von Restic implementieren?

Ist es wichtig, eine unkomprimierte Größe in der Indexdatei oder in der Fußzeile des Pakets zu haben?

Ja: Der Paket-Header beschreibt, was im Paket enthalten ist, und dies sagt dem Extraktionsprozess, was zu erwarten ist (in Bezug auf den Komprimierungsalgorithmus, die unkomprimierte Größe und später auch andere Attribute wie den Schlüssel, der für die Verschlüsselung verwendet wurde). Dasselbe muss im Index dargestellt werden, der eingeführt wurde, damit restic nicht jeden Blob in einem Pack-Header nachschlagen muss. Dort müssen also die gleichen Informationen vorhanden sein.

Meiner Meinung nach zeigt das Repository-Format 2 == das erste Byte der Blob-Daten das Komprimierungsformat an, es ist alles, was benötigt wird. Vielleicht könnte eines von 255 möglichen Formaten {64-Bit unkomprimierte Länge} {komprimierte Daten} sein.

Ich mag diese Idee nicht, sie macht das Dateiformat komplizierter: Wir haben Steuerinformationen an zwei verschiedenen Stellen: am Anfang eines Blobs und im Header. Der Header ist genau die Stelle, die Steuerinformationen enthält.

Ich denke, die Fehlerkorrektur ist eine gute Idee für die Sicherung. Aber ich denke, es ist eine Verantwortung des Dateisystems.

Im Prinzip stimme ich zu, aber Dateisysteme sind sehr komplizierte Dinge, und die Fehlerfortpflanzung (z. B. von Lese-/Schreibfehlern des Mediums) ist oft suboptimal. Für stark reduzierte (in Bezug auf Redundanz, zB deduplizierte) Sicherungsdaten halte ich es immer noch für eine gute Idee, eine weitere Ebene der Fehlerkorrektur hinzuzufügen (oder anzubieten).

Für Reed-Solomon-Codes gibt es unter https://github.com/klauspost/reedsolomon eine reine Go-Implementierung mit einigen Leistungsdaten.

Laut https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ sollte ZFEC schneller sein. Eine Implementierung befindet sich in https://gitlab.com/zfec/go-zfec , die auf https://pypi.python.org/pypi/zfec zu basieren scheint.

ECCs werden nach der Komprimierung angewendet und sind normalerweise in der Datendatei verschachtelt, da ihre Verteilung sie robuster macht, wenn die Daten über unzuverlässige oder verrauschte Kommunikationskanäle übertragen werden.

In Usenet-Binärgruppen verwenden sie separate Dateien (siehe https://en.wikipedia.org/wiki/Parchive), die die ECC-Informationen enthalten. Das würde dem Repository-Layout nur ein weiteres Unterverzeichnis hinzufügen, und die Anwendung von ECC auf die Repo-Verwaltungsinformationen (Konfiguration, Index, ...) wäre auch einfach. Ich bin mir jedoch nicht sicher, ob dies das ECC-Schema schwächen würde (möglicherweise nimmt die Robustheit gegenüber Clusterfehlern innerhalb der ECC-Informationen ab).

Danke für die Hinweise. Ich habe die PDF-Version des Papiers hier gefunden: https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

Die Implementierung von ZFEC Go ist nur ein Wrapper um die C-Bibliothek.

Für ZFEC gibt es einen Go-Port mit Zusätzen (Verwendung von Goroutinen) namens jfec auf [https://github.com/korvus81/jfec].

Ich habe ein „Projekt“ (eine kürzliche Ergänzung zu GitHub) hinzugefügt, um die Implementierung des neuen Repository-Formats zu verfolgen: https://github.com/restic/restic/projects/3

Einige Ideen, die beim Aufheben der Abwärtskompatibilität untersucht werden könnten:

• Wechseln Sie von sha256 zu sha512

Führt die Verwendung von sha512 (oder sha512/256) anstelle von sha256 zu einer erhöhten Sicherungsgeschwindigkeit? Soweit ich sehen kann, gilt dies für die meisten Plattformen mit Ausnahme von ARM.

Syncthing-Diskussion (https://github.com/syncthing/syncthing/issues/582)

Borg-Diskussion (https://github.com/jborg/attic/issues/209)

Papier zu sha512/256 (https://eprint.iacr.org/2010/548.pdf)

• Verwendung von Verschlüsselung mit öffentlichem Schlüssel anstelle eines einfachen Passworts

Derzeit hat jeder, der Schreibzugriff auf das Repository hat, Lesezugriff darauf. Die Verschlüsselung mit öffentlichen Schlüsseln würde dies beseitigen und dennoch eine Deduplizierung auf der Grundlage der Hashes ermöglichen.

Die Anwendung der Verschlüsselung mit öffentlichem Schlüssel auf die Datenblobs würde funktionieren, aber ich bin nicht vertraut genug mit der Verarbeitung der Baumstruktur durch restic, um zu wissen, ob sie auch dafür erfolgreich implementiert werden könnte. Es könnte möglicherweise eine Menge Komplexität einführen. Wenn nur die Daten-Blobs ausgeblendet werden, gibt es immer noch viele Informationen in den Bäumen.

NaCl – https://godoc.org/golang.org/x/crypto/nacl/box

• Repository-Identifikation

Derzeit gibt es keine Möglichkeit zu wissen, dass Sie sich ein Restic-Repository ansehen, wenn Sie auf das Repository stoßen. Wir lecken derzeit "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" in den Schlüsseldateien. Ich würde vorschlagen, diese Informationen zu verbergen und stattdessen einige Informationen über restic einzufügen, wie z. B. restic repository version X . Könnte so einfach sein wie eine README.

In Bezug auf frühere Diskussionen; Ich bin sehr dafür, irgendeine Form der Fehlerkorrektur zu implementieren.

@oysols Danke, dass du deine Ideen hinzugefügt hast!

Ich werde meine Gedanken unten hinzufügen:

Wechsel von sha256 zu sha512 (für Geschwindigkeit)

Im Moment geht es mir nicht um Geschwindigkeit (restic ist schon sehr schnell), daher hat dieser Punkt zumindest für mich eine niedrige Priorität. Es gibt sogar eine optimierte Version von SHA256 für SIMD-fähige Prozessoren, auf die wir einfach umsteigen können. Auf der anderen Seite, wenn wir uns entscheiden, Restic zu beschleunigen und der Hash diskutiert werden soll, würde ich wahrscheinlich Keccak (SHA3) oder Blake2 bevorzugen, das sind (soweit ich weiß, habe ich noch keine Benchmarks durchgeführt) viel schneller.

Daher ist dieser Punkt aus meiner Sicht vorerst verschoben.

Verwendung von Verschlüsselung mit öffentlichem Schlüssel anstelle eines einfachen Passworts

Dieses Feature ist geplant (siehe Nr. 187), ist aber kompliziert und erfordert viel Nachdenken und mehrere größere Infrastrukturänderungen. Ich würde das auch gerne verschieben und lieber kleinere inkrementelle Updates machen statt eines wo wir alles ändern -> verschoben.

Repository-Identifikation (Fügen Sie eine README-Datei zum Repository hinzu)

Sehr guter Punkt, wir können das jetzt sogar hinzufügen, ohne etwas kaputt zu machen.

Repository "Information Leak" (Entfernen von Benutzernamen, Hostnamen und erstellten Zeitstempeln aus Schlüsseldateien)

Das ist auch ein guter Punkt. Wir verwenden diese Informationen derzeit nur, um sie zusammen mit der Schlüssel-ID im key list -Befehl anzuzeigen. Wir können username und host einfach weglassen, der Zeitstempel gibt nicht viele Informationen, in den meisten Fällen ist es das gleiche wie das Erstellungsdatum der Datei.

Ich möchte username und host löschen und den erstellten Zeitstempel drin lassen. Gedanken?

Ich habe heute mit https://github.com/klauspost/reedsolomon herumgespielt und ich denke, wir können Fehlerkorrekturcodes ziemlich einfach an das Ende der Pack-Datei hinzufügen (sobald wir den Pack-Header an den Anfang der Datei verschieben ). Es gibt jedoch zwei Nachteile:

• Die Dateigröße erhöht sich um ~14-30%, abhängig von den Parametern, die wir für reed-solomon wählen
• Wir müssen Prüfsummen (nicht unbedingt kryptografische Hashes) von Abschnitten der Packdatei in der Packdatei selbst speichern, diese werden für die Rekonstruktion benötigt, da der Algorithmus für die Rekonstruktion wissen muss, welche Teile der Datei beschädigt wurden. Die Berechnung dauert also etwas länger, obwohl wir eine schnelle Prüfsumme (wie CRC oder so) verwenden können.

Gedanken?

Könnte der Datenstabschutz dann optional sein? Ich halte die Größenzunahme für mehr als marginal (es ist ein großartiges Feature für andere Leute, obwohl ich glaube!)

Lassen Sie mich ein bisschen damit spielen, damit ich ein Gefühl dafür bekomme, wie viel größer (oder kleiner?) Das Repo sein wird, wenn ECC mit Komprimierung kombiniert wird. Vielleicht fügen wir zwei Arten von Codes hinzu: Einen für den Pack-Header und einen (möglicherweise optional) für die Daten.

Benutzername und Host löschen

Klingt wie eine gute Idee. Wenn wir die Informationen behalten möchten, können sie auf die gleiche Weise wie der Hauptschlüssel einem separaten verschlüsselten Feld hinzugefügt werden.

ECC: Die Dateigröße erhöht sich um ~14-30%,

Ich denke nicht, dass es eine gute Idee ist, den ECC in die Pack-Dateien selbst aufzunehmen. Sie sind in einem typischen Wiederherstellungsszenario nutzlos und werden nur verwendet, falls die Paketdateien beschädigt sind.

Ich schlage vor, dass die Paritätsdaten in einem separaten Verzeichnis abgelegt werden:

repo/data/1e/1ef7267...
repo/parity/1e/1ef7267...

• Die Parität ist vollständig optional und kann nach der Sicherung erstellt werden.
• Keine Verlangsamung der Wiederherstellungsvorgänge. Keine zusätzliche Bandbreite für die Wiederherstellung erforderlich.
• Identische Dateinamen erleichtern das Identifizieren korrekter Paritätsdaten. Dies bedeutet, dass die Paritätsdaten nicht nach ihrem eigenen sha256-Hash benannt werden, aber kein zusätzlicher Index benötigt wird. (Die Überprüfung der Paritätsdaten sollte ohnehin durch Überprüfung der Pack-Dateien erfolgen.)
• Der Benutzer bekommt eine Vorstellung von der Menge der Paritätsdaten.

Egal wie es implementiert wird; Bei vielen Komprimierungs- und Verschlüsselungsschichten denke ich, dass eine Art ECC notwendig ist. Ein falscher Bit kann eine Menge Ärger verursachen.

Vielen Dank für Ihre Kommentare. Lassen Sie uns die Diskussion in ein separates Thema verschieben, das ich gerade erstellt habe: Nr. 804.

Ich kann mich des Eindrucks nicht erwehren, dass zwei Gruppen aneinander vorbeireden über Forward-Error-Correction-Codes in Restic. Eine Gruppe möchte das Repo (nur) vor Bitrot schützen, da selbst ein einziger Bitflip ein großes Problem in einem deduplizierten Repo verursachen kann. Die andere Gruppe möchte Löschcodes verwenden, um das Repo über mehrere Fehlerdomänen (z. B. Nicht-RAID-Festplatten) zu verteilen. Beide Ziele können durch Reed-Solomon-Codes erfüllt werden, aber sie erfordern unterschiedliche Parameter und unterschiedliche Speicherlayouts.

Ich habe mein Repo mit meinem Python-Skript (https://github.com/oysols/restic-python) schnell überprüft.

header_length:        8688549
tree_length:         53898054
data_length:     146443506727
treeblobs:               8466
datablobs:             200975
packfiles:              29351
---- repo size by dir ----
            155   config
146 510 470 574   data
     27 538 629   index
          4 545   keys
          4 243   locks
         14 041   snapshots
          4 096   tmp
-----
Currently 116071 original files contained in the backup.

Bei einer 146-GB-Sicherung sind die Baumblobs nur 54 MB groß und werden gut auf etwa ein Drittel des ursprünglichen Speicherplatzes komprimiert, wenn wir die Komprimierung implementieren.

Würde es eine Leistungsverbesserung geben, indem die Baum-Blobs von den Daten-Blobs getrennt würden?

Es scheint, dass die meisten Operationen, die während einer Wiederherstellung durchgeführt werden, auf der Grundlage der Baum-Blobs durchgeführt werden, bevor die Daten tatsächlich wiederhergestellt werden. Wenn Sie sie in separate Packdateien aufteilen, wird die Datenmenge minimiert, die heruntergeladen werden muss, um den Baum einer Sicherung zu analysieren. Angesichts der geringen Größe der Baum-Blobs ist es möglicherweise sogar schneller, alle Baum-Blobs herunterzuladen, bevor der Wiederherstellungsprozess gestartet wird.

Natürlich; Diese Verteilung ist möglicherweise nicht für alle Repos gleich.

Denken Sie, dass es sich lohnt, dies weiter zu untersuchen?

Würde es eine Leistungsverbesserung geben, indem die Baum-Blobs von den Daten-Blobs getrennt würden?

Vielleicht ist dies eine der Optimierungen, die ich für die Zukunft im Sinn habe.

Abgesehen davon möchte ich auch einen lokalen Cache für die Metadaten hinzufügen, damit sie überhaupt nicht aus dem Repo geholt werden müssen. Dies sollte die Geschwindigkeit vieler Operationen erheblich verbessern.

Würde es eine Leistungsverbesserung geben, indem die Baum-Blobs von den Daten-Blobs getrennt würden?

Dies könnte theoretisch den Betrieb prune verbessern, da weniger Neupacken erforderlich wäre, wenn Baum-Blobs und Daten-Blobs in separaten Packfiles wären (es könnte möglich werden, ein altes Packfile vollständig zu löschen, anstatt es neu zu packen).

Das schaue ich mir schon bei #842 an

gcm vs. ctr: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

sym vs asym: Die Idee ist, einen "Sitzungs"-Schlüssel mit einem Pubkey zu verschlüsseln, richtig?

Lassen Sie uns in dieser Ausgabe nicht über Krypto sprechen, da es vorerst verschoben wird. Das relevante Thema für asymmetrische Krypto-Diskussionen ist #187. Außerdem möchte ich die Diskussion auf einem hohen Niveau halten, bis wir den Anwendungsfall festgelegt haben. Dann können wir über Low-Level-Krypto sprechen.

Entfernen Sie den Benutzernamen und den Hostnamen aus den Schlüsseldateien.

Riesiges Metadaten-Leck!
Beispielsweise weist "username":"WorldBank\\JimYongKim" eindeutig auf einen hochrangigen Eigentümer hin .

Warten darauf, dass dies _entfernt_ (oder _verschlüsselt_) wird, seit die erste Windows-Binärdatei im Januar 2017 kompiliert wurde.
Glücklicherweise habe ich die Sicherung geprüft, bevor ich Restic hochgeladen oder datenschutzbewussten Kollegen empfohlen habe.

Bearbeiten: Die Zeitzone des Benutzers wird auch im Klartext erwähnt, was ebenfalls gegen das Vertraulichkeitsprinzip verstößt.

Betreff: SHA3 – hier ist eine Meinung darüber, warum es sich (noch?) nicht lohnt, es zu übernehmen: https://www.imperialviolet.org/2017/05/31/skipsha3.html

Daher glaube ich, dass SHA-3 wahrscheinlich nicht verwendet werden sollte. Es bietet keinen zwingenden Vorteil gegenüber SHA-2 und bringt viele Kosten mit sich. Das einzige Argument, das ich anerkennen kann, ist, dass es schön ist, eine Backup-Hash-Funktion zu haben, aber sowohl SHA-256 als auch SHA-512 werden allgemein unterstützt und haben unterschiedliche Kerne. Wir haben also bereits zwei sichere Hash-Funktionen bereitgestellt und ich glaube nicht, dass wir eine weitere brauchen.

Ich habe den Beitrag gelesen und verstehe die Argumente von agl. Für Restic ist das nicht so relevant: Wir verwenden die Hash-Funktion, um Blobs (eindeutig) zu identifizieren, nicht als Baustein eines kryptografischen Protokolls. Meine Idee, mir andere Hash-Funktionen anzusehen, war hauptsächlich, dass SHA-256 langsam zu berechnen ist, insbesondere auf Low-End-Systemen. Andere Hash-Funktionen sind viel schneller (zB blake2).

Nicht sicher, ob dies ein Ding im Repo-Format ist: Wie wäre es, die Verschlüsselung optional zu machen? Ich denke an Backups, die auf einem vertrauenswürdigen Backup-Server gespeichert werden, der bereits verschlüsselte Festplatten hat.

@mschiff Siehe Nr. 1018 für diese Diskussion. ;)

Wie wäre es, wenn Sie die Teilegröße zu einer Option machen würden?
Aktuell habe ich 4-6 MB pro Datei. Mit weniger Dateien, aber größeren, wird die Remote-Sicherung viel schneller sein.

@fd0 schrieb:

Im Moment geht es mir nicht um Geschwindigkeit (restic ist schon sehr schnell), daher hat dieser Punkt zumindest für mich eine niedrige Priorität. Es gibt sogar eine optimierte Version von SHA256 für SIMD-fähige Prozessoren, auf die wir einfach umsteigen können. Auf der anderen Seite, wenn wir uns entscheiden, Restic zu beschleunigen und der Hash diskutiert werden soll, würde ich wahrscheinlich Keccak (SHA3) oder Blake2 bevorzugen, das sind (soweit ich weiß, habe ich noch keine Benchmarks durchgeführt) viel schneller.

Eine weitere Überlegung für einen schnelleren, weniger CPU-intensiven Hash-Algorithmus (wie Blake2) wäre eine geringere Batterienutzung auf Laptops, wenn Backups erstellt werden, während sie nicht an eine Stromquelle angeschlossen sind.

Antwort auf den ersten Beitrag:

Entfernen Sie den Benutzernamen und den Hostnamen aus den Schlüsseldateien.

Würde dies durch einen Schlüsselnamen oder eine Art Beschreibung ersetzt? Ich glaube, dass eine Möglichkeit, verschiedene Schlüssel zu unterscheiden (ohne Zugriff auf den Schlüssel selbst zu haben, z. B. beim Widerrufen des Zugriffs für eine Maschine), nützlich ist, um die Schlüsselverwaltung nützlich zu machen?

Ein neuer Vorschlag: Wie wäre es mit einem anderen Schlüssel für Blobs, Bäume und Snapshots? Dies würde, AFAICS, ein Szenario ermöglichen, in dem das Vergessen und Pruning auf dem Backup-Speicherserver und nicht auf den Clients erfolgt. Indem dem Speicherserver Zugriff auf die Baum- und Snapshot-Objekte gewährt wird, sollte er über ausreichende Informationen verfügen, um zu bestimmen, welche Objekte von welchen Snapshots benötigt werden und welche Objekte nicht mehr verwendet werden. Wenn der Speicherserver vollständig kompromittiert ist, erhält man Zugriff auf die Metadaten des Baums, aber nicht auf den eigentlichen Dateiinhalt.

Dies kann etwas stärker gemacht werden, indem nur der Zugriff auf die Liste der Objekt-IDs zugelassen wird, auf die von einem Baum verwiesen wird, ohne den Zugriff auf die restlichen Metadaten zuzulassen (dies würde jedoch eine zusätzliche Datenstruktur für jeden Baum erfordern).

Wenn das Obige möglich wäre, eröffnet dies den Weg für die Verwendung von Nur-Schreiben/Nur-Anhängen-Speichern (wobei der gesicherte Client keine Sicherungen löschen kann, siehe #784), ohne entweder auf automatisches Pruning verzichten zu müssen, oder Datensicherheit.

Zu meinem vorherigen Kommentar (Pruning ohne vollen Zugriff auf die Daten zu benötigen): Dies gilt auch (evtl. noch stärker) für die Überprüfung des Backups. Es ist aus Effizienzgründen sinnvoll, ein Repo auf dem Speicherserver zu überprüfen (AFAICS erfordert für die Remote-Überprüfung eines Repos die Übertragung aller Inhalte) oder wenn echte Nur-Schreib-Unterstützung implementiert wird (siehe https://github.com/ncw/rclone/issues /2499).

Außerdem sind für einen reinen Schreibansatz Änderungen erforderlich, um einzuschränken, welche Dateien gelesen werden müssen (gemäß https://github.com/ncw/rclone/issues/2499#issuecomment-418609301). Ich bin mir nicht sicher, ob dafür auch Änderungen des Repository-Formats erforderlich sind. Wenn ja, könnte es nützlich sein, diese hier aufzunehmen?

Das Überprüfen und Bereinigen eines Repositorys auf dem Remote-Server wäre wirklich großartig. Ich bin dabei, Restic für die Sicherung mehrerer Hosts einzurichten, und möchte alle Wartungsaufgaben auf der Fernbedienung erledigen, damit die Client-Einrichtung so einfach wie möglich ist und nur die regelmäßige Ausführung der Sicherung erforderlich ist.

Ich möchte einige (möglicherweise optionale) Ergänzungen zum Snapshot-Dateiformat diskutieren:

• Liste der verwendeten Indexdateien hinzufügen (siehe #1988)
• Möglichkeit für benutzerdefinierte Daten hinzufügen (wie Ergänzungen, Beschreibungen usw., habe das Problem gerade nicht gefunden)
• Fügen Sie statistische Daten wie Anzahl der Dateien/Blobs, verwendeter Speicherplatz usw. hinzu. Dies könnte die Anzeige von Statistiken viel schneller machen und ermöglicht auch zusätzliche Überprüfungen

Zum Pack-Dateiformat möchte ich fragen, warum der Header nicht vollständig entfernt wird.
Die Informationen sind redundant in den Indexdateien enthalten. Es gab einige Diskussionen über das Hinzufügen von Redundanz zur Fehlerkorrektur, aber IMO sollte (und kann) dies vom allgemeinen Repo-Format getrennt werden und kann darüber hinaus hinzugefügt oder nicht hinzugefügt werden.

Kurz gesagt: Wenn Sie keine zusätzlichen Informationen zur Fehlerkorrektur benötigen oder wünschen, müssen Sie keine Informationen in Header- und Indexdateien des Pakets duplizieren. Indexdateien werden für einen performanten Betrieb benötigt und überall verwendet. Pack-Header werden selten verwendet - und wenn dann nur zur doppelten Kontrolle oder Fehlerkorrektur.

Ein weiterer Vorschlag: Fügen Sie den Benutzernamen, den Hostnamen und den Inhalt der Konfigurationsdatei zum Abschnitt data der Schlüsseldatei hinzu. Entfernen Sie daher die Konfigurationsdatei vollständig.

Wie bereits vorgeschlagen, sollten Benutzername und Host nur verschlüsselt vorliegen. Um zu überprüfen, ob der von KDF abgeleitete Schlüssel gültig ist, reicht es bereits aus, den MAC des verschlüsselten Abschnitts data zu überprüfen.
IMO ist es sinnvoll, alle Informationen, die zur Identifizierung des Schlüssels benötigt werden, dort abzulegen. Das Hinzufügen der Informationen, die in der Datei config gespeichert sind, entfernt nur eine zusätzliche Datei aus dem Repo und erleichtert die Repo-Initialisierung.

Entschuldigen Sie die "dumme" Frage, aber gibt es ernsthafte Bemühungen, in absehbarer Zeit ein verbessertes Format einzuführen? Ich verfolge dieses Thema seit Jahren. restic funktioniert derzeit nicht gut für große Datenmengen oder wenn es viele Snapshots gibt, und es erfordert viel Speicher. Es scheint, dass die fehlende Komprimierung und der große Overhead der JSON-codierten Metadaten die großen Probleme von Restic sind. Vielleicht sind die Bemühungen ins Stocken geraten, weil es ein vermeintliches Bedürfnis gibt, „Perfektion“ zu erreichen?

Mich interessiert auch, was die Zukunft für Restic bringt. Besonders bei asymmetrischer Kryptographie und Komprimierung.
Übrigens, für eine neue Hash-Funktion gibt es auch blake3, das ist ganz neu und auch extrem schnell: https://github.com/BLAKE3-team/BLAKE3
Wenn noch keine Entscheidung bezüglich einer Änderung der Hash-Funktion getroffen wurde, könnte dies interessant sein.

Noch ein paar Ideen für repo.v2:

• Speichern Sie Baum- und Daten-Blobs in verschiedenen Verzeichnissen (in der Vergangenheit wurden Baum und Daten gemischt, aber dies wurde mit der Einführung des Caches verworfen).
• Hinzufügen von Informationen zur „Erstellungszeit“ zu Datenblobs.

Dies sollte die Unterstützung für "kalte" Speicher mit sehr langsamen oder teuren Downloads wie Amazon Glacier vereinfachen.

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Ich mag diese Idee nicht.. Es macht das Erraten von Dateigrößen von Backups viel einfacher, obwohl ich keinen Vorteil darin sehe.

* add 'created time' info to data blobs.

Ich sehe keinen Nutzen darin, eine "erstellte Zeit" hinzuzufügen. Können Sie einen Anwendungsfall nennen?

Dies sollte die Unterstützung für "kalte" Speicher mit sehr langsamen oder teuren Downloads wie Amazon Glacier vereinfachen.

Ich würde sagen, dass "Cold Storage"-Unterstützung bereits mit dem aktuellen Repo-Format erreicht werden kann, indem einige Feinabstimmungsmöglichkeiten zur Restik hinzugefügt und die dennoch häufig verwendeten Dateien doppelt gespeichert werden, z. B. in einem lokalen Cache. Siehe auch Nr. 2504

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Ich mag diese Idee nicht.. Es macht das Erraten von Dateigrößen von Backups viel einfacher, obwohl ich keinen Vorteil darin sehe.

Der Vorteil ist in früheren Kommentaren zu genau diesem Thema gut dargelegt:
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
Die Ergebnisse im ersten Kommentar zeigen auch, dass das Mischen dieser beiden Arten von Blobs die Dateigröße nicht in sinnvoller Weise verschleiert.

zugehöriger Forumsbeitrag:
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbao Die Kommentare, auf die Sie sich beziehen, beziehen sich auf das Mischen von Baum und Datenblob in einer Datendatei (Paket). Dies zu trennen war nützlich, um die Cache-Verarbeitung zu ermöglichen. Auch dies ist innerhalb von restic bereits geändert.

Ich sehe jedoch immer noch keinen Vorteil darin, Baum- und Datenblobs in verschiedenen Verzeichnissen zu speichern . Können Sie einen Anwendungsfall nennen? (IMO, das Thema des Find-Forums ist nicht verwandt - ich werde Ihnen dort antworten)

Das Trennen von Baum- und Daten-Blob-Einträgen in separaten Indexdateien (z. B. Verzeichnisse "index-data" und "index-tree") würde jedoch einige Verbesserungen ermöglichen.

Baum-Blobs werden bereits in separaten Pack-Dateien gespeichert (dies wurde zusammen mit Cache eingeführt).
Sie einfach in ein anderes Verzeichnis zu schreiben, eröffnet eine Möglichkeit, die Unterstützung von sehr langsam herunterzuladenden Speichern (3-5 Stunden für den Amazon Glacier-Standard) zu verbessern. Wie das Speichern aller Metadaten (Index + Snapshots + Baum in regulärem S3 und Daten in Glacier).

2504 verbessert es ein wenig, aber ich mag es nicht, mich auf den lokalen Cache zu verlassen oder viel zu warten, um den Cache zu füllen.

Ich mag die Idee viel mehr, einen Reverse-Proxy zu haben, der tree+index+snapshots auf normalem S3 oder an einem anderen Ort speichert, aber Daten in ein tiefes Archiv legt.
In jedem Fall ist es sicherlich möglich, restic mit einigen Einschränkungen unverändert zu verwenden. Aber einige Formatänderungen können die Dinge verbessern/vereinfachen.

@cfbao wird , soweit ich aus Code restic find sehe, davon nicht profitieren. Es geht schon über Schnappschüsse. Im Grunde ist es meistens dasselbe wie restic ls <all-snapshots> | grep something .

@dionorgua
Ich mag die Idee, ein beliebiges Repository als "zusätzlichen" Cache hinzuzufügen, in dem alles außer Datenpaketen zwischengespeichert wird. Dies erfordert keine Änderung des Repository-Layouts und IMO ist viel flexibler.
Daran arbeite ich bereits, siehe auch #2516, letzter Kommentar.

Vielleicht ist es eine dumme Idee, aber was ist mit einem Format, das mit Borg oder Kopia kompatibel ist?

@aawsome

Die Kommentare, auf die Sie sich beziehen, beziehen sich auf das Mischen von Baum und Datenblob in einer Datendatei (Paket).

Wahr. Mein Fehler. Ja, das ist das Einzige, was mich interessiert.

Auch dies ist innerhalb von restic bereits geändert.

Weißt du in welcher PR/Version das geändert wurde? Als ich das letzte Mal mein Repo überprüfte, bemerkte ich eine Mischung aus Daten- und Baum-Blobs in denselben Pack-Dateien. Irgendwie kann ich (wahrscheinlich langsam) mein Repo konvertieren, um eine bessere Trennung zu haben?

Ich sehe immer noch keinen Vorteil darin, Baum- und Datenblobs in verschiedenen Verzeichnissen zu speichern. Können Sie einen Anwendungsfall nennen?

Ich habe keine Ahnung. Wie bereits erwähnt, ist mir das ziemlich egal.

@dionorgua

Soweit ich aus Code sehe, wird Restic Find davon nicht profitieren. Es geht schon über Schnappschüsse. Im Grunde ist es meistens dasselbe wie restic ls| grübel etwas.

Würde das Trennen von Baum-Blobs von Daten-Blobs nicht die Anzahl der für die Suche erforderlichen API-Aufrufe reduzieren? Bei einer Konzentration würde die Anzahl der Pack-Dateien, die Baum-Blobs enthalten, reduziert, und restic kann eine kleinere Anzahl ganzer Dateien herunterladen, anstatt viele Segmente aus vielen Pack-Dateien abzurufen. Dies ist wichtig für Backends, die relativ langsam sind und strengere Ratenbegrenzungen haben (z. B. Google Drive).

Auf jeden Fall kann ich (wahrscheinlich langsam) mein Repo konvertieren, um es besser zu haben
Trennung?

Mit einer neueren Version von Restic sollte ein Lauf von 'Prune' diese gemischten Packs neu erstellen.
Beachten Sie, dass die eigentliche Implementierung von „prune“ viel Datenverkehr für entfernte Repositories erzeugt. Mit der experimentellen Neuimplementierung in #2718 wären Sie in der Lage, nur gemischte Packs bei minimalem Datenverkehr neu zu packen.

Würde das Trennen von Baum-Blobs von Daten-Blobs die Anzahl der APIs nicht verringern
Aufrufe für find notwendig?

In einer neueren Version und mit einem Repo, das keine gemischten Pakete enthält, werden alle benötigten Informationen lokal zwischengespeichert.

Eine weitere Idee für ein verbessertes Repository-Format:

Wie wir gesehen haben, ist es vorteilhaft, Pack-Dateien nach Blob-Typ zu trennen (Baum- und Daten-Blobs gehen in verschiedene Pack-Dateien). Wäre es nicht eine gute Idee, Indexdateien auch nach Blob-Typ zu trennen? Die jüngsten Index-PRs gehen bereits in die Richtung, Indexeinträge für Baum- und Datenblobs in der In-Memory-Darstellung zu trennen.
Auch gibt es mögliche Optimierungen, um nur einen Teil des Indexes zu laden

Dies auch im Repository zu tun, würde eine kompaktere Darstellung ermöglichen, z

{
  "supersedes": [
    "ed54ae36197f4745ebc4b54d10e0f623eaaaedd03013eb7ae90df881b7781452"
  ],
  "type": "data",
  "packs": [
    {
      "id": "73d04e6125cf3c28a299cc2f3cca3b78ceac396e4fcf9575e34536b26782413c",
      "blobs": [
        {
          "id": "3ec79977ef0cf5de7b08cd12b874cd0f62bbaf7f07f3497a5b1bbcc8cb39b1ce",
          "offset": 0,
          "length": 25
        },{
          "id": "9ccb846e60d90d4eb915848add7aa7ea1e4bbabfc60e573db9f7bfb2789afbae",
          "offset": 38,
          "length": 100
        },
        {
          "id": "d3dc577b4ffd38cc4b32122cabf8655a0223ed22edfd93b353dc0c3f2b0fdf66",
          "offset": 150,
          "length": 123
        }
      ]
    }, [...]
  ]
}