Restic: Komprimierung implementieren

Erstellt am 15. Nov. 2014  ·  167Kommentare  ·  Quelle: restic/restic

Dieses Problem ist ein Nachverfolgungsproblem zum Nachverfolgen von Diskussionen und anderen Problemen/PRs im Zusammenhang mit der Anforderung zur Implementierung der Komprimierung.

Die folgenden Issues/PRs beziehen sich auf dieses Thema (und können daher zugunsten dieses geschlossen werden):

  • PR #2441
backend backup feature suggestion tracking

Hilfreichster Kommentar

Ich denke, es gab genug Diskussionen über das Hinzufügen von Komprimierung. Ich kann sehen, dass es ein mit Spannung erwartetes Feature ist. Ich werde dies als nächstes angehen, nachdem ich den neuen Archivierungscode fertiggestellt habe (siehe #1494).

Bitte keine weiteren Kommentare hinzufügen, danke!

Alle 167 Kommentare

Fügen Sie bei der Implementierung Benchmarks hinzu und sehen Sie sich insbesondere die Speichernutzung mit -benchmem und Benchcmp an!

lz4, lzo, lzma, null. bz2 ist ziemlich langsam.

snappy ist schnell mit moderater Kompression

Wenn die Komprimierung pro Chunk erfolgt, sollte darauf geachtet werden, dass restliche Backups nicht für Angriffe mit Wasserzeichen/Fingerabdrücken anfällig sind.

Dies ist im Wesentlichen das gleiche Problem, das wir im Zusammenhang mit dem Fingerabdruck des CDC-Deduplizierungsprozesses besprochen haben:
Mit "naivem" CDC kann überprüft werden, ob eine "bekannte Klartext"-Datei innerhalb des Backups vorhanden ist, wenn die Größe einzelner Blöcke von einem Angreifer beobachtet werden kann, indem CDC parallel auf die Datei angewendet und die resultierende Menge an Chunks und Individuen verglichen wird Stücklängen.
Wie bereits erwähnt, kann dies etwas abgeschwächt werden, indem der CDC-Algorithmus mit einem geheimen Wert gesalzen wird, wie dies auf dem Dachboden geschieht.

Bei Salted CDC gehe ich davon aus, dass die Komprimierung für jeden einzelnen Chunk erfolgen würde, nachdem die problematische Datei in Chunks aufgeteilt wurde. Restic Chunks liegen im Bereich von 512 KB bis 8 MB (aber nicht gleichmäßig verteilt - oder?).

  • Der Angreifer weiß, dass der CDC-Algorithmus einen geheimen Salt verwendet, sodass der Angreifer einen Bereich von Chunks generiert, der aus den ersten 512 KB bis 8 MB der Datei besteht, einen für jede gültige Chunk-Länge. Der Angreifer ist auch in der Lage, die Länge komprimierter Chunks zu bestimmen.
  • Der Angreifer komprimiert dann diesen Block mithilfe des Komprimierungsalgorithmus.
  • Der Angreifer vergleicht die Länge der resultierenden Chunks mit dem ersten Chunk in den restlichen Backup-Sätzen.
  • Wenn eine passende Blocklänge gefunden wird, wiederholt der Angreifer die Übung mit dem nächsten Chunk und dem nächsten Chunk und dem nächsten Chunk, ... und dem nächsten Chunk.
  • Ich glaube, dass dies bei ausreichend großen Dateien und angesichts der Tatsache, dass der CDC-Algorithmus "voreingenommen" ist (in Ermangelung besserer Worte), auf die Erzeugung von Blöcken von etwa 1 MB ausreicht, um festzustellen, ob eine bestimmte Größe Datei ist in der Sicherung vorhanden.

Wie immer, ein paranoider und höchst unwissenschaftlicher Bewusstseinsstrom.

Die Gedanken?

Interessant. Ich verstehe nicht, wie der von Ihnen beschriebene Angriff davon abhängt, ob eine Komprimierung verwendet wird, ist dies überhaupt notwendig? Funktioniert dieser Angriff nicht mit und ohne Kompression?

Momentan überlege ich, wie ich #56 umsetzen kann. Was halten Sie davon, mehrere Blobs in einer einzigen Datei zu bündeln?

Die genaue Funktionsweise der CDC-Implementierung ist mir etwas unklar:

  • Splitten Sie an genauen Bytegrenzen oder werden die 512 KB - 8 MB Blöcke auf ein Vielfaches von etwas "aufgerundet"?
  • (Die eigentliche Frage ist: Gibt es (15 * 512 * 1024) / (16 wegen AES-CTR) mögliche Chunk-Größen oder weniger?)
  • Ich bin auch neugierig, wie machbar es wäre, den Seed zu rekonstruieren, wenn genügend Teile einer bekannten Datei vorhanden sind - nicht sehr machbar, nehme ich an?

Um deine erste Frage zu beantworten:
Bei der mit Seeding versehenen CDC hängt der "Fingerabdruck" vom (Inhalt + dem geheimen Seed) ab, der Unterschied besteht jedoch darin, dass bei der Komprimierung _nach_ dem Chunking und unter der Annahme, dass Sie einzelne Blöcke voneinander unterscheiden können, Sie einen Fingerabdruck / Wasserzeichen (die Komprimierungsrate eines bestimmten Blocks), die ausschließlich vom Inhalt abhängt, in diesem Szenario ein bekannter Klartext.

Beispiel:
Wenn die mit Wasserzeichen versehene Datei 64 MB (8-128 Chunks) "AAAA" enthält, dann 64 MB "ABCABCABCABC", dann 64 MB Zufallsdaten, wären die ersten 16-256 Chunks sehr klein (da diese Sequenzen sehr gut komprimiert werden) , wo die 8-128 Chunks eher schlecht komprimieren würden).
Der Angreifer könnte auch rückwärts arbeiten, beginnend mit dem allerletzten (24. - 384.) Chunk und 512 KB bis 8 MB komprimieren, bis der Angreifer eine Größe findet, die auf genau die gleiche Chunk-Größe komprimiert wird. Sobald dies gefunden ist, werden die "nächsten" 512 KB bis 8 MB des ursprünglichen Klartexts komprimiert, um herauszufinden, welche Länge auf die Länge des vorletzten Blocks (23. - 383.) komprimiert wird usw kleine Stücke, die das Ergebnis der "AAAA"-Strings sind.
Dies ermöglicht es einem Gegner nicht, positiv zu bestätigen, dass eine mit Wasserzeichen versehene Datei im Backup gespeichert ist, aber ich denke, dass es statistisch gesehen ziemlich klare Ergebnisse liefern kann, wenn genügend Daten vorhanden sind.

Ich sehe einige mögliche Lösungen, vielleicht hast du noch mehr Ideen:

  • Erlauben Sie das Deaktivieren der Komprimierung und/oder Deduplizierung für bestimmte Verzeichnisse (wahrscheinlich am einfachsten zu implementieren)
  • Komprimierungswörterbücher randomisieren (ich habe dieses nicht wirklich durchdacht, aber es scheint eine interessante Idee zu sein)
  • Verhindern Sie, dass Angreifer die Längen einzelner komprimierter Chunks lernen, zum Beispiel durch Auffüllen (potenziell recht teuer) oder indem Sie mehrere kleine Chunks bündeln und die verbleibenden auffüllen (komplexer, aber effizienter)

Danke für deine Erklärung, jetzt verstehe ich dein Szenario.

Es wird wahrscheinlich keine Option geben, die Deduplizierung in Restic zu deaktivieren, da dies angesichts der aktuellen Struktur des Programms wirklich schwierig ist, Restic basiert auf CDC. Das Hinzufügen von Komprimierungsunterstützung hat derzeit geringe Priorität und ist kein Ziel für die Alpha-Version.

Ihre dritte Idee wird in #56 implementiert (Bündelung mehrerer Chunks), daran arbeite ich gerade. Und ich werde wahrscheinlich doc/Design.md mehr Dokumentation zur Funktionsweise des Chunkers hinzufügen.

Nochmals vielen Dank, dass Sie dieses Szenario angesprochen haben!

Ich bin mir nicht sicher, ob ich @cfcs folge - ist die komprimierte Größe nicht wie ein unglaublich schlechter Hash? Bei einer komprimierten Dateigröße ist die Anzahl der möglichen Eingaben, die diese Dateigröße erzeugen, endlos. Aber wahrscheinlich verstehe ich es einfach nicht.

Trotzdem. Ich wollte Sie nur schamlos auf eine modifizierte deflate/gzip-Bibliothek hinweisen, die ich erstellt habe. Es könnte Sie interessieren, dass ich einen konstanten Zeitkomprimierungsmodus aktiviert habe, der einen Durchsatz von ~150 MB/s/Kern für ALLE Daten ermöglicht, was ihn in Backup-Szenarien fast unsichtbar macht. Es gibt auch ein paralleles gzip-Paket , das größere Dateien auf mehrere Kerne gzip-komprimiert.

@klauspost : Denken Sie daran, dass wir eher die komprimierten Größen einzelner Chunks als Dateien besprechen. Eine 100-GB-Datei mit einer durchschnittlichen Chunk-Größe von 1 MB hat etwa 100 x 1024 Chunks, von denen jeder die Komprimierungsrate für einen bestimmten Teil der Datei verliert. Dies führt zu viel mehr statistischen Daten als die Größe einer einzelnen komprimierten Datei, wodurch es möglich ist, einen bekannten Klartext mit einer komprimierten und in Blöcke aufgeteilten Datei zu vergleichen, selbst wenn der CDC-Salz (und damit die genauen Ausrichtungsgrenzen der Blöcke) unbekannt sind.

151 wurde jedoch zusammengeführt, daher ist dies jetzt wahrscheinlich kein Problem.

Meiner Meinung nach ist dieses Informationsleck nur von untergeordneter Bedeutung, wenn man bedenkt, dass wir einen Seed-Chunker (über das benutzerdefinierte Per-Repo-Polynom) und Blob-Packing haben (wo ein Angreifer einzelne Chunks nicht sehen kann, sondern nur Gruppen von Chunks und die Anzahl der Chunks in einer Gruppe über die Länge des Klartext-Headers). Ich denke, es ist eine gute Idee, die Komprimierung aus Gründen der Geschwindigkeit oder des Datenschutzes vollständig zu deaktivieren, aber die Standardeinstellung (wenn dies implementiert ist) wird wahrscheinlich "Aktivieren" sein.

@klauspost Ich werde mir auf jeden Fall deine Bibliothek anschauen, danke für den Hinweis!

Ich stimme Ihren obigen Beobachtungen zu, @fd0 , aber ich möchte hinzufügen, dass es meiner Meinung nach einen weiteren wichtigen Anwendungsfall für das selektive Deaktivieren der Komprimierung für bestimmte Zieldateien/Verzeichnisse/Geräte geben kann, zum Beispiel beim Sichern von Multimedia-Formaten, die bereits komprimierte Binärdateien mit hoher Entropie, die sich nicht gut komprimieren lassen, oder bei inkrementellen Backups von verschlüsselten Volumes.

@cfcs - ok - aus Ihrem Text dachte ich, Sie könnten die Daten ableiten. Damit dies einen Unterschied macht, benötigen Sie die Originaldaten, was selten vorkommt.

In Bezug auf nicht komprimierbare Dateien habe ich den Konstantzeit-Nur-Huffman-Modus erwähnt, den ich in deflate gesetzt habe, da der Name schon sagt, dass er alle Daten mit der gleichen Geschwindigkeit komprimiert und automatisch auf das Speichern unkomprimierter Daten zurückgreift. Der maximale Overhead beträgt also etwa 0,04%, wenn der Inhalt komprimiert ist.

Hier sind einige Benchmarks . Am besten geeignet für Backups ist wahrscheinlich die "Medium Compression", also 10 GB gemischter Inhalt - komprimierbar und unkomprimierbar.

Es könnte sinnvoll sein, standardmäßig nur gzip Huffman zu verwenden und eine Option zur Angabe einer CPU-verbrauchenderen Komprimierungsstufe zu haben.

Meiner Meinung nach könnte es wertvoll sein, die Komprimierung getrennt für Daten- und Baumobjekte selektiv zu aktivieren/deaktivieren. Besonders große Baumobjekte sollten wirklich gut komprimieren.

Ich habe mir einige "Punkte" angesehen, an denen es sinnvoll sein könnte, Kompression einzufügen. Der transparenteste und vielseitigste Ort wäre irgendwo zwischen dem Repository und dem Backend.

Ich habe mir kurz die Modifizierung von Repository.Encrypt und Repository.DecryptTo angesehen , aber wir haben keine Typen, und die unterschiedlichen Größen würden die Dinge durcheinander bringen.

Mein Vorschlag ist, Komprimierung und _Verschlüsselung_ als "Backend" zu implementieren, die beide in ein zugrunde liegendes Backend schreiben. Dadurch wird die Komprimierung und Verschlüsselung für das Repository transparent.

Der Grund, warum wir die Verschlüsselung trennen müssen, ist, dass verschlüsselte Daten nicht komprimiert werden (wie Sie wahrscheinlich wissen).

Repository.Repository

Der Komprimierungsalgorithmus kann nur bei der Initialisierung eingestellt werden, und es wird davon ausgegangen, dass alles außer der Konfiguration mit diesem Algorithmus komprimiert wird.

Repository.Config

Die Konfiguration kann nicht komprimiert werden. Wir fügen eine Zeichenfolge hinzu, die den Dekompressionstyp angibt, der für alles verwendet werden soll. Leer ("") ist unkomprimiert. Andernfalls ist es der letzte Teil des Paketnamens der verwendeten Komprimierungsbibliothek.

Beachten Sie, dass die Komprimierungsstufen zwischen jedem Lauf/Typ geändert werden können. Es ist kein Problem, ein Repo zu haben, bei dem einige Snapshots/Typen auf Deflate-Level 0 (Speichern) und andere auf Level 9 (beste Komprimierung) liegen - solange der Dekomprimierer derselbe ist.

type Config struct {
    Version           uint        `json:"version"`
    ID                string      `json:"id"`
    ChunkerPolynomial chunker.Pol `json:"chunker_polynomial"`
+   Compression       string
}

Komprimierung wird als Erstellungsparameter hinzugefügt:

-func CreateConfig(r JSONUnpackedSaver) (Config, error) {
+func CreateConfig(r JSONUnpackedSaver, compression string) (Config, error) {

Das Backend wird nach LoadConfig/CreateConfig ersetzt. Hier ein Beispiel, wie es aussehen könnte:

// SearchKey finds a key with the supplied password, afterwards the config is
// read and parsed.
func (r *Repository) SearchKey(password string) error {
    key, err := SearchKey(r, password)
    if err != nil {
        return err
    }

-   r.key = key.master
-   r.keyName = key.Name()
    r.Config, err = LoadConfig(r)
+   r.be, err = FindCompressor(r.Config.Compression, Encryption(key, r.be))
    return err
}

Kompressionsimplementierung

Der Kompressor kann für einige Typen eine selektive/einstellbare Kompression implementieren. Da es als "Backend" angesehen wird, wird die komprimierte Größe niemals für das Repository sichtbar. Der Kompressor muss mit allen Einstellungen summetrisch sein.

Themen

HELPME/FIXME: "Gepackte" Dateien scheinen ein Problem zu sein, da die Verschlüsselung bei jeder Datei neu gestartet wird. Wenn die Verschlüsselung in das Back-End verschoben wird, gilt die Verschlüsselung für das gesamte Blob, nicht für jede Datei. Ich gehe davon aus, dass das ein Problem ist, und ich habe keine gute Lösung.

TODO: Finden Sie einen guten Weg, um Parameter/Konfigurationen an den Kompressor zu senden. Wird für eine erste Implementierung nicht benötigt.

TODO: Sind uns die Festplattengrößen wichtig? Wenn das obige implementiert ist, wird das Repository es nicht wissen.

Danke, dass du deine Gedanken teilst, hier sind meine:

Ich denke, dass Komprimierung und Verschlüsselung miteinander integriert werden müssen, ich werde darüber nachdenken. Im Moment gefällt mir der Gedanke nicht, die Kompressions-/Verschlüsselungsschicht vollständig voneinander zu abstrahieren. Wie Sie bereits beschrieben haben, müssen wir darauf achten, keine Dummheiten zu machen, zB verschlüsselte Daten zu komprimieren. Darüber hinaus sollten wir eine Option anbieten, um die Komprimierung zugunsten von Geschwindigkeits- und/oder Sicherheitsbedenken zu deaktivieren. Zur Verschlüsselung: Es kann später einen Nicht-Krypto-Modus für Restic geben, aber im Moment ist Krypto nicht optional.

Auch die gepackten Dateien sind eine Abstraktionsebene für sich (zB kann man Sachen neu packen), die mit abstrahierender Krypto nicht funktioniert.

Ich denke, das Repository Objekt ist viel zu komplex und braucht eine Generalüberholung, bevor man es angeht. Ich habe gerade keinen wirklich guten Plan dafür.

Zu den verschiedenen Komprimierungsalgorithmen und -optionen: Ich denke, wir sollten einen Algorithmus (einschließlich eines Parametersatzes) für Daten auswählen und vielleicht einen zweiten zum Komprimieren der JSON-Baumstrukturen, aber das war's. Für alle optionalen Dinge (zB verschiedene konfigurierbare Komprimierungsalgorithmen und/oder Parameter) hätte ich gerne eine solide Überlegung, die den Nutzen gegen die zusätzliche Komplexität und Menge an zusätzlichem Code abwägt.

Bitte verstehen Sie mich nicht falsch, ich möchte Restic gerne um weitere Funktionen erweitern, aber insbesondere für Änderungen, die das Format der Festplatte verändern, brauche ich sehr gute Argumente. Im allgemeinen Fall des Hinzufügens von Komprimierung kann ich den Vorteil sehen, aber die Komplexität und die Änderungen am Festplattenformat müssen überschaubar sein.

Sie benötigen unterschiedliche Algorithmen und Parameter (und nicht nur pro Repository, sondern sogar pro Backup-Lauf), es gibt keine Komprimierung, die für jeden Anwendungsfall am besten geeignet ist.

nur als praktisches beispiel:

Ich mache Backups von meinem Firmenserver auf meinen Backupserver zu Hause. dsl-Uplink mit ~700kbit/s.
dafür möchte ich die beste komprimierung (wie lzma + high level). Die CPU hat nachts viel Freizeit, während sie darauf wartet, dass die beschissene Verbindung das nächste Paket akzeptiert.

auf das gleiche Repository speichere ich auch meinen Laptop, wenn ich zu Hause bin, dort habe ich eine drahtlose "N"-Verbindung. natürlich möchte ich die verbindung nicht verlangsamen, indem ich dort lzma + high level verwende, sondern etwas sehr schnelles, das überhaupt nicht verlangsamt - wie lz4. Ich möchte jedoch immer noch eine Komprimierung. Wenn Sie lz4 nicht verwenden, würde dies ungefähr den doppelten Speicherplatz beanspruchen.

Ich will lzma hier aber lz4 da (umformuliert :-))

Das ist alles Bikeshedding imho... Lasst uns einen vernünftigen Standard wählen und nicht zu viele Konfigurationen offenlegen, das bringt nur viel Komplexität für wenig Gewinn, imho.

Ich denke, das Repository Objekt ist viel zu komplex und braucht eine Generalüberholung, bevor man es angeht. Ich habe gerade keinen wirklich guten Plan dafür.

Meinetwegen. Ich fing an, durch repository.go zu suchen und fand alle Stellen, an denen Sie einen Komprimierungs-/Dekomprimierungsschritt einfügen würden, und die zusätzliche Komplexität war keine gute Sache. Durch die Implementierung als backend Schnittstelle könnten Sie plötzlich die gesamte Verschlüsselung entfernen und sie zu einem Teil einer Backend-Kette machen. Sie könnten einen generischen Test durchführen, der die Symmetrie der Backend-Teile sicherstellt, einschließlich Komprimierung und Verschlüsselung.

Zur Verschlüsselung: Es kann später einen Nicht-Krypto-Modus für Restic geben, aber im Moment ist Krypto nicht optional.

Deshalb macht Backend-Chaining es so schön. Sie lassen einfach die Verschlüsselung weg (oder erstellen ein Passthrough-Backend) und es funktioniert nahtlos.

Im allgemeinen Fall des Hinzufügens von Komprimierung kann ich den Vorteil sehen, aber die Komplexität und die Änderungen am Festplattenformat müssen überschaubar sein.

Dies war die am wenigsten aufdringliche Art und Weise, die ich sehen kann. Wenn es eine Möglichkeit gibt, das Problem mit der gepackten Datei zu beheben, bleiben unkomprimierte Repos vollständig abwärtskompatibel; der alte Client kann sie wie bisher neben den neuen betreiben.

Komprimierte Repositorys werden dies natürlich nicht tun, aber wir können version nur dann auf 2 ändern, wenn das Repository komprimiert ist. Dies führt dazu, dass ältere Clients fehlschlagen. Der Check sollte dann natürlich auf if cfg.Version > RepoVersion { geändert werden, aber das hat keine Kompatibilitätsprobleme.

Das ist alles Bikeshedding imho... Lasst uns einen vernünftigen Standard wählen und nicht zu viele Konfigurationen offenlegen, das bringt nur viel Komplexität für wenig Gewinn, imho.

Zustimmen. Die meisten Algorithmen (lzma/deflate) bieten innerhalb desselben Dekompressionsformats viel Flexibilität.

Um die Komprimierbarkeit zu testen gibt es DataSmoke: https://github.com/Bulat-Ziganshin/DataSmoke

Außerdem wählt pcompress eine schöne Auswahl an Komprimierungsalgorithmen: https://github.com/moinakg/pcompress

Die Squash-Kompressions-Abstraktionsbibliothek enthält eine gute Liste von Algorithmen und einen Benchmark: https://quixdb.github.io/squash/

Hier gibt es einen Textkompressions-Benchmark: http://mattmahoney.net/dc/text.html

Ein einfacher Ansatz besteht darin, immer innerhalb von crypto/crypto.go Verschlüsselungs-/Entschlüsselungsfunktionen zu filtern.

gzip-compression-v1.patch.txt es ist ein Proof-of-Concept-Diff, das auf den Kopf angewendet werden könnte.

Danke, dass Sie @mappu ausprobiert

  • Wann wird Kompression angewendet? (Daten? Metadaten/JSON?)
  • Welchen Algorithmus sollen wir implementieren? Ich denke @klauspost hat einige Vorschläge für uns :)
  • Wie speichern wir dies in einem Repository, ohne Clients zu beschädigen?

Wann wird Kompression angewendet? (Daten? Metadaten/JSON?)

Daten offensichtlich ja.
Metadaten/json, vielleicht ist es sinnlos, aber ich denke, es könnte für große Metadatendateien hilfreich sein, da JSON-Daten hauptsächlich ASCII sind und von der arithmetischen Codierung / Huffman-Phase (gzip hat) profitieren würden.

Da Daten/Metadaten immer verschlüsselt sind, denke ich, dass das Hinzufügen zur Verschlüsselungs-/Entschlüsselungsroutine eine einfache Möglichkeit ist, alle Verwendungen zu erfassen, ohne dies "Ich habe angefangen, repository.go zu durchsuchen und alle Stellen gefunden, an denen Sie einen Komprimierungs-/Dekomprimierungsschritt einfügen würden. und die zusätzliche Komplexität war nicht gut." von @klauspost .
Da Blobs mit dem Namen hash(plaintext) not hash(chiffrtext) {{offensichtlich notwendig für Dedup, sonst würde zufälliges IV Dedup zerstören}} gespeichert werden, ist es sicher, dies zu tun, ohne Dedup zu verletzen.

Welchen Algorithmus sollen wir implementieren? Ich denke @klauspost hat einige Vorschläge für uns :)

egal Obwohl ich @ThomasWaldmann zustimme, dass es konfigurierbar sein sollte. Zumindest für einen --best und einen --fast Anwendungsfall.

Ich würde gzip nur vorschlagen, weil es pure go ist, es sich in der Golang-Standardbibliothek befindet und von Google auf die Leistung aufmerksam gemacht wird. xz ist eine viel stärkere langsame Komprimierung. lz4 ist viel schwächere schnelle Komprimierung. gzip ist ausgewogen und leicht zu stimmen, auch wenn es keines der Extreme erreicht.

Wie speichern wir dies in einem Repository, ohne Clients zu beschädigen?

Das Repository sollte nur in eine Richtung kompatibel sein. Ich denke, es ist in Ordnung, wenn der alte Restic kein neues Repo lesen kann, solange der neue Restic das alte Repo lesen kann.

Vielleicht könnten Sie nach dem MAC Tag-Byte hinzufügen. Nicht vorhanden - keine Kompression (alte Restic). Dann kann Byte auch anzeigen, welcher Komprimierungsalgorithmus verwendet wurde. 0x01 gzip 0x02 lz4 oder so.

Es scheint, dass das gleiche (oder schlimmere) Problem wie auf dem Dachboden vorhanden ist (kein Komprimierungstyp / Parameterbyte(s) im aktuellen Format verwendet).

Im Dachgeschoss (borg) hatte ich Glück, da das alte Format nur gzip war und das gzip-Format aus den ersten 2 Bytes erkannt werden kann. Also habe ich gzip ohne zusätzliche Bytes beibehalten (wie bei alten Repos) und Typbytes hinzugefügt (für keine oder andere Komprimierung), die mit den ersten 2 gzip-Bytes nie mehrdeutig sind.

Offensichtlich können Sie dies nicht tun, wenn das alte Format nur rohe, willkürliche Daten sind.

Nein. Aber es gibt andere Möglichkeiten, diese Informationen zu signalisieren. zB wenn IV am Anfang des verschlüsselten Chunks genau "NEWFORMAT" ist (1 :: 2^xyz Kollisionswahrscheinlichkeit), dann als neues Format parsen. Es ist nicht so "sauber", aber ich denke in der Praxis gut.

wie es mit EXTENDEDPROTOCOL in nmdc lock handshake gemacht wird.

Oh nein, so etwas Hässliches werden wir nicht tun, und das müssen wir auch nicht. Sollten wir uns dazu entscheiden, dies zu implementieren, haben die Pack-Dateien für jeden Blob ein Feld type . Dies ist ein uint8 , und im Moment nur für data und tree , können wir einfach compressed data und compressed tree hinzufügen. https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

Im Moment halte ich dieses Feature nicht für eine hohe Priorität.

Das Hinzufügen neuer Blob-Typen zum Packformat ist für die Datenkomprimierung in Ordnung, bietet jedoch keine Indexkomprimierung. Da Indizes groß werden können und JSON eine gute Komprimierungsrate hat und der Index möglicherweise keinen lokalen Cache hat, denke ich, dass es auch wichtig ist, Indizes zu komprimieren.

Es ist wichtig, dass new-restic mit old-repo zusammenarbeitet, um ein einfaches Upgrade zu ermöglichen. Es sollte entweder nahtlos sein (bevorzugt) oder ein restic upgrade-repo Tool haben (nicht bevorzugt).

Wie wäre es also damit?

Alle restic-Befehle laden und entschlüsseln bereits zuerst config .

  • Wenn das erste config Byte { (es ist das erste Byte des Json-Objekts), dann hat das gesamte Repository das alte Format (unkomprimiert)
  • andernfalls ist das erste config Byte {Tag-Byte} und das gesamte Repository hat ein neues Format. {Tag-Byte} am Anfang der entschlüsselten Daten zeigt das Komprimierungsformat an. Beispiel 0x00 unkomprimiert 0x01 gzip

Danke für den Vorschlag. Ich denke, es ist unnötig, die Config zu komprimieren, da dies nur eine wirklich kleine Datei ist und immer im JSON-Format bleiben kann, und wir können bei Bedarf Felder hinzufügen, z. B. ob die Indexdateien komprimiert sind oder nicht.

Ich bin gestern auf restic auf der Suche nach einer guten Backup-Lösung gestoßen. Eines meiner Hauptanliegen ist es, den Platzbedarf meiner Daten zu begrenzen. Vor allem, wenn ich Daten an Orte sende, für die ich bezahle, wie zum Beispiel S3. Dedup wird definitiv helfen, aber ich erwartete, dass die Komprimierung ein wesentlicher Bestandteil einer Backup-Lösung sein würde ... In https://github.com/restic/restic/issues/21#issuecomment -185920429 sagst du ( @fd0 ) dies hat eine niedrige Priorität, können Sie erklären, warum? Gibt es eine Roadmap, die ich mir irgendwo anschauen könnte?

Außerdem +1. ;)

Im Moment arbeite ich daran, alte Backup-Daten zu entfernen (#518). Es ist nicht einfach, die Komprimierung gleichzeitig richtig und sicher zu machen, und ich muss etwas mehr darüber nachdenken, wie ich dies in das Repository-Format integrieren kann.

Wir werden die Komprimierung implementieren (nach all dem, worum es in diesem Problem geht), es wurde nur noch nicht getan. restic ist ein ziemlich neues Projekt, bitte habt Geduld :)

Dieses Problem hängt mit #116 zusammen. Wegen der Verschlüsselung können wir das Backup nachher nicht mit einem anderen Tool komprimieren, oder? Welche Priorität haben Sie zwischen Komprimierung und optionaler Verschlüsselung? (Ich wette zuerst auf Kompression!)
_Entschuldigen Sie, dass ich deswegen Druck mache, Sie haben Recht, dass das Repository-Format mit Vorsicht zu genießen ist!_

Das ist einfach zu beantworten: Zuerst wird die Komprimierung implementiert.

Dies liegt daran, dass ich derzeit keine Pläne habe, die Verschlüsselung optional zu machen. Ich denke, es ist auch sehr schwer, richtig zu liegen. Wir müssen über Integrität nachdenken, da dies nicht optional sein sollte, aber (zumindest im Moment) eng mit der Verschlüsselung verbunden ist.

@fd0 Danke für die Beantwortung meiner Frage. Ich wünsche mir, dass meine Entwicklerfähigkeiten dazu in der Lage wären, dabei zu helfen. Aber ich habe go nur kaum berührt, und die meisten meiner anderen XP sind in Webdev- oder Sysadmin-Skripten.

Ich stimme voll und ganz zu, dass Sie sicherstellen müssen, dass die Komprimierung "richtig und sicher" durchgeführt wird. Wenn das die Dinge verzögert, soll es so sein. :Lächeln:

Ich habe die bissige Komprimierung in Restic hier implementiert: https://github.com/viric/restic/tree/snappy

Es ist nur ein Vorschlag. Grundsätzlich habe ich eine schnelle Komprimierung/Dekomprimierung für Blobs in Packs hinzugefügt, und ich verwende ein bisschen des Blob-Typ-Bytes als Markierung. Außerdem habe ich in Pack-Indizes ein Feld hinzugefügt: PLength (Klartextlänge), das bis dahin nicht gespeichert, sondern als "bloblength - crypto.Extension" berechnet wurde.

Mir ist aufgefallen, dass es für einige meiner Backups nicht nur weniger Speicherplatz benötigt, sondern sogar schneller arbeitet (weniger zu verarbeitende Daten).

Alle Restic-Tests bestehen gut. Es kann über vorherige Restic-Repositorys funktionieren, aber normales Restic (das von Master) kann die neuen Blobs nicht verarbeiten.

Ich habe snappy (https://github.com/golang/snappy) verwendet, weil ich dachte, dass es das Geschwindigkeitsziel von @fd0 weniger beeinträchtigen würde.

$50 Kopfgeld für Kompressionslandung auf Master hinzugefügt

Bountysource

Wie oben erwähnt, sollte es einen automatisierten, nicht konfigurierbaren Weg geben, um den Versuch zu vermeiden, nicht komprimierbare Dateien wie Medien, verschlüsselte oder bereits komprimierte Dateien zu komprimieren. Das Problem wird durch einige Containerformate wie PDF verschärft, deren Inhalt manchmal komprimierbar ist, manchmal nicht.

Am einfachsten wäre es, einfach einen Algorithmus zu verwenden, der dies transparent handhabt, wie den im ersten Kommentar von @klauspost erwähnten konstanten Zeitkomprimierungsmodus.

Andernfalls wären Dateityplisten erforderlich: eine Blacklist, die niemals komprimiert werden sollte, eine Whitelist, die immer komprimiert werden sollte, eine Heuristik für den Rest, die versucht, einen kleinen Teil der Datei zu komprimieren, und aufgibt, wenn die Größenreduzierung nicht erfolgt über einer bestimmten Schwelle.

Ich bin mir nicht sicher, wie gut dies auf dem Chunk und nicht auf der Dateiebene abgebildet werden würde.

Ich würde dagegen argumentieren, es zum Verschlüsselungs- / Entschlüsselungspass hinzuzufügen.
Wir möchten nicht verschiedene Arten von Daten mischen, da einige davon vorhersehbar sein können und die resultierenden Pack-/Blob-Längen Informationen über den Klartext der unvorhersehbaren/geheimen Daten preisgeben können.
Ich denke, es sollte pro Datei sein, auch wenn es dadurch "weniger schön" wird. Dies bringt jedoch den Vorteil mit sich, dass zum Lesen einer Datei keine streunende Dekompression von Tonnen von Pack-Dateien (bei denen jeweils nur ein Blob zählt) durchgeführt werden muss.

@teknico

Wie oben erwähnt, sollte es einen automatisierten, nicht konfigurierbaren Weg geben, um den Versuch zu vermeiden, nicht komprimierbare Dateien wie Medien, verschlüsselte oder bereits komprimierte Dateien zu komprimieren.

Mein modifiziertes Deflate-Paket implementiert das Überspringen bereits komprimierter Daten und dies mit einer Geschwindigkeit von ~250 MB/s pro Kern. Das Go 1.7 deflate unterstützt das nur bei den schnellsten Kompressionsstufen.

Snappy und LZ4 unterstützen eine ähnliche Skipping-Funktionalität.

Es wäre am einfachsten, einfach einen Algorithmus zu verwenden, der dies transparent handhabt, wie den Modus der konstanten Zeitkomprimierung.

Es sollte auf jeden Fall eine Option sein. In Go 1.7 (jetzt HuffmanOnly und mein Äquivalent genannt) unterstützt dieser Modus ~200 MB/s pro Kern, unabhängig von der Eingabe. Die Komprimierung wird jedoch im Vergleich zur "besten Geschwindigkeit", die typischerweise mit 80 MB/s/Kern arbeitet, stark behindert.

@cfcs

Ich denke, es sollte pro Datei sein, auch wenn es dadurch "weniger schön" wird.

Generell stimme ich zu. Restic muss ich mal nachlesen. Ist die Binärgröße jeder Packungsgröße unverschlüsselt verfügbar?

@klauspost Es sieht so aus, als ob einige Ihrer Verbesserungen in den Go 1.7 DEFLATE "BestSpeed" -Modus integriert wurden, ist das richtig? Das wäre vielleicht eine vernünftige Vorgabe.

Der Vorteil der Verwendung des DEFLATE-Formats besteht darin, dass viele verschiedene Kompressoren verfügbar sind, die kompatible Bitstreams erzeugen, sodass es für den Dekomprimierer vollständig transparent ist.

Aufgrund der Art, wie restic funktioniert (Dateien in Blobs aufteilen, behandelt nur Blobs danach) ist der einfachste Weg, die Komprimierung auf Blob-Ebene hinzuzufügen. Vielleicht könnten wir einige Heuristiken hinzufügen, um zu entscheiden, ob ein Blob komprimiert werden soll oder nicht, aber das kann der zweite Schritt sein.

Blobs werden zu Packdateien zusammengefasst, die dann im Repository gespeichert werden. Eine Packdatei enthält eine Reihe von (separat verschlüsselten) Blobs, gefolgt von einem (verschlüsselten) Header, gefolgt von der (unverschlüsselten) Headerlänge. Angreifer ohne Entschlüsselungsschlüssel sehen nur den Geheimtext, die Headerlänge und die Dateilänge. Basierend auf der Größe der Packdatei und der Headerlänge könnten Angreifer also die durchschnittliche Größe eines Blobs in einer bestimmten Packdatei berechnen, aber das war es auch schon. Die Indexdateien enthalten auch alle Daten (Größe, verschlüsselte Größe und später dann vielleicht die komprimierte Größe), aber auch diese sind verschlüsselt. Ich sehe hier kein Risiko.

Eine "komprimierbare" Testheuristik ist sowohl fehleranfällig als auch relativ teuer. Ich würde schätzen, dass es schwer wäre, weit über 200 MB/s/Kern zu kommen - das ist die Geschwindigkeit des Lookups der Ordnung 1 im Dedup-Paket auf AMD64.

Außerdem hängt es stark vom verwendeten Kompressor ab. Snappy wäre nicht in der Lage, zufällige Basis-64-Daten zu komprimieren, aber Deflate würde es zum Beispiel tun, also würde ich diesen Teil dem Kompressor überlassen - wir haben das für Snappy, LZ4 und Deflate eingebaut.

@fd0 Entschuldigung, ich meinte pro Blob, nicht pro Datei.
Wenn wir uns nicht für einen leichten Algorithmus entscheiden, wird die etwas CPU-lastige Komprimierung wahrscheinlich zu einem Engpass (neben AES, das in Zukunft hoffentlich von AES-NI übernommen wird).

@fd0 - Ich habe einen schnellen "Kompressibilitätsschätzer" erstellt: https://play.golang.org/p/Ve5z3txkyz - er schätzt die Vorhersagbarkeit und Entropie beliebiger Daten. Allerdings sollte es, wie gesagt, eher dem Kompressor überlassen bleiben.

borg 1.1 wird 2 "Kompressionsentscheider" haben:

  1. Entscheiden Sie pro Datei basierend auf der Übereinstimmung des Pfadmusters ( *.zip , *.mp3 , /htdocs/photos/* , ...)
  2. falls unentschlossen, entscheiden Sie sich pro Chunk, verwenden Sie lz4 als Test für Komprimierbarkeit - wenn das komprimiert wird, komprimieren Sie erneut mit der gewünschten Komprimierung (lz4, zlib, lzma), wenn nicht, komprimieren Sie nicht.

@klauspost hm, dieser Test ist auf meinem Rechner nicht so schlecht:

BenchmarkCompressibility-4           100      10345544 ns/op     810.84 MB/s

Benchmark-Code ist hier: https://gist.github.com/908c23123dda275a479cf931f2784f5d

Lz4 hat keinen Entropie-Codierer, daher wird es oft falsch negativ sein
wahrscheinlich?

Ich denke, wir brauchen drei Modi (weltweit):

  • Alle Datenblobs mit einem linearen Zeitkomprimierer komprimieren (Standard)
  • Keine Kompression
  • Max. Komprimierung (für Leute mit viel CPU-Leistung, aber nur geringer Bandbreite)

Ich möchte Baumobjekte (JSON) immer komprimieren, daher sollten wir einen geeigneten Algorithmus für ASCII-Text auswählen.

Ansonsten baue ich mit nachdenken .

Die Gedanken?

@klauspost hm, dieser Test ist auf meinem Rechner nicht so schlimm

Ich vergesse immer, wie wahnsinnig gut der neue Go-Compiler kann. Mindestens das Doppelte von dem, was ich erwartet hatte.

Ich denke, wir brauchen drei Modi (weltweit):

Deflate macht alle 3 ziemlich gut, obwohl es effizientere Kompressoren gibt (meistens LZMA). Entleeren ohne Komprimierung ist natürlich unnötig, aber natürlich schnell und mit minimalem Overhead, so dass ein allgemeiner Entleerungsansatz verwendet werden könnte, mit der Möglichkeit, später andere zu spezifizieren.

Ich habe angefangen, nach einer anderen Beschleunigung zu Go 1.7-Änderungen testen, bevor ich zu neuen Dingen übergehen kann.

Wenn Sie nur einen einzigen Komprimierungsalgorithmus wünschen, sollten Sie sich den neuen Anwärter zstd ansehen: https://github.com/facebook/zstd

Es wurde vom gleichen Entwickler wie lz4 entwickelt und hat eine bessere Komprimierungsrate als gzip, ist aber mehr als dreimal schneller: https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -zstandard/

zstd sieht sehr vielversprechend aus, obwohl ich in Go keine Implementierung finden konnte.

Die offizielle Seite http://facebook.github.io/zstd/#other -languages ​​verlinkt auf diese Go-Implementierung: https://github.com/DataDog/zstd

Oder meinst du eine reine Go-Implementierung?

Ja, meinte eine reine Go-Implementierung. Im Moment hängt restic von keinem C-Code ab, und das möchte ich im Idealfall auch beibehalten.

Gibt es eine Prognose für die Implementierung der Komprimierung?

Die Implementierung der Komprimierung hängt von der Änderung des Repository-Formats ab (Planung/Ideen sind in #628), was große Sorgfalt erfordert. Also nein, es gibt kein definitives Datum, wann die Komprimierung hinzugefügt wird ;)

Können wir etwas tun oder dazu beitragen, dass dies geschieht?

Ich glaube nicht, sorry :wink:, es braucht nur Zeit.

Also dachte ich, ich kann meinen Prüfstand von #790 noch einmal benutzen. In meinem Restic-Build habe ich alle Verschlüsselungen entfernt und dann noch einmal ein vollständiges Backup erstellt. Es kam in der gleichen Größe wie verschlüsselt - hier gibt es keine Überraschungen. Aber dann habe ich das Repository komprimiert und gefunden:

35G backup-unencrypted
6.4G    backup-unencrypted.tgz2

Was für ein Unterschied! Zum Vergleich hier die Größe eines einzelnen komprimierten Datenbank-Dumps:

1.7G    single-backup.sql.gz

Ich habe 29 davon oben. Ungefähr 100-fache Einsparungen im Vergleich zu regulären Backups!

Da ich alle Stellen gefunden habe, an denen Verschlüsselung hinzugefügt wurde, denke ich, dass ich eine sehr einfache konfigurierbare Komprimierung mit einer standardmäßigen gzip Implementierung hinzufügen kann, mit der Möglichkeit, in Zukunft eine andere Komprimierungs-Engine zu verwenden. Irgendwelche Einwände?

(Ich werde mir wahrscheinlich zwei Wochen Abende geben, um erfolgreich zu sein oder zu scheitern.)

Danke für deine Recherche und die Veröffentlichung der Ergebnisse hier! Ich habe ähnliche Ergebnisse erwartet. Um ehrlich zu sein: Ich werde nichts zusammenführen, was die Krypto entfernt oder sogar optional macht. Das ist etwas, was wir später tun können, aber es muss sorgfältig geplant werden.

Das Hinzufügen von Komprimierung mag auf den ersten Blick einfach erscheinen, ist es aber nicht. Wir müssen sehr vorsichtig sein, um Restic nicht versehentlich für unerwartete Angriffe anfällig zu machen (dies ist dem TLS-Protokoll mehrmals hintereinander passiert (ja, ich bin mir bewusst, dass dies eine andere Situation ist)).

Das Wichtigste im ganzen Projekt ist nicht der Code: Es ist das Repository-Format. Die Benutzer vertrauen uns ihre Daten an und sind darauf angewiesen, dass sie Daten nach längerer Verwendung von restic wiederherstellen können. Daher ist die Stabilität des Repository-Formats von größter Bedeutung. Um die Komprimierung zu unterstützen, müssen wir also zuerst die nächste Version des Repository-Formats entscheiden (und implementieren). Die Diskussion ist hier: https://github.com/restic/restic/issues/628

Ich kann sehen, dass Sie sehr daran interessiert sind, dies zu implementieren (und sogar Code beizutragen), aber bitte verbringen Sie keine Zeit damit, bis wir uns auf das Repository-Format einigen und alle Aspekte dieses Problems besprochen haben. Vielen Dank!

Was die entfernte Krypto angeht, werde ich nicht vorschlagen, diese zusammenzuführen. Ich habe das nur gemacht, um zu sehen, ob eine Komprimierung funktioniert. Und ja, dies musste sorgfältig geplant werden (niemand möchte plötzlich die Möglichkeit verlieren, ein Repository mit deaktivierter Verschlüsselung zu überprüfen).

Da wir json.Unmarshal wir der Konfiguration beliebig viele neue Schlüssel hinzufügen. Wenn sie nicht im JSON gefunden werden, behalten sie einfach ihre Standardwerte bei.

Die Wahl des Algorithmus ist nicht der Hauptpunkt, verstanden: Aber nur für zukünftige Referenzen scheint Brotli ein starker Anwärter zu sein.

Soweit ich weiß, ist die Brotli-Komprimierung sehr langsam (iirc 60 mal gzip), daher wird sie für Daten empfohlen, die sehr häufig gelesen werden, verglichen mit dem Schreiben und Komprimieren, was bei Backups wahrscheinlich nicht üblich ist. Aber ja, gehen wir noch nicht ins Detail :)

Dies gibt einen guten Überblick über die verschiedenen Kompressionsalgorithmen.

Brotli ist immer schneller oder hat eine bessere Kompression. Kommt auf die Komprimierungsstufe an.

@ibib Wie kommst du zu diesem Schluss? Mir scheint, dass brotli langsamer erscheint als die meisten anderen (auf den gemischten Datensätzen), während es keine besonders erstaunlichen Komprimierungsraten erreicht. Vielleicht ist es besser für bestimmte Arten von strukturierten Daten?

Wie in den Vergleichen beim Squash-Benchmark aufgeführt, gibt es drei Parameter, an denen man sich orientieren sollte:

  • Erreichte Komprimierungsrate: Wie gut komprimiert wird, ist wichtig, um Speicherplatz (und I/O zum Backend) zu sparen.

  • Komprimierungsgeschwindigkeit: Ist wichtig, da wir diese Operation jedes Mal durchführen werden, wenn wir einen Block hinzufügen. Wir wollen also wirklich etwas, das mit AES-NI und allgemeinen I/O mithalten kann, um nicht zu einem Engpass zu werden. Wir möchten wahrscheinlich keinen Algorithmus auswählen, der langsamer komprimiert als dekomprimiert, da wir den gegenteiligen Anwendungsfall von Webbrowsern haben wie diese neuen Algorithmen (wie zstd , lz4 , brotli ) sind optimiert für (wir haben "oft komprimieren, selten dekomprimieren" im Gegensatz zu "einmal komprimieren, oft dekomprimieren").

  • Dekompressionsgeschwindigkeit: Die Dekompressionsgeschwindigkeit ist nur relevant, wenn wir wiederherstellen. Wenn wir mit einer langsamen Wiederherstellung einverstanden sind, können wir eine langsame Dekompressionsgeschwindigkeit akzeptieren. Auf der anderen Seite haben wir auch Metadaten, die wir nicht langsam dekomprimieren möchten, sodass möglicherweise sogar zwei verschiedene Algorithmen erforderlich sind.

Es scheint, dass density zu den schnellsten gehört, wenn auch nicht besonders effizient in Bezug auf das Kompressionsverhältnis. In Bezug darauf, kein Flaschenhals zu sein, scheint es uns (im Durchschnitt) ein 2:1 Kompressionsverhältnis fast kostenlos zu geben. Wenn wir 4:1 wollen, müssen wir einen anderen Algorithmus wählen, aber dann sitzen wir herum und warten darauf.

Wir haben auch zwei (mindestens?) verschiedene Arten von Daten: Die Indizes; und die Datenblöcke. Die beiden werden unterschiedlich verwendet, und ich denke, es könnte diskutiert werden, ob es sinnvoll wäre, unterschiedliche Algorithmen für sie zu wählen. Ich persönlich denke, wir sollten bei einem Algorithmus bleiben (was auch immer wir wählen), damit die Neuimplementierung von Restic (in einer neuen Sprache oder was auch immer) nicht unangemessen erschwert wird. Und damit wir uns nicht den Fehlern von zwei aufregenden Komprimierungsalgorithmen aussetzen, da diese für Eckfälle schwer zu testen sind.

Ich muss Ihren empfohlenen Kompromissen nicht zustimmen. Backups können zu einem geeigneten Zeitpunkt im Hintergrund ausgeführt werden (vielleicht mit nice 10). Die Wiederherstellung geschieht unter Zeitdruck. Der relevante Kompromiss, den ich sehe, liegt zwischen Blockgröße und Komprimierungsverhältnis. Zu kleine Blöcke lassen sich nicht gut komprimieren und erhöhen den Metadaten-Overhead. Zu große Blöcke reduzieren das Deduplizierungsverhältnis. Bei den meisten Komprimierungsalgorithmen verbessern die höheren Einstellungen die Komprimierungsverhältnisse für kleine Eingaben nicht.

Darüber hinaus ermöglichen höhere Komprimierungsraten den Benutzern, mehr Versionen ihrer Daten auf demselben Speicherplatz zu speichern.

Denken Sie daran, dass meine Tests mit Snappy folgende Ergebnisse lieferten: 1) kleinere Backup-Größe (es komprimiert, normal) und 2) schnelleres Backup und Wiederherstellung (weniger Datenverschlüsselung, HMAC und Übertragung). Mit einem sehr billigen Laptop.

@cfcs Ich habe mich auf den Vergleich von gzip und brotli bezogen
image
Hier hat Brotli immer die schnellere und bessere Komprimierung.

@Crest Das ist fair genug, wir haben wahrscheinlich unterschiedliche Anwendungsfälle – ich verwende restic einfach nicht so wie du. Ich mache Backups von meinem Laptop und möchte, dass er schnell fertig wird, damit ich mit meinem Laptop gehen kann. Ich nehme an, Sie sprechen von Backups von Servern oder anderen ständig verbundenen Maschinen, bei denen die Backup-Rate nicht so wichtig ist. Ebenso muss ich nie alle meine Daten unter Zeitdruck wiederherstellen; Bei Zeitdruck (weil Sie es im beruflichen Kontext einsetzen?) kann ich die benötigten Daten gezielt wiederherstellen und den Rest später erledigen.

Sie machen einen sehr guten Punkt über die "viele kleine Eingaben";

@viric Der Effekt, auf den Sie sich beziehen, wird in den Squash-Benchmarks unter dem Abschnitt Transfer + Processing berücksichtigt :-)

@ibib ah, komm!

@ibib kannst du verlinken, woher du das Diagramm hast?

Ich habe einige Tests mit Brotli und Zstd durchgeführt und festgestellt, dass meine Ergebnisse nicht mit denen des Squash-Benchmarks übereinstimmen. Dann habe ich verstanden, dass dieser Benchmark 1,5 Jahre alt ist.

zstd funktioniert bei mir sehr gut. Fast + High Ratio, und sein "Level" erlaubt eine sehr große Spanne zwischen Fast und High Ratio. Tolle Sache.

Brotli arbeitet für mich sehr langsam, mit keiner besseren Komprimierungsrate als einem viel schnelleren zstd. Und Brotli scheint sich auf kleine Dateien mit englischen Texten zu konzentrieren (es enthält ein englisches Wörterbuch). Für HTML-Komprimierung oder ähnliches.

Neuere Benchmarks habe ich gefunden: https://github.com/inikep/lzbench

Also warf ich meinen Teststand noch einmal gegen zbackup mit LZMA-Komprimierung.

35G backup-unencrypted
6.4G    backup-unencrypted.tgz
2.5G    zbackup

Beeindruckend, nicht wahr?

Es genügt zu sagen, dass zbackup eigene Einschränkungen und Nachteile hat.

Laut @viric lzbench link ist der am besten geeignete Kompressor also einer, der Backups nicht verlangsamt (hohe Kompressionsgeschwindigkeit?, >200 MB/s), der tatsächlich ein gutes Kompressionsverhältnis (>=50) hat, oder?

Also habe ich die Ergebnisse aus der nach Verhältnis sortierten Tabelle herausgefiltert.

Ich habe auch eine _schnelle_ Suche nach Go-Implementierungen durchgeführt (deshalb habe ich sie in der Tabelle behalten). Durchgestrichen bedeutet, dass ich keine Implementierung gefunden habe, die fast alles eliminiert hat. Da es nur eine schnelle Suche war, habe ich die Ergebnisse behalten. Ausnahme für zstd, das nur ein Wrapper ist.

| Kompressorname | Kompression| Entpacken.| Kompr. Größe | Verhältnis |
| -------------- | ------------| ------------| ------------ | ----- |
| zstd 1.1.4 -1 | 242 MB/s | 636 MB/s | 73654014 | 34,75 |
| Eidechse 1.0 -30 | 258 MB/s | 867 MB/s | 85727429 | 40,45 |
| Dichte 0,12,5 Beta -3 | 253 MB/s | 235 MB/s | 87622980 | 41,34 |
| gipfeli 2016-07-13 | 233 MB/s | 451 MB/s | 87931759 | 41,49 |
| markant 2011-12-24 -9 | 257 MB/s | 1263 MB/s | 90360813 | 42,63 |
| markant 24.12.2011 -6 | 295 MB/s | 1268 MB/s | 92090898 | 43,45 |
| quicklz 1.5.0 -1 | 346 MB/s | 435 MB/s | 94720562 | 44,69 |
| Eidechse 1.0 -20 | 284 MB/s | 1734 MB/s | 96924204 | 45,73 |
| markant 24.12.2011 -3 | 352 MB/s | 1222 MB/s | 97255186 | 45,89 |
| lzrw 15.07.1991 -4 | 243 MB/s | 392 MB/s | 100131356 | 47,24 |
| lzo1x 2,09 -1 | 394 MB/s | 551 MB/s | 100572537 | 47,45 |
| lz4 1.7.5 | 452 MB/s | 2244 MB/s | 100880800 | 47,60 |
| schnelllz 0.1 -2 | 243 MB/s | 469 MB/s | 100906072 | 47,61 |
| lzo1y 2,09 -1 | 397 MB/s | 556 MB/s | 101258318 | 47,78 |
| lzo1x 2,09 -15 | 406 MB/s | 549 MB/s | 101462094 | 47,87 |
| Dichte 0,12,5 Beta -2 | 480 MB/s | 655 MB/s | 101706226 | 47,99 |
| lzf 3,6 -1 | 251 MB/s | 565 MB/s | 102041092 | 48,14 |
| bissig 1.1.4 | 327 MB/s | 1075 MB/s | 102146767 | 48,19 |
| blosclz 2015-11-10 -9 | 220 MB/s | 696 MB/s | 102817442 | 48,51 |
| markant 24.12.2011 -0 | 384 MB/s | 1221 MB/s | 103072463 | 48,63 |
| lzo1x 2,09 -12 | 418 MB/s | 550 MB/s | 103238859 | 48,71 |
| Eidechse 1.0 -10 | 360 MB/s | 2625 MB/s | 103402971 | 48,79 |
| schnelllz 0.1 -1 | 235 MB/s | 461 MB/s | 104628084 | 49,37 |
| lzrw 15.07.1991 -3 | 226 MB/s | 449 MB/s | 105424168 | 49,74 |
| lzf 3,6 -0 | 244 MB/s | 550 MB/s | 105682088 | 49,86 |
| lzo1x 2,09 -11 | 424 MB/s | 560 MB/s | 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522 MB/s | 2244 MB/s | 107066190 | 50,52 |
| Tornado 0.6a -1 | 233 MB/s | 334 MB/s | 107381846 | 50,66 |
| memcpy | 8657 MB/s | 8891 MB/s | 211947520 |100,00 |

LZ4 sieht aus wie der am besten geeignete Kompressor?

schätze du willst lz4 (>=1.7.0 r129) und zstd (>=1.3.0), falls vorhanden. wir verwenden diese auch für borgbackup.

ABER zstd ist mit einer einzigen Ganzzahl sehr abstimmbar, von lz4-Geschwindigkeit bis besser
als xz-Komprimierung. Das würde glückliche Nutzer von Density langsamer machen
Kompression und die der schnellen Kompression. Ganz zu schweigen davon, dass zstd
dekomprimiert sehr schnell, unabhängig vom Komprimierungsaufwand.

lz4 ist ziemlich schmal ausgelegt.

Am Samstag, 16. Dezember 2017 um 09:50:49 -0800 schrieb TW:

Ich schätze, du willst lz4 und zstd, falls vorhanden. wir verwenden diese auch für borgbackup.

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/restic/restic/issues/21#issuecomment -352199097

--
(Escriu-me xifrat si saps PGP / Schreiben Sie verschlüsselt, wenn Sie PGP kennen)
PGP-Schlüssel 7CBD1DA5 - https://emailselfdefense.fsf.org/

Nun .. gemäß https://github.com/restic/restic/issues/21#issuecomment -250983311, um Restic-Abhängigkeit frei zu halten, ist zstd vorerst keine Option. Außerdem gibt es einige Threads zu Patent-/Lizenzierungsproblemen.

Bei xz und hohen Komprimierungsraten beträgt die schnellste Komprimierung selbst bei den niedrigeren Komprimierungseinstellungen laut Tabelle etwa 15 MB/Sek.

Wenn die Anforderung für schnelles Backup verringert wird, sagen wir >=30 MB/Sek., könnten wir Folgendes hinzufügen:

| Kompressorname | Kompression| Entpacken.| Kompr. Größe | Verhältnis |
| -------------- | ------------| ------------| ------------ | ----- |
| xz 5.2.3 -9 | 1,70 MB/s | 56 MB/s | 48745306 | 23.00 |
| xz 5.2.3 -6 | 1,89 MB/s | 58 MB/s | 49195929 | 23.21 |
| xz 5.2.3 -3 | 4,18 MB/s | 55 MB/s | 55745125 | 26.30 |
| zstd 1.1.4 -8 | 30 MB/s | 609 MB/s | 61021141 | 28,79 |
| zling 2016-01-10 -2 | 32 MB/s | 136 MB/s | 61917662 | 29,21 |
| xz 5.2.3 -0 | 15 MB/s | 44 MB/s | 62579435 | 29,53 |
| zling 2016-01-10 -0 | 38 MB/s | 134 MB/s | 63407921 | 29,92 |
| zstd 1.1.4 -5 | 88 MB/s | 553 MB/s | 64998793 | 30,67 |
| lzfse 2017-03-08 | 48 MB/s | 592 MB/s | 67624281 | 31.91 |
| libdeflate 0.7 -6 | 64 MB/s | 609 MB/s | 67928189 | 32.05 |
| brotli 2017-03-10 -2 | 98 MB/s | 289 MB/s | 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185 MB/s | 587 MB/s | 70164775 | 33,10 |
| Tornado 0.6a -4 | 91 MB/s | 197 MB/s | 70513617 | 33,27 |
| libdeflate 0.7 -3 | 96 MB/s | 602 MB/s | 70668968 | 33,34 |
| xpack 2016-06-02 -1 | 98 MB/s | 506 MB/s | 71090065 | 33,54 |
| Tornado 0.6a -3 | 119 MB/s | 188 MB/s | 72662044 | 34,28 |
| libdeflate 0.7 -1 | 117 MB/s | 570 MB/s | 73318371 | 34,59 |
| Eidechse 1.0 -42 | 90 MB/s | 938 MB/s | 73350988 | 34,61 |
| zstd 1.1.4 -1 | 242 MB/s | 636 MB/s | 73654014 | 34,75 |

Es gibt mehrere Deflate-Implementierungen, die jedoch nicht sicher sind, ob sie vergleichbar sind.
Linkes xz als Referenz
zstd sieht so vielversprechend aus. Schade, dass es keine Go-Implementierung gibt

@viric zstd ist nicht ganz lz4-Geschwindigkeit.

aber wenn man lieber nur einen als mehrere kompressoren haben möchte, ist zstd flexibler.

Verzeihen Sie meine Verspätung. Einige Kommentare:

Komprimierungsgeschwindigkeit: Ist wichtig, da wir diese Operation jedes Mal durchführen werden, wenn wir einen Block hinzufügen. Wir wollen also wirklich etwas, das mit AES-NI und allgemeinen I/O mithalten kann, um nicht zu einem Engpass zu werden. Wir möchten wahrscheinlich keinen Algorithmus auswählen, der langsamer komprimiert als dekomprimiert, da wir den umgekehrten Anwendungsfall von Webbrowsern haben, für den diese neuen Algorithmen (wie zstd, lz4, brotli) optimiert sind (wir haben "oft komprimieren, selten dekomprimieren" im Gegensatz zu "einmal komprimieren, oft dekomprimieren").

Nein, eine Komprimierung mit hardwarebeschleunigten AES-Geschwindigkeiten ist nicht erforderlich. Bei der Komprimierung geht es darum, Zeit gegen Größe zu tauschen. Es ist völlig zu erwarten, dass komprimierte Backups länger dauern werden.

Anstatt zum Beispiel restic für meine persönlichen Backups zu verwenden, verwende ich immer noch Obnam, da sie auf einem der kleinen Server, auf denen ich sie speichere, nicht komprimiert würden, würden sie nicht passen. Die Backups dauern bereits Stunden und laufen im Hintergrund, sodass ich es nicht einmal bemerke.

Es ist mir egal, ob die komprimierten Backups von restic länger dauern. Tatsächlich erwarte ich das, und das ist der Kompromiss, den ich eingehen muss. Ohne diese Art der Komprimierung wäre restic für mich nicht sinnvoll.

Dekompressionsgeschwindigkeit: Die Dekompressionsgeschwindigkeit ist nur relevant, wenn wir wiederherstellen. Wenn wir mit einer langsamen Wiederherstellung einverstanden sind, können wir eine langsame Dekompressionsgeschwindigkeit akzeptieren. Auf der anderen Seite haben wir auch Metadaten, die wir nicht langsam dekomprimieren möchten, sodass möglicherweise sogar zwei verschiedene Algorithmen erforderlich sind.

Wiederherstellungen werden viel seltener durchgeführt als Backups, daher ist die Dekomprimierungsgeschwindigkeit nicht so wichtig. Jemand erwähnte, dass sie oft unter Zeitdruck durchgeführt werden: Das ist wahr, aber es bedeutet nicht, dass Wiederherstellungen so schnell wie Backups oder annähernd so schnell sein müssen.

Wir haben auch zwei (mindestens?) verschiedene Arten von Daten: Die Indizes; und die Datenblöcke. Die beiden werden unterschiedlich verwendet, und ich denke, es könnte diskutiert werden, ob es sinnvoll wäre, unterschiedliche Algorithmen für sie zu wählen.

Es ist möglicherweise nicht notwendig (oder unbedingt eine gute Idee), die Indizes überhaupt zu komprimieren. Da es sich um Indizes handelt, ist es unwahrscheinlich, dass sie von vornherein gut komprimieren werden, da ihr einziger Zweck darin besteht, eindeutige Daten zu speichern.

Ich persönlich denke, wir sollten bei einem Algorithmus bleiben (was auch immer wir wählen), damit die Neuimplementierung von Restic (in einer neuen Sprache oder was auch immer) nicht unangemessen erschwert wird. Und damit wir uns nicht den Fehlern von zwei aufregenden Komprimierungsalgorithmen aussetzen, da diese für Eckfälle schwer zu testen sind.

Ich verstehe diese Bedenken, aber ich denke, das wäre ein Fehler. Zumindest muss das Repo-Format mehrere Komprimierungsalgorithmen zulassen, damit in Zukunft neuere hinzugefügt werden können. Es sollte wahrscheinlich steckbare Module für die Komprimierung geben, damit Benutzer diejenigen auswählen können, die sie verwenden möchten, z. B. könnte ich mir Debian-Pakete wie restic-xz , restic-zstd usw. vorstellen, die Benutzer installieren könnten, wenn sie wollten diese Algorithmen verwenden. Die Komprimierung von Backup-Daten sollte so abstrahiert werden, dass restic einer Komprimierungsfunktion einige Daten übergibt und diese wieder komprimiert zurückgibt, und restic sollte sich nicht darum kümmern, was dazwischen passiert; das gleiche für die Dekompression.

Wenn die Anforderung für schnelles Backup gesenkt wird, sagen wir, >=30 MB/Sek., könnten wir hinzufügen

Das erscheint mir vernünftig. Denken Sie daran, dass lokale Backups nur eine Art sind; Netzwerk-Backups werden weniger wahrscheinlich durch die Komprimierungsgeschwindigkeit eingeschränkt.

Aber auch hier sollte dies von den Benutzern eingestellt werden können, damit sie die geeignete Lösung für ihre Bedürfnisse auswählen können.

10$ Kopfgeld für ein :Bier: :)
image

++

Hier ist ein Link zur BountySource, falls jemand anderes etwas beitragen möchte
badge
https://api.bountysource.com/badge/issue?issue_id=6096108

Ich frage mich, ob dies in einer vom Benutzer konfigurierbaren Weise implementiert werden kann, so dass die Wahl zwischen Geschwindigkeit und Größe dem Benutzer überlassen bleibt. Ich würde eine höhere Komprimierung als Standard bevorzugen.

Lassen Sie uns entscheiden, wann wir dort ankommen. Fürs Protokoll: Ich bin damit einverstanden, dem Benutzer ein wenig Kontrolle in Bezug auf Geschwindigkeit und Größe zu geben.

+1 für restic, das eine Komprimierungsimplementierung benötigt. Ich verwende restic, um VM-Images auf Backblaze zu sichern, und würde diese gerne vor dem Hochladen komprimieren. In meinem Anwendungsfall würde ich fast unendlich viel Zeit/CPU eintauschen, um die Größe der übertragenen/gespeicherten Daten zu reduzieren. Mir ist jedoch klar, dass Geschwindigkeit für einige ein größeres Problem ist. Eine steckbare Architektur zu haben, bei der mehrere Algorithmen ausgewählt werden können, ist der Schlüssel.

Ich helfe gerne beim Testen, da dies weiter untersucht wird.

@fd0 Es ist schon eine Weile her, dass ich an der restic Code-Basis gearbeitet habe. Ist es möglich, dass Sie eine schnelle Anleitung zu einem guten Ansatz geben und wo ich suchen sollte?

@klauspost Es ist nicht so sehr das Hinzufügen von Komprimierung auf technischer Ebene, das ist ziemlich einfach, sondern wie wir das Repository-Format abwärtskompatibel aktualisieren. Ich bin gerade damit beschäftigt, den Archivierungsteil neu zu schreiben (damit hässliche Dinge wie #549 verschwinden), danach möchte ich die Komprimierung hinzufügen und dann auf Repo v2 wechseln.

Was halten Sie von dem Komprimierungsalgorithmus, den wir verwenden sollten? Ich denke darüber nach, drei Modi zu unterstützen:
1) Keine Kompression
2) "Linearzeit"-Komprimierung (fügt nicht viel CPU-Last hinzu)
3) "Maximale Komprimierung"

Vielleicht werden der erste und zweite Modus gleich sein, ich bin mir noch nicht sicher

Es wäre großartig, so etwas wie zstd verwenden zu können, aber als nativen Go-Code. Damian deutete an, dass es möglicherweise nicht viel Arbeit ist, entweder die Java- oder die C-Version zu portieren: https://twitter.com/dgryski/status/947259359628738560, kann ich irgendetwas tun, um Ihr Interesse zu wecken, das auszuprobieren? :)

Ich habe mir die Formatspezifikation von zstd angeschaut, und für mich ist es nicht trivial (gut). Die Java-Quellen sind nur Dekompression.

Für eine schnelle Komprimierung sollte LZ4 sehr gut funktionieren. Der Go-Port ist ausgezeichnet. zstd wäre besser, aber ich würde ein bewährtes Paket verwenden, es sei denn, Sie möchten die cgo-Implementierung verwenden.

Für die Mitte der Straße ist die Deflationskompression immer noch gut in Bezug auf Geschwindigkeit / Kompression. Gut getestet usw.

Hohe Komprimierung ist etwas schwieriger. Es scheint jedoch eine native LZMA(2) Go-Implementierung im Paket github.com/ulikunitz/xz zu geben . Die README enthält einige Vorbehalte bezüglich Stabilität und Leistung. Der xz-Wrapper ist nicht erforderlich, da Sie bereits Hash und Größe unkomprimiert haben. Ich kann es ausprobieren und sehen, wie es im Vergleich ist.

Ich habe mir die Quelle angeschaut, um die natürliche Stelle zu finden, um den Kompressionsschritt einzufügen. Für mich war es sinnvoll, hier Kompression und hier Dekompression zu haben . Aber ich sehe die Herausforderung darin, die Kompression zu identifizieren und zu verfolgen.

Sie können sich auch einen von mir erstellten "Kompressibilitätsschätzer" ansehen. Es gibt eine schnelle Einschätzung, wie komprimierbar ein Datenblob ist. Es arbeitet in der Regel mit >500 MB/s und kann daher verwendet werden, um schwer zu komprimierende Daten schnell abzulehnen.

Sie können sich auch einen von mir erstellten "Kompressibilitätsschätzer" ansehen. Es gibt eine schnelle Einschätzung, wie komprimierbar ein Datenblob ist. Es arbeitet in der Regel mit >500 MB/s und kann daher verwendet werden, um schwer zu komprimierende Daten schnell abzulehnen.

Ich liebe den Kompressibilitätsschätzer! Das Vermeiden von Versuchen, nicht komprimierbare Daten zu komprimieren, würde viel an Geschwindigkeit gewinnen.

Zstd hat so etwas eingebaut: [1]

Zstd übergibt inkompressible Daten schneller. Erwarte etwas > 1 GB/s

Obwohl ich keine expliziten Benchmarks dazu gefunden habe.

Das xz-Paket sieht nach einem guten Deal für lzma aus. Habe einige Schnelltests mit den Standardeinstellungen durchgeführt:

| Algorithmus | Ebene | Größe | Übergröße | Millisekunden | MB/s | Verhältnis |
|------------|-------|------------|------------|---- ----|--------|--------|
| lz4 | - | 1000000000 | 625968314 | 5454 | 174,85 | 62,60% |
| flatekp | 1 | 1000000000 | 391051805 | 12367 | 77,11 | 39,11 % |
| flatekp | 5 | 1000000000 | 342561367 | 20164 | 47,3 | 34,26% |
| flatekp | 9 | 1000000000 | 324191728 | 43351 | 22 | 32,42 % |
| lzma2 | | 1000000000 | 291731178 | 149437 | 6,38 | 29,17% |
| lzma | | 1000000000 | 291688775 | 161125 | 5,92 | 29,17% |

Sehr vernünftiger Kompromiss zwischen Geschwindigkeit und Kompression. Alle sind Single-Core-Performance auf enwik9 - mittlerer komprimierbarer Textkörper. Offensichtlich hatte ich keine Zeit, ein vollständiges VM-Image oder so etwas wie den 10-GB-Korpus mit mehr gemischten Inhalten zu

Es scheint nicht, dass lzma2 in seiner aktuellen Implementierung viel über Standard-lzma bietet. Da es sich um kleine Blöcke handelt, sollte der Unterschied recht gering sein.

Zstd hat so etwas eingebaut

Ja, genauso wie lz4 und deflate, allerdings habe ich es nicht so schnell wie eine dedizierte Funktion gesehen.

zstd ist wirklich beeindruckend, kein Zweifel. Benchmarks mit der cgo-Implementierung:

| Ebene | Größe | Übergröße | Millisekunden | MB/s | Verhältnis |
|--------|------------|----------|--------|--------- -|--------|
| 1 | 1000000000 | 358512492 | 5100 | 186,96 | 35,85% |
| 2 | 1000000000 | 332265582 | 6264 | 152,24 | 33,23% |
| 3 | 1000000000 | 314403327 | 8099 | 117,75 | 31,44% |
| 4 | 1000000000 | 310346439 | 8588 | 111,04 | 31,03 % |
| 5 | 1000000000 | 305644452 | 12739 | 74,86 | 30,56 % |
| 6 | 1000000000 | 292551252 | 18531 | 51,46 | 29,26 % |
| 7 | 1000000000 | 287414827 | 23212 | 41,08 | 28,74% |
| 8 | 1000000000 | 282783804 | 27811 | 34,29 | 28,28 % |
| 9 | 1000000000 | 280432907 | 31752 | 30.03 | 28,04% |

Verzeihen Sie, wenn ich etwas übersehen habe, aber ich habe diese Fragen zuvor nicht beantwortet gesehen.

  1. Wir scheinen über Komprimierung auf Chunk-Ebene zu sprechen, nicht auf Dateiebene, richtig?
  2. Wenn dies der Fall ist, schränkt dies offensichtlich die Effektivität ein, da duplizierte Daten in mehreren Teilen einer einzelnen Datei gespeichert und für jeden Teil komprimiert werden.
  3. Dies hängt jedoch natürlich auch von der Größe des Chunks ab.
  4. Also, was ist die durchschnittliche Chunk-Größe? Scheint ein wichtiger Faktor dafür zu sein, wie nützlich die Komprimierung ist.
  5. Wenn die Chunk-Größe ziemlich klein ist, sollten wir vielleicht eine vollständige Datei-Pre-Chunking-Komprimierung für stark komprimierbare Dateien in Betracht ziehen (zB mit dem Schätzer von

Vielen Dank.

Wenn wir ganze Dateien komprimieren würden, könnte dies den Deduplizierungsalgorithmus manipulieren und ihn möglicherweise weniger effizient machen.

Abgesehen davon dürfen wir nicht vergessen, dass jede Kompression, obwohl sie enorme räumliche Vorteile bietet , uns für einen Seitenkanalangriff öffnet. Aus der Größe komprimierter Daten kann man eine fundierte Vermutung über den Inhalt der Daten anstellen. Ich glaube, das wurde schon mal erwähnt, aber trotzdem.

@alphapapa

Wir scheinen über Komprimierung auf Chunk-Ebene zu sprechen, nicht auf Dateiebene, richtig?

Ja, auf der Chunk-Ebene.

Wenn dies der Fall ist, schränkt dies offensichtlich die Effektivität ein, da duplizierte Daten in mehreren Teilen einer einzelnen Datei gespeichert und für jeden Teil komprimiert werden. Dies hängt jedoch natürlich auch von der Größe des Chunks ab. Also, was ist die durchschnittliche Chunk-Größe? Scheint ein wichtiger Faktor dafür zu sein, wie nützlich die Komprimierung ist.

Wir streben 1 MiB an, aber es kann bis zu 8 MiB groß sein.

Wenn die Chunk-Größe ziemlich klein ist, sollten wir vielleicht eine vollständige Datei-Pre-Chunking-Komprimierung für stark komprimierbare Dateien in Betracht ziehen (zB mit dem Schätzer von

Zuerst möchte ich die Komprimierung auf Chunk-Ebene integrieren und sehen, wie gut das in realen Szenarien funktioniert. Wir können diese Idee später noch einmal aufgreifen.

@klauspost Vielen Dank, dass Sie sich die Zeit genommen haben, einige Algorithmen/Implementierungen und Ihre Empfehlungen zu vergleichen, ich weiß es zu schätzen! Obwohl es schön wäre, zstd zu haben, denke ich, dass es für das Projekt als Ganzes viel wichtiger ist, nicht von cgo abhängig zu sein. Und die Verwendung eines Kompressibilitätsschätzers ist eine großartige Idee, das liebe ich.

Die Orte, die Sie zum Hinzufügen von Komprimierung/Dekomprimierung erwähnt haben, klingen gut, aber wir müssen die Metadaten dafür woanders nachverfolgen. Ich denke, wir werden Bits im Byte im Pack-Header wahrscheinlich eine Bedeutung hinzufügen, siehe http://restic.readthedocs.io/en/latest/100_references.html#pack -format. Dies ist der Teil, der sehr sorgfältig durchgeführt werden muss.

Also, lass mich mit #1494 abschließen, dann werden wir sehen, dass das gelöst wird.

@sanmai re: side-channels: Das habe ich ursprünglich
Es wurden verschiedene Lösungen vorgeschlagen, mit denen ich persönlich zufrieden wäre:

  • über Konfigurationsoptionen für Whitelisting/Blacklisting Verwendung von Komprimierung (ähnlich wie bei der Dateieinbindung)

Eine andere Idee war zu versuchen, die Chunk-Grenzen in den Packfiles zu verbergen, was es theoretisch schwieriger machen würde, aber ich denke, dass Sie immer noch Netzwerkschreibvorgänge und Seitenkanäle zeitlich festlegen können, wie zum Beispiel,

Das wäre toll! :Bier: +10€

Einfach wegwerfen, aber abgesehen von lzma oder einem der allgemeineren Komprimierungsalgos, was ist mit nur Run-Length-Codierung oder Zero-Squashing? Oder wäre dies nicht genug nützlich für genug Leute?

(Ich habe einen Hund bei dieser Jagd, ich sichere oft riesige WAV-Dateien mit viel Stille.)

+15 $

Einfach wegwerfen, aber abgesehen von lzma oder einem der allgemeineren Komprimierungsalgos, was ist mit nur Run-Length-Codierung oder Zero-Squashing? Oder wäre dies nicht genug nützlich für genug Leute?

Auch nützlich zum Sichern von VM-Laufwerken mit meist leerem Speicherplatz / Sparse-Dateien (nicht sicher, ob restic bereits Backup/Restore von Sparse-Dateien unterstützt)

@bherila restic unterstützt noch keine Archivierung/Wiederherstellung von Sparse-Dateien, die Dateien werden im Repository gespeichert, als ob sie nur viele Nullen enthalten würden. Diese großen Nullblöcke werden dedupliziert, sodass sie im Repository nicht viel Platz beanspruchen. Für die Wiederherstellung erhalten Sie jedoch eine normale (nicht mit Sparse besetzte) Datei ohne "Löcher".

Ich wollte nur mal nachschauen, gibt es schon eine Kompression? Ich habe mehrere Computer gesichert, darunter einen mit 50 GB Daten, und ich erhalte eine viel niedrigere Zahl auf dem Server:

# du -shc /home/restic/
40G     /home/restic/
40G     total

@Alwaysin Es ist wahrscheinlich die Deduplizierung , es sei denn, einige Dateien wurden natürlich ausgeschlossen.

@rawtaz danke, mir war die Deduplizierung nicht bewusst, muss so sein!

@iluvcapra Squashing von großen wiederholten Blöcken ist bereits durch Deduplizierung implementiert, wie von @rawtaz erwähnt.

@klauspost hast du das gesehen? https://github.com/mvdan/zstd

Ja, aber ehrlich gesagt ist ein Stream-Decoder der einfache Teil. Ich habe die FSE-En/Dekodierung abgeschlossen und einen Huffman-Encoder bereit. Sobald die Huffman-Decodierung abgeschlossen ist, ist ein zstd-Stream-Decoder ziemlich einfach, wobei der vollständige Encoder der letzte Teil ist.

LZ4 ist vollkommen ausreichend und wäre auch ein schneller Gewinn.

Warum nicht lz4 hinzufügen und einen weiteren PR erstellen, um zstd zu unterstützen?

Warum nicht lz4 hinzufügen und einen weiteren PR erstellen, um zstd zu unterstützen?

@dave-fl, weil wir sehr vorsichtig sein müssen, wenn wir das Repository-Format ändern. Dies muss abwärtskompatibel erfolgen. Der wichtigste Teil des gesamten Projekts ist das Repo-Format, nicht die Implementierung. Die Leute verlassen sich darauf, dass wir das Format nicht vermasseln, damit sie ihre Daten wiederherstellen können :)

Ich denke, wir können mit der Komprimierung nicht zu lange warten. Ich habe gerade einige Tests an einigen Repositorys von Server-Backups durchgeführt, ich gewinne genau nichts, wenn ich das Repository gzip ! Wie @Alwaysin gewinne ich bereits 30% mit Deduplizierung.

Abwärtskompatibel, meinst du, Restic sollte beide Formate lesen oder ein Tool zum Migrieren vom alten zum neuen? Wenn Restic nicht auf v1.0.0 ist, glaube ich, dass es in Ordnung ist, einfach zu migrieren.

Ich habe gerade einige Tests mit einigen Repositorys von Server-Backups durchgeführt, ich gewinne genau nichts, wenn ich das Repository gzipiere!

Ähm, das ist zu erwarten: Alle Daten im Repo sind verschlüsselt, also kaum komprimierbar. Wenn eine Komprimierung verwendet wird, muss diese an den Daten vorgenommen werden, bevor sie verschlüsselt werden.

Ich sehe nicht, wie die Verwendung von LZ4 die Dinge nicht abwärtskompatibel macht. Kompression ist Kompression. Warum nicht mehrere Formate unterstützen?

Du hast recht, daran habe ich nicht gedacht.
Wenn ich jedoch den Quellcode gzipiere, gewinne ich nicht mehr als 30%, die Deduplizierung ist bei einem großen Verzeichnis mit vielen Duplikaten bereits sehr effizient. Aber natürlich kann es bei beiden beeindruckend sein.
Mit zpaq, das Komprimierung und Deduplizierung durchführt, gewinne ich nur ein wenig mehr, nicht so viel.
Ich bin sehr offen, um einen Zweig mit Komprimierung zu testen, egal ob er nicht kompatibel ist!

Ich sehe nicht, wie die Verwendung von LZ4 die Dinge nicht abwärtskompatibel macht. Kompression ist Kompression. Warum nicht mehrere Formate unterstützen?

Was passiert, wenn 2 Clients dasselbe Repository verwenden, aber einer von ihnen eine ältere Version von Restic verwendet, die keine Komprimierung unterstützt? Diese Funktion muss sorgfältig unter Berücksichtigung aller möglichen Eckfälle entwickelt werden.

Ich würde keine Komprimierung einer halb funktionierenden Lösung vorziehen, die möglicherweise frühere Backups bricht.

Ich denke, es gab genug Diskussionen über das Hinzufügen von Komprimierung. Ich kann sehen, dass es ein mit Spannung erwartetes Feature ist. Ich werde dies als nächstes angehen, nachdem ich den neuen Archivierungscode fertiggestellt habe (siehe #1494).

Bitte keine weiteren Kommentare hinzufügen, danke!

@dimejo Was Sie sagen, hat nichts mit dem zu tun, was ich vorgeschlagen habe. Ob Sie zstd oder lz4 implementieren, würde sich auf beide Fälle auswirken.

Ich wage zu behaupten, dass die CGO-Version von zstd etwas portabel aussieht :)

Ich habe mir angeschaut, wie machbar es wäre, eine Golang-Implementierung von zstd zu schreiben, ganz kurz, basierend auf der Spezifikation .

zstd meistens alle internen Algorithmen, verlässt sich aber (optional) auf die xxHash-64-Prüfsumme zur Fehlerprüfung, und es gibt eine Golang-Portierung davon . Da optionale Bits optional sind, müssten Sie diese Teile nicht implementieren, um zstd-Unterstützung für einen Leser/Schreiber in Restic zu erhalten. zstd unterstützt das Konzept von "Wörterbüchern", um die Komprimierung zu optimieren - ich bin mir nicht sicher, wie das mit restict interagieren würde, aber es wäre ein interessantes Forschungsgebiet, um bestimmte Teile des Archivs zu komprimieren, zB JSON oder Metadatenströme. andernfalls könnte diese Implementierung auch übersprungen werden, da sie optional ist.

Schwieriger wird es natürlich bei der Entropiecodierung. zstd verwendet dort einen neuartigen Ansatz namens Finite State Entropy (FSE, eine Variation von [ANS](https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#, von denen auch nur eine C-Implementierung existiert Andere Entropie-Codierungsbits werden mit Huffman-Codierung implementiert, von denen es mehrere Implementierungen gibt, darunter zwei in der Standardbibliothek: eine in Compress.flate und eine andere in net.http2.hpack , das heißt eher komisch.

Soweit ich das beurteilen kann, ist alles andere noch Klebstoff... Einige Huffman-Bäume, Sequenzen, Frames und Blöcke. Es gibt auch interessante Eigenschaften in der Art und Weise, wie Blöcke und Frames erstellt werden, die sich gut in restic Blobs abbilden lassen, was es möglicherweise ermöglicht, das Repository als Ganzes zu komprimieren, während Blobs darin getrennt bleiben, obwohl ich mich nicht im Detail damit befasst habe . Es könnte auch eine Kopplung zwischen dem Repository-Format und der Komprimierung inakzeptabel machen.

zstd ist mit etwa 70k Codezeilen (laut cloc) im Vergleich zu 36k bzw. 12k wesentlich komplizierter als gzip oder xzip. dazu gehören jedoch zahlreiche Tests: Wenn diese ignoriert werden, ist die Implementierung selbst ungefähr vergleichbar mit gzip (~34k).

Zusammenfassend lässt sich sagen, dass es nur eine Frage der Zeit ist, bis dies in go implementiert wird. Ich glaube, eine solche Engine könnte auch die Parallelität von Golang nutzen, da zstd "Frames" voneinander unabhängig sind. Es ist mir jedoch unklar, wie Frames verwendet werden: Die meisten Streams, die ich getestet habe, hatten nur einen ( zstd /etc/motd ) oder zwei ( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) Frames (wie von binwalk -R "\x28\xb5\x2f\xfd" ). also vielleicht nicht so ein Gewinn, weil Blöcke miteinander verbunden und weniger parallelisierbar sind ...

Wie auch immer, alles strittig, es sei denn, jemand hier möchte sich tatsächlich hinsetzen und das portieren, aber ich dachte, ich würde teilen, was ich beim Lesen des Dings gefunden habe ... Es ist nicht unmöglich zu portieren...

Gibt es ein Update zur Komprimierung? Ich weiß, dass viele Leute auf zstd warten wollen, aber was wäre falsch daran, lz4 oder lzo oder lzma zu implementieren?

Wenn es ein Update gäbe, würde dieses Problem aktualisiert.

Versuchen wir jedoch, die Bitte des Autors in der Zwischenzeit zu respektieren:

Bitte keine weiteren Kommentare hinzufügen, danke!

@fd0 , wollte nur darauf hinweisen, dass es eine reine Go-Implementierung des zstd-Algorithmus zu geben scheint https://github.com/klauspost/compress/tree/master/zstd . Das habe ich selbst nicht probiert. Aber das hat mich für die Möglichkeit der Kompressionsunterstützung in Restic begeistert.

Ich kenne das Go-zstd-Zeug nicht (Geschwindigkeit? Codequalität? Wartung?), aber das C-zstd-Zeug ist so ziemlich alles, was ein Backup-Tool braucht, da es einen weiten Bereich von schneller/wenig bis langsamer/hoher Komprimierung unterstützt.

Wenn wir nicht bereits alle anderen Komprimierungsalgos (lz4, zlib, lzma) in borgbackup hätten und jetzt mit dem Hinzufügen von Komprimierung beginnen würden, könnten wir nur mit zstd und keinem leben.

Je nach Geschmack/Präferenz könnte die Standardeinstellung keine (wie zuvor) oder ein sehr schnelles zstd-Level sein (das insgesamt die meisten Backups immer noch schneller macht, da weniger Daten übertragen werden müssen).

Hallo,
Kompression ist meiner Meinung nach kein Muss für Restic. Ich habe die Sicherung meiner Daten mit Duplicati (mit Komprimierung) und Restic (ohne Komprimierung) verglichen und der insgesamt verwendete Speicherplatz war wirklich ähnlich.
Ich benötige restic nur, um ein schnelles und zuverlässiges inkrementelles Backup zu erhalten. Das Gebiss muss nicht gebrochen werden...
Auch die Wiederherstellung ist wichtig und restic eignet sich für die Notfallwiederherstellung. Duplicati ist ein Albtraum, denn wenn Sie die lokale Datenbank verloren haben, dauert die Reparaturaufgabe Tage ...

Danke @fd0 und danke an alle Mitwirkenden!

@filippobottega Wenn Sie in Ihrem Experiment keinen großen Unterschied gesehen haben, bedeutet dies entweder:

  • dass Ihre Daten nicht (stark) komprimierbar waren (aber das ist im Allgemeinen nicht der Fall), oder
  • dass duplicati eine etwas komprimierungsunabhängig schlechtere Speichereffizienz hatte (zB aufgrund unterschiedlicher Speicherformate, Granularität, Algorithmen, was auch immer...), so dass die Komprimierungseinsparungen durch Verluste in anderen Bereichen ausgeglichen wurden.

beides bedeutet nicht, dass Komprimierung sinnlos ist.

@ThomasWaldmann Ich sehe aus dem ersten Grund keinen großen Unterschied.
Daten werden heute bereits in vielerlei Hinsicht komprimiert: docx, xlsx, pptx, zip, 7z, jpeg, tif usw. sind alle komprimierte Formate. Und auch ISO-Images enthalten komprimierte Dateien. Aus diesem Grund ist Komprimierung im Restic meiner Meinung nach sinnlos.

@filippobottega Ihre Ansicht ist etwas engstirnig, welche Daten Leute restic zum Backup verwenden. Was ist mit SQL-Dumps, Quellcode, Datensätzen, Rohbildern und so weiter? Die Deduplizierung leistet hervorragende Arbeit bei der Reduzierung der Deltagröße zwischen Backups, trägt jedoch nicht dazu bei, die ursprüngliche Größe des Datasets zu reduzieren. Bei unkomprimierten Formaten kann dies viele Gigabyte bedeuten. Ganz zu schweigen davon, dass das Speichern eines unkomprimierten Formats und das anschließende Komprimieren + Deduplizieren bessere Ergebnisse liefern können als das Deduplizieren der bereits komprimierten Dateien.

SQL-Dumps waren mein erster Gedanke, aber restic sichert auch meinen Mailserver und es scheint insgesamt eine bessere Komprimierung zu erhalten, basierend auf einigen RAR-Snapshots, die ich beim Wechsel von Duplicati zu restic gemacht habe.

Ich kann den Anwendungsfall sehen, um die Komprimierung optional zu machen und eine Standardliste von Dateitypen zu haben, aber die Komprimierung würde mir eine angemessene Menge Geld sparen.

@mrschyte

Ihre Ansicht ist ein bisschen engstirnig, was die Leute mit Restic für Backups verwenden.

Jetzt müssen Sie nicht mehr persönlich werden. Seine Perspektive ist genauso gültig wie Ihre und es lohnt sich, darüber nachzudenken. Ich habe festgestellt, dass die meisten von mir gesicherten Daten aufgrund der Dateiformate bereits komprimiert sind.

Was ist mit SQL-Dumps?

Speichern Sie Ihre SQL-Dumps wirklich unkomprimiert? Ich gz alle meine, bevor ich sie sichere, weil ich sie nicht roh lagern muss.

Quellcode, Datensätze, Rohbilder und so weiter

Ich denke, der einzige gültige Anwendungsfall für komprimierte Backups sind große, unkomprimierte Dateien mit vielen Wiederholungen _die aktiv verwendet werden und daher nicht bereits komprimiert gespeichert werden_. Meiner Erfahrung nach (einschließlich jahrelanger Verwaltung der Daten anderer Personen) fallen nur sehr wenige Daten in diese Kategorie. Zumindest nicht genug, um in diesen Fällen einen großen Unterschied zu machen.

die ursprüngliche Größe des Datensatzes wird dadurch jedoch nicht verringert.

Das ist wohl nicht die Aufgabe eines Backup-Programms. Es sollte die Originaldaten nicht berühren.

Ganz zu schweigen davon, dass das Speichern eines unkomprimierten Formats und das anschließende Komprimieren + Deduplizieren bessere Ergebnisse liefern können als das Deduplizieren der bereits komprimierten Dateien.

Viele Komprimierungsalgorithmen verlassen sich auf Duplizierung, um ihre Arbeit zu erledigen (siehe die Wörterbücher von flate), daher bin ich davon _im Allgemeinen_ nicht überzeugt, obwohl ich zustimme, dass dies zumindest manchmal richtig ist.

(Ich sage nicht, dass die Komprimierung in Restic _schlecht_ ist, wenn sie richtig durchgeführt wird, ich argumentiere nur, dass sie keine Priorität haben muss – insbesondere im Vergleich zu anhaltenden Leistungsproblemen – und wir sollten die Zeitbeschränkungen von @fd0 respektieren und Wünsche bezüglich des Sehens.)

@mholt Ich würde im Allgemeinen zustimmen, aber ein Root-Backup (über einen Dump oder sogar das Iterieren des Inhalts von /) ergibt für mich ein schönes Komprimierungsverhältnis. Nicht unbedingt erforderlich , da der Gesamtverbrauch bereits gering ist, aber ich erhalte rund 50% Ersparnis, und das ist immer schön, wenn es für den Endverbraucher "kostenlos" ist.

Versuchen Sie diesen Test.

  1. Nehmen Sie einen SQL-Dump oder eine andere unkomprimierte Datei. Komprimiere es und dann
    Verwenden Sie restic, um es zu sichern.
  2. eine Tabelle aus der SQL-Datenbank entfernen, einen zweiten Dump erstellen und dann komprimieren,
    Verwenden Sie dann restic, um es zu sichern.

Ich glaube, Sie werden das feststellen, weil die Komprimierung VORHER erfolgt
Deduplizierung werden Sie den Restics-Deduplizierungsalgorithmus fast vollständig besiegen.
Wenn Restic jedoch die Komprimierung nach der Deduplizierung bewältigen könnte
sollte eine viel kleinere Gesamtleistung erhalten.

In der Enterprise-Storage-Branche mit Tools wie DataDomain ist es immer
empfohlen, die Daten unkomprimiert auf das Speichergerät zu übertragen
formatieren und das Gerät die Deduplizierung und dann die Komprimierung durchführen lassen. Die
Die allgemeine Reihenfolge, in der diese Tools angewendet werden sollten, ist die Deduplizierung,
Komprimierung, dann Verschlüsselung. Denken Sie eine Sekunde darüber nach....
Ich möchte wirklich die ganze zusätzliche CPU aufwenden, um die gleichen Daten mehrfach zu komprimieren
mal nur, damit es sowieso dedupliziert und im Wesentlichen verworfen wird? Es ist
allgemein anerkannt, dass es am besten ist, den Datensatz zuerst durch Deduplizierung zu reduzieren
bevor Sie die potenziell schwere Aufgabe der Komprimierung aufwenden.

Am Fr, 2. August 2019 um 13:29 Uhr Brandon Schneider [email protected]
schrieb:

@mholt https://github.com/mholt Ich würde im Allgemeinen zustimmen, wie auch immer
ein Root-Backup (über einen Dump oder sogar eine Iteration des Inhalts von /),
ergibt für mich ein schönes Kompressionsverhältnis. Nicht zwingend erforderlich , da die Summe
gebraucht ist schon klein, aber ich bekomme rund 50% gespart, und das ist immer schön
für den Endverbraucher "kostenlos" zu haben.


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVDZLOKTORWS5WWZ
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

Speichern Sie Ihre SQL-Dumps wirklich unkomprimiert? Ich gz alle meine, bevor ich sie sichere, weil ich sie nicht roh lagern muss.
Das ist wohl nicht die Aufgabe eines Backup-Programms. Es sollte die Originaldaten nicht berühren.

Sie haben das Gefühl, dass diese Art von Ansicht die effiziente Speicherung von Daten behindert? Die Idee, dass jedes Programm und jeder Exportvorgang sein eigenes Adhoc-Komprimierungsformat implementieren sollte, ist etwas, von dem ich versuche, wegzukommen, weil es verhindert, dass Deduplizierung/Komprimierung/usw. an etwas anderem als einem vordefinierten pro Datei (oder Verzeichnis-Tarball) Bereich arbeitet . Durch das individuelle Komprimieren von Dateien geht die Möglichkeit verloren, Gemeinsamkeiten zwischen verschiedenen Dateien/Dumps/usw. zu finden, und folglich verlieren Sie alle Vorteile der Deduplizierung. Wenn Sie Dinge unkomprimiert halten, kann ein Dateisystem (zfs, btrfs usw.) dies alles für Sie tun, und besser, da es sowohl Ordner, Snapshots usw mit den unkomprimierten Daten.

Die Komprimierung kann nur als zusätzliche Optimierung der Deduplizierung von restic angesehen werden, aber sie scheinen miteinander inkompatibel zu sein, wenn sie separat durchgeführt werden ... Der Vorschlag, Dateien vor dem Sichern zu komprimieren und vorzuverarbeiten, bringt alles in einen Workflow zurück, in dem Sie es auch können Verwenden Sie stattdessen einfach rsync/rclone, warum also überhaupt restic verwenden?

Sie haben das Gefühl, dass diese Art von Ansicht die effiziente Speicherung von Daten behindert? Die Idee, dass jedes Programm und jeder Exportvorgang sein eigenes Adhoc-Komprimierungsformat implementieren sollte, ist etwas, von dem ich versuche, wegzukommen, weil es verhindert, dass Deduplizierung/Komprimierung/usw. an etwas anderem als einem vordefinierten pro Datei (oder Verzeichnis-Tarball) Bereich arbeitet . Durch das individuelle Komprimieren von Dateien geht die Möglichkeit verloren, Gemeinsamkeiten zwischen verschiedenen Dateien/Dumps/usw. zu finden, und folglich verlieren Sie alle Vorteile der Deduplizierung. Wenn Sie Dinge unkomprimiert halten, kann ein Dateisystem (zfs, btrfs usw.) dies alles für Sie tun, und besser, da es sowohl Ordner, Snapshots usw mit den unkomprimierten Daten.

Es geht nicht nur um die effiziente Speicherung von Daten, sondern auch um die bestehenden Workflows. Ich möchte, dass ein Backup-Produkt meine Daten zuverlässig und effizient sichert und keine Workflows für andere Aspekte des Systems erzwingt. Es ist viel wichtiger, dass Backups (die möglicherweise auf unbestimmte Zeit aufbewahrt werden) effizient gespeichert werden, während Live-Arbeitsdaten im besten Format für ihre aktive Verwendung gespeichert werden sollten.

Nun gibt es Fälle, in denen es sinnvoll ist, vor dem Speichern zu komprimieren, insbesondere bei sehr komprimierbaren Daten auf langsamen Speichersystemen, aber dies ist meiner Erfahrung nach eher die Ausnahme als die Regel.

+1 Komprimierung würde mir wirklich helfen! Bei der Arbeit als Softwareentwickler sichere ich meinen gesamten Home-Ordner, der viel unkomprimierten Quellcode enthält (und in dynamischen Sprachen wie Ruby oder Python ist es fast immer Quellcode – sogar die meisten Abhängigkeiten).

Zu Hause sichere ich mein gesamtes / , wieder einschließlich vieler Dinge, die von der Komprimierung profitieren, wie Binärdateien, Man-Dateien, Ressourcendateien usw.

Natürlich könnte ich sie alle komprimieren und viele Transformationen vornehmen, bevor ich sie kopiere, aber das würde die Bequemlichkeit, nur einen sehr einfachen Befehl auszuführen und so einfach eine Sicherung zu erhalten, zunichte machen Dinge wiederherstellen.

Natürlich gibt es viele Klassen von Dateien, die sich nicht gut komprimieren lassen, aber niemand sagt, dass sie gezwungen werden sollten, komprimiert zu werden. Es gibt viele Ansätze, um dies zu lösen - Whitelist, welche Dateitypen komprimiert werden sollten, Blacklist, welche Dateien nicht sein sollten, oder sogar der einfachste: Versuchen Sie zu komprimieren, und wenn sich die resultierende Größe nicht verbessert, speichern Sie unkomprimiert (ich glaube ZFS verwendet diesen Ansatz, wenn die Komprimierung auf der Festplatte aktiviert ist).

Letztendlich ist die Komprimierung ein Beispiel für den klassischen Kompromiss zwischen Raum und Zeit: Wollen Sie mehr CPU oder mehr Speicher bezahlen? In meinem Fall dominiert der Speicher meine Kosten, daher denke ich, dass es großartig wäre, wenn sich mein Quad-Core etwas mehr aufheizen würde und dann meine Rechnung für das Dateihosting geringer wäre.

Schließlich sichere ich etwas mehr als 4 TB bei einem Cloud-Anbieter und meine Upload-Geschwindigkeit ist sowieso schwach, so dass eine Bonuskomprimierung meinen Backup-Prozess schneller und nicht langsamer machen würde – meine CPU kann mit meiner schlechten VDSL-Verbindung mehr als mithalten .

Ja, ich kann allen anderen hier nur zustimmen. Kompression ist ziemlich wichtig und ich sehe wirklich kein Argument, warum restic sie nicht haben sollte.

@mholt da stimme ich dir
In meiner Toolkette kommt die Komprimierung vor der Restic Deduplication, weil ich beispielsweise TFS als Quellcodeverwaltung verwende und alle Quellen bereits in SQL-Backups komprimiert sind und Anwendungsimages in MSI-Setup-Dateien oder 7z-Archiven komprimiert sind. Ich brauche nur einen schnellen und einfachen Weg, um das tägliche Delta abzurufen und in die Cloud zu senden, um einen sicheren Disaster-Recovery-Plan zu implementieren.
Ich denke, dass @fd0 seine Zeit darauf konzentrieren muss, Probleme zu lösen, als zu versuchen, dem Produkt andere Komplexität hinzuzufügen.

Ich habe nur einen kleinen Vergleich gemacht zwischen Borg mit auto,zstd Komprimierung und Restic (keine Komprimierung), zuerst auf / , dann auf /home , ausgenommen Dinge wie VM-Images und Docker-Images (da ich sie auch nicht in einem echten Backup sichere). Die Testmaschine war meine tägliche Softwareentwicklungsmaschine, die viele Binärdateien, einige komprimierte Bilder und Audiodateien, aber auch eine ganze Menge Klartext-Quellcode enthält, der recht gut komprimieren sollte:

/ : 1053136 Dateien, 92,9 GiB

  • borg, keine: 17:27 min, 64,1 GiB
  • borg, zstd: 19:29 min, 40,6 GiB
  • Rest: 09:45 min, 62,4 GiB

/home : 221338 Dateien, 58,3 GiB

  • borg, zstd: 09:06 min, 30,7 GiB
  • Rest: 04:36 min, 39,4 GiB
    Ich habe hier borg ohne Komprimierung weggelassen, da es in Bezug auf den Speicherplatz ungefähr dasselbe wie restic ist.

Erstens möchte ich Restic dafür loben, dass er in diesem Testfall fast genau doppelt so schnell ist. Abgesehen davon, dass Borg langsamer ist, könnte es von Interesse sein, dass die Komprimierung nur ~2 Minuten zur Gesamtsicherungsdauer hinzufügt (+11%), aber die zu speichernden Daten für den Fall / (-35 %). Im Fall meines Home-Verzeichnisses beträgt die Speicherersparnis etwa 20 %.

(Der Test wurde für diesen Fall auf einer externen Festplatte durchgeführt. Bei der Sicherung auf einen Remote-Speicher hängt die Dauer der Sicherung hauptsächlich von der Upload-Bandbreite ab, zumindest wenn die CPU- und IO-Geschwindigkeit viel höher ist als das Netzwerk. Ich habe getestet this und borg mit Komprimierung ist dann tatsächlich schneller als restic, weil die Komprimierung dazu führt, dass weniger Daten übertragen werden). Alles in allem bin ich sehr dafür, dass Restic Kompressionsunterstützung erhält, idealerweise die automatische Erkennung verwenden, um zu überprüfen, ob ein Chunk von der Kompression profitiert.

@nioncode Wenn meine Berechnungen korrekt sind,

Ich weiß, dass das Archivieren von VMs ein Anwendungsfall sein kann, aber ich versuche, dies zu vermeiden.
Ich versuche, die gesamte VM-Erstellung ausgehend von ISO- und Setup-Dateien zu automatisieren.
Im Falle einer Disaster Recovery möchte ich in der Lage sein, die gesamte VM mithilfe des Backups von Setup-Dateien, Dokumenten und Datenbank-Backups wiederherzustellen. Und ich versuche, es ohne Benutzerinteraktion zu tun.
Auf diese Weise kann ich vermeiden, dass viele in einer VM enthaltene Papierkorbdateien wie temporäre Dateien, unkomprimierte Dateien wie exe und dll usw. komprimiert und gesichert werden müssen.
Ich weiß, ist nicht einfach, aber ich kann es vermeiden, die gleichen und unbrauchbaren GB an Dateien zu komprimieren und zu deduplizieren, um Speicherplatz und Bandbreite zu sparen.

Lassen Sie uns diesen Thread nicht überladen, wer die Dinge wie macht. Es hat gereicht.

Komprimierung ist eine Funktion, die viele Leute wünschen (mich eingeschlossen) und sie kann bei langsamer bis mittlerer Internetverbindung sowohl Backup-Speicher als auch Upload-Zeit sparen, für manche Leute sogar 30% oder mehr.

Allerdings braucht es nicht jeder und manche Leute haben ihren Workflow clever angepasst, um damit umzugehen – oder haben einfach das Geld oder die Bandbreite oder beides, um sich einfach nicht darum zu kümmern.

Auf jeden Fall haben beide Seiten gesprochen.

@bjoe2k4 oder sind besorgt über die negativen Sicherheitsauswirkungen der Komprimierung von Daten vor der Verschlüsselung, die Informationen über die Klartextdaten preisgeben, wie es in diesem Thread in den letzten Jahren auch mehrmals als Argument

Wenn die Komprimierung nicht obligatorisch wird, sind die Sicherheitsbedenken der Komprimierung einfach ein Kompromiss, den ein Benutzer eingehen kann. Ich werde schnellere Backups machen und die monatlichen und einmaligen Kosten gegenüber diesem theoretischen Risiko reduzieren (ein Risiko, das wahrscheinlich sowieso nicht ausgenutzt werden könnte, da meine Datensätze groß und die Änderungen unvorhersehbar sind, so dass der Lärm jeden Versuch übertönen würde, eine Datei zu generieren Signal von der Kompression).

Ich glaube nicht, dass irgendjemand davon spricht, die Komprimierung obligatorisch zu machen.

Mein besonderer Anwendungsfall ist das Sichern von GROßEN Sätzen von CSV- und SQL-Dumps. Diese Dateien wären SEHR komprimierbar ... und ich möchte/kann sie nicht vorkomprimieren.

Ich würde die Komprimierungsfunktion wirklich gerne haben, da ich für jedes GB Online-Speicher bezahle

Da diese Diskussion jetzt etwas aktiver wird, möchte ich einige meiner Erkenntnisse mit einer gepatchten Restic-Version einiger meiner Freunde teilen. Sie haben restic eine Komprimierung hinzugefügt (mehr oder weniger schnell und schmutzig, soweit ich weiß) und ich werde sie über diesen Beitrag benachrichtigen, damit sie sich bei Interesse zu den Implementierungsdetails äußern können.
Mein Anwendungsfall ist eine wirklich hässliche Banking-Software, die ein eigenes Datenbankformat hat. Wir müssen diese Software aus regulatorischen Gründen verwenden und die Daten, die wir haben, sind mehrere TB ziemlich großer Dateien, die auf 90% ihrer ursprünglichen Größe komprimiert werden können. Ganz offensichtlich würde uns die Komprimierung also viel an Backup-Speicher, Backup-Zeiten und Wiederherstellungszeiten sparen.
Meine Erkenntnisse beim Vergleich von Restic Upstream, dem gepatchten Restic mit Komprimierung und unserer aktuellen Backup-Lösung mit tar findet ihr hier: https://gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f

| Werkzeug | Backup-Zeit (m:s) | Wiederherstellungszeit (m:s) | Backup-Speicherplatz (G) | Backup-Speicherplatz (%) | Backup (MB/s) | Wiederherstellen (MB/s) |
| -------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| Teer | 4:42 | 5:19 | 11 | 9,6% | 404 | 357 |
| Restic S3 lokaler Upstream | 10:04 | 30:56 | 102 | 89,5% | 189 | 61 |
| Restic S3 lokale Komprimierung | 5:43 | 19:28 | 8,6 | 7,5% | 332 | 98 |
| Restic Local Upstream | 8:33 | 26:06 | 102 | 89,5% | 222 | 73 |
| Restic Local Compress | 5:21 | 16:57 | 8,6 | 7,5% | 355 | 112 |
| Restic S3-Fernbedienung Upstream | 17:12 | 46:06 | 102 | 89,5% | 110 | 41 |
| Restic S3 Remote Compress | 5:27 | 21:42 | 8,6 | 7,5% | 349 | 88 |

Ich denke, restic würde mit optionaler Kompression jeglicher Art massiv gewinnen, weil es so ziemlich alles reduziert.

Nicht jede Datei hat ein interessantes Komprimierungsverhältnis. Das Komprimieren einer Videodatei ist wahrscheinlich wertlos, aber das Komprimieren eines SQL-Dumps ist es mit Sicherheit. Aus diesem Grund versuchen Dateisysteme wie Btrfs zuerst, die ersten 128 KB einer Datei zu komprimieren, und wenn es ein signifikantes Kompressionsverhältnis gibt, komprimieren sie dann die gesamte Datei. Es ist definitiv nicht perfekt, aber es ist schnell und sollte für die meisten Anwendungsfälle funktionieren, wenn Dateien einzeln komprimiert werden sollen.

Für diejenigen, die gegen die Bereitstellung von Komprimierung als Option argumentieren, ist mein Anwendungsfall, dass ich eine Mischung aus meist komprimierbaren Dateitypen sichere, auf deren Inhalt ich keine Kontrolle habe und es unangemessen ist, von mir zu erwarten, dass ich die Daten komprimieren muss mehrere Maschinen (die entweder beim Komprimieren in ein neues Archiv mehr lokalen Festplattenspeicher belegen oder die Dateien für die zugehörigen Anwendungen unbrauchbar machen, wenn sie an Ort und Stelle komprimiert werden), bevor eine Sicherungsoperation durchgeführt wird.

Ich würde es vorziehen, restic als mein DR-Backup-Tool verwenden zu können, aber ich verwende derzeit borg (langsame, massive RAM-Anforderungen usw.), da die resultierende Komprimierung + Deduplizierung mir viele Gigabyte Netzwerktransfer pro Backup-Vorgang spart und problemlos über ein Terrabyte Speicherplatz (für den ich monatlich bezahle) in der Cloud über mein gesamtes Backup-Set. Ich könnte Backups länger aufbewahren oder meine Speicherkosten reduzieren, wenn restic die Komprimierung unterstützt.

Hallo @joerg , danke, dass du deine Tests
Haben Sie versucht, die Ausgabe der Tar-Komprimierungsaufgabe mit restic zu sichern?
Ich bin gespannt auf den Vergleich von "Restic S3 Remote Compress" und "Tar" + "Restic S3 Remote Upstream".
Außerdem scheint das, was du sagst, nicht wirklich wahr zu sein:

Ich denke, restic würde mit optionaler Kompression jeglicher Art massiv gewinnen, weil es so ziemlich alles reduziert

Betrachtet man die Testergebnisse, scheint die von restic benötigte CPU-Zeit für lokale Sicherungen 2x länger und für Wiederherstellungen 6x länger zu sein. Nicht wirklich gut im Vergleich zu Tar.

tar ist kein Komprimierungsalgorithmus. natürlich geht es schnell.
EDIT: ach und btw. Wenn Sie ein Verzeichnis tarnen, werden nicht mehrere Threads pro Datei verwendet und es funktioniert auch nicht mit zwei oder mehr Dateien gleichzeitig, sondern scannt das Verzeichnis und fügt eine Datei hinzu und geht dann zur nächsten. ziemlich langsam. Das Problem ist jedoch die Archivdatei, die nicht für das Hinzufügen mit mehreren Threads ausgelegt ist.

Angesichts der Testergebnisse scheint die von restic verwendete CPU-Zeit beim lokalen Backup 2x langsamer und bei der Wiederherstellung 6x langsamer zu sein. Nicht wirklich gut im Vergleich zu Tar.

Ich bin mir Ihrer Aussage hier nicht ganz sicher. restic ist zwar langsamer als Tar, aber restic mit Kompression ist immer schneller als restic ohne, also würde restic eindeutig profitieren.

Tar ist ein nützlicher Vergleich mit einem „besten Fall auf dieser Hardware“, aber es fehlen die meisten anderen Funktionen von restic (Schnappschüsse und Datendeduplizierung fallen mir ein). Das Hinzufügen von Komprimierung scheint nur die Backup-Zeiten, die Wiederherstellungszeiten und die Speicherkosten zu verbessern, alles Dinge, die für ein Backup-Produkt wichtig sind.

@joerg Können deine Freunde einen Pull Request öffnen und ihre Patches für Restic mit Komprimierung öffentlich verfügbar machen? Welchen Kompressionsalgorithmus verwenden sie?

@joerg @thedaveCA
Ich entschuldige mich, ich habe die Bedeutung von @joergs Behauptung falsch verstanden. Eindeutig ist restic mit Kompression besser als restic ohne Kompression. Nun meine Frage: Tar + Restic ist besser oder nicht im Vergleich zu Restic mit Kompression?

Bitte beachten Sie, dass wir keine nackten Tar-Archive verwenden, sondern gzipped tar-Archive mit einer speziellen parallelen Zip-Implementierung, da sonst die Archivierung von Terabytes an Daten Tage in Anspruch nehmen würde statt der "nur" Stunden, die es derzeit dauert:
@shibumi Ich habe sie über dieses Thema und mein Posting informiert, sodass es nun an ihnen liegt, ob und inwieweit sie sich daran beteiligen möchten. Ich persönlich hoffe, dass sie diese Pull-Anfrage öffnen...

Komprimierung ist ein No-Go für Verschlüsselung. Es lässt einen Angreifer raten, ob ein verschlüsseltes Repository eine bestimmte Datei enthält, da ein Abschnitt (ein Stück) einer Datei unabhängig von einem verwendeten Verschlüsselungsschlüssel auf dieselbe Größe komprimiert wird. Dies ist eine sehr bekannte Schwachstelle von Verschlüsselungsprotokollen, weshalb die Komprimierung aus TLS 1.3 entfernt wurde.

Lassen Sie uns kein bekanntes Problem schaffen, wo keines ist, oder?

(Ich denke, dieses Problem wurde bereits erwähnt, und wahrscheinlich nicht einmal. Trotzdem ist dieses Thema offen, und ich denke, nur aus diesem Grund sollte es ein für alle Mal geschlossen werden.)

Warum spammst du das Problem? :( Es wurde so oft diskutiert, dass es fast offtopic ist. Du wirst nicht GEZWUNGEN, die Komprimierung zu aktivieren!!

Darüber hinaus denke ich, dass Ihre Angriffsidee erfordert, dass der Angreifer in der Lage ist, die zu komprimierenden und zu verschlüsselnden Daten zu kontrollieren (ich bin mir jedoch nicht sicher!). https://en.m.wikipedia.org/wiki/CRIME

Aber in jedem Fall, auch wenn es sich um Sicherheitsbedenken handelt, möchte jemand die Komprimierung möglicherweise nur auf einen Speicher verwenden, der unter seiner eigenen Kontrolle steht, um einfach Speicherplatz zu sparen.

Sogar eine optionale Funktion, die die Verschlüsselung schwächt, lädt zu einem falschen Gefühl der Sicherheit ein. Restic behauptet, ein _sicheres_ Backup-Programm zu sein. Das Hinzufügen einer optionalen Komprimierung macht dieses Versprechen ungültig, da Sie manchmal nicht sicher sein können, nur Vollzeit, die ganze Zeit. Und es wird sicher CVE-Berichte geben. Wer wünscht sich für seine Software diese Art von "Beliebtheit"?

Aber ich denke, dass das Hinzufügen einer Komprimierung auf eine Weise, die niemals mit Verschlüsselung verwendet wird, eine praktikable Option ist.

FWIW im Jahr 2017 habe ich eine Demo erstellt, in der ich die Verschlüsselung von Restic entfernt habe, und gezeigt, dass die Komprimierung sehr effektiv sein kann . Hundertfach wirksam. Die IIRC-Komprimierung kann wie eine Verschlüsselung als eine Art Wrapper hinzugefügt werden, aber ich habe mir den Code schon lange nicht mehr angesehen, daher können die Dinge heutzutage schwieriger oder einfacher sein.

Tatsächlich muss CRIME die Länge des Geheimtextes kennen, was in restic im Grunde unmöglich ist.
auch gibt es kein "sicheres" Backup-Programm. Wenn die Backup-Dateien für Dritte zugänglich sind, besteht immer die Möglichkeit, dass jemand die Daten manipuliert oder, schlimmer noch, liest.
zu sagen, dass die Kompression es noch schlimmer macht, ist einfach dumm.

Tatsächlich muss CRIME die Länge des Geheimtextes kennen

CRIME braucht, aber Sie nicht. Stellen Sie sich vor, Sie sind ein investigativer Journalist, der von Ihrer Quelle eine Reihe streng geheimer Akten erhält. Sie sichern sie mit Verschlüsselung und niemand wird wissen, dass Sie diese Dateien haben.

Stellen Sie sich nun vor, Sie wären nicht schlau genug, um die Komprimierung zu aktivieren, und jetzt wissen alle anderen, die diese Dateien auch haben, nur nach der Größe der komprimierten und dann verschlüsselten Blöcke zu urteilen, dass Sie diese streng geheimen Dateien in diesem Archiv ohne sogar den Verschlüsselungsschlüssel kennen müssen. Das ist alles andere als sicher. Menschen können wegen dieses "Merkmals" ins Gefängnis gehen, gefoltert werden oder Schlimmeres.

es gibt kein "sicheres" Backup-Programm

Dieser braucht dann ein Update.

Fast, secure, efficient backup program

Beachten Sie auch standardmäßig sicher.

restic speichert nur verpackte Brocken, sodass die Größe der Brocken nicht ersichtlich ist
jemand hat die Schlüssel nicht.

Am Freitag, 09.08.2019 um 02:09:23 -0700 schrieb Alexey Kopytko:

Komprimierung ist ein No-Go für Verschlüsselung. Es lässt einen Angreifer raten, ob ein verschlüsseltes Repository eine bestimmte Datei enthält, da ein Abschnitt (ein Stück) einer Datei unabhängig von einem verwendeten Verschlüsselungsschlüssel auf dieselbe Größe komprimiert wird. Dies ist eine sehr bekannte Schwachstelle von Verschlüsselungsprotokollen, weshalb die Komprimierung aus TLS 1.3 entfernt wurde.

Lassen Sie uns kein bekanntes Problem schaffen, wo keines ist, oder?

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/restic/restic/issues/21#issuecomment -519844526

--
(Escriu-me xifrat si saps PGP / Schreiben Sie verschlüsselt, wenn Sie PGP kennen)
PGP-Schlüssel 7CBD1DA5 - https://emailselfdefense.fsf.org/

Für diejenigen, die mehr über diese Sicherheitsbedenken erfahren möchten, gibt es ein schönes Papier, das sie beschreibt http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
Nach meinem Verständnis könnte es einen Fehler geben, wenn die Datei in Stücke geschnitten und dann komprimiert und verschlüsselt wird. Aber wenn die Datei vor dem Chunking komprimiert wird, handelt es sich um eine Binärdatei wie jede andere, und diese Klartextangriffe werden nutzlos.

Aber wenn die Datei vor dem Chunking komprimiert wird, handelt es sich um eine Binärdatei wie jede andere, und diese Klartextangriffe werden nutzlos.

Das ist richtig. Aber das hilft nicht gerade bei der effizienten Deduplizierung, wenn ich das richtig verstehe, da ein Komprimierungsalgorithmus für jede Version einer Datei ein anderes Vokabular verwenden kann, was zu einem ganz anderen Binärergebnis führt. Was offensichtlich nicht deduplizieren wird. Ansonsten macht es nur Sinn, die resultierenden Chunks zu komprimieren.

restic speichert nur verpackte Brocken, sodass die Größe der Brocken für jemanden, der nicht die Schlüssel hat, nicht ersichtlich ist

Das ist eine Erleichterung.

Mein Punkt ist immer noch: Es gibt viele Möglichkeiten, einem Programm eine versteckte Schwachstelle hinzuzufügen, wenn es Komprimierung zusammen mit Verschlüsselung implementiert, also am besten überhaupt keine hinzufügen. Sogar Verschlüsselungsexperten, die sich für TLS entschieden haben, entschieden sich dafür, die Komprimierung zu entfernen. Vermutlich hatten sie eine ähnliche Argumentation.

btw.:

However, it is important to note that these attacks have little security impact on, say, a bulkencryption application which compresses data before encrypting

...
auch CRIME funktioniert nur, wenn Sie mehrere verschiedene Versionen der verschlüsselten Dateien haben.
dh mehrere Backup-Läufe (in verschiedene Repositories, von denen der Angreifer alle erhalten hat)
und es funktioniert auch nur mit einer kleinen Datenmenge.

CRIME braucht, aber Sie nicht. Stellen Sie sich vor, Sie sind ein investigativer Journalist, der von Ihrer Quelle eine Reihe streng geheimer Akten erhält. Sie sichern sie mit Verschlüsselung und niemand wird wissen, dass Sie diese Dateien haben.

Stellen Sie sich nun vor, Sie wären nicht schlau genug, um die Komprimierung zu aktivieren, und jetzt wissen alle anderen, die diese Dateien auch haben, nur nach der Größe der komprimierten und dann verschlüsselten Blöcke zu urteilen, dass Sie diese streng geheimen Dateien in diesem Archiv ohne sogar den Verschlüsselungsschlüssel kennen müssen. Das ist alles andere als sicher. Menschen können wegen dieses "Merkmals" ins Gefängnis gehen, gefoltert werden oder Schlimmeres.

das ist Quatsch. weil es nur mit einer kleinen Stichprobengröße funktioniert. Es kann auch immer noch möglich sein, ohne Komprimierung ins Gefängnis zu gehen. Vor allem zu einem bestimmten Zeitpunkt, wenn ein Angreifer Ihre Backup-Dateien erlangt hat, kann er sie in Zukunft möglicherweise brutforcen.
es könnten in Zukunft andere Sicherheitsprobleme auftreten usw.
die Diskussion wurde nur zu bedeutungsloser Angstmacherei.

@sanmai , dieses Beispiel

Stellen Sie sich vor, Sie wären ein investigativer Journalist ... Stellen Sie sich nun vor, Sie wären nicht schlau genug, um die Komprimierung zu aktivieren, und jetzt wissen alle anderen, die diese Dateien zufällig auch haben, nur nach der Größe der komprimierten und dann verschlüsselten Brocken zu urteilen Sie haben diese streng geheimen Dateien in diesem Archiv, ohne den Verschlüsselungsschlüssel kennen zu müssen.

Was ist gemeint? Dass jemand anhand der Größe erraten kann, dass ein verschlüsselter Snapshot diese Dateien enthält? Dies setzt voraus, dass die Dateien allein oder zusammen mit anderen bekannten Dateien komprimiert werden. Aber dann kann die gleiche Vermutung mit einem unverschlüsselten shapshot durchgeführt werden.

Wie wäre es eigentlich mit Gzipping von Dateien vor dem Sichern? Öffnet dies auch eine Sicherheitslücke?

Ich halte dieses Beispiel für schlichten Unsinn: Wenn Sie behaupten, Sie könnten feststellen, ob ein Snapshot komprimierte Versionen einiger (beliebiger) Dateien enthält, die Ihnen bekannt sind, können Sie auch feststellen, ob er diese Dateien unkomprimiert enthält.

Ich glaube nicht, dass die Komprimierung die Verschlüsselung wesentlich weniger sicher machen kann.

Die meisten Kompressions-Seitenkanalangriffe beinhalten mehrere Faktoren:
1) Angreifer kann die Eingabe kontrollieren
2) Angreifer kann die Größe der Ausgabe beobachten
3) Kleine Änderungen der Eingabedaten führen zu messbaren Änderungen der Ausgabegröße
4) Angreifer kann die Eingabe ändern und es Hunderttausende Male wiederholen

Im Gegensatz zu webbasierten Systemen, die in der überwiegenden Mehrheit restic Backups beinhalten, halten (1) und (2) selten gleichzeitig. Außerdem ist für die blockbasierte Komprimierung (3) nicht wirklich garantiert, und für die meisten Backup-Regimes gilt (4) sicherlich nicht. Da die Backup-Häufigkeit in der Regel einmal täglich oder so ist, würde es Tausende von Jahren dauern, um Daten zu manipulieren und die komprimierte Ausgabegröße zu überwachen, um signifikante Unterschiede zu bemerken, und das setzt voraus, dass sich keine anderen Daten ändern, was in den meisten Fällen der Fall ist wäre.

Wenn Sie Backups erstellten, bei denen die Ausgabegröße sichtbar war, sollten Sie die Komprimierung deaktivieren. Ansonsten gibt es wirklich keine praktischen Angriffe dagegen und es würde es nicht weniger sicher machen, es aktiviert zu haben.

restic führt bereits Deduplizierung durch, was es ohnehin denselben theoretischen Angriffen aussetzt wie Kompressionsseitenkanäle, und meines Wissens hat sich darüber niemand beschwert.

Tatsache ist, dass es Hunderte oder Tausende von Benutzern gibt, die von einer Komprimierungsfunktion ohne jegliche Nachteile profitieren würden. Können wir dieses fünf Jahre alte Problem bitte einfach den Entwicklern überlassen, die daran arbeiten?

um ehrlich zu sein .... ich bevorzuge das Konzept von restic ... aber ich habe Tests in meinem Usecase gemacht (viele CSV-Dateien und SQL-Dumps) und musste auf borg umsteigen.

Ich habe mit vier Generationen von inkrementellen Backups getestet und meine Dateien erhalten eine Komprimierung von 7:1 und zusammen mit der Deduplizierung erreiche ich > 20:1. Ich kann das nicht ignorieren, da ich bereits gesagt habe, dass ich meinen Online-Backup-Speicher pro GB bezahle.

root<strong i="7">@xxxx</strong>:~# borg list
2019-08-08_14:37                     Thu, 2019-08-08 14:37:10 [5e113a8102f2bd7e40d100343f849dc73843d145011c7214d5fa0895927eb6d1]
2019-08-08_22:28                     Thu, 2019-08-08 22:28:21 [17d815d000212a576610b2fd5688ab87cce00039bb89f63722c6a7819dec1821]
2019-08-09_02:00                     Fri, 2019-08-09 02:00:23 [217c53b07f30dfbca584c49468cfa624a2445a005890220509c97715f7007e81]
2019-08-10_02:00                     Sat, 2019-08-10 02:00:10 [5dd45b8ccf0aa382bf00d5b08e1d5d88daae014f0a1a42b3e2b0fc368623bba0]
root<strong i="8">@xxxx</strong>:~# borg info
Repository ID: xxxx
Location: ssh://xxxx
Encrypted: Yes (repokey)
Cache: /var/lib/borg/cache/xxxx
Security dir: /var/lib/borg/security/xxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               69.02 GB             11.24 GB              2.80 GB

                       Unique chunks         Total chunks
Chunk index:                    9227                41812

Was ist gemeint? Dass jemand _erraten_ kann, dass ein verschlüsselter Snapshot diese Dateien enthält, nur wenn er sich die Größe ansieht? Dies setzt voraus, dass die Dateien allein oder zusammen mit anderen bekannten Dateien komprimiert werden. Aber dann kann die gleiche Vermutung mit einem unverschlüsselten shapshot durchgeführt werden.

Genau. Schneiden Sie eine reine Textdatei in gleiche Teile, komprimieren Sie sie und verschlüsseln Sie sie dann. Nochmals aufschneiden, komprimieren und verschlüsseln. Da sich die Größe verschlüsselter Dateien AES-mäßig nicht ändert, würden Sie sehen, dass Sie in beiden Fällen eine Bereichsgröße haben, die wie ein Fingerabdruck zusammenpasst. Sie (und damit meine ich hauptsächlich Verwaltungen repressiver Regime wie Iran oder Russland) können vernünftigerweise davon ausgehen, dass diese Akten hier vorhanden sind, was beispielsweise den Grund gibt, den Verdächtigen weiter zu foltern. Ich verstehe nicht, warum euch diese Ideen so ärgern, sind sie nicht einfach zu verstehen? Das ist nicht per se KRIMINALITÄT, oder?

Aber wie bereits von @viric erwähnt , ist

Wird Restic durch das Hinzufügen von Komprimierung einer zusätzlichen Sicherheitsanfälligkeit ausgesetzt, da bereits Deduplizierung durchgeführt wird?

Wenn Ihr Anliegen ein Angreifer ist, der komprimierte Blockgrößen errät, um die unkomprimierte Größe abzuleiten, okay, aber macht die Komprimierung dies noch schlimmer? Hätte ein Angreifer nicht die gleichen grundlegenden Informationen?

Wenn ein Angreifer die unkomprimierten UND komprimierten Größen jeder Datei sehen könnte, könnte die Identifizierung realistischer werden, aber dies wäre in restic nicht möglich.

Letztendlich setzt Sie die Deduplizierung bereits jedem theoretischen Angriff aus, auf den sich die Komprimierung auswirkt, und natürlich kann die Komprimierung deaktiviert werden, um den aktuellen Stand der Dinge beizubehalten, wenn dies besser zu Ihrer Situation passt.

Ich verstehe einfach nicht, warum Sie über hypothetische Sicherheitsbedenken diskutieren, das Vorhandensein einer Datei zu erraten, indem Sie die Größe eines verschlüsselten Chunks sehen..,,

Benutzt ihr ZIP oder GZ? Dann sollte es dir gut gehen.

Glauben Sie, dass die iranischen Behörden meine Inhalte nach Größe erraten können? Dann einfach keine Komprimierung(!) verwenden. Das bedeutet einfach nicht, dass die Komprimierung nicht verfügbar sein sollte.

Ich denke, wir haben alle relevanten Aspekte des Hinzufügens von Kompression zu Restic abgedeckt. Vielen Dank für Ihren Beitrag.

Ich denke, wir sollten die Komprimierung hinzufügen und standardmäßig aktivieren, aber den Benutzern erlauben, die Komprimierung zu deaktivieren. Bitte haben Sie Geduld, bis ich noch etwas Zeit habe, daran zu arbeiten.

Ich habe das Gefühl, dass diese Diskussion außer Kontrolle gerät, daher schließe ich dieses Thema vorerst ab. Wenn Sie diese Diskussion fortsetzen möchten, besuchen Sie bitte das Forum . Vielen Dank!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen