Wie gut ist die Compression von Hyperbackup?

[framp]

Soweit ich im Netz Antworten zu der Frage gefunden habe kommt es eben auf die Daten drauf an. Sind sie komprimiert wird nix mehr komprimiert und ansonsten wir komprimiert.

Im konkreten Fall soll eine NAS mit mehreren TB auf eine BackupNAS mit Hyperbackup gesichert werden. Die Frage ist wie gross muss der Backupspace sein? Klar muss er groesser als die Quelle sein wenn mehrere Backupversionen gehalten werden sollen. Was ich so lese sollte der Backupspace wenigstens so gross sein wie die Source. D.h. eigentlich kann man die Kompression vergessen. Das gibt zwar u.U. ein paar Bytes - aber niemand kann das garantieren und somit sollte man auch wenigsten genausoviel Backupspace haben wie die Source.

Hyperbackup nutzt wohl rsync und Hardlinks um Backupspace ueber die Backupversionen zu sparen. Es gibt ja noch Deduplication um noch mehr Space zu sparen was Hyperbackup leider nicht kann :-(

Kurzum: Die Compression sollte man wohl ignorieren und immer wenigsten soviel Backupspace haben wie die Source. Oder sehe ich das falsch?

 

[ottosykora]

klar macht es Sinn die Kompression zu haben, auch wenn das etwas langsamer gehen könnte unter Umständen.
Bilder wie .jpg kann man so gut wie nicht komprimieren, weil das ist bereits komprimiert.
Aber es gibt Leute die vielleicht Office Files haben, oder ähnliches. Das kann man sehr viel komprimieren.

Und weil kaum jemand genau weiss welche Daten ins Backup gehen, macht es Sinn zu komprimieren.

Und wenn du die Datenbank Version machst, dann wird auch nichts unnötigerweise mehrfach gespeichert, die Datenbank ist ja dafür doch da.

 

[framp]

Und wenn du die Datenbank Version machst, dann wird auch nichts unnötigerweise mehrfach gespeichert, die Datenbank ist ja dafür doch da.

Sorry. Den Kommentar von Dir verstehe ich leider nicht

 

[ottosykora]

was nicht genau? Es gibt bei Hyperbackup doch die Einzeversion und die Versionierte auf Datenbak basiert

 

[framp]

Da muss ich wohl noch mal genauer eruieren. Dass man da was mit einer DB konfigurieren kann ist mir neu

 

[dil88]

Selbst Office-Files werden seit Jahren komprimiert. Ich selbst verwende die HyperBackup-Komprimierung nicht und denke auch, dass es zumindest im privaten Kontext normalerweise wenig Wirkung erzielt, dafür aber mehr Ressourcen benötigt. Sollte man gut komprimierbare Dateien sichern wollen, sieht die Sache anders aus. Für die nicht versionierte Variante von HyperBackup ("Eine Version") braucht man dann, wenn man die gelöschten Dateien auch im Backup löschen lässt, genauso viel Platz im Backup wie an der Quelle (Edit: wenn man unkomprimiert arbeitet). Beim versionierten HyperBackup braucht man für die Versionen mehr Platz auf dem Backup.

 

[framp]

Für die nicht versionierte Variante von HyperBackup ("Eine Version") braucht man dann, wenn man die gelöschten Dateien auch im Backup löschen lässt, genauso viel Platz im Backup wie an der Quelle

Das passt zu meinem EIndruck. Auf die Komprimierung ist kein Verlass und man sollte wenigsten denselben Space wie die Source haben. Wenn man dann ein RAID5 auf dem Backupserver nutzt natuerlich brutto noch etwas mehr.

D.h. man sollte wenigsten ein 1:1 Spaceverhaeltnis haben von Source zu Backup. D.h. also wenn man sich ein System aufbaut was man verstaendlicherweise immer sichern sollte braucht man den Space zweimal. Die Backup HW muss dann natuerlich nicht so performant sein wie die Source.

Schade - ich dachte da gaebe es Moeglichkeiten den notwendigen Backupspace zu reduziern

 

[Tommes]

Hi!

Hyperbackup nutzt wohl rsync und Hardlinks um Backupspace ueber die Backupversionen zu sparen

Ist das nur eine Vermutung von dir, oder weißt du das mit ziemlicher Sicherheit. Ich hab mir die Frage ehrlich gesagt noch nie wirklich gestellt, dachte bisher halt, das Hyperbackup das irgendwie in dessen Datenbank verwurstelt. Würden die tatsächlich Hardlinks dazu hernehmen, fände ich das irgendwie lustig, weil ich bei meinen Backup-Scripten ebenfalls mit Hardlinks arbeite und ich immer dachte, das das nicht (mehr) „State of the Art“ ist.

Und wenn du die Datenbank Version machst, dann wird auch nichts unnötigerweise mehrfach gespeichert, die Datenbank ist ja dafür doch da.

Das kannst du aber auch mit rsync und Hardlinks erreichen. Und sollte Hyper Backup in der Datenbankversion ebenfalls mit Hardlinks arbeiten, dann gäbe es demnach keinen Unterschied zur „dateibasierten Datensicherung“. Die Datenbank hätte somit nur Verwaltungstechnische Aufgaben. Reine Vermutung

Auf die Komprimierung ist kein Verlass und man sollte wenigsten denselben Space wie die Source haben.

Das sehe ich auch so, da sich unterschiedliche Datenformate auch unterschiedlich komprimieren lassen. Hinzu kommt, wie viele Dateiänderungen man im Schnitt zwischen zwei Sicherungen so durchführt, man über kurz oder lang eh ein Zuwach-Backup erhält. Auch halte ich es immer für ein wenig fragwürdig, wenn man ein komprimiertes Archiv nur mit der Hersteller Software öffnen bzw. verwalten kann. Würde Synology hier auf bekannte Komprimierer setzten, wäre ich auch wesentlich entspannter. Aber so…

 

[Tommes]

In diesem Artikel ist unter anderem zu lesen…

• Die Sicherung mehrerer Versionen braucht weniger Speicher durch:
  • Deduplizierung auf Datei-Ebene und inkrementelle Sicherung von Ordnern und Paketen
  • Deduplizierung auf Block-Ebene und inkrementelle Sicherung des gesamten Systems

Also nix mit Daten, die in einer Datenbank gespeichert werden.

 

[metalworker]

@framp ,

was genau ist denn eigentlich deine echte Frage?

Das der Backupspace größer sein sollte hast ja schon selbst erkannt.
Und alles andere hängt ja einfach von dir ab

 

[NSFH]

Die Kompressionsrate liegt bei 50% bei Nutzung BTRFS
Jetzt müsstest du noch wissen wieviel MB du pro Tag neu bzw verändert speicherst. Das kann ja nur ein durchschnittlicher Schätzwert sein.
Diesen Wert x 365 / 2 und dann plus erste Vollsicherung, dann weisst du ungefähr den Bedarf pro Jahr.

 

[framp]

@framp ,

was genau ist denn eigentlich deine echte Frage?

Das was im Titel steht und mit einem Fragezeichen endet

Bislang war ich der Meinung dass es von den Daten abhaengt und man deshalb immer wenigstens dieselbe Storagepoolgroesse haben.

Nun hat @NSFH geschrieben dass bei btrfs die Rate bei 50% liegt. Dass btrfs Compression kann war mir bislang nicht bewusst. Aber mir leuchtet ein dass ein Backup geringeren Space braucht wenn die Dateien schon compressed sind. Allerdings sollte man das wohl nur bei Daten machen die weniger genutzt werden da die Geschwindigkeit bei der Nutzung der Daten sinkt.
Aber dass man konkret sagen kann dass 50% Compression stattfindet erstaunt mich. Letztendlich haegt die Compressionrate ja immer von den Daten ab. Interessant ist dieser Reddit Beitrag zu dem Thema.

Ist meine folgende Folgerung richtig?
Wenn man btrfs nutzt und compression eingeschaltet hat fuer Shared Folder kann man bis zu 50% Space einsparen. Allerdings ist das nicht garantiert und abhaengig von den Daten so dass man auch bei btrfs immer wenigstens dieselbe Backupstoragepoolgroesse haben sollte. Bei ext4 compressed HyperBackup das Backup. Allerdings sind da die Compressionsraten nicht so gut.

Ist das nur eine Vermutung von dir, oder weißt du das mit ziemlicher Sicherheit.

Eine Vermutung. Da es mich bislang nicht im Detail interessiert hat habe ich das nicht weiter untersucht. jedefalls macht es fuer mich irgendwie Sinn denn dadurch wird der benoetigte Backupspace ja auch reduziert - nur eben nicht per compression.

Die Sicherung mehrerer Versionen braucht weniger Speicher durch:

• Deduplizierung auf Datei-Ebene und inkrementelle Sicherung von Ordnern und Paketen
• Deduplizierung auf Block-Ebene und inkrementelle Sicherung des gesamten Systems

"Inkrementelle Sicherung" spricht doch sehr fuer rsync und Hardlinknutzung. Dass noch eine Deduplizierung stattfindet ist sehr interessant. Wuerde mich interessieren wie und welches Tool das genau macht

 

[Tommes]

Für die Deduplizierung benötigt man sicherlich eine Datenbank. Ich habe das Thema heut morgen mal kurz überflogen und dabei werden wohl hashes aller Dateien angelegt, miteinander verglichen und dann bestimmt, was doppelt ist. Das könnte zwar durchaus in Kombination mit Hardlinks funktionieren, jedoch lese ich in diesem Zusammenhang nie etwas von Hardlinks. Egal... wenn es mich nochmal packt, lese ich mich weiter ein, für den Moment packt es mich aber nicht weiter. Ich mag die Hyper Backup Datenbankgeschichte eh nicht sonderlich, daher ist es mir relativ egal, wie die das machen. Ich bleib jedenfalls bei "dateibasiert" oder auch versioniert mittels Hardlinks.

 

[framp]

@NSFH Deine Berechnungsformel klingt gut mit einem Konpressionfaktor von 50%. Ist das jetzt wg btrfs oder ist der Faktor von Hyperbackup?

Ich habe mich mal etwas in Kompressionsalgorithmen eingelesen. Kompresste Dateien lassen sich nicht mehr kompressen. D.h. die Formel nur wenn die Dateien nicht kompressed sind. Auch kann man nicht allgemein einen Faktor fuer einen Algorithmus angeben da der Faktor immer abhaengig ist von den Daten. Die naechste Frage ist welcher Kompressionsagorithmus bei btrfs oder Hyperbackup genutzt wird.

 

[NSFH]

Kompression plus Deduplizierung soll nichts mehr bringen. Der entscheidende Faktor ist BTRFS plus Deduplizierung.
Habe dieses Wissen aber auch nur aus Fachinfos (CT).