Welches Komprimierverfahren wäre empfehlenswert ?

[LinuxKnochen]

Habe 2 TB Archiv-Dokumaterial
und würde es gerne auf die Hälfte, volumenmässig stauchen
und dann in einen crypt-Container stecken ( + duplizieren + alle Nase lang dann clonen + Backup )
+ zum Cloud-Hoster beamen ( nur zulu-Container - keine offenen Dokumente )



Gibt es da brauchbare Daten-Kompressoren -
oder besser die Original-Dateien, unbehandelt in einen Ordnersack stecken und dann verschlüsseln -



Kenne mich da zu wenig aus, mit der Komprimiererei und stelle mir die Frage, ob es wieder
proplemlos entpackbar ist,
der ganze zusammengequetschte Salat - am Ende hat man nur noch einen 0/1-Haufen mit
Gekräusel auf dem Monitor?

Komprimieren möglich oder einfach sein lassen?
Besten Dank

 

[djducky]

Was sind das für Datenformate? Sowas wie MP4, JPEG etc. ist eigentlich schon ziemlich komprimiert, das bringt wenig...

 

[4nudels]

ich würde es mit veracrypt machen

 

[BFF]

2 TB Archiv-Dokumaterial

Was genau?
Packen kannst Du den Krams mit jedem Packer lokal in kleinere Stuecke. 2 TB oder ein komplettes Archiv dieser Groesse am Stueck macht keinen Spass irgendwohin hochzuladen.

Schau Dir mal cryptomator an. -> https://cryptomator.org/

Waere eventuell eine Idee fuer Dich.

 

[JumpingCat]

Also restic oder kopia. Aber das macht das schon alles automatisch, außer es sind bilder oder videos.

 

[LinuxKnochen]

Was genau?
Packen kannst Du den Krams mit jedem Packer lokal in kleinere Stuecke. 2 TB oder ein komplettes Archiv dieser Groesse am Stueck macht keinen Spass irgendwohin hochzuladen.

Schau Dir mal cryptomator an. -> https://cryptomator.org/

Waere eventuell eine Idee fuer Dich.

Die Daten per rar/zipper in mehrere Teile zerhacken und dann im zulu, fluks, cryptomator,
vera-Container verpacken - das funktioniert prächtig.

Frage mich, ob man den 2 TB Container auf 1 TB Volumen einsschrumpfen kann,
so dass das das Gesamtvolumen halbiert wird.

Ob es technisch, mit diversen Programmen überhaupt möglich ist
oder man die Finger gleich weg lässt, bevor Datenverlust programmiert?

Dass pdf`s eh schon komprimiert sind, ist so weit klar.
jpeg-Dokumente lassen sich als Einzeldatei einschrumpfen ( per Bildbearbeiter;
aber bei > 80 Leitzordnern, a`500 dinA4, > 50,000 Dokumenten...fängt man da nicht
groß manuell mit der Nachbearbeitung an.


War eine Überlegung, weil im Kamerabereich es auch Unterschiede gibt,
mit dem Daten-Recording + den jeweiligen Volumen.

Lasse ich den Axis-Recorder eine Woche laufen, müllt mir das Programm die
Speicher voll,
wogegen die OSX-Version im Mini die Daten auf ein Vielfaches kleiner zusammen
schrumpft
( vermutlich mit einem effizienterem Datenkompressor, inside )

Daher die Überlegung, ob es so was für Datencontainer gibt ( vorwiegend PDF,
jpeg-Dokus, Tabellen, kleinst-Videos, audio-Podcast-Aufnahmen )

Sonst wird man die Festplattenkapazitäten erhöhen und gut.
Die cloud-Schieberei, wird man sich dann wohl knicken -
nur das wichtigste Zeug dann hoch laden.

mfg

 

[Krik]

vorwiegend PDF,
jpeg-Dokus, Tabellen, kleinst-Videos, audio-Podcast-Aufnahmen

Was du aufzählst, liegt üblicherweise schon komprimiert vor. Du kannst da quasi nichts mehr rausholen, schon gar keine 50%. Obwohl, wenn du massiv auf Qualität verzichten willst, dann kann man noch stärker komprimieren. Das Ergebnis wird dir aber wahrscheinlich nicht gefallen.

Nachträgliche Komprimierung funktioniert gut bei Textdateien, aber da ist das am wenigsten nötig. Die Dateien sind da ohnehin klein.

 

[CyrionX]

jpeg-Dokumente lassen sich als Einzeldatei einschrumpfen ( per Bildbearbeiter;
aber bei > 80 Leitzordnern, a`500 dinA4, > 50,000 Dokumenten...fängt man da nicht
groß manuell mit der Nachbearbeitung an.

Batchkomprimierung z.B. per Irfanview
JPG Qualität auf 85%/90%,
Höhe bzw Breite an Pixeln begrenzen, also vorher testen ob das Dokument wirklich in zb 2480 x 3508 (300dpi) oder höher vorliegen muss und 1240 x 1754 (150 DPI) nicht doch ausreichen. Dann den ganzen Ordner ins Batch-Fenster hineinwerfen und starten.
Erfordert zwar ein bisschen Settingsgefummel, mit einer halbwegs aktuellen CPU und SSD hat man die 50.000 JPGs in 4-5 Stunden oder weniger aber durch.
Je nachdem wie groß die Pixeldichte ausfällt kann die Dateigröße sich auf Bruchteile reduzieren (150DPI sind 1/4 von 300DPI)
Für die Qualität des Ergebnisses bist du aber natürlich selbst verantwortlich

 

[djducky]

Naja, er will halt die Dateien behalten, wie sie sind - sie aber quasi noch kleiner packen. Das geht halt kaum. Bei Videos kann man natürlich effizientere Formate nehmen wie HEVC oder AV1. Das braucht für die gleiche (sichtbare) Qualität deutlich weniger Platz.

 

[nutrix]

Die Daten per rar/zipper in mehrere Teile zerhacken und dann im zulu, fluks, cryptomator,

Ganz schlechte Idee, ein Teil kaputt, alles kaputt.

oder besser die Original-Dateien, unbehandelt in einen Ordnersack stecken und dann verschlüsseln -

Genau so. Meine Güte, die Festplatten sind heute so günstig geworden, lass es doch einfach in dem Format und pack sie in den Veracypt-Container so rein.

 

[MoonTower]

Die Daten per rar/zipper in mehrere Teile zerhacken und dann im zulu, fluks, cryptomator,

Zitat: "Ganz schlechte Idee, ein Teil kaputt, alles kaputt."

Nein, bei Rar ist das so generell nicht der Fall. Falls einzelne Dateien komplett im jeweiligen Teil-Archiv liegen, kann man diese auch komplett entpacken. Dateien, die allerdings am Start- und Endpunkt des Archivs liegen, und sich jeweils noch zum Nachbar-Archiv erstrecken, bei denen geht das nicht.

 

[Ja_Ge]

HEVC oder AV1. Das braucht für die gleiche (sichtbare) Qualität deutlich weniger Platz.

Ist die Frage in welchem Format und Qualität / Bitrate liegen die Videos vor.
Ein bereits verlustbehaftet kodiertes Video noch einmal etwa mit HEVC zu codieren führt zu deutlichem Qualitätsverlust.

Sonst wird man die Festplattenkapazitäten erhöhen und gut.

2 TB in HDD ist ja nicht mehr wirklich teuer. Was ist überhaupt das Ziel? Währe eine kleine NAS zielführend?

 

[Piak]

@LinuxKnochen : Du möchtest Hilfe, dann gib uns bitte auch die Infos, was exakt du packen möchtest?

Bisherige Indizien, führen zu der Antwort: Geht nicht.

 

[LinuxKnochen]

2 TB in HDD ist ja nicht mehr wirklich teuer. Was ist überhaupt das Ziel? Währe eine kleine NAS zielführend?

Das Ziel ist, meine wichtigen Daten auf einen Speicher zu pressen, so dass ich Diese auch
noch in paar Jahren abgreifen kann, per crypto-container-Archiv in der cloud,
dann auch mobil; im Ausland

nas habe ich bereits eingerichtet, welche man nur house-intern nutze, per openMediaFault.
Habe nun 3 x Platten, welche 3 x gespiegelt werden ( benötige keine raid-Optionen +
entsprechender Optimierer und Beschleuniger, für brutale Rechenoperationen )

Werde die Daten auf die Platten packen und dann turnusmässig, alle Nase lang dann
clone-en.

Ergänzung (19. August 2025)

@LinuxKnochen : Du möchtest Hilfe, dann gib uns bitte auch die Infos, was exakt du packen möchtest?

Sind vorwiegend Dokumente, welche digitalisiert wurden.
Wie bereits beschrieben. rd. 100 Leitzordner Material.

Bisherige Indizien, führen zu der Antwort: Geht nicht.

die Erkenntnis habe ich erlangt und verbleibe bei der Variante,
dass die bisherigen Daten dann in crypt-Containern verpackt werden +
in die Cloud verschoben werden.
Muss dann eine entsprechende cloud-Lösung mir mir suchen

War bisher der Meinung, dass es in der Richtung was gäbe;
aber dem ist nicht so
Daher wird man den Komprimierversuch verwerfen und gut
Besten Dank

 

[HITCHER_I]

Die meisten JPEG sind nicht optimal komprimiert, es kommt auf das Detail bei gegebener Anzeigegröße an, aber überflüssige Qualitätseinstellung bringt dann nichts mehr, außer größeren Speicherverbrauch.
Da gibt es Spezialprogramme, welche das Maximum heraus holen, ohne Details im Bild merkbar zu verschlechtern.
https://github.com/packjpg/packJPG

PDFs kann man auch noch besser komprimieren, aber man muss sie zuerst "auspacken", und dann nochmals komprimieren. Dafür gibt es zB. so ein Spezialprogramm:
http://schnaader.info/precomp.php
Dieses Programm verwendet ua. auch das og. packJPG.

 

[Jeshiri]

Bezüglich PDF komprimieren, vor allem wenns viele Dateien sind, nutze ich gern Cisdem PDF Compressor.
Dort kannst du auch die Qualität etc. einstellen. Danach einfach mal schauen was dir so gefällt etc. Ist relativ einfach zu bedienen.

Der Größenunterschied fällt aber echt extrem unterschiedlich aus. Der kann mal gar 80-90% sein, und manchmal garkeiner. Hängt von einigen Faktoren dann ab.

 

[nutrix]

Nein,

Warum sagst Du nein 🙄

bei Rar ist das so generell nicht der Fall.

wenn Du einen speziellen Packer (es gibt ja viele andere noch auf dem Markt, gelle) nimmst, der es "generell" kann, aber nicht generell eben nicht

Dateien, die allerdings am Start- und Endpunkt des Archivs liegen, und sich jeweils noch zum Nachbar-Archiv erstrecken, bei denen geht das nicht.

und dann Dir gleich selbst wiedersprichst? 🙄🤦‍♂️ Und ja, genau diese und andere Fälle meine ich damit. Ich kann ja hier erwarten, daß die Leute mitdenken.

Sobald Du beispielsweise in feste Teilgrößen packst, hast Du immer das Problem, daß überhängende Dateien in ein oder mehrere Dateien bei vielen anderen Packern, und auch bei RAR, nicht mehr wieder hergestellt werden können. Und nicht jeder Packer hat Reparaturfunktionen wie RAR.

Und ich mache seit über 37 Jahren Backups auch professionell, daher kann man mir ruhig glauben, daß Zerteilen in viele kleinere Stücke komprimiert keine gute Idee ist. Da habe ich schon im Laufe dieser Zeit in Firmen viele Tränen und Klagen erlebt, wenn man wieder ein mühsames Backup für die Tonne war, gerade dann wo man es so wichtig brauchte. Sobald Du dann mit aufwendigen Verfahren die Packer sicherer machst, werden die Dateien wieder größer, und der Komprimierungseffekt ist vollkommen dahin.

2TB an Daten sind lächerlich, und dafür lohnt sich das Einpacken, Zerteilen und eventuelle Auspacken mit Zusammenfassen, was auch noch ordentlich CPU Ressourcen kostet, einfach nicht.

Ergänzung (19. August 2025)

Dass pdf`s eh schon komprimiert sind, ist so weit klar.
jpeg-Dokumente lassen sich als Einzeldatei einschrumpfen ( per Bildbearbeiter;
aber bei > 80 Leitzordnern, a`500 dinA4, > 50,000 Dokumenten...fängt man da nicht
groß manuell mit der Nachbearbeitung an.

Warum machst Du daraus kein OCR? Oder brauchst Du die Dokumente unbedingt als Bilder? Denk auch daran, daß beim Schrumpen der JGPs die Artefakte steigen, und damit senkt man die OCR Erkennungsrate.

 

[Piak]

Sind vorwiegend Dokumente, welche digitalisiert wurden.

Das ist doch nicht die Antwort! Gib uns Dateitypen und bisher genutzte Kompression.

Bsp.: Wenn du einfach gescannt hast und jetzt *.bmp Dateien hast, kannst du problemlos Faktor 2 einsparen.

Wenn du bereits *.heif Bilder hast, lautet die Antwort du kannst sogut wie nichts sparen.

Für jeden Dateityp ist es komplett unterschiedlich

 

[LinuxKnochen]

Das ist doch nicht die Antwort! Gib uns Dateitypen und bisher genutzte Kompression.

Nur jpeg, pdf, mp3, mpeg4(10%)

Bsp.: Wenn du einfach gescannt hast und jetzt *.bmp Dateien hast, kannst du problemlos Faktor 2 einsparen.

i.O. /bmp-doc;
Faktor 2 einsparen; mal näher einlesen

Wenn du bereits *.heif Bilder hast, lautet die Antwort du kannst sogut wie nichts sparen.

Für jeden Dateityp ist es komplett unterschiedlich

.heif-Bilder?
k.A. Muss mich mal näher damit befassen;
bisher nur jpeg, wie auch pdf.
Video-, Musikdateien, sonstige Dateien hat man sonst Keine;

 

[nutrix]

Nochmal, mußt Du unbedingt und unabdingbar komprimieren? Ich würde es verstehen, weil Du z.B. Cloudspeicher sparen willst. Wenn es nur direkt auf Datenträger geht, ist das heute doch, selbst mit SSDs und NVMe SSDs, relativ günstig.

Denk doch einfach mal logisch nach: Je mehr verschiedene Ketten in einen Prozess kommen, umso mehr steigt die Komplexität und Probleme im Fehlerfall. Wenn Du beispielsweise ein Problem mit dem verschlüsselten Container hast, und dann noch mit den komprimierten Dateien, wirds für eine Datenrettung im Fehlerfall sehr komplex wie herausfordernd, wenn Du das Problem selbst nicht so einfach eingrenzen kannst.