MEDICAL OFFICE - Anwenderforum

Hallo batsatd,

Ich denke, Sie sollten zunächst einmal den Unterschied zwischen Sicherung und Archivierung bedenken. Die Archivierung verschiebt nur Befunde, die sich nicht mehr ändern, in die Archiv Datei. Damit alleine haben sie noch nicht gesichert. Die Sicherung selbst schreibt alle Daten, bis auf die Archivdatei, in eine Sicherungs-Datei.

Also eine Archivierung lohnt sich nur, wenn Ihre Datenbank so stark angewachsen ist, daß eine Sicherung sehr lange dauern würde. Meine Datenbank ist ca. 8 GB groß, eine Sicherung mittels eingebauter Datensicherung dauert ca. 5 Minuten. Ich habe dabei keinen "Großrechner" , mit dem man auch die Mondlandung steuern könnte, sondern einen i3, 8GB RAM und eine 256 GB SSD. Die Rechnerdimension, die Sie haben ist nett, braucht es aber definitiv nicht. Damit wird die Datenbank nicht signifikant schneller, wie auch die Größe der Datenbank keinen wesentlichen Einfluß auf das Tempo hat (in gewissen Grenzen).

Also: Eine Archivierung sollten Sie durchführen, wenn Ihre Datenbank zu groß ist (je nach Temperament 20 GB). Habe ich auf meinem Testsystem auch schon gemacht, klappte hervorragend. Aber wie gesagt: Nur, wenn Sie kein Mobilsystem haben und keine andere "Erweiterung". Und Sie sollten wissen, was Sie tun...
Dafür wird es auch sicher keinen Knopf geben, so wie es beim Auto auch keinen Knopf für eine Inspektion gibt. Da lassen Sie doch auch die Werkstatt ran, oder?

Eine Datensicherung mache ich doppelt, sowohl mit dem im DPS eingebauten Mechanismus, als auch mittels eines externen Datensicherungsprogrammes. Als Test stelle ich immer mal wieder meine Datenbank auf meinem Testsystem wieder her. Das klappt gut, somit ist auch die Sicherung effizient .... vielleicht sonst mal beim Support beraten lassen....

Grüße,

Peter Quick

Zitat von »pquick«

Ich habe dabei keinen "Großrechner" , mit dem man auch die Mondlandung steuern könnte, sondern einen i3, 8GB RAM und eine 256 GB SSD

Bei der 1. Mondlandung 1969 wären sie froh gewesen, wenn sie solch einen Rechner gehabt hätten

Wir sichern tgl. mit NovaBackup auf Tandberg RDX Quickstore. Die Sicherung läuft nachts automatisch. Jeden Tag auf eine andere Kassete/Fetsplatte (Cartridge), die dann mit nach Hause genommen wird. Das läuft ganz gut. Hierbei wird gleichzeitig auch alles andere, z.B. Impfdoc, Cutomed (EKG)... gesichert.

In der Praxis natürlich zusätzlich gespiegelte Festplatte im Server, Notfallserver und mobiles System (Laptop).

Ich denke das reicht.

Viele Grüße

M.Meier


PS: Wie war es vor der EDV? Da wurden auch nicht die Karteikarten kopiert und mit nach Hause genommen und die Daten zu haben, falls die Praxis abbrennt

Hallo batsatd,

für die Archivierung gibt es keinen einfachen "Knopf", weil dieser Vorgang sehr komplex ist und eben nicht jeder einfach auf diesen "Knopf" drücken soll.

Eine hunterprozentige Prüfung einer Datensicherung erreicht man nur, wenn man eine Datensicherung zurückspielt und mit dem Orginal vergleicht und auch dass lässt sich nicht durch einen einfachen Knopf erledigen.
In Konzernen wird so etwas sicherlich in gewissen Abständen gemacht, aber ich glaube nicht, dass Ihre Daten für Sie weniger wichtig sind als das in einem Konzern der Fall ist. Somit würde es sicherlich nicht schaden, dass vom EDV-Betreuer einmal pro Halbjahr oder Jahr überprüfen zulassen, wenn man es nicht wie Herr Dr. Quick selber kann.

Ab welcher Datenbankgröße man archivieren soll, kann nicht pauschal beantwortet werden. Wir haben Kunden mit weit über 100GB die noch nie archiviert haben, andere mit 10GB archivieren regelmäßig. Es hängt hauptsächlich von der Art und Weise, wie Sie die Datensicherung machen, ab. Jemand, der diese automatisiert nachts laufen lässt, der hat sicher kein Problem, wenn diese 2 Std. oder länger benötigt, um alle Daten zu sichern. Jemand der nach Praxisschluss auf einen Knopf drücken will, um die Datensicherung anzustoßen, will wahrscheinlich nicht länger als 5-10min warten, bis diese fertig ist und das hängt neben der verwendeten Hardware halt von der Größe der Datenbank ab. Mit der Geschwindigkeit während dem Praxisbetrieb hat die Archivierung so gut wie nichts zu tun.

Ich würde hier immer dazu tendieren: So oft zu archivieren wie nötig und nicht so oft wie möglich. Wichtig ist, dass nach jeder Archivierung das Archiv entsprechend gesichert werden muss. Die dort enthaltenen Daten müssen dann zwar nicht mehr täglich gesichert werden, da sie sich bis zur nächsten Archivierung ja nicht mehr ändern aber man muss eine Kopie des Archivs auf jeden Fall sicher aufbewahren, falls mit den Echtdaten mal ein Problem auftritt (Festplatte kaputt, Diebstahl, Brand, ...)

Also: Archivieren sollte nur Derjenige, dem der zeitliche Aufwand für die Datensicherung zu groß wird und bevor man archiviert, sollte man überlegen, ob es nicht besser wäre, dass Datensicherungskonzept zu ändern!!

mfg
Uwe Streit

Ich habe heute meinen Indamed Ordner auf dem Server (50GB) per robocopy auf eine USB Festplatte (also praktisch den ganzen Indamed /MO etc Inhalt auf dem Server) auf eine externe Festplatte (USB 2.0) kopiert

robocopy "server indamed" (m: ) E: /mir

vorher auf dem server stop.mo.

keine weitere Eingriffe an der Datenbank !!

Wäre das eine sicherre Sicherung ?

1. Sicherung 25 Minuten
danach ca. 4 Minuten, da nur Änderungen erneut kopiert werden.

Hallo batsatd,

auf jeden Fall der 1. richtige Schritt. Sie könnten sich auch im DPS unter Arbeitsplatz-Datensicherung (als Administrator starten mit rechte Maustaste, starten als) eine regelmäßige Datensicherung auf eine externe Platte einrichten. Diese Datensicherung müßte bei der Rechenleistung Ihres Server eigentlich weitgehend unbemerkt nebenher laufen. In der Datenbank ist die gesamte Konfiguration Ihres Systems vorhanden. Bei einem Crash müßten Sie nur MO neu blanko installieren, was ja sehr schnell geht und dann Ihre Datenbank zurückspielen per Batch-Datei, was ebenfalls nur ca. 5-10 Minuten dauert (bei 9 GB). Dann sollten eigentlich alle Daten und die Konfiguration wieder da sein...

Zusätzlich würde ich immer auch ein Backup der gesamten Platte mittels Software wie Acronis etc. empfehlen. Kostet ja nicht die Welt, wenn Sie nicht gerade die echte Serverversion brauchen . Auch dann gibt es preiswerte Alternativen, die gut sind...

Grüße,

Peter Quick

Hallo batsatd,

ich bin mir nicht sicher, ob es ausreicht, nur eine Datei "STOP.MO" anzulegen.
Sie werden sicherlich bemerkt haben, dass dann ein Dialog startet, der Sie darauf hinweist, dass alle Clients innerhalb weniger Sekunden geschlossen werden .
Da ich allerdings nicht weiß, wie der "Medical Office Dienst" programmiert ist, kann ich nicht ausschließen, dass dennoch Zugriffe auf die Datenbank erfolgen. Das könnte im schlimmsten anzunehmenden Fall die Datenbank zerstören .
Ich zitiere mal aus dem Artikel von U. Streit zum sicheren Kopieren:

Zitat von »U.Streit«

1. Mechanismus (sicheres Kopieren der Datei)
Hierbei wird der Datenbank mit einem Befehl (nbackup) gesagt, dass Sie die Datei bis auf Widerruf nicht mehr ändern darf. Anfallende Änderungen werden nach Absetzen des Befehls in eine zweite Datei (die sogenannte Delta-Datei) geschrieben. Nach Absetzen des Befehles, kann man die Datei ganz normal z.B. im Windows-Explorer kopieren und trotzdem kann an allen Arbeitsplätzen weitergearbeitet werden. Man darf aber keinesfalls vergessen, dass man nach dem Kopieren der Datei den Befehl gibt, wieder im normalen Modus zu arbeiten, ansonsten hat man alle neuen Daten in der Delta-Datei und sichert dann beim nächsten Mal die neu erfassten Daten nicht mit.

Alle meine Ausführen sind jedoch ohne Gewähr auf Vollständigkeit oder Korrektheit zu verstehen. Antworten dieser Qualität kann Ihnen nur jemand von INDAMED direkt geben .

Viele Grüße,

vital

Mein Vorgehen:
alle clents beenden MO und die Rechner werden ausgeschaltet, bis auf einen.

von einem Client mache ich dann die Sicherung. Auf diesem ist MO natürlich auch beendet.

Wie setze ich wo den Befehl nbackup zum schliessen der Datenbank (*.bat Datei ?) und wie hebe ich den dann wieder auf

Während meiner Hauptsicherung ist die Praxis zu, es wird nicht mit MO gearbeitet. Muss man die Datenbank dann überhaupt sperren? Es greift ja niemand darauf zu, um Daten hineinzuschreiben.
Gruß
JS

Hallo batsatd,

wie schon geschrieben müssen Sie Ihre Datenbank in einen konsistenten Zustand versetzen, sonst können Sie kein Backup erzeugen, was vollständig ist. Wie sie folgendem Zitat aus der Anleitung von nbackup entnehmen können, müssen Sie vor Beginn des Backup folgendes tun:

One of the basic problems of trying to use a third party backup tool, or simple file copy of a Firebird database whilst a database is active and online, is that the tool or utility has no concept of transactions, so all you get is a copy of what is in the O/S buffer or disk of the database at the time you make the backup. However this "copy" of the database might be changing as new or active transactions are committed to the database while the copy is taking place. This is likely to produce at best, an inconsistent database, or at worst something that is corrupt and can't be used. Prior to Firebird 2.0 (other than using gbak) the only way you could do a backup or copy like this was to shut the database down, and make sure that no users were accessing the database before you invoked the third party backup tool or copy.

However it is possible to use Nbackup to achieve the functional equivalent of a gbak and use a third party backup tool.

The first thing you need to do is start a "freeze" on your database using the following syntax.

nbackup -U username -P password -L database.fdb

This will effectively lock the database, a flag is placed on the database header page, and it is set to "Locked" to let the engine know that all amended database pages that are written to the database are now being redirected to a delta file.

Changes are flushed from the internal (Firebird) database cache to the O/S cache when a transaction is committed, if forced writes are on then these changes are flushed directly to disk, the final task on commit is to mark the transaction as committed in the Transaction Inventory Page. Once the database is locked, all commits are written to the delta file rather than the database, thus ensuring that the database is kept in a consistent state.

Once the lock is applied, a simple gstat -h on the database wil show the "LOCKED" status as an optional database attribute. Once the -L command has done its work, a dela file will now be capable of receiving any committed changed database pages.

You can now use your an alternative backup tool whilst database users continue to work. When your backup tool has finished doing what it needs to do to take a copy of the database, you can "unfreeze" the database using the nbackup -N (unlock) command.

nbackup -U username -P password -N database.fdb

The unfreeze causes nabckup to merge the changed pages from the delta file back into the main database, when completed the delta file is removed and the database header is changed back to its normal state.
The backup you made of the database in its frozen state will still be in a "LOCKED" state, so if you need to restore it users will be unable to attach to it until you perform a "fixup". The fixup will reset the locked flag on the database header page back to normal, even though there isn't a delta file associated with the database.



Sie brauchen also eine Batch-Datei, die erst den Befehl zum lock gibt, dann das backup durchführt und dann die Datei wieder freigibt. Dabei könnten sie auch prinzipiell nebenher weiter arbeiten. So funktioniert auch das eingebaute backup von Medical Office.


Grüße,
Peter Quick

vielen Dank an P.Quick
ich glaube ich habe es - fast

nbackup -U username -P password -L database.fdb

woher bekomme ich den username und das passwort ist database.fdb so zu verwenden oder muss da individuell was anderes stehen?

ich gehe davon aus, das ich die batchdatei in dem verzeichnis starte wo die datebase.fdb liegt.

so sehe das dann aus:
nbackup -U username -P password -L database.fdb
robocopy M: E: /mir
nbackup -U username -P password -N database.fdb

Rot ist mir unklar

Vielen Dank
JS

Hallo batsatd,

kleiner Tipp, erst mal an Ihrem Testsystem ausprobieren...

Nutzername und Passwort brauchen Sie -so ich mich recht erinnere- nicht. Statt database.fdb müssen Sie natürlich den Namen der MO-Datenbank eintragen, also MEDOFF.GBD im Verzeichnis dat.

Am besten erstmal die Befehle in der DOS-Box ausführen, dann sehen Sie, was das System als Rückmeldung gibt...

Aber mal ehrlich, wäre es nicht doch besser, Sie fragen mal bei Ihrem Support nach, bevor etwas schief läuft?

Grüße,

Peter Quick

beim Befehl nbackup -L Medoff.dgb bekomme ich im dosfenster entweder eine Endlosschleife oder aber die Info : Medoff.GDB Datei wird nicht gefunden
das kann ja noch spannend werden.
meine Medoff liegt auf M:\dat\medoff.gdb

nbackup -L M:\dat\medoff.gdb das sollte so richtig sein, funzt aber nicht


nbackup liegt in M:firebird\bin\nbackup

passwort und username ist tatsächlich nicht erforderlich

Ich mache das so:

1. [Öffnen der cmd.exe über Start -> Ausführen
   
2. [Wechseln in das Verzeichnis C:\INDAMED\dat mit "cd c:\INDAMED\dat"(Verzeichnisse können anders sein, je nach Installation)
   
3. Ausführen von "C:\INDAMED\Firebird\bin\nbackup.exe -L MEDOFF.GDB" (Verzeichnisse können wieder anders sein, je nach Installation). Dieser Befehl sorgt dafür, dass Änderungen in eine "temporäre" Datei geschrieben werden.
4. Wenn Sie jetzt "dir" eingeben, könnte es sein, dass sie die temporäre Datei "MEDOFF.GDB.delta" finden. Wenn Sie weiter mit der Datenbank arbeiten, werden die Änderungen in diese Datei geschrieben. Sie können die Datei "MEDOFF.GDB" also sorgenfrei kopieren.
5. Wenn Sie den Befehl "C:\INDAMED\Firebird\bin\gstat.exe MEDOFF.GDB -h" eingeben, dann werden Ihnen Eigenschaften der Datenbank MEDOFF.GDB angezeigt. Nachdem sie in Schritt 3 die Datenbank für das Backup vorbereitet haben, sollten Sie nun unter Attributes "backup lock" sehen. Das heißt, dass Schritt 3 erfolgreich war. Dieser Schritt ist nur zur Kontrolle und kann später weggelassen werden.
6. Jetzt können Sie die MEDOFF.GDB kopieren.
7. Ausführen von "C:\INDAMED\Firebird\bin\nbackup.exe -N MEDOFF.GDB" (Verzeichnisse können wieder anders sein, je nach Installation). Dieser Befehl macht die temporären Änderungen wieder permantent. Diesen Schritt sollte man nicht vergessen.
8. Wenn Sie den Befehl "C:\INDAMED\Firebird\bin\gstat.exe MEDOFF.GDB -h" eingeben, dann werden Ihnen wieder die Eigenschaften der Datenbank MEDOFF.GDB angezeigt. Nach Schritt 7 sollte "backup lock" nun nicht mehr neben Attributes stehen. Das heißt, dass Schritt 7 erfolgreich war.

Wie immer ohne Gewähr. Viel Spaß .

Zitat

Wechseln in das Verzeichnis C:\INDAMED\dat

nur zur Sicherheit. Indamed liegt bei mir auf dem Server, und der hat m: als Laufwerksbuchstaben.

auf den clients gibt es auch C:\INDAMED\dat da liegt ja aber nicht die Datenbank die es zu locken gilt und dann zu sichern.

Ich ersetze c: durch m: und werde berichten

Danke und Grüße
JJ

nur so eine Idee... - den Laufwerksbuchstaben "M" haben ja sie am Client zugewiesen - wieso lassen Sie das nicht direkt am Server laufen? da hat das Verzeichnis sicherlich nichts mit M zutun - oder? bei uns ist MEDOFF auch via Netzlaufwerk als M:\ an den Clients angebunden - das Verziechnis selbst liegt am Server aber auf D:\ .. OK?

also versuchen Sie es doch mal direkt am Server im Eingabefenster... cmd.exe

Wechsel ins MEDOFF_Installationsverzeichnis - könnte wetten es liegt auf D ;-)

Vielleicht liege ich auch komplett falsch...

TF

Hallo,

so, ich habe nochmal auf meinem Server nachgesehen. Die Batchdatei zum lock hat folgenden Inhalt (auf meinem Server natürlich)

"D:\MEDOFF\Firebird\bin\nbackup" -user sysdba -password masterkey -L "D:\MEDOFF\dat\medoff.gdb"


Unlock dann entsprechend mit -N



Das funktioniert auf jeden Fall bei mir sehr gut. Wahrscheinlich kann man -user und -password weglassen, aber "never change a running system"...

Testen Sie es mal aus.

Grüße,

Peter Quick

Zitat

D:\MEDOFF\Firebird\bin\nbackup

dann ist also der Ordner Firebird ein unterordner von medoff - Richtig?
bei mir gibts medoff nicht, muss ich anpassen, werde berichten.
JS

Hallo,

Medoff befindet sich im Ordner Laufwerk:\INDAMED\dat !

viele Grüße

M.Meier

PS: deer Ordner Firebird liegt in Laufwerk:\INDAMED\Firebird

Zitat von »U.Streit«

Wir werden die Informationen zur Archivierung aktualisieren und dann auch hier bereitstellen. Aber es wird in der Beschreibung auch drin stehen "Nutzung auf eigene Gefahr" und "keine Garantie ohne vorhandene aktuelle Datensicherung".

Wo wurden die Informationen bereitgestellt?