TimeMachine und Checksums: Großer Ordner mit vielen Dateien / Integritätsprüfung

Schiffversenker schrieb:
Ich vermute, der Satz stammt vielleicht aus recht alten Zeiten und aus der Großrechner-Szene, wo man wenige Aufgaben erledigte, die sich kaum änderten. Und da waren Änderungen vielleicht immer ein wenig experimentell.
Da gab es halt noch keine Vernetzung wie heute mit den sich immer ändernden Angriffsmöglichkeiten.
Zum Vergrößern anklicken....

Ich kann mir eher vorstellen, dass der Spruch von Entwicklern stammt, die ihren eigenen Assembler-Code oder die Cobol-Sourcen nicht mehr verstehen, weil man halt mal "quick&dirty" programmiert hat und keinen Bock hatte irgendwas zu dokumentieren,
 
lisanet schrieb:
Bevor du dich mit "bitrot" beschäftigs
Zum Vergrößern anklicken....
Darum geht es nicht, es reicht wenn die Platte aufgrund eines Defekts falsche Daten liefert. Ist mir bei inzwischen schon zwei brandneuen SSDs passiert, dass der Speicher von Anfang an Defekt war und innerhalb der ersten Monate wurden die abgespeicherten Daten schon korrupt bis die eine SSD nach einem halben Jahr komplettt ausgefallen ist. Die Ursache war erst dann klar, davor gabs komische Fehlermeldungen, MacOS hat Programme oft nicht mehr gestartet oder stürzte ab. Das kann jedem User auch mit ganz moderner Hardware passieren (das eine war eine Crucial-SSD mit 5 Jahren Garantie) und hat überhaupt gar nichts mit bitrot zu tun.
 
OmarDLittle schrieb:
Darum geht es nicht, es reicht wenn die Platte aufgrund eines Defekts falsche Daten liefert. Ist mir bei inzwischen schon zwei brandneuen SSDs passiert, dass der Speicher von Anfang an Defekt war und innerhalb der ersten Monate wurden die abgespeicherten Daten schon korrupt bis die eine SSD nach einem halben Jahr komplettt ausgefallen ist. Die Ursache war erst dann klar, davor gabs komische Fehlermeldungen, MacOS hat Programme oft nicht mehr gestartet oder stürzte ab. Das kann jedem User auch mit ganz moderner Hardware passieren (das eine war eine Crucial-SSD mit 5 Jahren Garantie) und hat überhaupt gar nichts mit bitrot zu tun.
Zum Vergrößern anklicken....

doch das hat genau damit was zu tun.

Wenn Daten auf einer Platte defekt sind dann gibt es zwei Möglichkeiten:

Der Controller meldet dem OS Fehler. In diesem Fall brauchst du nichts mit irgendwelchen Checksummen, da du allein durch den Lesefehler eben weist, dass die Daten defekt sind.

Der Controller meldet keine Lesefehler, die Daten sind aber dennoch falsch. Das ist "bitrot". Das kann nur dann passieren, wenn die Fehlerkorrektur des Controllers irgendwelche einzelnen gekippten Bits nicht erkennen würde oder zwar erkennt aber keine Korrektur durchführt und auch keine Fehler meldet.

Daher ist alles was sich mit bitrot beschäftigt nahe an Paranoia. Und alle anderen "defekten" Daten führen zu Fehlern. Wozu dann Checksummen? Man weiß ja, dass ein Fehler vorliegt. Wichtiger ist ein Backup der Daten, um mit nicht defekten Daten weiter arbeiten zu können.
 
  • Gefällt mir
Reaktionen: dg2rbf
lisanet schrieb:
Daher finde ich diesen Spruch des "never change..." als eine der dümmsten Erscheinungen in der IT. In etwa so sinnvoll wie einen barcode-Entstörstift.
Zum Vergrößern anklicken....
Frag mal die Postbank Kunden, ob die das für eine dumme Entscheidung halten würden.

Das ist halt eher eine Weisheit Richtung;
If it ain't broken, don't fix it.
lisanet schrieb:
Ich kann mir eher vorstellen, dass der Spruch von Entwicklern stammt, die ihren eigenen Assembler-Code oder die Cobol-Sourcen nicht mehr verstehen, weil man halt mal "quick&dirty" programmiert hat und keinen Bock hatte irgendwas zu dokumentieren,
Zum Vergrößern anklicken....
Da stammt der eher her:
Real programmers don't comment their code.
It was hard enough to write, it should be hard to understand.
 
Moin zurück, also meine Backup und die Strategie sollte fein sein, das war eigentlich bzw. ist nicht das Thema. Ich speichere auch keine Backups auf USB-Sticks :-D

Habe zwei TimeMachine Backup-Platten, die immer mal angestöpselt werden, und an unterschiedlichen Orten liegen und zwei weitere Platten mit CCC.

Wie gesagt, mir ging es nur um den Gedanken, dass die Dateien defekt werden könnten und sich dann durch alle Backups durchschießen, ehe ich es mitbekomme. Da nützt mir ja auch das beste Backup nicht, es sei denn, das ist so arg, dass mir das wirklich auffällt. Also ging es mir hier eher so um den Fall:

"hää komisch wieso öffnet er die Datei nicht mehr, die ist wichtig" --> "Backup 1 dranstecken und dort gucken: gleiches Problem" --> "nächstes Backup prüfen und hoffen..."

anders gesagt: dieses "nicht mitbekommen, dass was kaputt ist und dann nicht rechtzeitig eingreifen können, weil schon alle Backups das Problem aufgenommen haben" war eher so der Aufhänger dieses Threads.

Habe aber nun verstanden, dass das eher keine realistische Bedrohung ist und wenn eher die Platte anderweitig auffällig kaputt geht.

Was das Update-Thema angeht: verstehe beide Seiten und habe immer einen guten Kompromiss gefahren. Nicht immer sofort, aber auch nicht übertrieben spät. Nun hats mich aber bisschen abgehängt, das stimmt. Denke da aber allgemein auch drüber nach mir mal ein neues MacBook zu gönnen, um wieder aktuell zu sein. Seit 2015 kann man ja mal drüber nachdenken :-D

Zumal ich (ohne Tricks) standardmäßig ja auch mit dem 2015er MacBook Pro nicht weiter als Montery komme, zumindest nicht offiziell. Und das ist ja auch schon "alt".
 
Sharptype schrieb:
"hää komisch wieso öffnet er die Datei nicht mehr, die ist wichtig" --> "Backup 1 dranstecken und dort gucken: gleiches Problem" --> "nächstes Backup prüfen und hoffen..."
Zum Vergrößern anklicken....

das ist doch genau der Punkt auf den es ankommt.

Wenn macOS eine Datei nicht öffnen kann, wie soll die dann ins Backup kommen? macOS kann sie doch nicht öffnen.
 
  • Gefällt mir
  • Wow
Reaktionen: Debianer, Sharptype und tocotronaut
lisanet schrieb:
das ist doch genau der Punkt auf den es ankommt.

Wenn macOS eine Datei nicht öffnen kann, wie soll die dann ins Backup kommen? macOS kann sie doch nicht öffnen.
Zum Vergrößern anklicken....
Ich glaube wir reden aneinander vorbei. Der Zustand, der in diesem Fall auftritt, ist der gleiche. Der Zustand heißt: "Problem ist da" :-D

Mir geht es darum, dass ich das gerne irgenwie mitbekommen möchte und nicht dann, wenn es zu spät ist und ich meine Backups durchgehe, weil mir irgendwie - weil ich gerade an eine Datei will, die ich vielleicht sehr selten öffne - auffällt, dass da etwas nicht stimmt.

Daher zurück zur Frage im Initialpost: Werde ich irgendwie aktiv über so einen Zustand informiert bei der Backuperstellung? Die Antwort ist nein, das habe ich jetzt verstanden. CCC bietet dafür Mechanismen an, das weiß ich, aber hier ging es ja um TimeMachine eigentlich.
 
lisanets Antwort geht leider an der Realität vorbei: Ich hatte bereits geschrieben, dass ich zwei ab Werk defekte SSDs hatte. Die ließen sich die ersten Wochen normal verwenden bis sie nach einem halben Jahr hinüber waren. TM-Backups wurden gemacht. MacOS hat hier nicht das eine definierte Verhalten bei I/O-Fehler und sagt dem User "ich kann jetzt kein Backup machen weil deine Platte Fehler hat" sondern die Backups sind manchmal gelaufen, manchmal hat sich der Mac aufgehängt, zwischendurch ist er ab und zu abgestürzt oder hat keine Programme mehr geöffnet während die bereits geöffneten normal weiterliefen.

Sowas kann schlimmstenfalls das ganze Dateisystem ruinieren wo das Backup draufliegt!

Da waren 1TB an epubs und PDFs drin, niemals wäre es uns möglich gewesen die aus dem Backup alle durchzuprüfen ob sie sich öffnen lassen. Und blind davon ausgehen dass die alle in Ordnung sind ist nun wirklich nicht optimal. Glücklicherweise waren alle diese Daten auf einem NAS mit ZFS gespeichert und lagen nur in Kopie auf diesem Mac. Wir konnten daher einfach die SSD ersetzen und die known-good Kopien vom NAS wieder auf den Mac spielen.

Wie hätte ich dem User garantieren können dass alle Dateien im Backup inklusive der neuesten noch in Ordnung sind? Vielleicht hat das undefinierte Verhalten vom Mac das Backup beschädigt, vielleicht wäre auch alles in bester Ordnung gewesen. Bei mehreren TB an Daten ist das jedenfalls nicht prüfbar.

Die Lösung ist wie gesagt ein NAS, am besten eins mit ZFS das jeden Fehler erkennt. Ob man da nun bitrot nennt, diese Semantik-Spiele interessieren mich nicht, Fakt ist wenn du dort was speicherst kann das NAS aufs einzelne Bit genau sagen ob die Dateien einwandfrei sind und wenn man zumindest mit 2 Platten spiegelt (RAID1) werden Fehler auch automatisch korrigiert. Die Synologies können das mit btrfs und die QNAP-QuTS-hero-NAS können das mit zfs ab Werk machen.

Alles keine Hexerei, NAS kostet ein paarhundert Euro und alle Dateien die du darauf ablegst werden dann so geschützt. Wenn die rote Lampe blinkt und eine Platte kaputt ist dann muss sie ausgetauscht werden damit die Funktion gewährleistet bleibt, viel mehr ist da nicht. Wenn schon ein NAS-Kauf zuviel des Guten ist oder man meint das TM-Backup sei unfehlbar dann bin ich an der Stelle raus, MacOS und TM haben die gewünschte Funktionalität jedenfalls nicht drin, und Drittanbieterapps die zusätzliche Checksummen anlegen sind super aber das hältst auf Dauer nicht durch, dich darum zu kümmern. Daher einfach ein NAS zulegen, kannst auch mit Kabel direkt verbinden wie eine externe Platte. Alles Andere wäre das Rad neu zu erfinden für ein Problem das schon seit vielen Jahren trivial und billig gelöst wurde.

OpenZFS hatte ich in diesem Thread auch verlinkt, wenn du ohne NAS-Kauf direkt eine Platte am Mac so formatieren willst, dass es diese Prüfung drin hat. Mit TM ist das nicht direkt kompatibel, aber du kannst einfach so Daten rüberziehen wie auf jede externe Platte.
 
  • Gefällt mir
Reaktionen: Schlenk, bowman und dg2rbf
Sharptype schrieb:
Daher zurück zur Frage im Initialpost: Werde ich irgendwie aktiv über so einen Zustand informiert bei der Backuperstellung? Die Antwort ist nein, das habe ich jetzt verstanden.
Zum Vergrößern anklicken....

Woraus liest du, dass es ein nein gibt? Klar meldet TimeMachine Fehler, wenn es Daten nicht lesen kann, das Backup, warum auch immer, nicht erstellen kann. Wenn man log files lesen kann, kriegst du sogar mit, an welcher Datei ein Fehler aufgetreten sit.

Allen gemeinsam ist aber, dass der Fehler eben vom Controller an macOs an TimeMachine geliefert wird. Und der Fehler ist da schon da. Und zwar auf der Original-Platte. Fehler muss dabei nicht immer mit Datenkorruption zu tun habe. Auch total verbastelte Rechte können zu Lesefehlern führen.

Du versuchst hellszusehen und Fehler zu erkennen, bevor es das Betriebsystem erkennt. Das nennt man "bitrot". Die Möglichkeiten, Grenzen und Sinnhaftigkeit habe ich dir versucht zu erklären. Urteile selbst, ob das überhaupt möglich ist, welche Wahrscheinlichkeit dahinter steht und was du mit dieser Information an zusätzlichen Handlungsoptionen hast.

CCC verwendet im übrigen die identischen Betriebssystem-Routinen wie macOS. Für das initiale Backup soagr 100% identische Routinen, wie du sie auch mit Bordmitteln machen kannst.

Aber bitte, wenn es dir nervliche Beruhigung bringt, irgendwelche "Verifizierung des geschriebenen Backups" zu machen (was keine Integritätsprüfung ist) sondern eher der Zeit uralter 5,25" Floppy-Laufwerke entstammt, dann mach das.

Ich gebe es auf, hier weiterhin irgendwie was zu Verhältnismäßgikeit von Risiken und sinnvollen Sicherungsmaßnahmen zu sagen.
 
Also erstmal vielen Dank für die ganzen Informationen und Hinweise von euch. Da muss ich mich in Ruhe mal durcharbeiten. Grundsätzlich nehme ich aber mal mit, dass ich vielleicht der Technik ein wenig mehr vertrauen sollte und auch kann.

Ich werde die Tage mal versuchen auf Montery zu aktualisieren, evtl. refreshe ich da nochmal einen Thread, den ich vor einigen Jahren hier mal aufgemacht hatte. Und dann komme ich auch an die 6er Version von CCC mit der Verifizierungsfunktion, die ich mir zumindest gerne auch mal ansehen wollen würde.

Das mit dem NAS ist auch sehr gut zu wissen und dem entsprechenden Filesystem.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten