Arbeitsstation als Ersatzserver

[FFSephiroth]

Hallo zusammen,
ich habe folgende Frage:

Ist es möglich, eine Turbomed-Arbeitsstation so zu konfiguriren, dass diese als Notfallserver genutzt werden kann?
Quasi, falls der eigentliche Server aufgrund von Problemen ausfallen sollte. Zweck ist, den Praxisbetrieb während der Ausfallzeit aufrecht zu erhalten.

[Geigenberger]

Hallo,

... absolut kein Problem!!
Habe erst letzte Woche bei einem befreundeten Kollegen wieder ein solches Netzwerk eingerichtet:

http://www.vondoczudoc.de/viewtopic.php?f=75&t=4438
http://www.vondoczudoc.de/viewtopic.php?f=75&t=5061

In weniger als zwei Minuten können Sie mit so einem Ersatzserver problemlos weiter arbeiten!

A. Geigenberger

[RAMöller]

Wichtig ist, dass an der Arbeitsstation regelmäßig eine Datenspiegelung (inkl.Dokumente) erfolgt und die Lizenz ebenfalls auf diesem Notfallarbeitsplatz gepeichert ist.

Wenn man testen möchte, ob der Arbeitsplatz als Ersatzserver taugt, kann man diesen vom Netz abklemmen, auf Einzelplatz stellen und starten. Wenn die Patienten von gerade eben vor der Sicherung noch da sind sieht es gut aus.

Wichtig: Nach dem Test bitte wieder auf Mehrplatz in den Gruneinstellungen umstellen, sonst kann es Probleme mit 2 parallen Datenbanken geben......

Um den Ersatzserver im Ernstfall zu starten, muss dort FastObjectsServer gestartet werden und das Laufwerk mit den Datenbanken freigegeben werden und die anderen Rechner aus diesen neuen Server eingestellt werden (Siehe Anleitung von Kollegen Geigenberger)

[Geigenberger]

Hallo,

Wenn man testen möchte, ob der Arbeitsplatz als Ersatzserver taugt, kann man diesen vom Netz abklemmen, auf Einzelplatz stellen und starten. Wenn die Patienten von gerade eben vor der Sicherung noch da sind sieht es gut aus.

--->> http://www.vondoczudoc.de/viewtopic.php ... 061#p28513 --->>
Innerhalb dieser local.ini Datei finden Sie ziemlich am Ende folgenden Abschnitt:
...
Lizenz zuerst auf Server suchen={nein}
Mehrplatzbetrieb={ja}
Pfad={C:\TurboMed}
Server={BigBoss}
Serverpfad={<nicht gesetzt>}
Serverport={<nicht gesetzt>}
...

Ich mach den Test folgendermaßen:
Wenn BEIDE Server laufen (also der FOS auf beiden Servern gestartet ist), stelle ich alle Arbeitsplätze so ein, dass diese auf den Ersatzserver zugreifen. Das geschieht ganz einfach mit folgender Zeile in der local.ini:
....
Server={LittleBoss}
...

Dann gebe ich an einem beliebigen Arbeitsplatz in einen beliebigen Patienten irgendeinen Text in die Karteikartenzeile und sehe erstmal nach, ob dieser neu eingegebene Text an allen Arbeitsplätzen sichtbar ist. Den "alten" Server schalte ich vorher aus - er ist ja "gespielt" defekt.
Anschließend schalte ich den "alten Server" wieder ein, stelle alle Arbeitsplätze wieder auf den "alten Server" um:
....
Server={BigBoss}
...
Und dann sollte der neu eingegebene Text an allen Arbeitsplätzen NICHT mehr sichtbar sein: Die Arbeitsplatzrechner greifen also wieder auf den "alten Server" zu.

"Spaßeshalber" kann man dann ja nochmal alle seine Arbeitsplätze wieder auf den "neuen Ersatzserver" umstellen:
Damit "übt" man den Notfall und man kann sehen, wie einfach und schnell man den Ersatzserver aktivieren kann.

Jedenfalls viel schneller, als sich ein "EDV-Partner" eine Zigarettenpause gönnen kann ...
... und viel billiger als teure "professionelle" Serverlösungen.

Sorgfältige Datensicherungen sind natürlich in jedem Fall nötig. Ich spiegle mit folgender Batch-Datei regelmäßig und automatisiert auf den Ersatz-Server-PC:
http://www.vondoczudoc.de/viewtopic.php ... =15#p14851
Dann sind immer die (ziemlich- je nach Intervall der Datensicherung) aktuellen Daten automatisch auch gleich auf dem Ersatzserver ("LittleBoss").

Viele Grüße
A. Geigenberger

P.S.: Natürlich müssen Sie sich bei der Umstellung auch noch um die Pfade z.B. zu den "Dokumenten" kümmern. Aber hier geht es ja zunächst erstmal nur um die Umstellung der "Serverfunktionalität" auf einen Ersatzserver.
Auf dem Hauptserver sind neuerdings zwei SSD-Platten, die im Raid-Verbund arbeiten, eingebaut: Ist rasend schnell - auch mit "veralteter" Hardware. Und wenn der Server ausfallen sollte und man mit dem Ersatzserver weiter arbeitet, dann hat man mit allergrößter Sicherheit auch noch die aktuellsten Daten.

[RAMöller]

@Geigenberger
an 2 Plätzen den FastObjectsServer laufen zu lassen ist schon speziell. Es kann zu Problemen kommen, wenn man hinterher vergisst, einen abzuschalten....und dann durch eine Fehlkonfiguration auf zwei Datenbanken arbeitet. Wenn man sich ganz sicher ist, kann man das machen, wenn man seltener derartige Ausfall- Szenarien testet, rate ich zum Entweder-Oder, d.h. FastObjectsServer nur auf dem Rechner laufen zu lassen, der als Server dient.

[lapins]

Herr Geigenberger, passen Sie auf, dass zur bekannten Lügenpresse hier nicht ein Lügenforum entsteht!!

Ich hab schon 2 Minuten gebraucht ihren Beitrag zu lesen und zu verstehen obwohl ich ja auch mein Bat.land betreibe um zu Sichern, zu Spiegeln und zu mappen und local ini zu verteilen!!

Also ein wenig länger dauerts schon!! Aber die gute Nachricht : es geht!!

[rfbdoc]

an 2 Plätzen den FastObjectsServer laufen zu lassen ist schon speziell

macht aber definitiv überhaupt keine Probleme.... !!!
Entscheidend sind nur die Grundeinstellungen (local.ini und global.ini)
Es sei aber nochmal auf den Hinweis aus dem Forum verwiesen, den Modus an Server1 oder Server2 (BigBoss/LittleBoss) unbedingt mit verschiedenen Farben zu versehen, damit man sofort erkennt, welcher Modus aktiv ist. Nicht nur theoretisch können im gleichen Netz zeitgleich der eine Client auf Server1(BigBoss) und der andere Client auf Server2(LittleBoss) zugreifen, was natürlich nie passieren sollte.
Der "Moduswechsel" ist einfach genial und verleiht eine Ausfallsicherheit die weit über Raidsysteme hinaus geht.

[EXEWERKER]

Ich finde diese Konstruktion auch cool.
RAID-Systeme lösen Backupproblematiken nicht, da Fehler, Verluste und versehentliche Löschungen einfach "sicher mitgespiegelt" werden. RAID Systeme erhöhen "nur" die Verfügbarkeit der Daten.
Die statistische Ausfallwahrscheinlichkeit von genau einer Festplatte im RAID 5 Verbund (von 3 oder 5 Platten) ist selbstverständlich auch mindestens 3- bzw. 5- mal höher, als bei einer Einzelplatte. Da ein Ersatz schnellstens erfolgen sollte, erhöht sich also auch die Supportwahrscheinlichkeit um mindestens den Faktor 3 oder 5. Die Gesamtverfügbarkeit des Systems nimmt prozentual zu, die Gesamtfehlerquote steigt dagegen aber viel dramatischer. Deshalb ist so ein "hot standby" System ein großer Nutzen, hat aber 2 Probleme: - die Daten sind noch immer nicht ganz aktuell, es kommt zu Verlusten und Sie müssen manuell eingreifen, was Zeit und Nerven kostet.

Wer eine vollautomatische Lösung möchte oder eine echte Hochverfügbarkeit aller Systeme, benötigt HA Lösungen ( https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit) der Stufe AEC-2 oder 3. Über Virtualisierung kann dies erreicht werden (VMWARE, Hyper-V). Der aktuelle Stand der Technik ist die sog. "Hyperconvergence", damit haben Sie 2 völlig synchrone Server ohne jegliches externes Storage. Der Ausfall eines Servers wird oft nicht einmal bemerkt. Kostet aber auch ein bisschen was.

[Geigenberger]

... da hätte ich mir jetzt einen schlimmeren "Shitstorm" erwartet

Aber der Reihe nach:

@Geigenberger
an 2 Plätzen den FastObjectsServer laufen zu lassen ist schon speziell. Es kann zu Problemen kommen, wenn man hinterher vergisst, einen abzuschalten....und dann durch eine Fehlkonfiguration auf zwei Datenbanken arbeitet. Wenn man sich ganz sicher ist, kann man das machen, wenn man seltener derartige Ausfall- Szenarien testet, rate ich zum Entweder-Oder, d.h. FastObjectsServer nur auf dem Rechner laufen zu lassen, der als Server dient.

Das ist richtig! Aber so ein "Serverumschalten" macht man ja nicht jeden Tag. WENN man es macht, muss man anschließend tatsächlich an JEDE Arbeitsstation gehen, in eine beliebige Patientenkarteikarte irgend etwas reinschreiben und nachsehen, ob dieser neu eingegebene Text wirklich auch an JEDER anderen Arbeitsstation sichtbar ist.
Dann kann man ohne Probleme an einem zweiten Arbeitsplatz den FOS-Server "mitlaufen" lassen: Er verbraucht so gut wie keine Resourcen!!! Ich habe auch nie die Probleme des "langsamen" TurboMed verstanden. Dies ist - so behaupte ich jetzt einfach mal - immer ein Problem einer fehlerhaften Netzwerkeinstellung: Feste IP-Adressen! Und gut ist's!!!
Und was ist hier im Forum nicht schon alles geschrieben worden über Probleme mit Terminal-Servern. So etwas KENNE ich gar nicht(!) : Zwei Arbeitsplätze im Netzwerk als Server; einer davon als "Ersatzserver". Dies ist in meinen Augen immer noch eine perfekte und extrem kostengünstige Lösung. Zugegeben: Unbeliebt bei EDV-Partnern

Herr Geigenberger, passen Sie auf, dass zur bekannten Lügenpresse hier nicht ein Lügenforum entsteht!!
Ich hab schon 2 Minuten gebraucht ihren Beitrag zu lesen und zu verstehen obwohl ich ja auch mein Bat.land betreibe um zu Sichern, zu Spiegeln und zu mappen und local ini zu verteilen!!
Also ein wenig länger dauerts schon!! Aber die gute Nachricht : es geht!!

Na, das ist ja die Hauptsache!
Aber es dauert tatsächlich nicht länger! Man muss ja nur an jedem Arbeitsplatz EINE Zeile in der local.ini ändern.
Und: Es geht noch eleganter! Ich habe mir an jedem Rechner 2 "local.ini's" in einen extra Ordner kopiert. Im Bedarfsfall kopiere ich nur die nötige local.ini in den Ordner C:\TurboMed\Programme\ . Gerade wenn mit dem Zweitserver andere Pfade nötig werden (z.B. für den Ordner "Dokumente"), dann ist dieses Verfahren einfacher, sicherer und schneller.
Das ist aber dann alles!! Und geht unter 2 Minuten!! Also: keine Lügenpresse

an 2 Plätzen den FastObjectsServer laufen zu lassen ist schon speziell

macht aber definitiv überhaupt keine Probleme.... !!!
Entscheidend sind nur die Grundeinstellungen (local.ini und global.ini)
Es sei aber nochmal auf den Hinweis aus dem Forum verwiesen, den Modus an Server1 oder Server2 (BigBoss/LittleBoss) unbedingt mit verschiedenen Farben zu versehen, damit man sofort erkennt, welcher Modus aktiv ist. Nicht nur theoretisch können im gleichen Netz zeitgleich der eine Client auf Server1(BigBoss) und der andere Client auf Server2(LittleBoss) zugreifen, was natürlich nie passieren sollte.
Der "Moduswechsel" ist einfach genial und verleiht eine Ausfallsicherheit die weit über Raidsysteme hinaus geht.

Ihr letzter Satz tut richtig gut!!
Wie machen Sie das mit den verschiedenen Farben?

Ich finde diese Konstruktion auch cool. (meine [A. Geigenberger] Anmerkung: Wow!!! Das adelt mich!)
RAID-Systeme lösen Backupproblematiken nicht, da Fehler, Verluste und versehentliche Löschungen einfach "sicher mitgespiegelt" werden. RAID Systeme erhöhen "nur" die Verfügbarkeit der Daten.

Ihr erster Satz tut auch richtig gut!!
Das ist natürlich klar! Ein RAID-System hat bei "meiner" Konfiguration trotzdem auch im Hinblick auf die Datensicherheit einen Sinn: Meist wird ja die Festplatte in einem PC kaputt. Und dann hat man eben bei einem RAID-System immer noch alle Daten, die zwischen dem Zeitpunkt der letzten Datensicherung und dem Festplattenausfall angefallen sind.

Zum praktischen Vorgehen:
1. Server defekt!
2. Ersatzserver starten und nahtlos weiter arbeiten. (Innerhalb 2 Minuten Ich bleibe dabei! )
3. Entspannen!! Ab jetzt hat man Zeit!
4. Server "reparieren". (Alle Daten sind ja noch auf der nicht defekten zweiten Festplatte im RAID-System)
5. Die inkonsistenten Daten des Servers auslesen und evtl. ausdrucken.
6. Zwischenzeitlich immer noch ganz entspannt mit dem Ersatzserver arbeiten
7. Daten des Ersatzservers auf den Hauptserver übertragen
8. Hauptserver starten und nun wieder mit diesem weiter arbeiten. (2 Minuten )
9. Bei Gelegenheit(!) - man hat immer noch viel Zeit - die inkonsistenten Daten manuell nachtragen. Dies sind meist/hoffentlich relativ wenige, abhängig vom Intervall der Datensicherung.
10. Mit dem gesparten Geld für einen EDV-Fachmann ein Wellness-Wochenende mit seiner Frau/Freundin//seinem Mann/Freund planen

Wer eine vollautomatische Lösung möchte oder eine echte Hochverfügbarkeit aller Systeme, benötigt HA Lösungen ( https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit) der Stufe AEC-2 oder 3. Über Virtualisierung kann dies erreicht werden (VMWARE, Hyper-V). Der aktuelle Stand der Technik ist die sog. "Hyperconvergence", damit haben Sie 2 völlig synchrone Server ohne jegliches externes Storage. Der Ausfall eines Servers wird oft nicht einmal bemerkt. Kostet aber auch ein bisschen was.

Tja - und damit wird's für Laien wie mich wieder einmal recht unverständlich - und wahrscheinlich wieder mal seehr teuer!!

A. Geigenberger

[rfbdoc]

Wie machen Sie das mit den verschiedenen Farben?

Über die TM Grundeinstellungen->Farbeinstellungen.
Einmal für Server1: Keine Änderung vornehmen
Dann für Server2: Farbgebung für Hauptfenster und Patientenfenster z.B. auf hellrot, dann würde man schon aus der Ferne erkennen dass der Klient nicht im normalen TM an Server1 arbeitet.
Das setzt natürlich voraus dass Sie für jeden Modus eine spezifische lokal.ini und global.ini in einem Verzeichnis ihrer Wahl abspeichern.

Das "umkopieren" oder "verschieben" der ini- Dateien kann man übrigens umgehen, indem TM mit einer Kopie der Desktopverknüpfung startet. In dieser Kopie gibt man unter Eigenschaften->"Ausführen in" das oben erwähnte Verzeichnis ihrer Wahl zur modifizierten local.ini und global.ini an. (Ist ein Tipp von "JR")

Jetzt können Sie wirklich mit einem Klick am Klienten vom einen auf den anderen Server umschalten.
Das geht noch schneller als in 2 Minuten und geht auch während an den anderen Arbeitsplätzen ganz normal weiter gearbeitet wird. Allerdings sollte man hier schon wissen wer was macht !! ABER ES GEHT.

[lapins]

hm, wie macht man das denn im Detail??

Geigenberger
5. Die inkonsistenten Daten des Servers auslesen und evtl. ausdrucken.

7. Daten des Ersatzservers auf den Hauptserver übertragen

Grüße rLap

[Geigenberger]

Hallo,

ad5:
Den "Hauptserver" wieder reparieren:
a) Wenn eine der beiden Festplatten defekt ist (ich gehe mal von einer RAID1 Konfiguration aus), dann einfach die defekte Festplatte ersetzen; das System sollte dann (ziemlich) selber die Datenspiegelung innerhalb der RAID-Platten erledigen. (Habe so etwas selber aber noch nie gemacht; bitte um Korrektur, wenn ich etwas Falsches sage). Außerdem sollte der Server sogar auch mit einer defekten Festplatte noch funktionieren, denn die zweite Festplatte ist ja in Ordnung.
b) Bei sonstigen Hardware-Defekten sind sowieso alle Daten ja noch da; man hat also alle Daten noch und muss diese auf den neuen Hauptserver umkopieren.

Anschließend hat man ja die Daten bis unmittelbar vor dem Crash auf dem Hauptserver zur Verfügung, könnte also z.B. eine Tagesliste ausdrucken und die Daten, die auf dem Ersatzserver fehlen ( = die angefallenen Daten im Zeitraum zwischen der letzten Datensicherung und dem Crash) zunächst auf dem Ersatzserver manuell nachtragen.

ad7:
Wenn dann die fehlenden Daten auf dem Ersatzserver nachgetragen sind, kann man ja ganz einfach die entsprechenden Daten (PraxisDB, "Dokumente") wieder vom Ersatzserver auf den Hauptserver umkopieren, um dann wieder mit dem Hauptserver zu arbeiten.

A. Geigenberger

https://de.wikipedia.org/wiki/RAID#RAID ... Spiegelung

[McLeod]

zu ad5 b)

Bei sonstigem Hardwareausfall ist die Wahrscheinlichkeit ziemlich hoch, daß die Praxis-DB zum Ausfallzeitpunkt hinüber ist (nicht konsistenter Zustand) und man auf die letzte Sicherung zurückgreifen muß.

[Geigenberger]

Warum eigentlich?
Mir leuchtet dies ein bei einem "extremen" Hardware-Ausfall: Wohnungsbrand oder Bltzschlag mit generalisierter massiver Überspannung im gesamten PC usw.
Aber warum sollten denn z.B. bei einem Netzteilausfall oder einem banalen Kabel-/Leiterbahndefekt im Mainboard die gesamten Daten auf der/den Serverfestplatte(n) weg sein?

A. Geigenberger

[McLeod]

Von den gesamten Daten und "weg" hat ja keiner gesprochen, nur von der Praxis-DB und von "kaputt".
Datenbanken mögen es eben nicht besonders, wenn man ihnen z.B. den Strom unterm Hintern wegklaut.
Stichworte: "hängende" Schreibvorgänge bzw. nicht abgeschlossene Transaktionen usw.
Tut man es dennoch, dann ist da Ergebnis eben oft eine fehlerhafte bzw. nicht verwendbare DB.

Ist prinzipiell das Gleiche wie beim Rechner selbst: Den soll man ja auch ordentlich herunterfahren und nicht nur hinten das Stromkabel rausreissen, damit geöffnete Dateien sauber zurückgeschrieben und evtl. Caches geleert, sowie Prozesse beendet werden können usw.
Tut man's nicht gibts bestenfalls Gemecker vom Fensterl oder dem Pinguin, schlimmstenfalls ein kaputtes Fenster oder kranken Vogel.

[Geigenberger]

Hallo,

Na ja; soo gefährlich scheint das mit den nicht abgeschlossenen Schreibvorgängen aber nun doch nicht zu sein. Ich arbeite schon seit es TurboMed gibt mit diesem Programm und zwar mit einem - von Spezialisten als ganz furchtbar schrecklich empfundenen - Peer-to-Peer Netzwerk:
Also ein Arbeitsplatz ist gleichzeitig der Server und ein zweiter Arbeitsplatz ist der "Ersatzserver".

In dieser Zeit ist es schon unzählige Male passiert, dass der Server ganz plötzlich in seiner Arbeit unterbrochen worden ist. (Stromausfall, versehentliches Ausschalten oder "Stecker ziehen" durch ein Arzthelferin).
NOCH NIE gab es negative Folgen außer dass vielleicht mal eine noch nicht abgeschlossene Zeileneingabe in der elektronischen Karteikarte (logischerweise) noch nicht auf den Server übertragen worden ist.
Trotzdem ist es natürlich korrekt von Ihnen, auf potentielle Gefahren hinzuweisen. Aber es ist keinesfalls die Regel, dass nach so einem Vorfall die Datenbank nicht mehr funktioniert und man auf die letzte Datensicherung zurück greifen muss.

zu ad5 b)
Bei sonstigem Hardwareausfall ist die Wahrscheinlichkeit ziemlich hoch, daß die Praxis-DB zum Ausfallzeitpunkt hinüber ist (nicht konsistenter Zustand) und man auf die letzte Sicherung zurückgreifen muß.

Ich meine, dass die Wahrscheinlichkeit, dass die Praxis-DB "hinüber" ist, ausgesprochen gering ist.

... aber vielleicht habe ja nur ich 15 Jahre lang Glück gehabt.

A. Geigenberger

[EXEWERKER]

Das Backup der geöffneten Datenbank sollte tunlichst vermieden werden. Dabei kommt es sehr oft zu Datenbankfehlern, meist merkt die nur keiner, weil es selten ist, dass mit der Kopie produktiv gearbeitet wird oder ein Test durchgeführt wird.

Jede Kopie ohne Backupmodus, jeder Snapshot egal ob Acronis oder Vmware verursacht ein Problem, weil die DB dies nicht unterstützt. Häufig landen diese DB's zur Reperatur in Kiel, es wird nur viel zu spät bemerkt. Nachts passieren wenig Fehler, weil keine Schreibzugriffe passieren, aber auch da sind Fehler die Folge.

Für die DB ist es nichts anderes als "Netzstecker ziehen", also ich kann nur warnen. DB also immer in den Backupmodus schicken und in x-Generationen bereithalten, weil ein Ausfall natürlich auch während der Kopie passieren kann. Mittels diverser Skripte oder TMPACKUP geht diese Versionierung automatisch, z.B. einmal pro Stunde, wobei die letzten 10 Stunden vorgehalten werden.

Wer weiss, wie es geht kann natürlich auch die Schreibzugriffe gleich auf 2 Medien parallel durchführen.

[Geigenberger]

Hallo,
ein Backup NUR im Backup-Modus ist eigentlich selbstverständlich! (Geht es eigentlich anders??)

%tumedprg%TMAdmin /beginBackup /server=%Servername%
..
[jetzt kommt das Backup: z.B. robocopy ...]
..
%tumedprg%TMAdmin /endbackup /server=%Servername%

Und ein unerwartetes Aussteigen immer ohne Backupmodus ergibt sich aus der unerwarteten Situation.
(Die Putzfrau, die versehentlich den Netzstecker zieht, wird den Server wohl kaum vorher in den Backup-Modus versetzen)

A. Geigenberger

[rfbdoc]

@Geigenberger
Um zu verhindern dass versehentlich gleichzeitig von 2 verschiedenen Clients aus auf die Datenbank zugegriffen wird, frage ich den externen Backupmodus der Datenbank ab: TmAdmin.exe /backupstatus. Die Ausgabe wird in der Datei Status.txt im Verzeichnis %tmp% abgelegt und im nächsten Schritt ausgelesen.
Je nach Errorlevel wird die Sprungmarke Kopieren oder NichtKopieren in der Batch aufgerufen.


Batch-Syntax, wobei die Variable TmPfad das lokale Installationsverzeichnis von Turbomed repräsentiert
@echo off

\\192.168.0.10\F\TurboMed\Programm\TmAdmin.exe /backupstatus /server=192.168.0.10 >%tmp%\Status.txt
FindStr /m "nicht" %tmp%\Status.txt

If %errorlevel% == 0 goto :Kopieren
If %errorlevel% == 1 goto :NichtKopieren

:Kopieren
cls
echo Externer Backupmodus laeuft nicht
echo Kopieren der PraxisDB mittels Robocopy wird nun gestartet
%TmPfad%\turbomed\Programm\TMAdmin /beginBackup /server=192.168.0.10
robocopy \\192.168.0.10\F\TurboMed\PraxisDB %TmPfad%\turbomed\PraxisDB /mir
%TmPfad%\turbomed\Programm\TMAdmin /endbackup /server=192.168.0.10
goto :Ende

:NichtKopieren
cls
echo Externer Backupmodus auf Server1 192.168.0.10 laeuft
echo Zugriff auf PraxisDB aktuell nicht moeglich. Versuchen Sie es spaeter noch einmal
echo Kopieren der PraxisDB mittels Robocopy wird nicht gestartet
echo....
pause>nul
goto :Ende

:Ende
echo Ende

[Geigenberger]

@Geigenberger
Um zu verhindern dass versehentlich gleichzeitig von 2 verschiedenen Clients aus auf die Datenbank zugegriffen wird, frage ich den externen Backupmodus der Datenbank ab: TmAdmin.exe /backupstatus. Die Ausgabe wird in der Datei Status.txt im Verzeichnis %tmp% abgelegt und im nächsten Schritt ausgelesen.
Je nach Errorlevel wird die Sprungmarke Kopieren oder NichtKopieren in der Batch aufgerufen.

Hallo,
Ist dieses Vorgehen tatsächlich notwendig?
Vor JEDEM Backuplauf folgt in der Batch-Datei die Zeile:
%tumedprg%TMAdmin /beginBackup /server=%Servername%
Dies versetzt die Datenbank in den Backupmodus - und wenn diese schon im Backupmodus ist, dann meldet dies der Server ganz brav. Ich muss also eigentlich nicht vorher fragen.
Außerdem "leben doch diese Server davon", dass ständig mit mehr als einem Rechner auf diesen Server zugegriffen wird !? Auch während des Backup-Modus.

Was schon gelegentlich hilfreich ist, ist ein Ikon, das nur diesen Code aufruft:
%tumedprg%TMAdmin /endbackup /server=%Servername%

Denn wenn mal eine ungeduldige Arzthelferin vor der Mittagspause den Rechner runterfährt und dieser im Backupmodus verbleibt, dann kann man den Server so wieder in den "normalen Arbeitsmodus" versetzen.

A. Geigenberger