abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

Datensicherung Server (Backup) Frage dazu v 10.01

30
letzte Antwort am 02.03.2017 11:39:58 von boomboom
Dieser Beitrag ist geschlossen
0 Personen hatten auch diese Frage
robdust
Einsteiger
Offline Online
Nachricht 1 von 31
7308 Mal angesehen

Hey,

unsere Datensicherung sieht wie folgt aus:

net stop "SQL Server (DATEV_DBENGINE)"

unter Dienste ist das der Anzeigename: SQL Server (DATEV_DBENGINE)
Dienstname: MSSQL$DATEV_DBENGINE

in jedem Fall ist nach Ausführen des o.g. Befehlt der Dienst beendet.

ab dem Moment kann ich mit dem Datev SQL Manager nicht mehr auf die Datenbanken zugreifen, daher gehe ich davon aus, dass diese beendet sind...


Nun sichern wir D:\DATEV und D:\WINDVSW1  inkl. kompletten Unterordnern und darin beinhalteten Dateien auf Band.

Haben nun 10.01 im Einsatz mit dem SQL 2014 nutzen eigentlich nur das Rechnungswesen zum Buchen.

Fehlt noch was? Oder soweit gut?
Im Übrigen erledigt das ein automatischer Script alles. Die Bänder überpüfen routiniert ob die auch die o.g. Inhalte beeinhalten.

theo
Meister
Offline Online
Nachricht 2 von 31
853 Mal angesehen


Fehlt noch was?

Fragen über Fragen. In solchen Fällen hilft prinzipiell nur das magische Orakel aka Praxistest. Folgefragen wie Klappt die recovery überhaupt? Wie lang dauert das? Was kostet mich das? Ist das nicht eigentlich viel zu stressig? u.a. etc werden damit idR auch beantwortet bzw. wie man hier sagen würde, stecksse nich drin musse kucken isso.

Mit nur sauberem DB-Backup-Blanko kriegt man bei Vorgehen nach den Leitfäden normal immer immer die Datev-Datenhaltung zurück, Systemumgebungen + Config sind aber futsch. Dementsprechend ist

soweit gut?

ausdrücklich zu verneinen bzw. wie man hier sagen würde, doppelt gemoppelt hält besser.

Ich nehme dafür Images (mit Acronis) von allen relevanten Systemen + nur die DBs als Backup-Backup. Recovery im Notfall (ohne dass die ganze Hardware+Kanzlei abgefackelt ist) mit SSDs + Umstöpseln für 5 - 10 Systeme  = ca. 2 Std. Läuft

PS Für die Praxistests empfiehlt sich ein gediegenes (urheberrechtlich eindeutig geklärtes dirk.jendritzki ) Ambiente.

in dubio pro theo
0 Kudos
mkolberg
Meister
Offline Online
Nachricht 3 von 31
853 Mal angesehen

Schon einmal den Notfall- getestet?

Einfach die Daten vom Band auf einen Laptop rücksichern, und sehen, ob nach einer DATEV- Installation mit ausgeliehenen Rechten alles läuft. (Natürlich nicht das Bandlaufwerk vom Server zum Einspielen nutzen, denn der Test soll ja einen abhanden gekommenen Server simulieren.)

Wie Theo schrieb, muß unbedingt zusätzlich eine Komplettsicherung laufen, die anschließend auf einen Testgerät rückgesichert wird. (Betriebssystem, Nutzer, Exchange, usw.)

Idealerweise muß dieses Gerät mit diesen Platten starten und fehlerfrei laufen (nicht ins Netz hängen...)

0 Kudos
jan
Fortgeschrittener
Offline Online
Nachricht 4 von 31
853 Mal angesehen

Zuerst sollte der hinnehmbare Datenverlust und die maximale Ausfallzeit definiert werden. Danach kann man dann über das "Was" und "Wie" sprechen.

In einer kleineren Umgebung, wie hier der Fall scheint, würde ich mir ein Recovery Konzept / Szenario überlegen und darauf aufbauend das Backup realisieren. Bevor dann das Backup implementiert wird, sollte das Recovery von verschiedenen Fällen (Einzelne Dateien, ganze DB, DR, etc.) durchgespielt werden.

0 Kudos
agmü
Meister
Offline Online
Nachricht 5 von 31
853 Mal angesehen

Hallo R S,

wir machen seit 2002 die Datensicherung wie von Ihnen beschrieben.  Bisher konnte ich mit dieser Vorgehensweise jeden Crash auffangen.

Als Ergänzung läuft bei uns noch im 3 Stunden Rhythmus eine automatische Datenbanksicherung über den DATEV-SQL-Manager.  Diese Sicherungen werden im laufenden Betrieb erstellt und landen in einem gesonderten Verzeichnis auf der Festplatte.  Das Verzeichnis wird dann auf das externe Medium mit gesichert.

Andreas G. Müller - Rechtsanwalt -
frei nach dem Motto: "Gestern standen wir am Abgrund, heute sind wir einen Schritt weiter."
0 Kudos
Offline Online
Nachricht 6 von 31
853 Mal angesehen

Die Onlinesicherung hat ihren Charme, ich habe mich damit auch auseinandergesetzt, getestet und dann verworfen. Das hat nichts mit versagender Technik sondern ausschließlich mit der Logik der Datenbanken und insbesondere DMS zu tun.

Während der Onlinesicherung erhalten die SQL Datenbanken einen besonderen Betriebsstatus der eine synchrone Sicherung der Daten- und der Transaktionslogdatei ermöglicht. Bei DMS kommt aber noch eine Komponente hinzu, das sind die Containermedien. Hier können während sich die SQL Datei im Sicherungsmodus befindet Dokumente hineingeschrieben werden. Im Fall der Fälle ist der gesicherte Bestand nicht synchron.

0 Kudos
jan
Fortgeschrittener
Offline Online
Nachricht 7 von 31
853 Mal angesehen

Die Einwände sind vollkommen korrekt, allerdings ist agmü​ bei der Sicherung die sich im SQL Manager der DATEV mit der Prüfung einrichten lässt (Meiner Interpretation nach zumindest).

Zur Online-(VSS-)Sicherung:

Mir wäre das in dem Fall allerdings egal. Die Zwischensicherung wären in dem Fall ja "nur" für einzelne Elemente der letzten X-Stunden seit Vollsicherung zurückzuholen. Sollte ich auf dieser Sicherung ein DR durchführen müssen, so wären mir die "paar Änderungen" in den DMS Container egal, da ich dann nur minimalen Datenverlust hätte und die "paar Änderungen" nachgearbeitet werden müssten (Oder ich hole mir die Daten dann aus dem "defekten" System zurück; Zur Not durch Kroll Ontrack o.ä,).

0 Kudos
mkinzler
Meister
Offline Online
Nachricht 8 von 31
853 Mal angesehen

Die Onlinesicherung sollte auch nur ein weiterer Bausteine im Sicherungskonzept sein um z.B. "untertage" Sicherungen zu erstellen.

Bei dem Einsatz von Virtualisierungstechnologie gibt es hierfür aber auch andere u.U. bessere Lösungen.

0 Kudos
Offline Online
Nachricht 9 von 31
853 Mal angesehen

Die Onlinesicherung sollte auch nur ein weiterer Bausteine im Sicherungskonzept sein um z.B. "untertage" Sicherungen zu erstellen.

Bei dem Einsatz von Virtualisierungstechnologie gibt es hierfür aber auch andere u.U. bessere Lösungen.

Leider nicht. DATEV warnt, aus gutem Grund, ja nicht umsonst vor den OpenFile SQL-Agents (die im jeweiligen Umfeld hervorragend arbeiten und je nach Sicherungsprogramm andere Namen tragen) vor Datenverlusten. Der "normale" Sicherungssnapshot der Programme für die Sicherung virtualisierter Maschinen bekommt nämlich den Zustand der offenen SQL-Datenbank nicht mit. Dadurch kann es zu unterschieden zwischen den beiden MS-SQL-Dateien (.mdf und .ldf) kommen.

Ergo bleiben die vom DATEV SQL-Manager eingerichteten Mechanismen der SQL-Onlinesicherung (es entstehen .bak Dateien). Soweit, so gut. Was ich noch nicht herausgefunden habe ist die Behandlung des write-back-Cache im Controller. Diese Caches haben bei neueren Modellen bis zu 2 GB Inhalt.

Von der Logik läuft der Sicherungsprozess für die Zwischensicherung so ab:

1. Start des vom SQL-Managers erzeugten Scripts

a) Prüfung der Datenbanken

b) Sicherungszustand der jeweiligen Datenbank einschalten (jede einzeln)

c) Wegschreiben der Sicherungsdatei

d) Normalbetrieb einschalten

2. Wegschreiben der gesicherten Datenbankdateien mit DMS Daten (wohin auch immer)

Zwischen der Sicherung der DMSDB und den Mediendaten liegt eine zeitliche Lücke die nicht (auch nicht durch einen Datenretter) wiederherstellbar ist - die während der Sperre aufgelaufenen Daten werden in die DMSDB geschrieben während die Dokumente schon lange in den Medien enthalten sind. Eine weitere Lücke entsteht im laufenden Betrieb in der Zeit zwischen dem Abschluss des SQL-Scripts und dem Wegschreiben der DMS-Medien. Auch hier stellt sich die Frage nach dem Zustand der Schreibcaches von Controller und DMS Dienst. Nicht ganz umsonst empfiehlt DATEV ja beim Stoppen der Dienste Reihenfolge und Wartezeiten einzuhalten.

Betrachte ich jedes Programm eigenständig habe ich vermutlich eine relativ konsistente Sicherung, als Gesamtsystem brauche ich einen anderen Blickwinkel.

0 Kudos
jan
Fortgeschrittener
Offline Online
Nachricht 10 von 31
853 Mal angesehen

Also stoppe ich jede Stunde die DB, damit ich eine 100% konsistente Sicherung habe?

Oder nehme ich in Kauf das evtl. ein Dokument oder eine Änderung nicht in der Sicherung enthalten ist und schmeiße eben nicht die Arbeit von vielleicht 100 Leuten von 5 Stunden weg?

Generell werden jetzt aber auch die Online Sicherung im DATEV SQL Manager und eine (konsistente) VSS Online Sicherung durcheinander geworfen.

0 Kudos
agmü
Meister
Offline Online
Nachricht 11 von 31
853 Mal angesehen

Hallo,

es ist richtig, dass die im kurzen zeitlichen Intervall erstellte Sicherung der Datenbanken im DATEV-SQL-Manager angelegt wurde.  Dies hat nichts mit der DATEV-Datensicherung-online gemeinsam.

Diese Funktionalität erspart Ihnen, jan, jede Stunde die DB zu stoppen - und zugleich die Arbeit in der Kanzlei/Unternehmen.

Für die Rücksicherung habe ich folgende Erfahrungen gemacht:

Sollte wirklich das System neu aufgesetzt werden müssen - habe ich bereits mehrfach machen müssen - habe ich nachdem das Betriebssystem wieder gelaufen ist, die aktuellsten Verzeichnisse \\DATEV und \\Windvsw1 auf die Platten kopiert, und danach mit der Installation der DATEV-Programme in der aktuellsten Version begonnen.  Nach der vollständigen Installation habe ich ggf. aktuellere Datenbanken über den DATEV-SQL-Manager eingespielt und erst danach das System wieder für die Arbeit freigegeben.  Zu Inkonsistenzen ist es dabei nicht gekommen.  Verloren waren allenfalls die Daten seit der letzten Sicherung (die sind aber immer verloren, wenn der Sicherungszeitraum zu lange ist).

Andreas G. Müller - Rechtsanwalt -
frei nach dem Motto: "Gestern standen wir am Abgrund, heute sind wir einen Schritt weiter."
0 Kudos
jan
Fortgeschrittener
Offline Online
Nachricht 12 von 31
853 Mal angesehen

Ich stoppe keineswegs jede Stunde die DBs, wäre ja irgendwie doof Wenn mehrfach am Tag gesichert wird, dann online per VSS Backup.

Anonym​ besteht ja nicht zu unrecht darauf, dass eine vollkommen konsistente Sicherung _nur_ mit gestoppten DBs erfolgen kann.

Jetzt kommt mit der Datensicherung Online die dritte Alternativ zur Verwirrung ^^

Ich würde mir die Zeit der Installation vom Server und der DATEV ersparen wollen. Für so ein DR bieten sich entsprechende Images oder Snapshots an. Da ist man um einiges schneller wieder online.

0 Kudos
agmü
Meister
Offline Online
Nachricht 13 von 31
853 Mal angesehen

nach meiner - nicht maßgeblichen Meinung - haben Images/Snapshots den Nachteil, dass tatsächlich Inkonsistenzen in den Datenbanken entstehen können.

Die Problematik des Zeitaufwandes kenne ich.  Allerdings habe ich noch keinen "einfacheren" Weg gefunden um mit derartigen Situationen umgehen zu können.

Andreas G. Müller - Rechtsanwalt -
frei nach dem Motto: "Gestern standen wir am Abgrund, heute sind wir einen Schritt weiter."
0 Kudos
Offline Online
Nachricht 14 von 31
853 Mal angesehen

nach meiner - nicht maßgeblichen Meinung - haben Images/Snapshots den Nachteil, dass tatsächlich Inkonsistenzen in den Datenbanken entstehen können.

Die Problematik des Zeitaufwandes kenne ich. Allerdings habe ich noch keinen "einfacheren" Weg gefunden um mit derartigen Situationen umgehen zu können.

So ist es, willkommen im Klub

0 Kudos
jan
Fortgeschrittener
Offline Online
Nachricht 15 von 31
853 Mal angesehen

Darf ich dem Club auch beitreten? Ich widerspreche euch ja nicht

Wobei die DATEV Datenhaltung generell sehr robust scheint. Ich hatte jedenfalls schon ein paar Fälle, wo die DBs nicht gestoppt wurden und ebenfalls nicht per VSS (Application Aware) gesichert wurde und ein Restore lief ohne Probleme.

Mit VSS lässt sich halt aber auch eine konsistente online Sicherung erstellen:

Ein in sich konsistenter Gesamt-Sicherungsbestand wird nur dann erreicht, wenn zu Beginn des Sicherungslaufs Schattenkopien für sämtliche zu sichernde Datenbank-Dateien angelegt werden. Das kann erreicht werden, wenn die Sicherungssoftware, die Option PrepareToFreeze verwendet. Diese erlaubt, mehrere Datenbanken einzufrieren und gleichzeitig Schattenkopien für diese Datenbanken zu erstellen. Allerdings kann die Anzahl von Datenbanken, die bei diesem Vorgehen gleichzeitig fehlerlos gesichert werden, von System zu System unterschiedlich sein. Dies muss durch einen Test-Sicherungsvorgang kontrolliert werden. Beachten Sie hierzu http://support.microsoft.com/kb/943471/en-us.

https://www.datev.de/dnlexom/client/app/index.html#/document/1080154

greg89
Beginner
Offline Online
Nachricht 16 von 31
853 Mal angesehen

Hallo,

für die Datensicherung soll ja vorher sinnvollerweise eine Datenbankprüfung

laufen. Wenn diese Datenbankprüfung über eine Batch-Datei aufgerufen worden ist,

wie kann man dann automatisch festellen lassen, ob die Prüfung fehlerlos war?

0 Kudos
Offline Online
Nachricht 17 von 31
853 Mal angesehen

Im DATEV SQL-Manager kann man sich die Ergebnisse ansehen, dort den SQL-Server markieren und aus dem Kontextmenü "Ergebnisdatei Datenbankprüfung anzeigen". Das Protokoll wird nur auf dem Rechner angezeigt auf dem der SQL-Server installiert ist.

0 Kudos
Offline Online
Nachricht 18 von 31
853 Mal angesehen

Darf ich dem Club auch beitreten? Ich widerspreche euch ja nicht

Versteht sich von selbst.

boomboom
Meister
Offline Online
Nachricht 19 von 31
853 Mal angesehen

Hallo,

ich muss das kurz nochmal aufrollen.

Es ist richtig, dass die Datenbanken bei VSS erst eingefroren werden müssen. Neue Daten landen dann erst einmal in einem Puffer.. so stell ich mir das vor. Entsprechend sind die Datenbanken konsistent.

Für sich ist die VSS-Sicherung auch eine feine Geschichte, aber:

"DATEV hat die Dateisicherung (VSS) mit verschiedenen Datensicherungsprogrammen getestet. Diese waren zum Teil nicht in der Lage, DATEV-Datenbanken zu sichern. Ursache hierfür ist oft, dass Sicherungssoftware die DATEV-Datenbanknamen falsch behandelt. Der Name der DATEV-Datenbanken entspricht der Formatregel von "delimited identifiers" (siehe hierzu auch: http://msdn.microsoft.com/en-us/library/aa224033(SQL.80).aspx). Diese definiert das Backslash-Zeichen "\" als erlaubtes Zeichen. Bei der Benutzung in Transact-SQL-Statements müssen die "delimited identifiers" in Double-Quotation-Marks (") oder Brackets ([ ]) eingeschlossen werden. Viele Hersteller halten sich jedoch nicht an diesen Standard."

Das ist der Haken daran..

Wenn DATEV alle halbe Jahre mal die geläufigsten Programme testen würde und Rücksprache mit den Herstellern halten würde (und das auch veröffentlichen würde), könnte man in einem einzigen, relativ kleinen Dokument eine sehr gute Sicherungsstrategie vorstellen.

Aber ne.. es muss ja kompliziert sein und dann steht hier was und da was und man muss sich erst sein Konzept zusammenbauen.

Wir wollen kein Rechenzentrum und der ständige Hinweis an allen Ecken nervt auch.

Wir oft habe ich unvollständige Rechnungswesenbestände aus dem Rechenzentrum holen müssen.. nicht nur einmal. 

0 Kudos
Offline Online
Nachricht 20 von 31
853 Mal angesehen

Moin,

die Probleme der Datenbanksicherung sind nicht herstellerspezifisch, ich unterstelle einmal, dass alle Anbieter ihre Hausaufgaben ordentlich gemacht haben und eine offene Datenbank sauber sichern können. Die Probleme liegen in den offenen Transaktionen der Datenbanken selber, egal welches Datenbankprodukt eingesetzt wird, das Backupprogramm kann immer nur den Bestand auf der Platte sichern. Befinden sich jetzt noch Transaktionsdaten im Cache des Programms (der Commit wurde abgesetzt, aber noch nicht vollständig verarbeitet) beginnen die Probleme. Hier setzt die in diesem Thread schon erwähnte freeze Technik an. Die jeweilige Datenbank wird aufgefordert alle offenen Transaktionen zu schreiben und weitere so zu puffern das diese nach Freigabe des freeze geschrieben werden. Soweit, so gut. Habe ich nur eine unabhängige Datenbank (bei MS SQL bestehend aus zwei Dateien im Dateisystem) gehen bei einem folgenden Crash nur die Daten seit der letzten Sicherung flöten.

Nicht nur bei DATEV bestehen die Datenbanken aus diversen physikalischen Dateien die untereinander abhängig sind. Wird eine Datenbankdatei mit freeze gesichert sind evtl. Daten im Puffer deren abhängige Daten bereits in eine andere Datenbank (commit komplett ausgeführt) geschrieben wurden. Diese Datenbank wird dann als nächste im Betrieb gesichert. Schon habe ich immer inkonsistente Daten, bei kleineren Mengen lassen sich die Differenzen mit der Hand bereinigen, bei DATEV fehlen mir aber für "mal eben" die notwendigen Zugänge und Kenntnisse der Abhängigkeiten der Tabellen.

DMS Nutzer haben jetzt noch das Problem mit den in einem anderen System abgelegten Dokumenten, das habe ich weiter oben bereits geschildert. Bei kleineren Umgebungen bleibt wohl nur der Weg über das Stoppen aller Dienste vor der Sicherung, bei größeren Umgebungen muss wohl über eine Replikation nachgedacht werden.

Gruß

KP

0 Kudos
boomboom
Meister
Offline Online
Nachricht 21 von 31
853 Mal angesehen

Gut.. verstanden. Aber ist das nun wirklich so kompliziert?

Sagen wir, der klassische Fall, alle Clients sind Offline und der Kommserver macht sein Ruheschläfchen über Ausschlusszeiten. Zusätzlich werden die Datenbanken eingefroren.

Bekommt man dann über VSS  keine konsistente Onlinesicherung inkl. DMS hin?

0 Kudos
Offline Online
Nachricht 22 von 31
853 Mal angesehen

Und schon sind wir bei dem Spielchen Theorie und Praxis. Eigentlich (also in der Theorie) sollte es funktionieren, in der Praxis eigentlich auch. Aber es heißt ja Datensicherung, da muss es sicher (immer!) sitzen. Immer! Reproduzierbar!

In allen InfoDB Dokumenten schreibt DATEV "Die Existenz ihrer Kanzlei hängt daran".

Dem ist aus meiner Sicht nichts hinzuzusetzen.

Was spricht dagegen, dass, wenn alles schläft, die Dienste per Skript und zeitgesteuert gestoppt werden, die Datensicherung läuft und die Dienste neu gestartet werden? Die von DATEV vorgeschlagenen Waitstates sind Erfahrungswerte die auch große Umgebungen abdecken, wenn alles schläft ... - notwendige automatische Datenbanktasks kann man per Skript außerhalb der Sicherungszeiten anstoßen (auch dafür liefert DATEV Skripte).

0 Kudos
mkinzler
Meister
Offline Online
Nachricht 23 von 31
853 Mal angesehen

Wenn sowieso nicht passiert, dann schadet es auch nicht den Server anzuhalten. Man kann im Sicherungsprogramm u.U. auch einstellen, dass sofort nach Beendung der Sicherung der Server wieder gestartet wird.

0 Kudos
boomboom
Meister
Offline Online
Nachricht 24 von 31
853 Mal angesehen

Für mich sind da mehrere Punkte unvorteilhaft.

Also wenn ich die Scripts an die Sicherungsprogramme hänge und das Sicherungsprogramm selbst hängt irgendwo, gehen die Datenbanken nicht Online.. niemand kann arbeiten.

Wenn ich nun mit der Aufgabenplanung arbeite, kann es sein, dass es sich überschneidet und ich muss wieder nacharbeiten.

Wenn ich spontan um 23.34 Uhr etwas am am Arbeitsplatz schauen will, hab ich keine Chance.. Datenbanken offline. Zusätzlich läuft nach jeder Trennung der Cache leer.. gefühlt dauert es nach jeder Offline-Aktion immer etwas bis man wieder in gewohnter Geschwindigkeit seine Arbeit verrichten kann.

Last but not least bietet ja die DATEV selbst mit Datensicherung-Online ein Programm an, dass nur funktioniert, wenn die Datenbanken überhaupt Online sind.

Es wäre ja wünschenswert, wenn allen Zugang hierzu gewährt werden würde ohne zwingend das RZ nutzen zu müssen.

0 Kudos
Offline Online
Nachricht 25 von 31
853 Mal angesehen

Die SQL Onlinesicherung ist unabhängig von der Datensicherung Online im RZ, sprachlich verunglückt.

Im InfoDB Dokument Tool für SQL können Sie alles über DATEV SQL Datenbanken nachlesen. Wie gesagt SQL Onlinesicherung und Datensicherung Online sind zwei Begriffe die zunächst nichts miteinander zu tun haben.

0 Kudos
boomboom
Meister
Offline Online
Nachricht 26 von 31
853 Mal angesehen

Das ist mir klar.. nur bietet die SQL Onlinesicherung nur Sicherung für SQL-Datenbanken an (während die Datenbanken Online sind). Während z.B. Datensicherung Online (RZ) alles mögliche konsistent sichert (während die Datenbanken Online sind).

So heisst es:

"Die korrekte VSS-Sicherungder DATEV-Daten wird dabei durch einen von DATEV entwickelten Vor-Befehl sichergestellt."

usw und sofort.

Im Grunde steht da, nutzen Sie das Rechenzentrum (für 3-400 euro im Monat), wenn Sie VSS nutzen wollen. Dabei könnte man das Tool auch kastrieren und statt einen Tunnel zum RZ ein lokales Laufwerk zum sichern nutzen. Viele könnten nicht mal die Daso nutzen, weil der Upload nicht genug hergibt.

0 Kudos
Offline Online
Nachricht 27 von 31
853 Mal angesehen

Weiter oben hatte ich schon gesagt, dass es sich um 2 unterschiedliche Verfahren handelt, jetzt müssen Sie nur noch verinnerlichen, dass nicht alles, was DATEV schreibt, auch so ins Deutsche zu übersetzen ist.

In dem genannten Dokument steht, dass die SQL Onlinesicherung eine Vorbedingung für die Onlinesicherung im RZ ist. In dem Dokument steht ausdrücklich, dass die SQL Onlinesicherung auch ohne die folgende RZ Sicherung funktioniert. Wer jetzt noch weiter liest, der stellt fest, dass der Assistent genau einen Eintrag in den Aufgaben von Windows erstellt. Wer jetzt mit diesen Mechanismen umzugehen weis, der kann sich aus der von DATEV erstellten Steuerdatei einen wunderbaren Zeitplan für eigene Onlinesicherungen bauen.

Die vorgenannten Logiklücken bleiben im laufenden Betrieb - daran hat DATEV aber keine Schuld.

Die Nummer mit den Rechten auf den entstehenden .bak Dateien hatten wir in einem anderen Thread.

0 Kudos
boomboom
Meister
Offline Online
Nachricht 28 von 31
853 Mal angesehen

Es ist aber keine konsistente Sicherung.. da sind keine DMS-Container enthalten, nix. Bei Daso soll es aber konsistent sein.

Wir nutzen die Sql-Onlinesicherung seit Jahren.. aber offensichtlich scheint es ja noch genug Verknüpfungen zu anderen Daten zu geben, die ausserhalb des SQL liegen.

Vielleicht kann ein DATEV-Mitarbeiter hierzu mal Stellung nehmen?!

0 Kudos
mkinzler
Meister
Offline Online
Nachricht 29 von 31
853 Mal angesehen

Es ist aber keine konsistente Sicherung.. da sind keine DMS-Container enthalten, nix. Bei Daso soll es aber konsistent sein.

Konsistent bezogen auf die reinen Datenbanken.

Es werden ja nur diese gesichert.

0 Kudos
chrisocki
Meister
Offline Online
Nachricht 30 von 31
853 Mal angesehen

Also, VSS in Verbindung mit SQL-Transaktionen sind m.E. kein Problem, wenn die DaSi-Software den VSS korrekt unterstützt und darüber die einzelnen VSS-Writer informiert. Das gilt sowohl für den DATEV-SQL als auch weiterer Fremdsoftware, die ggf. auch auf MS-SQL aufsetzen. Exchange unterstützt hier genauso eine reine VSS-Sicherung.

Insbesondere bei dem SQL (und darauf weist DATEV im Übrigen hin), gibt es Logbücher im SQL-Programmverzeichniss in denen der SQL sehr genau aufführt, ob bei einer VSS-Sicherung die Datenbanken "eingefrohren" wurden. Hierbei trägt der SQL auch Sorge, dass bei einem Freece die Transaktionen in den beiden Dateien (ldf und mdf) geschrieben wurden, erst dann gibt der SQL die DB für den VSS frei. Wenn dann eine Sicherung der DB's erfolgt ist (steht auch im Logbuch), gehts anschliessend für den SQL normal weiter.

Wir sichern seit Jahren mit verschiedenen Programmen via VSS und haben hier keinerlei Probleme.

DATEV verwendet einen Vorabbefehl bei der DaSi-Online um dem Asigra letztendlich dann auch mitzuteilen, dass die DB's nunmehr bereit zur Sicherung sind. Der SQL selber schreibt nur in die Logbücher und mehr nicht.

Leider haben durchaus einige Anbieter (DaSi-Software) hier das ein oder andere Problem mit dem VSS. Es gilt also, Logbücher sichten und Testrestore durchführen. Und dass bitte nicht unbedingt am Lifesystemmm

Ein Restore war bisher ohne Probleme möglich.

Grüße


Chr.Ockenfels

0 Kudos
30
letzte Antwort am 02.03.2017 11:39:58 von boomboom
Dieser Beitrag ist geschlossen
0 Personen hatten auch diese Frage