Wiederherstellen einer SQL Server Datenbank

[CorneliaBegier 10]

Hallo,

 

ich habe nun seit geraumer Zeit im Internet nach Informationen gesucht finde aber nicht das richtige.

 

Folgendes Szenario:

 

Ein SQL Server crashed.

 

Die Datenbanken sollen auf einem anderen SQL Server wieder hergestellt werden.

 

Das ganze soll so sein, daß auch ein Administrator, der nicht so viel Ahnung von SQL Server hat, diese Datenbank wieder herstellen kann ohne groß Konfigurationen am SQL Server vornehmen zu müssen.

 

Nach meinem dafürhalten brauche ich dafür zwei sachen:

 

1. Ein Backup von der wieder herzustellenden Datenbank

2. ein Script, mit dem ich die zugehörigen Logins wieder herstellen kann.

 

Ist das richtig so? Oder brauche ich noch was?

 

Was ist mit einem Restore von SQL 2k8 auf 2k5? Geht das?

 

Was ist die richtige Vorgehensweise? Erst Logins einspielen oder erst Backup?

 

Vielen Dank schon mal im Vorraus.

 

Cornelia Begier

[phoenixcp 10]

Hallo Cornelia und willkommen an Board

 

Was genau ist denn der Zweck bzw. das Ziel deiner Fragestellungen? Das ganze ist für mich ein wenig "durcheinander".

 

Was ist mit einem Restore von SQL 2k8 auf 2k5? Geht das?

Ich würde das ganz pauschal verneinen. Grundsätzlich würde ich dir empfehlen, dir eine konsistente SQL Server-Umgebung zuzulegen und dann ein für dich passendes Backup- und Recovery-Konzept zu entwerfen und auch auf Anwendbarkeit zu testen.

 

Wenn du uns dein gesamtes Szenario mal etwas anschaulicher darstellst, können wir dir sicher den einen oder anderen Anhaltspunkt geben.

 

Gruß

Carsten

[CorneliaBegier 10]

Hallo,

 

erstmal vielen Dank für Deine rasche Antwort.

 

Selbstverständlich ist es besser, eine Homogene Landschaft zu schaffen.

 

Aber so ein Netzwerk wächst halt ungleichmäßig. Ein neuer Server kommt hinzu mit aktuellerem Betriebssystem oder neuerem SQL Server.

 

Deswegen schmeißt man den alten SQL Server ja nicht weg.

 

Sinn und zweck meiner Fragen (es sind mehrere Fragen und deswegen klangen sie vielleicht etwas wirr) ist desaster recovery.

 

Sprich: Ein Server geht kaputt, der Fehler kann nicht adhoc behoben werden, die Datenbanken müssen aber zur Verfügung gestellt werden.

 

Da liegt der Gedanke für mich nahe, eine Datenbanksicherung zu nehmen und sie auf einem anderen Server einzuspielen.

 

Ich wollte eigentlich nur einmal bestätigt (oder wiederlegt) haben, was ich bisher raus gefunden habe, nämlich daß man dafür nur eine Datenbanksicherung und die ensprechenden Logins braucht. Es gibt da ja ein Script von Microsoft, mit dem man die Logins samt Passwort als Script extrahieren kann (sp_help_revlogin).

 

Außerdem würde ich gerne wissen, in welcher Reihenfolge man die beiden dinge einspielen muß erst die Logins und dann das Backup oder umgekehrt?

 

Und als dritte Frage: Ich kann also ein 2k8.bak-File nicht auf einem sql-Server 2k5 wieder herstellen? Keine Chance?

 

Ich hoffe, diesmal hab ich's etwas verständlicher erklärt :-)

 

Vielen Dank für Deine Hilfe

 

Cornelia Begier

[NilsK 2.934]

Moin,

 

vergiss das mit der Wiederherstellung einer DB auf einer anderen Version am besten ganz. Es mag in bestimmten Kombinationen gehen, aber du wirst dich nicht versionsübergreifend darauf verlassen können.

 

Wenn es um Disaster Recovery für wichtige Datenbanken geht, muss, wie Carsten schon richtig sagt, ein tragfähiger Recovery-Plan her. Die Datenbank "mal eben" auf irgendeinem Altserver wiederherzustellen, ist in aller Regel kein sinnvolles Verfahren. Denn dann musst du immer noch ein zweites Recovery einplanen auf den Server, wo die Datenbank dann wirklich laufen soll. Denke dabei auch an die Clientverbindungen, die du jedesmal neu konfigurieren müsstest. (Von der u.U. geringen Zuverlässigkeit eines Altservers ganz zu schweigen.)

 

Von den Schritten her hast du es grundsätzlich richtig verstanden - die Details hängen dann vom genauen Szenario ab (z.B. Log Restore). Wann du die Logins wiederherstellst, ist grundsätzlich egal - nur wirst du im Zweifel erst nach dem DB-Restore überhaupt nachsehen können, welche Logins du denn brauchst.

 

Vielleicht noch interessant für dich:

[faq-o-matic.net » SQL Server: Wie Datenablage, Backup und Recovery funktionieren]

http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/

 

Gruß, Nils

[phoenixcp 10]

Moin

Sprich: Ein Server geht kaputt, der Fehler kann nicht adhoc behoben werden, die Datenbanken müssen aber zur Verfügung gestellt werden.

 

Da liegt der Gedanke für mich nahe, eine Datenbanksicherung zu nehmen und sie auf einem anderen Server einzuspielen.

Mir würde da eher was anderes naheliegen: Hast du schonmal über über Failover-Clustering nachgedacht? Damit würdest du genau diese "ungeplanten" Hardwareausfälle abdeckeln und hättest im Gegenzug aber fast keine Downtime, da die Instanzen zwischen den Server schwenken.

 

Vielleicht solltest du dir entsprechenden Konzepte mal anschauen und für dich evaluieren. Denn so wie du schreibst, hast du weniger ein Problem mit deinem Recovery sondern eher Verfügbarkeitsanforderungen.

 

Gruß

Carsten

[CorneliaBegier 10]

MoinMoin,

Hast du schonmal über über Failover-Clustering nachgedacht?

 

<hust> das wäre wie mit Spatzen auf Kanonen schießen....

Abgesehen davon daß ein(mehrere) Enterprise SQL Server nicht in unserem Budget liegt..

 

Denn so wie du schreibst, hast du weniger ein Problem mit deinem Recovery sondern eher Verfügbarkeitsanforderungen

 

Stimmt. Wobei die Verfügbarkeitsanforderung nicht sooo hoch anzusiedeln ist. Es reicht, wenn die Datenbank nach sagen wir 30-60 Minuten wieder zur Verfügung steht. Hochverfügbarkeit ist nicht notwendig.

Es geht mir einfach darum, Vorbereitungen für den "Fall daß" zu treffen und was ich dafür brauche und wie ich das ganze für meine Kollegen dokumentieren kann/muß.

 

Es ist klar, daß ich die Applikationen, die auf die entsprechende Datenbank zugreifen umkonfigurieren muß aber das ist gar nicht das Problem.

Das könnte man auch mit entsprechenden DNS Aliassen realisieren.

 

Von der u.U. geringen Zuverlässigkeit eines Altservers ganz zu schweigen

 

Ich rede hier nicht von Altservern! Ich rede hier von dedizierten Datenbankservern, die bestimmte Applikationen bereit stellen und notfallmäßig für einen anderen Server einspringen.

 

Auf jeden Fall vielen Dank für eure Tips, Ihr habt mir sehr weiter geholfen.

 

liebe Grüße

 

Cornelia

[NilsK 2.934]

Moin,

 

eine tolerierbare Downtime von 30 Minuten ist allerdings durchaus in dem Bereich, den man als "Hochverfügbarkeit" bezeichnet. Wenn ihr solche Anforderungen erfüllen müsst, das Budget dazu aber nicht vorhanden ist, passen die Dinge nicht zusammen.

 

Ebenso wenig passt es, bei Datenbanken, die anscheinend eine sehr hohe Bedeutung für das Unternehmen haben, mit Bastellösungen à la "mal schnell auf einem anderen Server wiederherstellen" zu arbeiten. Das geht nach hinten los - spätestens, wenn der Fall tatsächlich mal eintritt.

 

Gruß, Nils

[NorbertFe 2.034]

Das geht nach hinten los - spätestens, wenn der Fall tatsächlich mal eintritt.

 

Der tritt ja nicht ein. ;) Hofft man immer wieder. :cool:

 

Bye

Norbert