Umstellung auf MariaDB und anschließendes Sicherungskonzept.
Zitat von Johannes Neimann am 16. Januar 2026, 7:19 UhrNachfrage aus aktuellem Anlass:
Nach meinem Verständnis ist die sicherste Variante für eine wiederherstellbare MariaDB-Datenbank der Dump. Für den Dump wird aber das MariaDB-Kennwort benötigt. Das Kennwort soll aber – nach Auskunft meines Systemhauses auf Direktive von Indamed – den Kunden grundsätzlich nicht (mehr) zur Verfügung gestellt. Faktisch sind wir zahlenden Kunden also nicht mehr „Herr“ oder „Frau“ unserer eigenen Daten und vom Wohlwollen Indameds bzw. des Systemhauses abhängig.
Ich bin also auch hinsichtlich sicherer Backup- und Sicherungskonzepte stark eingeschränkt. Dazu bitte ich um eine offizielle Aussage eines Indamed-Offiziellen.
Für mich persönlich heißt das, dass ich MedicalOffice nicht mehr uneingeschränkt potentiellen Neukunden empfehlen könnte. Und auch im Bereich der berufspolitischen Einflussnahme auf derartige Einschränkungen der Nutzer werde ich meine Bemühungen intensivieren. Der Digitalisierungsausschuss der KVN und die Vorständin Löhr werden zeitgleich informiert.
Nachfrage aus aktuellem Anlass:
Nach meinem Verständnis ist die sicherste Variante für eine wiederherstellbare MariaDB-Datenbank der Dump. Für den Dump wird aber das MariaDB-Kennwort benötigt. Das Kennwort soll aber – nach Auskunft meines Systemhauses auf Direktive von Indamed – den Kunden grundsätzlich nicht (mehr) zur Verfügung gestellt. Faktisch sind wir zahlenden Kunden also nicht mehr „Herr“ oder „Frau“ unserer eigenen Daten und vom Wohlwollen Indameds bzw. des Systemhauses abhängig.
Ich bin also auch hinsichtlich sicherer Backup- und Sicherungskonzepte stark eingeschränkt. Dazu bitte ich um eine offizielle Aussage eines Indamed-Offiziellen.
Für mich persönlich heißt das, dass ich MedicalOffice nicht mehr uneingeschränkt potentiellen Neukunden empfehlen könnte. Und auch im Bereich der berufspolitischen Einflussnahme auf derartige Einschränkungen der Nutzer werde ich meine Bemühungen intensivieren. Der Digitalisierungsausschuss der KVN und die Vorständin Löhr werden zeitgleich informiert.
Zitat von bro am 16. Januar 2026, 7:55 UhrDas Jahr fängt gar nicht gut an, wie mir scheint.
Da wir Indamed Kunden ja unvermeidlich in die MariaDB gezwungen werden, eine Frage:
Ich möchte wie bei Firebird mit Robocopy ein automatisiertes Backup der MariaDB machen, inklusive Stoppen des Servers vorher und Neustarten danach. Geht das genauso mit einem Batch-Skript, also die MariaDB als Dienst stoppen, die Dateien kopieren und den Dienst wieder starten.
Ungefähr so stelle ich mir das vor.
@echo off
REM —————————————
REM MariaDB Backup mit Robocopy auf D:\
REM —————————————REM 1. MariaDB-Dienst stoppen
echo Stoppe MariaDB-Dienst…
net stop MariaDBREM 2. Backup-Ordner definieren
set SOURCE=“D:\MariaDB\data“
set DEST=“E:\MariaDB_Backup_%date:/=-%“REM 3. Robocopy ausführen
echo Starte Kopie mit Robocopy…
robocopy %SOURCE% %DEST% /MIR /R:3 /W:5 /LOG:“E:\MariaDB_Backup_log.txt“REM 4. MariaDB-Dienst wieder starten
echo Starte MariaDB-Dienst…
net start MariaDBecho Backup abgeschlossen!
pause
Noch besser so:
Kann ich den Ordner \MariaDB\data in den \Indamed\ Ordner als Unterordner einfügen,D:\
└─ Indamed\
├─ MariaDB\
│ └─ data\ ← MariaDB-Daten
└─ Firebird\ ← Firebird-Daten, sonstige Dateien
@echo off
REM —————————————
REM Backup Indamed-Ordner inkl. MariaDB
REM —————————————REM 1. MariaDB-Dienst stoppen
echo Stoppe MariaDB-Dienst…
net stop MariaDBREM 2. Backup-Ziel definieren
set SOURCE=“D:\Indamed“
set DEST=“E:\Indamed_Backup_%date:/=-%“REM 3. Robocopy ausführen
echo Starte Kopie mit Robocopy…
robocopy %SOURCE% %DEST% /MIR /R:3 /W:5 /LOG:“E:\Indamed_Backup_log.txt“REM 4. MariaDB-Dienst wieder starten
echo Starte MariaDB-Dienst…
net start MariaDBecho Backup abgeschlossen!
pause
Das Jahr fängt gar nicht gut an, wie mir scheint.
Da wir Indamed Kunden ja unvermeidlich in die MariaDB gezwungen werden, eine Frage:
Ich möchte wie bei Firebird mit Robocopy ein automatisiertes Backup der MariaDB machen, inklusive Stoppen des Servers vorher und Neustarten danach. Geht das genauso mit einem Batch-Skript, also die MariaDB als Dienst stoppen, die Dateien kopieren und den Dienst wieder starten.
Ungefähr so stelle ich mir das vor.
@echo off
REM —————————————
REM MariaDB Backup mit Robocopy auf D:\
REM —————————————
REM 1. MariaDB-Dienst stoppen
echo Stoppe MariaDB-Dienst…
net stop MariaDB
REM 2. Backup-Ordner definieren
set SOURCE=“D:\MariaDB\data“
set DEST=“E:\MariaDB_Backup_%date:/=-%“
REM 3. Robocopy ausführen
echo Starte Kopie mit Robocopy…
robocopy %SOURCE% %DEST% /MIR /R:3 /W:5 /LOG:“E:\MariaDB_Backup_log.txt“
REM 4. MariaDB-Dienst wieder starten
echo Starte MariaDB-Dienst…
net start MariaDB
echo Backup abgeschlossen!
pause
Noch besser so:
Kann ich den Ordner \MariaDB\data in den \Indamed\ Ordner als Unterordner einfügen,
D:\
└─ Indamed\
├─ MariaDB\
│ └─ data\ ← MariaDB-Daten
└─ Firebird\ ← Firebird-Daten, sonstige Dateien
@echo off
REM —————————————
REM Backup Indamed-Ordner inkl. MariaDB
REM —————————————
REM 1. MariaDB-Dienst stoppen
echo Stoppe MariaDB-Dienst…
net stop MariaDB
REM 2. Backup-Ziel definieren
set SOURCE=“D:\Indamed“
set DEST=“E:\Indamed_Backup_%date:/=-%“
REM 3. Robocopy ausführen
echo Starte Kopie mit Robocopy…
robocopy %SOURCE% %DEST% /MIR /R:3 /W:5 /LOG:“E:\Indamed_Backup_log.txt“
REM 4. MariaDB-Dienst wieder starten
echo Starte MariaDB-Dienst…
net start MariaDB
echo Backup abgeschlossen!
pause
Zitat von Jörg Sprenger, Kirchner, Müller am 16. Januar 2026, 8:29 UhrHallo Bro
Vor einigen Jahren hatte ich mal ein Gespräch mit Herr Streit über das Sicherungskonzept, wenn die Daten des Archivs ausgelagert würden und die DB umgestellt würde. Ich habe für mich damals im Kopf behalten (über meinen Kopf ist ja so einiges verunsichernde im Forum zu lesen :-), dass ich dann, so ähnlich, wie sie dies mit Firebird gemacht haben, im laufendes Betrieb die gespeicherten Datenfiles innerhalb von /INDAMED sichern kann, nach der ersten kompletten Sicherung danach auch nur noch inkrementiell.
Das alleine reicht aber nicht, die Verwaltung dieser ganzen Daten, und ich beschreibe dass nun mit meine Worten, nicht als Techniker oder IT-Fachmensch, benötigt noch eine Verwaltungsschicht, die diese ganzen Daten organisiert/ MARIA-DB.
Um noch den Organisator aller Daten auch zu sichern, gibt es den sog. DUMP, eine Zusammenfassung aller MO-Daten, die von MARIA-DB verwaltet wird. Diesen DUMP muss man immer wieder neu erstellen, ähnlich einer GBAK-DaTei unter Firebird, auch hier mittels Batch.
Das Erstellen gelingt im laufenden Betrieb, so wie auch unter Firebird. Damit wird aber Quasi mit dem Erstellen des DUMPs der Zustand zu dem Zeitpunkt eingefroeren, alles was während der Erstellung noch in der MO-Struktur passiert, (für 10-60 Minuten, je nach Leistung des Rechners), ist dann noch nicht gesichert.
Aber, ja, so können Sie auch im laufenden Betrieb mit Batch und Robocopy, das meiste sichern. So machen wir es u.a.
A B E R :
ZUSÄTZLICH!!!! machen wir regelmäßig SNAPSHOTS vom gesamten Server (auch im laufenden Betrieb) und haben dies auch schon mehrfach erfolgreich auf externe Hardware zurück gespielt, quasi einen Server-light erzeugt. Die Software SNAPSHOT kosten ca 100€ und ist von einer Aachener? Software-Schmiede, nutze ich schon (selten) seit 15 Jahren. Ihren Robocopy-Job mache ich mit Syncredible (ASCOMP, ca 40€) und Batches seit 22 Jahren. Restores haben bis jetzt funktioniert.
So, das ist mein immer noch laienhafter Blick auf dieses eigentlich zentrale, aber nicht stabil integrierte Projekt von MO.
Hallo Bro
Vor einigen Jahren hatte ich mal ein Gespräch mit Herr Streit über das Sicherungskonzept, wenn die Daten des Archivs ausgelagert würden und die DB umgestellt würde. Ich habe für mich damals im Kopf behalten (über meinen Kopf ist ja so einiges verunsichernde im Forum zu lesen :-), dass ich dann, so ähnlich, wie sie dies mit Firebird gemacht haben, im laufendes Betrieb die gespeicherten Datenfiles innerhalb von /INDAMED sichern kann, nach der ersten kompletten Sicherung danach auch nur noch inkrementiell.
Das alleine reicht aber nicht, die Verwaltung dieser ganzen Daten, und ich beschreibe dass nun mit meine Worten, nicht als Techniker oder IT-Fachmensch, benötigt noch eine Verwaltungsschicht, die diese ganzen Daten organisiert/ MARIA-DB.
Um noch den Organisator aller Daten auch zu sichern, gibt es den sog. DUMP, eine Zusammenfassung aller MO-Daten, die von MARIA-DB verwaltet wird. Diesen DUMP muss man immer wieder neu erstellen, ähnlich einer GBAK-DaTei unter Firebird, auch hier mittels Batch.
Das Erstellen gelingt im laufenden Betrieb, so wie auch unter Firebird. Damit wird aber Quasi mit dem Erstellen des DUMPs der Zustand zu dem Zeitpunkt eingefroeren, alles was während der Erstellung noch in der MO-Struktur passiert, (für 10-60 Minuten, je nach Leistung des Rechners), ist dann noch nicht gesichert.
Aber, ja, so können Sie auch im laufenden Betrieb mit Batch und Robocopy, das meiste sichern. So machen wir es u.a.
A B E R :
ZUSÄTZLICH!!!! machen wir regelmäßig SNAPSHOTS vom gesamten Server (auch im laufenden Betrieb) und haben dies auch schon mehrfach erfolgreich auf externe Hardware zurück gespielt, quasi einen Server-light erzeugt. Die Software SNAPSHOT kosten ca 100€ und ist von einer Aachener? Software-Schmiede, nutze ich schon (selten) seit 15 Jahren. Ihren Robocopy-Job mache ich mit Syncredible (ASCOMP, ca 40€) und Batches seit 22 Jahren. Restores haben bis jetzt funktioniert.
So, das ist mein immer noch laienhafter Blick auf dieses eigentlich zentrale, aber nicht stabil integrierte Projekt von MO.
Zitat von bro am 16. Januar 2026, 9:00 UhrWir sichern nur 1x Mittags und 1x Abends, wenn MO nicht verwendet wird. Würde das die Sache vereinfachen, besonders was den DUMP angeht?
Wir sichern nur 1x Mittags und 1x Abends, wenn MO nicht verwendet wird. Würde das die Sache vereinfachen, besonders was den DUMP angeht?
Zitat von Christian Schnell am 16. Januar 2026, 10:28 UhrZitat von Johannes Neimann am 16. Januar 2026, 7:19 UhrNachfrage aus aktuellem Anlass:
Nach meinem Verständnis ist die sicherste Variante für eine wiederherstellbare MariaDB-Datenbank der Dump. Für den Dump wird aber das MariaDB-Kennwort benötigt. Das Kennwort soll aber – nach Auskunft meines Systemhauses auf Direktive von Indamed – den Kunden grundsätzlich nicht (mehr) zur Verfügung gestellt. Faktisch sind wir zahlenden Kunden also nicht mehr „Herr“ oder „Frau“ unserer eigenen Daten und vom Wohlwollen Indameds bzw. des Systemhauses abhängig.
Ich bin also auch hinsichtlich sicherer Backup- und Sicherungskonzepte stark eingeschränkt. Dazu bitte ich um eine offizielle Aussage eines Indamed-Offiziellen.
Das dieses Thema seit Ewigkeiten hochkocht und Indamed nichts sagt ist leider wirklich ungut.
Auf Ihr Passwort haben Sie aber Zugriff, es wird für jede Sicherung benötigt und steht im Sicherungsskript welches auf ihrem Server liegt. Bei uns heißt das Skript backupmariadb.cmd, dort steht das Passwort drin.
LG C.Schnell
Zitat von Johannes Neimann am 16. Januar 2026, 7:19 UhrNachfrage aus aktuellem Anlass:
Nach meinem Verständnis ist die sicherste Variante für eine wiederherstellbare MariaDB-Datenbank der Dump. Für den Dump wird aber das MariaDB-Kennwort benötigt. Das Kennwort soll aber – nach Auskunft meines Systemhauses auf Direktive von Indamed – den Kunden grundsätzlich nicht (mehr) zur Verfügung gestellt. Faktisch sind wir zahlenden Kunden also nicht mehr „Herr“ oder „Frau“ unserer eigenen Daten und vom Wohlwollen Indameds bzw. des Systemhauses abhängig.
Ich bin also auch hinsichtlich sicherer Backup- und Sicherungskonzepte stark eingeschränkt. Dazu bitte ich um eine offizielle Aussage eines Indamed-Offiziellen.
Das dieses Thema seit Ewigkeiten hochkocht und Indamed nichts sagt ist leider wirklich ungut.
Auf Ihr Passwort haben Sie aber Zugriff, es wird für jede Sicherung benötigt und steht im Sicherungsskript welches auf ihrem Server liegt. Bei uns heißt das Skript backupmariadb.cmd, dort steht das Passwort drin.
LG C.Schnell
Zitat von Jörg Sprenger, Kirchner, Müller am 16. Januar 2026, 11:05 UhrZitat von bro am 16. Januar 2026, 9:00 UhrWir sichern nur 1x Mittags und 1x Abends, wenn MO nicht verwendet wird. Würde das die Sache vereinfachen, besonders was den DUMP angeht?
Ja, insofern dann nicht mit ungesicherten Daten zwischen Beginn und Ende der Sicherung zu rechnen ist, außer Sie arbeiten an der DB in der Zeit.
Zitat von bro am 16. Januar 2026, 9:00 UhrWir sichern nur 1x Mittags und 1x Abends, wenn MO nicht verwendet wird. Würde das die Sache vereinfachen, besonders was den DUMP angeht?
Ja, insofern dann nicht mit ungesicherten Daten zwischen Beginn und Ende der Sicherung zu rechnen ist, außer Sie arbeiten an der DB in der Zeit.
Zitat von bro am 16. Januar 2026, 11:17 UhrSolange die Sicherung läuft, wird grundsätzlich nicht gearbeitet, also in der 13 Uhr Pause und nach Praxisende. Dann ist das beruhigend und es bleibt so, wie bei Firebird.
Solange die Sicherung läuft, wird grundsätzlich nicht gearbeitet, also in der 13 Uhr Pause und nach Praxisende. Dann ist das beruhigend und es bleibt so, wie bei Firebird.
Zitat von Thomas Schössow am 16. Januar 2026, 14:37 UhrZitat von Christian Schnell am 16. Januar 2026, 10:28 UhrBei uns heißt das Skript backupmariadb.cmd, dort steht das Passwort drin.
Sie machen selbst die Einschränkung „bei Ihnen“ -). Hier nicht und an den anderen 6 Standorten auch nicht -(
Zitat von Christian Schnell am 16. Januar 2026, 10:28 UhrBei uns heißt das Skript backupmariadb.cmd, dort steht das Passwort drin.
Sie machen selbst die Einschränkung „bei Ihnen“ -). Hier nicht und an den anderen 6 Standorten auch nicht -(
Zitat von Peter Quick am 16. Januar 2026, 18:05 UhrDas wäre ja wirklich ein Unding. Okay, ich hatte damals die Maria DB selbst aufgesetzt und habe damit selbstverständlich auch mein Passwort. Aber ich würde vor meinem First Level Service erwarten, dass er mir auf Anfrage das Passwort auch herausgibt. Und ich glaube, wer mit seinem FLS ein gutes Verhältnis hat, sollte das auch können.
zumindest würde ich dann mal gerne die Argumentation hören, warum das Passwort nicht herausgegeben werden kann, wenn der Kunde den Bedarf erklären kann und auch über ein gewisses Maß an technischen Verständnis verfügt. Ja, man kann sich seine Datenbank auch sehr schnell kaputt machen…
von daher wäre mein erster Schritt ein vernünftiges Gespräch mit meinem FLS… da sollte sich das Thema in Ruhe und Vernunft klären lassen.
Das wäre ja wirklich ein Unding. Okay, ich hatte damals die Maria DB selbst aufgesetzt und habe damit selbstverständlich auch mein Passwort. Aber ich würde vor meinem First Level Service erwarten, dass er mir auf Anfrage das Passwort auch herausgibt. Und ich glaube, wer mit seinem FLS ein gutes Verhältnis hat, sollte das auch können.
zumindest würde ich dann mal gerne die Argumentation hören, warum das Passwort nicht herausgegeben werden kann, wenn der Kunde den Bedarf erklären kann und auch über ein gewisses Maß an technischen Verständnis verfügt. Ja, man kann sich seine Datenbank auch sehr schnell kaputt machen…
von daher wäre mein erster Schritt ein vernünftiges Gespräch mit meinem FLS… da sollte sich das Thema in Ruhe und Vernunft klären lassen.