Kurz gesagt: SQL Server Hochverfügbarkeit hält ERP und andere Anwendungen am Laufen, wenn der Datenbankserver ausfällt: Der Dienst wird an eine bereitstehende zweite Kopie übergeben, die Unterbrechung bleibt kurz. Welche Lösung für ein KMU passt, hängt davon ab, wie viel Ausfallzeit und Datenverlust akzeptabel sind und welche SQL-Server-Edition im Einsatz ist. In der Standard Edition schützt eine Basis-Verfügbarkeitsgruppe eine Datenbank, Always On-Verfügbarkeitsgruppen der Enterprise Edition schützen mehrere Datenbanken gemeinsam, und für großzügigere Ziele eignet sich der Protokollversand (Log Shipping).
In vielen KMU laufen ERP, E-Rechnungs-Schnittstelle und Reporting auf einem einzigen SQL Server. Fallen Festplatte, Mainboard oder Betriebssystem aus, stehen Auftragserfassung, Versand und Fakturierung gleichzeitig still. Ein Backup bringt die Daten zurück, doch einen neuen Server aufzusetzen und wiederherzustellen kann Stunden dauern. Hochverfügbarkeit soll genau diese Wartezeit verkürzen.
Was ist SQL Server Hochverfügbarkeit?
SQL Server Hochverfügbarkeit (High Availability, HA) ist eine Architektur, die den Dienst bei Ausfall eines Datenbankservers oder einer Instanz auf einen vorbereiteten zweiten Server umschaltet (Failover), sodass Anwendungen weiterarbeiten können.
Hochverfügbarkeit ist kein Backup. HA überbrückt Hardware- und Serverausfälle, ein versehentlich gelöschter Datensatz oder von Ransomware verschlüsselte Daten landen aber meist auch in der zweiten Kopie. Microsoft betont im Leitfaden zu Geschäftskontinuität für SQL Server, dass die Verfügbarkeitsfunktionen eine robuste, getestete Sicherungs- und Wiederherstellungsstrategie nicht ersetzen. Ihr HA-Konzept sollte daher auf einem funktionierenden SQL-Datenbank-Backup aufbauen.
Zuerst zwei Fragen: Wie viel Ausfallzeit, wie viel Datenverlust?
Legen Sie vor der Technikwahl für jede Datenbank zwei Ziele schriftlich fest:
- RTO (Recovery Time Objective): die maximale Zeit, bis das System nach einem Ausfall wieder laufen muss.
- RPO (Recovery Point Objective): der maximal akzeptable Datenverlust.
Für die ERP-Datenbank kann „wenige Minuten Ausfall, kein Datenverlust“ eine realistische Anforderung sein; für eine Archivdatenbank mit Monatsberichten sind auch einige Stunden vertretbar. Stimmen Sie die Ziele mit den Fachbereichen ab – die teuerste Lösung für jede Datenbank treibt das Budget unnötig in die Höhe. Die Ziele sollten außerdem zu Ihrem unternehmensweiten Disaster-Recovery-Plan passen.
SQL Server Hochverfügbarkeit: die Optionen im Vergleich
Die integrierten Optionen von SQL Server und der Schutz auf Virtualisierungsebene im Überblick. Die Angaben zu den Editionen stammen aus Microsofts Vergleich der SQL Server 2022-Editionen:
| Lösung | Was wird geschützt? | Failover | Benötigte Infrastruktur | Edition | Worauf achten? |
|---|---|---|---|---|---|
| Basis-Verfügbarkeitsgruppe | Eine Datenbank | Automatisch (synchroner Modus) oder manuell | Zwei Server, Windows Server-Failovercluster (WSFC) oder Pacemaker unter Linux | Standard | Nur zwei Kopien; das Sekundärreplikat ist weder lesbar noch für Backups nutzbar |
| Always On-Verfügbarkeitsgruppe | Mehrere Datenbanken in einer Gruppe | Automatisch oder manuell, in der Regel innerhalb von Sekunden | Cluster und eigener Speicher je Kopie | Enterprise | Anmeldungen, SQL Server-Agent-Aufträge und Verbindungsserver separat synchronisieren |
| Failoverclusterinstanz (FCI) | Die gesamte SQL-Server-Instanz: Datenbanken, Aufträge, Anmeldungen | Automatisch; die Instanz startet auf dem anderen Knoten neu | Cluster und gemeinsamer Speicher | Standard, Enterprise | Der gemeinsame Speicher ist ein Single Point of Failure; die Wiederherstellung dauert meist länger als ein AG-Failover |
| Protokollversand (Log Shipping) | Je Datenbank | Immer manuell | Zweiter Server, freigegebener Backup-Ordner, SQL Server-Agent-Aufträge | Enterprise, Standard, Web | Die Umleitung der Anwendungen auf den neuen Server muss separat geplant werden |
| HA auf Virtualisierungsebene | Die virtuelle Maschine selbst | Die VM startet auf einem anderen physischen Host neu | Hypervisor-Cluster und gemeinsamer Speicher | Unabhängig von der SQL-Server-Edition | Behebt Probleme im SQL-Server-Dienst oder in der Datenbank nicht allein |
Bei Verfügbarkeitsgruppen verbinden sich Anwendungen über einen Listener-Namen statt über den Namen des Primärservers; nach einem Failover landet die Verbindung beim neuen Primärreplikat. Beim Protokollversand gibt es diese Ebene nicht.
Welche Lösung passt zu welchem KMU?
Eine ERP-Datenbank in der Standard Edition: Die Basis-Verfügbarkeitsgruppe ist oft die ausgewogenste Wahl. Der zweite Server wartet nur; er liefert keine Berichte, und Backups werden auf dem Primärserver erstellt.
Mehrere voneinander abhängige Datenbanken: Arbeiten ERP-, Schnittstellen- und Webshop-Datenbank zusammen, braucht die Standard Edition für jede eine eigene Basisgruppe, und jede Gruppe schaltet einzeln um. Müssen die Datenbanken gemeinsam in einer Gruppe wechseln, sollten Sie Always On-Verfügbarkeitsgruppen der Enterprise Edition prüfen.
Reporting vom Hauptserver trennen: Lesbare Sekundärreplikate gibt es nur in der Enterprise Edition, und jeder Server mit einem lesbaren Replikat benötigt eine Lizenz.
Großzügige Ziele, begrenztes Budget: Können Sie den Verlust der Änderungen seit der letzten Protokollsicherung und einen manuellen Wechsel akzeptieren, ist der Protokollversand einfach und robust. Da sich das Einspielen der Protokollsicherungen bewusst verzögern lässt, schützt er auch vor Fehlern wie einem UPDATE ohne WHERE-Bedingung.
Die ganze Instanz muss geschützt werden: In Umgebungen mit vielen SQL Server-Agent-Aufträgen und Verbindungsservern nimmt eine FCI diese Objekte mit; den gemeinsamen Speicher müssen Sie jedoch separat absichern.
Schritt-für-Schritt-Plan vor dem Aufbau
- Datenbanken und Ziele erfassen: Notieren Sie RTO und RPO jeder Datenbank, die angebundenen Anwendungen und die Wartungsfenster.
- Edition und Lizenzierung klären: Prüfen Sie, welche Optionen Ihre Edition unterstützt, und klären Sie die Lizenzierung des zweiten Servers mit Ihrem Lizenzpartner. Läuft noch eine alte Version, planen Sie zuerst das SQL Server Upgrade.
- Den zweiten Server wirklich trennen: Liegen beide Kopien auf demselben physischen Host oder Speicher, trifft ein Ausfall beide. Versionen und Patchstände müssen übereinstimmen, und das Netzwerk muss die synchrone Replikation tragen.
- Cluster und Zeugen einrichten: In Zwei-Knoten-Clustern verhindert ein Dateifreigabe- oder Cloudzeuge, dass beide Server gleichzeitig Primärserver werden wollen.
- Anwendungen auf den Listener umstellen: Tragen Sie in ERP, Schnittstellendiensten und Reporting-Werkzeugen den Listener-Namen statt des Servernamens ein und testen Sie jede Anwendung.
- Objekte auf Serverebene synchronisieren: Anmeldungen, SQL Server-Agent-Aufträge und Verbindungsserver wandern nicht mit der Datenbank. Eigenständige (contained) Verfügbarkeitsgruppen in SQL Server 2022 verwalten einen Teil davon auf Gruppenebene.
- Backup-Aufträge anpassen: Prüfen Sie, dass Backups nach einem Failover auch auf dem neuen Primärserver laufen und an einem getrennten Ort landen.
- Failover testen und dokumentieren: Führen Sie in einem geplanten Wartungsfenster einen manuellen Failover durch, beobachten Sie die Anwendungen und halten Sie die Schritte in einem kurzen Runbook fest.
- Überwachung einrichten: Alarme für Synchronisierungsstatus, Verzögerung zwischen den Kopien, Clusterereignisse und Speicherplatz.
Häufige Fehler
- Backups vernachlässigen, sobald Hochverfügbarkeit eingerichtet ist.
- Beide virtuellen Server auf demselben physischen Host oder Speicher betreiben.
- Anwendungen mit dem Servernamen statt mit dem Listener verbinden.
- Vergessen, Anmeldungen und geplante Aufträge auf den zweiten Server zu übertragen.
- Ohne Failover-Test live gehen – dann findet der erste Test beim echten Ausfall statt.
Ob Server, Speicher und Netzwerk für diese Schritte bereit sind, zeigt ein IT-Infrastruktur-Audit.
Zusammenfassung und Checkliste
- RTO- und RPO-Ziele sind für jede Datenbank festgelegt.
- Edition und Lizenzierung sind geklärt; der Unterschied zwischen Standard und Enterprise ist bekannt.
- Der zweite Server läuft auf getrennter Hardware und getrenntem Speicher.
- Anwendungen verbinden sich über den Listener-Namen.
- Anmeldungen, Aufträge und Verbindungsserver sind synchronisiert.
- Backups laufen auch nach einem Failover weiter, eine Wiederherstellung wurde getestet.
- Ein Failover-Test ist erfolgt; Runbook und Überwachung stehen.
Richtig aufgebaut macht SQL Server Hochverfügbarkeit aus einem stundenlangen Stillstand nach einem Serverausfall eine kurze Unterbrechung. Die SQL-Beratung von ÇAP Teknoloji legt mit Ihnen die Ziele Ihrer Datenbanken fest, entwirft eine Architektur passend zu Edition und Budget und führt die Failover-Tests gemeinsam mit Ihrem Team durch. Sprechen Sie uns an.
Häufig gestellte Fragen
Ersetzt Hochverfügbarkeit das Backup?
Nein. Hochverfügbarkeit hält den Dienst bei Hardware- oder Serverausfällen am Laufen, versehentlich gelöschte oder verschlüsselte Daten landen aber meist auch in der zweiten Kopie. Regelmäßige Backups und Wiederherstellungstests bleiben notwendig.
Lässt sich Hochverfügbarkeit mit der SQL Server Standard Edition umsetzen?
Ja. Die Standard Edition unterstützt die Basis-Verfügbarkeitsgruppe für eine Datenbank auf zwei Servern, Failoverclusterinstanzen und den Protokollversand. Für mehrere Datenbanken in einer Gruppe und lesbare Sekundärreplikate ist die Enterprise Edition nötig.
Was unterscheidet eine Always On-Verfügbarkeitsgruppe von einem Failovercluster?
Eine Verfügbarkeitsgruppe repliziert Datenbanken auf Kopien mit eigenem Speicher, Anwendungen verbinden sich über einen Listener. Eine Failoverclusterinstanz startet die gesamte SQL-Server-Instanz über gemeinsamen Speicher auf einem anderen Knoten neu; dieser Speicher bleibt ein Single Point of Failure.
Wie lange dauert ein Failover?
Laut Microsoft dauert ein Failover bei Verfügbarkeitsgruppen in der Regel Sekunden; bei Failoverclusterinstanzen meist länger, weil die Instanz neu startet und die Wiederherstellung durchläuft. Beim Protokollversand wird manuell umgeschaltet. Messen Sie die tatsächliche Dauer durch Tests in Ihrer Umgebung.
