Zitat von Marc Allef am 22. Februar 2025, 22:35 Uhr

Hallo Herr Sprenger,

natürlich führen viele Wege nach Rom.

wichtig sind ein paar Kriterien:
– dass die DaSi real erfolgt
– räumliche Trennung
– elektronische Trennung

Bei einer Datei-orientierten Datensicherung per „Robocopy“ dauert die erste Sicherung sehr lang, danach ist die Dauer vermutlich mit unter 15 Minuten erträglich.
Wichtig: Der Rechner, der die Daten empfängt, muß derjenige sein, der alles managed. Nicht der „Server“. Bei einer Festplatten-Sektoren-ortientierten Datensicherung (z. B. mit „DriveSnapshot“)  ist die Dauer vermutlich dauerhaft relativ hoch, dafür nicht inkrementell, und relativ konstant.
Bonus: Die DaSi läuft per DriveSnaphot stabil, kaum Aussetzer. Bin wirklich erstaunt.

Zitat von Julian Hartig am 24. Februar 2025, 9:38 Uhr

Ich bleibe bei meiner bereits geäußerten Meinung, dass die Sicherung eines Systemzustandes sinnvoller als die einzelner Dateien ist :). Ich würde also immer dazu raten, das komplette System (also inklusive Betriebssystem) zu sichern und im Bedarfsfall aus dieser Sicherung wieder zurückzuspielen. Mit den geeigneten Tools kann auch das inkrementell erfolgen und es können bei Bedarf aus diesem Image auch nur ausgewählte Dateien (statt des gesamten Images) wiederhergestellt werden.

Am einfachsten ist es natürlich, wenn man das Serversystem virtualisiert. Der Proxmox-Backup-Server (an anderer Stelle von Kollegen und von mir bereits ausführlich beschrieben) bietet einem beispielsweise ein ausgefuchstes Sicherungskonzept, bei dem u.a. eine Dirty-Bitmap geführt wird, die es ohne groß herumzurechnen erlaubt, in einem Backup nur die Teile eines Images erneut zu sichern, die sich seit der letzten Sicherung verändert haben. Durch die deduplizierende Speicherung reduziert sich zudem der Speicherbedarf wiederholter Backups erheblich und im Gegenteil zu klassischen inkrementellen Backups kann ich jeden Sicherungspunkt zu jeder Zeit löschen, wenn ich ihn nicht mehr brauche. Trotzdem bleiben alle Daten vorhanden, die für eine Wiederherstellung der noch vorhandenen Sicherungspunkte notwendig sind.

Über den PBS können zudem in der heutigen Zeit sehr empfehlenswerte Offsite-Pull-Sicherungskonzepte sehr einfach realisiert werden. Die Sicherung eines ganzen, lauffähigen Systemabbildes garantiert dabei eine extrem schnelle Disaster Recovery – sobald die neue Hardware bereitsteht, kann Proxmox dort installiert, das Backup zurückgespielt und die VM direkt wieder ans Laufen gebracht werden mit dem exakten Funktionszustand des letzten Backup-Zeitpunktes.

VG Julian Hartig

Zitat von Jörg Sprenger, Kirchner, Müller am 25. Februar 2025, 9:22 Uhr

Zitat von Julian Hartig am 24. Februar 2025, 9:38 Uhr

Ich bleibe bei meiner bereits geäußerten Meinung, dass die Sicherung eines Systemzustandes sinnvoller als die einzelner Dateien ist :). Ich würde also immer dazu raten, das komplette System (also inklusive Betriebssystem) zu sichern und im Bedarfsfall aus dieser Sicherung wieder zurückzuspielen. Mit den geeigneten Tools kann auch das inkrementell erfolgen und es können bei Bedarf aus diesem Image auch nur ausgewählte Dateien (statt des gesamten Images) wiederhergestellt werden.

Am einfachsten ist es natürlich, wenn man das Serversystem virtualisiert. Der Proxmox-Backup-Server (an anderer Stelle von Kollegen und von mir bereits ausführlich beschrieben) bietet einem beispielsweise ein ausgefuchstes Sicherungskonzept, bei dem u.a. eine Dirty-Bitmap geführt wird, die es ohne groß herumzurechnen erlaubt, in einem Backup nur die Teile eines Images erneut zu sichern, die sich seit der letzten Sicherung verändert haben. Durch die deduplizierende Speicherung reduziert sich zudem der Speicherbedarf wiederholter Backups erheblich und im Gegenteil zu klassischen inkrementellen Backups kann ich jeden Sicherungspunkt zu jeder Zeit löschen, wenn ich ihn nicht mehr brauche. Trotzdem bleiben alle Daten vorhanden, die für eine Wiederherstellung der noch vorhandenen Sicherungspunkte notwendig sind.

Über den PBS können zudem in der heutigen Zeit sehr empfehlenswerte Offsite-Pull-Sicherungskonzepte sehr einfach realisiert werden. Die Sicherung eines ganzen, lauffähigen Systemabbildes garantiert dabei eine extrem schnelle Disaster Recovery – sobald die neue Hardware bereitsteht, kann Proxmox dort installiert, das Backup zurückgespielt und die VM direkt wieder ans Laufen gebracht werden mit dem exakten Funktionszustand des letzten Backup-Zeitpunktes.

VG Julian Hartig

Hallo Herr Hartig

Ich glaube Ihnen, dass dieses Konzept gut ist, gleichzeitig ist es für mich nicht zu durchschauen, es es komplex und auf den ersten Blick kompliziert. Genau diese tatsache ist der Grund für diesen Thread. Ich möchte erst einmal verstehen, wo sind die Daten wie gespeichert, was ist konkret zu sichern, wie kann ich damit für mich verständlich eine Sicherung realisieren, auch wenn diese erst einmal nicht die optimale ist. So bin ich jetzt über 20 Jahre gut klargekommen und habe wiederholt ein Backup vorgenommen und getest und funktionierend ans Laufen gebracht. Nicht schön, nicht elegnat, nicht optimal, aber es funktionierte.

Danach gehe ich gerne den nächsten Schritt und mache es besser. Bisher ist unsere Praxis mit einem Server und Server-Betriebssystem auf 2 Partionen aufgesetzt, MO auf M, Windows auf C.  Damit tue ich mich schon schwer, dies in ein (1)  Image zu packen. Leider habe ich mich überreden lassen, alles mit Domäne ausetzen zu lassen, das macht es für mich einfach nur schwieriger.

 

Damit bin ich also wieder am Anfang ihres letzten Posts, ja, in Schritt 2 schwebt mir auch vor, das System und MO so zu sichern, eine Virtualisierung wäre dabei ein weiterer, späterer Schritt. Ich muss es aber verstehen und selber managen können, und da sind die Grundlagen auf meiner Seite ganz andere, als bei Ihnen. Gerne nehme ich natürlich dieses Wissen in Anspruch, aber aktuell überfordert es mich noch.

 

Danke für die Anregungen,  ich bin neugierig auf den nächsten Input.

 

Mit freundlichen Grüßen, Jörg Sprenger

Zitat von Jörg Sprenger, Kirchner, Müller am 25. Februar 2025, 14:38 Uhr

Nur zur Info: Ich habe nun einmal den gesamten Files-Ordner mal mit Winrar gepackt, ca. 3 Stunden, jetzt werde ich mal entpacken und schauen, wie lange das dauert. Dieses RAR-File ist damit ja eine gute Basis für weitere, dann aber wesentlich kleinere Abgleiche.

Zitat von Marc Allef am 25. Februar 2025, 22:14 Uhr

Bei meinen Kunden habe ich regelmäßig keinen EDV-Profi vor Ort. Deshalb mache ich gerne Datensicherungen statt nach dem „Türme-von-Hanoi-Prinzip“ lieber technisch schlechter mit einer festgelegten externen SSD pro Wochentag (Mo-Fr). Dann kann ich die externen SSDs mit Wochentagen beschriften, und das klappt wenigstens.

Der als „Server“ deklarierte PC (Ist kein Server-Betriebssystem) bleibt dann halt meistens stets eingeschaltet und macht nachts per „DriveSnapshot“ mindestens eine, besser aber 2 Kopien der real verwendeten SSDs (C: und D:): Eine interne, auf eine sonst nicht verwendete SSD (E:), und die echte Dasi: eine externe Kopie auf (F:), die nimmt sich dann die Chefin täglich nach Hause und bringt sie am nächsten Tag wieder mit. Wegen „räumliche Trennung“.

Das Konzept halte ich für einen guten Kompromiss zwischen „technisch optimal“ und „helferinnentauglich“. Zur Kontrolle, dass die DaSi auch real erfolgt: Mein DaSi-Script sendet mir stets nach der Arbeit eine Email. Das wichtigste ist dabei der Zeitpunkt, an dem die Email versandt wird: Ist der zu früh, war was schief gelaufen. Grob um 3:30 Uhr nachts: Das sieht erst mal gut aus…

Mit „helferinnentauglich“ meine ich dabei, dass das Konzept auch von Personen verstanden werden kann, die sich bewußt für einen sozialen Beruf anstatt einem technischen Beruf entschieden haben.

Und ja: Natürlich kann man auch einen Server virtualisieren, und dann dessen Dateien sichern. Aber das mache ich nicht. Eine Virtualisierung frisst Performance. Nicht unbendingt viel, aber doch etwas. DriveSnapshot (und andere Programme) machen eine Virtualisierung deutlich weniger attraktiv.
Denn wozu virtualisieren? Ich kann so z. B. den Druckertreiber mit sichern. Aber per „DriveSnapshot“ mache ich das auch. Virtualisierung oder nicht? Das hängt vom konkreten Einzelfall ab. Ich habe bei meinen Kunden beides. Beide Varianten funktionieren, keine ist der Heilsbringer, keine die Hölle.

Als Ehemann einer dieser Chefinnen habe ich noch dazu ein VPN nach Hause aufgespannt, darüber mache ich noch zusätzlich eine DaSi per Robocopy. Sowohl vom Ordner „Indamed“ als auch vom Ordner „Praxis“, in dem z. B. alle möglichen nicht-MO-Dokumente enthalten sind. Das dauert auch nur ca. 15 Minuten…

Eine DaSi per „DriveSnapshot“ kann man sowohl per „Komplette Festplatte wiederherstellen“ wieder herstellen, aber auch einzelne Dateien wieder rücksichern.
Bei Robocopy werden ohnehin nur Dateien kopiert. Das ist eher ein Schmankerl obendrauf.

Mit freundlichen Grüßen,

 

Marc Allef

 

Zitat von Jörg Sprenger, Kirchner, Müller am 26. Februar 2025, 18:49 Uhr

@Herr Allef

Das ist so verständlich, wie ich es brauche. 😀 

Der Snapshot ist dann jeweils aufgeteilt auf 2 Images? Jeweils für Part C: und D: ? 

Leider (?) habe ich ein Server-OS und stehe mangels ausreichendem Wissen mit einigen Dingen auf Kriegsfuß,  auch die Domäne verfluche ich innerlich, da ich ohne dieselbe bis vor 4 Jahren sehr gut klar kam. Ich kann eben nur das, was ich auch verstehe, und habe vermutlich nicht die geistigen Kapazitäten, die für alles notwendig wären.

Wie haben sie denn die erste Sicherung vorgenommen, auf per Snapshot und dann Migration auf einen Heimrechner? Der Datenabgleich per VPN ist ja bei einer Sicherung des Files-Ordners und der Maria.DB (Dump) über diese Leitung kaum realisierbar, lediglich die Delta-Sicherung kann ich mir vorstellen.

Was steckt außer Tabellen und SQL-Anweisungen in der Maria.DB drin? Ich hatte es so verstanden, dass alle historischen und zukünftigen MO-Eingaben/PDFs/EKGs etc. im Dateisystem gespeichert werden und die DB nur die „Übersicht“ über diese Daten hat. Oder sind „klassische“ MO-Inhalte in der Maria.DB gespeichert?

 

Zitat von Marc Allef am 27. Februar 2025, 0:17 Uhr

Das Programm „DriveSnapshot“ kann entweder „logische Festplatten“ sichern, dann gäbe es in einem DaSi-Script eben 2 Zeilen für C: und D:, oder es kann die physikalische Festplatte sichern. Dann ist das eine Zeile im Script, und DriveSnapshot kümmert sich um die Bennenung der einzelnen Dateien dann selber. Diese Variante empfehle ich. Es sind dann Detailfragen der Bedienung, was, wann, wie wieder hergestellt wird. Immerhin können Sie so die gesamte physikalische Festplatte wieder herstellen, nur einzelene Partitionen oder auch nur einzelne Dateien.

Und für alle drei Varianten der Wiederherstellung gibt es Anwendungsfälle, ich habe alle drei leider schon verwenden dürfen.

DriveSnapshot verwendet offenbar intensiv Windows-Funktionen: Das Programm ist extrem klein, schneller heruntergeladen, als man gucken kann.

Ich habe in der Praxis Glasfaser mit 1000/400 MBit, daheim „Breitbandkabel“/Kabelfernsehen mit 1000/50 MBit. Mit Hilfe von 2 Raspi-Computern habe ich ein Wireguard-VPN bis fast an seine theoretische Geschwindigeits-Begrenzung (400/50 MBit) bringen können.  Diesen Aufwand treiben wahrscheinlich nur wenige hier im Forum.
Der Lohn: Ich konnte mit Robocopy grob 1TB an Daten in einer einmaligen Sitzung in grob 48h per Internet übertragen. Der Praxisbetrieb konnte dabei problemlos weiterlaufen. Der 2. Start des gleichen Kopiervorganges überprüft dann vor allem die Änderungen, und kopiert die erstaunlich wenigen geänderten Dateien: das dauert dann bisher meist knapp 15 Minuten.

Wegen MariaDB werden alle „Dokumente“ extern gespeichert, die landen also nicht in  der eigentlichen Datenbank. Die Datenbank selber wird dadurch relativ klein. Alle „Dokumente“ werden bei „DriveSnapshot“ ja sowieso mit gesichert, wenn sie denn irgendwo auf der Festplatte liegen. Und bei „Robocopy“ werden nur die Neuen gesichert, der Rest wird nur kontrolliert.

Mit Domäne und Server: Da wird Drivensapshot leider trivial etwas teurer: Statt 39€ kostet es dann halt 99€. (Laut Homepage am 27.2.25).

mfg

Marc Allef

Zitat von Jörg Sprenger, Kirchner, Müller am 27. Februar 2025, 12:22 Uhr

Zitat von Marc Allef am 27. Februar 2025, 0:17 Uhr

Der Lohn: Ich konnte mit Robocopy grob 1TB an Daten in einer einmaligen Sitzung in grob 48h per Internet übertragen. Der Praxisbetrieb konnte dabei problemlos weiterlaufen. Der 2. Start des gleichen Kopiervorganges überprüft dann vor allem die Änderungen, und kopiert die erstaunlich wenigen geänderten Dateien: das dauert dann bisher meist knapp 15 Minuten.

 

Was genau haben Sie dabei wie übertragen?  Den Files-Ordner in gepackter Form? Die MySQLDUMP-Datei? Den Indamed-ordner in gepackter/ungepackter Form?

Zitat von Marc Allef am 27. Februar 2025, 13:39 Uhr

Hier ist mein Script, das ich nur für mich persönlich gebastelt habe, „quick and dirty“.

Das geht sicher irgendwie besser, aber z. B. kenne ich die „errorlevel“, brauche diese daher nicht irgendwie schön darzustellen.
Mit dem Script habe ich nichts gepackt, sondern einfach nur die Freigaben auf dem Server kopiert.
Wegen der gefühlt Trillionen Dateien dauert das auch beim ersten Durchlauf lang.

Umso beeindruckender ist die Geschwindigkeit beim 2. Start.

(Ich habe das Script ein bisschen verändert, will ja hier nicht alles verraten…)

Übrigens: Man kann den 1. Durchlauf auch entspannt in mehreren Etappen durchziehen: Der Befehl „Robocopy“ prüft, was schon da ist und kopiert dann einfach weiter…

Aber: Dieses Script kopiert viel, aber eben nicht alles, was den Server ausmacht. Dieses Script ersetzt keine Datensicherung!

 

Achtung: Robocopy ist mit diesen Einstellungen brutal: wenn im Originalverzeichnis eine Datei gelöscht wird, dann wird die auch im Ziel gelöscht. Wehe, wenn man Robocopy falsch herum einrichtet….

—————————————————

@echo off
set d=%date%
set SORTDATE=%d:~-4%-%d:~3,2%-%d:~0,2%
set t=%time%
set SORTTIME=%t:~0,2%-%t:~3,2%-%t:~6,2%
if „%SORTTIME:~0,1%“==“ “ set SORTTIME=0%SORTTIME:~1,6%
set logfile=c:\Dasi\logfiles\log-Px-Priv%SORTDATE%–%SORTTIME%.txt
set log2=c:\Dasi\logfiles\log-Px-Priv-Zusammenfassung.txt
set Log=c:\Dasi\logfiles\log-Px-Priv.txt

echo –%logfile%–
echo %date%–%time%: Datensicherung Start
echo %date%–%time%: Datensicherung Start>>%logfile%
robocopy \\IP-Adresse des Servers\Praxis e:\dasi-Px-Priv /MIR /R:1 /W:1 /copy:DT /nodcopy /a-:rhs /NP /TEE /Log:log.txt
set a=%errorlevel%
robocopy \\IP-Adresse des Servers\Indamed e:\dasi-Indamed /MIR /R:1 /W:1 /copy:DT /nodcopy /a-:rhs /NP /TEE /Log:log2.txt
set b=%errorlevel%
echo %date%–%time%: die Datensicherung hat Ergebnis %a% und %b% ergeben.
echo %date%–%time%: die Datensicherung hat Ergebnis %a% und %b% >>%logfile%
goto :weiter
:weiter
echo %date%–%time%: Datensicherung Ende>>%logfile%
echo %date%–%time%: Datensicherung Ende
pause