Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Archiv- und Wechselschnittstelle, Verschlüsselte Datenbank, Software-Wechsel, Vertragsende
Zitat von GMPTS am 30. Januar 2026, 16:06 Uhrvieles (vielleicht auch alles) wurde schon gesagt aber eben noch nicht von jedem daher mein „Senf“ dazu:
ich kann verstehen das Indamed sein „geistiges EIgentum“ (den „Programmcode“) schützen will und auch das Argument mit dem o.g. „unkontrollierten“ Zugriffen von Drittprogrammen (ich meine zu wissen wer das war / ist und warum die mir nie ins Haus kommen – wir wollen garnicht wissen was die so alles abgreifen/abgegriffen haben) kann ich nachvollziehen
ABER:
keiner der derzeit (ohne Passwort) möglichen Wege ermöglicht es mir eine „zufriedenstellende“ Backupstrategie umszusetzen
Neben diversen (semi-)lokalen Backups des Gesamtsystems sichern wir essentielle Daten in eine „Cloud“ – aufgrund der Bandbreite etc. kann dies nur „inkrementell“ geschehen – unter firebird war es „kein Thema“ die Datenbank mit nbackup zu sperren (da während der Sperre alles in eine Delta geschriebben wurde konnte hier mit MO weitergearbeitet werden) – das backu zu fahren egal wie lange es läuft und dann die Datenbank wieder zu entsperren (natürlich alles per skript) – bei Maria würde mir ein dump „reichen“ kriege ich ohne passwort nicht.
Und nein die interne Datenscherung ist keine Alternative weil hier auch immer das DBFA (zumindest „act“) mitgesichert wird etc. etc. auch mit extra-Skripten wieder MO zu stoppen ist keine sinnvolle AlternativeAuch das o.g. „Datensicherungs-Wiki“ empfiehlt zurecht das es wohl Sinn macht die Wiederherstellung der Sicherung zu überprüfen / testen
– wie soll ich den das aus der MO-eigenen Sicherung entstande Backup testen – ich weiß nicht wie es zurückzuspielen soll
– auch wenn ich auf welchen umwegen auch immer ein „konsistentes“ backup der Datenbank erstellt habe kann ich es nur testen wenn ich mein System virtualisiere – die Datenbank in die MO-Demo zu „implantieren“ (wie im Wiki vorgeschlagen) scheitert mal wieder am fehlenden passwortmomentan „pfusch“ ich mir hier was zurecht was (derzeit) funktioniert … aber viel getrickse von hinten durchs Auge nach unten zum Fuss hoch zum Gehirn braucht
hier braucht es eine (individuell konfigurierbare, automisierbare) Lösung (Möglichkeiten wurden ja genannt) die aber nur von INDAMED realisiert werden können oder doch irgendeinen DB-Zugriff
vieles (vielleicht auch alles) wurde schon gesagt aber eben noch nicht von jedem daher mein „Senf“ dazu:
ich kann verstehen das Indamed sein „geistiges EIgentum“ (den „Programmcode“) schützen will und auch das Argument mit dem o.g. „unkontrollierten“ Zugriffen von Drittprogrammen (ich meine zu wissen wer das war / ist und warum die mir nie ins Haus kommen – wir wollen garnicht wissen was die so alles abgreifen/abgegriffen haben) kann ich nachvollziehen
ABER:
keiner der derzeit (ohne Passwort) möglichen Wege ermöglicht es mir eine „zufriedenstellende“ Backupstrategie umszusetzen
Neben diversen (semi-)lokalen Backups des Gesamtsystems sichern wir essentielle Daten in eine „Cloud“ – aufgrund der Bandbreite etc. kann dies nur „inkrementell“ geschehen – unter firebird war es „kein Thema“ die Datenbank mit nbackup zu sperren (da während der Sperre alles in eine Delta geschriebben wurde konnte hier mit MO weitergearbeitet werden) – das backu zu fahren egal wie lange es läuft und dann die Datenbank wieder zu entsperren (natürlich alles per skript) – bei Maria würde mir ein dump „reichen“ kriege ich ohne passwort nicht.
Und nein die interne Datenscherung ist keine Alternative weil hier auch immer das DBFA (zumindest „act“) mitgesichert wird etc. etc. auch mit extra-Skripten wieder MO zu stoppen ist keine sinnvolle Alternative
Auch das o.g. „Datensicherungs-Wiki“ empfiehlt zurecht das es wohl Sinn macht die Wiederherstellung der Sicherung zu überprüfen / testen
– wie soll ich den das aus der MO-eigenen Sicherung entstande Backup testen – ich weiß nicht wie es zurückzuspielen soll
– auch wenn ich auf welchen umwegen auch immer ein „konsistentes“ backup der Datenbank erstellt habe kann ich es nur testen wenn ich mein System virtualisiere – die Datenbank in die MO-Demo zu „implantieren“ (wie im Wiki vorgeschlagen) scheitert mal wieder am fehlenden passwort
momentan „pfusch“ ich mir hier was zurecht was (derzeit) funktioniert … aber viel getrickse von hinten durchs Auge nach unten zum Fuss hoch zum Gehirn braucht
hier braucht es eine (individuell konfigurierbare, automisierbare) Lösung (Möglichkeiten wurden ja genannt) die aber nur von INDAMED realisiert werden können oder doch irgendeinen DB-Zugriff
Zitat von Peter Quick am 31. Januar 2026, 0:40 UhrZitat 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.Hallo Herr Patzer,
Das verstehe ich selbstverständlich auch. Ich hatte mir schon so etwas gedacht. Aber auch das kann man ja vertraglich regeln. Diejenigen, die fremder Software Zugriff auf die Datenbank geben, indem sie das Passwort an andere herausgeben, müssen dann auch die Kosten für die Behebung der Probleme selber tragen. Oder müssen halt die andere Software wieder abschalten, weil es nicht geht. Wenn es wirklich eine Fremdspftware ist, die auf vielen Systemen arbeitet (da käme mir Doctolib in den Sinn), sollte sich ja relativ schnell eine Idee finden lassen, woran das Ganze wohl liegen könnte.
aber jetzt allen Den Zugriff zu entziehen, weil es bei wenigen nicht läuft, finde ich aus meiner Sicht nicht optimal. Wie gesagt, wir diskutieren ja auf einem ganz sachlichen Level und das finde ich auch gut so. Mir selbst könnte es egal sein, ich habe ja mein Passwort und damit auch meinen Zugriff. Aber vielleicht lässt sich ja doch noch auf einer anderen Ebene mit den Kollegen, die gerne den Zugriff haben möchten und ihn auch vernünftig begründen können, eine ordentliche Regelung finden.
grüße und allen ein schönes Wochenende
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.
Hallo Herr Patzer,
Das verstehe ich selbstverständlich auch. Ich hatte mir schon so etwas gedacht. Aber auch das kann man ja vertraglich regeln. Diejenigen, die fremder Software Zugriff auf die Datenbank geben, indem sie das Passwort an andere herausgeben, müssen dann auch die Kosten für die Behebung der Probleme selber tragen. Oder müssen halt die andere Software wieder abschalten, weil es nicht geht. Wenn es wirklich eine Fremdspftware ist, die auf vielen Systemen arbeitet (da käme mir Doctolib in den Sinn), sollte sich ja relativ schnell eine Idee finden lassen, woran das Ganze wohl liegen könnte.
aber jetzt allen Den Zugriff zu entziehen, weil es bei wenigen nicht läuft, finde ich aus meiner Sicht nicht optimal. Wie gesagt, wir diskutieren ja auf einem ganz sachlichen Level und das finde ich auch gut so. Mir selbst könnte es egal sein, ich habe ja mein Passwort und damit auch meinen Zugriff. Aber vielleicht lässt sich ja doch noch auf einer anderen Ebene mit den Kollegen, die gerne den Zugriff haben möchten und ihn auch vernünftig begründen können, eine ordentliche Regelung finden.
grüße und allen ein schönes Wochenende
Zitat von bro am 31. Januar 2026, 8:45 UhrZitat von Peter Quick am 31. Januar 2026, 0:40 Uhr Das Ganze hat allerdings einen kleinen Pferdefuß: Immer wenn etwas nicht mehr mit MO funktioniert, liegt es in der Regel an den Datenbanken – zumindest kann man das so behaupten. Und ab diesem Punkt wird jede Maßnahme, egal von welchem Support, in der Regel kostenpflichtig.Das Ganze hat allerdings einen kleinen Pferdefuß: Wenn dann etwas nicht mehr mit MO funktioniert, liegt es dann an der Datenbank – zumindest kann man das so behaupten. Und ab diesem Punkt wird jede Maßnahme, egal von welchem Support, in der Regel kostenpflichtig.
Allein schon die Herausgabe des Passworts führt dazu, dass ab diesem Moment grundsätzlich der User für alles verantwortlich gemacht wird.
___________________
Indamed sollte endlich eine praktikable Backup-Datenbank – oder eine vergleichbare Sicherung – zur Verfügung gestellt werden, die auch diejenigen zufriedenstellt, die überprüfen möchten, ob ihr Backup tatsächlich rückspielfähig ist. Mir wurde zwar einmal gesagt, dass das keine einfache Angelegenheit sei, da das Rückspielen von Backups im Zweifel sogar Systeme zerstören könne und man deshalb besser die Finger davon lasse. Wie auch immer: Das kann jeder für sich bewerten. Gleichwohl brauchen wir endlich – aus meiner Sicht schon seit 2015, da bin ich mit dabei – eine Backup-Lösung, die nicht ständig neue Diskussionen auslöst. Alternativ sollte Indamed klar kommunizieren: Das geht so nicht, das können wir nicht umsetzen, das lässt sich nicht darstellen oder programmieren. Auch diese klare Botschaft wäre hilfreich, damit endlich Ruhe in die Runde kommt.
Unstrittig ist jedoch, dass die aktuelle Datenbanksicherung unbrauchbar ist und den Anforderungen des ärztlichen Alltags in keiner Weise gerecht wird.
Hilfreich wäre eventuell ein Brandbrief von allen Usern unterschrieben (aber Ärzte bekommt man ja nicht vereint)
in der Art
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]
Zitat von Peter Quick am 31. Januar 2026, 0:40 Uhr Das Ganze hat allerdings einen kleinen Pferdefuß: Immer wenn etwas nicht mehr mit MO funktioniert, liegt es in der Regel an den Datenbanken – zumindest kann man das so behaupten. Und ab diesem Punkt wird jede Maßnahme, egal von welchem Support, in der Regel kostenpflichtig.
Das Ganze hat allerdings einen kleinen Pferdefuß: Wenn dann etwas nicht mehr mit MO funktioniert, liegt es dann an der Datenbank – zumindest kann man das so behaupten. Und ab diesem Punkt wird jede Maßnahme, egal von welchem Support, in der Regel kostenpflichtig.
Allein schon die Herausgabe des Passworts führt dazu, dass ab diesem Moment grundsätzlich der User für alles verantwortlich gemacht wird.
___________________
Indamed sollte endlich eine praktikable Backup-Datenbank – oder eine vergleichbare Sicherung – zur Verfügung gestellt werden, die auch diejenigen zufriedenstellt, die überprüfen möchten, ob ihr Backup tatsächlich rückspielfähig ist. Mir wurde zwar einmal gesagt, dass das keine einfache Angelegenheit sei, da das Rückspielen von Backups im Zweifel sogar Systeme zerstören könne und man deshalb besser die Finger davon lasse. Wie auch immer: Das kann jeder für sich bewerten. Gleichwohl brauchen wir endlich – aus meiner Sicht schon seit 2015, da bin ich mit dabei – eine Backup-Lösung, die nicht ständig neue Diskussionen auslöst. Alternativ sollte Indamed klar kommunizieren: Das geht so nicht, das können wir nicht umsetzen, das lässt sich nicht darstellen oder programmieren. Auch diese klare Botschaft wäre hilfreich, damit endlich Ruhe in die Runde kommt.
Unstrittig ist jedoch, dass die aktuelle Datenbanksicherung unbrauchbar ist und den Anforderungen des ärztlichen Alltags in keiner Weise gerecht wird.
Hilfreich wäre eventuell ein Brandbrief von allen Usern unterschrieben (aber Ärzte bekommt man ja nicht vereint)
in der Art
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]
Zitat von Peter Quick am 31. Januar 2026, 18:07 UhrLieber Bro,
eigentlich wollte mich aus der Sache jetzt raushalten und es bei dem belassen, was ich oben schrieb. Aber ich will doch noch mal etwas zu dem sagen, was sie da schreiben.
Das stimmt doch einfach so nicht, was sie schreiben. Ich habe seit zehn Jahren ein zuverlässiges Back-up, ohne dass ich damit große Probleme habe. Ich habe nur eine externe Lösung für mich angepasst, die aber dann problemlos funktioniert. Wir haben das alles schon diskutiert und andere Kollegen und ich haben Methoden und Software vorgeschlagen. Aber einige Mitschreiber hier wollen oder können das anscheinend nicht umsetzen. Kann ich nicht verstehen.
Das was aber bleibt und was auch nicht einfach zu lösen ist, ist der Restore. Sie können auf einem verteilten System, was sich außerhalb der Datenbank auf andere Systeme repliziert, nicht einfach ein Backup wieder einspielen. Wer das nicht versteht oder verstehen will, sollte seine technische Basis auffrischen. Sicher gibt es Lösungen im Super-Profi Bereich, aber dann hat das dann auch eine ganz andere Kostenstruktur. Für mich reicht es aus, wenn maximal die Arbeit einer Stunde verlorengeht. Das ist ein Verlust, den ich verschmerzen kann.
So, damit ist jetzt aus meiner Sicht alles gesagt und ich werde mich bemühen, beim Thema Backup/Restore nichts mehr zu sagen. -))
Lieber Bro,
eigentlich wollte mich aus der Sache jetzt raushalten und es bei dem belassen, was ich oben schrieb. Aber ich will doch noch mal etwas zu dem sagen, was sie da schreiben.
Das stimmt doch einfach so nicht, was sie schreiben. Ich habe seit zehn Jahren ein zuverlässiges Back-up, ohne dass ich damit große Probleme habe. Ich habe nur eine externe Lösung für mich angepasst, die aber dann problemlos funktioniert. Wir haben das alles schon diskutiert und andere Kollegen und ich haben Methoden und Software vorgeschlagen. Aber einige Mitschreiber hier wollen oder können das anscheinend nicht umsetzen. Kann ich nicht verstehen.
Das was aber bleibt und was auch nicht einfach zu lösen ist, ist der Restore. Sie können auf einem verteilten System, was sich außerhalb der Datenbank auf andere Systeme repliziert, nicht einfach ein Backup wieder einspielen. Wer das nicht versteht oder verstehen will, sollte seine technische Basis auffrischen. Sicher gibt es Lösungen im Super-Profi Bereich, aber dann hat das dann auch eine ganz andere Kostenstruktur. Für mich reicht es aus, wenn maximal die Arbeit einer Stunde verlorengeht. Das ist ein Verlust, den ich verschmerzen kann.
So, damit ist jetzt aus meiner Sicht alles gesagt und ich werde mich bemühen, beim Thema Backup/Restore nichts mehr zu sagen. -))
Zitat von bro am 1. Februar 2026, 9:48 UhrIch wollte Sie nicht verärgern und habe Sie auch nicht adressiert. Ich möchte von Indamed nur eine schnelle Sicherungslösung, die praxistauglich ist. In Minuten ausgedrückt sind das 10 Minuten je 70 GB Indamed Ordner. Dieses zuverlässige 10 Minuten / 70 GB Indamed Ordner Back-up hatte ich bisher mit Firebird. Und will ich und viele andere auch haben.
Da ich von der Nummer nix verstehe, habe ich die KI gefragt und das entspricht dem, was hier von wissenden geschrieben wird:
Wenn kein Client auf die MariaDB zugreift, gilt: Die Datenbank könnte problemlos gestoppt werden. Damit wäre eine schnelle, einfache Dateisicherung des gesamten Indamed-Ordners inklusive MariaDB technisch möglich, vergleichbar mit der bisherigen Firebird-Lösung. MariaDB selbst stellt dafür keinerlei Hindernis dar: Wird der MariaDB-Dienst kurz beendet, ist eine konsistente 1:1-Kopie der Daten in wenigen Minuten machbar. Dass dies aktuell nicht vorgesehen oder unterstützt wird, liegt nicht an MariaDB, sondern daran, dass Indamed keinen kontrollierten Datenbank-Stopp bzw. keinen offenen Zugriff erlaubt und Anwender stattdessen brutalst auf ein langsames internes Backup festlegt. Kurz gesagt: Für mein Offline-Backup-Modell wäre MariaDB vollkommen geeignet – Indamed setzt das aber extrem benutzerunfreundlich um, indem diese einfache Vorgehensweise blockiert wird. So jedenfalls lese ich die bisherigen Beiträge.
Das ist doch jetzt nicht zu viel verlangt?
Ich wollte Sie nicht verärgern und habe Sie auch nicht adressiert. Ich möchte von Indamed nur eine schnelle Sicherungslösung, die praxistauglich ist. In Minuten ausgedrückt sind das 10 Minuten je 70 GB Indamed Ordner. Dieses zuverlässige 10 Minuten / 70 GB Indamed Ordner Back-up hatte ich bisher mit Firebird. Und will ich und viele andere auch haben.
Da ich von der Nummer nix verstehe, habe ich die KI gefragt und das entspricht dem, was hier von wissenden geschrieben wird:
Wenn kein Client auf die MariaDB zugreift, gilt: Die Datenbank könnte problemlos gestoppt werden. Damit wäre eine schnelle, einfache Dateisicherung des gesamten Indamed-Ordners inklusive MariaDB technisch möglich, vergleichbar mit der bisherigen Firebird-Lösung. MariaDB selbst stellt dafür keinerlei Hindernis dar: Wird der MariaDB-Dienst kurz beendet, ist eine konsistente 1:1-Kopie der Daten in wenigen Minuten machbar. Dass dies aktuell nicht vorgesehen oder unterstützt wird, liegt nicht an MariaDB, sondern daran, dass Indamed keinen kontrollierten Datenbank-Stopp bzw. keinen offenen Zugriff erlaubt und Anwender stattdessen brutalst auf ein langsames internes Backup festlegt. Kurz gesagt: Für mein Offline-Backup-Modell wäre MariaDB vollkommen geeignet – Indamed setzt das aber extrem benutzerunfreundlich um, indem diese einfache Vorgehensweise blockiert wird. So jedenfalls lese ich die bisherigen Beiträge.
Das ist doch jetzt nicht zu viel verlangt?
Zitat von Privacy am 1. Februar 2026, 15:21 UhrEin Kompromiss wäre ein _uneingeschränkter_ Lesezugriff auf die Datenbank. Damit kann man beliebige Select Anfragen generieren und für eigene, angebundene Anwendungen nutzen. Damit wäre der Zugriff von Drittprogrammen kein Problem mehr
Aber zB die unsäglichen Adresstabellen in eine bessere Parallelstruktur zu überführen (außerhalb MO) wäre schon eine lohnenswerte Aufgabe.
Gruß
B. Müller
Ein Kompromiss wäre ein _uneingeschränkter_ Lesezugriff auf die Datenbank. Damit kann man beliebige Select Anfragen generieren und für eigene, angebundene Anwendungen nutzen. Damit wäre der Zugriff von Drittprogrammen kein Problem mehr
Aber zB die unsäglichen Adresstabellen in eine bessere Parallelstruktur zu überführen (außerhalb MO) wäre schon eine lohnenswerte Aufgabe.
Gruß
B. Müller
Zitat von bro am 2. Februar 2026, 9:21 UhrAn die Maria DB User: Wie sieht euer Sicherungskonzept nun tatsächlich aus, wer hat das eingerichtet und wie lange dauert die Sicherung der MariaDB und des gesamten Indamedordners? Ich gehe davon aus, dass man die MariaDB da in einen Unterordner legen kann. Und wer hat ein On-click-Setting?
- On-Click-Setting? Ja / Nein
- Zeit Datensicherung: min
- Wer hat es eingerichtet: Selbst / FLS / Kosten
- batch file:
An die Maria DB User: Wie sieht euer Sicherungskonzept nun tatsächlich aus, wer hat das eingerichtet und wie lange dauert die Sicherung der MariaDB und des gesamten Indamedordners? Ich gehe davon aus, dass man die MariaDB da in einen Unterordner legen kann. Und wer hat ein On-click-Setting?
- On-Click-Setting? Ja / Nein
- Zeit Datensicherung: min
- Wer hat es eingerichtet: Selbst / FLS / Kosten
- batch file:
Zitat von Johannes Braun am 2. Februar 2026, 9:30 Uhr@bro Das einfachste was man machen kann ist die kostenlose Backup Software von Veeam, sichert ein Image vom kompletten Server.
https://www.veeam.com/products/free/backup-recovery.html
@bro Das einfachste was man machen kann ist die kostenlose Backup Software von Veeam, sichert ein Image vom kompletten Server.
Zitat von bro am 2. Februar 2026, 10:14 UhrOhne dass man die MariaDB in einen Schlafmodus geschickt hat, genau das geht doch angeblich nicht.
Ohne User + Passwort mit entsprechenden Rechten kann kein konsistentes Dump-Backup erstellen.
Ohne dass man die MariaDB in einen Schlafmodus geschickt hat, genau das geht doch angeblich nicht.
-
Ohne User + Passwort mit entsprechenden Rechten kann kein konsistentes Dump-Backup erstellen.
Zitat von Johannes Braun am 2. Februar 2026, 11:19 UhrEin Backup mit Veeam entspricht dem Zustand ihrers Servers, wenn der Strom ausfällt.
Ein konsistentes Datenbankbackup auf dem Server liegen zu haben wäre trotzdem nicht schlecht – daher meine Frage nach der Konfiguration des internen Backups ohne Sicherung des DBFA.
Ein Backup mit Veeam entspricht dem Zustand ihrers Servers, wenn der Strom ausfällt.
Ein konsistentes Datenbankbackup auf dem Server liegen zu haben wäre trotzdem nicht schlecht – daher meine Frage nach der Konfiguration des internen Backups ohne Sicherung des DBFA.