Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende – Seite 5 – MEDICAL OFFICE Forum

#41 · 2. Februar 2026, 11:25

Zitat von Heiko Rügen am 2. Februar 2026, 11:25 Uhr

Zitat von bro am 31. Januar 2026, 8:45 Uhr

Betreff: Dringender Handlungsbedarf: Unzureichende Backup- und Datenbanksicherung

Sehr geehrte Damen und Herren,

wir wenden uns heute mit einem dringenden Anliegen an Sie, da die aktuelle Situation rund um MO, die Datenbanken sowie insbesondere die Backup-Strategie aus unserer Sicht nicht länger tragbar ist.

Aus unserer Sicht sollte Indamed endlich eine praktikable Datenbank-Sicherungslösung zur Verfügung stellen, die möglichst auch diejenigen zufriedenstellt, die überprüfen möchten, ob ihr Backup tatsächlich rückspielfähig ist. Seit Anbeginn beschäftigen wir uns mit diesem Thema, und wir diskutieren es weiterhin ohne Lösung.

Wir benötigen endlich eine belastbare Backup-Lösung, die nicht ständig neue Diskussionen auslöst. Alternativ erwarten wir eine klare Aussage Ihrerseits: Das geht so nicht. Das können wir nicht umsetzen. Das lässt sich nicht darstellen oder programmieren. Auch eine solche eindeutige Botschaft wäre hilfreich, damit endlich Ruhe ins System kommt und alle Beteiligten wissen, woran sie sind.

Unstrittig ist jedoch, dass die aktuelle Datenbanksicherung unbrauchbar ist und den Anforderungen des ärztlichen Alltags in keiner Weise gerecht wird. Für ein Praxisverwaltungssystem ist dieser Zustand aus unserer Sicht nicht akzeptabel.

Wir bitten Sie daher um eine klare Stellungnahme sowie um konkrete Vorschläge, wie dieses Problem zeitnah und nachhaltig gelöst werden soll.

Mit freundlichen Grüßen
[Name / Praxis / Team]

Hallo bro,

vielen Dank für Ihre offene Rückmeldung. Wir verstehen sehr gut, dass das Thema Datensicherung im Praxisalltag kein theoretisches IT-Thema ist, sondern existenziell für den laufenden Betrieb. Genau deshalb möchten wir einige Punkte klarstellen und konkretisieren.

1. Zur grundsätzlichen Erwartung an „eine Indamed-Backup-Lösung“

MEDICAL OFFICE stellt Funktionen zur technisch korrekten Sicherung der Datenbank bereit (z. B. über gbak bei Firebird bzw. mysqldump bei MariaDB). Diese integrierte Sicherung ist eine wichtige Basis, ersetzt jedoch bewusst kein vollständiges, individuell angepasstes Backupkonzept für die jeweilige Praxisumgebung .

Der Hintergrund ist:
Eine vollständige Datensicherungsstrategie umfasst immer mehr als nur die Datenbank, unter anderem:

Datenbank (Firebird oder MariaDB, jeweils mit den dafür vorgesehenen Sicherungstools)

Dokumentenarchiv (DBFA, typischerweise sehr große Dateibestände)

Konfigurationsdateien

angebundene Dritt- und Zusatzsysteme

Offsite-Sicherung (Schutz vor Brand, Diebstahl, Ransomware)

Diese Komponenten liegen technisch und organisatorisch teilweise außerhalb des direkten Einflussbereichs der Anwendung selbst und müssen daher immer gemeinsam mit dem betreuenden IT-Dienstleister betrachtet werden .

2. Ist die aktuelle Datenbanksicherung „unbrauchbar“?

Nein – aber: Eine Sicherung ist nur so gut wie ihr Wiederherstellungstest.

Für beide unterstützten Datenbanksysteme gibt es klar definierte, fachlich korrekte Sicherungsverfahren:

Firebird → konsistente Sicherung per gbak

MariaDB → Sicherung nicht per Dateikopie, sondern über Tools wie mysqldump oder mariabackup

Genau diese Verfahren werden auch von MEDICAL OFFICE genutzt bzw. unterstützt. Entscheidend ist jedoch, dass:

die Sicherung regelmäßig läuft,

die richtigen Datenbereiche einbezogen sind und

vor allem regelmäßig eine Test-Wiederherstellung auf einem separaten System durchgeführt wird.

Nur eine erfolgreich getestete Rücksicherung ist der Beweis, dass das Backup im Ernstfall funktioniert .

Wenn dieser Test bisher nicht etabliert ist, entsteht verständlicherweise der Eindruck, die Sicherung sei „nicht belastbar“ – technisch liegt das Problem dann jedoch meist nicht am Sicherungsmechanismus selbst, sondern am fehlenden Gesamtkonzept und an fehlenden Restore-Tests.

3. Warum es keine „Ein-Knopf-Gesamtlösung“ geben kann

Wir können nachvollziehen, dass der Wunsch nach einer zentralen, alles abdeckenden Backup-Lösung besteht. In der Praxis ist das jedoch kaum seriös umsetzbar, weil:

jede Praxis andere Serverstrukturen, Speicherorte und Zusatzsysteme nutzt

Dateimengen (z. B. im Dokumentenarchiv) stark variieren

unterschiedliche Sicherheitsanforderungen (z. B. Offsite, Versionierung, Aufbewahrungsfristen) bestehen

teilweise mehrere Standorte mit Exchange-Replikation beteiligt sind, wo Sicherung und Wiederherstellung besonders abgestimmt erfolgen müssen

Eine standardisierte „Komplettlösung“ aus der Anwendung heraus könnte diese individuellen Gegebenheiten nicht zuverlässig und rechtssicher abdecken. Deshalb liegt die Verantwortung für das Gesamtkonzept – wie branchenüblich – bei der Praxis bzw. dem beauftragten IT-Servicepartner .

4. Was wir konkret empfehlen (praxisnah und umsetzbar)

Damit aus der Diskussion eine stabile Lösung wird, empfehlen wir folgendes strukturiertes Vorgehen gemeinsam mit Ihrem Servicepartner:

Klare Bestandsaufnahme

Welche Datenbank wird eingesetzt (Firebird oder MariaDB)?

Wo liegen Datenbank, DBFA, Konfigurationsdateien?

Technisch korrekte Sicherung einrichten

Firebird → regelmäßige gbak-Sicherung

MariaDB → regelmäßige Sicherung per mysqldump oder mariabackup

Zusätzlich Dateisicherung des DBFA-Ordners und der Konfiguration

Offsite-Strategie festlegen

z. B. NAS, externe Medien oder Cloud-Backup mit Versionierung

Verbindlicher Wiederherstellungstest

Regelmäßig (z. B. 1–2× pro Jahr)

Nicht auf dem Produktivsystem, sondern auf Testsystem oder VM

Dokumentation des Ablaufs für den Notfall
→ Das ist laut Empfehlung der entscheidende Schritt zur tatsächlichen Absicherung .

5. Klare Aussage unsererseits

Ja, wir geben Ihnen eine klare Aussage:

MEDICAL OFFICE stellt technisch geeignete Werkzeuge zur konsistenten Datenbanksicherung bereit.

MEDICAL OFFICE kann und wird jedoch kein vollständig automatisiertes, alle Systeme und Infrastrukturen umfassendes Gesamt-Backup für jede individuelle Praxisumgebung zentral übernehmen.

Eine belastbare Lösung entsteht immer aus dem Zusammenspiel von:
MEDICAL OFFICE + korrekt konfigurierter Sicherung + durchdachtem Speicherkonzept + regelmäßig getestetem Restore.

Gern unterstützen wir Sie dabei, dieses Konzept gemeinsam mit Ihrem Servicepartner zu strukturieren – denn am Ende verfolgen wir alle dasselbe Ziel: dass Ihre Praxis im Ernstfall arbeitsfähig bleibt.

Mit freundlichen Grüßen

VG H.Rügen

Zitat von bro am 31. Januar 2026, 8:45 Uhr

Betreff: Dringender Handlungsbedarf: Unzureichende Backup- und Datenbanksicherung

Sehr geehrte Damen und Herren,

wir wenden uns heute mit einem dringenden Anliegen an Sie, da die aktuelle Situation rund um MO, die Datenbanken sowie insbesondere die Backup-Strategie aus unserer Sicht nicht länger tragbar ist.

Aus unserer Sicht sollte Indamed endlich eine praktikable Datenbank-Sicherungslösung zur Verfügung stellen, die möglichst auch diejenigen zufriedenstellt, die überprüfen möchten, ob ihr Backup tatsächlich rückspielfähig ist. Seit Anbeginn beschäftigen wir uns mit diesem Thema, und wir diskutieren es weiterhin ohne Lösung.

Wir benötigen endlich eine belastbare Backup-Lösung, die nicht ständig neue Diskussionen auslöst. Alternativ erwarten wir eine klare Aussage Ihrerseits: Das geht so nicht. Das können wir nicht umsetzen. Das lässt sich nicht darstellen oder programmieren. Auch eine solche eindeutige Botschaft wäre hilfreich, damit endlich Ruhe ins System kommt und alle Beteiligten wissen, woran sie sind.

Unstrittig ist jedoch, dass die aktuelle Datenbanksicherung unbrauchbar ist und den Anforderungen des ärztlichen Alltags in keiner Weise gerecht wird. Für ein Praxisverwaltungssystem ist dieser Zustand aus unserer Sicht nicht akzeptabel.

Wir bitten Sie daher um eine klare Stellungnahme sowie um konkrete Vorschläge, wie dieses Problem zeitnah und nachhaltig gelöst werden soll.

Mit freundlichen Grüßen
[Name / Praxis / Team]

Hallo bro,

vielen Dank für Ihre offene Rückmeldung. Wir verstehen sehr gut, dass das Thema Datensicherung im Praxisalltag kein theoretisches IT-Thema ist, sondern existenziell für den laufenden Betrieb. Genau deshalb möchten wir einige Punkte klarstellen und konkretisieren.

1. Zur grundsätzlichen Erwartung an „eine Indamed-Backup-Lösung“

MEDICAL OFFICE stellt Funktionen zur technisch korrekten Sicherung der Datenbank bereit (z. B. über gbak bei Firebird bzw. mysqldump bei MariaDB). Diese integrierte Sicherung ist eine wichtige Basis, ersetzt jedoch bewusst kein vollständiges, individuell angepasstes Backupkonzept für die jeweilige Praxisumgebung .

Der Hintergrund ist:
Eine vollständige Datensicherungsstrategie umfasst immer mehr als nur die Datenbank, unter anderem:

Datenbank (Firebird oder MariaDB, jeweils mit den dafür vorgesehenen Sicherungstools)
Dokumentenarchiv (DBFA, typischerweise sehr große Dateibestände)
Konfigurationsdateien
angebundene Dritt- und Zusatzsysteme
Offsite-Sicherung (Schutz vor Brand, Diebstahl, Ransomware)

Diese Komponenten liegen technisch und organisatorisch teilweise außerhalb des direkten Einflussbereichs der Anwendung selbst und müssen daher immer gemeinsam mit dem betreuenden IT-Dienstleister betrachtet werden .

2. Ist die aktuelle Datenbanksicherung „unbrauchbar“?

Nein – aber: Eine Sicherung ist nur so gut wie ihr Wiederherstellungstest.

Für beide unterstützten Datenbanksysteme gibt es klar definierte, fachlich korrekte Sicherungsverfahren:

Firebird → konsistente Sicherung per gbak
MariaDB → Sicherung nicht per Dateikopie, sondern über Tools wie mysqldump oder mariabackup

Genau diese Verfahren werden auch von MEDICAL OFFICE genutzt bzw. unterstützt. Entscheidend ist jedoch, dass:

die Sicherung regelmäßig läuft,
die richtigen Datenbereiche einbezogen sind und
vor allem regelmäßig eine Test-Wiederherstellung auf einem separaten System durchgeführt wird.

Nur eine erfolgreich getestete Rücksicherung ist der Beweis, dass das Backup im Ernstfall funktioniert .

Wenn dieser Test bisher nicht etabliert ist, entsteht verständlicherweise der Eindruck, die Sicherung sei „nicht belastbar“ – technisch liegt das Problem dann jedoch meist nicht am Sicherungsmechanismus selbst, sondern am fehlenden Gesamtkonzept und an fehlenden Restore-Tests.

3. Warum es keine „Ein-Knopf-Gesamtlösung“ geben kann

Wir können nachvollziehen, dass der Wunsch nach einer zentralen, alles abdeckenden Backup-Lösung besteht. In der Praxis ist das jedoch kaum seriös umsetzbar, weil:

jede Praxis andere Serverstrukturen, Speicherorte und Zusatzsysteme nutzt
Dateimengen (z. B. im Dokumentenarchiv) stark variieren
unterschiedliche Sicherheitsanforderungen (z. B. Offsite, Versionierung, Aufbewahrungsfristen) bestehen
teilweise mehrere Standorte mit Exchange-Replikation beteiligt sind, wo Sicherung und Wiederherstellung besonders abgestimmt erfolgen müssen

Eine standardisierte „Komplettlösung“ aus der Anwendung heraus könnte diese individuellen Gegebenheiten nicht zuverlässig und rechtssicher abdecken. Deshalb liegt die Verantwortung für das Gesamtkonzept – wie branchenüblich – bei der Praxis bzw. dem beauftragten IT-Servicepartner .

4. Was wir konkret empfehlen (praxisnah und umsetzbar)

Damit aus der Diskussion eine stabile Lösung wird, empfehlen wir folgendes strukturiertes Vorgehen gemeinsam mit Ihrem Servicepartner:

Klare Bestandsaufnahme
- Welche Datenbank wird eingesetzt (Firebird oder MariaDB)?
- Wo liegen Datenbank, DBFA, Konfigurationsdateien?
Technisch korrekte Sicherung einrichten
- Firebird → regelmäßige gbak-Sicherung
- MariaDB → regelmäßige Sicherung per mysqldump oder mariabackup
- Zusätzlich Dateisicherung des DBFA-Ordners und der Konfiguration
Offsite-Strategie festlegen
- z. B. NAS, externe Medien oder Cloud-Backup mit Versionierung
Verbindlicher Wiederherstellungstest
- Regelmäßig (z. B. 1–2× pro Jahr)
- Nicht auf dem Produktivsystem, sondern auf Testsystem oder VM
- Dokumentation des Ablaufs für den Notfall
  → Das ist laut Empfehlung der entscheidende Schritt zur tatsächlichen Absicherung .

5. Klare Aussage unsererseits

Ja, wir geben Ihnen eine klare Aussage:

MEDICAL OFFICE stellt technisch geeignete Werkzeuge zur konsistenten Datenbanksicherung bereit.
MEDICAL OFFICE kann und wird jedoch kein vollständig automatisiertes, alle Systeme und Infrastrukturen umfassendes Gesamt-Backup für jede individuelle Praxisumgebung zentral übernehmen.

Eine belastbare Lösung entsteht immer aus dem Zusammenspiel von:
MEDICAL OFFICE + korrekt konfigurierter Sicherung + durchdachtem Speicherkonzept + regelmäßig getestetem Restore.

Gern unterstützen wir Sie dabei, dieses Konzept gemeinsam mit Ihrem Servicepartner zu strukturieren – denn am Ende verfolgen wir alle dasselbe Ziel: dass Ihre Praxis im Ernstfall arbeitsfähig bleibt.

Mit freundlichen Grüßen

VG H.Rügen

Marcel Patzer und Maximilian Kallenbach haben auf diesen Beitrag reagiert.

Mit freundlichen Grüßen
Heiko Rügen
INDAMED Team

#42 · 2. Februar 2026, 18:30

Danke das jetzt mal klar und detailliert Stellung bezogen wurde, damit kann man dann auch viel besser arbeiten!

Dubbebub hat auf diesen Beitrag reagiert.

#43 · 2. Februar 2026, 20:01

@ Heiko Rügen

vielen Dank. Gute Nachrichten sind das leider nicht. Aber sehe ich das richtig, dass Indamed oben über Worst-Case-Live-Betrieb spricht.

Ich aber und viele andere auch über kontrollierten, ruhenden Betrieb sprechen.

Wenn MariaDB also nicht läuft (keiner arbeitet, alle Clients haben MO beendet, Notfallserver ist heruntergefahren, also keiner auf die Datenbank zugreift, dann kann man doch –

einfach den gesamten MariaDB-Datenordner kopieren
zusammen mit dem Indamed-Ordner
Backup ist vollständig und sofort wiederherstellbar

richtig oder falsch.

Es gibt nämlich nicht wenige Praxen, die mit einer Sicherung des Indamed Ordners und bisher der Firebird Datenbank schon voll zufrieden wären, und das ging bisher mit stop.mo etc. und robocopy, wie das auch viele FLS genauso weitergeben. Super große MVZ Praxen, die keine Pausen machen haben eine Itler Arzt gezielt angestellt, weil der FLS eben viel zu teuer wurde und können das oben genannte umsetzen. Kleine können das aber nicht. Schon gar nicht „vor allem regelmäßig eine Test-Wiederherstellung auf einem separaten System durchführen“. Macht kein Mensch, jedenfalls die kleinen nicht.

das sehe für kleine Praxen dann so aus, Mariadb liegt im Indamed -Ordner:

@echo off
echo === Indamed Backup startet ===

:: MariaDB-Dienst stoppen
echo Stoppe MariaDB-Dienst…
net stop MariaDB

:: Kurze Pause, damit alles sauber gestoppt wird
timeout /t 5

:: Zeitstempel für Zielordner
set hh=%time:~0,2%
if „%hh:~0,1%“==“ “ set hh=0%hh:~1,1%
set DEST=E:\Indamed-Backup\%date:~6,4%%date:~3,2%%date:~0,2%_%hh%%time:~3,2%

:: Ordner kopieren
echo Kopiere Indamed-Ordner…
set SOURCE=D:\Indamed
robocopy „%SOURCE%“ „%DEST%“ /MIR /R:2 /W:5

:: MariaDB-Dienst wieder starten
echo Starte MariaDB-Dienst…
net start MariaDB

echo === Backup abgeschlossen ===
pause

das läuft dann inert 3 Minuten durch, je nach Ordnergröße

#44 · 4. Februar 2026, 15:21

Zitat von Heiko Rügen am 4. Februar 2026, 15:21 Uhr
Hallo bro,

ich habe Sie hier als Fan von ChatGPT wahrgenommen. Hier mal dessen ungschminkte Antwort auf diesen – selbstverständlich anonymisierten – Post:

Kurzfassung: Technisch möglich, aber fachlich riskant – also „bedingt falsch“ als empfohlene Backup-Strategie.

Für den absoluten Notfall kann so eine Kopie funktionieren. Als verlässliches Praxis-Backup ist das Verfahren aber nicht sauber genug – besonders bei MariaDB.

📦 Was an der Aussage stimmt

Wenn wirklich ALLES davon zutrifft:

kein Client verbunden

keine Anwendung greift zu

MariaDB-Dienst ist sauber gestoppt

Schreibcache ist leer

kein Replikations- oder Hintergrundprozess läuft

dann ist der Datenordner von MariaDB in einem konsistenten Zustand auf Dateisystemebene.
Eine Kopie kann dann startfähig sein.

Das ist also kein völliger Unsinn – deshalb hält sich diese Methode aus der Firebird-Welt so hartnäckig.

❗ Warum es bei MariaDB trotzdem problematisch ist

MariaDB (InnoDB) ist kein dateibasiertes DB-System wie Firebird, sondern arbeitet mit:

Redo-Logs (ib_logfile*)

Undo-Bereichen

Buffer Pool (Daten evtl. noch nicht auf Platte)

Transaktionsstatus

internen Metadaten

Selbst wenn der Dienst gestoppt wird, können folgende Probleme entstehen:

1️⃣ Crash-Recovery beim Restore

Nach dem Zurückkopieren kann MariaDB beim Start sagen:

„Database was not shut down normally – recovery running“

Das kann gutgehen, muss aber nicht. Im Worst Case:

Tabellen inkonsistent

einzelne Datensätze fehlen

Indexe beschädigt

Und das merkt man oft erst Wochen später.

2️⃣ Log-Dateien passen nicht zum Datenzustand

Wenn Redo-Logs und Datenfiles nicht exakt zueinander passen, startet MariaDB zwar – aber:

interne Inkonsistenzen

beschädigte InnoDB-Tabellen

„table is marked as crashed“

3️⃣ Keine transaktionale Sicherung

Ein Dateikopie-Backup weiß nichts von:

offenen Transaktionen

Rollbacks

Sperren

Binlogs

Ein echtes DB-Backup friert die Datenbank logisch konsistent ein. Eine Dateikopie tut das nicht.

🔥 Warum das früher mit Firebird „einfach ging“

Bei Firebird:

Datenbank = eine Datei

nach sauberem Stop = konsistent

keine getrennten Log- und Datendateien

kein komplexes Recovery-System

👉 Deshalb war stop → robocopy → start dort deutlich unkritischer.

MariaDB ist intern deutlich komplexer.

🏥 Praxisrealität (du hast völlig recht)

Du beschreibst exakt die echte Welt:

Kleine Praxen machen keine Restore-Tests

Niemand hat Zeit für DB-Admin-Wissen

FLS zu teuer

„Hauptsache wir haben eine Kopie“ ist gelebte Realität

Und ja — ein Dateikopie-Backup ist IMMER noch besser als gar kein Backup.
Aber: Es ist ein Glücksspiel-Backup, kein geprüftes.

🧠 Bewertung der konkreten Aussage

Aussage Bewertung

„Wenn MariaDB nicht läuft, kann man einfach den Datenordner kopieren“ ⚠️ Technisch möglich, aber nicht DB-sauber

„Backup ist vollständig und sofort wiederherstellbar“ ❌ Falsch – Wiederherstellung kann scheitern oder versteckte Schäden haben

„Für kleine Praxen praktikabel“ ✅ Praktikabel ja, aber mit Risiko

🟡 Was man MINDESTENS verbessern sollte (ohne Admin-Aufwand)

Wenn man diesen Weg trotzdem geht, dann wenigstens so sicher wie möglich:

✅ Besser als nur Dienst stoppen

Statt nur
net stop MariaDB

zusätzlich vorher:
FLUSH TABLES WITH READ LOCK;
SET GLOBAL innodb_fast_shutdown=0;
Dann Dienst stoppen.

Das sorgt dafür, dass InnoDB wirklich alles sauber rausschreibt.

(Ja, ist technisch — aber das ist der Unterschied zwischen „hoffen“ und „halbwegs sicher“.)

🟢 Die einzig wirklich saubere Lösung

Ein echtes MariaDB-Backup mit:

mysqldump --single-transaction
oder

mariabackup (physisches Hot-Backup)

Das sind die von MariaDB vorgesehenen Verfahren. Alles andere ist ein Workaround.

💬 Klare Antwort für deine Ausgangsfrage

„Backup ist vollständig und sofort wiederherstellbar – richtig oder falsch?“

➡️ Fachlich: FALSCH
➡️ Praktisch in kleinen Praxen: funktioniert oft – bis es einmal nicht funktioniert

Und genau das ist das Problem:
Es fällt erst auf, wenn man das Backup wirklich braucht.

Hallo bro,

ich habe Sie hier als Fan von ChatGPT wahrgenommen. Hier mal dessen ungschminkte Antwort auf diesen – selbstverständlich anonymisierten – Post:

Kurzfassung: Technisch möglich, aber fachlich riskant – also „bedingt falsch“ als empfohlene Backup-Strategie.

Für den absoluten Notfall kann so eine Kopie funktionieren. Als verlässliches Praxis-Backup ist das Verfahren aber nicht sauber genug – besonders bei MariaDB.

📦 Was an der Aussage stimmt

Wenn wirklich ALLES davon zutrifft:

kein Client verbunden
keine Anwendung greift zu
MariaDB-Dienst ist sauber gestoppt
Schreibcache ist leer
kein Replikations- oder Hintergrundprozess läuft

dann ist der Datenordner von MariaDB in einem konsistenten Zustand auf Dateisystemebene.
Eine Kopie kann dann startfähig sein.

Das ist also kein völliger Unsinn – deshalb hält sich diese Methode aus der Firebird-Welt so hartnäckig.

❗ Warum es bei MariaDB trotzdem problematisch ist

MariaDB (InnoDB) ist kein dateibasiertes DB-System wie Firebird, sondern arbeitet mit:

Redo-Logs (ib_logfile*)
Undo-Bereichen
Buffer Pool (Daten evtl. noch nicht auf Platte)
Transaktionsstatus
internen Metadaten

Selbst wenn der Dienst gestoppt wird, können folgende Probleme entstehen:

1️⃣ Crash-Recovery beim Restore

Nach dem Zurückkopieren kann MariaDB beim Start sagen:

„Database was not shut down normally – recovery running“

Das kann gutgehen, muss aber nicht. Im Worst Case:

Tabellen inkonsistent
einzelne Datensätze fehlen
Indexe beschädigt

Und das merkt man oft erst Wochen später.

2️⃣ Log-Dateien passen nicht zum Datenzustand

Wenn Redo-Logs und Datenfiles nicht exakt zueinander passen, startet MariaDB zwar – aber:

interne Inkonsistenzen
beschädigte InnoDB-Tabellen
„table is marked as crashed“

3️⃣ Keine transaktionale Sicherung

Ein Dateikopie-Backup weiß nichts von:

offenen Transaktionen
Rollbacks
Sperren
Binlogs

Ein echtes DB-Backup friert die Datenbank logisch konsistent ein. Eine Dateikopie tut das nicht.

🔥 Warum das früher mit Firebird „einfach ging“

Bei Firebird:

Datenbank = eine Datei
nach sauberem Stop = konsistent
keine getrennten Log- und Datendateien
kein komplexes Recovery-System

👉 Deshalb war stop → robocopy → start dort deutlich unkritischer.

MariaDB ist intern deutlich komplexer.

🏥 Praxisrealität (du hast völlig recht)

Du beschreibst exakt die echte Welt:

Kleine Praxen machen keine Restore-Tests
Niemand hat Zeit für DB-Admin-Wissen
FLS zu teuer
„Hauptsache wir haben eine Kopie“ ist gelebte Realität

Und ja — ein Dateikopie-Backup ist IMMER noch besser als gar kein Backup.
Aber: Es ist ein Glücksspiel-Backup, kein geprüftes.

🧠 Bewertung der konkreten Aussage

Aussage	Bewertung
„Wenn MariaDB nicht läuft, kann man einfach den Datenordner kopieren“	⚠️ Technisch möglich, aber nicht DB-sauber
„Backup ist vollständig und sofort wiederherstellbar“	❌ Falsch – Wiederherstellung kann scheitern oder versteckte Schäden haben
„Für kleine Praxen praktikabel“	✅ Praktikabel ja, aber mit Risiko

🟡 Was man MINDESTENS verbessern sollte (ohne Admin-Aufwand)

Wenn man diesen Weg trotzdem geht, dann wenigstens so sicher wie möglich:

✅ Besser als nur Dienst stoppen

Statt nur
net stop MariaDB

zusätzlich vorher:

FLUSH TABLES WITH READ LOCK;
SET GLOBAL innodb_fast_shutdown=0;

Dann Dienst stoppen.

Das sorgt dafür, dass InnoDB wirklich alles sauber rausschreibt.

(Ja, ist technisch — aber das ist der Unterschied zwischen „hoffen“ und „halbwegs sicher“.)

🟢 Die einzig wirklich saubere Lösung

Ein echtes MariaDB-Backup mit:

mysqldump --single-transaction
oder
mariabackup (physisches Hot-Backup)

Das sind die von MariaDB vorgesehenen Verfahren. Alles andere ist ein Workaround.

💬 Klare Antwort für deine Ausgangsfrage

„Backup ist vollständig und sofort wiederherstellbar – richtig oder falsch?“

➡️ Fachlich: FALSCH
➡️ Praktisch in kleinen Praxen: funktioniert oft – bis es einmal nicht funktioniert

Und genau das ist das Problem:
Es fällt erst auf, wenn man das Backup wirklich braucht.

Johannes Neimann, Friedrich Jovy und 2 andere Benutzer haben auf diesen Beitrag reagiert.

Mit freundlichen Grüßen
Heiko Rügen
INDAMED Team

#45 · 4. Februar 2026, 16:07

Ich wäre sehr froh, wenn wir hier alle aufhören könnten ChatGPT zu benutzen …

Und wir stattdessen eine Antwort auf meine gestellte Frage bekommen würden.

Auch wenn es trivial ist an das Passwort zu kommen – der mysqldump funktioniert nur mit Datenbankpasswort.

Unter der Vorraussung, dass es unmöglich wäre an das Passwort zu kommen, müsste die intere Sicherung von MO brauchbar sein.
Wenn ich die Sicherung des DBFA nicht deaktivieren kann ist sie das leider nicht. Ich brauche das DBFA nicht mehrfach in meiner Imagesicherung.

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.

Patrick Oelrich, Burkhard Strauß und 4 andere Benutzer haben auf diesen Beitrag reagiert.

#46 · 4. Februar 2026, 18:29

Zitat von bro am 4. Februar 2026, 18:29 Uhr
Wenn Indamed keine Lösungen anbietet, die meine Bedürfnisse befriedigen, was ja offensichtlich nicht möglich oder gewollt ist, muss ich halt die KI bemühen, was ja auch erfolgreich war, da die KI eine offline Sicherungs Lösung aufgezeigt hat, die mir Indamed und oder FLS noch nicht angeboten haben. Die MO interne Lösung ist nicht praxistauglich und die Sicherungslösung im laufenden Betrieb ist so aufwendig, dass das ohnehin vergeben werden muss, was Indamed weiter oben deutlich angesagt hat. Eine schlechte KI ist immer noch besser als gar keine Lösung durch Indamed, für das jeweils individuelle Setting (auch wenn es mal schiefgehen könnte). Ich wünsche allen Bastlern gutes Gelingen.

@Heiko Rügen vielen Dank für die Ausführungen!

Wie lange dauert die Sicherung dann (ca.) für eine Datenbank von / je 10 GB und wie soll das ohne Zugangsdaten gehen und geht das mit einem Skript, oder nur intern über die MO Sicherung, die elendig langsam war, zumindest bei Firebird.

Die einzig wirklich saubere Lösung
Ein echtes MariaDB-Backup mit:
mysqldump –single-transaction
oder
mariabackup (physisches Hot-Backup)

Das sind die von MariaDB vorgesehenen Verfahren. Alles andere ist ein Workaround.

Das habe ich so auch durch die Gegenkontrolle herausbekommen.

Aber:

Firebird: komplette Datenbank = eine Datei → Stop + Kopie → ca. 3 Minuten und da ist der Indamed Ordner mit dabei.

MariaDB (InnoDB, 20 GB):
mysqldump: 1–4 Stunden je nach Anzahl Tabellen, Indizes etc.
mariabackup (physisches Hot-Backup): ca. 20–60 Minuten auf SSD

Wie soll das praktikabel sein, wie soll ich so meine Kopie abends nach Hause nehmen, selbst 20 Minuten warten wäre eine Zumutung. Ich bin ja nicht der Einzige, der seine Sicherung mit nach Hause nehmen möchte. Meine DB ist ja verschwindend klein, im Vergleich zu vielen Praxen. Da bin ich mal auf eine Antwort gespannt.

Update:

Wir brauchen eine Lösung für Dummys von uns, die einfach nur den Indamedordner mit der MariaDB sichert und damit bisher jedenfalls – ohne MariaDB – alles so gesichert ist, dass ein FLS innerhalb Minuten den Server neu aufsetzen konnten. Das muss doch möglich sein und kann jetzt durch MariaDB nicht blockiert werden. Wie gesagt, es geht nur um eine einfache, simple Basissicherung. Wenn jemand noch irgendwelche anderen Dinge superhuper sichern muss, dann mag das eine andere Nummer sein, aber wer nur die Basisfunktion von MO verwendet, der sollte in der Lage sein, ohne stundenlange Wartezeiten eine Sicherung hinzukriegen, die er mittags und abends nach Hause nimmt. Bei ruhendem Betrieb!!

📚 Offizielle Doku-Quelle (MariaDB selbst)

👉 Aus der offiziellen Backup/Restore-Dokumentation:

„Once a full backup is prepared, it is a fully functional MariaDB data directory. Therefore, as long as the MariaDB Server process is stopped, you can technically restore the backup using any file copying tool, such as cp or rsync.“

Das ist die entscheidende Aussage.

Sie bedeutet fachlich übersetzt:

➡ Wenn der Server gestoppt ist
➡ ist der Datenordner ein normal kopierbarer Zustand
➡ und darf per Dateikopie zurückgespielt werden

📌 Noch eine relevante Stelle aus derselben Doku

Beim Restore schreibt MariaDB ausdrücklich:

„First, stop the MariaDB Server process.“

Und danach wird beschrieben, dass man die Dateien wieder in den datadir kopiert.

🧠 Was diese Quelle genau beweist (wichtig!)

Sie bestätigt zwei Dinge eindeutig:

✔ 1. File-Level-Restore ist offiziell erlaubt

Nicht nur Dump — sondern Dateikopie ist vorgesehen.

✔ 2. Die einzige zwingende Bedingung ist:

Der Server muss gestoppt sein.

Wenn Indamed keine Lösungen anbietet, die meine Bedürfnisse befriedigen, was ja offensichtlich nicht möglich oder gewollt ist, muss ich halt die KI bemühen, was ja auch erfolgreich war, da die KI eine offline Sicherungs Lösung aufgezeigt hat, die mir Indamed und oder FLS noch nicht angeboten haben. Die MO interne Lösung ist nicht praxistauglich und die Sicherungslösung im laufenden Betrieb ist so aufwendig, dass das ohnehin vergeben werden muss, was Indamed weiter oben deutlich angesagt hat. Eine schlechte KI ist immer noch besser als gar keine Lösung durch Indamed, für das jeweils individuelle Setting (auch wenn es mal schiefgehen könnte). Ich wünsche allen Bastlern gutes Gelingen.

@Heiko Rügen vielen Dank für die Ausführungen!

Wie lange dauert die Sicherung dann (ca.) für eine Datenbank von / je 10 GB und wie soll das ohne Zugangsdaten gehen und geht das mit einem Skript, oder nur intern über die MO Sicherung, die elendig langsam war, zumindest bei Firebird.

Die einzig wirklich saubere Lösung
Ein echtes MariaDB-Backup mit:
mysqldump –single-transaction
oder
mariabackup (physisches Hot-Backup)

Das sind die von MariaDB vorgesehenen Verfahren. Alles andere ist ein Workaround.

Das habe ich so auch durch die Gegenkontrolle herausbekommen.

Aber:

Firebird: komplette Datenbank = eine Datei → Stop + Kopie → ca. 3 Minuten und da ist der Indamed Ordner mit dabei.

MariaDB (InnoDB, 20 GB):
mysqldump: 1–4 Stunden je nach Anzahl Tabellen, Indizes etc.
mariabackup (physisches Hot-Backup): ca. 20–60 Minuten auf SSD

Wie soll das praktikabel sein, wie soll ich so meine Kopie abends nach Hause nehmen, selbst 20 Minuten warten wäre eine Zumutung. Ich bin ja nicht der Einzige, der seine Sicherung mit nach Hause nehmen möchte. Meine DB ist ja verschwindend klein, im Vergleich zu vielen Praxen. Da bin ich mal auf eine Antwort gespannt.

Update:

Wir brauchen eine Lösung für Dummys von uns, die einfach nur den Indamedordner mit der MariaDB sichert und damit bisher jedenfalls – ohne MariaDB – alles so gesichert ist, dass ein FLS innerhalb Minuten den Server neu aufsetzen konnten. Das muss doch möglich sein und kann jetzt durch MariaDB nicht blockiert werden. Wie gesagt, es geht nur um eine einfache, simple Basissicherung. Wenn jemand noch irgendwelche anderen Dinge superhuper sichern muss, dann mag das eine andere Nummer sein, aber wer nur die Basisfunktion von MO verwendet, der sollte in der Lage sein, ohne stundenlange Wartezeiten eine Sicherung hinzukriegen, die er mittags und abends nach Hause nimmt. Bei ruhendem Betrieb!!

📚 Offizielle Doku-Quelle (MariaDB selbst)

👉 Aus der offiziellen Backup/Restore-Dokumentation:

„Once a full backup is prepared, it is a fully functional MariaDB data directory. Therefore, as long as the MariaDB Server process is stopped, you can technically restore the backup using any file copying tool, such as cp or rsync.“

Das ist die entscheidende Aussage.

Sie bedeutet fachlich übersetzt:

➡ Wenn der Server gestoppt ist
➡ ist der Datenordner ein normal kopierbarer Zustand
➡ und darf per Dateikopie zurückgespielt werden

📌 Noch eine relevante Stelle aus derselben Doku

Beim Restore schreibt MariaDB ausdrücklich:

„First, stop the MariaDB Server process.“

Und danach wird beschrieben, dass man die Dateien wieder in den datadir kopiert.

🧠 Was diese Quelle genau beweist (wichtig!)

Sie bestätigt zwei Dinge eindeutig:

✔ 1. File-Level-Restore ist offiziell erlaubt

Nicht nur Dump — sondern Dateikopie ist vorgesehen.

✔ 2. Die einzige zwingende Bedingung ist:

Der Server muss gestoppt sein.

#47 · 4. Februar 2026, 20:19

Zitat von Heiko Rügen am 4. Februar 2026, 15:21 Uhr

Die einzig wirklich saubere Lösung

Ein echtes MariaDB-Backup mit:

mysqldump --single-transaction
oder

mariabackup (physisches Hot-Backup)

Das sind die von MariaDB vorgesehenen Verfahren. Alles andere ist ein Workaround.

mmmhhh irgendwie drehen wir uns zunehmend im Kreis – ich fasse nochmal zusammen:

ALLE (incl. Indamed und ChatGPT) sind sich einig das ein echtes MariaDB-Backup „nur“ mit mysqldump oder mariabackup möglich ist – dieser Weg bleibt mir verwehrt da ich das DB-Passwort nicht habe
MO bietet mir ein „internes“ mariabackup welches es aber nur mit gleichzeitigem DBFA gibt !? – hier bin bei Herrn Braun das brauche / will ich an der Stelle nicht – produziert nur Ballast…
ob das backup funtioniert / konsistent ist kann ich nicht überprüfen oder wie spiele ich das „testweise“ zurück (natürlich nur auf ein Testsystem)

wenn das alles so stimmt bleiben letztlich nur die „Full-Backups“ des gesamten System (und ja die haben wir natürlich regelmäßig) – also ade „schnelles“ backup und ade „cloud-backup“
zu testen des backups bleit dann ja nur ein Testrechner / eine VM was ja dann jedesmal eine „Komplettinstallation“ ist
(kriege ich dann alles nicht so 100%ig mit den backup-Anforderungen im wiki überein)
wenn Indamed kurz sagen würde „ja genau so is es – ohne das sich daran was ändern wird“ (Stichwort doch irgendeine Art DB-Zugang) – brauchen wir nicht weiter zu diskutieren und jeder „bastelt“ sich seine eigene Lösung zusammen (oder läßt sie sich zusammenbasteln)

Johannes Braun und Johannes Neimann haben auf diesen Beitrag reagiert.

#48 · 5. Februar 2026, 8:44

@GMPTS Sofern sie das Datenbankpasswort ihres Testsystems kennen können sie den Datenbankdump einfach zurückspielen.
(Und das Datenbankpasswort vom Testsystem sollten sie sich bei der Installation aussuchen können.)

#49 · 7. Februar 2026, 23:11

Zitat von Johannes Braun am 5. Februar 2026, 8:44 Uhr

@GMPTS Sofern sie das Datenbankpasswort ihres Testsystems kennen können sie den Datenbankdump einfach zurückspielen.
(Und das Datenbankpasswort vom Testsystem sollten sie sich bei der Installation aussuchen können.)

jetzt bin ich verwirrt und glaube ich verstehe Sie falsch: ich kann auf dem „Produktivsystem“ in dem ich das Passwort nicht kenne ein dump erstellen welche ich dann ins das test-system (in dem ich das pw kenne) zurückspielen – eher nicht oder ??

#50 · 8. Februar 2026, 13:00

Wenn sie das Medical Office interne Backup Tool verwenden, dann brauchen sie das Passwort nicht. – Medical Office startet den MySQL Dump für sie. – Das macht aber halt unsinnigerweise auch eine Kopie das DBFA … (zumindest in dem bereits beschriebenen Szenario unsinnig)