Guten Morgen zusammen,

ich bin auf der Suche nach einer Backup-Lösung für den SQL-Server (2012 Express Edition).

Eine automatisches Backup, das eine *.bak erzeugt, habe ich bereits mittels Script und Taskmanger realisiert, das funktioniert auch sehr gut.

Ich hätte gerne eine Lösung die es ermöglicht, das bei einem Ausfall des Hauptservers, einfach die Client-Software auf den Backupserver umgestellt werden kann. Das hätte den Vorteil, das bei einem Ausfall die Anwendungen wieder schneller laufen können und eine Umstellung ist für die User ebenfalls möglich, falls ich nicht da bin.

Könnte man das mit eine Trigger realisieren? Nur wie verhält sicher Server wenn der Backup-Server nicht verfügbar sein sollte??

Im "großen" SQL Server könntest Du eine Datenbankspiegelung einrichten, um eine synchrone Kopie zu erzeugen. In Deiner Clientanwendung brauchst Du dann nur noch einen Failover-Server einzutragen und fertig. Fällt der erste Server aus, übernimmt der zweite automatisch den Dienst und der Client verbindet sich mit diesem, weil er mit dem ersten keinen Kontakt bekommt. Das ist eine sehr feine Sache.

Allerdings gibt es das Feature nicht bei SQL Express. Was Du hier mit etwas Aufwand machen könntest, wäre per Script das Backup auf einem zweiten Server wiederherzustellen. Das kannst Du mittels einer Transaction Log Backup und einem Rollforward auf dem zweiten Server sogar in sehr kurzen (z.B. alle 15min) machen. Das ist allerdings recht aufwändig und bei schlechtem Timing fehleranfällig.
Zudem hast Du damit immer noch ein Problem: Sobald die Clientsoftware sich mit dem zweiten Server verbindet, bekommst Du inkonsistente Daten, weil eventuell Änderungen des Primärservers nicht übertragen worden sind.

Fazit: Die sauberste Lösung wäre ein richtiger SQL Server. Ich weiß zwar nicht, wie groß Deine Anwendung ist, aber der Express hat ja auch noch ein paar andere Einschränkungen.

Hallo Christoph,

für den "echten/großen" SQL-Server:
Praktisch kenne ich mich damit zwar nicht aus, aber die beiden Stichwörter "Database Mirroring" und "Replication" sollten dich weiterbringen. Hier die beiden Seiten dazu von MSDN:
Database Mirroring (SQL Server)
Database Mirroring and Replication (SQL Server)

Da "Database Mirroring" aber (laut obiger Seite) als veraltet gilt, hier noch der Link zu Overview of AlwaysOn Availability Groups (SQL Server)

Th69 hat folgendes geschrieben :

Hallo Christoph, für den "echten/großen" SQL-Server: Praktisch kenne ich mich damit zwar nicht aus, aber die beiden Stichwörter "Database Mirroring" und "Replication" sollten dich weiterbringen. Hier die beiden Seiten dazu von MSDN: Database Mirroring (SQL Server) Database Mirroring and Replication (SQL Server) Da "Database Mirroring" aber (laut obiger Seite) als veraltet gilt, hier noch der Link zu Overview of AlwaysOn Availability Groups (SQL Server)

Ja, auf lange Sicht wird MS das Mirroring, wie man es bisher kennt sterben lassen, aber bis dahin ist es noch ein weiter Weg. Und grundsätzlich unterscheidet sich AlwaysOn von Database Mirroring technisch kaum. Bei AlwaysOn werden nur verschiedene Techniken miteinander kombiniert, um die Flexibilität zu erhöhen, z.B. mehrere Mirroringpartner, nachlaufendes Mirroring, Lesezugriff auf den Mirror Partner usw. usf.. Solche Sachen gehen mit dem jetzigen Mirroring nicht.

Allerdings gibt es das alles (derzeit) zu einem hohen Preis: Für AlwaysOn wird eine Enterprise-Lizenz von SQL benötigt. Wenn man Pech hat und noch nicht auf Windows Server 2012 setzt, wird zudem auch hier die Enterprise-Version benötigt, da AlwaysOn auf dem Failover Cluster aufsetzt.

Fazit: Database Mirroring kann auch jetzt noch ohne Probleme eingesetzt werden, denn der Implementationsaufwand ist mit einem ADO-Client minimal und wenn dann der nächste SQL Server kommt, stellt man eben auf AlwaysOn um.

Nicht alles, was in MS Dokus steht, sollte man wörtlich nehmen

Hallo zusammen!

Danke für die zahlreichen Anregungen!

UGrohne hat folgendes geschrieben :

Im "großen" SQL Server könntest Du eine Datenbankspiegelung einrichten, um eine synchrone Kopie zu erzeugen. In Deiner Clientanwendung brauchst Du dann nur noch einen Failover-Server einzutragen und fertig. Fällt der erste Server aus, übernimmt der zweite automatisch den Dienst und der Client verbindet sich mit diesem, weil er mit dem ersten keinen Kontakt bekommt. Das ist eine sehr feine Sache.

Tja, der große Server, ja das wäre was. Nur damit brauche ich meinem Chef momentan nicht kommen, das ist leider zu viel Geld.

UGrohne hat folgendes geschrieben :

Allerdings gibt es das Feature nicht bei SQL Express. Was Du hier mit etwas Aufwand machen könntest, wäre per Script das Backup auf einem zweiten Server wiederherzustellen. Das kannst Du mittels einer Transaction Log Backup und einem Rollforward auf dem zweiten Server sogar in sehr kurzen (z.B. alle 15min) machen. Das ist allerdings recht aufwändig und bei schlechtem Timing fehleranfällig.

Ein Backup mittels Script habe ich ja bereits realisiert. Kann man das auch so auf einen anderen Server zurückspielen? Wie geht das mit dem ConnectionString für den Anderen Server?

UGrohne hat folgendes geschrieben :

Zudem hast Du damit immer noch ein Problem: Sobald die Clientsoftware sich mit dem zweiten Server verbindet, bekommst Du inkonsistente Daten, weil eventuell Änderungen des Primärservers nicht übertragen worden sind.

Die inkonsistenten Daten wären nicht so wichtig, da das Backup-System nur bei einem Server Crash verwendet wird und wenn das der Fall ist, ist das das kleinste Problem. Auch ein automatisches Umleiten werde ich nicht einrichten, da der Backup-Server sonst eventuell dauerhaft als Datenspeicher verwendet wird. Mit dieser "Spiegelung" möchte ich lediglich ein einfaches umstellen auf ein Backup-System ermöglichen(anderen ServerNamen eintippen fertig) , welches gut in der Doku erläutert ist. Ich möchte einfach nur die Abhängigkeit zu mir reduzieren, weil ein Crash kommt sicher wenn ich im Urlaub bin.

Zu einem anderen/besseren Zeitpunkt werde ich den Chef mal auf den großen Server anhauen.