Multipar: Größe der Sicherheitsdateien explodiert bei den Bilder-Ordnern?

[Spawnie112]

Hallo,

ich versuche meinen Backups eine gewisse Robustheit anzueignen.
Daher möchte ich Wiederherstellungsdateien erzeugen.

Bislang deckte sich der Wiederherstellungsgrad in Prozent grob dem was an Speicher veranschlagt wird.

Das hat bei den Video-Dateien vom Camcorder gut geklappt.
Nun wären die Bilder dran gewesen, grob geschätzt 25% Handy-JPGs und 75% Nikon RAWs.

Dort eskaliert das aber völlig. Ein Ordner mit 150GB Bildern soll Wiederherstellungsfiles in der Größe von 1,5TB benötigen bei 30% Wiederherstellbarkeit? Die Effizienz liegt eigentlich auch immer in den hohen 90er% und dort auf einmal zw. 1-7%?

Kann ich da was umkonfigurieren oder gibts ein anderes Tool?

 

[n/a]

Ich finde diese Frage schwer zu lesen ... Bitte erkläre mal, was MultiPar macht, was das reguläre Filesystem nicht auch schon macht

 

[foofoobar]

Bitte erkläre mal, was MultiPar macht, was das reguläre Filesystem nicht auch schon macht

https://de.wikipedia.org/wiki/Vorwärtsfehlerkorrektur

 

[klampf]

@Spawnie112
Du kannst auf jeden Fall was umkonfigurieren, ich mache das auch (gerade für RAWs) und man kann einfach einstellen wieviel Redundanz man möchte.

Also hier in dem Bereich

Ich mach das so:
Multipar öffnen
Files einwerfen
Un dann so einstellen, dass da unten recht wenigsten 1-xxx steht, denn dann kann er ein defektes Files und egal welches auch wiederherstellen. Für RAWs okay, für Videos wahrscheinlich mehr als Du willst. Da dann halt die Redundancy auf einen Wert stellen, der Dir gefällt.



@n/a
Multipar erzeugt Redundanzfiles, in gewisser Weise wie ein Raid auf filesystem-ebene.
Seiteneffekt ist, das der auch einfach die Konsistenz der Dateiein überprüfen kann.
und falls mal eine einzelne Datei defekt wäre, auch reparieren.
Hilft ggf. gegen "Bitrot", wie Leute das so schön nennen.

Und es ist ein Opensource-std-format kann man sagen.

 

[gymfan]

Un dann so einstellen, dass da unten recht wenigsten 1-xxx steht, denn dann kann er ein defektes Files und egal welches auch wiederherstellen. Für RAWs okay

Das ist halt die Frage. 148GB Nikon NEF sind bei mir 7048 Bilder, und da sind noch keine mini-JPGs vom Smartphone dabei.

Aber nutze ich die Kommandozeilenversion von MultiPar mit 5% Redundanz, dann erstellt er mir auch exakt 5% .par2 files. Im Gegensatz zum Original par2 auch ohne dass ich an sonstigen Parametern herum spielen muss.
https://github.com/Yutaka-Sawada/MultiPar

Recovery file count gemäß Ausgabe wäre 10, immer noch entweder zu wenig, wenn ich meinem Speichermedium nicht traue oder zu viel, wenn ich ihm traue.

Kann ich da was umkonfigurieren oder gibts ein anderes Tool?

Was hast Du denn eingestellt? Die GUI zeigt schon an, wie groß die par2-Dateien insg. werden.

 

[Micha-]

das der auch einfach die Konsistenz der Dateiein überprüfen kann.

Wie soll das gehen? Oder meinst du später, als Verify?

 

[n/a]

https://de.wikipedia.org/wiki/Vorwärtsfehlerkorrektur

Nimms mir nicht übel, aber ich hatte dich nicht gefragt - und irgendeinen Link hinklatschen, ist auch nicht die Lösung. Fehlerkorrekturverfahren kenne ich, ich wollte wissen, was sich TE davon erhofft

 

[gymfan]

Oder meinst du später, als Verify?

Ja, in dem konkreten Fall:
Man sichtet, verschlagwortete und löscht dabei die ungewollten Bilder. Da sich umgehend danach die Bilder nicht mehr ändern, wurde die Inhaltliche Korrektheit bereits geprüft. Nun erstellt man die par2 Dateien und kann damit immer prüfen, dass die Dateien noch inhaltlich unberändert sind.

Damit muss man der SSD/HDD nur ein paar Stunden/Tage zwischen dem Sortieren und dem Erstellen der par2 Dateien vertrauen.

ich wollte wissen, was sich TE davon erhofft

Falls Du nicht ein RAID5, BTRFS oder ZFS (letztere mit jeweiligen Recovery-Daten) als ein "reguläres" Dateisystem betrachtest, ist die (offenslicht bekannte) Wiederherstellung einzelner Dateien, die sich nicht oder mit fehlerhaftem Inhalt lesen lassen, der erhoffte Mehrwert.

So muss man das nicht für die gesamte SSD machen sondern nur für sowieso unveränderliche Daten (oder gar nur für dessen Backup).

Was auf einer normalen Festplatte für mich nur wenig Sinn ergibt (erst recht, wenn man mind. ein weiteres Backup und Prüfsummen dazu hat), mag bei bei DVDs/BDs als Backup-Medium einen Merhwert regeben.

Ich habe par2 jedenfalls genutzt, um das ext. auf DVD-RAM gelagerte 3. Backup gegen solche Lesefehler zu sichern. Andere hier im Forum haben sich schon über eine vergleichbare Funktion im neueren winrar gefreut. Nur dass par2 quelloffen und OS-unabhängig ist (auch in der Erstellung).

 

[gaym0r]

Nimms mir nicht übel, aber ich hatte dich nicht gefragt - und irgendeinen Link hinklatschen, ist auch nicht die Lösung.

Der Link beantwortet deine Frage nunmal 1a.

Fehlerkorrekturverfahren kenne ich, ich wollte wissen, was sich TE davon erhofft

dann sag doch einfach direkt warum es in deinen Augen mumpitz ist, anstatt so rumzudrucksen. Oder beantworte dem OP seine Frage. Wenn du beides nicht willst/kannst, dann halt dich doch einfach raus und überlasse das Feld denjenigen, die Ahnung von der Materie haben?

 

[n/a]

Na gut... seine Frage und sein Vorhaben ist schwachsinnig 🤷‍♂️

Begründung brauchts ja nicht, weil @gay hat ja Ahnung

 

[Spawnie112]

Hallo zusammen, danke vorweg schon mal für die (konstruktiven) Antworten.

Na gut... seine Frage und sein Vorhaben ist schwachsinnig 🤷‍♂️

Es freut mich, zumindest deiner Unterhaltung beigetragen zu haben - auch wenn ich nicht weiß, wie du zu diesem wirklich erstklassigem Urteil kommst?

Vom Weg den wir einschlagen wird mich mit recht hoher Wahrscheinlichkeit die Antwort eh nicht interessieren, aber der Vollständigkeit halber:
Nachdem ich auf die blöde Art lernen musste, dass ein autom. Backup nicht "kugelsicher" ist, will ich die Robustheit erhöhen. Mir hat ein schleichender Defekt der Festplatte unbemerkt die autom. Backups korrumpiert, da die Fehler in die Sicherungen gesynct wurden. So hat es geschätzt 5-10% der Bilder zerstört bzw. da ich keine Lust hatte tausende Bilder einzeln zu prüfen, habe ich die betroffenen Monate komplett ersetzt und schlussendlich gut 1/3 der Dateien aus einem alten Offline Backup ziehen müssen, und habe immer noch Defekte drinne.
Daher will ich für die wichtigen Dateien eben eine Wiederherstellbarkeit erzeugen, und Tadaaaaaa: Das klappt (zumindest in der Theorie) ganz gut mit Multipar. Es ist zwar nicht so kompfortabel wie ein NAS mit ZFS & Co. aber es erfüllt seinen Zweck.

So nun zum Problem zurück:
Im Anhang ein Bild. Das ist ein Jahr mit rund 6k Bildern, die 150GB auf der Platte haben. 10% Wiederherstellbarkeit würden bei der üblichen Effizienz von 99,x% ungefähr 15GB bedeuten. Die Effizienz liegt aber bei 1,x% und die Wiederherstellungsfiles sollen 790GB benötigen???

Irgendwas passt da nicht, und das Problem habe ich bei jedem Jahr/Ordner in dieser Form.

Ergänzung (10. Juli 2025)

UPDATE: Wenn ich die Anzahl der Blöcke erhöhe, so dass es deutlich mehr sind als Dateien, so steigt die Effizienz und die Größe der Wiederherstellungsfiles geht runter.

Was bei dieser Menge Daten eben unpraktisch ist, ist die Tatsache, dass ich so extrem feingliedrig arbeiten muss, statt in einem Rutsch alles abzudecken

 

[Hardkorn]

 

[Spawnie112]

Exakt das habe ich auch bemerkt. Rückblickend macht das auch Sinn, denn wenn extrem viele Dateien in wenigen Blöcken mit höher Wiederherstellbarkeit abliegen sollen, dann liegt ja in jedem Block plötzlich alles, banal ausgedrückt.

Wobei ich dachte, da die Regler beim einwerfen der Files rumspringen, dass es da ein Balancing gibt.

 

[klampf]

Wirkt sih evtl. die Einstellung Mediengröße aus?
Weil die bei Dir auf 700MB steht und bei den beiden anderen bei 50GB.
Ich weiß nicht was der macht, aber versucht vermutlich irgendwie was auf eine bestimmte Größe zu bringen?

Was Du mit den defekten Dateien beschreibst, ist genau das wovor gewarnt wird, es geht was kaput und mn kopiert den Fehler weiter. Ich mache meine Backups auch als filekopien und als Hobbyfotograf, der seine "negative" (RAWs) aufheben will, kopiert man dien im Luafe der jahre halt immer wieder mal auf eine gröere Platte oder so.
Das gute an der par-files ist halt, man kopiert die mit, d.h. ich kopier das evtl. 10x und kann dann imer checken, ob noch alles ganz ist.

Und das ist auch besser als das fancieste Filesystem, denn wenn die Daten genau beim kopieren kaputt gehen, im RAM oder auf dem Bus oder so, da hilft Dir das Filesystem nix.

 

[Evil E-Lex]

Ich glaube, ihr macht eure Backups falsch. Korrupte Dateien auf einem Backupdatenträger sind kein Problem, denn man hat ja noch die Originale. Hat man die nicht mehr, ist das Backup kein Backup.

Und das ist auch besser als das fancieste Filesystem, denn wenn die Daten genau beim kopieren kaputt gehen, im RAM oder auf dem Bus oder so, da hilft Dir das Filesystem nix.

Dafür gibt es Programme, die die Dateien nach dem Kopieren überprüfen.

 

[foofoobar]

Exakt das habe ich auch bemerkt. Rückblickend macht das auch Sinn, denn wenn extrem viele Dateien in wenigen Blöcken mit höher Wiederherstellbarkeit abliegen sollen, dann liegt ja in jedem Block plötzlich alles, banal ausgedrückt.

Wobei ich dachte, da die Regler beim einwerfen der Files rumspringen, dass es da ein Balancing gibt.

Möglicherweise wäre es schlauer dort auf GUIs zu verzichten und CmdLine Versionen zu nutzen wo die "richtigen" Einstellungen, Reihenfolgen in einem Script verdrahtet sind.

Das schützt auch vor falschen Klicks. Und wahrscheinlich ist auch die Verfügbarkeit in der Zukunft der entsprechenden CmdLine Versionen wesentlich besser.

Ergänzung (11. Juli 2025)

Dafür gibt es Programme, die die Dateien nach dem Kopieren überprüfen.

Das hilft eben nicht gegen silent corruption.
Das ist ja genau das Szenario was der TO erlebt hat und wogegen er sich in Zukunft schützen möchte.

Ergänzung (11. Juli 2025)

Und das ist auch besser als das fancieste Filesystem, denn wenn die Daten genau beim kopieren kaputt gehen, im RAM oder auf dem Bus oder so, da hilft Dir das Filesystem nix.

Ohne ECC-Ram kein Mitleid.

 

[Evil E-Lex]

Das hilft eben nicht gegen silent corruption.
Das ist ja genau das Szenario was der TO erlebt hat und wogegen er sich in Zukunft schützen möchte.

Das Original und Backup gleichzeitig kaputtgehen halte ich für ausgeschlossen. Und man hat sinnvollerweise mehr als ein Backup.

 

[klampf]

Ohne ECC-Ram kein Mitleid.

Manche Leute haben halt nur normale PCs und die waren/sind ohne ECC.
Also die Meisten eigentlich.
Zählt das ECC auf DDR5 (was ich noch nicht habe)?

Ihr könnt ja versuchen zu raten wo es bim TO kaput gegangen ist, als er das Problem hatte.
Für mich ist das mir den par file auch einfach ein "peace of mind".
Die Diskussion ist immer so ein bisschen müßig, es schadet absolut nix mal so ein paar Dateien zu generieren.
Bisschen Platz, bisschen Rechenzeit also genau wofür ich nen Computer habe

 

[gymfan]

Ich glaube, ihr macht eure Backups falsch. Korrupte Dateien auf einem Backupdatenträger sind kein Problem, denn man hat ja noch die Originale. Hat man die nicht mehr, ist das Backup kein Backup.

Nur dass nicht jeder in der idenalen Welt und mit beliebig viel Kapital lebt.

Archiv und Backup liegen zu Hause, das 2. Backup davon (nur die mir wirklich wichtigen Daten) online. Und das Drittbackup diese wichtigen Daten liegt komplett offline auf DVD-RAMs bei meinen Eltern.

Nun brennt meine Wohnung ab und der Cloud-Anbieter sperrt (nahezu zeitgleich) meinen Account (alternativ kann er auch einfach meine Daten löschen). Dann bin ich froh, wenn ich das 3. Backup von den DVD-RAMs lesen und zur Not korrigieren kann.

Ob ich die letzte DVD mit par2 Files fülle oder teilweise leer lasse, ist bis auf etwas mehr Zeitaufwand irrlevant.

In dem Szenario kann ich das 2. Backup meines Bildarchivs (das auf HDDs bei meinen Entern liegt, 3,5 TB Cloudspeicher ist mir dafür zu teuer und mit 100 MBis/s Upload viel zu lahm angebunden) nur noch auf Korrektheit prüfen und weiss dann, welche Bilder defekt wären.

Das ist am Ende wie das BTRFS auf dem Backup-NAS. Ich hatte persönlich noch nie einen BitRot mit meinen Daten auf irgendeiner HDD (ich habe zu allen gut 3,5 TB archivierten Bilddaten Prüfsummen, welche schon vor der Sichtung der Bilder erstellt werden). Trotzdem beruhigt es, zusätzlich ein paar Prüfsummen im Dateisystem zu haben.

 

[Evil E-Lex]

Warum du dich jetzt angesprochen fühlst, verstehe ich nicht. Dein Anwendungsfall ist der einzige, wo ich noch einen Nutzen für Paritätsdateien sehe. Die sind ja mal entwickelt worden, um unzuverlässige Speichermedien (Disketten, frühe optische Medien) oder instabile Datenübertragungen zu kompensieren. Beides hat man heute typischerweise nicht mehr.

Ich bezog mich eher darauf, dass man seine eigene Backup-Strategie (hier: bereits gesicherte Dateien, mit defekten Dateien zu überschreiben) mit Paritätsdateien kompensieren will. Der viel simplere Weg wäre, Dateien direkt mit Überprüfung zu sichern und bereits gesicherte Dateien nicht zu überschreiben, solange die sich nicht geändert haben. Dann kann einem egal sein, ob das Original oder die Kopie defekt sind, denn man hat immer noch eine unbeschädigte Version.