AW: WaWi Datensicherung / Backup Strategien
Um da mal ein bisschen licht ins Dunkel zu bekommen,
dass was in dem in #23 Gelinkten Beitrag der Context die Problematik ist, warum es besser ist alle Prozesse die auf der DB arbeiten zu beenden für eine Sicherung würde ich als einen Software Fehler innerhalb der
Wawi sehen, welchen ich so in einer aktuellen Version nicht umbedingt bestätigen oder verneinen könnte.
Hier wird ja im Grunde beschrieben, dass wärend der Sicherung unterumständen ein Auftrag geschrieben wird, und ein Teil dieses Prozesses (z.B. die Datensätze in der tBestellung) in der Sicherung wären, der rest (die Positionen) eben nicht. Ein solches geschehen umgeht man eigentlich, in dem ein Auftrag nur als ganzes in die DB geschrieben wird (Sprich Entweder alle datensätze oder keiner) dies macht man in der Regel mit Transaktionen (welche auch JTL verwendet)
Beim erstellen einer Sicherung (gerade einer Onlinesicherung) geht das system hin und sagt, Punkt X, mit allen zu diesem Zeitpunkt abgeschlossenen Transaktionen ist mein Sicherungspunkt, alles bis dahin wird gesichert, alles danach (was ja während des Backups vielleicht noch in die DB geschrieben wird) fällt raus.
So hat man einen eigentlich sauberen Sicherungszustand.
Wenn natürlich durch eben keine Verwendung von Transaktionen daten bereits innerhalb des Sicherungspunktes, und daten die Logisch zusammen gehörend sind ausserhalb liegen, dann könnten wir "Software" Seitig einen Inkonsistenten Datenbank zustand bekommen. Dies ist klar, und sicher gerade in alten Wawi Versionen eher möglich als in neuen. Problematik an der sache ist dann nur, jeder Wawi Absturz, jeder PC Absturz, jeder Verbindungsabbruch kann dann diesen Zustand auch hervorrufen.
Sprich im genannten Beispiel z.B. auch das Beenden des Workers, während er noch Daten schreibt. sofern JTL da nicht sehr fein Granular Programmiert hat, und dort sicher geht das alle Schreib Vorgänge die zu einem "Großen Vorgang" gehlören abgeschlossen sind.
Der von christian1701 geteilte Beitrag muss ich in soweit Korrigieren, dass die MsSql Version nicht mal eine Rolle Spielt, da alle das Unterstützen. Es gibt genauso auch Db System die das eben nicht können, z.B. MySql da musst du für eine zuverlässe sicherung (welche auf Dateisystem Ebene Stattfinden würde) die Datenbank am besten beenden, oder man geht hin und Dumpt die DB als SQL Script runter (was dann meistens als Online Variante gemacht wird).
Auf die schnelle habe ich jetzt leider keinen MSDN Artikel gefunden, welcher das bis ins Detail leicht verständlich erklärt, was da DB Seitig alles passiert. Aber gerade wenn man eine "ich beende alles für eine Datensicherung" Szenario verfolgen möchte, müsste man eine reine File Based Sicherung mit herunterfahren der DB machen. Nur so kannst du wirklich sicher gehen, dass keine Daten mehr geschrieben werden. Und gerade sowas geht in größeren Installationen nicht mehr. Da gehen nur Online Sicherungs Michanismen.
Immer wieder wird auf sqlbackupandftp verwiesen. Das nutzt auch nur SQL-Server-Tools, vermutlich sqlcmd.
sqlcmd ist eigentlich nicht mehr als ein Kommandozeilen tool, was SQL an die DB schickt, sqlandbackupftp macht das direkt, da wird kein Tool mehr benutzt, ich kann auch selber hin gehen und der DB mit einem Statement sagen, sicher dich bitte mal, einfach so aus C# heraus mit einem Sql Statement. Ähnliches wie ja auch in SQL Scripten.
Immer liest man hier, keine eigenen scripte ausführen
Dies ist meistens darauf zurück zu führen, dass die wenigsten Wissen, was sind das für Sripte, was machen die da wirklich. Backupen die nur, oder verändern die was. Welcher Normale user kann der SQL noch nie gesehen hat kann das unterscheiden?
In diesem Forum gibt es zum Thema backup nur Vermutungen, Halbwahrheiten und Gerüchte. Fragen dazu werden konsequent ignoriert und bleiben unbeantwortet.
Das mag sein, ist mir auch schon oft aufgefallen. Aber zu all diesen Theman kann man sich auch offiziel Informieren.
Im Großen muss man sagen, die Technologie des Online Backups die Mssql nutzt, ist da sehr zuverlässig, egal ob Express oder Vollversion. Einzige möglichkeit für Inkonsistenzen die auftreten könnten, wäre einfache Programmierfehler seitens JTL.
In meinem genannten Szenario sichere ich jedoch alle 15 Minuten etwas weg (nicht immer alles) sprich ein Maximales Risiko von 15 Minuten an änderungen, solche Inkonsistenzen machen dann natürlich bei Sicherungen alle 24h echt Probleme, bei ale 15min eben nicht mehr.
Dabei sind die Sicherungen je nach Typ eben so aufgebaut, dass diese auf einander aufbauen. Halt ein Vollbackup (sprich klappt Standalone und enthält alle Daten) ein Diff Backup (Enthält alle daten/ änderungen seit dem letzten Vollbackup) und das Transaktions Backup (dieses enthält alle gelaufenen Transaktionen seit der letzten Transaktionssicherung) alle zusammen ermöglichen mir dann einen exakten Zeitpunkt wiederherzustellen. Und gerade die letzte Sicherungsebene geht meistnes in wenigen Sekunden durch.
