WaWi Datensicherung / Backup Strategien

[Marc Völker]

AW: WaWi Datensicherung / Backup Strategien

Naja wenn ich damit gemeint sein sollte.

Dann habe ich ja schon drauf hingewiesen
1. Alle 24h Full backup alle 3h Diff, alle 15min Transaktion, sprich runter gebrochen hast du alle 15 Min eine Sicherung.
2. Direkt beim Sichern auch in die Cloud als Storage schreiben (idealerweise auch auf ein Räumlich getrenntes NAS)
3. Der Sicherung sollte bei einem Hardwareausfall dann nichts passieren
4. Dafür ja dann Fallback Hardware. Selbst wenn Full Image des Systems verfügbar dauert es meistens länger, als Ersatz Hardware anzuschließen und Backup der DB einzuspielen.

...ausreichend wäre ja, wenn die datenbank nicht nur immer lokal auf dem server gespeichert wird, sondern immer alles quasi "gespiegelt" übers netz woanders mitabgespeichert wird. mit dieser könnte man dann im fall der fälle einfach wieder diese sicherung auf dem server einspielen?!

Dabei sind wir wieder bei einem Premium Feature, geht wie ich gerade lese am Standard Edition als Publisher, und ab Web Edition als Listener. Sprich sofern du nicht an eine Web Edition kommst. Braucht man schon 2 Standard Editionen.

 

[sergiostiletto]

AW: WaWi Datensicherung / Backup Strategien

bei den premium features sprichst du von ms sql??

 

[sergiostiletto]

AW: WaWi Datensicherung / Backup Strategien

ich könnte auf alles verzichten und auch zeitlich von mir aus 1-2 tage brauchen, bis ich einen neuen server aufgesetzt habe. aber ich würde gerne immer eine bis zum crash oder ausfall eine zusaätzliche, räumlich getrennte sicherung meiner datenbank haben.

 

[sergiostiletto]

AW: WaWi Datensicherung / Backup Strategien

und ein datenbank hosting wäre mir aufgrund der performanceeinbußen übers netz viel zu langsam, besonders im bezug auf ls pos!

 

[Marc Völker]

AW: WaWi Datensicherung / Backup Strategien

Ja meine MsSql, dann les dir bitte einfach meine Postings von anfang an durch, da wird das ziemlich detailiert erklärt.

 

[boaa-group]

AW: WaWi Datensicherung / Backup Strategien

und ein datenbank hosting wäre mir aufgrund der performanceeinbußen übers netz viel zu langsam, besonders im bezug auf ls pos!

LS-POS plant für dieses Jahr aber auch eine Variante die man dann im Hosting betreiben kann, damit wären die Einbußen dort nicht mehr vorhanden.

 

[Marc Völker]

AW: WaWi Datensicherung / Backup Strategien

Täusch dich bitte bei der Variante nicht, es geht dabei nur um die Betriebsmöglichkeit auf Virtuellen Maschinen, gerade bei der Hardwareanbindung wirst du eine LOkale Installation weiterhin benötigen

 

[fav-hosting.online]

AW: WaWi Datensicherung / Backup Strategien

Bzgl. LS-POS, wir hatten das mal eine zeitlang per RDP im Einsatz, lediglich die Druckerumleitung musste aktiviert werden damit die Bons auch gedruckt werden und die Kassenlade sich öffnet.
Wir haben das allerdings wieder verworfen da das öffnen der Kassenlade je nach aktuellem Ping und Auslastung der DSL-Leitung zwischen 1-3 Sekunden gedauert hat. Aber vom Prinzip her ist das leicht und schnell umsetzbar.

 

[gutberle]

Hallo Leute,

obwohl hier schon viel Richtiges und Wertvolles zum Thema Backup-Plan und zur Frage Lokal/Remote/Cloud/DVD gesagt wurde, möchte oder vielmehr MUSS ich diesen Thread doch noch einmal aus der Schublade ziehen, sorry. Warum? - Ganz einfach...

Das Einzige, was hier bisher nicht klar dargelegt werden konnte ist, ob es ÜBERHAUPT sicher ist, im laufenden Betrieb Backups der JTL Wawi DB zu ziehen, was @SebastianB in einem anderen, hier referenzierten Thread, negativ beschieden hatte. Marc hatte hierzu zwar korrekt darauf hingewiesen, dass das, was @SebastianB geschrieben hat, eigentlich nicht (mehr) aktuell sein dürfte, weil die aktuellen Wawi Versionen mit SQL Transaktionen arbeiten und man derlei eher bei den älteren Wawi Versionen vermuten müsste, aber @SebastianB habe ich selber im TeamViewer DB Support erlebt und weiß, dass er weiß, was er sagt/tut und da hat mich seine Äußerung doch ziemlich nervös gemacht.

Also habe ich mir selber angeschaut, wie die aktuelle Wawi (z.Zt. 1.1.4.14) tatsächlich eine Bestellung anlegt und siehe da, es stimmt zwar, was Marc schreibt, es stimmt ABER eben auch zu 100%, was @SebastianB geschrieben hat, denn eine Bestellung wird eben nicht mit einer (1) Stored Procedure in die DB geschrieben, die mit Transaction/Commit abgesichert ist, sondern das Bestellungsgerüst wird über einen einmaligen Aufruf von spBestellungAnlegen angelegt und danach wird jede Bestellposition mit einem paarigen Auftruf von spBestellposAnlegen und spBestellposAendern angelegt, wobei JEDE dieser Stored Procedures individuell abgesichert ist, der Prozess insgesamt aber NICHT.

Damit stimmt das, was @SebastianB im anderen Thread geschrieben hat, zu 100% und Backups im Laufenden Betrieb sind ABSOLUT NICHT SICHER, weil jede dieser Transaktionen für sich mit COMMIT abgeschlossen wird und das Backup somit zu jedem beliebigen Zeitpunkt in der Auftragsanlage greifen kann! Der früheste Zeitpunkt hierfür erzeugt eine Bestellung ohne Positionen und alle weiteren erzeugen eine Bestellung mit fehlenden und potentiell inkonsistenten Bestellpositionen.

Da stellen sich mir vor Sorge (nennen wir es mal Angst...) die Nackenhaare auf und ich würde mich wirklich sehr freuen, wenn sich jemand von JTL (vielleicht @SebastianB?) hier zu Wort melden könnte und diesen Punkt trotz der eigentlich schon klaren Aussage im anderen Thread hier noch einmal bestätigen oder relativieren könnte und für UNS ALLE, die wir auf konsistente Backups angewiesen sind, so etwas wie eine Handlungsanweisung oder ein "Best Practice" geben könnte.

Gruß,
Ingmar

 

[Marc Völker]

Hi

Hallo Leute,

obwohl hier schon viel Richtiges und Wertvolles zum Thema Backup-Plan und zur Frage Lokal/Remote/Cloud/DVD gesagt wurde, möchte oder vielmehr MUSS ich diesen Thread doch noch einmal aus der Schublade ziehen, sorry. Warum? - Ganz einfach...

Das Einzige, was hier bisher nicht klar dargelegt werden konnte ist, ob es ÜBERHAUPT sicher ist, im laufenden Betrieb Backups der JTL Wawi DB zu ziehen, was @SebastianB in einem anderen, hier referenzierten Thread, negativ beschieden hatte. Marc hatte hierzu zwar korrekt darauf hingewiesen, dass das, was @SebastianB geschrieben hat, eigentlich nicht (mehr) aktuell sein dürfte, weil die aktuellen Wawi Versionen mit SQL Transaktionen arbeiten und man derlei eher bei den älteren Wawi Versionen vermuten müsste, aber @SebastianB habe ich selber im TeamViewer DB Support erlebt und weiß, dass er weiß, was er sagt/tut und da hat mich seine Äußerung doch ziemlich nervös gemacht.

Also habe ich mir selber angeschaut, wie die aktuelle Wawi (z.Zt. 1.1.4.14) tatsächlich eine Bestellung anlegt und siehe da, es stimmt zwar, was Marc schreibt, es stimmt ABER eben auch zu 100%, was @SebastianB geschrieben hat, denn eine Bestellung wird eben nicht mit einer (1) Stored Procedure in die DB geschrieben, die mit Transaction/Commit abgesichert ist, sondern das Bestellungsgerüst wird über einen einmaligen Aufruf von spBestellungAnlegen angelegt und danach wird jede Bestellposition mit einem paarigen Auftruf von spBestellposAnlegen und spBestellposAendern angelegt, wobei JEDE dieser Stored Procedures individuell abgesichert ist, der Prozess insgesamt aber NICHT.

Damit stimmt das, was @SebastianB im anderen Thread geschrieben hat, zu 100% und Backups im Laufenden Betrieb sind ABSOLUT NICHT SICHER, weil jede dieser Transaktionen für sich mit COMMIT abgeschlossen wird und das Backup somit zu jedem beliebigen Zeitpunkt in der Auftragsanlage greifen kann! Der früheste Zeitpunkt hierfür erzeugt eine Bestellung ohne Positionen und alle weiteren erzeugen eine Bestellung mit fehlenden und potentiell inkonsistenten Bestellpositionen.

Da stellen sich mir vor Sorge (nennen wir es mal Angst...) die Nackenhaare auf und ich würde mich wirklich sehr freuen, wenn sich jemand von JTL (vielleicht @SebastianB?) hier zu Wort melden könnte und diesen Punkt trotz der eigentlich schon klaren Aussage im anderen Thread hier noch einmal bestätigen oder relativieren könnte und für UNS ALLE, die wir auf konsistente Backups angewiesen sind, so etwas wie eine Handlungsanweisung oder ein "Best Practice" geben könnte.

Gruß,
Ingmar

Hier muss ich doch den einwand bringen. Natürlich ist es es sicherer wenn keine Prozesse auf der DB mehr laufen um eine Sicherung zu fahren. Sollte man tatsächlich zu den Menschen gehören die der Meinung sind einmal am Tag zu sichern, ist es definitiv besser alles zu Stoppen. Den je nach dem, können durch Programmierfehler Inkonsistente Zustände erreicht werden.
Zu der Geschichte, natürlich ist es nicht so einfach möglich eine Bestellung mit nur einer Stored Procedure anzulegen, dafür sind es einfach zu viele Informationen die übergeben werden müssen. Aber den Aufruf mehrerer Stored Procedures kann man sehr gut in einer eigenen Transaktion sichern, und zumindest damals wo ich darauf hinwies war dies sogar der Fall. (Mit entsprechenden Tools kann man aufzeichen was so auf der DB passiert)

Nur in der Realität der Anwendung, kann man so gut wie keine Anwendung immer komplett Herunterfahren um Laufende Backups zu machen.
Wie geht man den nun richtig hin um zu Backupen?
Einmal Täglich ein Backup ist zumindest schon mal mehr als gar keins. Aber Idealerweise arbeitet man sogar noch härter, z.B. macht man zusätzlich zu jedem Daily Backup (was Idealerweise eh zusätzlich zu einem Zeitpunkt gemacht wird, wo eben wenig Last auf der DB ist) noch im Abstand von wenigen Stunden Differenzielle Backups, die einfach nur die Änderungen zum letzten Vollen Backup wieder spiegeln.
Und als ob das reicht. Ne wenn man es richtig Übertreiben will (wobei ich es ehrlich gesagt nicht als Übertreibung sehe) stellt man den Wiederherstellungsmodus auf Vollständig, und sichert auch die Transaktionslogs mit (Achtung wenn auf Vollständig steht ist das Sichern der Logs absolute Pflicht, sonst machen die Logs euch die Platte voll, sind auch nicht auf 10 GB beschränkt)
Diese werden z.B. alle 5 Minuten oder 15 Minuten gesichert.
Nun hat man den Vorteil, selbst wenn JTL hier und da mist Programmiert hat, und nicht genügend Code Blöcke durch eine Umliegende Transaktion gesichert werden. ist die Warscheinlichkeit für einen Datenverlust, bzw Inkonsistente Daten extrems Gering. Und Natürlich gibt es ein Restrisiko. Aber wenn es zu dem Punkt kommt, dass ich eine Datensicherung zurück spielen muss, weil es warum auch nötig ist, da ist unterm Strich sogar ein Fehlerhafter Datensatz Irrelevant, zu den vielen anderen Datensätzen die verloren gegangen sind.

Defakto ist was das Backupen angeht grundsätzlich folgendes immer von oberster Priorität im Falle einer Desaster Recovery

1. Überhaupt ein Backup haben.
2. Das Backup sollte so Jung wie möglich sein. (Was man über sehr weitreichende Backup Pläne Erreichen kann)

Sollte man jedoch ein Backup erzeugen, um z.B. Upzudaten, oder einen Datenbank umzug zu machen. Dann ist es extrems Wichtig das kein anderer mehr Arbeitet.

Dabei gibt es aber meiner Meinung nach auch ein paar Schritte die man lieber Manuell durch führen sollte.

• z.B. Datenbank in Single user Modus setzen (es kann immer nur einer mit der DB Verbunden sein.)
• Datenbank TCP Anschluss beenden und Neustarten (Verhindert auch das sich Remote Clients verbinden können, aber eher was aufwändiger)
• Zu dem wenn man Backup Pläne für Regelmäßige Backups hat, ein sogenanntes Copy-Only Backup erzeugen. Alles andere Zerstört die Konsistenz der backups wenn man das Backup danach weg schmeißt. (Backup wird zum Teil des Backup Plans)

So ist es z.B. bei jedem Kunden von uns, wo wir das Backupen betreuen auch so eingerichtet.
Und Fakt ist, wenn du überhaupt Sicher Backupen willst, kannst du ja nicht alle paar Stunden allen MA der Firma, und so weiter sagen, jetzt bitte für X Minuten die Arbeit einstellen. (Übrigens, X Minuten ist hier sogar sehr gut getroffen, haben schon Backups gesehen die bei keiner 10 GB Datenbank nur ne Minute brauchten, genauso auch welche die 30 Minuten brauchten) Und in der Realität einer Ordentlich eingerichteten Datenbank, wo mit auch gearbeitet wird, sind Down Times für Backups NICHT akzeptabel. Für die geringe Warscheinlichkeit das man eins für nen Desaster Recovery brauch, ist das dann eh Egal.

Achtung, anders sieht es bei Betriebssystem Sicherungen und ähnlichem aus. Mit Betriebssystem Mitteln die DB Sichern erzeugt bei Laufender DB defintiv keine Konsistente Sicherung. Dafür müsste die MsSql mit Volume Schatten Kopien (oder wie das heisst) arbeiten. Das gleiche gilt übrigens auch für das Gerne angebotene. Wir sichern die Ganze VM weg, vieler Rechenzentren. Damit ist die Datenbank auf keinem Fall in einem Konsistenten Zustand. Hier ist es absolut wichtig, auch Ordentliche Backup Pläne einzurichten, und im Recovery Fall auch diese zurück zu spielen.

Liebe Grüße

Marc

 

[gutberle]

Hi Marc,

jojo, möchte ich hier sagen. Alles, was Du oben schreibst, hast Du schon früher hier im Thread schon ausführlich und sehr hilfreich dargelegt, aber um all das, was Du oben schreibst, geht es eben NICHT.

Hier geht es ausschließlich um die Frage, ob die Gesamttransaktionen in der Wawi über explizite TRANSACTION/COMMITs gesichert laufen, oder ob es zwischen den Einzelschritten Zeitlücken gibt. Es kann/darf/soll hier einfach nicht darum gehen, ob man mit Einspielen des nächsten (oder nächsten, oder nächsten) Transaction Logs die eben noch vorhandene(n) Inkonsistenz(en) wieder beheben kann, weil man einfach nicht sehen kann, welcher Stand welche Inkonsistenzen beherbergt und ob überhaupt welche.

Bei einer Auftragsanlage ist das noch einfach, weil die eher seriell ist und im Auftrag selbst eine externe Referenz hat, aber was ist mit all den vielen Housekeeping Transaktionen, etc. Sind die nicht vollständig gesichert, kann nach einem Restore auf einen inkonsistenten Zustand die Hölle los sein...

Deshalb ist es nicht zielführend, auf ein enges Backupschema und die Unmöglichkeit, alle MA alle X Minuten in die Pause zu schicken, hinzuweisen, sondern es muß die Frage geklärt werden, ob JTL die DB Transaktionen bereits jetzt schon insgesamt schützt, oder nicht.

P.S. Ich habe natürlich ein "Tool" zum Tracen benutzt, sehe damit, ohne großen Aufwand zu betreiben, aber natürlich auch nicht zwangsläufig alles. Deshalb kann ich nicht wirklich sagen, ob da nicht noch eine übergeordnete Transaction Kapselung existiert, aber das, was ich sehe, spricht erst einmal dagegen.

Viele Grüße,
Ingmar