macOS Mojave Integrität von Dateien auf der Festplatte (hier SSD) über die Zeit

S

Sharptype

Aktives Mitglied
Thread Starter
Dabei seit
23.05.2015
Beiträge
1.181
Reaktionspunkte
112
Hallo zusammen,

habe mal eine blöde Frage :p
Ich habe vor Jahren mal schlechte Erfahrungen gemacht mit Dateien, die auf USB-Sticks einfach so über die Zeit "kaputtgegangen" sind. Sich so verändert haben, dass sie nicht mehr lesbar waren. PDFs usw. Das passierte einfach über die Zeit ohne bestimmte Gründe. Vermutlich einfach schlechte Hardware, ich weiß es nicht.

Daraufhin habe ich mir mal so Tools gebastelt, die mir Prüfsummen von meinen Dateien anlegen und die ich hin und wieder mal durchlaufen lasse, damit ich das überhaupt mal mitbekomme bzw. einschätzen kann. Wahrscheinlich in der heutigen Zeit überflüssig oder schwachsinnig? Es nervt mich auch total und kostet Zeit :LOL:

Gibt es solche Szenarien überhaupt noch, dass Dateien irgendwann mal so kaputt gehen (können) oder hat das Betriebssystem dafür Schutzmechanismen für und informiert den Anwender in solch einem Fall?

Ich nutze noch Mojave und ein altes MBP 2015 (bin also nicht ganz up-to-date) und es geht um die Dateien auf der internen SSD des Macbooks.

PS: Klar, Backups, immer, werden auch regelm. erstellt und es geht auch nicht um einen Festplattentotalausfall usw. vor dem niemand geschützt ist. Es geht hier um so Dinge, die ich damals nur mitbekommen habe, weil ich zufällig mal an eine alte Datei wollte und die plötzlich nicht mehr "lesbar" war bzw. nicht geöffnet werden konnte. Hätte das sonst nicht mal mitbekommen :unsure:

Danke für euer Feedback/Erfahrungen.
 
Gibt es solche Szenarien überhaupt noch, dass Dateien irgendwann mal so kaputt gehen (können) oder hat das Betriebssystem dafür Schutzmechanismen für und informiert den Anwender in solch einem Fall?
Wie sollte es das feststellen?
Es gibt keine eingebauten Checksummen in den Mac Dateisystemen.
Ein USB Stick hat kein Bad Block Management.
Da kann die Datei schon beim drauf kopieren defekt gegangen sein.
 
  • Gefällt mir
Reaktionen: win2mac und dg2rbf
PS: Klar, Backups, immer, werden auch regelm. erstellt und es geht auch nicht um einen Festplattentotalausfall usw. vor dem niemand geschützt ist. Es geht hier um so Dinge, die ich damals nur mitbekommen habe, weil ich zufällig mal an eine alte Datei wollte und die plötzlich nicht mehr "lesbar" war bzw. nicht geöffnet werden konnte. Hätte das sonst nicht mal mitbekommen :unsure:

Danke für euer Feedback/Erfahrungen.
Eigentlich ist genau dafür das Backupsystem Time Machine von macOS ideal. Denn Du kannst für jede einzelne Datei in der Zeit zurückgehen und die letzte funktionsfähige Dateiversion wiederherstellen.

Gleiches bieten übrigens auch die meisten Cloudspeicher wie z. B. OneDrive oder pCloud an.
 
Ja, der Effekt den du beschreibst, nennt sich bitrot, kann immer vorkommen. Wie hoch die Wahrscheinlichkeit ist, dass einzelne Bits kippen, weis ich nicht.

Dagegen helfen tun wirklich nur Checksummen.
 
  • Gefällt mir
Reaktionen: win2mac und dg2rbf
Solche Verluste gab bzw. gibt es mit fast jedem Datenträger denke ich. Bei SSDs etc. sollte ab und zu mal Strom drauf.
Auch nutzen sich Datenträger ab bzw. altern. Also Backup muss und beruhigt.
 
  • Gefällt mir
Reaktionen: dg2rbf
Eigentlich ist genau dafür das Backupsystem Time Machine von macOS ideal. Denn Du kannst für jede einzelne Datei in der Zeit zurückgehen und die letzte funktionsfähige Dateiversion

Gegen bitrot bringt ein Backup gar nichts, da gekippte Bits in einer Datei nicht erkannt werden können, solange kein Checksummenvergleich mit einem vorherigen, noch nicht gekippten Stand, erfolgt.
 
Gegen bitrot bringt ein Backup gar nichts, da gekippte Bits in einer Datei nicht erkannt werden können, solange kein Checksummenvergleich mit einem vorherigen, noch nicht gekippten Stand, erfolgt.
Es geht darum, dass er es irgendwann ja doch mitbekommt, eben dann wenn sie "plötzlich nicht mehr lesbar war bzw. nicht mehr geöffnet werden konnte", wie er es selbst formuliert hat. DANN ist Time Machine ideal, denn er kann damit soweit zurück gehen, bis eine noch funktionsfähige Datei gefunden wird. Damit wird das von ihm benannte - und von mir deshalb ja zitierte - Problem adressiert, dass ein klassisches Vollbackup in der Regel nur den letzten gesicherten Status festhält und somit eben nicht beliebig bis zur letzten noch funktionierenden Version einer Datei zurückgegangen werden kann.
 
Klar.

Dennoch hilft dein Hinweis nur dann, wenn das Backup noch nicht gekippte Daten enthält oder nicht selbst gekippt ist.

Und nochmals: die Wahrscheinlichkeit kann ich nicht benennen.

Das tückische ist halt, dass man es erst beim Lesen bemerkt und bei besonders bedeutsamen Daten, wie alten Fotos der Kinder, liest nan diese Daten erst nach vielen Jahren wieder.
 
  • Gefällt mir
Reaktionen: dg2rbf
Klar.

Dennoch hilft dein Hinweis nur dann, wenn das Backup noch nicht gekippte Daten enthält oder nicht selbst gekippt ist.

Und nochmals: die Wahrscheinlichkeit kann ich nicht benennen.

Das tückische ist halt, dass man es erst beim Lesen bemerkt und bei besonders bedeutsamen Daten, wie alten Fotos der Kinder, liest nan diese Daten erst nach vielen Jahren wieder.
Wenn Time Machine mit entsprechend großzügig bemessener Festplatte über Jahre genutzt wird, sollte das dann kein Problem sein. Und bei Cloud-Diensten sollte das erst recht kein Problem sein, denn da werden die letzten Versionen ja immer aufgehoben, selbst wenn sie viele Jahre alt sind.
 
Zum Archivieren am besten mit einem Packer wie RAR packen und Recovery Records dazu schreiben.
Kann man ja noch mit PAR ergänzen.

Oder halt ein Dateisystem mit ähnlichen Features.
 
  • Gefällt mir
Reaktionen: lisanet
Wenn Time Machine mit entsprechend großzügig bemessener Festplatte über Jahre genutzt wird, sollte das dann kein Problem sein. Und bei Cloud-Diensten sollte das erst recht kein Problem sein, denn da werden die letzten Versionen ja immer aufgehoben, selbst wenn sie viele Jahre alt sind.

Nochmal: wenn man Backups solange aufbewahrt wie die Originale alt sind, kann man sicher zurück gehen.

Du musst halt sicherstellen, dass auf diesen uralten Backup-Datenträger ebenso keine für die Lesbarkeit des Backups relevanten Bits gekippt sind und das Alter des Datenträgers das auch noch zulässt. Umkopieren auf neue Datenträger alleine hilft hier nicht, wenn keine Prüfung der Checksummen erfolgt.

Abschließend: Die Wahrscheinlichkeit von bitrot kenne ich nicht.
 
Bei USB Sticks, billigen erst recht, kommen Datenverluste vergleichsweise häufiger vor, daher empfiehlt sich sowas auch nicht als Backup-Medium. Wird immer wieder gesagt.
die auf USB-Sticks einfach so über die Zeit "kaputtgegangen" sind
Was für Sticks, welche Zeiträume?
es geht um die Dateien auf der internen SSD des Macbooks.
Das ist doch eine andere Liga der Qualität, denke ich.
 
  • Gefällt mir
Reaktionen: dg2rbf
Abschließend: Die Wahrscheinlichkeit von bitrot kenne ich nicht.
Hängt von vielen Faktoren ab, aber vor allem vom Datenträger. Die Wahrscheinlichkeit von Datenfehlern auf alten Disketten ist schon ziemlich hoch. Auch wiederbeschreibbare CDs habe eine ziemliche hohe Fehlerrate nach wenigen Jahren.
 
Dagegen helfen tun wirklich nur Checksummen.
Frage mich persönlich jedes Mal frage wie sicher das bei bitrot ist. Im Prinzip wird hier ein Zahlenbereich m auf n abgebildet, wobei m >> n und die Abbildung nicht injektiv ist.

Falls du oder andere da einen Link haben wie man das berechnen/schätzen kann würde es mich interessieren.
 
Frage mich persönlich jedes Mal frage wie sicher das bei bitrot ist. Im Prinzip wird hier ein Zahlenbereich m auf n abgebildet, wobei m >> n und die Abbildung nicht injektiv ist.
Sicher im Sinne von "wenn die Checksumme noch stimmt, hat es keinen Fehler" natürlich nicht, aber durchaus sicher im Sinne von "wenn die Checksumme nicht mehr stimmt, hat es einen Fehler" schon.
 
Du kannst dir dazu mal die üblichen Berechnungsmethode für Checksummen / Hashes ansehen. Die bekanntesten sind da sowas wie md5, sha256, crc. Bei allen Verfahren können theoretisch natürlich Kollisionen auftreten, da die Checksumme, wie du richtig siehst, ja weniger bits enthält als das original. Allerdings ist bei bitrot, also dem Kippen einzelner, weniger bits, das kein Thema, da müssten schon drastisch mehr Bits verändert werden, ggf, weggelassen oder hinzugefügt werden, um eine Kollision zu erhalten.
 
Jedes Mal wenn ich mit den Gedanken spiele, wird es sehr schnell sehr kompliziert - und dafür ist es mir nicht wichtig genug -, denn da sind so viele Größen die man berücksichtigen muss:

- wie wahrscheinlich ist überhaupt dass gespeicherte Daten irgendwie kippen/sich ändern
- wie verändern sich die Daten - einzelne Bits oder ganze Blöcke
- wie groß sind die Dateien
- wie wird die Checksumme berechnet
- usw.

daher wollte ich es mir einfach machen und nachfragen.

Habe übrigens zu Anfangszeiten der SSD mal etliche GB an Videodaten mittels Checksummen über einen längeren Zeitraum getestet und da gab es nach Monaten keine geänderten Checksummen.
 
Habe übrigens zu Anfangszeiten der SSD mal etliche GB an Videodaten mittels Checksummen über einen längeren Zeitraum getestet und da gab es nach Monaten keine geänderten Checksummen.

Genau das ist ja das Problem. Es ist sehr unwahrscheinlich. Wenn man dann aber nach 10 oder 20 Jahren, mal z.Bsp Bilder von früher ansehen will und festellt, dass diese nicht mehr lesbar sind, dann kann der individuell empfunde Verlust von Erinnerungsfotos schon recht groß sein.

Sieh dir mal das Video eines bekannten Youtubers / Fotografen an. Kleine Wahrscheinlichkeit, großer Schaden.
https://www.youtube.com/watch?v=xvbnhCDfREk&t=661s
 
  • Gefällt mir
Reaktionen: dg2rbf
Jedes Mal wenn ich mit den Gedanken spiele, wird es sehr schnell sehr kompliziert - und dafür ist es mir nicht wichtig genug -, denn da sind so viele Größen die man berücksichtigen muss:

- wie wahrscheinlich ist überhaupt dass gespeicherte Daten irgendwie kippen/sich ändern
- wie verändern sich die Daten - einzelne Bits oder ganze Blöcke
- wie groß sind die Dateien
- wie wird die Checksumme berechnet
- usw.
Aber das ist letztlich nicht relevant, wenn die Checksumme zum Erkennen von Fehlern benutzt wird und nicht zum Erkennen von Korrektheit.

Die Checksumme ist eine vorgegeben Funktion die für Werte ein Ergebnis berechnet. Wenn ich die selbe Funktion mit den Werten ein anderes Ergebnis liefert, kann ich absolut sicher sein, dass sich bei den Werten etwas geändert hat. Dafür ist die Methode bestens geeignet und es ist letztlich egal, wie sich die Checksumme genau berechnet.

Hingegen kann ich nicht darauf schließen, dass sich die Werte nicht verändert haben, wenn die Checksumme immer noch das gleiche Ergebnis liefert, denn das ist je nach Checksumme auch bei bestimmten Änderungen der Werte möglich.
 
Aber das ist letztlich nicht relevant, wenn die Checksumme zum Erkennen von Fehlern benutzt wird und nicht zum Erkennen von Korrektheit.
Die Korrektheit ist aber das Komplement der Fehlerhaftigkeit. ;) Wenn man somit weiß dass kein Fehler vorliegt, dann ist es korrekt. Wenn man die obige Aussage aber dahingehend ändert dass mit der Checksumme nicht alle Fehler erkannt werden können, dann passt deine Aussage.

Und dieses nicht alle kann ich eben schlecht abschätzen. Bei kleinen Dateien dürfte die Zahl der nicht erkannten Fehler sehr klein sein, bei sehr großen dagegen dürfte es komplett anders sein.
 
Zurück
Oben Unten