Hot Site, Warm Site, Cold Site: was jedes Ausweichrechenzentrum vorhält und wo DRaaS einzuordnen ist

Hot Site, Warm Site und Cold Site: was jeder Standort vorhält

Eine Cold Site bietet Raum, Strom, Kühlung und Netzwerkanschlüsse, aber keine IT-Ausrüstung. Eine Warm Site hält die Hardware und die Telekommunikation ganz oder teilweise bereit, während Systeme und Daten noch auf den aktuellen Stand gebracht werden müssen. Eine Hot Site ist für die Systeme dimensioniert, die sie schützt, und mit Hardware, Infrastruktur und Personal ausgestattet, sodass Systeme dort mit wenig Aufbauarbeit starten. Wie viel vor einer Katastrophe bereits vorhanden ist, bestimmt sowohl die Wiederanlaufzeit als auch die Kosten, das Ausweichrechenzentrum einsatzbereit zu halten.

Die hier verwendeten Definitionen stammen aus Abschnitt 3.4.3 der NIST Special Publication 800-34 Revision 1, dem Contingency Planning Guide for Federal Information Systems (aktualisiert am 11. November 2010, Stand Oktober 2026 die gültige Fassung). NIST ordnet Ausweichstandorte nach ihrer „Betriebsbereitschaft“. Cold Sites sind typischerweise Räumlichkeiten „mit ausreichend Platz und Infrastruktur (Stromversorgung, Telekommunikationsanschlüsse und Klimatisierung), um Wiederherstellungsarbeiten am Informationssystem zu unterstützen“. Warm Sites sind „teilweise ausgestattete Büroräume, die einen Teil oder die gesamte Hardware, Software, Telekommunikation und Stromversorgung des Systems enthalten“. Hot Sites sind „angemessen dimensioniert, um die Systemanforderungen zu erfüllen, und mit der nötigen Systemhardware, unterstützender Infrastruktur und Supportpersonal ausgestattet“. Als Varianten nennt NIST mobile Standorte (Mobile Sites), „in sich geschlossene, transportable Einheiten“, und gespiegelte Standorte (Mirrored Sites), „vollständig redundante Standorte mit automatischer Echtzeitspiegelung der Informationen“.

NIST SP 800-34 Rev. 1, Abschnitt 3.4.3 und die dortigen Beispielkriterien für Ausweichstandorte (Zeilen für Cold, Warm und Hot Site; mobile und gespiegelte Standorte aus dem Text). Die Erläuterungen nach jeder Bewertung der Aufbauzeit und die Spalte zum Vorhalteaufwand sind unsere Zusammenfassung.

Anbieter verwenden dieselben Begriffe für unterschiedliche Zustände. Das Disaster-Recovery-Whitepaper von AWS (zuletzt überarbeitet am 1. April 2022) bezeichnet als Warm Standby „eine verkleinerte, aber voll funktionsfähige Kopie Ihrer Produktionsumgebung“, die bereits läuft, und als Hot Standby einen Aktiv/Passiv-Aufbau, bei dem „DR-Regionen keinen Datenverkehr annehmen“. Ein als warm bezeichnetes Angebot kann daher ungenutzte Hardware bedeuten oder Server, die in verkleinertem Umfang laufen; vergleichen Sie Angebote also danach, was installiert ist, wie aktuell die Daten sind und was nach der Ausrufung des Katastrophenfalls noch zu tun bleibt.

Cold Site: Raum und Strom, Wiederherstellung aus Backups

Bei einer Cold Site beginnt der Wiederanlauf mit dem Aufbau der Plattform. NIST hält fest, dass Cold Sites „im Unterhalt am kostengünstigsten sind, auch wenn sie erhebliche Zeit für die Beschaffung und Installation der nötigen Ausrüstung erfordern können“. Abschnitt 3.4.4 des Leitfadens nennt drei Wege zur Hardware: Vereinbarungen mit Lieferanten, bei denen „das SLA festlegen sollte, wie schnell der Lieferant nach der Benachrichtigung reagieren muss“ und welche Priorität Sie bei einer Katastrophe erhalten, „die mehrere Kunden des Lieferanten betrifft“; im Voraus gekaufte und außer Haus gelagerte Ausrüstung; und kompatible Ausrüstung, die anderswo in der Organisation im Einsatz ist. Danach folgen Hypervisoren, Speicher und die Backup-Infrastruktur und erst dann die Wiederherstellung aus den Kopien außer Haus, zuerst Verzeichnisdienst und DNS, mit der Datenrate, die das langsamste Element im Pfad zulässt; unser Artikel dazu, warum Backup kein Disaster Recovery ist, rechnet das durch.

Warm Site im Disaster Recovery: teilweise ausgestattet, teilweise aktuell

Eine Warm Site liegt in der Mitte der Skala von NIST; in den Beispielkriterien für Ausweichstandorte ist ihre Hardware mit „teilweise“ bewertet, ihre Telekommunikation mit „teilweise/vollständig“ und ihre Aufbauzeit mit „mittel“. In einer virtualisierten Umgebung kann sie aus einem kleineren Cluster oder älteren Hosts in einem anderen Gebäude oder einem Colocation-Rack bestehen, mit Speicher, der Backup-Kopien oder periodische Replikate empfängt, und einer WAN-Verbindung, die bereits steht. Daten, die schon auf dem Speicher des Standorts liegen, lassen sich vor Ort wiederherstellen oder starten, während Daten, die nur auf Band oder in einem Cloud-Archiv liegen, zuerst übertragen werden müssen. Hosts, die nur einen Teil der Produktionslast tragen, brauchen eine vorab abgestimmte Startliste. Konfigurationsdrift kostet zusätzlich Zeit, denn Hypervisor-Versionen, Netzwerkeinstellungen und Firewall-Regeln, die sich seit dem letzten Test in der Produktion geändert haben, müssen an der Warm Site abgeglichen werden; NIST verlangt bei der Auswahl eines Standorts eine verwandte Prüfung, damit „die Sicherheits-, Management-, Betriebs- und technischen Maßnahmen des Systems mit dem in Betracht kommenden Standort vereinbar sind“.

Hot Site im Disaster Recovery und gespiegelte Standorte

NIST bewertet Hardware und Telekommunikation einer Hot Site mit „vollständig“ und ihre Aufbauzeit mit „kurz“. Die Definition der Hot Site erfasst keine Daten; wie alt diese sind, hängt davon ab, wie Kopien an den Standort gelangen. Tabelle 3-2 ordnet der Hot Site für missionskritische Systeme „gespiegelte Systeme und Plattenreplikation“ zu. Sind replizierte Daten und Hardware vorhanden, entscheiden die Startreihenfolge und die Umleitung von Benutzern und Netzwerkverkehr über den größten Teil der Wiederanlaufzeit.

Ein gespiegelter Standort ist „in allen technischen Belangen mit dem primären Standort identisch“. Die Spiegelung kopiert jeden Schreibvorgang, auch beschädigte und verschlüsselte, und AWS merkt für Multi-Site Active/Active an, dass „bei Datenbeschädigung unter Umständen auf Backups zurückgegriffen werden muss, was in der Regel zu einem Wiederherstellungspunkt ungleich null führt“. Synchrone Spiegelung begrenzt außerdem die Entfernung zwischen den Standorten. Unsere Seite zu Cloud Disaster Recovery ordnet Aktiv-aktiv-Synchron-Clustering den Fällen zu, in denen schon eine Stunde Ausfall zu viel ist, und hält fest, dass es Infrastruktur und Budget verdoppelt.

Mobile Standorte und Gegenseitigkeitsvereinbarungen

Ein mobiler Standort wird als transportable Einheit geliefert, „individuell mit bestimmter Telekommunikations- und Systemausstattung ausgerüstet“. Laut NIST können „mobile Standorte in vielen Fällen innerhalb von 24 Stunden an den gewünschten Ort geliefert werden“, und Installation und Aufbau verlängern diese Zeit; der Aufstellort braucht weiterhin Strom- und Netzwerkanschlüsse.

Eine Gegenseitigkeitsvereinbarung teilt die Kosten mit einer anderen Organisation: „Zwei oder mehr Organisationen mit ähnlichen oder identischen Systemkonfigurationen und Backup-Technologien können eine formelle Vereinbarung schließen, einander als Ausweichstandort zu dienen“. NIST warnt, dass „jeder Standort in der Lage sein muss, im Katastrophenfall zusätzlich zur eigenen Arbeitslast den anderen zu unterstützen“, dass beide Seiten die Wiederherstellungsreihenfolge gemeinsam festlegen müssen und dass Tests Kapazitätsreserven, kompatible Konfigurationen, Sicherheitsmaßnahmen und „die Sensibilität von Daten, die für andere privilegierte Benutzer zugänglich sein könnten“, abdecken sollten. Der Partner kann auch intern sein; dasselbe gilt daher für zwei Rechenzentren eines Unternehmens, die wechselseitig aufeinander replizieren.

Wovon die Kosten der einzelnen Standorttypen abhängen

Der gespiegelte Standort ist in den Worten von NIST „die teuerste Wahl“, während teilweise ausgestattete Standorte wie Warm Sites „in der Mitte des Spektrums liegen“, oberhalb der Cold Sites. Die Vorlage von NIST für die Budgetplanung gliedert die Kosten einer Cold Site, Warm Site oder Hot Site in Anbieter-, Hardware-, Software-, Reise- und Versand-, Personal- oder Auftragnehmer-, Test- und Materialkosten.

Die für den Wiederanlauf vorgehaltene Hardware ist an Warm Sites, Hot Sites und gespiegelten Standorten der sichtbarste Posten, mit Wartungsverträgen und einem eigenen Erneuerungszyklus. Standby-Systeme brauchen Softwarelizenzen zu den Bedingungen, die der jeweilige Hersteller für die Standby- oder DR-Nutzung festlegt. Die Datenverbindung wird bei Backup-Kopien für eine nächtliche Übertragung dimensioniert, bei Replikation für die Änderungsrate und bei synchroner Spiegelung zusätzlich für niedrige Latenz. Personal hält den Ausweichstandort auf dem Stand der Produktion, denn eine nur am primären Standort vorgenommene Änderung kann sich beim Failover als fehlgeschlagener Start zeigen. Bei einem kommerziellen Standort kommt hinzu, was NIST als „Kosten-/Gebührenstruktur für die Ausrufung des Katastrophenfalls und die Belegung (tägliche Nutzung)“ aufführt, dazu Gebühren für Verwaltung, Wartung und Tests. Unsere Seite zu Cloud Disaster Recovery fasst den Fall des eigenen Standorts zusammen: „Ein eigener Standby-Standort bedeutet doppelte Hardware, Lizenzen und Personal.“

Wo DRaaS unter den Standorttypen einzuordnen ist

Disaster Recovery as a Service ist ein kommerziell angemieteter Standort, bei NIST der dritte Weg neben einem eigenen Standort und einer Gegenseitigkeitsvereinbarung. Bei einem replikationsbasierten Service betreibt der Anbieter die Räumlichkeiten, das Netzwerk und die Rechenkapazität, und Ihre virtuellen Maschinen kommen als Replikate an, die Veeams Quick Start Guide als exakte Kopien im nativen vSphere-Format „im startbereiten Zustand“ beschreibt; unser Leitfaden zu Veeam-Replikation, Backup Copy und Cloud Connect erklärt, wie sie aktuell gehalten werden. Nach unserer Lesart liegt ein solcher Standort zwischen Warm Site und Hot Site. Wo der Vertrag Kapazität für Sie reserviert, entspricht der Standort den Hot-Site-Bewertungen von NIST mit vollständiger Hardware und Telekommunikation und kurzer Aufbauzeit, während seine Daten so aktuell sind wie der letzte Replikationslauf und die Systeme bis zum Failover ausgeschaltet bleiben.

Ansätze und typische Werte aus dem Vergleich auf unserer Seite zu Cloud Disaster Recovery; NIST-Typen aus SP 800-34 Rev. 1, Tabelle 3-2 und Abschnitt 3.4.3. Die Zuordnung ist unsere Lesart.

Wie nahe ein DRaaS-Standort im Katastrophenfall an eine Hot Site herankommt, hängt weitgehend vom Vertrag ab. Die Liste von NIST, was eine Vereinbarung über einen Ausweichstandort regeln sollte, deckt das meiste davon ab: wie der Katastrophenfall ausgerufen wird, vorrangiger Zugang, andere Kunden, die dieselben Ressourcen abonniert haben, und Testzeit. Für einen kommerziellen Standort will NIST außerdem „Wiederherstellungstage (wie lange die Organisation die Fläche während der Wiederherstellungsphase belegen kann)“ im Vertrag sehen. Der Leitfaden warnt, dass ein gemeinsam genutzter Standort „möglicherweise nicht alle Kunden aufnehmen kann, wenn eine Katastrophe genügend dieser Kunden gleichzeitig trifft“. Unsere DRaaS-Checkliste macht daraus Fragen, die Sie vor der Unterschrift stellen sollten.

Unser Service Cloud Disaster Recovery ist ein Standort dieser Art: Ihre Systeme starten aus Replikaten in Baltnetas Tier-3-Rechenzentren in Litauen und laufen, während Ihre Primärseite steht. Nennen Sie uns, welche Systeme einen solchen Standort brauchen und wie Sie sie heute wiederherstellen.

Den Standorttyp für jede Systemstufe wählen

Tabelle 3-2 von NIST gibt Beispiele, die Standorttypen der Auswirkung zuordnen: Verlagerung oder eine Cold Site für Systeme mit geringer Auswirkung, eine Cold Site oder Warm Site für Systeme mit mittlerer Auswirkung und eine Hot Site für missionskritische Systeme. Für jedes System mit mittlerer oder hoher Auswirkung sollte der Plan „eine Strategie enthalten, um den Systembetrieb an einem Ausweichstandort wiederherzustellen und dort über einen längeren Zeitraum fortzuführen“.

1. Teilen Sie die Systeme nach den Folgen von Ausfallzeit und Datenverlust in Stufen ein, wie es unser Leitfaden zur Festlegung von RPO und RTO je System beschreibt.
2. Vergleichen Sie den RTO jeder Stufe mit der Zeit, die eine Cold Site braucht, um Hardware zu beschaffen und Daten wiederherzustellen; dauert das zu lange, braucht die Stufe bereitstehende Hardware an einer Warm Site, einer Hot Site oder einem DRaaS-Standort.
3. Vergleichen Sie ihren RPO damit, wie oft Daten den primären Standort verlassen: Tägliche Backup-Kopien passen zu einer Cold Site oder Warm Site, Replikation zu einer Warm Site, einer Hot Site oder DRaaS und synchrone Spiegelung zu einem RPO nahe null.
4. Wählen Sie einen Standort, der, in den Worten von NIST, „voraussichtlich nicht von derselben Gefährdung beeinträchtigt wird“ wie der primäre Standort; unser Artikel zur Entfernung des Ausweichrechenzentrums behandelt, welche Entfernung das bedeutet.
5. Halten Sie schriftlich fest, was jedem Standort am Tag des Ernstfalls fehlt und wer es liefert, und testen Sie dann den Wiederanlauf gegen die Zielwerte.

Für die in ihrem Artikel 1 genannten Einrichtungen verlangt die Durchführungsverordnung (EU) 2024/2690 in Punkt 4.2.4 „eine zumindest teilweise Redundanz“ von Netz- und Informationssystemen, Betriebsstätten, Ausrüstung, Personal und Kommunikationskanälen, ohne einen Standorttyp zu nennen. Ob ein Unternehmen darunter fällt, ist eine rechtliche Bewertung, die bei seiner Rechtsabteilung liegt.

In unserem DR-Strategie-Design definieren wir gemeinsam mit Ihnen die kritischen Systeme und Ziel-RPO und -RTO je Systemstufe. Beschreiben Sie Ihre Stufen im Formular unten, mit dem Standort, an dem jede Stufe heute wiederhergestellt würde.

Was wir tun

Unser Service Cloud Disaster Recovery gibt kritischen Systemen einen Ausweichstandort ohne eigenes zweites Rechenzentrum: Kapazität in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS), geographisch von Ihrer Primärinfrastruktur getrennt, mit EU-Datenresidenz. Unser Engineering-Partner Vixen.UNO richtet die VM-Replikation ab einem 15-Minuten-Intervall über Veeam Cloud Connect ein, verwaltet aus Ihrer Veeam-Konsole oder komplett auf unserer Seite, und führt planmäßige Failover-Tests in einer isolierten Umgebung durch, mit einem Bericht nach jedem Test. Die Standardziele sind ein RPO ab 15 Minuten und ein RTO von 1 bis 2 Stunden für kritische Systeme, und Ihre Ziele je Systemstufe werden im SLA fixiert. Braucht ein System einen RPO von null, ist das Aktiv-aktiv-Synchron-Clustering, eine andere Lösungsklasse, und das sagen wir im ersten Gespräch. Standort, Replikation, Tests und Support laufen über einen EU-Vertrag und eine Rechnung von Eurokommerz.

FAQ