none
Gedankenspiel: Worst-Case Szenario Restore Database RRS feed

  • Frage

  • Hallo liebe Leute,

    ich stelle mir folgende Frage, weil ich ein gefährliches Setup erlebt habe.

    Folgende Situation: Es existiert ein Server mit bspws. zwei Datenbanken:

    1. Produktiv-Datenbank
    2. Test-Datenbank

    Anforderung: Nun stelle man sich vor, dass man mehrere Backups der Produktiv-Datenbank hat. Ein älteres Backup soll in die Test-Datenbank eingespielt werden, um diese wieder einigermaßen sauber zu haben.

    Fiktives Szenario: Ein SQL-Server-Admin soll das ältere Backup einspielen, gibt als Ziel aber nicht explizit die Test-Datenbank an und startet den Restore-Vorgang und stellt erst im fortgeschrittenen Zustand der Wiederherstellung fest, dass er/sie einen unglaublichen Fehler gemacht hat, da das ältere Backup in das Produktiv-System eingespielt wird.

    Fragen:

    1. Was passiert, wenn der Import während des laufenden Restores manuell durch den Admin abgebrochen wird?
    2. Handelt es sich bei dem Import um eine Transaktion, die durch den Abbruch rückgängig gemacht wird?
    3. Wird die Produktiv-Datenbank dadurch beschädigt?
    4. Welche Maßnahmen wären in einer solchen Situation die best practice? (Flucht nach Kuba wäre keine Option :D)

    Ich weiß, dass man so etwas nicht macht. Allerdings kann ich mir vorstellen, dass so etwas in der Vergangenheit schon vorgekommen ist und auch immer wieder mal vorkommen wird. Mich würde interessieren, wie man sich als Admin in einer solchen Situation verhält und welche Maßnahmen man ergreifen kann, um das Schlimmste zu verhinden.

    Ich würde mich sehr über zahlreiche Feedback freuen und verbleibe

    mit freundlichen Grüßen

    Phido

    Dienstag, 9. Juli 2019 15:27

Alle Antworten

  • Die Frage stellt sich i.d.R. nicht, da ein Restore einer Datenbank niemals auf das Original gemacht wird (werden sollte).
    Ist der Restore erforgreich, wird die Datenbank dann umgehängt (Rename).
    Dienstag, 9. Juli 2019 17:14
  • Hallo Phido,

    wenn die Produktiv-Datenbank noch in Benutzung ist, dann sollte das Restore nicht laufen. Aber natürlich kann man alles so hinbiegen, dass man seine produktive Datenbank zerstört. Das geht nicht nur durch eine Fehlbedienung beim Restore, sondern auch durch Hardware-Ausfälle, was man eher im Alltag sehen wird. Aber auch Logikfehler in der Software kann die produktive Datenbank zerstören. Du brauchst in jedem Fall ein Wiederherstellungsszenario beginnend ab einem Bare-Metal-Restore des Betriebssystems. 

    Das fängt an mit einer Neuerstellung der Systemdatenbanken, Restore der gesicherten Systemdatenbanken und dann Restore der Benutzerdatenbanken mit all ihren Transaktionslogsicherungen.

    Du brauchst also ein Backup-Konzept, welches Dir alles dafür zur Verfügung stellt. 

    Solltest Du also "nur" die produktive Datenbank zerstört haben, dann brauchst Du das letzte Full-Backup, das letzte differenzielle Backup und alle Transaktionslog-Backups bis zum Ausfallzeitpunkt. Diese solltest Du auch auf anderen Platten als die Datenbank-Files oder sogar auf einem anderen Server abgelegt haben um Hardware-Ausfällen vorzubeugen.

    Das ganze ist natürlich nicht nur theoretisch, sondern auch schon praktisch durchgespielt und idiotensicher dokumentiert worden. 


    Einen schönen Tag noch, Christoph - http://www.insidesql.org/blogs/cmu

    Mittwoch, 10. Juli 2019 05:45
    Beantworter
  • Hallo Phido,

    "Was passiert, wenn der Import während des laufenden Restores manuell durch den Admin abgebrochen wird?"

    Ich vermute mal, dass Du mit "Import" den Restore meinst. In diesem Fall hast Du echt Pech gehabt, denn dann wird weder der Restore erfolgreich beendet noch wird ein Rollback durchgeführt. Die Datenbank verbleibt im RESTORING-Status!

    "Handelt es sich bei dem Import um eine Transaktion, die durch den Abbruch rückgängig gemacht wird?"

    Prinzipiell JA! Das kannst Du sehr leicht testen, indem Du versuchst, einen Restore auf eine Datenbank durchzuführen, die noch benutzt wird (wie Christoph bereits geschrieben hat). Bevor ein RESTORE ausgeführt wird, versucht SQL Server - in einer Transaktion - eine X-Sperre auf die Datenbank zu setzen (siehe Abbildung!)

    "Wird die Produktiv-Datenbank dadurch beschädigt?"

    Ja - die Datenbank ist nicht mehr zu benutzen. Die Datenbank befindet sich im RESTORING-Modus und ist nicht vollständig. Somit nicht mehr zu gebrauchen!

    "Welche Maßnahmen wären in einer solchen Situation die best practice?"

    Die Flucht nach Kuba wäre anzuraten - eventuell besser nach Nordkorea (die liefern nicht aus!). Scherz beiseite; dir bleibt nur noch der RESTORE aus dem letzten Backup (FULL, DIFF, LOG) der Produktionsdatenbank.


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Dienstag, 30. Juli 2019 08:48
  • Die Frage stellt sich i.d.R. nicht, da ein Restore einer Datenbank niemals auf das Original gemacht wird (werden sollte).
    Ist der Restore erforgreich, wird die Datenbank dann umgehängt (Rename).

    Entschuldigung, wenn ich da mal reingrätschen muss - aber das ist so im täglichen Betrieb nicht richtig/sinnvoll:

    • Der Restore in eine neue Datenbank erfordert, dass die Datenbankfiles neu benannt werden müssen
    • Es sollten/können im Falle eines OUTAGE eh keine User mehr auf der Datenbank arbeiten
    • Sofern Du einen RESTORE in eine andere Datenbank durchführst, während User noch in der "alten" Datenbank arbeiten (können), stimmen die Datenstände nicht mehr und Neueingaben gehen verloren.

    Erster Grundsatz: Eine Testdatenbank gehört nicht auf ein Produktionssystem!

    Wer aus Kostengründen gegen diesen Grundsatz verstößt, ist es selbst schuld :)

    Leider sehe ich solche Konstellationen viel zu oft und der Kunde lässt sich auch nicht überzeugen, Testsysteme fachlich und technisch zu trennen. In der Regel sind es Kostengründe, die gegen eine Trennung sprechen :(

    Einen Restore in eine NEUE Datenbank mache ich nur, wenn Teildaten (Tabellen gedropped, Zeilen gelöscht) verloren gegangen sind und in die Produktion wieder eingespielt werden müssen


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Dienstag, 30. Juli 2019 08:58
  • Bisher stellt sich mir die Datenbank als XXX.dbf dar. Wieso sollte ich also nicht in eine yyy.dbf restoren und bei Erfolg eine Umbenennung durchführen?
    Dienstag, 30. Juli 2019 12:01
  • Bisher stellt sich mir die Datenbank als XXX.dbf dar. Wieso sollte ich also nicht in eine yyy.dbf restoren und bei Erfolg eine Umbenennung durchführen?

    Ganz einfach, weil der DBA i. d. R. kein Application Owner ist und auch nicht weiß, ob u. U. die Applikation diese Namen überprüft.

    Fazit: "Das kann man zwar so machen, dann ist es aber ..." :)

    Mag total sinnbefreit sein, habe ich aber genau so mal erlebt, weil irgendeine schei... Applikation eben NICHT mit BACKUP -> RESTORE gearbeitet hat sondern die Datenbank abgehängt hat, Files kopiert hat und anschließend wieder angehängt hat! :)

    So einen Schei... möchte man als DBA nicht erleben.

    In großen Unternehmen gilt eine "Segregation of Duty". Wir waren DBA und hatten keine Erlaubnis, in irgendeiner Art und Weise bei Entwicklung, etc. behilflich zu sein!


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Dienstag, 30. Juli 2019 12:12
  • "Ganz einfach, weil der DBA i. d. R. kein Application Owner ist und auch nicht weiß, ob u. U. die Applikation diese Namen überprüft."

    Verstehe ich nicht, da ich doch der Anwendung genau wieder durch Umbenennen den selben Namen wieder gebe.

    Backup im laufenden Betrieb ist i.d.R. auch transaktionssicher, vorausgesetzt, die Anwendung verwendet keinen Autocommit. Was ich aber auch viel zu häufig schon gesehen habe und man sich dann im tatsächlichen Restorefall über unvoollständige Daten wundert.

    Aber das ist eine ganz andere Diskussion...

    Dienstag, 30. Juli 2019 15:38