Jump to content

SQL Server recovery


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...