Mephistopheles

Joa: Aber das hat bisher nie gestört - und er sagt ja schon beim Connecten, dass das Volume die notwendige Funktionalität nicht hätte. Also - einfach schon wieder der gleiche Fehler. Und die Lösung wird wieder mal sein, das Backup komplett zu löschen und neu zu erstellen. Was ja so absolut nicht der Sinn eines Backups ist. Ich denke, ich werde wieder auf externe SSD und Kabel wechseln. Kann ja nicht sein, dass das Backup halbjährlich einfach kaputt geht.

Es ist wieder passiert. Relativ zuverlässig nachdem ich das letzte "große" Update auf Unraid 7 gemacht habe. Also: Mit jedem "größeren" Versionsupdate scheint einfach das TimeMachine-Backup kaputt zu gehen. 😐

Cool, Danke für die Tipps. 🙂 Ich hab' das direkt mal angepasst. Mal sehen, ob das besser läuft.

Naja, bei mir sieht das so aus: Vorher war das auch schon so - allerdings kann ich das für den Fehlerfall ja nicht mehr sagen, weil TimeMachine ja nicht mehr darauf zugreifen konnte. 🤷‍♂️

Da steht nichts auffällig drin. Ich habe es jetzt (wieder mal) gelöst, in dem ich das Share gelöscht und ein neues erstellt habe. Aber das kann ja keine Lösung sind, jetzt alle anderthalb Monate das Backup zu löschen und neu zu machen. 😯

Tach zusammen - ich schon wieder. Also: Ich habe mich jetzt an die Anleitungen gehalten, habe ein neues Share aufgesetzt, dass dann auch nur auf einer einzigen Platte läuft, alles brav konfiguriert - und das geht auch tatsächlich. Jetzt seit anderthalb Monaten. Bis heute Morgen. Ich habe keine Ahnung was das soll, aber ich stoße derweil ein paar farbenfrohe Flüche aus und stecke dann lieber immer mal wieder eine SSD an den Mac. Lässt sich irgendwie rausfinden, warum von einem Tag auf den anderen "Das Backup-Volume im Netzwerk die notwendigen Funktionalitäten" nicht mehr unterstützt? Ich meine: Das kann doch nicht sein? Es macht alles, was es machen soll - und Zack, unterstützt es die Funktionalität nicht mehr? Warum denn? Ging doch? Und dann nicht mehr? Ich glaube, Unraid verarscht mich... 😯

Mhm. Ok. Ich versuche mal die Daten via Unbalanced auf einer Platte zusammen zu schieben. Mal sehen, ob das klappt.

Das Sparsebundle war und ist über mehrere Platten verteilt. Mhm. Also könnte es ein, dass es plötzlich die "Plattengrenze" überschritten hat und damit dann ein Problem hat? Ich könnte jetzt also mal probieren das Share auf eine Platte zu beschränken, den Mover laufen zu lassen und es dann noch mal zu probieren, zum Share zu connecten?

Neues Update (ich gebe ja so schnell nicht auf): Mein neues Share war einfach "zu groß" und konnte deshalb nicht erstellt werden. Ok. Soweit so gut. In diesem neuen Share kann er dann auch wieder connecten und Backups machen. Bleibt die Frage: Warum kann er das bei dem alten Share nicht mehr? Und wie bringe ich ihn dazu, das wieder zu benutzen? 🤔

Ich habe jetzt auch schon mal verschiedene Dinge probiert. TimeMachine gestoppt, neu gestartet - kein Effekt. Server neu gestartet - kein Effekt. Versucht beim Share einmal TimeMachine Support auszuschalten und wieder an - kein Effekt. Versucht einen neuen Share zu erstellen - es wird einfach kein neuer Share erstellt. (Auch wenn ich Docker und VM abschalte nicht...)

Moin zusammen, von einem Moment auf den anderen schlägt das TimeMachine-Backup fehl. Da es jetzt monatelang problemlos lief, frage ich mich, was das jetzt plötzlich soll. Gibt's eine Möglichkeit, irgendwo in einem Log nachzulesen, warum plötzlich keine Verbindung mehr hergestellt werden kann?

Ha! Yay! Danke! 🙂 Das funktioniert. 🙂

Moin zusammen, ich habe da ein interessantes Phänomen: Auf meinem Server gibt es einige Ordner mit sehr vielen RAW-Fotos. Wenn ich versuche die auf dem Mac zu öffnen (mein Haupt-Computer), dann lädt der einfach unendlich lang und stürzt dann schlicht ab. Öffne ich die Ordner unter Windows (die uralte Zweit-Maschine, die eigentlich aussortiert gehört), braucht der Explorer da zwar länger, um die Ordner zu laden, öffnet aber alles fehlerfrei. Ich hatte schon Sorge, dass die Dateien irgendwie korrupt sein könnten - aber nein, es scheint tatsächlich so ein spezielles Mac-Problem zu sein. Habt ihr eine Idee, woran das liegen könnte? 🤔

Also die mcvlan-Call-Traces konnte ich beheben. Ich hab' mich einfach noch mal getraut auf ipvlan umzustellen und diesmal hat's keinen katatrophalen Fehler ergeben wie beim letzten Versuch. 😯 Jetzt muss ich nur noch rausfinden, warum ein Array-Spin-Down zum Absturz führt.

Es fühlt sich für mich auch an wie "geht nicht". 😁 Ich bin ja ein Freund von "Fehlermeldung - aha - kann ich beheben." Bisher war das immer so ein Fall von "Fehlermeldung - versuch ich zu beheben und mache dabei alles nur noch viel schlimmer." So wie diese Maclavan-Traces. Hab' ich mal versucht nach dem, was ich so im Netz gefunden habe zu beheben. Danach hatte ich keinen Zugriff mehr auf irgendwas, hab's wieder zurück gedreht und einfach wieder die Finger davon gelassen, weil ich Angst hab, nur noch mehr kaputt zu machen, wovon ich dann wieder keine Ahnung habe. 😯 Da sind auch "machine check errors". Aber die gab's eigentlich schon von Anfang an und nachdem was ich so gelesen habe (oder: Was ich in den letzten Jahren so dazu finden konnte), lassen die sich ignorieren. Lief ja jetzt auch so seine drei, vier Jahre ohne großes Murren. Das fing erst letzten Juli an - da hab' ich die Dose dann erstmal in die Ecke gestellt und liegen lassen. Jetzt hab' ich mal Zeit mich darum zu kümmern, finde aber keine für Normalsterbliche verständliche "Du hast das hier falsch gemacht, also machst du jetzt dies-und-jenes richtig und dann läuft alles"-Fehlermeldung. 😐 Ich bin da zugegebenermaßen ein ziemlicher Linux-Noob mit geringer Frustrationstoleranz. Aber ich hab' mal die Diagnostics angehangen. angrynerds-diagnostics-20240120-1700.zip