8
MSSQL-Datenbank sichern übers Internet?
Ich habe ein Problem. Ich versuche eine Datev Kundendatenbank (MSSQL) über das Internet zu sichern. Momentan ist es nur eine Überlegung und ich versuche in die richtige Richtung zu gehen. Ich würde gerne eure Vorgehensweise hören.
Der Kunde hat nur einen begrenzte Upload-Bandbreite zur Verfügung (DSL-1000) deswegen ist es zwingen erforderlich, dass nur die Unterschiede (Delta) übertragen wird. Meiner Überlegungen war jetzt folgende.
1. MSSQL-Datenbank auf einer DVD sichern und auf die NAS in der Firma packen.
2. MSSQL-Datenbank lokal beim Kunden sichern und mit einer Kopie die ebenfalls lokal liegt vergleichen um das Delta herauszufinden.
3. Delta an die Kopie anhängen und auf die NAS beim Kunden packen. (Hier findet also keine Versionisierung statt, man müsst dies mit einem Script machen)
Zur NAS:
Die NAS ist eine Qnap. Hat man zwei dieser Geräte wie in meinem Beispiel können sich diese verschlüsselt replizieren.
4. Nun müssten beide NAS-Geräte miteinander Kontakt aufnehmen um die Datenbank-Files zu vergleichen und ggf. zu updaten.
Soweit zur Theorie.
Um das Delta zwischen den Datenbanken herauszufinden würde ich rsync nutzen. Ich weiß leider nicht ob sich rsync dafür eignet Datenbanken zu sichern, hier würde mich eure Meinung interessieren. Jedenfalls müsste ich von der MSSQL-Datenbank ein DUMP-File erstellen, damit rsync damit arbeiten kann. Aber genau hier fängt mein Problem schon an. Ich muss es entweder übertragen ich nur das Delta, was keine Ausfallsicherheit bietet und keine Backup-Historie oder ich schaffe es irgendwie die Datenbank abzugleichen.
Fällt euch da etwas ein?
1. MSSQL-Datenbank auf einer DVD sichern und auf die NAS in der Firma packen.
2. MSSQL-Datenbank lokal beim Kunden sichern und mit einer Kopie die ebenfalls lokal liegt vergleichen um das Delta herauszufinden.
3. Delta an die Kopie anhängen und auf die NAS beim Kunden packen. (Hier findet also keine Versionisierung statt, man müsst dies mit einem Script machen)
Zur NAS:
Die NAS ist eine Qnap. Hat man zwei dieser Geräte wie in meinem Beispiel können sich diese verschlüsselt replizieren.
4. Nun müssten beide NAS-Geräte miteinander Kontakt aufnehmen um die Datenbank-Files zu vergleichen und ggf. zu updaten.
Soweit zur Theorie.
Um das Delta zwischen den Datenbanken herauszufinden würde ich rsync nutzen. Ich weiß leider nicht ob sich rsync dafür eignet Datenbanken zu sichern, hier würde mich eure Meinung interessieren. Jedenfalls müsste ich von der MSSQL-Datenbank ein DUMP-File erstellen, damit rsync damit arbeiten kann. Aber genau hier fängt mein Problem schon an. Ich muss es entweder übertragen ich nur das Delta, was keine Ausfallsicherheit bietet und keine Backup-Historie oder ich schaffe es irgendwie die Datenbank abzugleichen.
Fällt euch da etwas ein?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 135772
Url: https://administrator.de/contentid/135772
Printed on: April 16, 2024 at 09:04 o'clock
8 Comments
Latest comment
Hallo,
wie groß ist die Datenbank und wieviel ändert sich darin pro zeiteinheit.
grundsätzlich würd ich sagen, dsl 1000, vergiss es.
welchen vorteil hat ne online sicherung gegenüber nem bankschließfach wenn das herunterladen im
recovery fall tage dauert?
wie groß ist die Datenbank und wieviel ändert sich darin pro zeiteinheit.
grundsätzlich würd ich sagen, dsl 1000, vergiss es.
welchen vorteil hat ne online sicherung gegenüber nem bankschließfach wenn das herunterladen im
recovery fall tage dauert?
Die Datenbank ist etwa 2 -4 Gb groß. Es ändert sich etwa jede 10 Minuten etwas. Natürlich nur wenn die Leute daran arbeiten. Genau wegen der geringen Bandbreite will ich ja nur das Delta abgleichen. Im Idealfall ist diese nicht mehr als ein paar KB groß.
Hallo,
eigentlich gibt´s ja für sowas die Datenbankreplikation die im MSSQL eingebaut ist oder
man bastelt sich halt was mit den Log Dateien zusammen.
Aber den Sinn hab ich trotzdem noch nicht verstanden...
eigentlich gibt´s ja für sowas die Datenbankreplikation die im MSSQL eingebaut ist oder
man bastelt sich halt was mit den Log Dateien zusammen.
Aber den Sinn hab ich trotzdem noch nicht verstanden...
Hm vielleicht habe ich es ein bisschen schlecht erklär 
Sinn dahinter:
1. Orginaldatenbank
2. NAS mit der Datenbanksicherung (Kunde)
3. NAS mit Backup vom Vortag (Firma)
Nun soll folgendes passieren. Abgleich der NAS (Kunde) mit der Orginaldatenbank. Versenden der aktuellen Daten von heute auf die NAS (Firma) allerdings nur, wenn sich die Datenbestände unterscheiden. Dieser Vorgang soll über eine Replizierung der beiden NAS-Geräte stattfinden.
Sinn dahinter:
1. Orginaldatenbank
2. NAS mit der Datenbanksicherung (Kunde)
3. NAS mit Backup vom Vortag (Firma)
Nun soll folgendes passieren. Abgleich der NAS (Kunde) mit der Orginaldatenbank. Versenden der aktuellen Daten von heute auf die NAS (Firma) allerdings nur, wenn sich die Datenbestände unterscheiden. Dieser Vorgang soll über eine Replizierung der beiden NAS-Geräte stattfinden.
meine meinung:
vergiss es. 1000 dsl hat wenn du glück hast gerade mal 128kb upload.
selbst wenn die nur mit kanzlei rechnungswesen arbeiten wirst du immer eine schön grosse datenbank zum sichern haben.
was du dir zu nutzen machen kannst: datev bietet auch das gleiche an wie du haben willst. der 1. sync dauert ewig aber dann nur noch die veränderungen. wenn du das umbiegst und nicht zu datev sondern zu euch hast das was du willst. ist aber in fall das es probleme oder eine rücksicherung geben soll von datev nicht supportet.
vergiss es. 1000 dsl hat wenn du glück hast gerade mal 128kb upload.
selbst wenn die nur mit kanzlei rechnungswesen arbeiten wirst du immer eine schön grosse datenbank zum sichern haben.
was du dir zu nutzen machen kannst: datev bietet auch das gleiche an wie du haben willst. der 1. sync dauert ewig aber dann nur noch die veränderungen. wenn du das umbiegst und nicht zu datev sondern zu euch hast das was du willst. ist aber in fall das es probleme oder eine rücksicherung geben soll von datev nicht supportet.
Danke für deine Meinung! Die Funktion hatte ich auch noch im Hinterkopf. Da müsste ich mal schauen ob sich das einfach umlenken lässt. Datev sichert soweit ich weiß auch nicht automatisiert sondern mithilfe des User die Veränderungen nach dem 1.sync.
Du denkst also auch, dass es keinen Sinn macht so einen Aufwand zu betreiben?
Bei der Rücksicherung müsste man schauen in welche Form. Soweit ich weiß werden in .CSV-Dateien gesichert.
Du denkst also auch, dass es keinen Sinn macht so einen Aufwand zu betreiben?
Bei der Rücksicherung müsste man schauen in welche Form. Soweit ich weiß werden in .CSV-Dateien gesichert.
Moin,
es ist die frage wie genau die DB für Datev aufgebaut ist. Danach kannst du dich für eine Sicherungsmaßnahme entscheiden. Denn: Wenn die (was ich glaube) mit Transaktionen arbeitet dann reicht es bei weitem nicht wenn du nur mal eben nen Dump der DB sicherst. Fliegt dir die DB um die Ohren und du hast nur das Dump aber nicht die Transaktionsprotokolle gesichert dann wirst du nur mit sehr viel Mühe was wiederherstellen (und ohne genauere Kenntnisse über Datenbanken wirst du das gar nicht können).
Eine DB sichert man üblicherweise eben aus genau dem Grund nicht mittels Rsync oder sonstigen Dateisystem-Tools sondern mit entsprechenden Backup-Programmen die erstmal die DB praktisch anhalten, die Transaktionen überprüfen und falls alles gut gelaufen ist die Protokolle *kontrolliert* löschen (und dieses auch der DB mitteilen). Erst wenn das passiert ist DANN geht man hin und sichert den Inhalt der Tabellen.
Sollte es aber bei Datev erlaubt/empfohlen sein das du wirklich nur die DB sicherst dann kannst du dir im zweifel auch nen eigenes Script schreiben. Du wirst ja vermutlich Tabellen haben die ewig und 3 Tage immer gleich sind (z.B. Formular-Layouts, Stammdaten der FIrma usw.). Und du wirst Bewegungsdaten haben (Rechnungen, Lieferungen,...). Letztere Daten musst du dann regelmäßig sichern - wobei du dir in einem eigenen Script ja nen Timestamp setzen kannst wann die letzte Sicherung gelaufen ist und schon kannst du deinem Backup-Script sagen das es nur Daten ziehen soll die neuer sind. Ist aber natürlich zimlich aufwendig das ganze. Die alternative wäre das du dir das DB-Dump per ZIP zusammenpacken lässt. Da es sich dabei idR. um eine normale Textfile handelt sollte die Kompression auch recht gut werden - so das du auf jedenfall deutlich weniger Daten zum Übertragen hast. So hast du statt 2 GB dann ggf. noch 200 MB oder so. Dann stellt sich noch die Frage: Wie lang darf die Übertragung dauern OHNE das es jemand stört - und wie sehr benötigen die diese Leitung? Du kannst dort z.B. nen Linux hinstellen und dort mittels Parameter die Übertragungsgeschwindigkeit reduzieren - so das die ggf. noch weiter arbeiten können und dein Backup halt x Std. zum Übertragen benötigt.
Oder du guckst mal warum die Leitung so langsam ist - da es bei den aktuellen Preisen selbst bei SDSL sich idR. nicht lohnt mit 1 Mbit Upload zu arbeiten.
Ich persönlich würde jedoch DRINGEND dazu übergehen das du das Backup mittels eines richtigen Programmes auf einen externen Datenträger in der Firma machen lässt (Band, externe USB-HDD,...). Und je nach Sicherheitsanforderung soll halt ein Mitarbeiter immer das letzte Medium mit nach Hause nehmen so das du immer entweder das Backup vom Vortag hast (bei dem Mitarbeiter) oder von dem Tag davor (das Medium muss ja dann wieder in der Firma liegen). Aber mit so einer kleinen Leitung wird es auf dauer nichts werden wenn du die Daten online übertragen willst - und wenn die Leute dann Tagsüber nich im Netz surfen können gibts auch nur wieder Mecker ;)
es ist die frage wie genau die DB für Datev aufgebaut ist. Danach kannst du dich für eine Sicherungsmaßnahme entscheiden. Denn: Wenn die (was ich glaube) mit Transaktionen arbeitet dann reicht es bei weitem nicht wenn du nur mal eben nen Dump der DB sicherst. Fliegt dir die DB um die Ohren und du hast nur das Dump aber nicht die Transaktionsprotokolle gesichert dann wirst du nur mit sehr viel Mühe was wiederherstellen (und ohne genauere Kenntnisse über Datenbanken wirst du das gar nicht können).
Eine DB sichert man üblicherweise eben aus genau dem Grund nicht mittels Rsync oder sonstigen Dateisystem-Tools sondern mit entsprechenden Backup-Programmen die erstmal die DB praktisch anhalten, die Transaktionen überprüfen und falls alles gut gelaufen ist die Protokolle *kontrolliert* löschen (und dieses auch der DB mitteilen). Erst wenn das passiert ist DANN geht man hin und sichert den Inhalt der Tabellen.
Sollte es aber bei Datev erlaubt/empfohlen sein das du wirklich nur die DB sicherst dann kannst du dir im zweifel auch nen eigenes Script schreiben. Du wirst ja vermutlich Tabellen haben die ewig und 3 Tage immer gleich sind (z.B. Formular-Layouts, Stammdaten der FIrma usw.). Und du wirst Bewegungsdaten haben (Rechnungen, Lieferungen,...). Letztere Daten musst du dann regelmäßig sichern - wobei du dir in einem eigenen Script ja nen Timestamp setzen kannst wann die letzte Sicherung gelaufen ist und schon kannst du deinem Backup-Script sagen das es nur Daten ziehen soll die neuer sind. Ist aber natürlich zimlich aufwendig das ganze. Die alternative wäre das du dir das DB-Dump per ZIP zusammenpacken lässt. Da es sich dabei idR. um eine normale Textfile handelt sollte die Kompression auch recht gut werden - so das du auf jedenfall deutlich weniger Daten zum Übertragen hast. So hast du statt 2 GB dann ggf. noch 200 MB oder so. Dann stellt sich noch die Frage: Wie lang darf die Übertragung dauern OHNE das es jemand stört - und wie sehr benötigen die diese Leitung? Du kannst dort z.B. nen Linux hinstellen und dort mittels Parameter die Übertragungsgeschwindigkeit reduzieren - so das die ggf. noch weiter arbeiten können und dein Backup halt x Std. zum Übertragen benötigt.
Oder du guckst mal warum die Leitung so langsam ist - da es bei den aktuellen Preisen selbst bei SDSL sich idR. nicht lohnt mit 1 Mbit Upload zu arbeiten.
Ich persönlich würde jedoch DRINGEND dazu übergehen das du das Backup mittels eines richtigen Programmes auf einen externen Datenträger in der Firma machen lässt (Band, externe USB-HDD,...). Und je nach Sicherheitsanforderung soll halt ein Mitarbeiter immer das letzte Medium mit nach Hause nehmen so das du immer entweder das Backup vom Vortag hast (bei dem Mitarbeiter) oder von dem Tag davor (das Medium muss ja dann wieder in der Firma liegen). Aber mit so einer kleinen Leitung wird es auf dauer nichts werden wenn du die Daten online übertragen willst - und wenn die Leute dann Tagsüber nich im Netz surfen können gibts auch nur wieder Mecker ;)
Hallo Maretz,
danke für deine Antwort. Klingt sehr einleuchtend. Ich werde es jetzt so machen, dass die Backups per Programm angefertigt werden und auf einen Externen-Datenträger gespeichert. Das mit dem Datev Export werde ich mal nachforschen. Wäre eine Umlenkung wirklich möglich, wäre es Ideal. Das mit dem Internet-Backup der Datenbank habe ich mir aber aus dem Kopf geschlagen Das macht keine Sinn und macht zu viel Aufwand.
Viele Dank für eure Antworten.
danke für deine Antwort. Klingt sehr einleuchtend. Ich werde es jetzt so machen, dass die Backups per Programm angefertigt werden und auf einen Externen-Datenträger gespeichert. Das mit dem Datev Export werde ich mal nachforschen. Wäre eine Umlenkung wirklich möglich, wäre es Ideal. Das mit dem Internet-Backup der Datenbank habe ich mir aber aus dem Kopf geschlagen
Das macht keine Sinn und macht zu viel Aufwand.Viele Dank für eure Antworten.