Möglichkeit zum Erkennen, ob komprimieren lohnt.

[heinz]

Hallo Zusammen,

kennt jemand von Euch ein tool oder eine Möglichkeit eine Datei darauf hin zu testen
ob sich eine Komprimierung "lohnt", also ob die Datei wesentlich kleiner wird als das Original?
Natürlich ohne die Daten vorher zu komprimieren.

Ist das überhaupt möglich?

gruß heinz

[TRex]

Der Dateityp sollte das aufzeigen. Textdateien zB sind sehr gut komprimierbar, mp3-Dateien dagegen sind bereits komprimiert und lohnen sich daher kaum für eine Komprimierung. Entropie wäre das Stichwort, keine Ahnung, ob es da eine effiziente Messmethode gibt (die es anzuwenden lohnt, bevor man komprimiert).

[Liffi]

Ich wuerde da auch einfach file drauf anwenden. Schauen ob es darin das Wort text auftaucht. Wenn ja lohnt sich die Komprimierung.
Damit sollte man schon das meiste erschlagen koennen.
Ansonsten wuesste ich nicht, wie man es pruefen kann, ohne es wirklich zu tun.

[LessWire]

Mit steigender Prozessorleistung sind in den letzten Jahren die Algorithmen für die Komprimierung immer komplizierter geworden. Somit kann es keine sichere Methode zur schnellen Feststellung des zu erwartenden Resultats geben. Wie schon erwähnt, entscheidet man am besten anhand des Dateityps.

VG, LW.

[ralli]

Auch würde ich auf keinen Fall ganze Ordner komprimieren zur Datensicherung, wenn dann mal die Archivdatei kaputt ist, dann hast Du ganz schlechte Karten. Ich zweifel daran, ob bei der enormen Kapazität aktueller Festplatten sich eine Komprimierung überhaupt noch lohnt. Und es wurde schon angesprochen ich erweiter das mal, Multimedia Dateien sind alle bereits komprimiert, dazu zählen auch Videodateien unterschiedlicher Formate oder jpeg Bilder.

[pferdefreund]

Stimmt nicht ganz - Midi-Dateien kann man auch gut komprimieren - habs gerade getestet. Ne 20K Datei anschliessend nur noch 4k.
Gleiches gilt sicherlich auch für unkomprimierte Audio-Dateien. Hier kommt es aber sicherlich auch auf den Inhalt an.
Stille sollte sich gut komprimieren lassen - ansonsten ein Test eben 28.000 KB wurden 26.000 KB - recht wenig aber das
war auch eine Datei ohne Stille.

[uname]

Um eine Art möglichen Komprimierungsfaktor zu ermitteln kannst du dir einmal alle Bytes zählen lassen (Gesamtgröße) und die Anzahl der druckbaren Zeichen (Befehl "strings"). Je geringer der Quotient je sinnvoller ist eine Komprimierung.

Mal schnell zusammengehackt:

Code: Alles auswählen

#!/bin/bash
echo $(($(ls -l $1 | awk '{print $5}')/$(strings $1 |wc -c)))

Code: Alles auswählen

./programm.sh <dateiname>

Eine tar.gz-Datei hat einen Faktor von "13", so dass eine weitere Komprimierung eher wohl keinen Sinn macht. Eine tar-Datei hat einen Faktor von "1" (da reine Textdateien). Hier macht eine Komprimierung Sinn. Eine jpg-Datei hatte mit diesem Script einen Faktor von "10".

[Liffi]

Stimmt nicht ganz - Midi-Dateien kann man auch gut komprimieren - habs gerade getestet. Ne 20K Datei anschliessend nur noch 4k.
Gleiches gilt sicherlich auch für unkomprimierte Audio-Dateien. Hier kommt es aber sicherlich auch auf den Inhalt an.
Stille sollte sich gut komprimieren lassen - ansonsten ein Test eben 28.000 KB wurden 26.000 KB - recht wenig aber das
war auch eine Datei ohne Stille.

Bitmaps kann man vermutlich auch gut komprimieren. Letztlich muss man halt gucken, was fuer Dateitypen man hat und wie gross sie insgesamt sind. Sollte ja mit find und file und evtl. awk kein Problem sein.

[hikaru]

Bitmaps kann man vermutlich auch gut komprimieren.

Ja. Ein Beispiel für verlustfreie Bitmapkomprimierung ist PNG.

[yeti]

Code: Alles auswählen

(yeti@destiny:2)~/wrk/propeller/propgcc-hg$ xz -l *.xz
 Str.  Blöcke       Kompr.     Unkompr.  Verh.  Check   Dateiname
    1       1     21,7 MiB    214,8 MiB  0,101  CRC64   propgcc-0.2.3-r1119-debian-squeeze-32bit.tar.xz
    1       1    203,6 MiB    868,3 MiB  0,234  CRC64   propgcc-r1119.tar.xz
-------------------------------------------------------------------------------
    2       2    225,4 MiB  1.083,1 MiB  0,208  CRC64   2 Dateien

...was "xz -9e" da auf ca 22MBytes zusammenstauchte war in bzip2 noch >65 Mbytes groß.

Mich freut's trotz günstiger gigafetter Festplatten immer wieder wenn es einen noch besseren Kompressor gibt, denn auch die durch bessere Kompression kürzere Transferdauer erfreut Hoch- und Runterladenden.

Welche Daten sich womit gut komprimieren lassen hängt von ihrer Art und dem benutzten Kompressor ab. Mit einem verlustfreien Audio-Kompressor (flac) würde ich keine brauchbare Kompressionsrate bei einem Bündel aus zB allen zu GCC gehörenden Binaries erwarten... aber das wär glatt mal eine Versuchsreihe wert...

...und unkomprimierte Audiostreams berauschen mit Gzip zu Leibe gerückt sicherlich auch nicht durch schöne Kompressionsfaktoren...

Ich fürchte man kommt schlicht nicht um Ausprobieren herum...

[Fjunchclick]

Ich zweifel daran, ob bei der enormen Kapazität aktueller Festplatten sich eine Komprimierung überhaupt noch lohnt.

Genau so sehe ich das auch. Wenn man etwas per Mail oder Dsateiversand verschicken möchte, ist Kompression natürlich manchmal angebracht.
Aber ich würde z.B. niemals auf die Idee kommen, irgend welche Datenbackups zu komprimieren. Denn ein Backup muss im Falle eines Falles funktionieren und auf jeden Fall Zugriff ermöglichen. Da wäre mir jede Kompression einfach zu unsicher.

[peschmae]

kennt jemand von Euch ein tool oder eine Möglichkeit eine Datei darauf hin zu testen
ob sich eine Komprimierung "lohnt", also ob die Datei wesentlich kleiner wird als das Original?
Natürlich ohne die Daten vorher zu komprimieren.

Kannst du etwas konkreter werden - um was geht es denn genau? Dann werden die Antworten auch etwas konkreter (und wer weiss, vielleicht sogar richtig nützlich) ausfallen...

MfG Peschmä

[ralli]

Also so richtig erschließt sich mir auch nicht, was Du praktisch machen willst und für was das gut sein soll. Konkretisiere doch mal Dein Vorhaben, oder ist das rein theoretischer Natur?

[heinz]

Hallo Zusammen,

erstmal Danke für die vielen Antworten!

Der Dateityp sollte das aufzeigen.
Entropie wäre das Stichwort.

Da es um Dateien geht die von verschiedenen Systemen stammen (Win., Mac, Dos, ...), wäre eine Unterscheidung sehr "mühseelig". Auch Spiele-Daten haben oft ihre eigenen Endungen.
Aber Entropie ist ein guter Ansatzpunkt. Danke.

Ich wuerde da auch einfach file drauf anwenden.

Leider zeigt file bei vielen Dateien anderer Systeme (Win., Mac, Dos, ...), nur ->data.

Um eine Art möglichen Komprimierungsfaktor zu ermitteln kannst du dir einmal alle Bytes zählen lassen (Gesamtgröße) und die Anzahl der druckbaren Zeichen (Befehl "strings"). Je geringer der Quotient je sinnvoller ist eine Komprimierung.

Keine schlechte Idee die man auch um andere Faktoren erweitern könnte. Z.B. auf mehrere
gleiche Bytes hintereinander testen u.ä....
Danke!

Mich freut's trotz günstiger gigafetter Festplatten immer wieder wenn es einen noch besseren Kompressor gibt, denn auch die durch bessere Kompression kürzere Transferdauer erfreut Hoch- und Runterladenden.
Ich fürchte man kommt schlicht nicht um Ausprobieren herum...

Genau so sehe ich das auch. Warum Platz verschwenden?
Anscheinend kommt man doch um das Ausprobieren drumrum.
TRex hat denke ich den Nagel auf den Kopf getroffen. Man muß die Entropie der Datei
ermitteln. Dateien mit geringer Entropie sollten sich gut Komprimieren lassen.

Ich zweifel daran, ob bei der enormen Kapazität aktueller Festplatten sich eine Komprimierung überhaupt noch lohnt.

Genau so sehe ich das auch.

Das gleiche dachte ich vor vielen Jahren von meiner 120MB-Platte und einige Jahre später
dachte ich das von meiner 4GB-Platte...

Kannst du etwas konkreter werden - um was geht es denn genau? Dann werden die Antworten auch etwas konkreter (und wer weiss, vielleicht sogar richtig nützlich) ausfallen...

MfG Peschmä

Uups, sorry, ich dachte eigentlich meine Frage sei Konkret?
Ich möchte mir ein Backup-Programm schreiben, daß von verschiedenen Systemen
(Win., Mac, Dos, ...) Backups macht und ich möchte dort größere Dateien gerne Komprimieren,
wenn es denn lohnt.
Bei kleinen Dateien lohnt es schon mal nicht, wegen den Blockgrößen des Dateisystems.
Aber ab ein paar MB könnte man, bei großen Datenmengen, sicher viel Platz sparen.
Das Backup soll ein kompletter Spiegel des entsprechenden Systems sein, nur einige Dateien sind
eben Komprimiert.
(Das Problem mit den Dateirechten verschiedener Systeme ist mir bekannt.
Das muß ich auch noch angehen...)

Also so richtig erschließt sich mir auch nicht, was Du praktisch machen willst und für was das gut sein soll. Konkretisiere doch mal Dein Vorhaben, oder ist das rein theoretischer Natur?

Siehe Antwort @peschmae und ja, im Moment ist es noch etwas theoretisch aber das Ziel ist
schon Fest. Herauskommen soll ein Backup-Programm, das meinen kleinen "Rechner-Zoo"
(Mit artgerechter Haltung... ) auf einer großen Platte sichert. Und zwar über lan
und so wie es im Moment aussieht in C/C++.

Vielen Dank nochmal an alle die mir geantwortet haben.

Ich liebe dieses Forum.
Man bekommt hier sehr oft den "Schubser" in die richtige Richtung den man braucht um
sein Ziel zu erreichen!

gruß heinz

[wanne]

Also ich würde mal sagen, dass du bei nem Backup die Größte Kompression dadurch erreichst, dass du alles keine in ne tar steckst, und so Blockgrößen umgehst.
Bei großen Dateien würde ich sagen, das du außer bei ausführbarem zeug, das nicht setup und nicht auf jar endet praktisch alles nicht zu komprimieren ist. (zumindest nicht verlustfrei.)

[peschmae]

Uups, sorry, ich dachte eigentlich meine Frage sei Konkret?

Naja, was mir (und auch anderen) fehlte ist ein Hinweis darauf ob es denn irgendwelche Vorkenntnisse gibt in Bezug auf was für Dateien man denn da so erwarten kann. Das scheint nicht der Fall zu sein. Solche Probleme voraussetzungslos anzugehen (soll mit beliebigen Daten laufen) mag zwar schöner erscheinen, ist aber oft unnötig kompliziert.

Im Prinzip sehe ich zwei Möglichkeiten:
Entweder zu komprimierst per Default alles, ausser Dateien die von den Namen auf eine Black/Whitelist matchen (also *.jpg, *.zip *.bz2, etc) - das ist so das übliche Vorgehen und hat vor allem den Vorteil für den Nutzer transparent zu sein.

Oder du guckst auf den Inhalt. Das Stichwort Entropie wurde schon erwähnt, das lässt sich ja einfach errechnen - müsste man mal ausprobieren wie gut die Entropie mit den Kompressionsraten existierender Algorithmen korreliert (sollte eigentlich ganz gut passen, aber wer weiss).
Man könnte es sich auch überlegen (lesen musst du die Daten ja eh), die Dinger einfach mal testweise zu komprimieren (so mit gzip -1, das ist richtig schnell) und zu gucken ob die Datei kleiner wird. Wenn ja ist da wohl was zu gewinnen und man schleust das Ding dann in einen "richtigen" Kompressor...

Also ich würde mal sagen, dass du bei nem Backup die Größte Kompression dadurch erreichst, dass du alles keine in ne tar steckst, und so Blockgrößen umgehst.
Bei großen Dateien würde ich sagen, das du außer bei ausführbarem zeug, das nicht setup und nicht auf jar endet praktisch alles nicht zu komprimieren ist. (zumindest nicht verlustfrei.)

Für meine persönlichen Anwendungen meide ich Backupsoftware die irgendwelche solchen Tricks macht. Der einfache Grund ist, dass ich ein Backup haben will, welches ich einfach und von Hand wiederherstellen kann, ohne die Software. Auch das extrahieren von einzelnen Dateien muss einfach sein (was tar schon mal ausschliesst).
Also am liebsten einfach den Verzeichnisbaum spiegeln und (wenns denn irgendwie geht) die paar Dateien wos was bringt einzeln komprimieren (so wie storebackup, was leider kein remote kann, dafür benutz ich dann rsync, da geht dann leider die Kompression nicht...).

Aber jeder hat da so seine eigenen Anforderungen.

MfG Peschmä

[hjc]

Uups, sorry, ich dachte eigentlich meine Frage sei Konkret?

...
Im Prinzip sehe ich zwei Möglichkeiten:
Entweder zu komprimierst per Default alles, ausser Dateien die von den Namen auf eine Black/Whitelist matchen (also *.jpg, *.zip *.bz2, etc) - das ist so das übliche Vorgehen und hat vor allem den Vorteil für den Nutzer transparent zu sein.

Oder du guckst auf den Inhalt. Das Stichwort Entropie wurde schon erwähnt, das lässt sich ja einfach errechnen - müsste man mal ausprobieren wie gut die Entropie mit den Kompressionsraten existierender Algorithmen korreliert (sollte eigentlich ganz gut passen, aber wer weiss).
Man könnte es sich auch überlegen (lesen musst du die Daten ja eh), die Dinger einfach mal testweise zu komprimieren (so mit gzip -1, das ist richtig schnell) und zu gucken ob die Datei kleiner wird. Wenn ja ist da wohl was zu gewinnen und man schleust das Ding dann in einen "richtigen" Kompressor...

Wenn es da es Brauchbares gäbe um über die Entropie eine Auswahl zu finden, wäre das interessant. Gibt es da Algorithmen, die man verwenden kann? Das könnte man dann (über die Regeln !) in dem von Dir unten angesprochenen storebackup einbauen. (Das wäre relativ einfach.)

Der Trick mit gzip -1 wird m.E. nur dazu dienen können, Dateien zu finden, die auf jeden Fall komprimierbar seid. Da dürfte viel durch die Lappen gehen, das mit bzip2 oder xz noch brauchbare Resultate bringt.

Grundsätzlich sehe ich das Thema des Aufwandes für die Kompression als idR. nicht so gravierend an. Jedenfalls nicht bei Tools, die nur Dateien mit neuem Inhalt kopieren / komprimieren. Da sich nur ein paar Prozent der Dateien von Backup zu Backup ändern, stört der (Rechen-)Aufwand nach meinen Erfahrungen nicht groß. Das gilt natürlich nur, wenn keine sehr großen Dateien zu komprimieren sind - und diese nicht über Deduplikation ("blocked" files bei storeBackup) in "Scheibchen" geschnitten werden.

Oder hast Du da andere Erfahrungen - würde mich interessieren.

Also ich würde mal sagen, dass du bei nem Backup die Größte Kompression dadurch erreichst, dass du alles keine in ne tar steckst, und so Blockgrößen umgehst.
Bei großen Dateien würde ich sagen, das du außer bei ausführbarem zeug, das nicht setup und nicht auf jar endet praktisch alles nicht zu komprimieren ist. (zumindest nicht verlustfrei.)

Die Blockgrößen kann man auch umgehen, indem man ein Dateisystem verwendet, das "tail-packing" unterstützt. Nach meinem Kenntnisstand sind das momentan reiserfs und in Zukunft btrfs. (btrfs würde heute nicht für ein Backup verwenden)

Für meine persönlichen Anwendungen meide ich Backupsoftware die irgendwelche solchen Tricks macht. Der einfache Grund ist, dass ich ein Backup haben will, welches ich einfach und von Hand wiederherstellen kann, ohne die Software. Auch das extrahieren von einzelnen Dateien muss einfach sein (was tar schon mal ausschliesst).

Das sehe ich auch so. Allerdings würde ich noch ergänzen, dass die Meta-Informationen (Rechte, Zeitstempel, hard-Verlinkung) auch in einem möglichst einfachen Format (ASCII) verfügbar sein sollten.

Also am liebsten einfach den Verzeichnisbaum spiegeln und (wenns denn irgendwie geht) die paar Dateien wos was bringt einzeln komprimieren (so wie storebackup, was leider kein remote kann, dafür benutz ich dann rsync, da geht dann leider die Kompression nicht...).

Das kann man so oder so sehen. Du kannst natürlich NFS verwenden. Ich vermute aber, die meinst über Firewalls o.ä. Da gäbe es folgende Möglichkeiten:

• per openvpn einen Tunnel aufmachen und NFS verwenden, muss aber nicht unbedingt sinnvoll sein, hängt vom Sicherheitskonzept und von Bandbreiten ab, in welcher Richtung das sinnvoll ist oder auch (gar) nicht
• In der Doku von storebackup steht unter FAQ4, wie man ein Backup über ssh durchführen kann. Damit sollte ein remote Backup möglich sein.

Grundsätzlich sollte ein (echtes, d.h. miese Bandbreite oder hohe Latenzen) remote Backup mit der Option lateLinks gemacht werden (siehe Example 6). Ob das dann für das reine Backup schneller oder langsamer als rsync ist, weiß ich nicht. Nach dem Backup ist serverseitig später noch storeBackupUpdateBackup fällig.

Entschuldigt für die Abschweifung - aber das Meiste sind Punkte, die für den Thread-Ersteller auch interessant sein dürften, wenn er seine Backup-Software plant.

Grüße, hjc

[peschmae]

Der Trick mit gzip -1 wird m.E. nur dazu dienen können, Dateien zu finden, die auf jeden Fall komprimierbar seid. Da dürfte viel durch die Lappen gehen, das mit bzip2 oder xz noch brauchbare Resultate bringt.

Das ist die Frage. Mein Eindruck war bisher, dass man Daten die komprimierbar sind schon mit schnellen Algorithmen schon ein ganzes Stück kleiner machen kann. Die kriegt man dann mit den langsameren Algorithmen halt noch etwas stärker komprimiert.

Daten die man nicht komprimieren kann (weil sie schon ordentlich komprimiert sind - also mp3, jpg, mpeg 4) kriegt man mit weder den langsamen noch den schnellen Methoden klein.

Ich hatte jetzt mal postuliert, dass es die Zwischenkategorie - also Daten die man mit "gzip -1" nicht nennbar komprimieren kann, dafür aber mit "gzip -9"/bzip oder so - nicht oder kaum gibt.

Grundsätzlich sehe ich das Thema des Aufwandes für die Kompression als idR. nicht so gravierend an. Jedenfalls nicht bei Tools, die nur Dateien mit neuem Inhalt kopieren / komprimieren. Da sich nur ein paar Prozent der Dateien von Backup zu Backup ändern, stört der (Rechen-)Aufwand nach meinen Erfahrungen nicht groß. Das gilt natürlich nur, wenn keine sehr großen Dateien zu komprimieren sind - und diese nicht über Deduplikation ("blocked" files bei storeBackup) in "Scheibchen" geschnitten werden.

Also bzip2 finde ich schon gravierend langsam beim komprimieren, das verwende ich entsprechend auch nur für wenige Datentypen (primär vorher unkomprimierte raw-Dateien von Digitalkameras). Für Backups muss es für mich halt einfach ein algorithmus sein, der so schnell ist dass es nicht weiter stört - da passt gzip ganz gut. Wo da der Threshold ist kommt auch auf die jeweiligen Datenmengen und die Backuphäufigkeit an.

Das kann man so oder so sehen. Du kannst natürlich NFS verwenden. Ich vermute aber, die meinst über Firewalls o.ä. Da gäbe es folgende Möglichkeiten:

• per openvpn einen Tunnel aufmachen und NFS verwenden, muss aber nicht unbedingt sinnvoll sein, hängt vom Sicherheitskonzept und von Bandbreiten ab, in welcher Richtung das sinnvoll ist oder auch (gar) nicht
• In der Doku von storebackup steht unter FAQ4, wie man ein Backup über ssh durchführen kann. Damit sollte ein remote Backup möglich sein.

Grundsätzlich sollte ein (echtes, d.h. miese Bandbreite oder hohe Latenzen) remote Backup mit der Option lateLinks gemacht werden (siehe Example 6). Ob das dann für das reine Backup schneller oder langsamer als rsync ist, weiß ich nicht. Nach dem Backup ist serverseitig später noch storeBackupUpdateBackup fällig.

NFS über OpenVPN ist mir einfach etwas zu kompliziert. Zudem habe ich auf allen Maschinen ssh installiert, da nur um Backups machen zu können noch eine zusätzliche potentielle Sicherheitslücke mit OpenVPN und NFS (letzteres dann ja im LAN unverschlüsselt) muss für mich nicht sein.

Der Ansatz mit Storebackup auf sshfs kommt für mich nicht in Frage, weil ich oft über unterwegs über sehr instabile Verbindungen arbeite.

Fuse- und andere Netzwerkdateisysteme kommen damit einfach nicht gut zurecht. Man sieht nicht dass da keine Verbindung mehr besteht nur plötzlich hängt dann alles. Dann gehts daran das alles sauber zu beenden und neu zu starten...

Rsync ist da eine sehr gute Lösung - ich habe mir da etwas gebastelt was mehr oder weniger dasselbe macht wie Storebackup. Mit dem grossen Vorteil, dass es abgebrochene Backups sehr schnell wiederaufnehmen und weiterfahren kann ohne irgendwelchen mount-Leichen und ähnlichem. Das einzige was fehlt ist die Kompression. Die kriegt man da leider einfach nicht eingebaut. Ausser man macht das Backup auf ein Dateisystem was transparent komprimiert (btrfs, wenns denn mal ein fsck gibt vielleicht eine Option)

MfG Peschmä

[hjc]

Für "richtig" wackelige Leitung ist rsync natürlich unübertroffen für die Datenübertragung - dazu verwende ich es auch.

Nur ein Tipp (jetzt nicht wg. Backup): openvpn unterbricht die darüberlaufenden IP Sessions nicht, wenn die Verbindung weg ist. Aus Sicht der Anwendungen bleibt die Verbindung also sogar erhalten, wenn man z.B. von WLAN auf Kabel wechselt. Allerdings gibt's bei zu langen Unterbrechungen natürlich je nach laufenden Anwendungen Timeouts.


Die Idee mit dem gzip -1 muss ich mal ausprobieren (inwieweit das realistisch ist). Vielleicht baue ich's in storeBackup so ein, dass man's beliebig mit anderen Vorgaben (Pfad, Endung, Größe, User, etc) kombinieren kann. Mal sehen . . .

Grüße, hjc

[hjc]

Hallo,

für die, die's interessiert. Es gibt inzwischen Version 3.3 von storeBackup als Release Kandidaten. Dieser enthält neben anderem (insbesondere Backup-Replikation auf andere Medien) auch die hier besprochene Abschätzung der Komprimierbarkeit von Dateien oder Teilen von Dateien ("blocked files"). Die Implementiertung ist so ähnlich, wie hier besprochen. Das scheint ganz gut zu klappen - vielen Dank noch an Peschmä für die Idee.

Wer das verwenden will, muss aber das tar File herunterladen und irgendwo auspacken - bis Debian so weit ist, wird wohl einige Zeit dauern.

Links:

http://www.linux-community.de/Internal/ ... barkeit-ab
http://www.nongnu.org/storebackup/de/node8.html
http://storebackup.org