MS SQL Datenbank wiederherstellen
- Ersteller schapfy
- Erstellt am
Werbung:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.860
Ich bin nur ein Entwickler und DB Backups und MS SQL Administration sind nicht mein Thema.
Anhand Deiner Frage kann man jedenfalls sagen: Nein.
Nein, nicht für die letzten 15 Minuten.
Backup ist nicht nur eine Frage einer handvoll Dateien, wenn auch eine grundlegende. Es ist eine Frage der Strategie bzw. des Bedarfs, der Möglichkeiten und der Ressourcen.
Technisch reichen die genannten Dateien für Restore von MS SQL DB. Und, wenn die Daten nicht so wichtig sind, 4h Datenverlust sind zu verkraften, dann kommst Du auch ohne TRN aus. Wäre nur die Frage, warum man überhaupt Daten speichert, wenn man auch ohne auskommt. (Etwas generalisiert und böse, schließlich verzichtest Du ja freiwillig auf 15 Minuten)
Wenn die Technik klar ist und die Frage der kleinsten vertretbaren Ausfallgröße, solltest Du Dich mit Abläufen und Ressourcen beschäftigen.
Wieviel Daten entstehen beim Vollbackup plus TRN. Wo und wie schnell werden die sicher gelagert. Wie und wie schnell kann man sie wieder einspielen (reiner Transport). Wie lange dauert das Restore aus Vollbackup plus TRN Sequenz? Welche Parameter kann ich nutzen/ändern, um die Gesamtperformance zu verbessern? Welche Ausfallzeit ist überhaupt verkraftbar? Ist das mit den eingesetzten Mitteln realistisch?
Welche Desaster Szenarien gibt es?
- Hardwarefehler
- Softwarefehler
- DML Fehler*
Neben den rein technischen Fragen (MSSQL) gibt es viele Dinge, die um das Backup herum geklärt werden müssen. Wenn Dein Erfahrungsmangel nur MSSQL Server betrifft. Kennst Du das ja vielleicht alles.
*
Nur als Hinweis noch, weil die Frage danach riecht: Du bist nicht auf der sicheren Seite, wenn Du ein Backup mit Point In Time Revovery auf die letzte Sekunde machst / machen kannst. Die Frage ist, wo der Point In Time liegt? (Wie lange nach dem Fehlerfall, wird der Fehler bemerkt?) Bei einem Festplatten Crash ziemlich klar. Bei einem Fehler nach einem Software Update, das zu inkonsistenten Daten führt? Dann willst eigentlich 2 Punkte wieder herstellen. Vor dem Softwareupdate, alle konsistenten Daten, danach alles was "noch brauchbar" ist und der Rest muss bestmöglich rekonstruiert/repariert werden. Aus diesem Szenario ergeben sich viele Implikationen für Fullbackups (BAK), TRN usw., ihre Aufbewahrungsdauer und Taktung. Z.B. die Verwendung älterer Vollbackups, Difs (wenn vorhanden) oder älterer TRN.
Anhand Deiner Frage kann man jedenfalls sagen: Nein.
Nein, nicht für die letzten 15 Minuten.
Backup ist nicht nur eine Frage einer handvoll Dateien, wenn auch eine grundlegende. Es ist eine Frage der Strategie bzw. des Bedarfs, der Möglichkeiten und der Ressourcen.
Technisch reichen die genannten Dateien für Restore von MS SQL DB. Und, wenn die Daten nicht so wichtig sind, 4h Datenverlust sind zu verkraften, dann kommst Du auch ohne TRN aus. Wäre nur die Frage, warum man überhaupt Daten speichert, wenn man auch ohne auskommt. (Etwas generalisiert und böse, schließlich verzichtest Du ja freiwillig auf 15 Minuten)
Wenn die Technik klar ist und die Frage der kleinsten vertretbaren Ausfallgröße, solltest Du Dich mit Abläufen und Ressourcen beschäftigen.
Wieviel Daten entstehen beim Vollbackup plus TRN. Wo und wie schnell werden die sicher gelagert. Wie und wie schnell kann man sie wieder einspielen (reiner Transport). Wie lange dauert das Restore aus Vollbackup plus TRN Sequenz? Welche Parameter kann ich nutzen/ändern, um die Gesamtperformance zu verbessern? Welche Ausfallzeit ist überhaupt verkraftbar? Ist das mit den eingesetzten Mitteln realistisch?
Welche Desaster Szenarien gibt es?
- Hardwarefehler
- Softwarefehler
- DML Fehler*
Neben den rein technischen Fragen (MSSQL) gibt es viele Dinge, die um das Backup herum geklärt werden müssen. Wenn Dein Erfahrungsmangel nur MSSQL Server betrifft. Kennst Du das ja vielleicht alles.
*
Nur als Hinweis noch, weil die Frage danach riecht: Du bist nicht auf der sicheren Seite, wenn Du ein Backup mit Point In Time Revovery auf die letzte Sekunde machst / machen kannst. Die Frage ist, wo der Point In Time liegt? (Wie lange nach dem Fehlerfall, wird der Fehler bemerkt?) Bei einem Festplatten Crash ziemlich klar. Bei einem Fehler nach einem Software Update, das zu inkonsistenten Daten führt? Dann willst eigentlich 2 Punkte wieder herstellen. Vor dem Softwareupdate, alle konsistenten Daten, danach alles was "noch brauchbar" ist und der Rest muss bestmöglich rekonstruiert/repariert werden. Aus diesem Szenario ergeben sich viele Implikationen für Fullbackups (BAK), TRN usw., ihre Aufbewahrungsdauer und Taktung. Z.B. die Verwendung älterer Vollbackups, Difs (wenn vorhanden) oder älterer TRN.
Zu erst: Man sichert die Transaktionspotokolle und Datenbanken, keine TRN oder BAK Dateien. Das sind die Sicherungen!
Zum anderen: Es wurde ja viel geschrieben und durcheinander gebracht. Wichtig: Backup und Verfügbarkeit nicht verwechseln.
Backup nutzt man um bei einem Ausfall ein laufendes System zu bekommen indem man eine Kopie der Produktiven Daten erstellt. Hier sind RTO und RPO wichtig (Zeit zur Wiederherstellung und möglicher Datenverlust).
Ohne diese Anforderungen kein sinnvolles Backup!
Angenommen ich mache einmal am Tag ein Fullbackup meiner DB, dann habe ich max. einen Datenverlust von 1 Tag. Wenn mir das reicht, dann ist alles in Ordnung, wenn nicht muss ich öfters ein Backup machen. Wenn das zu lange dauert macht man Incremetelle / Differenzielle Backups.
Wenn mein Restore (incl. Ersatz Hardware,...) 4h dauert und mir das reicht, dann passt auch diese Komponente, wenn nicht muss mein Restore schneller werden.
Wenn ich keine Daten verlieren darf wird das mit einem Backup nicht funktionieren. Dann kommt man an das Thema HA (Hochverfügbarkeit) und an retundanzen. In einem richtigen Server sind einzelne Komponenten (Netzteil, Netzwerk, Disk) Redundant, aber nicht alles. Dafür gibt es Cluster Lösungen um alles Redundant zu machen.
Jetzt kommen noch die spezialfälle. Bei Datenbanken gibt es die Aufteilung in DB Files und Transaktionsprotokolle. Wenn man nur die DB sichert kann man einen Restore nur zu den Backupzeiten machen. Wenn man die Transaktionsprotokolle hat (wenn diese gesichert werden oder noch verfügbar sind) kann man einen Restore zu einem beliebigen Zeitpunkt (auch zum letzten möglichen) machen.
Neben dem Backup gibt es noch ein Archiv. Das ist auch wieder ein spezialfall und kein Langzeit-Backup. Bei einem langzeitbackup habe ich bestimmte Zeitpunkte im Backup, bei einem Archiv möchte ich aber auch alles was dazwischen war haben.
Kurz: Zu dem Software Update: Hier möchte man ein manuelles Backup vor einem Update machen um bei einem Fehler zu dem vorherigen Zustand zurück zu gehen.
Zum anderen: Es wurde ja viel geschrieben und durcheinander gebracht. Wichtig: Backup und Verfügbarkeit nicht verwechseln.
Backup nutzt man um bei einem Ausfall ein laufendes System zu bekommen indem man eine Kopie der Produktiven Daten erstellt. Hier sind RTO und RPO wichtig (Zeit zur Wiederherstellung und möglicher Datenverlust).
Ohne diese Anforderungen kein sinnvolles Backup!
Angenommen ich mache einmal am Tag ein Fullbackup meiner DB, dann habe ich max. einen Datenverlust von 1 Tag. Wenn mir das reicht, dann ist alles in Ordnung, wenn nicht muss ich öfters ein Backup machen. Wenn das zu lange dauert macht man Incremetelle / Differenzielle Backups.
Wenn mein Restore (incl. Ersatz Hardware,...) 4h dauert und mir das reicht, dann passt auch diese Komponente, wenn nicht muss mein Restore schneller werden.
Wenn ich keine Daten verlieren darf wird das mit einem Backup nicht funktionieren. Dann kommt man an das Thema HA (Hochverfügbarkeit) und an retundanzen. In einem richtigen Server sind einzelne Komponenten (Netzteil, Netzwerk, Disk) Redundant, aber nicht alles. Dafür gibt es Cluster Lösungen um alles Redundant zu machen.
Jetzt kommen noch die spezialfälle. Bei Datenbanken gibt es die Aufteilung in DB Files und Transaktionsprotokolle. Wenn man nur die DB sichert kann man einen Restore nur zu den Backupzeiten machen. Wenn man die Transaktionsprotokolle hat (wenn diese gesichert werden oder noch verfügbar sind) kann man einen Restore zu einem beliebigen Zeitpunkt (auch zum letzten möglichen) machen.
Neben dem Backup gibt es noch ein Archiv. Das ist auch wieder ein spezialfall und kein Langzeit-Backup. Bei einem langzeitbackup habe ich bestimmte Zeitpunkte im Backup, bei einem Archiv möchte ich aber auch alles was dazwischen war haben.
Kurz: Zu dem Software Update: Hier möchte man ein manuelles Backup vor einem Update machen um bei einem Fehler zu dem vorherigen Zustand zurück zu gehen.
castorp
Datenbank-Guru
- Beiträge
- 670
Da muss ich ein wenig widersprechen. Redundante Server sind kein Backup. Sie sind dafür da um die Verfügbarkeit des Gesamtsystems zu sichern. Ein vernünftiges Backup kann damit nicht ersetzt werden.
Mit Backup meine ich das kontinuierliche Sichern jeder Transaktion - nicht das erzeugen eines Dumps ("BAK" Datei)
Mit Backup meine ich das kontinuierliche Sichern jeder Transaktion - nicht das erzeugen eines Dumps ("BAK" Datei)
Wer schreibt denn das Redundante Server mit Backup gleichgestellt sind?
Durch Techniken/Replikation wie Logshipping verschwimmt das Thema Backup und HA etwas. Ist prinzipell ein Backup (Kopie der primären DB) aber auch eine Cluster Lösung mit automatischen Failover (was es bei einem Backup ja nicht gibt).
Durch Techniken/Replikation wie Logshipping verschwimmt das Thema Backup und HA etwas. Ist prinzipell ein Backup (Kopie der primären DB) aber auch eine Cluster Lösung mit automatischen Failover (was es bei einem Backup ja nicht gibt).
akretschmer
Datenbank-Guru
- Beiträge
- 10.376
Sorry, nein. Ein Backup ermöglicht die Wiederherstellung eines FRÜHEREN Zustandes. Dementsprechend hat man auch eine Retention-Policy, z.B. '2weeks'. Das mit der Fähigkeit PITR (Point In Time Recovery) rettet Dir den Arsch, wenn in der Zeit bis max. (im Beispiel) 2 Wochen zurück Du z.B. einen bestimmten Stand wiederherstellen willst.
HA ist was völlig anderes. Hier kannst Du in def. Zeit auf ein Ersatzsystem umschalten. Diese def. Zeit ist typischerweise im Bereich von Millisekunden bis etwas mehr ... abhängig von der Implentierung. HA und Failover stellen Dir aber keinen Stand von letzter Woch Montag 8:45 wieder her.
HA ist was völlig anderes. Hier kannst Du in def. Zeit auf ein Ersatzsystem umschalten. Diese def. Zeit ist typischerweise im Bereich von Millisekunden bis etwas mehr ... abhängig von der Implentierung. HA und Failover stellen Dir aber keinen Stand von letzter Woch Montag 8:45 wieder her.
schapfy
Neuer Benutzer
- Beiträge
- 4
Nabend, wow ich sehe schon das die Themen Backupstrategie und Wiederherstellung nicht ganz trivial ist. Ich muss mir Eure Gedanken nochmals anschauen, desweiteren prüfen wieviel Datenverlust in Zeit wir verkraften könnten das ist ein sehr wichtiger Punkt bei dem Thema. Uns geht es nicht nur um Hard und Softwarefehler sondern auch die Datenbank bei einem möglichen Ramsoware Angriff wieder auf einer neuen Maschine herzustellen, bei solcher Sczenario ist die Windows Maschine welche das Problem hat nicht mehr zu gebrauchen bzw. zu vertrauen und es muß ein neuer Server her, dann würde hier das Thema SQl Recovery zum einsatz kommen.
Grob gesagt habe ich es so verstanden, wenn ich täglich eine Vollsicherung machen würde + die TRNs und BAKs könnte ich theoretisch den SQL bis auf ein paar Minuten evtl. Stunden wiederherstellen, das ist so Korrekt oder ?
Grob gesagt habe ich es so verstanden, wenn ich täglich eine Vollsicherung machen würde + die TRNs und BAKs könnte ich theoretisch den SQL bis auf ein paar Minuten evtl. Stunden wiederherstellen, das ist so Korrekt oder ?
dabadepdu
Datenbank-Guru
- Beiträge
- 1.860
Was wurde denn durcheinander gebracht?
Ja, wenn man weiß, dass aufgrund bestimmter Maßnahmen Probleme zu erwarten sind, möchte man das. Man weiß aber nicht sicher, wann / wodurch Dateninkonsistenzen entstehen. Und man möchte dann trotzdem eine Option haben.
ukulele
Datenbank-Guru
- Beiträge
- 5.321
Ich fürchte nein aber dazu fehlen weiterhin Infos von dir. Ganz wichtig:
- Welche BAK sicherst du? Einfach alle BAK aus dem Verzeichnis des SQL Servers oder erzeugst du wirklich eine BAK, z.B. per SQL Code? Versteh das nicht falsch ich will nicht auf sprachlichen Details rum reiten aber eine Aussage "ja das passt schon" werde ich nicht geben und hoffentlich auch kein Anderer hier sofern man sich nicht sicher ist.
- Du musst dein Backup mind. einmal testen nach Einrichtung. Alles andere ist nicht vertrauenswürdig. Einmal Desaster Recovery auf eine andere VM oder so ist absolut notwendig.
- Eventuell macht eine Backup Software deine Sicherung deutlich robuster. Ja Script Lösungen sind günstig aber theoretisch toll aber nur so lange bis etwas unerwartetes passiert und man im Notfall fest stellen muss das doch irgendwas nicht richtig ausgeführt wurde. Backup Software kommt zumindest mit Logs etc. daher, da sinkt die Warscheinlichkeit das du einen Fehler begehst.
Das ist für die Wiederherstellung völlig ausreichend. Um bis zum Crash die Daten wiederherzustellen mußt Du ein Taillog Backup vor dem Wiederherstellen durchführen, sofern möglich. In der Regel reicht einmal am Tag ein Fullbackup (*.bak) und dann die Transactionslogs. Die würde ich auf 5 min. oder weniger einstellen. Aber das muss man testen.
Ja, ist völlig korrekt so. Aber eben nur den SQL Server, nicht den Server selbst.
Also beim MS SQL Server kann mit einem Backup bis zum Crash recovered werden. Dafür wirds auch gemacht
akretschmer
Datenbank-Guru
- Beiträge
- 10.376
Danke für die Bestätigung. Wäre aber nicht nötig gewesen ;-)
Hm, doch. Schließlich hast Du mit deinem Post hier was anderes behauptet. Ich zitier dich da gerne:
Werbung:
akretschmer
Datenbank-Guru
- Beiträge
- 10.376
Nun ja, Zeitpunkt der Wiederherstellung kann auch unmittelbar vor dem Crash sein. Aber vielleicht machst Du Dir die Mühe mal das zu lesen, worauf ich mich bezog. Könnte hilfreich sein.
Ähnliche Themen
