Keine Entscheidung aus drei Klicks. Aber eine gute Vorauswahl aus acht Fragen.
Drei Teile lang ging es um die Mechanik von Failover Cluster Instance (FCI) und Availability Group (AG), um Featurematrix, Betriebsfolgen und Lizenzregeln. Jetzt geht es um Ihren Fall. Die Entscheidungshilfe unten stellt acht Fragen zu Anforderungen und Rahmenbedingungen und ordnet danach fünf Kandidaten: FCI, Basic AG, volle AG, Log Shipping und, ganz ehrlich, Backup und Restore ohne Hochverfügbarkeit. Jeder Kandidat bekommt Gründe dafür, Gründe dagegen und, wo es sie gibt, den Ausschlussgrund. „Weiß ich noch nicht“ ist bei jeder Frage erlaubt und wandert in eine Liste dessen, was Sie klären sollten. Ihre Antworten bleiben im Browser; nichts wird übertragen.
Kurz gesagt
- Das Werkzeug liefert eine Rangfolge mit Gründen, kein Produkt. Fünf Kandidaten, je mit „dafür spricht“, „dagegen spricht“ und „ausgeschlossen durch“.
- Harte Ausschlüsse kommen nur aus belegten Grenzen: eine Datenbank je Basic AG, kein Lesen und kein Sichern auf der Basic-AG-Secondary, eine Datenkopie bei der FCI, volle AG nur in Enterprise, kein automatisches Failover bei Log Shipping.
- Weiche Bewertungen folgen Teil 2: Ein Rollenwechsel ist schneller als ein Instanzneustart, Instanzobjekte reisen nur mit der FCI, zwei Replikate reichen nicht für lokale Automatik und Standortschutz zugleich.
- „Weiß ich noch nicht“ ist eine erlaubte Antwort, meist die wichtigste. Sie erscheint unter „Das sollten Sie klären“, zusammen mit den drei Punkten, die bei jeder Variante offen sind: Failover geprobt, Anwendung verbindet sich neu, Backup getestet.
- Nichts verlässt Ihren Browser. Keine Anmeldung, kein Formular, keine Speicherung; die Zusammenfassung können Sie kopieren und in Ticket oder E-Mail einfügen.
- Hochverfügbarkeit ersetzt kein Backup. Jedes Ergebnis endet mit diesem Satz, weil er in jeder Variante gilt.
Die Entscheidungshilfe
Beantworten Sie die Fragen in beliebiger Reihenfolge; das Ergebnis rechts (auf dem Telefon darunter) aktualisiert sich mit jeder Antwort. Wo Sie unsicher sind, wählen Sie „Weiß ich noch nicht“. Ein Klick auf eine Begründung führt zu dem Abschnitt der Reihe, aus dem sie stammt.
So kommt das Ergebnis zustande
Das Werkzeug kennt zwei Arten von Regeln. Harte Ausschlüsse nehmen einen Kandidaten aus der Wertung, weil eine belegte Grenze der Variante Ihrer Antwort widerspricht. Weiche Bewertungen verschieben die Rangfolge, weil eine Variante die Anforderung leichter oder schwerer erfüllt. Beide Arten stehen hier offen, damit Sie das Ergebnis nachvollziehen und widersprechen können.
| Wenn Sie antworten … | … scheidet aus | weil |
|---|---|---|
| Datenverlust: keiner | Log Shipping, Backup ohne HA | Log Shipping überträgt Log-Backups im Takt der Jobs, ein Backup-Konzept verliert bis zum letzten Log-Backup (Teil 2, Matrix) |
| Wiederanlauf: automatisch | Log Shipping, Backup ohne HA | Log Shipping kennt kein automatisches Failover, der Rollenwechsel ist immer manuell (Teil 2) |
| Schutz: zusätzlich Storage oder Standort | FCI | Die FCI hat eine Datenkopie auf gemeinsamem Speicher; Storage- oder Standortausfall deckt nur eine replizierte Speicherlösung ab (Teil 1) |
| Datenbanken: mehrere, die zusammen umschalten | Basic AG | Eine Basic AG enthält genau eine Datenbank; mehrere Gruppen schalten unabhängig voneinander (Teil 1) |
| Storage: nur lokale Datenträger | FCI | Eine FCI braucht gemeinsamen Speicher: SAN, Storage Spaces Direct oder eine SMB-Freigabe (Teil 1) |
| Kopie: Berichte lesen | FCI, Basic AG | Passive FCI-Knoten sind gestoppt; die Basic-AG-Secondary erlaubt keinen Lesezugriff (Teil 2) |
| Kopie: Backups auslagern | FCI, Basic AG | Es gibt keine zweite Kopie beziehungsweise keine Backups auf der Basic-AG-Secondary (Teil 2) |
| Edition: Standard, Enterprise keine Option | Volle AG | Die volle AG ist Enterprise vorbehalten (Teil 3) |
Die weichen Bewertungen in Kurzform: Ein Wiederanlauf in Sekunden spricht für die AG, denn der Rollenwechsel war im Lab unter einer Sekunde fertig, der Instanzneustart als Stellvertreter des FCI-Failovers brauchte rund zehn (Teil 2). Administration nebenbei spricht für die FCI, weil Logins, Jobs und Konfiguration mit der Instanz umziehen und bei einer AG auf jedem Replikat gepflegt werden müssen (Teil 2). Standortschutz plus lokale Automatik belastet die Basic AG, weil ihre zwei Replikate entweder lokal synchron oder asynchron im zweiten Standort stehen können, nicht beides (Teil 1). Stunden Datenverlust und manueller Rollenwechsel stärken Log Shipping und das reine Backup-Konzept, weil beide die Anforderung ohne Cluster erfüllen. Berichte oder Backups auf der Kopie führen zur vollen AG und tragen zugleich den Hinweis aus Teil 3: Eine lesbare Secondary ist nicht passiv und braucht eine eigene Lizenz (Teil 3).
Was das Werkzeug bewusst nicht tut: Es rechnet keine Kosten, es bewertet keinen Vertrag, und es zählt keine synchronen Replikate, weil Microsoft diese Zahl auf verschiedenen Seiten unterschiedlich nennt.
Drei typische Ergebnisbilder
Die Fachanwendung mit einer Datenbank. Ein Rechenzentrum, Datenverlust ausgeschlossen, Wiederanlauf in einigen Minuten automatisch, niemand liest auf der Kopie, Standard Edition, Administration nebenbei. Ergebnis: FCI und Basic AG liegen vorn, die FCI wegen der Instanzobjekte meist knapp davor, die Basic AG wegen des schnelleren Rollenwechsels und des Storage-Schutzes dicht dahinter. Die volle AG ist ausgeschlossen, Log Shipping scheitert an der Automatik. Zu klären bleibt: gemeinsamer Storage vorhanden, Failover geprobt, Anwendung verbindet sich neu.
Zwei Rechenzentren, mehrere Datenbanken. Lokale Automatik und Standortschutz, Datenbanken müssen zusammen umschalten, Enterprise ist möglich. Ergebnis: Die volle AG führt, die Basic AG ist ausgeschlossen (eine Datenbank je Gruppe), die FCI ohne replizierte Speicherlösung ebenfalls. Log Shipping bleibt als DR-Ergänzung stehen. Mit „Standard, Enterprise keine Option“ kippt das Bild: Dann heißt der Standard-Weg FCI für die lokale Automatik plus Log Shipping in den zweiten Standort mit manuellem Rollenwechsel, und das Werkzeug sagt das so.
Die Berichte sollen weg vom Primary. Sobald Sie „Berichte lesen“ wählen, bleibt nur die volle AG, und das Ergebnis trägt den Lizenzhinweis: Die lesbare Secondary ist nicht passiv. Wer das nicht will, sieht unter „zu beachten“ die Alternativen aus Teil 3, etwa eine getrennte Reporting-Kopie oder Log Shipping mit Standby-Datenbank, die zwischen den Restores lesbar ist.
Was das Ergebnis nicht ist
Es ist keine Architektur. Es sagt nicht, wie viele Knoten, welche Quorum-Konfiguration, welcher Zeuge, welche Netzwerke. Es ist keine Lizenzauskunft: Die Regeln aus Teil 3 gelten mit Quelle und Stand, maßgeblich ist Ihr Vertrag. Und es ersetzt drei Dinge nicht, die jede Variante braucht und die in Datenbankprojekten selten budgetiert werden: eine Failover-Übung mit gemessener Zeit bis zum ersten erfolgreichen Schreibzugriff, eine Anwendung, die sich neu verbindet, und ein getestetes Backup, weil eine Secondary jeden Anwenderfehler in Millisekunden übernimmt.
Nach dem Ergebnis: die Checkliste fürs Gespräch
Die Vorauswahl ist der Anfang des Gesprächs mit Infrastruktur, Anwendungsverantwortlichen und Einkauf. Diese acht Punkte sollten darin vorkommen:
- RPO und RTO schriftlich, in Minuten, mit dem Namen dessen, der sie festgelegt hat. Teil 2 zeigt, wie man beide bei einer AG misst.
- Die Liste der Ausfälle, gegen die geschützt werden soll: Knoten, Storage, Standort, Anwenderfehler. Für den letzten hilft keine Replikation.
- Der Datenbankzuschnitt der Anwendung: Welche Datenbanken müssen zusammen umschalten, welche Instanzobjekte (Logins, Jobs, Linked Server) gehören dazu?
- Der Storage: gemeinsamer Speicher vorhanden oder nicht, repliziert oder nicht, und wer ihn betreibt.
- Der Lesebedarf: Wer will auf der Kopie lesen oder sichern, und ist die Lizenzfolge aus Teil 3 bekannt?
- Edition und Vertrag: Standard oder Enterprise, Software Assurance oder Subscription für die Fail-over-Rechte, Kapazitätsgrenzen der Standard Edition gegen die erwartete Last.
- Die Betriebsmannschaft: Wer pflegt Logins und Jobs auf allen Replikaten, wer patcht in welcher Reihenfolge, wann ist die nächste Failover-Übung?
- Anwendung und Backup: Verbindet sich die Anwendung nach einem Failover neu? Wann wurde der Restore zuletzt geprobt?
Häufige Fragen
Warum erscheint Log Shipping als Kandidat? Das ist doch keine Hochverfügbarkeit. Richtig, der Rollenwechsel ist manuell. Aber viele Anforderungen heißen in Wahrheit „zweiter Standort, Verlust von Minuten tragbar, Umschalten von Hand ist in Ordnung“, und dafür ist Log Shipping in Standard der einfachste belegte Weg. Das Werkzeug soll das zeigen, statt reflexhaft einen Cluster zu empfehlen.
Warum fragt das Werkzeug nicht nach dem Budget? Weil Preise nicht Teil dieser Reihe sind und ein Budget ohne Anforderung keine Entscheidung trägt. Die Frage nach der Edition deckt den Teil ab, der die Architektur bestimmt.
Warum fehlt Azure? Die Reihe vergleicht die beiden Verfahren auf eigenen Windows-Servern. Für Azure SQL Database, Managed Instance und SQL Server auf Azure-VMs gelten andere Hebel; sie haben eigene Seiten unter SQL Server in Azure.
Speichert die Seite meine Antworten? Nein. Die Antworten liegen nur im Arbeitsspeicher der Seite und sind nach dem Neuladen weg. Deshalb gibt es die Schaltfläche „Zusammenfassung kopieren“.
Was, wenn zwei Kandidaten gleichauf liegen? Dann ist das die ehrliche Antwort: Beide erfüllen Ihre Anforderungen, und die Entscheidung fällt über Dinge, die das Werkzeug nicht sieht: vorhandene Hardware, Erfahrung der Mannschaft, Vertragslage. Genau das ist der Punkt, an dem ein Verfügbarkeits-Review mehr bringt als ein weiterer Klick.
Wenn Sie vor der Entscheidung stehen
Mit dem kopierten Ergebnis haben Sie eine Vorauswahl mit Gründen. Im Verfügbarkeits-Review unseres Health Checks legen wir sie neben das, was Ihre Umgebung heute erreicht: gemessene Wiederanlaufzeit, Sendewarteschlangen, Backup-Kette, Anwendungsverhalten im Failover. Für Planung, Aufbau und Migration steht die Leistung Infrastruktur und Hochverfügbarkeit. Wir beraten ohne eigenes Lizenzverkaufsinteresse.
Quellen
Die Regeln dieses Werkzeugs beruhen auf den Microsoft-Fundstellen der Teile 1 bis 3 dieser Reihe (geprüft am 08. und 09.11.2026) und auf den Labmessungen aus Teil 2 (SQL Server 2022 CU27, ohne Windows-Cluster). Jede Begründung im Ergebnis verlinkt den Abschnitt, aus dem sie stammt. Das Werkzeug nennt keine Zahl synchroner Replikate und keine Preise.