Never Touch a Running System?

Judith Petasch

Alles war so schön, bis wir der Meinung waren, das 6 Monate auf dem Markt befindliche Upgrade auf OS Sierra durchzuführen.

Seither laufen wir Spießruten! Als Einstieg mußte das Raid System über einen kryptischen -sudo- Befehl zum Starten gebracht werden. Als es zu unserer Freude wieder startete, war der Labordatenübertrag unmöglich, da das Script in der bisherigen Form von Apple nicht mehr unterstützt wird. Einige Tage später wurde ein entsprechendes neues Script vom Support editiert und im Gespräch festgestellt, dass die Praxismitarbeiter in der Vergangenheit die übertragenen Laborbefunde nicht ordnungsgemäß bestätigt hatten. So lagen die Labordaten also unbestätigt im mittlerweile überfrachteten Labormodul. Eine Mitarbeiterin wurde damit beauftragt, die lange Liste abzuarbeiten. Sie fand aber heraus, dass man alle Listeneinträge markieren und über den Löschen Button mit einem Wisch entfernen kann … Als nun keine Labordaten mehr verfügbar waren, ergab mein Anruf beim Support, dass man das Laborarchiv ohne Weiteres wieder in den Laboreingang kopieren kann. Da waren sie nun wieder da und die "schuldige" Mitarbeiterin begann anschließend mit der Zuordnung von ca. 5000 Laborbefunden. Dann aber stimmte eigentlich nichts mehr. Herr Dr. Berg bemühte sich nun am Freitag das Chaos zu beseitigen, was Ihm auch gelang. Super!

Aber nun ist von dem empfohlenen Pegasus RAID eine Platte defekt, dass war wahrscheinlich zu viel Traffic in den letzten 14 Tagen.

Immer noch guter Dinge haben wir heute Nachmittag eine Ersatzplatte besorgt. Gleicher Hersteller, gleicher Typ, aber der Raid-Gedanke, austauschen und warten bis sich alles repariert hat, scheint aufgrund des ausgelagerten Betriebssystems nicht zu funktionieren.

Stinksauer!!!!

Wir arbeiten papierlos und müssen uns folglich auf die Technik zu 100% verlassen können. Im Zeitalter von immer abenteuerlicheren Hackerangriffen sollte man auch sein Betriebsystem auf dem aktuellen Stand halten. Offensichtlich wird seitens Apple eine Gefahr im ausgelagerten Betriebssystem und bei gewissen Scripts gesehen. Wir haben diese Sperre nun mit einem kleinen Befehlen umgangen? Es stellt sich auch die Frage, ob Softwareentwickler, wie die von TOMEDO, nicht die nötigen Informationen zur zukünftigen Strategie der Entwicklung des Betriebssystems erhalten und sie dann die Möglichkeit haben, diese zeitnah einzupflegen. Und zum Thema Löschen von Karteieinträgen stelle ich mir spätesten seit vorletzter Woche die Frage, wie es sein kann, das eine Mitarbeiterin ohne Adminrechte die Möglichkeit haben kann, die gesamte Labordatenbank zu schrotten???

Selbst für versierte Nutzer ist das System in der momentanen Konfiguration mit dem ausgelagerten Betriebsystem nicht ohne tiefgreifendes Wissen beherrschbar. Eine Wiederherstellung ist bei Halbwissen mit riesigen Gefahren verbunden. Wir werden also bis Montag schmoren, um vom Support entsprechende Anweisungen zu erhalten, wie die neue Platte zu beleben ist. Wie ich heute hier im Forum las, ist seit über einem Jahr bekannt, dass die Platten reihenweise abschmieren. Warum gibt es da nicht wenigstens ein entsprechendes Todo für die Einbindung einer neuen Platte?

In der Folge wird Montag wiederum kein Praxisbetrieb möglich sein, da sich der Wiederherstellungsmodus über viele Stunden hinziehen wird. Das ist für die Zukunft kein gangbarer Weg.

Johannes Zollmann

Liebe Frau Dr. Petasch,

aufgrund der Dringlichkeit hatte ich Ihnen hierzu schon direkt eine Mail geschrieben. Ich fasse die wichtigstens Punkte darauf hier noch mal (für die anderen Anwender) zusammen:

Wenn ich das richtig verstehe ist eine der vier Festplatten kaputt und auch nach einem Austausch der Platte läuft das Raid nicht mehr? Normalerweise läuft bei einem Festplattenausfall das Raid und somit das ganze System „einfach weiter“ und die Platte leuchtet rot (so dass man die dann austauschen kann). Nach unserer Erfahrung funktioniert das auch bei den Promise Raids so (zumindest bei den größeren R4s): Festplattenausfälle sind ein „relativ typischer“ Supportfall, der aber selten bis zu uns kommt, da die jeweiligen Praxenbetreuer die Platten meistens „einfach austauschen“. In unseren beiden Betapraxen in Jena sind bislang 3 mal Platten ausgefallen (was in etwa der durchschnittlichen Lebenserwartung entspricht), in allen Fällen ist das System jedoch normal weitergelaufen und die Platten konnten im laufenden Betrieb getauscht werden.

Wie Sie selbst schreiben haben aber bereits andere Ärzte berichtet (in allen Fällen war das kleinere M4 im Einsatz, wie bei Ihnen auch), das dort nach einem Festplattenausfall das Raid gestoppt war und manuell wieder aktiviert werden musste. Normalerweise erfolgt das einfach indem man das Programm „Promise Utilities“ startet und dort den Einsatz der Platte bestätigt bzw. quittiert. Ich habe mal die entsprechenden Supportprotokolle bei uns durchforstet, aber nur einen Fall gefunden in dem das mit dem Quittieren scheinbar nicht so einfach ging, den entsprechenden Bericht kopiere ich (aufgrund des 8000-Buchstaben-Limits hier im Forum) in eine separate Antwort.

Es tut mir aufrichtig leid, dass sich die Probleme bei Ihnen so häufen. Bzgl. des Löschens der Laborbefunde haben wir bereits ein Meeting angesetzt, in dem wir besprechen wie wir einen Fall wie bei Ihnen zukünftig verhindern können. Das ist nicht ganz trivial, denn leider können wir das Löschen nicht einfach „verbieten“ oder einschränken, da es ein sehr typischer Fall ist, dass MFAs Befunde wieder löschen (z.B. wenn diese doppelt eingelesen wurden) und uns somit viele Ihrer Kollegen aufs Dach steigen würden. Ich denke aber, dass wir hier eine Lösung finden werden. Bzgl. der Problematik mit dem M4 hatten wir Promise bereits mehrfach um eine Stellungnahme gebeten, bislang aber immer mit dem unbefriedigenden Ergebnis, dass das Problem nicht nachvollziehbar wäre und das M4 in allen Belangen mit dem R4 übereinstimme (ich hatte dazu auch schon mal was in unserem Forum geschrieben, nachdem Dr. Odenthal ein ähnliches Problem berichtet hatte: /d/4166 ).

Wichtig ist jetzt erst mal, dass wir Ihren Server wieder zum laufen bringen, lassen Sie uns wie ich Ihnen per Mail geschrieben habe dazu telefonieren.

Johannes Zollmann

Bericht zum Umgang mit Plattenausfall beim Promise M4:

------------------------------------------------------------------------------------

Ausgangssituation:

* tomedo läuft nicht

* tomedo Server startet nicht bzw. nach Anschalten des Mac Mini läuft der Startbalken bis ca. 1/3 durch, danach passiert nichts mehr

-> Thunderbolt-Kabel des Raids getrennt, Mac Mini neugestartet (in der Hoffnung, daß dieser von der internen Platte startet)

* Mac Mini läuft, Teamviewer-Verbindung besteht

-> TB-Kabel wieder verbinden

* Raid-Volume wird nicht automatisch gemountet, Promise-Utilities finden nichts

-> TB-Kabel trennen, Strom-Kabel (vom Raid...) trennen, 10 Sek warten, Strom-Kabel verbinden, TB-Kabel verbinden

* Raid ist immer noch nicht da, aus dem system.log erfährt man:

Feb 25 08:21:59 Servers-Mac-mini kernel[0]: STEX : PromiseSTEX loaded up...

Feb 25 08:22:02 Servers-Mac-mini kernel[0]: STEX : Init controller event and source

Feb 25 08:22:05 Servers-Mac-mini kernel[0]: STEX : Physical address : 0x100800000

Feb 25 08:22:05 Servers-Mac-mini kernel[0]: STEX : BAR0 length : 400000 bytes

Feb 25 08:22:05 Servers-Mac-mini kernel[0]: STEX : Get the virtual address : 18dfc000

Feb 25 08:22:05 Servers-Mac-mini kernel[0]: STEX : Machine Model : Macmini7,1

Feb 25 08:22:09 Servers-Mac-mini kernel[0]: STEX : PowerState registered

Feb 25 08:22:09 Servers-Mac-mini kernel[0]: STEX : setPowerState : 2, (0 = sleep , 1 = pause, 2 = wake)

Feb 25 08:22:09 Servers-Mac-mini kernel[0]: STEX : Power on device

Feb 25 08:22:09 Servers-Mac-mini kernel[0]: STEX : setPowerState done

Feb 25 08:22:10 Servers-Mac-mini kernel[0]: STEX : fw is READY to do handshake

Feb 25 08:22:10 Servers-Mac-mini kernel[0]: STEX : Sending Host Model Name : Macmini7,1

Feb 25 08:22:10 Servers-Mac-mini kernel[0]: STEX : Sending Host Build Version : 14D136

Feb 25 08:22:10 Servers-Mac-mini kernel[0]: STEX : scatch Data = 0

Feb 25 08:22:51 Servers-Mac-mini kernel[0]: STEX : RE-SEND Handshake frame to FW ...

Feb 25 08:23:11 --- last message repeated 2 times ---

Feb 25 08:23:11 Servers-Mac-mini kernel[0]: STEX : Handshake failed, Device#1

-> handshake failed !!!, d.h. das Raid war nicht in der Lage, eine Verbindung aufzubauen

* nochmal: TB-Kabel ab, Strom-Kabel an, 10 Sek warten, Strom-Kabel an, TB-Kabel an

Feb 25 08:25:47 Servers-Mac-mini kernel[0]: STEX : PromiseSTEX loaded up...

Feb 25 08:25:50 Servers-Mac-mini kernel[0]: STEX : Init controller event and source

Feb 25 08:25:53 Servers-Mac-mini kernel[0]: STEX : Physical address : 0x100c00000

Feb 25 08:25:53 Servers-Mac-mini kernel[0]: STEX : BAR0 length : 400000 bytes

Feb 25 08:25:53 Servers-Mac-mini kernel[0]: STEX : Get the virtual address : 194fe000

Feb 25 08:25:53 Servers-Mac-mini kernel[0]: STEX : Machine Model : Macmini7,1

Feb 25 08:25:57 Servers-Mac-mini kernel[0]: STEX : PowerState registered

Feb 25 08:25:57 Servers-Mac-mini kernel[0]: STEX : setPowerState : 2, (0 = sleep , 1 = pause, 2 = wake)

Feb 25 08:25:57 Servers-Mac-mini kernel[0]: STEX : Power on device

Feb 25 08:25:57 Servers-Mac-mini kernel[0]: STEX : setPowerState done

Feb 25 08:25:58 Servers-Mac-mini kernel[0]: STEX : fw is READY to do handshake

Feb 25 08:25:58 Servers-Mac-mini kernel[0]: STEX : Sending Host Model Name : Macmini7,1

Feb 25 08:25:58 Servers-Mac-mini kernel[0]: STEX : Sending Host Build Version : 14D136

Feb 25 08:25:59 Servers-Mac-mini kernel[0]: STEX : scatch Data = 0

Feb 25 08:26:09 Servers-Mac-mini kernel[0]: STEX : RE-SEND Handshake frame to FW ...

Feb 25 08:26:32 --- last message repeated 2 times ---

Feb 25 08:26:32 Servers-Mac-mini kernel[0]: STEX : handshake with FW successfully, Device#1

-> handshake successful !!!, d.h. das Raid ist da

* Promise-Utilities starten, Eventlog lesen

-> bad sector Fehler auf FP #2 -> Vermutung: FP #2 ist im A... defekt

* beim Versuch, das smart-log der Festplatte #2 auszulesen, hängt sich das Promise-Utility auf, das Raid stürzt wieder ab

-> TB-Kabel ab, Strom-Kabel ab, MFA erklärt, daß sie FP #2 aus dem Raid entfernen muss, Strom-Kabel an, TB-Kabel an

* Promise-Utilities starten, bestätigen, daß das Raid trotz fehlender Platte verwendet werden soll (Dialog wird automatisch angezeigt), Server vom Raid neustarten

-> nach 30 Min Arbeit läuft die Praxis wieder

------------------------------------------------------------------------------------

Judith Petasch

Festplatte 2 scheint gern im A... zu sein. Habe es nach der Beschreibung nun doch gewagt im Promise Utillities die entsprechenden "CONFIRM" zu geben. Die Hinweise habe ich dann mal ausgeblendet... Und das Raid wurde sofort wieder angezeigt. Nach dem Boot kommt nun zumindest mal der bekannte Bildschirmschoner und alle Platten befinden sich in regem Betrieb. Ich hoffe mal das dies der Recoverstatus für die getauschte Platte ist, denn ich kann derzeit nicht den Bildschirmschoner beenden.

Danke für den nächtlichen Wochenendsupport!

Judith Petasch

Server ist wieder bereit und hoffentlich läuft jetzt wieder alles in bewährter zuverlässigkeit. Ich werde meinen Frust Promis antragen und eine Wandlung fordern. Vielleicht sollten sich die die TOMEDO Kunden auch gemeinschaftlich gegen diesen Mangel wehren. Eine Festplatte geht in aller Regel nicht nach 1,5 Jahren kaputt. und das Raid ist ja dafür da ausfälle zu vermeiden. Kann doch nicht sein, das es einfach ausfällt! Das Pegasus 2M4 scheint einfach mangelbehaftet zu sein. Die Option SSD würde weniger wärme erzeugen und noch ettwas schnellere zugrifszeiten erlauben, was spricht dagegen? Die Postmortalen wiederherstellungsmöglichkeiten von herkömmlichen Festplatten?

[gelöscht]

SSD Laufwerke sind in der Anzahl der Schreib/Lesezugriffe begrenzt, soweit ich weiss und der Flaschenhals am Server ist die Netzwerkverbindung und beim Thunderbolt die Zugriffe auf viele kleine Dateien. Sie würden durch SSD Platten keine Unterschied am Client merken.

Wolfgang Krause

Sehr geehrte Fr. Kollegin Dr. Petasch,

auch meine Praxis war vom OS Sierra-Update Crash betroffen (wir verwenden für unsere kleine Praxis ein USB3 RAID) und in der Folgezeit kam es zu einer Vielzahl von Ausfälle/Rettungsversuchen, die von einer wahren Kette von Fehlern verursacht wurden (u.a. fehlendes Backup wg Diagnosearbeiten am Server, Rechner/Programmabstürze wegen eines RAID-Doppelfehlers (1 FP defekt (in Garaniezeit!!), gleichzeitig Fehler im RAID). Das neu gelieferte USB-RAID hat eine andere Bedienungsroutine, so daß ich leider mehrfach versehtlich die falsche Platte überschrieben/gesichert hatte.

Wir mussten also mehrfach die Support-Hotline in Anspruch nehmen, die mir bei der Datenrettung (sofern jeweils möglich) kompetent geholfen hat. Vielen Dank nach Jena!

Zur Zeit laufen wir immer noch "auf Reserve", d.h. mit 1 FP als Startlaufwerk und häufigen Sicherheitsbackups. Ich hoffe, daß wir das im Laufe der nächsten Woche mithilfe des hiesigen Technikers wieder in geordnete Bahnen bekommen.

nähere Details werde ich Beitrag: Gibts eine günstige Alternative zum Thunderbolt-RAID v.a. für kleinere Praxen? einstellen, sobald wieder alles stabil läuft.

Gerald Freier

Ich hatte ebenfalls bereits Probleme mit dem M4. Zum Glück habe ich die defekte Platte (nach nur 14 Monaten Laufzeit) nicht im Praxisbetrieb gewechselt, sondern danach: Das Mounten hat ca. 8 Stunden gedauert... In dieser Zeit war der Zugriff auf den Server nicht möglich.

Meiner Kenntnis nach sind die Hitachi-Platten, die bei mir mit dabei waren, aber auch nicht die besten, sagte mir ein verwandter EDV-Fachmann.

Ich habe trotzdem 2-3 Platten nachgekauft und im Schrank liegen. Wer weiss, wann es die nicht mehr gibt und ob sich unterschiedliche Platten im selben RAID vertragen. Und was wäre, wenn mal 2 gleichzeitig aussteigen? Will ich nicht dran denken...

Mein Großhändler ("okluge" über Amazon.de) hatte den Festplattenersatz für die defekte Platte mehrfach abgelehnt, bzw. gefordert, dass ich das ganze RAID zurückschicken müsse, was ja aber nicht geht und auch nicht Sinn eines RAID ist. Ich habe dann den email-Verkehr irgendwann zu ihm entnervt eingestellt. Ich kann ihn aber daher auch nicht mehr empfehlen.

Problematisch finde ich bei Mac und Co., dass es kaum fähige Netzwerk- und IT-Experten gibt, die man, wie bei Windows PC's, in die Praxis kommen lassen kann, damit jeder Rechner auch mal auf Datensicherheit und optimale Konfiguration überprüft wird, bzw. ein regelmässiger Hardwarewechsel erfolgt. Sowas wäre mir das Geld wert. Und das ist ja eigentlich auch nicht die Aufgabe von Zollsoft. Und ich bin eben auch nur ein "Learning by doing" und "trial and error"-Halbfachmann. Das würden wir in der Medizin so nie akzeptieren. Ich vermute, so geht es vielen von uns Tomedo-Nutzern.

[gelöscht]

Ich habe Pegasus, Thunderbolt und RAID aus der Gleichung genommen und fühle mich sehr gut damit.

Johannes Zollmann

Lieber Dr. Freier,

wenn Sie einen IT-Experten in Ihrer Nähe suchen, könnten Sie sich mal an unseren Partner Herrn Nebe von maccc wenden: http://www.maccc.de

Die Firma betreut seit vielen Jahren Arztpraxen in IT- und Netzwerkfragen, darunter auch seit drei Jahren verschiedene tomedo-Praxen in Ihrer Umgebung. Sie kennt somit tomedo "von Anfang an" und ich habe bislang nur positives Feedback über die Arbeit von maccc bekommen.

Viele Grüße

Johannes Zollmann

Andreas Cepin

maccc sollte vielleicht noch tomedo auf seine Link-Liste setzen ;-)