Hintergrund:
1. Ich arbeite mit einem MBP mit M1 pro-Prozessor und derjeweils aktuellsten Version von macOS
2. Ich hatte neulich einen Fall eines extremen Datenverlust (30+ TB) auf einer Synology DS1815+, der hier erschöpfend diskutiert wurde, ohne dass eine Ursache identifiziert werden konnte. Dieser Datenverlust hat mich dazu gebracht, nach alternativen RAID-Systemen zu suchen. Derzeit benutze ich neben der Diskstation eine OWC Mercury Quad Pro im RAID 5-Modus.
3. Auch auf diesem RAID-System kam es in den letzten Tagen wiederholt zu Datenverlusten. Daten wurden auf das RAID kopiert (und von mir auch von dort aus weiterverarbeitet).
4. Ich leide an einer generellen Instabilität meines macOS. Wiederholte Crashs werden vom System immer mit der Einleitung kommentiert, dass eine Kernel panic von einem Prozess Namens "USB-Tart" ausgelöst wurden. An meinem MBP betreibe ich per Thunderbolt ein LG 5K-Display mit USB-C 3fach HUB an dem wiederum ein alter Anker 7fach USB 3 Portreplikator läuft. Das OWC Mercury-RAID ist an einem zweiten Thunderbolt-Anschluss des MBP angeschlossen, läuft aber als USB-C 3.1-Anschluss (das OWC hat kein Thunderbolt.

Beobachtungen:
In den letzten Tagen hatte ich leider wiederholt die Gelegenheit, das Verhalten des OWC-RAIDs nach Kernel panics zu beobachten.
Dabei hat sich wiederholt der Verlust von großen Datenmengen gezeigt (und ist auch nachweisbar, s.u.), die jene Daten betreffen, die während der Sitzung geschrieben wurden, die durch den Crash beendet wurde. Diese Daten waren jedoch vor dem Crash unzweifelhaft auf dem OWC-RAID vorhanden und abgespeichert, was ich unter anderem anhand von Foto-Dateien beweisen kann. Gestern importierte ich eine Anzahl von RAW-Bildern in meine Fotobearbeitungssoftware und exportierte anschließend jpegs nach Fotos. In Fotos, dessen Mediathek auf einer einzelnen externen HDD liegt, sind die Bilder auch heute, nach einem erneuten Crash, noch vorhanden, nicht jedoch in meinen Verzeichnissen für RAW-Daten auf dem OWC-RAID.
D.h., dass die fertig geschriebenen RAW-Dateien nach dem Crash von dem OWV RAID verschwunden sind (vermutlich wurden sie im Inhaltsverzeichnis entfernt oder nicht aus einem vorübergehenden Inhaltsverzeichnis in das endgültige Inhaltsverzeichnis des RAIDs übertragen. Meine Fotos-Mediathek liegt übrigens nicht auf dem OWC-RAID, sondern wie gesagt auf einer herkömmlichen externen Festplatte, weshalb sich die importierten jpegs dort erhalten haben.
Vermutlich erklärt dieses Verhalten nach Crashs auch meinen oben verlinkten Datenverlust auf der Synology. Ich hatte ja angegeben, dass ich vor dem Verlust Ordner verschoben hatte. Es wäre also gut möglich, dass diese Ordner im Inhaltsverzeichnis der Sybology nicht in das endgültige Verzeichnis übertragen wurden, weil sich vor dem nächsten Herunterfahren ein Crash meines Systems ereignet hat. Das würde auch erklären, warum der Speicherplatz auf der Synology nach dem Ereignis nicht freigegeben wurde.
Ich vermute den Bug übrigens in macOS, weil ich mir nicht vorstellen kann, dass Synology und OWC SodtRAID den gleichen Fehler als Reaktion auf Crashs des verbundenen Computer eingebaut haben könnten.

Hat irgendjemand ähnliche Erfahrungen mit dem Verlust von "frisch geschriebenen" Daten auf seinem RAID gemacht? Halten die RAID-Experten hier den beschriebenen Verlust durch einen Fahler in macOS (Verhalten bei Crashs) für möglich?

Für euren Input wäre ich sehr dankbar!

Ok, ich komme doch noch einmal auf dieses Thema zurück:
Bei APFS werden Daten nicht überschrieben, sondern freie Speicherbereiche werden neu beschrieben und der bisher für die nun obsoleten Daten belegte Speicher wird stündlich für 24h in einem Snapshot gesichert.
Wenn viel auf der SSD geschrieben wird, gibt es umfangreiche Snapshots. Während es bei mir im Normalfall 7 GB sind, ist es bei einem Update auch mal 20 GB.
Schreibst Du sehr große Datenmengen, z.B. bei Datentransfers zwischen OWC/Synology/Mac? Werden diese Daten zwischenzeitlich auf der internen SSD gespeichert? Könnte es sein, dass der Speicherplatz wegen Snapshots knapp wird - auch wenn er als "verfügbar" deklariert ist?

Die Daten (ausschließlich während der crashenden Sitzung neu erstellte sind vom Verschwinden betroffen) wurden im Fall der Fotos (DxO) mit dem Finder direkt auf das RAID geschrieben. Dabei sind nicht nur die RAWs verschwunden, sondern auch der frisch angelegt Ordner, in den die Bilder abgelegt wurden. DxO wurde während der Bearbeitung mehrfach (mit Absicht) beendet und neu gestartet. Bei der Testversion handelt es sich nicht um eine Beta, sondern ein Version, die man vor dem Kauf ausführlich testen kann (Vollversion).
Die verlorenen Filme wurden aus eine Mediathek der öffentlich-rechtlichen Sender heruntergeladen und ebenfalls direkt auf dem RAID abgespeichert und im Finder umbenannt.

Für mich hat es den Anschein(!), als würde macOS mit der endgültigen Speicherung auf einem RAID warten, bis eine Sitzung ordentlich beendet wird. Stürzt der Rechner vorher ab, sind die Daten daher verloren, obwohl zwischenzeitlich mit ihnen gearbeitet werden konnte. – Ich habe keine Ahnung, ob APFS irgendetwas derartiges macht, aber dass es Verzögerung bei APFS gibt ist an der Verwaltung des freien Speichers deutlich, der eben erst nach einiger Zeit oder bei dringendem Bedarf freigegeben wird. Und genau das würde ich gerne einen APFS-Experten fragen, ob sich hier vielleicht ein Fehler in macOS eingeschlichen hat, der dazu führt, dass ein zwischenzeitlicher Absturz ein "Löschen"/"Nicht-Übernehmen" der Daten zur Folge haben könnte.

Ich habe derzeit knapp 10GB Snapshots. Die Daten werden ohne Zwischenspeicherung direkt auf das RAID geschrieben. Und ja, es geht um durchaus große Datenmengen, z.B. eine umfangreiche TV-Serie, die immerhin knapp 100GB hatte, die anschließend verschwunden war.

Ist das dann so zu verstehen?
1. Du speicherst Dateien extern auf NAS oder DAS.
2. Du bearbeitest Dateien auf NAS oder DAS mit DxO?
3. Gelegentlich (bei Crash) sind dann bereits auf DAS oder NAS gespeicherte Dateien weg?

Falls das richtig ist, macht DxO da was falsch.

Es ist nicht ganz klar, was "Sitzung" hier bedeuten soll, aber dieses Verhalten ist völlig selbstverständlich.

Das tritt seit über 50 Jahren bei jedem Betriebssystem, jedem Datenträger und jedem Format auf. Das ist ja der Grund, weshalb Volumes kaputt gehen können, wenn man sie ohne Auswerfen vom Computer trennt, bzw. das Betriebssystem abstürzt.

Jeder Computer hält zu sichernde Daten zunächst im RAM. Die Daten werden mit Verzögerung erst dann geschrieben, wenn Betriebssystem und Datenträger Zeit dafür haben, oder der für die Pufferung reservierte RAM-Bereich überläuft.

DxO macht überhaupt nichts falsch. Es sind alle Dateien nachgeprüft vorhanden und in einwandfreiem Zustand, wenn ich DxO beendet habe (was hier der Fall war, weil sich der Daten entfernende Crash erst einen Tag später ereignete). Und es geht auch um Filmdaten, die ebenso vorhanden, abspielbar und in einwandfreiem Zustand waren, jetzt aber nicht mehr vorhanden sind. Es sind diese verdammten Crashs, die die Daten anschließend in Luft auflösen.

Ich habe gerade mit dem Apple Support, zweite Ebene, gesprochen und den Crashreport auch dort hochgeladen. Das Problem ist auch für diese Supportebene zu komplex und wird deshalb an die zuständigen Ingenieure weitergeleitet. Was leider gleichzeitig bedeutet, dass frühestens bei einem größeren Update mit einer Lösung zu rechnen ist (14.1. soll gerüchteweise im Dezember erscheinen – na toll, kann ich nur sagen). Bis dahin kann ich nur hoffen, dass mir keine wirklich wichtigen Dateien verschwinden und muss zusehen, irgendwie mein Arbeiten auf einzelne Festplatten umzustellen, da auf die RAIDS gegenwärtig kein Verlass mehr ist (es sei denn ich fahre den Mac nach jedem Speicherzugriff einmal kurz runter).
Wenn jetzt wenigstens meine iCloud funktionieren würde, könnte das en Weg sein – tut sie aber auch nicht und ebenfalls ungeklärter Weise nicht. Es ist ein grandios beschissener Alptraum, wenn man auf einem solchen Gerät auch noch ein kleines Unternehmen zu führen hat.

genau richtig erklärt marcel, ich predige das auch immer meinen usern die platten/sticks nicht einfach abzuziehen.
daher meine frage, wurde der rechner zwischen den erstellten daten (die jetzt weg sind) und dem crash ausgeschaltet oder neugestartet?
und, auch wenns im nachhinein blöd klingt, sicherst du dein nas und die owc ab?
raid (ausser raid 0) schützt vor festplattenverlusst, aber nicht vor datenverlusst ...

Oha - wurde ja schon ganz schön viel geschrieben hier.

Leider kann ich aus Zeitgründen nicht alles durchlesen, aber meine Vorgehensweise wäre die:
Rechner checken, der immer abstürzt: meine Vermutung ist, dass weder Ventura noch Sonoma für den Datenverlust verantwortlich sind, sondern defekte Hardware (RAM oder SSD-Swap), die beim Absturz für schlimme Konflikte sorgen. Hier wäre zu erwähnen, dass man bei laufenden Problemen, in der Analysephase besser KEIN Systemupgrade (Ventura auf Sonoma) durchführt. Das macht die Fehlersuche meist nicht einfacher.

• Konstrukt aus mehreren lokal angeschlossenen Festplatten, die wohl durch ein Software-Raid angesteuert werden, auflösen bzw. eine anschließen und händisch oder automatisch Backuppen lassen. Das Problem ist hierbei, dass das Software-Raid, das wohl auf dem ständig aufhängenden Rechner läuft, natürlich nicht mehr arbeiten kann, wenn der Rechner sich aufhängt.

• Wie und wo ist die Synology oder jetzt eine OWC "dranhängt" habe ich noch nicht kapiert. Insgesamt scheint mir dein Netzwerkplan nicht transparent zu sein.
• Vielleicht hat Du es schon beschrieben und ich habe es überlesen, aber wie sieht Dein Netzwerkplan aus? Angefangen von Internet zu Router zu Firewall zu DNS-Server zu Synology (oder andere) zu Arbeitsrechnern und daran angeschlossene externe Platten. Gibt es Netzwerkdrucker? Wie werden die IPs verwaltet? Gibt es Switches oder Backbones? Woran hängen die etc. Zeichne am Besten mal einen Plan mit den dazugehörigen Netzwerkadressen.

Wie gesagt: (Nicht nur) ich glaube das einfach nicht. Das klingt wie Voodoo. Es ist einfach unmöglich, dass ein Crash auf einem Mac Tage später, nachdem Dateien erfolgreich auf ein NAS übertragen wurden, diese verschwinden lassen kann. Dazu müssen vom Mac aus Dateioperationen auf dem NAS durchgeführt werden. Dabei dürfte komplett ausgeschlossen sein, dass ein Crash ohne gerade aktive Dateioperationen bezogen auf genau diese Dateien diese Dateien löschen kann.

mit datenverlusst meine ich natürlich die durch versehentliches löschen oder so ...
ansonsten schützt die entsprechende raid-konfiguration natürlich vor datenverlusst wenn eine platte ausfällt ...

Was glaubst Du wohl, wie es mir da geht? Aber genau das ist mehrfach passiert. Und nachweislich!

Danke für deinen Kommentar. Ich fürchte allerdings, dass Du ums Lesen nicht herumkommen wirst, wenn du konstruktiv mitdiskutieren willst.

Vielleicht - Mutmaßung - sind die Datenmengen auf dem externen Laufwerk auch das Problem. Wenn da so viele Daten gleichzeitig geschrieben und gelesen werden (mediaanalysisd im Hintergrund!!) wird es dem Controller oder der SSD zu viel - für den Throttle-Down handelt der Controller eine andere Übertragunsgeschwindigkeit aus und möglicherweise wird deswegen ein neuer Eintrag in der DART mit einer neuen DAV Adresse vergeben. Ob das am USB-C Controller im Mac oder in den SSDs liegt ist da offen. Könnte auch auf einen Hardware-Defekt hinweisen. Passiert das häufiger, wenn du viele Daten von und zum externen Volume schickst?

Allerdings kann das die Probleme mit einer NAS nicht erklären, da diese immer eher gemütlich zu Werke geht.

PS: klar benutzt eine NAS kein APFS, weil es ja ein Server ist und daher auch wie ein solches benutzt wird. Das dort ganz Ordner verloren gehen finde ich tatsächlich noch unerklärlicher als am USB-C Medium.

uuups ... was habe ich überlesen? sorry
btw. falls nicht schon gefragt, stimmt datum und uhrzeit auf dem nas?

ssb:
Ich habe dem Apple Support meine Probleme genauso geschildert, wie ich sie hier dagelegt habe, also inklusive der Beteiligung von macOS/APFS an dem Verschwinden der Daten auf der OWC Mercury und der Synology. Der Mitarbeiter (zweite Ebene und macOS-Experte) hat alles ohne Kommentar mitgeschrieben und will es so nach Cupertino weiterleiten. Das scheint mir darauf hinzudeuten, dass er zumindest kkeine fachlichen Bauchschmerzen damit hatte, denn sonst kamen auf der zweiten Support-bene durchaus auch inhaltlich begründete Argumente gegen meine Vermutungen, wenn diese für gar zu abgehoben gehalten wurden.

Das Verschwinden auf der Synology (das weiterhin ohne Erklärung ist), kann ich mir nur aufgrund meiner Erfahrungen mit der Arbeitsweise von APFS erklären. Dinge geschehen bei APFS nicht immer zu dem Zeitpunkt, zu dem sie angestoßen werden (Freigabe von Speicher z.B.)- Ansonsten spekuliere ich ausgehend von meinen Beobachtungen, also auf deskriptiver Ebene. Feststeht, dass meine Diskstation sämtliche Daten "vergessen" hat, die zuvor, also während einer ebenfalls gecrashten macOS-Session verschoben hatte. Das kann ich mir nur so erklären, dass macOS ein Protokoll über solche Operationen führt und mindestens beim Neustart von Ist-Zustand und Soll-Zustand auf RAID-Systeen vornimmt. Dabei scheint es sich un bester "Rechthaberei" zum einzigen gültigen Maßstab zu erheben und entfernt alles, was nicht in seinen eigenen (allerdings unvollständige, da gecrashten) Verzeichnissen steht. Schwupp ist alles weg (gleichgültig ob auf der Synology oder dem OWC.
Natürlich ist das reine Spekulation. Aber es würde exakt alles erklären, was mir an rätselhaften Dingen mit meinen RAIDs in den letzten Monaten passiert ist. Jetzt müsste nur noch ein Experte für APFS klären, ob so etwas möglih ist oder nicht. Auf der deskriptiven Ebene ist das einfach genau die0 Problematik, die mir widerfahren ist, wobei ich eine Ursache in den RAIDs ausschließe, weil zwei völlig unabhängige RAIDS mit unterschiedlicher Technologie von verschiedenen Herstellern betroffen waren.

Falls jemand also mal mit einem Mac-Ingenieur zu tun hat, der am Betriebssystem arbeitet, fragt ihn doch bitte mal nach einer Erklärung für meinen mehrfachen Datenverlust. Mir ist dabei sehr bewusst, dass es vielleicht eine andere Erklärung gibt, aber die reine Beschreibung der Verluste legt einfach erstmal meine obige Erklärung nahe. (Übrigens habe ich mir gerade eine externe Samsung t7-SSD gekauft, auf die ich nun bis zur Behebung dieses Problems sämtliche Daten kopieren werde, die eigentlich auf den RAIDS aufbewahrt werden sollen. Irgendwie muss ich ja arbeitsfähig bleiben – und nach jedem Speichern den Rechner neu zu starten ist einfach völlig unpraktikabel.

Herzlichen Glückwunsch. Mit der T7 kommst du vom Regen in die Traufe. Die T7 hat einige Probleme, gab da mal eine Charge die komplett weggestorben ist und auch die aktuellen Rezensionen lesen sich nicht gut was Datenverlust betrifft.
Wenn es Geschwindigkeit sein muß und auch stabil sein soll, dann nimm eine m.2 in einem USB-C oder Thunderbolt Gehäuse.

Ich habe schon eine t7, die wunderbar läuft. Platte mit Gehäuse geht, bei dem, was ich dann kaufen wollte(!), locker ins doppelte. Außerdem scheint es, ehrlich gesagt überhaupt keine Speichermedien zu geben, über die nicht irgendwer Horrorgeschichten zu berichten hat.

Das ging meiner Meinung nach um SanDisk und nicht um Samsung.
Habe auch eine T7, läuft gut.

Auf der NAS hat das nicht - gar nichts - mit APFS zu tun. Das ist ein Netzwerk-Share das in den meisten Fällen Samba (smb://) verwendet. Der Finder weiß gar nicht, in welchem Format das Netzwerk-Volume formatiert ist - interessiert ihn auch nicht.

Der geeignete Ansprechpartner dürfte Quinn „The Eskimo“ sein Ich hatte mich in den Labs während vergangener WWDCs schon öfter mit ihm über - ähhm… - spezielle Themen unterhalten.

Beobachte mal in der Aktivitätsanzeige die Festplattenzugriffe, was sich da so tut. Ich habe durchaus noch immer den Verdacht, dass medianalysed im Hintergrund Bilder und Filme analysieren will. Wenn du da größere Datenmengen exportierst, ist der damit auch eine ganze Weile beschäftigt. Mag sein, dass der Amok läuft, aber er ist in der Vergangenheit eher dadurch aufgefallen, dass er viel CPU-Last erzeugte (und man das am System gespürt hat).
Wie gesagt, ich habe nicht den Verdacht, dass mediaanalysed der Grund deines Problems ist, aber wenn der loslegt nachdem du größere Daternbmengen exportiert hast, dann kommt dein System irgendwo an Grenzen.
Wobei - vielleicht ist auch was in der Hardware defekt, I/O-Chips in dem SoC? Hattest du das schon bei älteren Macs?

"https://discussions.apple.com/thread/252210055", ähnlich, Hardware Fehler, Macbook Air M1.

Ich habe noch nie eine große Last bei meinem MBP bemerkt. mediaanalysed läuft gegenwärtig laut Aktivitätsanzeige gar nicht. Es waren auch keine großen Mengen an Bildern, die hochgeladen habe, vielleicht 50-60. Und auch die Filme waren vielleicht 30 Folgen einer Serie. Allerdings kam mir das MBP heute früh relativ warm vor, vielleicht 30 °C, verglichen mit sonst Raumtemperatur. Ich werde es beobachten.
Meine Synology benutzt tatsächlich SMB für die Verbindung zum Mac. Hättest du denn eine andere Erklärung dafür, warum ausgerechnet die vor dem Crash neu geschriebenen Daten verschwinden?

Der OWC Support hat sich gerade gemeldet – wie immer außerordentlich schnell, höflich und zugewandt – und um weitere Daten von meinem RAID gebeten. Ein selektives Verschwinden sei ihnen bisher noch nicht untergekommen. Ich habe sie sehr kurz über die Vorgeschichte mit der Synology und den heutigen Anruf beim Apple support informiert und gebeten gründlicl nachzuforschen, da die Verkettung von Crashs und dem Löschen zwischenzeitlich geschriebener Daten meinen Computer derzeit für die Arbeit fast unbenutzbar mache.
Ich bin gespannt, ob sie etwas herausfinden. Immerhin setzen sie selbst APFS als mögliches Format auf ihren RAID-Laufwerken ein. Ic hoffe also, dass OWC jemanden im Haus hat, der. sich im Detail mit APFS auskennt. Mal sehen ...

Ach herrje, die Diskussion läuft ja schon wieder so wie seinerzeit mit dem Synology-Raid-Problem. Überall wird die Schuld von Rosember gesucht, aber er macht immer alles richtig, bei geringstem Technikverständnis. Irgendjemand oder irgendein Hersteller muss verantwortlich sein.

Das mit dem OWC Softraid habe ich dir übrigens 1:1 genauso vorausgesagt, damals im Synology-Thread. Wunder oh Wunder, es ist genauso passiert.

Hast Du wenigstens mal den Schreibcache beim Softraid abgeschaltet?

Seltsam, dass das hier so selten erwähnt wird, aber ich würde an Rosembers Stelle tatsächlich als erstes die Qualität/Stabilität der Netzspannung in den Räumen mit den betroffenen Geräten prüfen. Insbesondere, wenn andere große (oder viele zusätzliche) Verbraucher zusätzlich anspringen (z.B. Herd, Waschmaschine, Kühlschrank, etc.).

Für mich deutet es tatsächlich auf kleine „lokale“ Brownouts hin, die bei „normalen“ Geräten nicht auffallen, aber bei empfindlicher Elektronik zu sehr seltsamen Effekten führen können.

Und diese Netzspannungssschwankungen löschen dann Daten, die vor zwei Tagen auf das RAID geschrieben wurden? Da glaube ich nicht dran, sorry, zumal der Rechner auch noch ein MacBook Pro mt vollem Akku ist.

Danke für deinen Beitrag, der mich allerdings sehr blendet. Mühsam erkennen konnte ich im Strahlenglanz nur, dass der Schreib-Cache wohl kaum etwas mit Daten zu tun haben kann, die vor zwei Tagen auf das RAID geschrieben wurden.

Wauzeschnuff: Brownouts wurden gestern von SSB schon angesprochen; Rosember hatte dazu geschrieben, dass zumindest sein LG Ultrafine 5K-Monitor über eine unterbrechungsfreie Stomversorgung läuft. (Nachtrag: Rosember war schneller und hat schon darauf geantwortet)

Support-Mitarbeiter sind Telefonagenten. Die haben sehr wenig fachliche Kompetenz, sind aber professionell darauf geschult, immer freundlich zu sein, egal was der Kunde erzählt.

Wie schon mehrfach erklärt, kann macOS auf der Synology nicht beteiligt sein. Wenn macOS dort irgendwie eingreifen könnte, wäre das eine Sicherheitslücke. Und APFS kommt dort sowieso nirgendwo zum Einsatz.

macOS 14.1 wird voraussichtlich heute Abend erscheinen. Ein "größeres" Update wäre macOS 15, das voraussichtlich im Herbst 2024 erscheint. Wenn es tatsächlich ein Bug im Kernel sein sollte, der durch SoftRAID aufgedeckt wird (hier: im Treiber für das DMA-Speichermanagement des Apple T6000 = M1 Pro), kann es aber auch noch ein paar Jahre dauern, bis das behoben wird.

Diese Netzschwankungen könnten zum Beispiel dafür sorgen, dass Daten die im Augenblick der Netzschwankung geschrieben werden, die Dateisystemtabelle im Dateisystem so beschädigen, dass Daten die schon vor langer Zeit geschrieben wurden nicht mehr wiedergefunden werden können. Bitte beachte, dass Probleme zu einem Zeitpunkt X durchaus Effekte auf Daten haben können, die lange zuvor geschrieben wurden (und damals auch intakt waren).

Zumal Deine umfangreichen und völlig unzusammenhängenden (NAS, USB-Geräte, etc.) Probleme auf eine Korrelation hindeuten, die auf eine außerhalb des Systems liegende Ursache hindeuten. Ich zumindest würde leichte Instabiliäten in der Netzspannung nicht ohne weiteres ausschließen.

Das ist richtig, aber von Problemen mit seinem Monitor hat er ja auch nicht berichtet. Nur von Problemen mit dort angeschlossenen Geräten, bzw. Geräten die über einen weiteren aktiven Hub angeschlossen sind. Und von Geräten (wie das NAS) die ebenfalls eine eigene Stromversorgung besitzen.

Puh, was für ein Thread.

Ich gebe nun auch mal meine 2 Cents dazu. Netzschwankungen halte ich eher weniger für eine Ursache. Seit wir unsere PV haben, beschäftige ich mich sehr intensiv mit dem Thema und wir haben eigentlich kaum nennenswerte Schwankungen in Deutschland, die gerade auch für die Häufung an Crashes sprechen würden. Es sei denn, Du betreibst auf der Seite nach dem Hausanschluss Großverbraucher, aber selbst eine Wärmepumpe die beim Start 5kW zieht, bringt bei mir keine Displays, Macs, Festplatten oder NAS zum Crash.

Die Argumentation hinsichtlich T6000DART wurde ja in den Apple Discussions bereits geführt und bei einigen Anwendern wurden tatsächlich MLB getauscht. Ich nehme an, Du kannst das nicht mit einem zweiten Mac rekonstruieren, daher dieses Thema bitte im Hinterkopf behalten.

Ansonsten habe ich bei Mac zahlreiche Abstürze durch USB Geräte erlebt. Da hat selbst das Anschließen eines USB-Sticks mal einen Panic verursacht - ein anderes Mal wieder nicht. Also Wackler auf dem Bus können hier den Crash auslösen, ohne dass man die zwangsläufig mit Dateisystemproblemen oder Datenverlusten in Verbindung bringen würde - normalerweise.

Hier verweise ich auf die Apple Support Dokumente und auch auf das bereits gesagte: Minimalkonfiguration. Alle Fehlerquellen ausschließen und beobachten. Und ja, bei Exoten kann das auch mal Tage oder länger dauern. Das ist einer der Gründe, warum sich Fehler auch in Releases einschleichen, die dann erst viel später (die berühmten .3er Releases) behoben werden. Weil eben nicht alles sofort offensichtlich ist.

Zum Datenverlust selbst, hier habe ich auch geöffnete Dateien und Caches im Verdacht. Das kann sowohl auf einem NAS als auch auf einem DAS passieren, ebenso aber auch auf einer einfachen Festplatte. Und die Analyse von Bilddaten passiert halt ohne Einflussnahme des Anwenders zu irgendeinem Zeitpunkt. Wenn da gerade Metadaten in Ordner geschrieben werden und die Blöcke nicht ordentlich aufs Dateisystem zurückgeschrieben werden, kann auch mal ein ganzer Ordner korrupt werden und dann eben nicht mehr angezeigt. Daher möchte ich mich hier weder auf T7, OWC, Synology festlegen. Es ist einfach für das Dateisystem "verwirrend", wenn man den Schreibvorgang nicht abschließt. Und wenn der Ordner "Müll" ist, wird der halt entsorgt.

Ich möchte Dir Rosember jetzt keine Vorwürfe machen, außer dass Du vielleicht wirklich mal die Ratschläge hinsichtlich der angesprochenen Minimalkonfiguration betrachten solltest, denn vielleicht ist es ja wirklich ein Fehler in Deinem Setup - und wie von mir geschrieben, es kann einer sein, den keiner im Verdacht hat. Es kann auch einfach ein USB-C Kabel sein, das ohne angeschlossenes Gerät leer am Hub oder direkt am Rechner angeschlossen ist. Defekte Kabel können auch den USB-Treiber "verwirren", ich denke da an die Lightning-Kabel, die ja auch eine gewisse Logic durch Chips in den Steckern enthalten.

Final: rotierende Backups. Speichere die Daten auf zwei Laufwerke und werfe eines nach dem Speichern aus. Dann kannst Du nach einem Crash vergleichen, was bei dem getrennten Medium passiert ist. Das sollte ja intakt bleiben.

Viel Erfolg.

Nein, das ist habe ich so nicht geschrieben – was aber weit oben im Thread war, deshalb hier noch einmal die Klarstellung: Die Geräte an dem Monitor und an dem alten Anker USB-Hub, den ich hoffentlich heute ersetzen kann, funktionieren völlig störungsfrei. Probleme mach(t)en nur die Synology (vor zwei Monaten), die Teil des Netzwerks war und das OWC RAID (DAS), das direkt am Mac angeschlossen ist. Alle datenkritischen Geräte hängen übrigens an der USV, also Synology, OWC, Mac und externe Festplatten mit eigenem Netzteil.

Es geht doch um das "OWC Mercury Elite Pro Quad"? Ob man das wirklich "RAID" oder "DAS" nennen sollte, ist die Frage.

Das ist lediglich ein "USB 3.1 Gen 2"-Gehäuse für 4 SATA-Platten. Alle RAID-Funktionen werden ausschließlich per Software erbracht. Das Besondere ist nur, dass eine kostenlose Lizenz für SoftRAID mitgeliefert wird.

Danke für deinen Beitrag, Stefanie Ramroth!
Zu den "geöffneten Daten und Caches": Das hochgradig irritierende an den Verlusten ist ja gerade, dass sie ebn nicht geöffnete Dateien betreffen. Sämtliche Anwendungen, die auf die verlorenen Daten zugriffen, waren zum Zeitpunkt des Crashs und anschließenden Verlustes (lange) geschlossen. Das betrifft sowohl die Fotos als auch die Videos, die verschwunden sind. Im übrigen ist auch eine reine Textdatei (RTF) verschwunden, was für mich Zweifel an der "Medien-Hypothese" weckt.
Bezüglich der schrittweisen Fehlersuche bin ich längst dabei. Der alte Anker-Hub wird heute ersetzt und auch die Benutzung des USB-Hubs am Monitor werde ich damit beenden.
Und zu den Backups: Diese laufen bei mir ständig und für sämtliche Daten. Allerdings sichere ich Daten je nach Wichtigkeit mit unterschiedlicher Frequenz. Der Hintergrund ist ganz einfach die Systemauslastung und die Auslastung vor allem des OWC RAIDs. Wichtige Daten werden jede Stunde gesichert, weniger wichtige einmal am Tag, "Unterhaltungsdaten" wie die betroffenen Videos einmal pro Woche. Es hilft aber leider kein Backup, wenn der Computer crasht, bevor das erste Backup geschrieben wurde. Und das gilt leider in gleichem Maße für stündliche wie für wöchentliche Backups. Die einzige Möglichkeit, Daten auf dem OWC RAID sicher zu schützen, scheint im Moment zu sein, den Mac(! – nicht das RAID!) sofort nach dem Schreiben der Daten neu zu starten (was natürlich in keiner Weise praktikabel ist).
Ich war auch eigentlich dabei, meine Datensicherung von zwei jeweils durch RAID 5 bzw. 6 zusätzlich geschützten Datenspeichern auf drei umzustellen. Allerdings fehlt mir dafür aktuell schlicht das Kapital, das sich durch den Austausch des Hubs und den Kauf der Samsung t7 auch nicht weiter vermehrt hat. Und davon abgesehen bringen auch drei Backups aufgrund der gerade beschriebenen Crashs keine Sicherheit, solange die Daten nicht kopiert worden sind.

Das ist richtig. Nenn es wie du willst. Entscheidend ist, dass es als RAID und DAS fungiert und das die Festplatten tatsächlich zusammenarbeiten. Dass natürlich auch SoftRAID eine Quelle des Problems sein kann, ist ja völlig klar.
Genauso klar ist übrigens, dass APFS sehr wohl auf dem OWC zum Einsatz kommt, denn so habe ich die Festplatten formatiert (SoftRAID bietet die Auswahl zwischen HFS+ und APFS). Mein (rein deskriptiver!) Eindruck ist, dass irgendeine Instanz (wo auch immer) mitprotokolliert, was auf dem OWC-Gerät für Daten geschrieben werden – und diese nach einem Crash entfernt, weil das Betriebssystem des Macs bei Crashs nicht ordnungsgemäß heruntergefahren wurde (also quasi vorläufige Datenanlagen nicht in endgültige umgewandelt wurden). Mein Verdacht richtet sich dabei auf macOS, weil ausschließlich der Mac crasht, aber nicht das OWC und weil alle Daten, die dann auf dem OWC verlorengehen, natürlich letztlich vom Mac dorthin befördert wurden. Ich habe keine Ahnung, ob es solche Protokolle gibt und ob sie, so es sie gibt, ein solches Verhalten auslösen könnten, aber es ist die einzige rationale Erklärung, die dafür habe, dass genau diese Daten auf dem OWC verschwinden.
Du hast jetzt wiederholt gesagt, dass könne nicht sein. Aber welche andere Erklärung gibt es dann dafür, dass genau diese Daten verschwinden? Der Zusammenhang mit der jeweils durch Crash beendeten Mac-Sitzung ist völlig eindeutig. Hättest du den eine Erklärung dafür, warum genau diese Daten betroffen sind?

Da auch auf dem OWC APFS zum Einsatz kommt, werden auch dort Snapshots angelegt. Das gehört zur Funktionsweise von APFS. Wie Snapshots mit einem RAID funktionieren, ist mir nicht klar. Das müssten doch dann 4 Snapshots pro Stunde sein? Also immer dort wo physisch die alten, obsoleten Daten auf der jeweiligen Platte liegen.
PS. Das ↑ ist eine Frage ...

Das ist ja wohl selbstverständlich und hat niemand bestritten.

Nun ja, aber das OWC-Gerät ist kein DAS, sondern nur ein Gehäuse ohne Betriebssystem. Deshalb kann es voll betroffen sein, wenn die steuernde Software (nämlich der Mac) abstürzt.

Das ergibt so keinen Sinn. Bei einem Crash des Software-RAID können alle Daten auf dem OWC verschwinden, wenn zufällig gerade eine zentrale Datenstruktur des Dateisystems im Schreibzugriff war.

Das OWC kann doch garnicht crashen, wenn da wer ein Problem macht ist es am wahrscheinlichsten das SoftRaid. Den Controller im OWC kann man natürlich auch nicht gänzlich ausschließen, aber im Gesamtbild deiner Problem halte ich den unschuldig.
Zu den offenen Dateien: das sind nicht nur die, die du selber öffnest sondern auch alle, die vom System selber genutzt werden. Das meiste davon wird zwar sicher „nur lesend“ genutzt, aber es wird sicher mer Dateien vom System geben, die dauerhaft mit Schreibzugriff „offen“ sind als die paar von die selber geöffneten Dateien.
Diese ganze „ Geschichte“ das nach einem Crash irgendwas „aufräumt“ was nicht mehr „zu den eigenen Logs paßt“, halte ich für extrem unwahrscheinlich. Das könntest du aber auch selber sehr schnell prüfen, wenn du nach dem Crash den Computer aus läßt und mit einem 2. die Daten auf den Laufwerken kontrollierst.

An deiner Stelle würde ich einfach ein Testsystem auf einer frischen Platte ohne SoftRaid erstellen und darauf je 14 Tage arbeiten und dann erst jeweils eine weitere Komponente hinzufügen. SoftRaid wäre wirklich erst ganz am Ende in dieser Versuchsreihe dran mit der Installation.

Diese Snapshots sind zumindest für mich als normalen Benutzer allerdings nicht sichtbar – falls es sie tatsächlich geben sollte.

Das ist aber nachweislich nicht der Fall. Wie also könnte eine Erklärung aussehen, die dazu führt, dass nur die aktuellsten Daten gelöscht werden / verschwinden? Das ist meine Frage.

Das sind ja durchaus zielführende Vorschläge. Aber ich weiß leider nicht recht, wie ich die umsetzen soll. Denn SoftRAID muss mit Lizenz erworben werden, damit man es auf einem anderen Computer nutzen kann. Mein ater iMac hat zudem gerade anscheiennd seinen Geist aufgegeben (geht nicht mehr an). Und auch die Vorschläge mit dem frischen Laufwerk sind nicht so ohne weiteres umzusetzen. Wo soll ich mit meinen Daten hin, ohne nur mit einem einzigen Backup dazustehen? Denn um das OWC ohne SoftRAID zu betreiben, müsste ich die Platten wohl formatieren. Und – wie gesagt – meine finanziellen Ressourcen sind begrenzt.

Nur so am Rande, und ich denke nicht, dass das in Rosembers Fall die Ursache ist:

Das stimmt. Aber in Hausverdrahtungen, die noch nicht WAGOisiert ( ) sind, lockern sich nach Jahrzehnten gerne mal Schraubverbindungen (z. B. an den Leitungsschutzschaltern im Verteiler/Zählerschrank).
Hatte mal einen Fall, wo ein locker sitzender Nullleiter zwei elektronische Drehstrom-Zähler und einen Garagentorantrieb zerstört hat. Schraube festgezogen Probleme weg!

Die Formulierung "es können alle Daten verschwinden" bedeutet, dass eine scheinbar zufällige Beschädigung des Dateisystems an irgendeiner unvorhersagbaren Stelle auftreten kann.

Es können die neuesten Daten verschwinden.
Es können die ältesten Daten verschwinden.
Es können alle Daten verschwinden.
Vielleicht passiert überhaupt nichts.
usw.

macOS führt nach einem Absturz eine automatische Prüfung und Reparatur aller angeschlossenen Volumes durch. Das Ergebnis ist im Systemprotokoll nachzulesen, das aber regelmäßig bereinigt wird. Dauerhaft aufbewahrt werden nur die Protokolle von HFS-Prüfungen, nicht die von APFS-Prüfungen.

Korrektur: Es wird HFS und APFS protokolliert. Unterschiede in der Aufbewahrung gibt es nur bei manuell angestoßenen Prüfungen in bestimmten Sonderfällen.

Vom System automatisch durchgeführte Prüfungen von APFS-Volumes werden in /var/log/fsck_apfs.log festgehalten.

Nicht wirklich. Snapshots werden nur angelegt, wenn dies nötig ist. Das Betriebssystem legt für sich selbst eine versiegelte Kopie auf einem Snapshot an, von dem es startet. Außerdem kann bei System-Updates ein Snapshot des System-Volumes erzeugt werden. Ansonsten legen aber eigentlich nur Datensicherungsprogramme (wie Time Machine oder CCC) Snapshots an, und zwar bei jeder Sicherung auf allen in der Sicherung enthaltenen Quell-Volumes.

Das Dateisystem "weiß" nicht, auf welcher Art von Blockspeichergerät es liegt. Es sieht nur nummerierte Datenblöcke, die geschrieben oder gelesen werden können, sonst nichts. Ob das Gerät eine magnetische Festplatte, eine SSD oder ein RAID ist, spielt keine Rolle.

Bei APFS ist das sogar noch weiter virtualisiert, denn zwischen physischer Platte und Volume liegt zusätzlich noch der "Container", eine partitionslose, synthetische Blockspeicherplatte, die beliebig viele Volumes aufnehmen kann.

Danke für den Hinweis! Ich habe auf meinem Mac sowohl die /var/log/fsck_apfs.log Datei als auch eine /var/log/fsck_apfs_error.log. Beide Dateien werden offenbar kontinuierlich weitergeführt. Die Log-Datei ohne error im Namen seit dem 26. September, die mit error im Namen seit dem 17. Oktober. Beide decken also den kritischen Zeitraum am Wochenende ab und weisen, wie mir zufällig beim Reinschauen aufgefallen ist, auch Einträge zu dem OWC-Gehäuse auf. Wonach sollte ich in welcher Datei suchen (insbesondere die Log-Datei ohne error ist extrem umfangreich, daher verbietet es sich sie hier reinzukopieren)? Vielleicht ließen sich aber zu beachtende Passagen hier anführen?

Noch eine Anmerkung zu den verschwundenen Dateien: Es sind nun in bisher vier von mir beobachteten Fällen ausschließlich die neuesten Dateien gewesen, die (da ich das natürlich nicht vollständig überprüfen kann:) zumindest auch betroffen waren. Das ist schon sehr auffällig, wenn auch noch kein 5-Sigma-Beweis, wie ihn die Naturwissenschaft fordert.

Marcel Bresink:
Hier ist der Auszug aus der /var/log/fsck_apfs.log-Datei für den Zeitraum, in dem es zu Datenverlust kam. Abgesehen von den relativ vielen Meldungen, kannst Du daraus irgendetwas zum Geschehen ableiten? Der kritische Datenverlust ereignete sich, bei oder nachdem der Mac am Morgen des 21.Okt. abgestürzt war.

/dev/rdisk10s1: fsck_apfs started at Thu Oct 19 09:59:42 2023
/dev/rdisk10s1: ** Checking the container superblock.
/dev/rdisk10s1: Checking the checkpoint with transaction ID 6241.
/dev/rdisk10s1: ** Checking the object map.
/dev/rdisk10s1: ** Checking volume /dev/rdisk10s1.
/dev/rdisk10s1: ** Checking the APFS volume superblock.
/dev/rdisk10s1: The volume Iron Wolf 8TB was formatted by diskmanagementd (2142.140.9) and last modified by apfs_kext (2235.0.13).
/dev/rdisk10s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk10s1: fsck_apfs completed at Thu Oct 19 09:59:42 2023


/dev/rdisk16s1: fsck_apfs started at Thu Oct 19 09:59:46 2023
/dev/rdisk16s1: ** Checking the container superblock.
/dev/rdisk16s1: Checking the checkpoint with transaction ID 88421.
/dev/rdisk16s1: ** Checking the object map.
/dev/rdisk16s1: ** Checking volume /dev/rdisk16s1.
/dev/rdisk16s1: ** Checking the APFS volume superblock.
/dev/rdisk16s1: The volume OWC Merc RAID5 was formatted by newfs_apfs (2142.140.9) and last modified by apfs_kext (2235.0.13).
/dev/rdisk16s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk16s1: fsck_apfs completed at Thu Oct 19 09:59:46 2023


/dev/rdisk3s5: fsck_apfs started at Fri Oct 20 06:10:33 2023
/dev/rdisk3s5: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s5: fsck_apfs completed at Fri Oct 20 06:10:33 2023




/dev/rdisk1s1: fsck_apfs started at Sat Oct 21 16:07:58 2023
/dev/rdisk2s1: fsck_apfs started at Sat Oct 21 16:07:58 2023
/dev/rdisk3s1: fsck_apfs started at Sat Oct 21 16:07:58 2023
/dev/rdisk3s1: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk1s1: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s1: fsck_apfs completed at Sat Oct 21 16:07:58 2023
/dev/rdisk3s1: fsck_apfs completed at Sat Oct 21 16:07:58 2023


/dev/rdisk2s1: ** Checking the container superblock.
/dev/rdisk2s1: Checking the checkpoint with transaction ID 124.
/dev/rdisk2s1: ** Checking the object map.
/dev/rdisk2s1: ** Checking volume /dev/rdisk2s1.
/dev/rdisk2s1: ** Checking the APFS volume superblock.
/dev/rdisk2s1: The volume Recovery was formatted by newfs_apfs (1934.101.3) and last modified by apfs_kext (2142.140.9).
/dev/rdisk2s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk2s1: fsck_apfs completed at Sat Oct 21 16:07:58 2023


/dev/rdisk3s3: fsck_apfs started at Sat Oct 21 16:07:59 2023

/dev/rdisk3s3: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s3: fsck_apfs completed at Sat Oct 21 16:07:59 2023

/dev/rdisk1s2: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk1s2: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s2: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk2s2: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk2s2: ** Checking the container superblock.
/dev/rdisk2s2: Checking the checkpoint with transaction ID 124.
/dev/rdisk2s2: ** Checking the object map.
/dev/rdisk2s2: ** Checking volume /dev/rdisk2s2.
/dev/rdisk2s2: ** Checking the APFS volume superblock.
/dev/rdisk2s2: The volume Update was formatted by com.apple.MobileSo (1934.101.3) and last modified by apfs_kext (2142.140.9).
/dev/rdisk2s2: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk2s2: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk3s2: fsck_apfs started at Sat Oct 21 16:07:59 2023

/dev/rdisk1s3: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk1s3: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s3: fsck_apfs completed at Sat Oct 21 16:07:59 2023

/dev/rdisk3s2: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s2: fsck_apfs completed at Sat Oct 21 16:07:59 2023



/dev/rdisk3s4: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk1s4: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk3s4: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s4: fsck_apfs completed at Sat Oct 21 16:07:59 2023

/dev/rdisk1s4: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk1s4: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk3s5: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk3s5: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s5: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk3s6: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk3s6: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s6: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk3s3s1: fsck_apfs started at Sat Oct 21 16:07:59 2023
/dev/rdisk3s3s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s3s1: fsck_apfs completed at Sat Oct 21 16:07:59 2023


/dev/rdisk5s2: fsck_apfs started at Sat Oct 21 16:08:03 2023
/dev/rdisk5s2: ** Checking the container superblock.
/dev/rdisk5s2: Checking the checkpoint with transaction ID 72736.
/dev/rdisk5s2: ** Checking the object map.
/dev/rdisk5s2: ** Checking volume /dev/rdisk5s2.
/dev/rdisk5s2: ** Checking the APFS volume superblock.
/dev/rdisk5s2: The volume T7 Shield was formatted by diskmanagementd (2142.120.7) and last modified by apfs_kext (2235.0.13).
/dev/rdisk5s2: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk5s2: fsck_apfs completed at Sat Oct 21 16:08:03 2023


/dev/rdisk3s5: fsck_apfs started at Sat Oct 21 16:08:05 2023
/dev/rdisk3s5: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s5: fsck_apfs completed at Sat Oct 21 16:08:06 2023


/dev/rdisk7s1: fsck_apfs started at Sat Oct 21 16:08:13 2023
/dev/rdisk7s1: ** Checking the container superblock.

/dev/rdisk8s2: fsck_apfs started at Sat Oct 21 16:08:13 2023
/dev/rdisk8s2: ** Checking the container superblock.
/dev/rdisk7s1: Checking the checkpoint with transaction ID 120966.
/dev/rdisk7s1: ** Checking the object map.
/dev/rdisk7s1: ** Checking volume /dev/rdisk7s1.
/dev/rdisk7s1: ** Checking the APFS volume superblock.
/dev/rdisk7s1: The volume 2TB auf 4TB-Platte was formatted by diskmanagementd (2142.120.7) and last modified by apfs_kext (2235.0.13).
/dev/rdisk7s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk7s1: fsck_apfs completed at Sat Oct 21 16:08:13 2023

/dev/rdisk8s2: Checking the checkpoint with transaction ID 374573.
/dev/rdisk8s2: ** Checking the object map.
/dev/rdisk8s2: ** Checking volume /dev/rdisk8s2.
/dev/rdisk8s2: ** Checking the APFS volume superblock.
/dev/rdisk8s2: The volume TimeMachine New 4TB was formatted by diskmanagementd (2142.81.1) and last modified by apfs_kext (2235.0.13).
/dev/rdisk8s2: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk8s2: fsck_apfs completed at Sat Oct 21 16:08:13 2023


/dev/rdisk13s1: fsck_apfs started at Sat Oct 21 16:08:17 2023
/dev/rdisk13s1: ** Checking the container superblock.
/dev/rdisk13s1: Checking the checkpoint with transaction ID 6260.
/dev/rdisk13s1: ** Checking the object map.
/dev/rdisk13s1: ** Checking volume /dev/rdisk13s1.
/dev/rdisk13s1: ** Checking the APFS volume superblock.
/dev/rdisk13s1: The volume Iron Wolf 8TB was formatted by diskmanagementd (2142.140.9) and last modified by apfs_kext (2235.0.13).
/dev/rdisk13s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk13s1: fsck_apfs completed at Sat Oct 21 16:08:17 2023


/dev/rdisk15s1: fsck_apfs started at Sat Oct 21 16:08:17 2023
/dev/rdisk15s1: ** Checking the container superblock.
/dev/rdisk15s1: Checking the checkpoint with transaction ID 88840.
/dev/rdisk15s1: ** Checking the object map.
/dev/rdisk15s1: ** Checking volume /dev/rdisk15s1.
/dev/rdisk15s1: ** Checking the APFS volume superblock.
/dev/rdisk15s1: The volume OWC Merc RAID5 was formatted by newfs_apfs (2142.140.9) and last modified by apfs_kext (2235.0.13).
/dev/rdisk15s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk15s1: fsck_apfs completed at Sat Oct 21 16:08:17 2023




/dev/rdisk2s1: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s1: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s1: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s1: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s1: fsck_apfs completed at Sat Oct 21 16:18:19 2023

/dev/rdisk3s1: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s1: fsck_apfs completed at Sat Oct 21 16:18:19 2023

/dev/rdisk2s1: ** Checking the container superblock.
/dev/rdisk2s1: Checking the checkpoint with transaction ID 124.
/dev/rdisk2s1: ** Checking the object map.
/dev/rdisk2s1: ** Checking volume /dev/rdisk2s1.
/dev/rdisk2s1: ** Checking the APFS volume superblock.
/dev/rdisk2s1: The volume Recovery was formatted by newfs_apfs (1934.101.3) and last modified by apfs_kext (2142.140.9).
/dev/rdisk2s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk2s1: fsck_apfs completed at Sat Oct 21 16:18:19 2023



/dev/rdisk2s2: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s2: fsck_apfs started at Sat Oct 21 16:18:19 2023

/dev/rdisk3s4: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s2: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s2: fsck_apfs completed at Sat Oct 21 16:18:19 2023

/dev/rdisk3s4: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s4: fsck_apfs completed at Sat Oct 21 16:18:19 2023

/dev/rdisk2s2: ** Checking the container superblock.
/dev/rdisk2s2: Checking the checkpoint with transaction ID 124.
/dev/rdisk2s2: ** Checking the object map.
/dev/rdisk2s2: ** Checking volume /dev/rdisk2s2.
/dev/rdisk2s2: ** Checking the APFS volume superblock.
/dev/rdisk2s2: The volume Update was formatted by com.apple.MobileSo (1934.101.3) and last modified by apfs_kext (2142.140.9).
/dev/rdisk2s2: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk2s2: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk1s3: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s3: error: container /dev/rdisk1 is mounted with write access; please re-run with -l.
/dev/rdisk1s3: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk3s3: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s3: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s3: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk1s4: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk1s4: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk1s4: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk3s2: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s2: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s2: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk3s5: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s5: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s5: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk3s6: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s6: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s6: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk3s3s1: fsck_apfs started at Sat Oct 21 16:18:19 2023
/dev/rdisk3s3s1: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk3s3s1: fsck_apfs completed at Sat Oct 21 16:18:19 2023


/dev/rdisk5s2: fsck_apfs started at Sat Oct 21 16:18:24 2023
/dev/rdisk5s2: ** Checking the container superblock.
/dev/rdisk5s2: Checking the checkpoint with transaction ID 72757.
/dev/rdisk5s2: ** Checking the object map.
/dev/rdisk5s2: ** Checking volume /dev/rdisk5s2.
/dev/rdisk5s2: ** Checking the APFS volume superblock.
/dev/rdisk5s2: The volume T7 Shield was formatted by diskmanagementd (2142.120.7) and last modified by apfs_kext (2235.0.13).
/dev/rdisk5s2: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk5s2: fsck_apfs completed at Sat Oct 21 16:18:24 2023


Und zur Ergänzung noch die Datei /var/log/fsck_apfs_error.log für den gleichen Zeitraum:

dev= uuid=BD939F23-148B-4EDA-8E8D-B1B661A8C805 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Thu Oct 19 09:59:42 2023
dev= uuid=A5B2B409-C097-48D8-972C-EA9EAE4B99A2 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Thu Oct 19 09:59:46 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Fri Oct 20 06:10:33 2023
dev=/dev/rdisk3 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:58 2023
dev=/dev/rdisk1 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:58 2023
dev= uuid=DA3F27BC-8AF6-4C96-B997-0C5D934B8704 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:58 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev=/dev/rdisk1 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev= uuid=DA3F27BC-8AF6-4C96-B997-0C5D934B8704 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev=/dev/rdisk1 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev=/dev/rdisk3 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev=/dev/rdisk3 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev=/dev/rdisk3 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:07:59 2023
dev= uuid=61A5EA3D-FE72-40E5-B8C1-4EA145F22668 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:08:03 2023
dev= uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=1 iter=1
fsck_apfs completed at Sat Oct 21 16:08:06 2023
dev= uuid=8955650F-1D67-4DD4-B3FE-50953FE01B0F vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:08:13 2023
dev= uuid=841D7A2E-826C-4DA4-B65B-4BC546303113 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:08:13 2023
dev= uuid=BD939F23-148B-4EDA-8E8D-B1B661A8C805 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:08:17 2023
dev= uuid=A5B2B409-C097-48D8-972C-EA9EAE4B99A2 vers=2235.0.13 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:08:17 2023
dev=/dev/rdisk1 uuid=00000000-0000-0000-0000-000000000000 vers=2235.0.13 default_ans=n result=65 fp=2 fl=156 repairs=0 time=0 iter=1
fsck_apfs completed at Sat Oct 21 16:18:19 2023

Da ist nirgendwo ein Problem zu erkennen. Zwischen 20.10. 06:10 Uhr und 21.10. 16:07 gibt es allerdings keine Daten.

Danke! – Wie ich schon befürchtet hatte.
Worauf weisen die fehlenden Einträge zwischen den beiden Zeitpunkten hin? Werden Einträge in reglemäßigen Zeitabständen vorgenommen oder nur, wenn etwas "passiert"? Anders ausgedrückt: Weist das auf einen ereignislosen Verlauf hin oder darauf, dass irgendetwas Einträge verhindert hat? Mein Rechner lief in dieser Zeit durch, wenn er nicht gerade crashte.