Thema "Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)" in Technisches zu Software

Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

robdust — Tue, 11 Dec 2018 17:33:48 GMT

Moin,

ich glaube seit dem Update von der Express auf die SE Version läuft bei uns auch der "SQL Server Agent (DATEV_DBENGINE)"

1.) Muss das Teil überhaupt laufen?

2.) Sonst haben wir nur folgenden Script gehabt:

net stop "SQL Server (DATEV_DBENGINE)"

sichern auf Backupserver
net start "SQL Server (DATEV_DBENGINE)"

habe den Script mal manuell gestartet und siehe da, er bemängelt die Abhängigkeit zum oberen Dienst...

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Tue, 11 Dec 2018 19:55:08 GMT

Die Befehle lauten leicht anders. Siehe LEXinform/Info-DB // Punkt 2.4

net stop MSSQL$DATEV_DBENGINE /Y
net start MSSQL$DATEV_DBENGINE /Y
net start SQLAgent$DATEV_DBENGINE

Es gibt aber auch ein fertiges Skript der DATEV, in der auch alle etwaigen Optionen wie DMS, PEA, EMA inkludiert und per rem nur auskommentiert sind.

Ich meine aber, dass DATEV ein Beenden des SQLs gar nicht mehr aus Performancegründen empfiehlt?!

Handelt es sich um eine VM?

Ich hatte folgendes Skript erfolgreich in allen Kanzleien im Einsatz. Einfach in eine Textdatei kopieren und als *.cmd abspeichern.

STOPPEN

@echo off
cls
echo ***********************************************
echo STOPPEN DER DATEV E-Mail Archivierung pro (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz des zusätzlichen Produkts
rem DATEV E-Mail-Archivierung pro. Ist diese im Einsatz
rem entfernen Sie vor den nächsten Zeilen die
rem Auskommentierungsbuchstaben rem
rem net stop ELMPSTImportSv
rem net stop ELMDirectArchiveSv
rem net stop ELMMAPIServices
rem net stop ELMSchedulerSv
rem net stop ELMExchangeSv
rem net stop ELMHandler
rem net stop ELMManagerSv
rem net stop ELMGuardSv
rem net stop PamLogSv
rem net stop ELMPostProcessingSv
rem net stop "DATEV-DMS EMA Dienst"
rem Wartezeit 180 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass das Beenden der DATEV EMA Dienste
rem abgeschlossen ist.
ping localhost -n 10 >NUL
echo ***********************************************
echo STOPPEN DES DATEV DMS POSTEINGANGSASSISTENT (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS Posteingangsassistent. Ist diese nicht im Einsatz
rem ergänzen Sie vor den nächsten Zeilen die
rem Auskommentierungsbuchstaben rem
net stop "DATEV Dokumentenanalyse"
net stop "smartFIX Web Services"
net stop "smartFIX Activator"
rem Wartezeit 180 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass der Start des DATEV DMS Posteingangsassistent
rem abgeschlossen ist.
ping localhost -n 15 >NUL
echo ***********************************************
echo DATEV DMS RECHNUNG DIENST STOPPEN (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS OCR Buchungsassistent. Ist diese nicht im Einsatz
rem ergänzen Sie vor der nächsten Zeile die
rem Auskommentierungsbuchstaben rem
net stop "DATEV DMS Rechnung Dienst"
rem Wartezeit 10 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass das Beenden des DATEV DMS Rechnung Dienstes
rem abgeschlossen ist.
ping localhost -n 10 >NUL
echo ***********************************************
echo DATEV DMS OCR Dienst STOPPEN (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS OCR. Ist diese nicht im Einsatz ergänzen Sie vor der
rem nächsten Zeile den Auskommentierungsbefehl rem.
net stop "DATEV DMS OCR Dienst"
rem Wartezeit 10 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass das Beenden des DATEV DMS OCR Dienstes
rem abgeschlossen ist.
ping localhost -n 10 >NUL
echo ***********************************************
echo DATEV DMS CORESERVER STOPPEN
echo ***********************************************
net stop "DATEV DMS classic Core Server"
echo ***********************************************
echo DATEV SQL Servers STOPPEN
echo ***********************************************
rem Wird der SQL Server Dienst bereits durch eine andere Batch Datei oder durch die
rem Datensicherung selbst gestoppt, kann die folgende Zeile zum Stoppen des SQL Servers
rem gelöscht bzw. auskommentiert werden (Auskommentierung durch rem am Zeilenanfang)
rem HINWEIS: Beim Einsatz der DATEV Datensicherung Online darf der komplette SQL
rem Server nicht gestoppt werden. Beachten Sie hierbei die Abhängigkeiten und
rem Anforderungen der DATEV Datensicherung Online.
net stop MSSQL$DATEV_DBENGINE /Y
echo

STARTEN

net start MSSQL$DATEV_DBEngine
net start SQLAgent$DATEV_DBEngine
ping localhost -n 15 >NUL
echo ***********************************************
echo STARTEN DES DATEV DMS CORE SERVERS
echo ***********************************************
rem Bitte ergänzen Sie in der folgenden Zeile den tatsächlichen
rem Laufwerksbuchstaben
C:\DATEV\PROGRAMM\DATEVDMS\TOOLS\DMS-StartServices.exe
rem Wartezeit 30 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass der Start des DATEV DMS Core Server
rem abgeschlossen ist.
ping localhost -n 15 >NUL
echo ***********************************************
echo STARTEN DES DATEV DMS OCR Dienstes (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS OCR. Ist diese nicht im Einsatz ergänzen Sie vor der
rem nächsten Zeile den Auskommentierungsbefehl rem. Ergänzen Sie
rem den Befehl ebenso, wenn es nicht gewünscht ist
rem (z.B. aus Performancegründen), den OCR Dienst ganztägig zu starten.
net start "DATEV DMS OCR Dienst"
rem Wartezeit 30 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass der Start des DATEV DMS OCR Dienst
rem abgeschlossen ist.
ping localhost -n 30 >NUL
echo ***********************************************
echo STARTEN DES DATEV DMS RECHNUNGSDIENSTES (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS Buchungsassistent. Ist diese nicht im Einsatz
rem ergänzen Sie vor der nächsten Zeile die
rem Auskommentierungsbuchstaben rem
net start "DATEV DMS Rechnung Dienst"
rem Wartezeit 30 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass der Start des DATEV DMS OCR Rechnung Dienst
rem abgeschlossen ist.
ping localhost -n 10 >NUL
echo ***********************************************
echo STARTEN DES DATEV DMS POSTEINGANGSASSISTENT (optional)
echo ***********************************************
rem Nur notwendig beim Einsatz der optionalen Zusatzkomponente
rem DATEV DMS Posteingangsassistent. Ist diese nicht im Einsatz
rem ergänzen Sie vor den nächsten Zeilen die
rem Auskommentierungsbuchstaben rem
net start "smartFIX Activator"
net start "smartFIX Web Services"
net start "DATEV Dokumentenanalyse"
rem Wartezeit 300 Sekunden bis zur nächsten Aktion. Notwendig um
rem sicherzustellen, dass der Start des DATEV DMS Posteingangsassistent
rem abgeschlossen ist.
ping localhost -n 10 >NUL
echo ***********************************************
rem Nur notwendig beim Einsatz des zusätzlichen Produkts
rem DATEV E-Mai-Archivierung pro. Ist diese im Einsatz
rem entfernen Sie vor der nächsten Zeile die
rem Auskommentierungsbuchstaben rem und ergänzen
rem den tatsächlichen Laufwerksbuchstaben
rem LW:\DATEV\PROGRAMM\DATEVDMS\EMA\EMAAdmin\StartEMAServices.exe

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 07:13:07 GMT

Ich meine aber, dass DATEV ein Beenden des SQLs gar nicht mehr aus Performancegründen empfiehlt?!

Hi, genau! Der SQL organisiert sich zur Laufzeit den Cache. Durch einen Dienststop wird dieser komplett gelöscht und im Anschluss neu aufgebaut.

Es wird sich nicht merklich auswirken, aber dennoch sollte mal heute eher in Richtung VSS-Mechanismen gehen, die den SQL im laufenden Betrieb sichern können. Produkte hierzu gibt es genug.

Damit lassen sich auch Sicherung zur Mittagszeit problemlos durchführen, ohne das es bemerkt wird. Das kann dann auch ein Vorteil sein, wenn die Ramsonware o.ä. zuschlägt...

Grüße

Chr.Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

martinkolberg — Wed, 12 Dec 2018 08:52:50 GMT

Hatten wir nicht bei der VSS das Problem, daß nicht eine SQL- Datei gesichert wird, sondern ein Sammelsurium von Dateien betroffen sind, die alle den identischen Zeit Stempel haben sollten.

Man stelle sich vor, während die VSS der Rewe- Datenbank gesichert wird werden Steuerbuchungen übergeben und am Bericht geschrieben (incl. Stammdatenabgleich), die dann alle in die Sicherung einfließen.

Sicherlich, im Falle eines Brandes im Serverraum besser als keine Sicherung... aber …

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 09:05:32 GMT

Jein. VSS heißt ja nur, dass ein Snapshot erstellt wird (ähnlich wie VMware). Heißt, wenn Sie die Sicherung nachts fahren bleibt der SQL gestartet und wird in dem Stand gesichert.

Oder arbeiten viele Leute bei Ihnen auch nachts zur Sicherungszeit?

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 09:25:28 GMT

Hatten wir nicht bei der VSS das Problem, daß nicht eine SQL- Datei gesichert wird, sondern ein Sammelsurium von Dateien betroffen sind, die alle den identischen Zeit Stempel haben sollten.
Man stelle sich vor, während die VSS der Rewe- Datenbank gesichert wird werden Steuerbuchungen übergeben und am Bericht geschrieben (incl. Stammdatenabgleich), die dann alle in die Sicherung einfließen.
Sicherlich, im Falle eines Brandes im Serverraum besser als keine Sicherung... aber …

Hi,

bei einer Sicherung, egal über offline oder via VSS, ist es wichtig, dass die LDF und MDF einen gleichen Zeitstempel haben. Die restlichen Dateien "links und rechts" neben den beiden Datenbankdateien ist "fast" egal. Bei denen handelt es sich um Verbindungsinformationen, Indexdateien, Rechnungsbausteine (EO comfort), etc.. Da kommt es nicht unbedingt auf den Zeitstempel an.

Im Rewe-Datenverzeichniss gibt es noch eine Menge Dateien pro Mandantenbestand. Was hier im einzelnen noch abgelegt wird, kann nur die DATEV sagen. Bei all unseren notwendigen Rücksicherungen haben wir uns aber immer auf die LDF und MDF beschränkt und unsere gesuchten Nutzdaten extrahiert bekommen.

Wie der Kollege Bohle geschrieben hat, wird bei dem VSS ein SnapShot für das gesamte Laufwerk/Server ausgelöst. Der Trick besteht darin, dass die auslösende BackupSoftware nicht nur dem Dateisystem via VSS mitteilt, dass jetzt gesichert wird, sondern auch dem SQL-VSS-Writer die Backup-Aufforderung "zustellt". Wenn das ordentlich erfolgt, geht der SQL dazu über auch die Datenbanken (LDF&MDF) in einen konsistenten Zustand zu bringen, damit die DB's gesichert werden können.

Im Erfolgsfall stehen die entsprechenden Meldungen im SQL-Logbuch oder im Ereignisslogbuch von Windows.

Bei dem Exchange wird z.B. der ESE durch VSS benachrichtigt.

Grüße

Christian Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 10:22:51 GMT

ich habe (ehrlich gesagt) nicht so viel Vertrauen in die Snapshots und in die VSS-Sicherung wie in die Offline-Sicherung (also nach dem Stoppen des SQL-Servers), genauso wenig wie in die DUMP-Dateien bei Systemfehlern.

Bei Online-Sicherungen der SQL-Datenbanken, also ohne Stoppen des SQL-Servers, kann es auch 'gelegentlich' vorkommen, dass die Snapshot-Dateien aus unbekannten Gründen nicht erstellt werden können.

Verursacht denn der Neuaufbau des Caches und dessen 'Organisation' irgendwelche sichtbaren oder relevanten Verzögerungen oder Performance-Einbußen ?

Eigentlich könnte man das Verhalten mit und ohne Stoppen des SQL-Servers selbst testen.

Nachtrag:

... aber ob eine Sicherung einwandfrei funktioniert, wird man erst bru der Rücksicherung feststellen.

Ich habe in der Vergangenheit immer beim Serverwechsel solche alternativen Methoden getestet. Im 'produktiven' Betrieb wäre das riskant. Außerdem steht man i.d.R. unter chronischem Zeitdruck

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 10:28:10 GMT

ich habe (ehrlich gesagt) nicht so viel Vertrauen in die Snapshots und in die VSS-Sicherung

Dann setzen Sie besser auf SmartIT / asp statt eigenem Server, der virtualisiert . Nichts anderes macht man bei VMware / HyperV als dass die virtuellen Server per einer Art VSS gesichert werden. Da wird die ganze virtuelle Maschine eingefroren, weggesichert und alle Änderungen in dieser Zeit werden in eine extra Datei geschrieben, die nach der erfolgreichen Sicherungen wieder in die Ursprungdatei zurückgeschrieben wird.

Klappt zu 99% immer 1A ohne Probleme.

Verursacht denn der Neuaufbau des Caches und dessen 'Organisation' irgendwelche sichtbaren oder relevanten Verzögerungen oder Performance-Einbusen ?

Naja, wenn der SQL gestoppt wird, werden auch alle Informationen, die im RAM stehen gelöscht. Heißt, es muss jeden Tag immer alles neu gecashed werden. Gerade bei großen FiBu Beständen wird das jeden Tag morgens beim 1. Öffnen wohl deutlich länger dauern, da die FiBu, die Sie jeden Tag eines Mandats buchen, jeden Tag neu in den RAM geschrieben werden muss.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

andreashofmeister — Wed, 12 Dec 2018 10:28:58 GMT

ich habe (ehrlich gesagt) nicht so viel Vertrauen in die Snapshots und in die VSS-Sicherung wie in die Offline-Sicherung (also nach dem Stoppen des SQL-Servers), genauso wenig wie in die DUMP-Dateien bei Systemfehlern.
Bei Online-Sicherungen der SQL-Datenbanken, also ohne Stoppen des SQL-Servers, kann es auch 'gelegentlich' vorkommen, dass die Snapshot-Dateien aus unbekannten Gründen nicht erstellt werden können.

Woher nehmen Sie diese Erkenntnis? Haben Sie diesbezüglich entsprechende Erfahrungen? Gab es Störungen aufgrund dieser "Technik"?

Wie wollen Sie einen 24/7/365-Verfügbarkeit ohne diese Technik gewährleisten? Meinen Sie, dass die von Ihnen in einem anderen Betrag diskutierte Option "Smart-IT" anders gesichert wird? Zumindest läuft die DASO (die es ja noch gibt) nicht, wenn der SQL-Server beendet ist.....

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 10:29:03 GMT

Wie ich schon schrieb, der einzelne Benutzer wird es wahrscheinlich nicht direkt merken. Evtl. kommt es zu einer Verzögerung, wenn der SQL die Daten statt aus dem Cache erst von der Platte holen muss.

Je nachdem, wie das System hardwaretechnisch ausgestattet ist, wird es wahrscheinlich gar nicht bemerkt.

Im Zusammenspiel mit den Wartungsplänen könnte sich auch das stoppen/starten des SQL-Dienstes negativ asuwirken.

Die VSS-Mechanismen ist mittlerweile ausgereift. Da bestehen unsererseits keine Bedenken. Insbesondere bei der Verwendung Hyper-V/Veeam und hier die komplette Maschine im Sekundenbruchteilen mit einem SnapShot gesichert wird.

Probleme in diesem Bereich sind mit nicht bekannt.

Chr.Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 10:57:09 GMT

Wenn man (leider) selbst die Verantwortung für die Datensicherung hat, verwendet man eine Methode, die man einschätzen kann und die man schon getestet hat.

In unserem kleinen Client-Server-Netz (17 Clients) brauchen wir keine 24/7/365-Verfügbarkeit. Hier reichen ein paar wenige Nachtstunden, um automatisiert die SQL-Online-Sicherung, die Datev-Offline-Sicherung, die Exchange-Sicherung und die 3rd Party-Daten-Sicherung auszuführen.

Im RZ steht sicher eine zuverlässige Technik zur Verfügung. Wenn die Kanzlei mal (irgendwann) auf ASP umgestellt sein wird, mache ich mir auch keinen Kopf mehr darüber. Die Verantwortung liegt dann in anderen Händen.

Nachtrag:

Meinen Sie, dass die von Ihnen in einem anderen Betrag diskutierte Option "Smart-IT" anders gesichert wird? Zumindest läuft die DASO (die es ja noch gibt) nicht, wenn der SQL-Server beendet ist.....

in diesem Zusammenhang irritiert es mich, dass man bei Smart-IT nur 3 Tage als Systemsicherung (keine Dateisicherung) zur Verfügung hat und dass man zusätzlich noch eine DASO beauftragen muss, um mehr Generationen sichern zu können.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

andreashofmeister — Wed, 12 Dec 2018 11:00:16 GMT

Mit welcher Softwarelösung sichern Sie denn momentan?

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 11:03:44 GMT

... mit Acronis Backup Windows Server 11.7 ....

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 11:05:08 GMT

in diesem Zusammenhang irritiert es mich, dass man bei Smart-IT nur 3 Tage als Systemsicherung (keine Dateisicherung) zur Verfügung hat und dass man zusätzlich noch eine DASO beauftragen muss, um mehr Generationen sichern zu können.

Wieso? Je mehr Tage zurückgesichert werden können, umso mehr Platz braucht DATEV dazu. Selbst mit platzsparenden Maßnahmen (Deduplizierung). Und das lässt sich die DATEV bezahlen. Festplatten kostet auch bei der DATEV noch Geld und da es nicht nur Festplatten sind sondern ein hochkomplexes System, wird es nicht günstiger das RZ speichermäßig aufzurüsten.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

andreashofmeister — Wed, 12 Dec 2018 11:09:04 GMT

Wieso? Je mehr Tage zurückgesichert werden können, umso mehr Platz braucht DATEV dazu. Selbst mit platzsparenden Maßnahmen. Und das lässt sich die DATEV bezahlen. Festplatten kostet auch bei der DATEV noch Geld und da es nicht nur Festplatten sind sondern ein hochkomplexes System, wird es nicht günstiger das RZ speichermäßig aufzurüsten.

Zumal ja DASO preislich schon sehr anspruchsvoll war. Aber ein hervorragendes Produkt! Bis nächstes September 2019.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 11:19:17 GMT

bei ASP hat man allerdings schon standardmäßig 30 Tage 'Datei-Datensicherung' zur Verfügung. Das wird wohl immer ausreichen, um versehentlich gelöschte oder beschädigte Dateien wiederherstellen zu können.

Nochmal zum SQL-Cache.

Wenn ein gewaltiger RAM-Speicherplatz zu Verfügung steht, hat man natürlich große Geschwindigkeitsvorteile.

Herr Bohle, Sie sprechen wahrscheinlich von 128 GB RAM, ich denke momentan an unsere 32 GB RAM, was bei Serverkauf gar nicht so wenig war, was aber heute wahrscheinlich belächelt wird.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 11:27:17 GMT

Herr Bohle, Sie sprechen wahrscheinlich von 128 GB RAM, ich denke momentan an unsere 32 GB RAM, was bei Serverkauf gar nicht so wenig war, was aber heute wahrscheinlich belächelt wird.

Kommt immer auf die Software drauf an, was serverseitig von Microsoft da läuft.

Hardwaremäßig werden alle Serverboards mit genug RAM-Bänken mehr als genug RAM-Platz anbieten können.

Der SBS2011 konnte nur 32GB, Server 2008 R2 auch nur 32GB. Wenn Ihre Hardware entsprechendes Alter hat, wird auch vermutlich ein älteres Windows Server im Einsatz sein. Warum 64GB verbauen, wenn Microsoft nur 32GB nutzen kann?!

Aber ja, ab Server 2012 hat sich da ja einiges getan. Da gibt es auch softwaremäßig keine Limitierung mehr. Je nachdem, ob der Server auch noch andere Aufgaben zu erledigen hat, ob virtualisiert wird, wie groß die Kanzlei und die REWE Datenbank ist ... aber 32GB in einer Kanzlei rein für DATEV würde ich schon einsetzen. Bei steigender Mitarbeiterzahl ruhig auf 48GB oder gar 64GB RAM setzen.

Wenn man neu kauft, wird man wahrscheinlich nicht so schnell Festplatten oder RAM nachstecken. Daher lieber "zu viel" einbauen lassen.

Wie sagt man immer: zu viel RAM oder Speicherplatz gibt es nicht .

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 12:14:52 GMT

chrisocki

... dass das Snapshot in Sekunden erstellt ist, heißt aber nicht, dass die Datensicherung auch sicher gespeichert ist.

Gegen Ransomware hilft wahrscheinlich nur, eine Datensicherung nach extern zu kopieren. Und das dauert eben nicht nur Sekunden, sondern kann bei Komplettsicherungen auch gern mal in den Stundenbereich gehen. Allerdings kann dieses Kopieren nach extern dann im laufenden Betrieb erfolgen und belastet die Server-CPU nicht.

Mehrmals am Tag einen Stand per VSS-Sicherung festzuhalten, ist natürlich sehr 'charmant'. Bei großen Netzwerken bzw. großem Datenbestand hätte man sowieso nicht die Option einer Offline-Sicherungwährend der Arbeitszeit, da man nicht Stunden auf den Neustart des SQL-Servers warten kann.

Nachtrag:

Mein (bisheriges Fazit):

Ich werde nach wie vor jede Nacht so sichern wie bisher, aber ich kann ja zusätzlich tagsüber 1 oder 2 VSS-Snapshots erstellen. Es schadet ja nicht.

Wenn tatsächlich mal während der Arbeitszeit etwas passieren sollt, hätte man dadurch evtl. einen neueren Datenstand zur Verfügung. Da 'Nachstricken' von Buchhaltungen, Erklärungen, Abschlüssen usw. wäre extrem 'hässlich'

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 12:17:46 GMT

Gegen Ransomware hilft wahrscheinlich nur, eine Datensicherung nach extern zu kopieren.

Korrekt. LTO / Bandlaufwerke oder RDX kann man dazu gut nutzen. Aber: auch nur eine Frage der Zeit, bis diese Viren schlau werden und sich erst im System einnisten und dann nach x Tagen erst aktiv werden. Dann sichert man unbemerkt den Virus nach extern mit, der bei einer Rücksicherung auch wieder ausbricht.

Allerdings kann dieses Kopieren nach extern dann im laufenden Betrieb erfolgen und belastet die Server-CPU nicht.

Korrekt. Dann ist ein 24/7 Arbeiten ohne Probleme möglich.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 12:32:04 GMT

chrisocki
... dass das Snapshot in Sekunden erstellt ist, heißt aber nicht, dass die Datensicherung auch sicher gespeichert ist.

Nun ja, wir sichern ersteinmal auf HDD und später auch noch auf Bänder. Und je nach Storage/Umgebung können auch TB's innerhalb von Minuten weggesichert werden. Bei Veeam u.ä. werden zudem nur die geänderten Blöcke gesichert, ist also auch bei grösseren Datenbanken kein wirkliches Zeitproblem...

chrisocki
Gegen Ransomware hilft wahrscheinlich nur, eine Datensicherung nach extern zu kopieren. Und das dauert eben nicht nur Sekunden, sondern kann bei Komplettsicherungen auch gern mal in den Stundenbereich gehen. Allerdings kann dieses Kopieren nach extern dann im laufenden Betrieb erfolgen und belastet die Server-CPU nicht.

Das kommt auf das Datensicherungskonzept an. Wenn ich Netze sehe, bei denen auf USB-HDD gesichert wird (ersteinmal nicht verwerflich) und diese von jedem Benutzer über Freigabe erreichbar sind, dann brauch ich mich nicht zu wundern.

Die Sicherungen müssen immer in einem getrennten Bereich kopiert werden (seperates IP-Netz / VLAN / iSCSI u.s.w.). Das sollte aber für einen verantwortungsvollen Admin kein Problem darstellen. Und wenn dann noch Hyper-V/VMware im Einsatz ist, wo ich die "Produktion" vom Speichernetz trennen kann und sollte, ist es für Ramsomware schwierig an die DaSi-Bestände zu kommen.

Und ob große Netze oder kleine Netze, letztendlich kommt es auf das eigene Sicherheitsbedürfniss an, auf die Frage wie schnell muss ich nach einem Problem wieder online sein, welche Daten muss ich schnell verfügbar für wieviel Tage haben, etc. etc..

Was die Thematik der 3 Tage im SmartIT angeht: Ehrlich, wer möchte eine Rewe-Datenbank älter 3 Tage zurücksichern? Bei DMS, DokOrg oder EO in den wenigsten Fällen... Auch bei uns sind i.d.R. sofort Restores, weil ein Benutzer just einen Stapel oder Fibu zerschossen hat... Da brauchen wir ggf. die Sicherung von 12:00 Uhr MIttag und nicht die vom Vorabend....

Alles in Allem: Komplexes Thema, was nicht mit einem Patentrezept auf alle Umgebungen ausgerollt werden kann...

Grüße

Chr.Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 12:52:40 GMT

das Schlimme bei einem Ransomware-Befall ist, dass das gesamte System nicht mehr 'normal' lauffähig ist. Das Einzige was noch funktioniert ist die Anweisung auf dem Bildschirm, wie man die Bitcoins per Darknet bezahlen soll, um das System wieder zu entschlüsseln.

Ein Mandant hat mir mal das Ergebnis eines Ransomware-Angriffs gezeigt.

Es wird dann auch schwierig oder erstmal unmöglich sein, eine Datensicherung wiederherzustellen, weil die entsprechende Backup-Software auch nicht mehr startet.

Man braucht also unbedingt auch eine Systemsicherung, die ein lauffähiges System wiederherstellen kann, um dann im Anschluss eine Rücksicherung der Daten ausführen zu können.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 13:12:19 GMT

weil die entsprechende Backup-Software auch nicht mehr startet.

Fail. Das geht mal gar nicht.

Man braucht also unbedingt auch eine Systemsicherung,

Deshalb virtualisiere ich dann doch ganz gerne, weil die gesamte Maschine in einer Datei *.vmdk (VMware) oder *.vhdx (HyperV) gespeichert wird, die die BackupSoftware dann einfach "wegkopiert". Dann braucht man der BackupSoftware nur sagen: diese Maschine, letzte Sicherung vor dem Befall, ab geht's. Dann wird die Datei zurückgespielt und schon lässt sich der Server starten, als wenn nichts gewesen wäre.

Bei einer Hardwaremaschine ohne Virtualisierung müsste dann ein aufwändigeres DisasterRecovery durchgeführt werden.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 13:27:54 GMT

das Schlimme bei einem Ransomware-Befall ist, dass das gesamte System nicht mehr 'normal' lauffähig ist. Das Einzige was noch funktioniert ist die Anweisung auf dem Bildschirm, wie man die Bitcoins per Darknet bezahlen soll, um das System wieder zu entschlüsseln.

Ich schliesse mich Herrn Bohle an: Insbesondere bei virtuellen Umgebungen ist mir das "wurscht". Da ist der BackupServer eben nicht "produktiv" incl. seiner Datensicherungsziele. Wenn die Ramsomware das produktive System verschlüsselt, fahre ich den Klumpen runter und ziehe die gesicherte Maschine zurück.

Je nach BackupSoftware geht ein anlaufen der VM's schon während des Restore. D.h. der Restore läuft noch und die Daten kommen quasi hinterher... incl. aller Rechte (NTFS) u.s.w. das geht dann nur mit VSS....

Grüße

Chr.Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 14:09:57 GMT

chrisocki

metalposaunist

Wenn man ein ü50-Netzwerk (also über 50 Clients) zu betreuen hat und als angestellter Systemtechniker Überzeugungskraft und ein hübsches Budget zur Verfügung hat, nimmt man natürlich das beste was man auf dem IT-Markt bekommen kann. Man tut sich auch selbst einen großen Gefallen damit.

Leider kann man/ich mit begrenztem Portemonnaie nicht jeder neuen Technik nachlaufen und die Infrastruktur permanent auf- und umrüsten.

Kleine Kanzleien werden wohl auf wesentlich 'kleinerer Flamme' arbeiten.

Allerdings habe ich auch schon Mandanten-Startups erlebt, die mit 4 Personen 5 Unternehmen gründen und mit einer Infrastruktur wie in einem Großunternehmen arbeiten wollten. Vorsichtshalber habe ich solches Ansinnen abgelehnt. Wenn jemand Interesse hat, kann ich solche Anfragen gerne weitervermitteln

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Wed, 12 Dec 2018 14:19:06 GMT

Leider kann man mit begrenztem Portemonnaie nicht jeder neuen Technik nachlaufen und die Infrastruktur permanent auf- und umrüsten.

Muss man ja auch nicht. Man muss es nur "einmal richtig" machen, damit man sich viel Arbeit erspart. Daher ist Virtualisierung auch ein großer Vorteil und kostet gar nicht mal sehr viel mehr.

Man kauft heute einmal Hard- und Software ein. Die Software kann man bis 2027 nutzen. Die Hardware darunter kann man dank VMware, HyperV und Co. ja einfach austauschen und die Software weiternutzen, als wenn nichts gewesen wäre. Es wird dann einfach nur der Motor ausgetauscht, ohne viel Aufwand.

Bei 50 Usern wird es aber mit 1 Host schon schwierig, dort 2x WTS, 1x DATEV FS, 1x DC und ggf. 1x Exchange unterzubringen.

Dann müsste man schauen, ob man direkt ganz groß geht und ein Storage kauft, auf dem alle Daten liegen oder ob man sich mit 2 Hosts behilft: 1x für WTS und 1x für alles andere. Theoretisch sollte die Gigabit-Verbindung onboard zum WTS-Betrieb mit 50 Usern ausreichen.

Mit 2 Hosts hat man dann aber wieder das Datensicherungsproblem: entweder auch 2x oder eine extra Maschine, die aber dann min. mit 10Gbits zu den Hosts angebunden sein muss.

Vielleicht hat chrisocki eine schicke Lösung?

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Wed, 12 Dec 2018 14:26:14 GMT

Budget ist immer ein Problem. Egal ob grosse oder kleine Netzwerke. Dass IT-Sicherheit Geld kostet ist nunmal Fakt. Es ist auch ziemlich egal ob 1 oder 50 Benutzer betroffen sind. Allein wenn dann schon mehrere Tage Mandanten vertrösten muss, kann ich die Kanzlei wegen Rufschadens dicht machen...

Aber: Auch bei einer wirklich kleinen Umgebung mit 2 Servern (FS + Exchange / Client-Server) kann ich die beiden Server auf einem Hyper-V fahren. Der Hyper-V bekommt auch die DaSi installiert und auf einem zweiten Netzwerk-Interface eine Synology angehangen (direkt per Cross-Link). Dann hab ich den Datenspeicher der VM's schon getrennt und das Datensicherungsziel Synology ist unerreichbar für eine Ramsomware.

Das geht bereits mit einem überschaubaren Budget. Direkte Installationen auf Blech würde ich heute nicht mehr machen wollen. Wie der Kollege Bohle schon ausgeführt hat, ist hier das Desasterrecover einfach zu aufwändig.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Wed, 12 Dec 2018 14:50:53 GMT

chrisocki

metalposaunist

Ich stelle fest, dass es Ihnen beiden jedenfalls nicht an Überzeugung und Überzeugungskraft fehlt

Danke für die Infos

Ich werde zeitnah wohl auch virtualisieren müssen.

Viele Grüße

Michael Vogtsburger

P.S.

Ich werde aber ein paar Szenarien ("was wäre wenn... ") an einem ausgemusterten Kanzlei-Server (SBS 2011) 'durchspielen', bevor ich die Virtualisierung an der Front einsetze.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Thu, 13 Dec 2018 12:51:20 GMT

Der Hyper-V bekommt auch die DaSi installiert und auf einem zweiten Netzwerk-Interface eine Synology angehangen (direkt per Cross-Link). Dann hab ich den Datenspeicher der VM's schon getrennt und das Datensicherungsziel Synology ist unerreichbar für eine Ramsomware.

Jetzt habe ich wenigstens mal eine sinnvolle Verwendung für meine zusätzliche(n) Netzwerkkarte(n) im Server.

Bisher wusste ich tatsächlich nicht, was ich mit einer zusätzlichen Netzwerkkarte im Server machen sollte. Gibt es noch andere Verwendungsmöglichkeiten ?

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Thu, 13 Dec 2018 21:56:26 GMT

Gibt es noch andere Verwendungsmöglichkeiten ?

Mittels NIC-Teaming lassen sich mehrere 1Gbits Anschlüsse zusammenschalten. Dann hat man effektiv 2, 3, 4 ... Gbits zur Verfügung.

Oder: Server via Netzwerkkarte verwalten (HP: iLO, Fujitsu: iRMC) > ausschalten, neustarten, Komponenten auslesen, Bild statt VGA über Java Software sehen, ...

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Fri, 14 Dec 2018 17:38:26 GMT

Mit meinem Schmalspur-Netzwerk-Wissen könnte ich vermutlich das NIC-Teaming nicht optimal einrichten und nutzen, höchstens hinsichtlich Ausfallsicherheit, aber nicht zur Performance-Steigerung. Die 'Partner' im Netzwerk müssten ja dann auch die theoretisch höhere Geschwindigkeit unterstützen und nutzen können (Switch, Router, andere Netzwerk-Geräte, ...)

Aber einen NAS (vielleicht sogar mit Wechselplatten) an eine zweite Netzwerkkarte anschließen, das klingt verlockend.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

jan — Fri, 14 Dec 2018 17:49:26 GMT

Mittels NIC-Teaming lassen sich mehrere 1Gbits Anschlüsse zusammenschalten. Dann hat man effektiv 2, 3, 4 ... Gbits zur Verfügung.

Nein, hat man nicht. Man hat 2 oder 4 mal 1GBit.

Das lässt sich am besten mit einem Zug und Gleisen vergleichen. Sobald ich 2 Gleise habe, fährt ein ICE ja auch nicht plötzlich 660 km/h. Dafür können aber 2 ICE parallel 330 km/h fahren.

Ich würde mir auch die Zeit sparen 1GBE Adapter zu teamen und einfach 10GBE oder größer Adapter nehmen.

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

metalposaunist — Fri, 14 Dec 2018 20:30:49 GMT

Dafür können aber 2 ICE parallel 330 km/h fahren.

Und deshalb hat man dann einen Datendurchsatz von maximal 2x 1Gbits?!

Ich würde mir auch die Zeit sparen 1GBE Adapter zu teamen und einfach 10GBE oder größer Adapter nehmen.

Das sowieso. Aber auch wieder eine falsche Kostenfrage .

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

chrisocki — Mon, 17 Dec 2018 06:43:49 GMT

Ein Grund mehr, auf irgendwelche Vergleiche zu verzichten. Irgendwie interpretiert hier jeder anders...

Aber: Teaming ist nett und gut, aber gibt es tatsächlich eine "Killeranwendung" die das GBit-Interface komplett auslastet? Auch unsere FS, der im Schnitt 100 User abfrühstücken muss, langweilt sich auf dem Netzwerkinterface.

Stress haben da eher die Terminalserver. Aber nicht wegen der Größe von Datenpaketen, sondern eher wegen der Menge an unzähligen kleinen RDP-Paketen. Und denen ist die die Bandbreite eher egal, da geht es eher in Richtung Latenz...

Grüße

Chr.Ockenfels

Re: Datev Sicherung SQL Server Agent (DATEV_DBENGINE)

vogtsburger — Mon, 17 Dec 2018 12:35:52 GMT

Stress haben da eher die Terminalserver. Aber nicht wegen der Größe von Datenpaketen, sondern eher wegen der Menge an unzähligen kleinen RDP-Paketen. Und denen ist die die Bandbreite eher egal, da geht es eher in Richtung Latenz...

Können Sie mit 'resmon' oder anderen Tools erkennen, ob die Terminalserver überfordert oder noch 'im grünen Bereich' sind ?