MS SQL Server redundant machen und Backup und Recovery Lösung

Wenn du ein Backup zurückspielst dann werden immer die Daten seit dem Backup abhanden kommen.

Ich hab Stündlich eine Transaktionslog Sicherung und 2x am Tag eine Vollsicherung + noch ein paar andere Sicherungen

Wie oft hast du denn überhaupt Probleme mit der Datenbank?

Guten Morgen,

Also jetzt mal im Ernst, wenn du nicht mal das SQL Server Management Studio kennst, um deine DB´s in Sicherheit zu bringen- frage ich mich wie ihr ein Projekt erstellen wollt mit 100 % Laufzeit. SQL Qluster und Replikation heißt das Zauberwort.
wie habt ihr den dem Kunden ein Angebot erstellt für die Lizenzierung ?
lg
Frank

Erstmal würde ich zustimmen das deine Kenntnisse echt etwas mau sind, an Replikation habe ich mich selbst noch nichtmal versucht und halte sie für nicht trivial. Es gäbe zur Replikation noch die Alternative "ganz normale", Virtualisierung mit HA einzusetzen. Fällt ein Host aus bootet dein DB Server auf dem anderen, Downtime entspricht in etwa der Bootzeit plus eine Minute oder so und deine DB reagiert wieder. Ein zentrales und vor allem redundantes Storrage ist natürlich zwigend. Wenn das nicht vorhanden ist ist ein SQL Cluster vermutlich sogar günstiger von den Lizenzkosten her.

Hallo,

eine weitere Möglichkeit wäre auch noch SQL Mirroring (falls deine Anwendungen das auch unterstützen).
Ist Lizenztechnisch billiger als ein Cluster und falls der Prinzipal Server ausfällt übernimmt der Spiegel Server innerhalb von ein paar Sekunden.

Tom

auf Datei-Ebene
SQL M-Studio öffnen, Rechtsklick auf Datenbank
Optionen > Wiederherstellungsmodell vollständig
dann
Transaktionsprotokollversand aktivieren, Zyklus festlegen.

=> Zusätzlich zur Vollsicherung werden hier "Teilsicherungen" kumulativ angelegt.
=> Wenn du RAID 1+0 hast, sind die Daten also nach deinem Zyklus doppelt vorhanden.
=> Sollte die Datenbank abrauchen, kannst du nach deinem Zyklus den entsprechenden Zeitpunkt wiederherstellen.

Serverebene
Ist dein SQL Server eine VM, kannst du den Server nach dieser Art sichern. Es sichert den Zeitpunkt der VM inkl. Datenbank. Eine DB aber ständig über VM zu sichern ist nicht sinnvoll, dazu gibt es das o.g. TPV.

Datenbankspiegelung
Hier wird ein zweiter Server bereitgehalten, auf den quasi ständig repliziert wird - erfordert aber eine SQL Enterprise Edition. Weiterhin musst du deinem Programm(en) auch klar machen, dass wenn SQL-Server1 nicht erreichbar ist, diese nach SQL-Server2 schwenken - was oft der Knackpunkt ist für ein automatisches Failover. Dieses benötigt noch einen dritten Client als "Zeugen", da bitte ich aber selber nochmal zu googeln wie fähig dieser "Zeuge" (je nach deiner Version) ist.

Nach deiner Anforderung "SQL Server möglichst 100% erreichbar" musst du also mischen, d.h. Server + DB redundant machen und per Automation schwenken.

Datenbankspiegelung funktioniert auch mit der Standardversion. Allerdings kann dann das Mirroring nur synchron betrieben werden. Das ist aber ja kein Nachteil.
Das mit dem dritten "Server" als Zeuge (es genügt auch die SQL Express Version) funktioniert zuverlässig.
Man benötigt daher 2 Standard Server-Lizenzen und die Cals nur für 1 Server.
Das eigentliche Problem das hin und wieder auftaucht ist, dass einige Programme den Connection String für Mirroring nicht unterstützen.

Und zu beachten ist auch, dass es Mirroring nur bis zum SQL 2014 gibt. Bei den folgenden Versionen wird diese Funktion nicht mehr bereitgestellt.

Tom

PS: "Möglichst 100%" ist auch ein sehr unglückliche Definition. Um für einen Dienst nahe 100% Verfügbarkeit zu gewährleisten braucht man zunächst mal unterschiedliche Standorte und sehr viele redundant ausglegte Komponenten.