9
Datenmigration MSSQL - Anregungen benötigt
Guten Morgen Kollegen,
ich habe den Umzug einer MSSQL Datenbank (150GB) vor mir und benötige Iden von euch.
Der Umzug ist nicht das Problem sondern die Bedingungen.
Alter und neuer Standort sind zwei verschiedene Firmen in verschiedenen europäischen Ländern,
wobei der alte Standort recht strenge Policies hat.
D.h.
Wir dürfen die Datenbank nicht über das Netzwerk übertragen. Es ist nur ein Transport über externes NAS erlaubt.
Hochladen in Sharpoint o.a. entfällt damit auch.
Daten bis 2 GB dürfen wir über eine secure File transfer Platform übertragen.
Da ich momentan von einem Zeitraum (Begin der Datenkopie auf externes NAS im alten Standort bis Ende Datenkopie im neuen Standort)
von 4 - x Tagen ausgehen muss, habe ich folgende Überlegung.
Ich könnte mir eine leere DB erstellen und in diese nur die neuen bzw. geänderten Daten seit dem Datum der alten Kopie einspielen.
Welche Möglichkeiten gibt es da?
Nicht alle Tabellen haben ein Datumsfeld auf das ich mit beziehen könnte.
Ich suche also eine Möglichkeit für "Übertrage alle neuen/geänderten Daten seit Zeitpunkt in eine separate Datenbank".
Diese würde dann am WE des Finalen Umzugs in 2GB Backup Häppchen zerlegt, über den Secure File Transfer übertragen
und in die schon bestehende Kopie eingespielt.
Ist soetwas mit MSSQL Bordmitteln möglich?
grüße vom it-frosch
Update:
Ich habe die SQL Server Data Tools (SSDT) gefunden über die ich wohl zwei DB vergleichen kann und ein TSQL Skript mit den Differenzen erstellen kann.
Das könnte etwas sein. Ich werde das mal prüfen und hier weiter berichten.
Update II
Wir haben letztendlich die Backup Dateien der DB kopiert.
Hat einige Stunden gedauert aber war der sinnvollste Weg.
ich habe den Umzug einer MSSQL Datenbank (150GB) vor mir und benötige Iden von euch.
Der Umzug ist nicht das Problem sondern die Bedingungen.
Alter und neuer Standort sind zwei verschiedene Firmen in verschiedenen europäischen Ländern,
wobei der alte Standort recht strenge Policies hat.
D.h.
Wir dürfen die Datenbank nicht über das Netzwerk übertragen. Es ist nur ein Transport über externes NAS erlaubt.
Hochladen in Sharpoint o.a. entfällt damit auch.
Daten bis 2 GB dürfen wir über eine secure File transfer Platform übertragen.
Da ich momentan von einem Zeitraum (Begin der Datenkopie auf externes NAS im alten Standort bis Ende Datenkopie im neuen Standort)
von 4 - x Tagen ausgehen muss, habe ich folgende Überlegung.
Ich könnte mir eine leere DB erstellen und in diese nur die neuen bzw. geänderten Daten seit dem Datum der alten Kopie einspielen.
Welche Möglichkeiten gibt es da?
Nicht alle Tabellen haben ein Datumsfeld auf das ich mit beziehen könnte.
Ich suche also eine Möglichkeit für "Übertrage alle neuen/geänderten Daten seit Zeitpunkt in eine separate Datenbank".
Diese würde dann am WE des Finalen Umzugs in 2GB Backup Häppchen zerlegt, über den Secure File Transfer übertragen
und in die schon bestehende Kopie eingespielt.
Ist soetwas mit MSSQL Bordmitteln möglich?
grüße vom it-frosch
Update:
Ich habe die SQL Server Data Tools (SSDT) gefunden über die ich wohl zwei DB vergleichen kann und ein TSQL Skript mit den Differenzen erstellen kann.
Das könnte etwas sein. Ich werde das mal prüfen und hier weiter berichten.
Update II
Wir haben letztendlich die Backup Dateien der DB kopiert.
Hat einige Stunden gedauert aber war der sinnvollste Weg.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665060
Url: https://administrator.de/contentid/665060
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
wie ist denn die Internetverbindung zwischen den Standorten?
Ansonsten das Backup in gesplittete Rar Archive packen und dann in 2 GB Häppchen übertragen und im Anschluss am Zielort wieder entpacken und einspielen.
Gruss
wie ist denn die Internetverbindung zwischen den Standorten?
Ansonsten das Backup in gesplittete Rar Archive packen und dann in 2 GB Häppchen übertragen und im Anschluss am Zielort wieder entpacken und einspielen.
Gruss
Moin,
das klingt möglich aber gefährlich.
Wenn da auch nur eine handvoll Datensätze falsch (zu alt, zu neu, fehlen, doppelt) übertragen werden können die Folgen Katastrophal sein und mit Pech auch erst nach Wochen oder Monaten auffallen.
Ich würde:
Schritt1:
- Dump1 der Datenbanken erstellen
- Hashwert des Dumps1 ermitteln und merken
- Dump1 per NAS zu neuen Zielpunkt übertragen
- Dump1 als Dump1 auf den neuen Server kopieren (nicht einspielen)
- Hashwert Dump1 vergleichen
Schritt2: (später)
- Dump2 der Datenbanken erstellen
- Hashwert des Dumps2 ermitteln und merken
- Diff zwischen Dump1 und Dump2 erstellen lassen
(eigentlich rsync, aber das geht hier ja nicht)
(Es gibt ja tausend Programm mit den denen man Diffs erstellen kann.
- Hashwert des Diffs ermitteln und merken
- Diff komprimieren und über "secure File transfer Platform" übertragen
Schritt3: (drüben)
- Hashwert Diff vergleichen
- Mit Dump1 und Diff Dump2 erzeugen
- Hashwert Dump2 vergleichen
(Damit hast Du den Beweis, dass Dump2 1:1 übertragen wurde)
- Dump einspielen
Stefan
das klingt möglich aber gefährlich.
Wenn da auch nur eine handvoll Datensätze falsch (zu alt, zu neu, fehlen, doppelt) übertragen werden können die Folgen Katastrophal sein und mit Pech auch erst nach Wochen oder Monaten auffallen.
Ich würde:
Schritt1:
- Dump1 der Datenbanken erstellen
- Hashwert des Dumps1 ermitteln und merken
- Dump1 per NAS zu neuen Zielpunkt übertragen
- Dump1 als Dump1 auf den neuen Server kopieren (nicht einspielen)
- Hashwert Dump1 vergleichen
Schritt2: (später)
- Dump2 der Datenbanken erstellen
- Hashwert des Dumps2 ermitteln und merken
- Diff zwischen Dump1 und Dump2 erstellen lassen
(eigentlich rsync, aber das geht hier ja nicht)
(Es gibt ja tausend Programm mit den denen man Diffs erstellen kann.
- Hashwert des Diffs ermitteln und merken
- Diff komprimieren und über "secure File transfer Platform" übertragen
Schritt3: (drüben)
- Hashwert Diff vergleichen
- Mit Dump1 und Diff Dump2 erzeugen
- Hashwert Dump2 vergleichen
(Damit hast Du den Beweis, dass Dump2 1:1 übertragen wurde)
- Dump einspielen
Stefan
ich würde ehrlich gesagt, mit einem SQL Vollbackup arbeiten und dann noch mal ein differenzielles Backup. Das geht mit Bordmitteln des SQL Servers.
Der Trick mit dem differenziellen Backup ist daß es dann alle Daten seit dem letzten Backup enthält. So ein Vollbackup sollte in 30-60 Minuten durch sein, in der Regel sogar schneller aber das ist vom Backupziel abhängig.
Eine 150 GB Datenbank vom MS SQL Server ist komprimiert ca. 15 GB groß, da würde es sich fast lohnen, diese in 1 GB Stückchen zu packen und die Filetransferplatform verwenden. Machen wir auch so, nur daß unsere mittlerweile von 2 auf 30 GB aufgebohrt wurde.
15 GB mach ich z.B. über meinen 50 Mbit Uplink zuhause innerhalb wenigen Stunden.
Wenn das Diff Backup gemacht wird, muß am alten Standort Produktionsstopp sein, das DIFF wird übertragen und am neuen Standort hinzugefügt. ODBC Verbindungen u.s.w., Applikationskonfiguration und so weiter hat man natürlich schon vorbereitet... um die Zeiten zu kennen MUSS man einen Testlauf machen, auch um irgendwelche Fallstricke zu finden - z.B. die ausgehende Bandbreite am alten Standort und die eingehende Bandbreite am neuen Standort muß bekannt sein bzw. wieviel man davon effektiv nutzen kann, die Backupzeiten, die Restorezeiten etc etc
Der Trick mit dem differenziellen Backup ist daß es dann alle Daten seit dem letzten Backup enthält. So ein Vollbackup sollte in 30-60 Minuten durch sein, in der Regel sogar schneller aber das ist vom Backupziel abhängig.
Eine 150 GB Datenbank vom MS SQL Server ist komprimiert ca. 15 GB groß, da würde es sich fast lohnen, diese in 1 GB Stückchen zu packen und die Filetransferplatform verwenden. Machen wir auch so, nur daß unsere mittlerweile von 2 auf 30 GB aufgebohrt wurde.
15 GB mach ich z.B. über meinen 50 Mbit Uplink zuhause innerhalb wenigen Stunden.
Wenn das Diff Backup gemacht wird, muß am alten Standort Produktionsstopp sein, das DIFF wird übertragen und am neuen Standort hinzugefügt. ODBC Verbindungen u.s.w., Applikationskonfiguration und so weiter hat man natürlich schon vorbereitet... um die Zeiten zu kennen MUSS man einen Testlauf machen, auch um irgendwelche Fallstricke zu finden - z.B. die ausgehende Bandbreite am alten Standort und die eingehende Bandbreite am neuen Standort muß bekannt sein bzw. wieviel man davon effektiv nutzen kann, die Backupzeiten, die Restorezeiten etc etc
Zitat von @StefanKittel:
Moin,
das klingt möglich aber gefährlich.
Wenn da auch nur eine handvoll Datensätze falsch (zu alt, zu neu, fehlen, doppelt) übertragen werden können die Folgen Katastrophal sein und mit Pech auch erst nach Wochen oder Monaten auffallen.
[...]Moin,
das klingt möglich aber gefährlich.
Wenn da auch nur eine handvoll Datensätze falsch (zu alt, zu neu, fehlen, doppelt) übertragen werden können die Folgen Katastrophal sein und mit Pech auch erst nach Wochen oder Monaten auffallen.
Ich seh da absolut kein Problem. Für jeden Part Prüfsummen erstellen und schauen ob die Prüfsummen auf der anderen Seite noch passen. Fertig.
Hallo GSMS,
das komprinierte Backup unserer DB ist 90 GB groß aber dann sind es halt ein paar Häppchen mehr.
Da ein diffrenz. Backup nur bis zum nächsten Vollbackup gültig ist, fällt das aus da der Zeitraum zwischen erster DB kopie und
finaler Kopie > 1 Monat beträgt und so lange fahre ich nicht ohne Vollbackup.
Wir machen jede Nacht ein Vollbackup.
trotzdem danke
grüße vom it-frosch
das komprinierte Backup unserer DB ist 90 GB groß aber dann sind es halt ein paar Häppchen mehr.
Da ein diffrenz. Backup nur bis zum nächsten Vollbackup gültig ist, fällt das aus da der Zeitraum zwischen erster DB kopie und
finaler Kopie > 1 Monat beträgt und so lange fahre ich nicht ohne Vollbackup.
Wir machen jede Nacht ein Vollbackup.
trotzdem danke
grüße vom it-frosch
Hallo Stefan,
der Hinweis mit dem Hashwert ist gut.
Ich suche aber zuerst eine Möglichkeit quasi alle Änderungen seit der letzte Vollsicherung in eine extra DB zu spielen.
Da der Zeitraum wahrscheinlich > 1 Monat betragen wird, kann ich hier nicht die das SQL Backup verwenden.
Ansonsten würde ich meine Prod DB > 1 Monat ohne Vollbackup betreiben.
grüße vom it-frosch
der Hinweis mit dem Hashwert ist gut.
Ich suche aber zuerst eine Möglichkeit quasi alle Änderungen seit der letzte Vollsicherung in eine extra DB zu spielen.
Da der Zeitraum wahrscheinlich > 1 Monat betragen wird, kann ich hier nicht die das SQL Backup verwenden.
Ansonsten würde ich meine Prod DB > 1 Monat ohne Vollbackup betreiben.
grüße vom it-frosch
Moin,
einmal folgende Überlegung, was natürlich von den verfügbaren Zeiten abhängt.
Variante 1
Export der DB auf einen USB-Stick (verschlüsselt) an einem Freitag, danach DB herunterfahren (Dienst stoppen)
Stick per Express an den anderen Standort senden (Freitag Abend)
Daten am Sontag am neuen Standort importieren.
Variante 2:
kleine Nextcloud bei euch hinstellen. Die DB dort ablegen (gesplittet/ verschlüsselt) und am Ziel herunterladen - hängt natürlich von eurem Upload ab...
Ggf. den Standort des NC-Speichers ändern!?
Wäre das denkbar?
einmal folgende Überlegung, was natürlich von den verfügbaren Zeiten abhängt.
Variante 1
Export der DB auf einen USB-Stick (verschlüsselt) an einem Freitag, danach DB herunterfahren (Dienst stoppen)
Stick per Express an den anderen Standort senden (Freitag Abend)
Daten am Sontag am neuen Standort importieren.
Variante 2:
kleine Nextcloud bei euch hinstellen. Die DB dort ablegen (gesplittet/ verschlüsselt) und am Ziel herunterladen - hängt natürlich von eurem Upload ab...
Ggf. den Standort des NC-Speichers ändern!?
Wäre das denkbar?
Hallo em-pie,
Variante 2 entfällt auf Grund der Restriktionen.
Wir müssen jeden Datentransfer zuvor anmelden.
Variante 1 ist quasi das was wir mit allen anderen Daten machen.
Ich bin mir nur nicht sicher ob over Night über Ländergrenzen hinweg funktioniert.
Außerdem ist der Aufwand, die Kollegen von einem extra Prozess für die DB zu überzeugen, nicht unerheblich.
Ich will mir erst einmal das SSDT (siehe oben) anschauen. Wenn das so funktioniert wie beschrieben, dass wäre es
für mich die perfekte Lösung, den eigentlich will die DB noch noch einmal komplett übertragen.
Trotzdem danke dir fürs Mitdenken.
grüße vom it-frosch
Variante 2 entfällt auf Grund der Restriktionen.
Wir müssen jeden Datentransfer zuvor anmelden.
Variante 1 ist quasi das was wir mit allen anderen Daten machen.
Ich bin mir nur nicht sicher ob over Night über Ländergrenzen hinweg funktioniert.
Außerdem ist der Aufwand, die Kollegen von einem extra Prozess für die DB zu überzeugen, nicht unerheblich.
Ich will mir erst einmal das SSDT (siehe oben) anschauen. Wenn das so funktioniert wie beschrieben, dass wäre es
für mich die perfekte Lösung, den eigentlich will die DB noch noch einmal komplett übertragen.
Trotzdem danke dir fürs Mitdenken.
grüße vom it-frosch
Hallo it-frosch,
sorry, bissl spät, aber vielleicht ist es ja doch noch nützlich.
Vielleicht wäre ja der Transaktionsprotokollversand (log_shipping) das passende für Dich. Entweder direkt zum neuen Standort oder wenn das nicht möglich ist über eine Datenbankkopie am alten Standort und dann über differenzielles Backup auf dieser Kopie.
Gruß, Mad Max
sorry, bissl spät, aber vielleicht ist es ja doch noch nützlich.
Vielleicht wäre ja der Transaktionsprotokollversand (log_shipping) das passende für Dich. Entweder direkt zum neuen Standort oder wenn das nicht möglich ist über eine Datenbankkopie am alten Standort und dann über differenzielles Backup auf dieser Kopie.
Gruß, Mad Max
