Datensicherung

[wahnfried]

Hallo,

soweit ich weiß, gibt es im BIOS eine Einstellung, den Prozessor-Cache sofort oder verzögert auf der HDD abzuspeichern.

Dies sollte immer auf "sofort speichern" eingestellt sein, da sonst tatsächlich bei Rechnerausfall/Stromausfall_ohne_USV eine nicht bekannte Anzahl von Eingaben verlorengeht (abhängig vom Speicherbedarf der einzelnen Eingaben).

Das ist aber eine generelle Regel für Rechner in Arztpraxen und sollte von jedem verantwortlichen Systembetreuer von vornherein so eingestellt sein, unabhängig von TurboMed...

Da aber Viele ihre Rechner lieber selbst Aufbauen und Warten: lieber nochmal nachsehen!

Für die Systembetreuer-Nutzer: lieber nochmal kontrollieren!


Nun aber noch eine kleine Frage:

Im Zusammenhang mit Speicher-Skripts war der Befehl "Net Use" mit dabei. Aus der Angabe im DOS werde ich nicht schlau und denke, daß auch Andere im Forum gerne wissen würden, was dieser Befehl alles ausführt. Wer gibt mir Nachhilfe?

Viele Grüsse, Wahnfried

[DerEchteFreund]

Lieber Wahnfried,
sind Sie Informatiker? Wissen Sie genau wie ein Cache funktioniert? Wissen Sie, was ein Commit auf einer Datenbank bewirkt?
Wenn Sie eine dieser Fragen mit nein beantwortet haben, sollten Sie nicht derart falsche Aussagen bezüglich des Zwischenspeicherns verbreiten.
Ich weiss, Sie meinen es nur gut, aber diesmal liegen Sie total daneben

[wahnfried]

Lieber echter Freund,

dreimal nein: also habe ich nachgefragt, wo meine Fehlmeinung herkommt (die ich ja glücklicherweise mit "soweit ich weiß" begonnen hatte):

(Diese Info jetzt von meinem PC-Spezialisten-Freund, die Datenbankwartungen usw. beruflich macht und mir meinen Praxisserver vor etwa 5-6 Jahren aufgebaut hat)

Das, was auf "sofort schreiben" eingestellt werden sollte, war der FESTPLATTEN-Cache, bezogen auf meinen Rechner VOR dem Netzwerkaufbau, der damals ein (noch im vorigen Jahrtausend selbst aufgebautes... ) SCSI-System war und dann im Netzwerk bis zur Umstellung auf TurboMed als Client weiterverwendet wurde. Gilt wohl nur für SCSI-Platten und dürfte dann (das ist aber wieder meine eigene Schlußfolgerung...) vermutlich im SCSI-Bios eingestellt werden

Vielen Dank an den Echten Freund für die Korrektur und die Mahnung !
(auch oder gerade wer etwas gut meint, ist lernfähig... )

Viele Grüsse, Wahnfried

[Lauxtermann]

Ich habe die praxisdb mit dem cache-Befehl ins RAM versetzt. Die Anzeige des freien RAM ging um ca. 600 MB runter. Nach Weiterarbeit mit Turbomed wurden aber innerhalb einiger Minuten wieder 600 RAM frei, so daß ich davon ausgehe, daß die praxisdb nur für einen Augenblick im RAM gespeichert wurde. Ist das richtig? Dann wäre der cache-Befehl ja wohl ziemlich unsinnig. Oder gibt es eine andere Erklärung?

[lapins]

@hw cachen auf laptop zu hause:

mangels doku weiß ich nicht wie tm den zugriff auf die daten durchführt, wenn man es als EIN-Platz System fährt. (Grundeinstellungen MEHRPLATZBETRIEB=NEIN)

Das Cachen - wie beschrieben- funktioniert mit MEHRPLATZBETRIEB=JA.
Dazu muss auch auf dem Laptop zu Hause der Fastobject-prozess gestartet
sein.

Nach dem Befehl rödelt es eine Weile bis die DB geladen ist und dann zischen alle Auswertungen.

Bislang gab es trotz automatischer täglicher shutdowns + start in der Nacht und versehentliche Strom-weg-vorfälle keine Datenverluste.


Alternative, wenn der PC oder Laptop zu Hause leider nicht genug Memory
besitzt also ca 256 + db-größe :

-Schnelle USB Sticks kaufen (Speedvergleiche siehe http://www.alternate.de/html/shop/produ ... USB-Sticks&)
zb 4GB mit 15MB/s write um ca 56€
- praxisdb dorthin kopieren
- ptserv.cfg ändern wie folgt wenn g: zb der USB Stick ist

...
name=C:\TurboMed\Dictionary
[databases\PraxisDB]
name=g:\TurboMed\PraxisDB
[databases\PraxisBackup]
name=g:\TurboMed\PraxisDB\Backup
[schemata\StammDict]
...

und dann ebenfalls staunen, wie schnell die erweiterten Suchen funktionieren können.
Der Geschwindigkeitsvorteil ergibt sich, wie in diesem Forum bereits beschrieben aus der "fehlenden" Zugriffszeit, also keine
Armbewegungszeit und keine Rotationsverzögerung,
wie es bei Platten auftritt, wenn nicht schon alles gecached ist.

Mfg RLapins

[a_engels]

Sehr geehrte Kollegen,

Ich habe mir das Backupscript hier im Forum angesehen. Aufgrund der Wichtigkeit der Daten kann ich davon nur dringend abraten.

Warum?
1.) Es wird nicht überprüft, ob sich die Datenbank in einem Zustand befindet, der ein konsistentes Backup zulässt (man stelle sich vor, dass sich die Parameter für TMAdmin ändern, die Datenbank aktiv ist und sich während es Backups ändert..).
2.) Die kopierten Dateien werden nicht dahingehend überprüft, ob sie mit dem Original identisch sind.
3.) Es wird keine Warnmeldung verschickt, falls etwas schief gegangen ist. Stellen Sie sich vor, Sie verlassen sich über Jahre auf einen Backupmechanismus, der gar nicht funktioniert.

Wir haben eine Software selbst programmiert, die folgende Schritte ausführt. Es wird jeder Schritt auf Erfolg überprüft:
1.) Stoppe den Datenbankdienst.
2.) Überprüfe, ob ptserv32 noch läuft -> Datenbankkonsistenz
3.) Verbinde mit Remotecomputer (smb Protokoll)
4.) Kopiere Dateien
5.) Erstelle MD5 Prüfsumme von Original und Ziel und vergleiche. Hier werden CPU, RAM und Festplatte des Quell- und Ziel-PCs überprüft. Wir haben durch diesen Test schon einen Hardwarefehler aufspüren können.
6.) Starte Datenbank
7.) Überprüfe, ob Datenbank läuft

Alle Schritte werden permanent in eine Logdatei geschrieben. Sollte ein Fehler auftreten, so wird eine Email verschickt.

Bestünde Interesse an der Software in diesem Forum? Wir setzen diese Software seit mehreren Jahren erfolgreich ein.

Viele Grüße

[Geigenberger]

... dann habe ich wohl über Jahre Glück gehabt. Ich habe schon mehrmals die kopierte Datenbank auf einen anderen Rechner übertragen: Funktionierte stets problemlos.

Der Vorteil dieser Datensicherung ist ja gerade die Tatsache, dass im _laufenden_ Betrieb Datensicherungen vorgenommen werden können.

Theoretisch könnte man also alle 2 Stunden eine Datensicherung automatisiert während des Sprechstundenbetriebes ablaufen lassen. Und wenn es doch 'mal schiefgehen sollte, dann nehme ich eben bei der evtl. nötigen Rücksicherung die Daten von vor 4 Stunden. Ist meist immer noch aktueller als die Sicherung des Vortags.

Bin schon gespannt, was die Experten dazu sagen.

A. Geigenberger

[a_engels]

Hallo Herr Geigenberger,

Das Script ansich ist auch in Ordnung, die Kritik ist nur, dass an keiner Stelle auf Erfolg überprüft wird.

z.B. könnte sich der Pfad von TMadmin.exe oder dessen Parameter beim nächsten Update ändern. Das Script würde einfach weiterlaufen, ohne zu meckern -> hier müsste man schauen, ob TMadmin einen Status zurückgibt und diesen auswerten. (Wir beenden den Datenbankserver, prüfen, ob der Prozess nicht mehr existiert und können dann von einem konsistenten Momentbild ausgehen - es spricht aber nichts gegen TMAdmin mit Statusauswertung).

Oder irgendeine Komponente ist fehlerhaft (da gibt es unzählige Möglichkeiten..CPU, RAM, HDD, ..) und die Zieldatei stimmt überhaupt nicht mit der Quelle überein.

Oder noch ein Beispiel: der Netzwerkpfad ändert sich und sie denken nicht daran, das Script umzustellen.

Bei den oben genannten Konstellationen sind dann mitnichten nur ein paar Stunden Arbeit verloren sondern eben bis zu dem Zeitpunkt der letzten erfolgreichen Sicherung.

[wahnfried]

Hallo,

ein Pause-Befehl am Ende der backup-Batch mit TMAdmin führt dazu, daß das DOS-Fenster mit den Meldungen offen bleibt, bis man es mit einem Tastendruck schließt.

Vorher kann man die Meldungen lesen. Wenn zuletzt fünfmal das korrekte Beenden des Backupmodus für die Datenbanken gemeldet wird, ist die Spiegelung korrekt abgelaufen, was den Datenbankzustand betrifft. Sollte dort ein Fehler gemeldet werden, weil ein weiterer Arbeitsplatz gleichzeitig gespiegelt hat (hier bisher einmal in einem halben Jahr aufgetreten), läßt man die Spiegelung einfach nochmal laufen.

Auch kann man sehen, ob sich eine Datenbank fälschlicherweise vor der Spiegelung im Backupmodus befand und ob dies beim Beenden von TMAdmin behoben worden ist (falls nicht: Rechner herunterfahren...)

Weiter oben in den Meldungen wird berichtet, wieviel Dateien kopiert wurden, da werden auch Fehler gemeldet.

Wenn man "blind" arbeiten möchte, weil die Helferinnen es sonst zu kompliziert finden, kommentiert man die Pause aus oder entfernt den Befehl, kann sie bei Bedarf wieder aktivieren oder hinzufügen...

Die Überprüfung der korrekten Übertragung ist allerdings interessant, wenn auch aus meiner Erfahrung nicht dringend erforderlich, sofern ich den Clienten auch im Einzelplatzmodus benutze (dann fällt die fehlende Konsistenz sofort auf).

Ihre Software kostet?

Viele Grüße, Wahnfried

[a_engels]

Ich hatte an 20 €/Lizenz gedacht, weil ich schon noch etwas Zeit investieren müsste, um die Software "massentauglich" zu machen.

[uro_fs]

@a_engels:

Das Problem Ihrer Lösung ist, dass in dieser Zeit NICHT gearbetet werden kann, d.h. ein Backup ist NUR nach Feierabend möglich - denn keine Praxis kann es sich leisten, alle 2 Stunden 10 Minuten die Arbeit am PC einzustellen.
Aber genau das geht mit TMadmin sehr wohl automatisiert, so dass kontinuierlich gesichert werden kann und ein Datenverlust dadurch minimal wird.

Am Abend kann man dann Ihr Skirpt nehmen oder auch die TM-eigene Backup Lösung wählen, welche auch die Sicherung noch prüft.

Gruss
fs

und mit
robocopy c:\daten f:\backup /MIR /MON:5
kann man robocopy ohne nennenswerten Ressourcenverbrauch dazu bewegen, z.B. den Dokumenteordner zu überwachen und 5 (bzw. gewählte Anzahl von Änderungen diese zu aktualisieren

so würde im Extremfall
robocopy c:\daten f:\backup /MIR /MON:1
jede neue Datei gleich auf einen anderen Rechner spiegeln können ohne Benutzereingriff

[a_engels]

@uro_fs: Offensichtlich liegt hier ein Missverständnis vor. Ich sagte bereits, dass gegen die "TMAdmin Methode" nichts einzuwenden ist, solange ein Statuscode überprüft wird. Dies allein reicht aber für ein konsistentes Backup auch nicht aus. Ich hatte die Punkte aufgezählt.

Ich habe die TMAdmin-Methode übrigens inzwischen in meine Software integriert, da ich sie auch für sehr sinnvoll erachte.

[a_engels]

Ich habe für das Utility einen eigenen Thread mit Beschreibung und Screenshots eröffnet:
http://www.vondoczudoc.de/viewtopic.php?t=998

[tom.stein]

mein Stick hat einen Durchsatz von 12 Mb/Sek. - ein 100Mbit-Netzwerk schafft meist effektiv zwischen 6 und 8 Mbit/s Durchsatz.

12 MB/s Schreibgeschwindigkeit ist schon ein sehr guter und schneller Stick - viele Sticks machen da (dann oft aus guten Gründen) leider keine vernünftigen Angaben.

Das Netzwerk schafft natürlich 6-8 MB/s (Megabyte/s) oder bis zu ca. 10% der Nominalleistung. Kabelqualität/Kabellängen, Qualität und Auslastung der Switche und Netzwerkkarten sowie sonstiger Netzwerkverkehr beeinflussen dies natürlich etwas. Üblicherweise sind Gigabit-Switche selbst in 100-Mbps-Netzwerken schneller als 100-Mbps-Switche (besserer Chip/Prozessor), aber in den meisten Netzwerken ist das nicht mehr relevant.

Im TM-Betrieb "zieht" ein Arbeitsplatz zwischen 0.04 und 0.1 Mbits/s (aus Trafficüberwachung ermittelt), d.h. der maximale Datendurchsatz ist nicht das Problem, sondern die Zugriffszeit und die liegt bei optimalen Platten bei 5 ms, bei normalen Platten bei ca. 9-11 ms, und bei "einfachen" USB-Platten bei 13+ ms. Die Zugriffszeit eines Sticks ist etwa 500x geringer - und keine mechanischen Teile!

Bei einer Datenbank im Speicher ist die Zugriffszeit der Festplatte kein Thema. Wichtiger wird da das Caching - das ist für USB-Sticks normalerweise ausgeschaltet, und dann wartet die Datenbank auf das Ende des Schreibvorgangs! Lieber eine USV nehmen und verbieten, den Stick ohne "Auswerfen" zu ziehen - und dann den Schreibcache aktivieren. Bei USB-Festplatten ist das Caching oft bereits aktiviert (wenn die Festplatte sich als Festplatte und nicht als Stick zu erkennen gibt).

Zu erwähnen wäre noch, das normale USB-Sticks nur eine relativ geringe Anzahl Schreibzugriffe zulassen - durch interne Maßnahmen des Controllers sind es effektiv ja mehr Schreibzugriffe, je größer der Stick (bzw. der nicht ständig neu beschriebene Teil) ist. Und inzwischen ist natürlich USB 3.0 unbedingt empfehlenswert.

Aus heutiger Sicht kann ich jedem Anwender nur raten, die Datenbank auf eine interne SSD zu legen und genügend Hauptspeicher einzubauen - da findet Turbomed seinen Turbo wieder.

Tom