SQL Sicherung mit Veeam

[#1]

Hallo,

wir sichern unsere Datev Server (VMware VMs) mit Veeam, aber auf die alte Datev Methode. Das heißt: Datenbanken per Script stoppen, Sichern, Datenbanken wieder hochfahren. Die Datev Dokumente zu Thema SQL Sicherung habe ich durchgearbeitet:

-Dok.-Nr.: 1013210 „Leitfaden zur Datensicherung“

-Dok.-Nr.: 1080154 „Datensicherung mit dem Volume Shadow Copy Service (VSS): Erfahrungen aus der Praxis“

Wir würden jetzt gerne umstellen auf Sicherung der Daten und Datenbanken im laufenden Betrieb, aus mehreren Gründen: die Anwender können durcharbeiten, die Sicherung kann früher erfolgen und daher Zeitfenster besser einhalten, Performancesteigerung durch durchlaufenden SQL Server, usw.

Laut Veeam Dokumentation dürfte das kein Problem sein, wir  sichern auch schon andere SQL Datenbanken "online" ohne Probleme, auch Rücksicherungen sind immer i.O..

Das Testen der Rücksicherung nach Umstellen der Sicherung würden wir natürlich auch machen, aber trotzdem meine Frage an die Community:

Gibt es damit schon Erfahrungen in einem ähnlichen Umfeld, also Datev Server virtuell, Sicherung mit Veeam ohne die Datenbanken zu stoppen?

Vielen Dank im Voraus

[#2 · Accepted solution]

---

@UEAki  schrieb:

Gibt es damit schon Erfahrungen in einem ähnlichen Umfeld, also Datev Server virtuell, Sicherung mit Veeam ohne die Datenbanken zu stoppen?

---

Werden Sie hier nur lesen: läuft. 👍 Bitte daran denken, die Datenbanken trotzdem täglich prüfen zu lassen. 

Ab DVD 14.0 bekommt man auch eine E-Mail Benachrichtigung, über das Prüfergebnis am DATEV SQL. 

[#3]

Wir machen es bereits seit Jahresbeginn im laufenden Betrieb. Bislang keine Probleme. Aber leichte Bauchschmerzen, ob im Ernstfall alles funktionieren würde, kann ich nicht leugnen ...

[#4]

Kann man ja testen 😉. Die SQL-Datenbank 1:1 zurückzuschreiben, geht wegen fehlendem SA-Kennwort vom SQL der DATEV sowieso nicht. Also muss man die *.mdb und *.ldb temporär zurücksichern und manuell dem SQL-Server der DATEV bekannt machen. Klappt das und läuft die tägliche SQL-Prüfung stehen die Chancen sehr gut 👍. 

Aber ich denke, es haben recht wenige eine Aufgabe in der Firma, die Datensicherung allg. auf Lauffähigkeit zu prüfen. Unabhängig der DATEV, die ja nur ein Teil der Gesamtdaten ist. Denke da so an E-Mails aus Exchange wiederherstellen und einzelne Dateien aus ganzen VMs, ... 

[#5]

---

@SteuerRock  schrieb:

Wir machen es bereits seit Jahresbeginn im laufenden Betrieb. Bislang keine Probleme. Aber leichte Bauchschmerzen, ob im Ernstfall alles funktionieren würde, kann ich nicht leugnen ...

---

Ich kann da beruhigen. 

Bei meinem vorherigen AG haben wir auch große K-Rewe-Datenbanken erfolgreich mit Veeam gesichert und auch zurückgeholt. 

Bei einem Restore haben wir einen neuen Datenpfad in den Bestandsdiensten angelegt und die DB aus dem Backup dorthin verbracht (nicht die die CDBINFO überschreiben!). 

Daraus konnten dann problemlos einzelne Mandantenbestände herausgeholt werden. 

Andere DATEV-DB's waren ebenfalls problemlos. Gute Anlaufstelle, ob ein Backup ordnungsgemäß funktioniert, ist das SQL-Error-Log im ProgrammPfad des DATEV-SQL. Dort sollte für die einzelnen DB's der Backupstatus (frozen, backup, resume) auftauchen.

Grüße

Chr.Ockenfels

[#6]

Hatten letztes Jahr zwangsläufig auch umgestellt und meine Freund und Systempartner sagte mir letztens auch, dass die Sicherung korrekt verläuft, auch wenn die DATEV-SQL-Datenbanken nicht gestoppt würden.

Er erklärte mir dies auch, warum das so sei, aber ich kann das hier jetzt nicht richtig wiedergeben.

Wir sichern hier mit ACMEO MSP i.V. Solarwinds . . .

Das flaue Bauchgefühl haben Sie mit Ihrer kurzen Bestätigung, dass eine Sicherung auch grundsätzlich im laufenden SQL-Betrieb möglich ist, deutlich reduziert.

Von der DATEV hört man hier natürlich (und nachvollziehbar) nur "ganz sichere" Aussagen bezüglich "Starten-Sichern-Stoppen" und dass Sicherungen ohne dies Fehler "auslösen" können.

Es wurden ja mit 14.0 auch deutliche Änderungen im SQL - Bereich vorgenommen, vielleicht ist zwischenzeitlich die Sicherung angehängter SQL-Datenbanken möglich; wir sichern bspw. nachts um vier und alle DATEV-Programme sind aus; insofern dürften hier doch auch keine korrumpierende Zugriffe und Störungen ausgelöst werden... aber was weiß ich schon 😉

[#7]

---

@deusex  schrieb:

Hatten letztes Jahr zwangsläufig auch umgestellt und meine Freund und Systempartner sagte mir letztens auch, dass die Sicherung korrekt verläuft, auch wenn die DATEV-SQL-Datenbanken nicht gestoppt würden.

Er erklärte mir dies auch, warum das so sei, aber ich kann das hier jetzt nicht richtig wiedergeben.

---

Aktuelle Sicherungssoftware wird im Regelfall mit den VSS-Mechanismen sichern. Der SQL installiert im Betriebssystem einen "SQL-VSS-Writer", welcher von der Backup-Software genutzt werden kann. 

Wenn nun Veeam o.ä. ein Backup starten, wird über den Writer dem SQL mitgeteilt, dass ein Backup ansteht. Der SQL bringt sodann seine angehängten Datenbanken in einen sicherungsfähigen Zustand (frozen) und meldet dies entsprechend zurück. 

Sodann wird über das Dateisystem (welches auch auf VSS-Meldungen reagiert) ein SnapShot ausgelöst, welcher den aktuellen Zustand aller Dateien umfasst. Alle nun auflaufenden Änderungen werden bei dem Backup nicht berücksichtigt (erst wieder im nächsten Backup) --> SQL-Meldung "backuped".

Nach dem SnapShot werden alle Writer über das erfolgreiche Backup informiert, der SQL bringt seine Datenbanken wieder in den Normalzustand (resumed). 

Der gesamte Vorgang dauert nur Sekunden. Der nun folgende Schreibvorgang auf Backupmedien betrifft nur den SnapShot und kann dauern "so lang er will". Alle folgenden Änderungen werden erst wieder im folgenden Backupvorgang berücksichtigt.

Da dieser VSS-Vorgang irre schnell ist, hab ich bei fast allen Kunden auch eine stündliche Sicherung in Veeam eingerichtet. Merkt kein Benutzer. Und im (hoffentlich) nie auftretenden Fall von Verschlüsselungstrojaner o.ä. kann eine Kanzlei statt auf einen kompletten Arbeitstag auf "nur" Stunden zurückgreifen.

Hierbei sollte die Backupstruktur allerdings vom normalen Arbeitsnetzwerk abgekoppelt sein. Mit Hyper-V oder VMware ist dies kein Problem. Die Backupserver sind in einem eigenen IP-Segment inkl. der angeschlossenen Backupziele. Der Backupserver sichert die VM's auf dem Hyper-V-Host und fertig. Ein Trojaner dürfte hier wenig Möglichkeiten haben... 

Das extra IP-Segment könnte je nach Switch, etc. auch noch in einem eigenen VLAN gebracht werden. Oder komplett eigene Verkabelung. 

---

Es wurden ja mit 14.0 auch deutliche Änderungen im SQL - Bereich vorgenommen, vielleicht ist zwischenzeitlich die Sicherung angehängter SQL-Datenbanken möglich; wir sichern bspw. nachts um vier und alle DATEV-Programme sind aus; insofern dürften hier doch auch keine korrumpierende Zugriffe und Störungen ausgelöst werden... aber was weiß ich schon 😉

---

Es wurde doch nur der SQL-Server aktualisiert. Und der "Neue" kann auch VSS.

Insgesamt würde es mich wundern, wenn die DATEVasp-Abteilung nicht mit gleichen Mechanismen arbeiten würde... da laufen meines Erachtens mit Sicherheit keine Stop-Start-Scripte. Viel zu anfällig.... Wobei große Datenstorages auch noch eigene Möglichkeiten haben... da ist Veeam mit unter nicht mehr notwendig... 

Grüße

Chr.Ockenfels

[#8]

---

@chrisocki  schrieb:
....

Insgesamt würde es mich wundern, wenn die DATEVasp-Abteilung nicht mit gleichen Mechanismen arbeiten würde... da laufen meines Erachtens mit Sicherheit keine Stop-Start-Scripte. Viel zu anfällig....

...

... dann würde es mich aber interessieren, warum in SmartIT jede Nacht in einem Zeitfenster (nach Mitternacht) offenbar der SQL-Server gestoppt wird und ein Arbeiten in den Datev-Anwendungen in diesem Zeitfenster nicht möglich ist.

... bin davon ausgegangen, dass hier auch mit Stoppen/Starten des SQL-Servers gearbeitet wird.

... kann aber auch sein, dass sich hier DatevASP und SmartIT unterscheiden

[#9]

kurze Frage dazu, wir sichern unser FS Hyperv-VM mit Veeam, in ErrorLog gibt es Fehler: 18456, Schweregrad: 14, Status: 5 das ist klar da Datev nutzt eigenen Benutzername für DB und Kennwort haben wir nicht  wenn wir die Sicherung zurücksetzten kann es problematisch sein? mit dem Start der DB?

[#10]

---

@Tissen  schrieb:

kurze Frage dazu, wir sichern unser FS Hyperv-VM mit Veeam, in ErrorLog gibt es Fehler: 18456, Schweregrad: 14, Status: 5 das ist klar da Datev nutzt eigenen Benutzername für DB und Kennwort haben wir nicht  wenn wir die Sicherung zurücksetzten kann es problematisch sein? mit dem Start der DB?

---

Hier als erstes prüfen in welcher Form die Datenbank gesichert wurde. Was sagt der Veeam Report?

Wenn mittels Veeam die komplette virtuelle Maschine gesichert wird kann in einer ruhigen Zeit auch die Datenbank im laufenden Betrieb gesichert werden. Der Snapshotmodus in den die Maschine versetzt wird sorgt für Abschluss der Commitoperation, was an Commits nach diesem Befehl kommt wird ohnehin nicht gesichert.

Das OpenFile Tool von Veeam macht nun nichts anderes als die DATEV SQL Sicherung, beide setzen den SQL-Server (=Programm, nicht die Maschine) in einen bestimmten Zustand und kopieren den Inhalt der Datenbank in eine besondere Datei. Commits werden während dieser Zeit gepuffert und danach wieder in die Datenbank geschrieben. Die Methode sollte gleich sein, der Unterschied liegt im Wissen vom DATEV um die Kombination User/Passwort.