Wie dimensionieren Sie Serverinfrastruktur, wenn 99,9% Verfügbarkeit gefordert wird?

Eine Serverinfrastruktur für 99,9 % Verfügbarkeit muss nicht möglichst gross sein. Sie muss vor allem so dimensioniert werden, dass geschäftskritische Anwendungen auch bei vorhersehbaren Störungen, Wartungsarbeiten und dem Ausfall einzelner Komponenten innerhalb der vereinbarten Grenzen nutzbar bleiben.

Dafür reicht es nicht, CPU-Kerne, Arbeitsspeicher und Storage grosszügig zu bestellen. Entscheidend sind die tatsächliche Anwendungslast, die Abhängigkeiten zwischen den Systemen und die Ressourcen, die nach einem Komponentenausfall noch zur Verfügung stehen.

Für IT-Verantwortliche in Schweizer Unternehmen entsteht dabei ein Zielkonflikt: Zusätzliche Redundanz verbessert die Ausfallsicherheit nur dann, wenn sie technisch durchgängig funktioniert und zuverlässig betrieben werden kann. Gleichzeitig verursacht jede zusätzliche Komponente Anschaffungs-, Lizenz- und Betriebskosten.

Eine wirtschaftliche Dimensionierung beginnt deshalb mit messbaren Verfügbarkeitszielen, realen Leistungsdaten und überprüfbaren Wiederherstellungsverfahren. Daraus lässt sich ableiten, welche Reserven notwendig sind, wo Redundanz tatsächlich hilft und welche Investitionen keinen entsprechenden Nutzen bringen.

Warum 99,9 % Verfügbarkeit schnell teuer werden, wenn eine Komponente zum Single Point of Failure wird

Bei einer geforderten Verfügbarkeit von 99,9 % ist zunächst zu klären, was überhaupt verfügbar sein muss. Ein erreichbarer Server bedeutet nicht automatisch, dass eine Geschäftsanwendung funktioniert. Fällt beispielsweise die gemeinsame Datenbank, Firewall oder Authentifizierung aus, können mehrere redundant ausgelegte Server gleichzeitig ihren geschäftlichen Nutzen verlieren.

Bei einem durchgehenden Betrieb über 365 Tage entsprechen 99,9 % Verfügbarkeit rechnerisch 8,76 Stunden beziehungsweise rund 8 Stunden und 46 Minuten möglicher Nichtverfügbarkeit im Jahr. Diese Grössenordnung wird auch in der Microsoft-Dokumentation zur Definition von Verfügbarkeitszielen ausgewiesen.

Das Ausfallbudget ist keine Garantie und auch kein Freipass für beliebig lange einzelne Unterbrechungen. Messzeitraum, Wartungsfenster, Ausschlüsse und die Definition eines Ausfalls müssen im Service Level Agreement (SLA) eindeutig festgelegt werden.

Die entscheidende Frage lautet: Wo endet die Redundanz?

Eine Abhängigkeitskarte sollte den vollständigen Weg einer geschäftskritischen Transaktion abbilden:

• Benutzerzugriff, DNS und Netzwerkverbindung
• Firewall, Load Balancer und Authentifizierung
• Virtualisierungshosts und Anwendungssysteme
• Datenbank, gemeinsamer Storage und benötigte Netzwerkpfade
• Stromversorgung und weitere gemeinsam genutzte Infrastruktur

Zwei Virtualisierungshosts schützen beispielsweise nicht vor dem Ausfall eines gemeinsam genutzten Storage-Systems, wenn dieses selbst keine geeignete Ausfallabsicherung besitzt. Ebenso können zwei Server denselben fehlerhaften Netzwerkpfad oder dieselbe Stromversorgung nutzen.

Für jede kritische Abhängigkeit muss deshalb eine bewusste Entscheidung getroffen werden: automatischer Failover, manuelle Wiederherstellung oder akzeptierte Unterbrechung. Die wirtschaftliche Bewertung berücksichtigt neben zusätzlichen Geräten auch Lizenzen, Monitoring, Tests und laufende Administration.

Bei Schweizer Hostinganbietern ist ausserdem zu unterscheiden, ob eine Verfügbarkeitszusage das Rechenzentrumsnetz, eine einzelne virtuelle Maschine oder den gesamten Anwendungsbetrieb betrifft. Ein Netzwerk-SLA ersetzt keine Vereinbarung zur Wiederherstellung einer ausgefallenen Datenbank.

Erst wenn die kritischen Abhängigkeiten und zulässigen Wiederanlaufzeiten bekannt sind, lässt sich berechnen, wie viel Serverkapazität tatsächlich benötigt wird.

Wie planen Sie Serverkapazität mit 6 Messwerten statt Bauchgefühl?

Eine belastbare Serverkapazitätsplanung basiert auf sechs Messgrössen: CPU-Auslastung, Arbeitsspeicherbedarf, Speicherplatzverbrauch, Storage-Latenz beziehungsweise IOPS, Netzwerkdurchsatz und Anwendungsantwortzeit. Diese Werte müssen über repräsentative Betriebszeiträume erfasst und gemeinsam ausgewertet werden. Für 99,9 % Verfügbarkeit ist zusätzlich zu prüfen, ob die Infrastruktur bei einem Hostausfall genügend Ressourcen bereitstellt.

Die sechs Messwerte erfüllen unterschiedliche Aufgaben:

Eine hohe CPU-Auslastung allein beweist noch keine Unterdimensionierung. Wenn die Antwortzeiten stabil bleiben und keine relevanten Warteschlangen entstehen, kann eine hohe Ressourcennutzung wirtschaftlich sinnvoll sein. Umgekehrt können niedrige CPU-Werte mit kritischen Storage-Latenzen zusammenfallen.

Die AWS-Best-Practice zur Erfassung von Serverleistungsdaten empfiehlt, Compute-Kennzahlen systematisch aufzuzeichnen, ihre Entwicklung auszuwerten und sie mit den Anforderungen des jeweiligen Workloads zu verknüpfen.

Für eine aussagekräftige Kapazitätsplanung sollten Messungen sowohl typische Arbeitstage als auch besondere Belastungen erfassen: gleichzeitige Benutzer, nächtliche Batch-Verarbeitung, Monatsabschlüsse und saisonale Auftragsspitzen. Durchschnittswerte ohne zeitlichen Kontext können entscheidende Engpässe verdecken.

Besonders wichtig ist die Dimensionierung unter reduzierter Clusterkapazität. Bei einem Cluster mit zwei Hosts muss der verbleibende Host nach dem Ausfall des anderen die erforderlichen Anwendungen mit vertretbarer Leistung betreiben können. Ist dies nicht möglich, besteht zwar technische Redundanz, aber keine ausreichende betriebliche Ausfallreserve.

Ein geeigneter Lasttest simuliert deshalb den Ausfall oder die Wartung eines Hosts und überprüft die tatsächlichen Antwortzeiten der geschäftskritischen Anwendungen. Auch Storage und Netzwerk müssen die veränderte Lastverteilung verkraften.

Die Beschaffung sollte zwischen sofort notwendiger Leistung und später erweiterbarer Kapazität unterscheiden. RAM, Storage oder zusätzliche Hosts müssen nicht vorsorglich angeschafft werden, wenn ein überprüfbarer Erweiterungspfad vorhanden ist und rechtzeitig reagiert werden kann.

Bevor daraus eine Hardwarebestellung entsteht, sollte allerdings geklärt werden, ob vermeintliche Serverengpässe tatsächlich im Netzwerk verursacht werden.

Wie finden Sie Netzwerkengpässe mit 5 Tests, bevor Sie neue Hardware kaufen?

Netzwerkengpässe lassen sich mit fünf aufeinander aufbauenden Tests eingrenzen: DNS und Verbindungsaufbau prüfen, Latenz und Paketverlust messen, den erreichbaren Durchsatz bestimmen, Schnittstellenzähler untersuchen sowie MTU-, Firewall- und Load-Balancer-Konfigurationen kontrollieren. Neue Hardware ist erst sinnvoll, wenn die Messungen eine tatsächliche Kapazitätsgrenze nachweisen.

Die Reihenfolge hilft dabei, Konfigurationsprobleme von fehlender Bandbreite zu unterscheiden.

1. DNS und Verbindungsaufbau: Prüfen, ob Namen korrekt aufgelöst werden und die benötigten Dienste über ihre vorgesehenen Netzwerkpfade erreichbar sind. Verzögerungen beim Verbindungsaufbau können auftreten, bevor relevante Daten übertragen werden.
2. Latenz und Paketverlust: Antwortzeiten und Übertragungsverluste zwischen den beteiligten Systemen messen. Die Ergebnisse entlang verschiedener Kommunikationspfade vergleichen und mögliche Einschränkungen einzelner Messverfahren berücksichtigen.
3. Tatsächlicher Durchsatz: Beispielsweise mit iperf3 die erreichbare Übertragungsleistung zwischen geeigneten Testendpunkten prüfen. Die Messung sollte kontrolliert erfolgen, damit produktive Anwendungen nicht unnötig belastet werden.
4. Portauslastung und Fehlerzähler: Switchports und Netzwerkschnittstellen auf Auslastung, Übertragungsfehler, verworfene Pakete und auffällige Zählerentwicklungen untersuchen.
5. MTU und Netzwerkfunktionen: Die Konfiguration von MTU, Firewalls und Load Balancern kontrollieren. Fehlkonfigurationen oder ungünstige Weiterleitungsregeln können die Kommunikation beeinträchtigen, ohne dass die Leitung grundsätzlich zu wenig Kapazität besitzt.

Wichtig ist, die Tests an den richtigen Stellen durchzuführen. Eine Messung zwischen Client und Anwendungsserver untersucht einen anderen Pfad als eine Messung zwischen Anwendung und Datenbank oder zwischen zwei Virtualisierungshosts.

Während einer Lastspitze sollten Netzwerkwerte mit CPU-Auslastung, Storage-Latenz und Anwendungsantwortzeit verglichen werden. Wartet eine Anwendung beispielsweise auf langsame Datenbankzugriffe, kann sich dies für Benutzer wie ein Netzwerkproblem anfühlen.

Die möglichen Massnahmen hängen vom Befund ab: DNS-Konfiguration korrigieren, fehlerhafte Schnittstellen beheben, Datenverkehr gezielter verteilen oder tatsächlich überlastete Verbindungen erweitern.

Nach jeder Anpassung sollte derselbe Test unter möglichst vergleichbaren Bedingungen wiederholt werden. Nur so lässt sich nachvollziehen, ob die Änderung den ursprünglichen Engpass beseitigt hat.

Sind Netzwerk- und Kapazitätsbedarf geklärt, folgt die Frage, mit welcher Betriebsplattform die Anwendungen möglichst zuverlässig und effizient bereitgestellt werden.

VMs oder Container: Was ist sinnvoll bei 10 Anwendungen und kleinem Team?

Für zehn Anwendungen und ein kleines IT-Team sind virtuelle Maschinen häufig ein überschaubarer Ausgangspunkt. Container können Vorteile bieten, wenn Anwendungen regelmässig aktualisiert werden und ihre Bereitstellung automatisiert ist. Eine orchestrierte Containerplattform lohnt sich dagegen nicht allein wegen der Anwendungszahl: Ihr zusätzlicher Betriebsaufwand muss durch konkrete Anforderungen gerechtfertigt sein.

Die Entscheidung hängt insbesondere von Betriebssystemabhängigkeiten, persistenten Daten, Änderungsfrequenz, Ressourcenverbrauch und Wiederherstellungsanforderungen ab.

Drei Betriebsmodelle stehen zur Auswahl:

Container sind keine Hochverfügbarkeitsfunktion. Fällt ein Host aus, müssen Anwendungen auf verbleibenden Hosts neu gestartet oder übernommen werden können. Dafür benötigen sie passende Netzwerkverbindungen, Zugriff auf persistente Daten und ausreichende Rechenkapazität.

Auch eine orchestrierte Plattform kann ausfallen, wenn ihre Steuerung, Speicheranbindung oder Netzwerkinfrastruktur nicht entsprechend ausgelegt ist.

Als ausdrücklich hypothetisches Beispiel dient ein Unternehmen mit zehn Anwendungen, darunter eine ältere ERP-Lösung, mehrere interne Fachanwendungen und häufig aktualisierte Webdienste.

Die Entscheidungsmatrix sollte Teamkapazität, Automatisierungsgrad, Änderungsfrequenz und Anforderungen an die Wiederherstellung berücksichtigen. Dabei zählt nicht nur die anfängliche Einrichtung, sondern auch, ob die verantwortlichen Personen die Umgebung bei einem Ausfall zuverlässig diagnostizieren und wiederherstellen können.

Unabhängig vom gewählten Modell muss die Hochverfügbarkeit auch während regulärer Änderungen erhalten bleiben. Gerade beim Patchen entstehen vermeidbare Ausfallrisiken.

Der Patch-Fehler, der ein System-Update zum Totalausfall macht

Ein besonders kritischer Wartungsfehler entsteht, wenn mehrere redundante Hosts gleichzeitig aktualisiert oder neu gestartet werden. Obwohl die Infrastruktur für den Ausfall eines Hosts ausgelegt ist, fehlt dann die verbleibende Kapazität für die produktiven Anwendungen. Ein geplantes Update kann dadurch eine vollständige Unterbrechung des Betriebs verursachen.

Das Problem liegt nicht zwangsläufig in fehlerhafter Hardware. Vielmehr wurde die Redundanz durch den Wartungsablauf vorübergehend ausser Kraft gesetzt.

Ein kontrolliertes Rolling-Update reduziert dieses Risiko, wenn die Architektur und die betroffenen Komponenten ein solches Vorgehen unterstützen:

1. Clusterzustand, Alarme, Replikation und verfügbare Kapazität vor Beginn prüfen.
2. Den ersten Host kontrolliert aus dem produktiven Betrieb nehmen und betroffene Anwendungen auf geeignete verbleibende Hosts verschieben.
3. Updates installieren und erforderliche Neustarts ausführen.
4. Host, Clusterintegration und betroffene Anwendungen auf Funktion und Stabilität kontrollieren.
5. Erst nach erfolgreicher Prüfung mit dem nächsten Host fortfahren.

Dieses Verfahren setzt voraus, dass die verbleibende Infrastruktur die produktive Last bewältigt. Ein Cluster, der bereits im Normalbetrieb sämtliche verfügbaren Ressourcen benötigt, ist nicht automatisch wartungsfähig ohne Unterbrechung.

Zusätzlich müssen technische Abhängigkeiten geprüft werden. Änderungen an Hypervisoren, Betriebssystemen, Storage-Treibern oder Datenbanken können unterschiedliche Kompatibilitätsanforderungen besitzen. Gemeinsame Clusterkomponenten und Quorum-Regeln sind besonders kritisch, weil ein ungeeigneter Aktualisierungsablauf die gesamte Umgebung beeinträchtigen kann.

Ein Rollback muss vor dem Update realistisch geplant werden. Eine Konfigurationsänderung lässt sich unter Umständen einfach zurücknehmen. Datenbankschemaänderungen oder bestimmte Cluster-Upgrades können hingegen eine Wiederherstellung aus einer geeigneten Sicherung oder ein gesondertes Rückfallverfahren erforderlich machen.

Für jede Wartung sollten deshalb überprüfbare Abbruchkriterien dokumentiert werden: Welche Alarme stoppen den Ablauf? Welche Funktionsprüfungen müssen erfolgreich sein? Wer entscheidet über die Fortsetzung und wie wird die ursprüngliche Betriebsfähigkeit wiederhergestellt?

Auch zeitlich geplante Wartungen müssen mit den vereinbarten SLA-Regelungen abgestimmt werden. Nicht jedes SLA behandelt Wartungsunterbrechungen gleich.

Sind Kapazitätsplanung und Betrieb unter Kontrolle, können Infrastrukturkosten reduziert werden, ohne die notwendigen Sicherheitsreserven aufzugeben.

Welche 3 Massnahmen senken Infrastrukturkosten, ohne Verfügbarkeit zu gefährden?

Drei Massnahmen können Infrastrukturkosten senken, ohne die vereinbarte Verfügbarkeit zu gefährden: Ressourcen anhand gemessener Last richtig dimensionieren, Anwendungen entsprechend ihrer geschäftlichen Kritikalität unterschiedlich absichern und Eigenbetrieb, Schweizer Hosting sowie Managed Services anhand der gesamten Betriebskosten vergleichen. Einsparungen sind nur belastbar, wenn die verbleibende Infrastruktur weiterhin die notwendigen Ausfallreserven und Wiederherstellungsziele erfüllt.

1. Überdimensionierte Ressourcen gezielt reduzieren

Virtuelle Maschinen werden im Betrieb häufig mit mehr Ressourcen ausgestattet, als dauerhaft benötigt werden. Auch ungenutzte Storage-Reserven und selten benötigte Instanzen können laufende Kosten verursachen.

Eine Reduktion sollte sich jedoch nicht auf durchschnittliche CPU- oder RAM-Werte stützen. Entscheidend sind Lastspitzen, Speicherwachstum und die verfügbare Kapazität nach dem Ausfall eines Hosts.

Wird beispielsweise der zugewiesene Arbeitsspeicher einer VM reduziert, müssen anschliessend Anwendungsantwortzeiten und möglicher Speicherdruck überprüft werden.

2. Verfügbarkeit nach Geschäftskritikalität differenzieren

Nicht jede Anwendung benötigt denselben Schutz. Ein produktives Bestell- oder Abrechnungssystem kann andere Wiederanlaufanforderungen haben als eine interne Testumgebung.

Eine betriebliche Klassifizierung sollte deshalb mindestens die Auswirkungen eines Ausfalls, die zulässige Unterbrechungszeit und den tolerierbaren Datenverlust erfassen.

Dadurch können hochverfügbare Ressourcen gezielt den Anwendungen zugeordnet werden, deren Ausfall erhebliche Geschäftsfolgen hätte. Weniger kritische Systeme können gegebenenfalls mit einfacheren Wiederherstellungsverfahren betrieben werden.

Die zugesagten Verfügbarkeitsziele geschäftskritischer Anwendungen dürfen dadurch nicht stillschweigend reduziert werden.

3. Gesamtkosten statt Anschaffungspreise vergleichen

Ein günstiger monatlicher Hostingpreis ist nicht automatisch günstiger als Eigenbetrieb. Ebenso ist ein bereits vorhandener Server nicht kostenfrei.

Ein sinnvoller Vergleich berücksichtigt:

• Hardwarebeschaffung beziehungsweise wiederkehrende Hostinggebühren in CHF
• Softwarelizenzen, Support und Wartungsverträge
• Stromversorgung, Kühlung und benötigte Stellfläche
• Administration, Überwachung und notwendige Fachkenntnisse
• Backup, Wiederherstellung und Ausfallvorsorge
• Ersatzbeschaffung, Erweiterbarkeit und mögliche Vertragsabhängigkeiten

Bei Managed Services muss zusätzlich geprüft werden, welche Betriebsaufgaben tatsächlich übernommen werden und welche weiterhin beim Unternehmen liegen.

Eine belastbare Entscheidung benötigt einen Vorher-nachher-Vergleich: jährliche Gesamtkosten, verbleibende Failover-Kapazität, Anwendungsleistung und gemessene Wiederanlaufzeiten. Eine nominell günstigere Architektur ist keine wirtschaftliche Verbesserung, wenn sie kritische Ausfallrisiken erhöht.

Bei der Bewertung sollten auch die Kosten für Datensicherung und Wiederherstellung einbezogen werden. Diese Aufgaben bleiben selbst dann notwendig, wenn die produktive Infrastruktur redundant ausgelegt ist.

Wie erstellen Sie einen Backup-Plan mit der 3-2-1-Regel, der wirklich umsetzbar ist?

Ein umsetzbarer Backup-Plan nach der verbreiteten 3-2-1-Regel sieht mindestens drei Datenkopien einschliesslich der produktiven Daten, zwei unterschiedliche Speichermedien beziehungsweise Speichertechnologien und eine Kopie an einem anderen Standort vor. Entscheidend sind zusätzlich geeignete Sicherungsintervalle, getrennte Zugriffsrechte, dokumentierte Verantwortlichkeiten und eine Wiederherstellung, die mit den vorhandenen Ressourcen tatsächlich durchführbar ist.

Die 3-2-1-Regel beschreibt eine grundlegende Verteilung von Datenkopien. Sie legt jedoch nicht automatisch fest, wie häufig gesichert werden muss, wie lange Kopien aufzubewahren sind oder wie schnell Anwendungen wiederhergestellt werden können.

Für Schweizer Unternehmen ist die Empfehlung des Bundesamt für Cybersicherheit (BACS) relevant. Im Halbjahresbericht 2024/I des Bundesamts für Cybersicherheit wird für besonders wichtige Daten eine 3-2-1-Strategie beschrieben, bei der mindestens drei Sicherungskopien auf zwei Lokalitäten verteilt und mindestens eine davon vollständig offline gehalten werden sollen.

Diese behördliche Formulierung unterscheidet sich von der verbreiteten Definition mit drei Datenkopien einschliesslich des produktiven Datenbestands und zwei Medientypen. Beide Ansätze unterstreichen jedoch, dass Sicherungen nicht vollständig von derselben Infrastruktur beziehungsweise demselben Zugriff abhängig sein sollten.

Für die praktische Planung sind zwei Wiederherstellungskennzahlen notwendig:

• Recovery Point Objective (RPO): der maximal tolerierbare Datenverlust, ausgedrückt als zeitlicher Abstand zum letzten wiederherstellbaren Datenstand.
• Recovery Time Objective (RTO): die angestrebte maximale Zeitspanne bis zur Wiederherstellung des benötigten Betriebs.

Eine Anwendung mit geringem tolerierbarem Datenverlust benötigt möglicherweise häufigere Sicherungen oder zusätzliche transaktionsbasierte Verfahren. Für weniger kritische Systeme können längere Sicherungsintervalle genügen.

Die technische Unabhängigkeit der Kopien muss dabei ausdrücklich geprüft werden. Eine externe Sicherung kann weiterhin gefährdet sein, wenn derselbe kompromittierte Administratorzugang sämtliche Kopien löschen kann. Offline gehaltene oder ausreichend geschützte unveränderbare Sicherungen können dieses Risiko begrenzen.

Ebenso sind zwei Schadensszenarien getrennt zu betrachten: der Ausfall des primären Standorts und eine Kompromittierung administrativer Zugänge.

Für jedes Backup sollten Speicherort, Verantwortlichkeit, Zugriffsschutz, Sicherungsrhythmus und Aufbewahrung dokumentiert sein. Bei Schweizer Hostingangeboten gehören auch Datenstandort, Übertragungswege und vertraglich geregelte Zuständigkeiten zur Prüfung.

Schliesslich muss der Plan wirtschaftlich und operativ tragfähig sein. Datenvolumen, Speicherwachstum, Übertragungsdauer, verfügbare Bandbreite und Lizenzkosten beeinflussen die Wahl der Sicherungsstrategie. Backup-Fenster dürfen den produktiven Betrieb nicht unnötig beeinträchtigen.

Die Existenz mehrerer Sicherungskopien beweist allerdings noch nicht, dass eine Geschäftsanwendung nach einem Ausfall wieder verwendet werden kann. Dies lässt sich erst durch einen vollständigen Wiederherstellungstest feststellen.

Warum regelmässige Backups nutzlos sein können, wenn Sie nie einen Restore testen

Ein Backup kann technisch erfolgreich abgeschlossen werden und im Notfall trotzdem unbrauchbar sein. Sicherungsdateien allein beweisen weder die Vollständigkeit der Daten noch die Wiederherstellbarkeit einer gesamten Anwendung. Fehlen Datenbankkonfigurationen, Zugangsdaten oder benötigte Systemabhängigkeiten, kann ein scheinbar erfolgreicher Restore scheitern oder die Anwendung unbenutzbar bleiben.

Das Risiko betrifft nicht nur beschädigte Sicherungsdateien. Auch unvollständig dokumentierte Wiederherstellungsabläufe, veraltete Konfigurationen und längere als erwartete Übertragungszeiten können verhindern, dass ein vereinbartes Wiederanlaufziel erreicht wird.

Die AWS-Dokumentation zur Überprüfung von Backup-Wiederherstellungen empfiehlt regelmässige Wiederherstellungstests. Dabei sollen unter anderem Datenintegrität, Zugänglichkeit und die Einhaltung der definierten RTO- und RPO-Ziele überprüft werden.

Ein vollständiger Anwendungstest geht über die Kontrolle einzelner Dateien hinaus.

Ein nachvollziehbarer Restore-Test umfasst folgende Schritte:

1. Eine geeignete Sicherung auswählen und den erwarteten Datenstand dokumentieren.
2. Die benötigten Systeme in einer isolierten Testumgebung wiederherstellen.
3. Daten auf Vollständigkeit, Integrität und Zugänglichkeit prüfen.
4. Anwendung, Datenbankverbindungen, Konfigurationen und erforderliche Berechtigungen kontrollieren.
5. Einen repräsentativen Geschäftsprozess vollständig ausführen.
6. Die tatsächlich benötigte Wiederherstellungszeit und den erreichten Datenstand mit RTO und RPO vergleichen.

Die Zeitmessung sollte mit dem tatsächlichen Beginn des Notfallprozesses starten und erst enden, wenn die benötigte Anwendung wieder nutzbar ist. Eine reine Messung der Dateikopierdauer bildet den betrieblichen Wiederanlauf nicht vollständig ab.

Auch der wiederhergestellte Datenstand muss überprüft werden. Ist die Anwendung zwar funktionsfähig, fehlen aber mehr aktuelle Daten als laut RPO zulässig, wurde das Wiederherstellungsziel nicht vollständig erfüllt.

Die Testergebnisse liefern zudem konkrete Hinweise zur Verbesserung: fehlende Zugangsdaten, nicht gesicherte Konfigurationsdateien, unzureichende Übertragungsleistung oder zu viele manuelle Arbeitsschritte.

Nach wesentlichen Änderungen an Anwendungen, Datenbanken, Netzwerk oder Backup-Infrastruktur sollte überprüft werden, ob die bisherigen Wiederherstellungsverfahren weiterhin funktionieren. Eine pauschale Testhäufigkeit ist dabei weniger aussagekräftig als ein Rhythmus, der zur Kritikalität und Änderungshäufigkeit der Systeme passt.

Ein erfolgreicher Restore-Test allein beweist zwar keine jährliche Verfügbarkeit von 99,9 %. Er liefert jedoch die erforderlichen Messdaten, um die Wiederherstellungsfähigkeit realistisch zu beurteilen.

Der nächste sinnvolle Schritt besteht darin, für eine geschäftskritische Anwendung einen vollständigen Restore-Test durchzuführen, ihre Wiederanlaufzeit zu messen und anschliessend Kapazitätsreserven, Betriebsverfahren und Sicherungsstrategie anhand der Ergebnisse gezielt anzupassen.