Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Zitat von bro am 29. Januar 2026, 12:25 UhrDa ich ja mit robocopy sichere, könnte ich ja, wenn alle Clients MO geschlossen haben, also keine Anfragen an die MariaDB stattfinden, ohne irgendwelche weiteren Maßnahmen einfach meinen Indamed Ordner und den Ordner mit der MariaDB sichern, auf eine externe Festplatte und fertig. Das geht schneller, als wenn ich eine ganze FP-Partition sichere. Denke ich richtig. Bei Firefox muss ich ja ein stop.mo setzen.
Da ich ja mit robocopy sichere, könnte ich ja, wenn alle Clients MO geschlossen haben, also keine Anfragen an die MariaDB stattfinden, ohne irgendwelche weiteren Maßnahmen einfach meinen Indamed Ordner und den Ordner mit der MariaDB sichern, auf eine externe Festplatte und fertig. Das geht schneller, als wenn ich eine ganze FP-Partition sichere. Denke ich richtig. Bei Firefox muss ich ja ein stop.mo setzen.
Zitat von Peter Quick am 29. Januar 2026, 12:46 UhrDa würde ich nicht drauf wetten. Das kann klappen, muss es aber nicht. Wenn Sie auf Dateiebene sichern, ist das bei einer Datenbank immer schwierig. Auch wenn keiner angemeldet ist. Die einzelnen Daten im Dateisystem sind kein Problem. Aber die Hauptdatenbank ist ein Problem aus meiner Sicht…
Da würde ich nicht drauf wetten. Das kann klappen, muss es aber nicht. Wenn Sie auf Dateiebene sichern, ist das bei einer Datenbank immer schwierig. Auch wenn keiner angemeldet ist. Die einzelnen Daten im Dateisystem sind kein Problem. Aber die Hauptdatenbank ist ein Problem aus meiner Sicht…
Zitat von Ulrich Fickweiler am 29. Januar 2026, 14:11 UhrDie laufenden Dienste am Server müssen beendet werden. Das kann per kurzem Skript erfolgen. Dann sollte das Sichern konsistent funktionieren. Aber vielleicht könnte sich Indamed hierzu nochmal kurz äußern….
Die laufenden Dienste am Server müssen beendet werden. Das kann per kurzem Skript erfolgen. Dann sollte das Sichern konsistent funktionieren. Aber vielleicht könnte sich Indamed hierzu nochmal kurz äußern….
Zitat von Friedrich Jovy am 29. Januar 2026, 15:09 UhrIch lasse Nachts vor und nach dem Backup immer folgende Scripte mitlaufen. Damit erhalte ich bisher immer einen konsistenten Datensatz.
Vor dem Backup werden diese drei Befehle vom Backupprogramm ausgeführt:
net stop „MEDICAL OFFICE – Guardian“
net stop „Firebird Guardian – MEDICALOFFICE“
net stop „MariaDB-MEDICALOFFICE“Nach Abschluss des Backups führt mein Backupprogramm dann diese drei Befehle aus.
net start „Firebird Guardian – MEDICALOFFICE“
net start „MEDICAL OFFICE – Guardian“
net start „MariaDB-MEDICALOFFICE“
Ich lasse Nachts vor und nach dem Backup immer folgende Scripte mitlaufen. Damit erhalte ich bisher immer einen konsistenten Datensatz.
Vor dem Backup werden diese drei Befehle vom Backupprogramm ausgeführt:
net stop „MEDICAL OFFICE – Guardian“
net stop „Firebird Guardian – MEDICALOFFICE“
net stop „MariaDB-MEDICALOFFICE“
Nach Abschluss des Backups führt mein Backupprogramm dann diese drei Befehle aus.
net start „Firebird Guardian – MEDICALOFFICE“
net start „MEDICAL OFFICE – Guardian“
net start „MariaDB-MEDICALOFFICE“
Zitat von bro am 29. Januar 2026, 18:00 Uhrwelches Backupprogramm verwenden Sie?
net stop „MEDICAL OFFICE – Guardian“
net stop „Firebird Guardian – MEDICALOFFICE“ das heißt ein stop.mo wird nicht in den Ordner geschrieben, ich dachte, das wäre zwingend erforderlich, da Windows die Diensten incht sauber beendet.
net stop „MariaDB-MEDICALOFFICE“Nach Abschluss des Backups führt mein Backupprogramm dann diese drei Befehle aus.
net start „Firebird Guardian – MEDICALOFFICE“
net start „MEDICAL OFFICE – Guardian“
net start „MariaDB-MEDICALOFFICE“
welches Backupprogramm verwenden Sie?
net stop „MEDICAL OFFICE – Guardian“
net stop „Firebird Guardian – MEDICALOFFICE“ das heißt ein stop.mo wird nicht in den Ordner geschrieben, ich dachte, das wäre zwingend erforderlich, da Windows die Diensten incht sauber beendet.
net stop „MariaDB-MEDICALOFFICE“
Nach Abschluss des Backups führt mein Backupprogramm dann diese drei Befehle aus.
net start „Firebird Guardian – MEDICALOFFICE“
net start „MEDICAL OFFICE – Guardian“
net start „MariaDB-MEDICALOFFICE“
Zitat von Marcel Patzer am 30. Januar 2026, 8:55 UhrZitat von Johannes Neimann am 28. Januar 2026, 18:30 UhrLeider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Hallo Herr Neimann,
sie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.
Zitat von Johannes Neimann am 28. Januar 2026, 18:30 UhrLeider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Hallo Herr Neimann,
sie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.
Marcel Patzer
INDAMED Team
Zitat von Marcel Patzer am 30. Januar 2026, 9:04 UhrZitat von Peter Quick am 29. Januar 2026, 12:22 UhrZitat von Peter Quick am 29. Januar 2026, 12:18 UhrZitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Aber ich gebe allen Vorrednern Recht: Das Einbehalten des Passworts finde ich keinen guten Schritt. Das schafft kein Vertrauen, ganz im Gegenteil. Man kann vieles vertraglich regeln, ich will kein geistiges Eigentum von Indamed stehlen. Aber es sind MEINE Daten. Ich habe diese erhoben und gespeichert. Also habe ich auch ein Recht zum Zugriff auf diese Daten. Falls jemand so bescheuert ist, auf die Datenbank zu schreiben, ohne sich auszukennen, muß er halt mit den Folgen leben. Das nennt sich Eigenverantwortung!
Hallo Herr Quick,
prinzipiell haben sie damit nicht unrecht. Nur geht es in einem anderen Punkt auch darum, Fremdsoftware keinen Zugriff auf die Datenbank zu ermöglichen. Wir hatten dort einen Fall, dass sich diverse Praxen immer wieder wegen mangelnder Performance gemeldet haben und der INDAMED-Support sehr viele Stunden an Aufwand hatte um herauszufinden, dass eine Fremdsoftware direkt Abfragen auf die Datenbank macht, die aufgemachten Verbindungen dann nicht schließt und so bei jeder Abfrage eine neue Verbindung aufmacht. Dadurch geht je nach Potenz des Servers, dann die Performance in den Keller bis zum Praxisstillstand.
Der angerichtete Schaden und Arbeitsaufwand ist nicht zu beziffern und das ohne Eigenverschulden. Auch wegen solchen Fällen hat sich die Geschäftsführung zu diesem Schritt entschieden.
Zitat von Peter Quick am 29. Januar 2026, 12:22 UhrZitat von Peter Quick am 29. Januar 2026, 12:18 UhrZitat von Dubbebub am 27. Januar 2026, 11:19 UhrZitat von Ulrich Fickweiler am 27. Januar 2026, 9:15 UhrWir sichern MO nach Beendigung der laufenden Dienste mit einem normalen Backup-Programm. Das funktioniert problemlos, eine Wiederherstellung auf einem neuen Server hatten wir schon und hat problemlos funktioniert.
Haben Sie schon Maria-DB ?
Habe auch Maria DB seit längerer Zeit und arbeite genau so. habe erst im Sommer meinen Server selbst ersetzt. Ging so problemlos…
Also kein Dump, sondern Festplatten Backup (kein File, sondern Partition)… Tools hatten wir ja schon mehrfach besprochen
Aber ich gebe allen Vorrednern Recht: Das Einbehalten des Passworts finde ich keinen guten Schritt. Das schafft kein Vertrauen, ganz im Gegenteil. Man kann vieles vertraglich regeln, ich will kein geistiges Eigentum von Indamed stehlen. Aber es sind MEINE Daten. Ich habe diese erhoben und gespeichert. Also habe ich auch ein Recht zum Zugriff auf diese Daten. Falls jemand so bescheuert ist, auf die Datenbank zu schreiben, ohne sich auszukennen, muß er halt mit den Folgen leben. Das nennt sich Eigenverantwortung!
Hallo Herr Quick,
prinzipiell haben sie damit nicht unrecht. Nur geht es in einem anderen Punkt auch darum, Fremdsoftware keinen Zugriff auf die Datenbank zu ermöglichen. Wir hatten dort einen Fall, dass sich diverse Praxen immer wieder wegen mangelnder Performance gemeldet haben und der INDAMED-Support sehr viele Stunden an Aufwand hatte um herauszufinden, dass eine Fremdsoftware direkt Abfragen auf die Datenbank macht, die aufgemachten Verbindungen dann nicht schließt und so bei jeder Abfrage eine neue Verbindung aufmacht. Dadurch geht je nach Potenz des Servers, dann die Performance in den Keller bis zum Praxisstillstand.
Der angerichtete Schaden und Arbeitsaufwand ist nicht zu beziffern und das ohne Eigenverschulden. Auch wegen solchen Fällen hat sich die Geschäftsführung zu diesem Schritt entschieden.
Marcel Patzer
INDAMED Team
Zitat von bro am 30. Januar 2026, 9:18 UhrZitat von Marcel Patzer am 30. Januar 2026, 8:55 Uhrsie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.Ich kenne die interne Datensicherung mit der Firebird Datenbank. Die ist so langsam, das geht gar nicht.
Ich sichere den gesamten Indamed-Ordner mit derzeit 70 GB in unter drei Minuten (das ist noch wenig, im Vergleich zu anderen Praxen. Insgesamt dauert das, hintereinander auf vier verschiedene interne und externe Festplatten, maximal zehn Minuten – eher weniger. Das lässt sich mit der Datenbanksicherung von Indamed überhaupt nicht darstellen.
Wir machen das zweimal am Tag während der Praxispause und am Praxisende und ich möchte danach rasch nach Hause gehen und nicht ewig auf eine Datensicherung warten. Und ich möchte auch externe Platten mit nach Hause nehmen.
Läuft die MO interne Datensicherung bei MariaDB auch so langsam wie eine Schnecke?
Mit meinen Sicherungen konnte der FLS den Server neu aufsetzen und die MO-Serverinstallation ebenfalls neu durchführen. Das war überhaupt kein Problem, und es gab auch keinerlei Performance-Einbrüche.
Irgendwie ist die Datensicherungsthematik bei MO eine never ending story. Ich habe einiges am Medical Office zu kritisieren, damit kann ich aber gut leben, bis zu meinem Praxisende. Was ich jedoch nicht akzeptieren kann und will, ist auch nur eine Sekunde länger als nötig am Ende des Praxisalltages zu warten, um eine Sicherung mit nach Hause zu nehmen. Wann kommt endlich die „out of the box“ Lösung für alle, besonders spätestens dann, wenn wir alle mit Maria zwangsverheiratet werden.
Zitat von Marcel Patzer am 30. Januar 2026, 8:55 Uhrsie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.
Ich kenne die interne Datensicherung mit der Firebird Datenbank. Die ist so langsam, das geht gar nicht.
Ich sichere den gesamten Indamed-Ordner mit derzeit 70 GB in unter drei Minuten (das ist noch wenig, im Vergleich zu anderen Praxen. Insgesamt dauert das, hintereinander auf vier verschiedene interne und externe Festplatten, maximal zehn Minuten – eher weniger. Das lässt sich mit der Datenbanksicherung von Indamed überhaupt nicht darstellen.
Wir machen das zweimal am Tag während der Praxispause und am Praxisende und ich möchte danach rasch nach Hause gehen und nicht ewig auf eine Datensicherung warten. Und ich möchte auch externe Platten mit nach Hause nehmen.
Läuft die MO interne Datensicherung bei MariaDB auch so langsam wie eine Schnecke?
Mit meinen Sicherungen konnte der FLS den Server neu aufsetzen und die MO-Serverinstallation ebenfalls neu durchführen. Das war überhaupt kein Problem, und es gab auch keinerlei Performance-Einbrüche.
Irgendwie ist die Datensicherungsthematik bei MO eine never ending story. Ich habe einiges am Medical Office zu kritisieren, damit kann ich aber gut leben, bis zu meinem Praxisende. Was ich jedoch nicht akzeptieren kann und will, ist auch nur eine Sekunde länger als nötig am Ende des Praxisalltages zu warten, um eine Sicherung mit nach Hause zu nehmen. Wann kommt endlich die „out of the box“ Lösung für alle, besonders spätestens dann, wenn wir alle mit Maria zwangsverheiratet werden.
Zitat von Christian Schnell am 30. Januar 2026, 10:44 UhrZitat von Marcel Patzer am 30. Januar 2026, 9:04 Uhr
Hallo Herr Quick,
prinzipiell haben sie damit nicht unrecht. Nur geht es in einem anderen Punkt auch darum, Fremdsoftware keinen Zugriff auf die Datenbank zu ermöglichen. Wir hatten dort einen Fall, dass sich diverse Praxen immer wieder wegen mangelnder Performance gemeldet haben und der INDAMED-Support sehr viele Stunden an Aufwand hatte um herauszufinden, dass eine Fremdsoftware direkt Abfragen auf die Datenbank macht, die aufgemachten Verbindungen dann nicht schließt und so bei jeder Abfrage eine neue Verbindung aufmacht. Dadurch geht je nach Potenz des Servers, dann die Performance in den Keller bis zum Praxisstillstand.
Der angerichtete Schaden und Arbeitsaufwand ist nicht zu beziffern und das ohne Eigenverschulden. Auch wegen solchen Fällen hat sich die Geschäftsführung zu diesem Schritt entschieden.Hallo Herr Patzer, vielen Dank für das HowTo Datensicherung und die Erklärung, das hilft schon mal weiter.
Ich habe jetzt Glück, dass ich noch Herr über meine Daten bin und selber meine Sicherung konfigurieren und auch prüfen kann, die meisten Kunden können das nun scheinbar nicht mehr. Auch wenn ich das Problem nachvollziehen kann, muss ich als Kunde meine Datensicherung machen und prüfen können und kann nicht immer beim überlasteten Support betteln. Datenbank Zugriff könnte Indamed eventuell davon trennen und ein extern auslösbares MO-Sicherungsprogramm erstellen das die Nutzer bekommen und mit Ihrem Sicherungskonzept nutzen. Für mich wäre das ok, die Nutzerin Privacy sieht das anders.
Lg C.Schnell
Zitat von Marcel Patzer am 30. Januar 2026, 9:04 Uhr
Hallo Herr Quick,
prinzipiell haben sie damit nicht unrecht. Nur geht es in einem anderen Punkt auch darum, Fremdsoftware keinen Zugriff auf die Datenbank zu ermöglichen. Wir hatten dort einen Fall, dass sich diverse Praxen immer wieder wegen mangelnder Performance gemeldet haben und der INDAMED-Support sehr viele Stunden an Aufwand hatte um herauszufinden, dass eine Fremdsoftware direkt Abfragen auf die Datenbank macht, die aufgemachten Verbindungen dann nicht schließt und so bei jeder Abfrage eine neue Verbindung aufmacht. Dadurch geht je nach Potenz des Servers, dann die Performance in den Keller bis zum Praxisstillstand.
Der angerichtete Schaden und Arbeitsaufwand ist nicht zu beziffern und das ohne Eigenverschulden. Auch wegen solchen Fällen hat sich die Geschäftsführung zu diesem Schritt entschieden.
Hallo Herr Patzer, vielen Dank für das HowTo Datensicherung und die Erklärung, das hilft schon mal weiter.
Ich habe jetzt Glück, dass ich noch Herr über meine Daten bin und selber meine Sicherung konfigurieren und auch prüfen kann, die meisten Kunden können das nun scheinbar nicht mehr. Auch wenn ich das Problem nachvollziehen kann, muss ich als Kunde meine Datensicherung machen und prüfen können und kann nicht immer beim überlasteten Support betteln. Datenbank Zugriff könnte Indamed eventuell davon trennen und ein extern auslösbares MO-Sicherungsprogramm erstellen das die Nutzer bekommen und mit Ihrem Sicherungskonzept nutzen. Für mich wäre das ok, die Nutzerin Privacy sieht das anders.
Lg C.Schnell
Zitat von Johannes Braun am 30. Januar 2026, 11:34 UhrZitat von Marcel Patzer am 30. Januar 2026, 8:55 UhrZitat von Johannes Neimann am 28. Januar 2026, 18:30 UhrLeider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Hallo Herr Neimann,
sie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.Mein letzter Stand war auch, dass man bei der internen Datensicherung das Passwort braucht – ist aber tatsächlich nicht so, macht Medical Office dann für einen.
@Marcel Patzer – Lässt sich die interne Datensicherung so konfigurieren, dass sie NUR die MariaDB sichert, aber nicht das DBFA?
Es wäre nett auf dem Server eine konsistente Sicherung der Datenbank liegen zu haben, falls die Datenbank im Backup korrupt ist – aber eine zusätzliche Kopie des DBFA kann ich überhaupt nicht gebrauchen.
Zitat von Marcel Patzer am 30. Januar 2026, 8:55 UhrZitat von Johannes Neimann am 28. Januar 2026, 18:30 UhrLeider nicht.
Denn das vorgesehene Standardvorgehen erfordert bei MariaDB den Befehl mysqldump, der aber das Datenbankkennwort benötigt.
Hallo Herr Neimann,
sie können den mysqldump, wie im Artikel genannt, über unsere interne Datensicherung durchführen.
Dazu benötigen sie meines Wissens nach kein Datenbank-Passwort.
Mein letzter Stand war auch, dass man bei der internen Datensicherung das Passwort braucht – ist aber tatsächlich nicht so, macht Medical Office dann für einen.
@Marcel Patzer – Lässt sich die interne Datensicherung so konfigurieren, dass sie NUR die MariaDB sichert, aber nicht das DBFA?
Es wäre nett auf dem Server eine konsistente Sicherung der Datenbank liegen zu haben, falls die Datenbank im Backup korrupt ist – aber eine zusätzliche Kopie des DBFA kann ich überhaupt nicht gebrauchen.