SQL Server recovery

[chris4you 10]

Also, wir haben einen SQL Server 2k SP4 mit Win2k3 Adv Server. Auf diesem laufen diverse Datenbanken mit der Gesamtgröße von ca. 250Gb (natürlich im Raid5). Im Grunde sind ein paar von diesen DB's auch im 7/24 Betrieb (es laufen Jobs in der Nacht).

 

Die Sicherungsstrategie sieht derzeit folgendermaßen aus das eigentlich alle DB's im Recovery Mode 'Full' laufen. Es wird 1-2x pro Woche fullbackups und teilweise mehrmals täglich transaktionlog Backups durchgeführt. Das Betriebssystem wird mit der Imagesicherungssoftware 'Powerquest v2i Protector' gesichert

 

Nun denke ich mal an den Katastrophenfall wenn der Server komplett abraucht oder einfach ein disaster-recovery notwendig ist brauche ich sehr lang bis alles wieder so läuft wie vorher. Da ich ja jede DB einzeln nehmen muss um diese wiederherzustellen.

 

Habt Ihr da Strategien wie man solche Fälle in einer vernünftigen Zeit, bis max. 8 Stunden, abhandeln kann.

 

fg

 

Chris

[gotama 10]

wir haben nicht ganz so grosse DB aber wir lösen das mit einer externen HD

[BuzzeR 10]

Hallo Chris, ...

 

... sorry, dass ich den Korinthen-K****r habe raushängen lassen, aber wie Du siehst, ist das

wirklich der PRO-Bereich. ;)

 

Nun, Deine Beschreibung gibt jetzt eine Menge mehr an Infos her und ich lasse das mal

auf mich wirken und antworte Dir auf jeden Fall.

 

Hängt bei Euch noch die Produktion am SQL-Server, um die BDE/MDE - Daten

zu erfassen? Ich frage wegen dem 24/7 Betrieb.

 

LG

Marco

[phoenixcp 10]

Wie wäre es einfach mit Risikominderung?

 

Auch der SQL-Server beherrscht sowas wie Replikation. Heißt, du bräuchtest einen zweiten SQL-Server, der als Subscriber konfiguriert ist und sich von dem ersten Server (Publisher) sein DB-Replikat holt.

 

Wenn dir einer der beiden Server abraucht, hast du nen zweiten, der weiterhin läuft und kannst in aller Ruhe den abgerauchten Server frisch machen und drehst dann einfach die Rollen um.

[BuzzeR 10]

@phoenixcp

Diesen Einwand habe ich auch schon vorgebracht, bzw. sogar das Clustering angesprochen,

da Chris 30DB mit 250GB fährt.

 

LG

Marco

[phoenixcp 10]

Hm, dann hast diese Infos aber nicht über Thread bekommen oder gegeben, sonst hätt ich das ja gelesen und hätte gewusst: Ok, noch einer, der nen guten Tipp auf Lager hat. ;)

 

Auf der andren Seite muss ich sagen: Wenn man 30 DB mit 250 GB auf einem SQL-Server fährt, dann sollte man sich schon eher Gedanken über Cluster oder Auslagerung machen, als über Replikation. Für 30 DB's dürfte der Traffic bei der Replikation recht barbarisch werden.

[chris4you 10]

Hi, das Problem mit Clustering ist schon auch der Preis weil die Clusterversion des Sql-Server liegt bei 2x4500€, ungeachtet von dem ganzen Aufwand der Hardware (SAN).

 

Mir persönlich gefällt eigentlich die Sache mit Replikation am besten, aber was ich dabei noch nicht ganz verstanden habe ist folgendes:

 

• Server1 hält Datenbank1; Server2 halt Datenbank1 im Recovermodus (Repliktion)

• Server1 fällt aus

• Recovery und Onlineschalten der Datenbank1 auf Server2

• Das Problem: Woher wissen die Clients das sich Ihre Datenbank1 nun nicht mehr auf Server1 befindet sondern auf Server2? Da sich die Appl im Normalfall über ODBC connecten und im Verbindungsdescriptor ja explizit der Server1 drinsteht?

 

Wie löst man dieses Problem?

[Zearom 10]

wenn sich die Applicationen über DNS mit dem SQLserver verbinden ist das kein Problem, dazu bräuchtet ihr nur den dnsrecord anpassen. Habt ihr aber direkt die IP-Adressen eingetragen wird das natürlich etwas schwieriger. Das ist auch der Grund warum ich zum Connecten meiner Apps nur hostnamen nehme.

[phoenixcp 10]

Was dann wiederrum für die Clusterlösung sprechen würde.

[Zearom 10]

Ich würde sagen das das ne Kostenfrage ist. wenn ich den 2. sqlserver via dns zum Primary machen kann, spar ich ne menge kohle im vergleich zum Enterprise server. sicherlich wäre das technisch gesehen die ideal lösung, leider lässt das oft der Geldbeutel bzw das Budget nicht zu, oder der Chef ist dafür nicht empfänglich dafür.

[substyle 20]

Also in einer solche Umgebung lebt die Firma von ihrem SQL Server !

Da würde ich dem Chef mal vorrechnen was ein Ausfall kosten kann (Worst Case)

 

Da wird er gaaanz schnell etliches an Kohle Locker machen.

Bei uns musste der Gau leider erst eintreten aber dann gab es auch die erforderlichen Mittel

 

subby

[phoenixcp 10]

Es ist bedauerlich, das Nichttechniker den Bedenken von Technikern selten Glauben schenken und nach dem Motto "Es läuft doch alles" reagieren. Problem: Wenn es einmal nicht läuft, wird der Chef sicher nicht sagen "Meine Schuld, hätte sollen doch Geld locker machen" sondern eher "Sie sind der Techniker und müssen sicherstellen das es läuft."

 

Was sind also deine Möglichkeiten?

1. Du setzt dich mit deinem Chef zusammen, ihr diskutiert sachlich den Worst-Case-Fall und seht, ob sich die Anschaffung eines zweiten Systems rechnet. Wenn sich das für deinen Chef nicht rechnet, weil er der Meinung ist, das alles läuft, dann mach ihn auf das Risiko aufmerksam und lass dir die Entscheidung schriftlich geben, damit du im Fall der Fälle was in der Hand hast.

 

2. Lass dich und deinen Chef von einem Externen über die Risiken bei diesem System beraten, das kommt immer besser.

 

3. Teste wieder und wieder deine Backup- und Recoverystrategie, um Möglichkeiten für die Optimierung zu finden.

 

Wenn ihr 30 DB's mit 250 GB laufen habt, dann wird da schon ein ordentliches Blech drunter hängen. Und dann dürfte es kein Problem sein, als Ausfalllösung eine etwas schwächere Maschine daneben zu stellen, die einfach nur für den Fall der Fälle da ist.

 

Ich wünsche dir aus kollegialer Sicht nicht, das du den Recoveryplan je aus dem Schreibtisch holen musst.

[BuzzeR 10]

Ich bin weiter dabei ... auch wenn ich gerade eine Sicherheits-Baustelle hatte. :D

 

Lese mir mal alles durch und bleibe dran ... ist aber bis jetzt schon spannender als

ein Hitchcock. ;)

 

Gruß

Marco