Guten Tag,
wir sichern seit neustem unsere Server mit Veeam (vorher Veritas Backup Exec) und haben hier bei der Wiederherstellung ein paar Probleme feststellen können.
Mit der alten Backupsoftware haben wir vor jedem Backup die SQL Datenbank heruntergefahren und anschließend wieder per Skript gestartet.
Veeam sollte hier in Sachen Komfort einen Schritt weitergehen und die Datenbank dank der VSS im laufenden Betrieb sichern, ohne das wir hier Skripte zum Herunterfahren und Starten der DB in dem Job laufen lassen.
Der Job für die VM läuft ohne Probleme durch, beim Testen der Sicherung bzw. Wiederherstellung der Datenbank konnte er keine passenden credentials finden, mit denen er sich an der SQL DB anmelden konnte.
Der Credentials Test innerhalb von Veeam lief ohne Probleme durch, in den Logs vom Datevserver fand ich folgende Einträge:
Logon Fehler: 18546, Schweregrad: 14, Status: 5
Login failed for user "XXXXXX\XXXXXXX". Ursache: Es konnte keine Anmeldung gefunden werden, die mit dem angegeben Namen übereinstimmt.
Wir nutzen hierfür den Domänenadministrator und haben noch keinen Prüf- und Sicherungsplan erstellt oder die SQL Online Sicherung (weil wir alles über Veeam laufen lassen wollen).
Ist die Prüfung der Datenbank nötig, um die über Veeam konsistent sichern zu können?
Im Forum habe ich bereits einen ähnlichen Beitrag gefunden, allerdings nur ein Szenario mit den Skripten, welche wir abschaffen wollen.
Vielen Dank im Voraus
Gelöst! Gehe zu Lösung.
@timolb schrieb:Wir nutzen hierfür den Domänenadministrator und haben noch keinen Prüf- und Sicherungsplan erstellt oder die SQL Online Sicherung (weil wir alles über Veeam laufen lassen wollen).
Ist die Prüfung der Datenbank nötig, um die über Veeam konsistent sichern zu können?
Unbedingt eine Prüfung einrichten! Ab DVD 14.0 dieses Jahr kann man sich auch per E-Mail benachrichtigen. Mit Veeam hat das aber nichts zu tun. Trotzdem muss man ja defekte SQL Datenbanken reparieren, wenn welche gefunden werden.
Die Wiederherstellung einer SQL Datenbank aus Veeam ist meiner Meinung nach nicht möglich, weil DATEV den SQL mit einem besonderen Kennwort schützt. Die SQL Datenbanken müssen aus meiner Sicht manuell zurückgesichert und von Hand ausgetauscht werden inkl. der zugehörigen LDFs.
EDITH: Außer, Sie nutzen für DATEV Ihren eigenen lizenzierten MS SQL Server. Dann sollte das auch mit Veeam wieder klappen. Selbst lizenzierten Microsoft SQL Server für DATEV-Programme verwenden
Hi,
ein Restore des DATEV-Verzeichnisses MUSS in ein extra Verzeichnis erfolgen. Oder Sie stoppen den SQL und überschreiben alles im Ziel...
Verfahren im WorstCase wäre also:
1. Restore in alternativen Pfad
2. DATEV-SQL stoppen
3. Inhalt des benötigten Pfades mit den Restore-Daten austauschen
4. DTAEV-SQL starten
Für einen Testrestore könnten die Restore-Daten auch ggf. in einem zusätzlichen DATEV-Pfad (Bsp: L:\DATEV\DATEN\RWDAT\TEST\DATA\ --> Vorher in den Bestandsdiensten anlegen und die DB dann im SQL-Mandanter der DATEV trennen) rückgesichert werden. Hierbei die cdbinfo nicht überschreiben! Anschließend die DB wieder anhängen und den Inhalt in den Bestandsdiensten prüfen.
Im WorstCase bin ich immer diesen Weg über einen Test/Restore-Pfad gegangen. In den Bestandsdiensten können dann einzelne Mandantenbestände bequem von dem Pfad in den regulären kopiert werden. Somit setzt man nicht den kompletten Kanzleibestand zurück... wäre auch echt doof... 😉
Im Anschluss den Datenpfad über die Bestandsdienste wieder löschen und gut...
Einen direkten Restore in die DB können Sie nicht durchführen! Das notwendige SA-Kennwort hat nur DATEV. Eine Herausgabe öffnet dann viele weitere Probleme (GoBD, etc.).
Bei einem Backup vorab kontrollieren, ob die VSS-Mechanismen funktionieren. In den SQL-Logs sollten "frozen, backup, etc." für die DATEV-DB's verzeichnet sein.
Grüße
Chr.Ockenfels
Hallo zusammen,
vielen Dank für diese schnelle und ausführliche Antwort.
Hat uns schon direkt weiter geholfen.
In den SQL-Logs sind die "frozen backup etc." Einträge alle vorhanden, lediglich an der Anmeldung von Veeam an der DATEV SQL-DB ist es gescheitert.
Werde nun den DSQLCHECK dann täglich laufen lassen und die Datensicherung über SQL-Online separat sichern.
Hier im Forum wird einem ja schon schneller geholfen als der DATEV Support am Telefon 😉
Der Thread kann geschlossen werden.
Viele Grüße.