Hallo in die Runde,
aus gegebenem Anlass würde ich gerne wissen, welche Datenbanken bei Euch/Ihnen über den automatischen Prüf- und Sicherungslauf, der im DATEV SQL-Server (Administrator) eingerichtet werden kann. Insbesondere ob die Datenbanken der EO dort im Standard gesichert werden.
Nach einem Blick gestern in das Sicherungsverzeichnis habe ich bei uns ein ungutes Gefühl.
Moin @agmü,
welche Datenbanken bei Euch/Ihnen über den automatischen Prüf- und Sicherungslauf,
Alle... Es wird erst einmal unterhalb von %DATEVServer%\windvsw1\DATEV\DATEN alles gesichert.
Komplette Sicherung aller relevanten DATEV-Dateien erstellen
Abweichend von diesem Dokument würde ich mich allerdings mit dem Mechanismus "VSS" beschäftigen, welche die aktuellen Datensicherungsanbieter (Veeam, Acronis, TerrraCloudBackup, DriveSnapShot, etc.) beherrschen.
Datensicherung mit dem Volume Shadow Copy Service (VSS): Erfahrungen aus der Praxis
Beste Grüße
Christian Ockenfels
Ich habe die EO Compact im Einsatz und die *.bak-Dateien (der letzten 3 Sicherungsläufe) sind m.E. im Verzeichnis:
XX:\SQL-Online-Sicherung\XXX\windvsw1\DATEV\DATEN\K0005100\DATA\STANDARD
ich musste bisher (zum Glück) noch nie eine Rücksicherung dieser SQL-Datenbanken machen
... aber wenn man tatsächlich eine Rücksicherung braucht, wird es sicher extrem spannend
Eigentlich sollte man den Notfall auch 'trainieren'.
Die Frage ist nämlich, ob man überhaupt noch etwas mit einer Rücksicherung anfangen kann, die schon mehrere Tage alt ist
Es gibt ja unendlich viele Abhängigkeiten in diesem 'Gestrüpp' von Datenbanken.
Einzelne Datenbanken rückzusichern, wird wohl keine gute Idee sein
@chrisocki schrieb:Moin @agmü,
welche Datenbanken bei Euch/Ihnen über den automatischen Prüf- und Sicherungslauf,
Alle... Es wird erst einmal unterhalb von %DATEVServer%\windvsw1\DATEV\DATEN alles gesichert.
Komplette Sicherung aller relevanten DATEV-Dateien erstellen
davon war ich bis gestern auch ausgegangen. Nur fehlen die EO-Datenbanken in der Standardsicherung, die der SQL-Mananger von DATEV anbietet.
Bedeutet für mich, dass ich wiedereinmal auf die Suche gehen darf - es ist ja sonst nichts zu tun😎.
Danke für die Information
@vogtsburger schrieb:
ich musste bisher (zum Glück) noch nie eine Rücksicherung dieser SQL-Datenbanken machen
... aber wenn man tatsächlich eine Rücksicherung braucht, wird es sicher extrem spannend
Eigentlich sollte man den Notfall auch 'trainieren'.
Die Frage ist nämlich, ob man überhaupt noch etwas mit einer Rücksicherung anfangen, die schon mehrere Tage alt ist
Es gibt ja unendlich viele Abhängigkeiten im diesem 'Gestrüpp' von Datenbanken.
Einzelne Datenbanken rückzusichern, wird wohl keine gute Idee sein
Glücklicherweise gab es keinen Datenchrash, sondern ich wollte dem Service "nur" zur Fehlersuche eine Kopie der Datenbank vor Installation des letzten SR zur Verfügung stellen.
Nur fehlen die EO-Datenbanken in der Standardsicherung, die der SQL-Mananger von DATEV anbietet.
Das ist nur einer der Punkte, warum ich dieser Sicherungsart noch nie vertraut habe. Das macht irgendwas, aber keiner weis so richtig wie und was...
Dann lieber die VSS_Sicherungen. Da muss ich bei der Einrichtung prüfen ob der SQL das auch richtig mitbekommt und dann funktioniert das.
Zumal bei VSS der SQL dann auch seinen aufgebauten Cache weiterhin nutzen kann. Bei einem SQL_Stopp ist das komplett weg.
Und wenn man keine "teure" Lösung nutzen möchte, DriveSnapShot ist wirklich eine Möglichkeit. Dann bedarf es allerdings noch Hirnschmalz um das zu skripten.
Beste Grüße
Christian Ockenfels
@vogtsburger schrieb: ich musste bisher (zum Glück) noch nie eine Rücksicherung dieser SQL-Datenbanken machen
Doch mehrfach...
a) Rücksicherung wegen Hardwaretausch
b) Rücksicherung wegen Benutzerfehler (Bestand in Rewe gelöscht, Buchungsstapel gelöscht, Papierkorb überschrieben, u.s.w.)
Hierbei auch gern schon einzelne Datenbanken (nur Rewe) zurück gesichert und als zusätzliche DB eingehangen um einen Bestand zu restaurieren. Geht, aber man muss schon wissen wie und wo.
Beste Grüße
Christian Ockenfels
@agmü schrieb:
[...]
glücklicherweise gab es keinen Datenchrash, sondern ich wollte dem Service "nur" zur Fehlersuche eine Kopie der Datenbank vor Installation des letzten SR zur Verfügung stellen.
... ich habe den Eindruck, dass die EO-Datenbank die 'gefährlichste' Datenbank 'von Welt' ... ähm ... der Datev-Welt ist
... ohne die EO-Datenbank geht anscheinend gaaar nichts
... bei uns ist es "EO Comfort", aber bei "EO Classic" wird es auch nicht viel anders sein.
"EO" hat 'überall seine Finger im Spiel'
Die Datev interne SQL Prüfung und Sicherung funktioniert und ist vollständig. Besser ist natürlich noch eine Sicherung mit Veeam und Co. per VSS. Vor ein paar Wochen musste ich an einem Einzelplatz (Mittelstand) nach einem Totalverlust des Rechners, auf eine Sicherung aus der Datevsicherung zurückgreifen. Das rücksichern der BAK Dateien war kein Problem und schnell erledigt. Die Datevinstallation lief dann auf dem neuen Rechner fehlerfrei. Ich habe dazu nach der sauberen Neuinstallation (gleicher Softwarestand wie vorher) alle Datenbanken zurück gesichert. Es waren nur wenige Nacharbeiten notwendig. Dazu zählte die Erstbestückung und Nacharbeiten am Auftragswesen. Das LIZPOOL Verzeichnis war noch notwendig und für den Notfall das Nuko Notprogramm.
Gruß blablax
Nachtrag:
@agmü ,
man sollte sich auch immer das Ergebnis der SQL-Prüfung anschauen bzw. zusenden lassen.
Es kann nämlich passieren, dass einzelne Prüfungen nicht erfolgreich sind und dass dann die *.bak-Datei der entsprechenden SQL-Datenbank fehlt
Wenn Probleme mit einzelnen SQL-Datenbanken erst spät(er) entdeckt werden, könnte es 'hässlich' werden
... und wenn es eine der zentralen Datenbanken ist, dann erst recht
... gut möglich, dass Ihre "EO"-Datenbank normalerweise mitgeprüft und mitgesichert wird, aber dass es irgend ein Problem mit ihr gibt und dass die Sicherung/die BAK-Datei nicht erstellt wird
... man kann die 'verdächtige' SQL-Datenbank aber auch einzeln prüfen, auch ad hoc
Hallo,
unabhängig von Datev/Daten ist die Config DB auch nicht zu vernachlässigen.