neue Servertools. Fehler beim Update

Question

Liebe Entwickler!

Immer wieder tritt der folgende Fehler beim updaten auf. Ich finde das sehr lästig und wüsste gerne wie man das vermeiden kann. Das externe Back-up Laufwerk ist ordentlich im System angemeldet und wird auf dem Schreibtisch dargestellt.

 

Comments

.... versuchen Sie einmal den Pfad für das Ziel in der Backupeinrichtung in den Servertools neu auszuwählen, meistens ist der fehlenden korrekte mount auch im Zusammenhang mit dem selbstständigem Ein- und Aushängen das Problem,

---

Bei mir seit September das gleiche Problem. Normale backups laufen ohne Störung. Nur beim updates hängt der server wie oben beschrieben. Der support kennt das Problem seit September.

---

hatte bis vor kurzem ein ähnliches Problem. Mit dem Support sind wir drauf gekommen, dass das Volume aus irgendeinem OS-seitigen Grund beim abstecken als "Geistervolume" in der Mount Liste verblieben ist und dann beim nächsten Anstecken mit einer neuen Bezeichnung gemounted wurde (aus .../tomedo_backup wurde ../tomedo_backup 1). Abhilfe brachte - ganz einfach - den Server einmal richtig runterzufahren und wieder raufzufahren. Sicher nicht das genau gleiche Problem, aber vielleicht probieren Sie das mal.

---

Hallo Herr Handwerker!

Es könnte genau das sein was sie oben beschreiben. Hin und wieder kommt macOS beim an und abstecken verschiedener Laufwerke in der Tat mal durcheinander, und dann werden bestimmte Laufwerke gar nicht richtig gemountet. Das hängt möglicherweise auch von dem externen Laufwerk selber ab, Ich habe das Problem mit einer bestimmten externen SSD ganz ausgeprägt. Die wird aber im täglichen Betrieb gar nicht benutzt.

Möglicherweise Ist das Ganze also gar kein Tomedo Problem sondern ein macOS Fehler ...

Answer 1

Das Problem haben wir auch, die Tools erkennen den Typ des Laufwerks (Netz, extern/USB) oder die Verfügbarkeit nicht mehr und dann wird nicht mehr gemounted oder synchronisiert.

Abhilfe bringt der Automounter aus dem App-Store für 9.95, der auf dem Server zu installieren ist. Das Teil funktioniert auch nach Stromausfall und Neustart.

Gruß aus Lippstadt vom Arztgatten, RA J. Frotscher

Comments

Ahh guter Tip, Herr Frotscher!

Den Automounter habe ich hier seit längerer Zeit im Einsatz. Aber für diesen Zweck .... darauf bin ich nicht gekommen!

Wird sofort eingerichtet!

 

PS: Der Auto-Mounter reagiert nicht auf die USB-Festplatte. Damit komme ich nicht weiter. ?!

---

Hatte das Problem gerade auch und habe automatisches Einhängen und Auswerfen passager deaktiviert, dann ging es

---

Die Automatik habe ich standardmäßig deaktiviert weil die Tools mit der verschlüsselten externen Festplatte nicht zurecht kommen beim automatischen einhängen und aushängen ...

---

Hatte ich auch, als bei uns die neuen Server-Tools installiert wurden , hab dann die Platten nochmal neu formatiert (APFS verschlüsselt) und neu die Backups aufgespielt, seitdem funktionieren sie problemlos.

---

Japp, hier genauso ... (also APFS wgen BigSur und CCC)

Answer 2

Sehr geehrter Hr. Dr. Cepin,

ich habe mir ihre Logdaten einmal genauer angechaut und komme zu folgendem Schluss.

Zum Zeitpunkt, als das Update durchgeführt wurde (und der Platz für das Backup berechnet wird) war ein "Volume" unter dem angegeben Pfad "nicht sauber" sichtbar (/Volumes/TglBackup_Daten).

Aufällig in den Log Daten ist die Stelle bei der wir ausrechnen, wieviel Platz auf dem Volume frei sein muss

Bei Ihnen stand im Log:

-> Benötige 35.951 GB für Synchronisierung unter /Volumes/TglBackup_Daten/tomedo_backup

Das weicht enorm von den Werten ab, die sonst bei einem "normalen" Backup stehen

-> Benötige 0.695 GB für Synchronisierung unter /Volumes/TglBackup_Daten/tomedo_backup

Dafür gibt es zwei Erklärungen : 

1. das Volume war nicht das Volume was sonst immer gesteckt war und die Zugriffsrechte waren nicht ausreichend gesetzt

2. das Volume war zwar gesteckt, aber aktuell "nicht sichtbar" für den Tomedo-Server

Ich tendiere zu Erklärung 2, jedoch werde ich aufgrund der Runtime Exception, die nachträglich aufgetreten ist (welche die Fehlermeldung in den Servertools produziert) im Code eine weitere Auschrift vorsehen, damit in Zukunft die Ursache eingegrenzt werden kann. 

--

Das "Volume" ist prinzipiell (zumindest an anderen Stellen im Log) korrekt angebunden, d.h. sie können erst einmal gar nichts weiter unternehmen.

-> Check isVolumeMountedByDeviceAndMountPath : /dev/... / /Volumes/TglBackup_Daten -> true

--

Den Fehler den sie beschreiben kann ich nur nachstellen, wenn das "Volume" auf dem gechrieben werden soll tatsächlich nicht "ge-mounted" / "sichtbar"  ist.

 

Im Bild unten sehen sie einmal einen Screen-Shot, in dem Pop-Over am "primären Backup" kann man evtl. schon ableiten, dass das Volume "nicht sichtbar" ist. Der Fehler der dann auftritt entspricht genau dem oben gemeldeten.

--

Solten sie mehrere "ausser Haus" Backups konfiguriert haben, und beim nächsten Update dieser Fehler bei einem der "ausser Haus Updtes" auftreten - so kann man diese "kurzzeitig" deaktivieren.

Das "primäre Baclup" läßt sich im Notfall auch deaktivieren, davon rate ich i.d.R. ab. 

 

Mit freundlichen Grüßen

Andreas Reinhardt

Comments

Hmm, Vielen Dank für die Analyse, lässt mich allerdings trotzdem etwas ratlos zurück. Also erst mal das nächste Back-up Update abwarten und auf eine eventuelle Fehlermeldung warten.

'Außer Haus' ist etwas irreführend, es ist ja lediglich eine externe Festplatte bzw ein NAS-Laufwerk als sekundäres Backup konfiguriert.

---

der o.g. Fehler ist bei einem "Update" aufgetreten -> das beinhaltet i.d.R. ein Backup.

insofern haben sie recht, dass das nächste "automatische" Backup prinzipiell abzuwarten ist. Wenn das "durchläuft" ist davon auszugehen, dass beim nächsten Update dieses ebenso der Fall ist.

zu "ausser Haus":

das ist der Begriff der hier "intern" verwendet wird für die "zusätzlichen" Backups. Hier ist auch empfohlen, dass mindestens eines der Backups physisch an einem anderen Ort aufbewahrt wird.