Eine Hot Site ist ein voll ausgestatteter Ausweichstandort, an dem Hardware, Software, Netzwerkanbindungen und aktuelle Daten bereits vorhanden sind und der innerhalb von Minuten bis Stunden vom Primärstandort übernehmen kann. Sie ist die schnellste und teuerste Art eines Disaster-Recovery-Standorts. In der Cloud entspricht ihr ein Hot-Standby- oder Active/Active-Setup in einer zweiten Region.
Das Wichtigste in Kürze
- NIST beschreibt Hot Sites als Einrichtungen, die auf das System ausgelegt und mit der nötigen Hardware, unterstützenden Infrastruktur und dem Supportpersonal ausgestattet sind.
- Ihre Daten werden kontinuierlich oder kurz nach dem Primärsystem aktualisiert, sodass wenig Daten verloren gehen und die Wiederherstellung schnell ist.
- Warm Sites halten einen Teil der Ausstattung vor und brauchen vor der Nutzung eine Einrichtung. Cold Sites bieten nur Fläche und Strom.
- In AWS-Begriffen entspricht das „Hot Standby“ (Active/Passive mit voller Kapazität) oder „Multi-Site Active/Active“, der komplexesten und teuersten Strategie.
- Replikation schützt nicht vor Datenkorruption oder Ransomware. Sie brauchen weiterhin Point-in-Time-Backups.
Was ist eine Hot Site in der Disaster Recovery?
Das ist ein alternativer Standort, an dem bereits eine Kopie Ihrer Produktivsysteme läuft oder sofort laufen kann. Fällt der Primärstandort aus, leiten Sie die Nutzer um und arbeiten weiter.
Die maßgebliche US-Referenz ist NIST SP 800-34, der Contingency Planning Guide for Federal Information Systems. Er definiert diesen Standorttyp als einen mit ausreichender Ausstattung, der aktuellen Produktionssoftware und ausreichendem Speicher, auf dem die neuesten gesicherten Daten geladen sind. Vielfach werden seine Datenbanken gleichzeitig mit den primären oder kurz danach aktualisiert. NIST weist außerdem darauf hin, dass der Standort eine Möglichkeit braucht, die Konnektivität der Nutzer schnell umzuleiten, und einen Betriebssupport nahe dem des Produktionsstandorts.
Ein NIST-Beispiel sind zwei identische Systeme an verschiedenen Orten, beide in Produktion, jedes in der Lage, die volle Last zu tragen, mit kontinuierlich synchronisierten Daten. NIST bezeichnet dies als die teuerste Option.
Hot Site, Warm Site und Cold Site im Vergleich
Die drei Standorttypen unterscheiden sich darin, wie viel vor einem Notfall bereitsteht. Mehr Bereitschaft bedeutet schnellere Wiederherstellung und höhere laufende Kosten.
| Merkmal | Cold Site | Warm Site | Hot Site |
|---|---|---|---|
| Was vorhanden ist | Fläche, Strom, Telekommunikationsanschlüsse, Umgebungskontrollen | Teile oder die gesamte Hardware, Software, Telekommunikation und Stromversorgung | Komplette Hardware, unterstützende Infrastruktur und Personal |
| Daten | Werden nach dem Ereignis aus dem Backup wiederhergestellt | Wiederhergestellt oder teilweise repliziert | Aktuell oder nahezu aktuell, oft kontinuierlich repliziert |
| Einrichtungszeit | Lang | Mittel | Kurz |
| Kosten | Niedrig | Mittel | Mittel bis hoch |
| Typische Verwendung | Systeme, die tagelang ausfallen dürfen | Wichtige Systeme mit gewisser Toleranz | Systeme, bei denen Minuten Ausfallzeit zählen |
Die Zeilen zu Einrichtungszeit und Kosten folgen der Beispieltabelle der Kriterien für Ausweichstandorte von NIST. Die tatsächlichen Wiederherstellungszeiten hängen von Ihrem Design und Ihren Tests ab, nicht von der Bezeichnung.
Wie funktioniert eine Hot Site?
Ein funktionierendes Setup besteht aus vier Teilen, die mit der Produktion im Gleichschritt bleiben müssen:
- Infrastruktur: Server, Storage und Netzwerkkapazität, dimensioniert für die Last, die dort laufen soll.
- Datenreplikation: synchrones oder asynchrones Kopieren von Datenbanken und Dateien vom Primärstandort.
- Konfiguration und Code: dieselben Softwareversionen, Patches und Einstellungen wie in der Produktion, idealerweise aus denselben Infrastructure-as-Code-Vorlagen ausgerollt.
- Umschalten des Datenverkehrs: Änderungen an DNS, Load Balancer oder Netzwerk, die Nutzer bei Aktivierung zum Ausweichstandort leiten.
Was passiert bei der Aktivierung?
Die Aktivierung ist eine Entscheidung, nicht nur ein technischer Schritt. Die Incident-Leitung bestätigt, dass der Primärstandort sich nicht innerhalb der vereinbarten Recovery Time Objective (RTO) erholen kann, dann folgt das Team dem Runbook: Schreibzugriffe auf den Primärstandort nach Möglichkeit stoppen, die Replikat-Datenbanken hochstufen, den Datenverkehr umschalten, prüfen, ob die Anwendungen funktionieren, und Nutzer sowie Stakeholder informieren. AWS weist darauf hin, dass ein automatischer Failover auf Basis von Health Checks mit Vorsicht eingesetzt werden sollte, weil ein Fehlalarm Verfügbarkeit und Daten kostet. Viele Teams lösen den Failover daher manuell aus, automatisieren aber jeden Schritt hinter dem Knopf.
Hot Sites in der Cloud: Hot Standby und Active/Active
In der Cloud mieten Sie selten ein separates Gebäude. Stattdessen betreiben Sie eine zweite Kopie der Umgebung in einer anderen Region oder Availability Zone. Das AWS-Whitepaper zur Disaster Recovery beschreibt vier Strategien, von der günstigsten bis zur vollständigsten:
| AWS-Strategie | Was in der Wiederherstellungsregion läuft | Nächster Standorttyp |
|---|---|---|
| Backup and Restore | Nur Backups; die Infrastruktur wird nach dem Ereignis neu bereitgestellt | Cold Site |
| Pilot Light | Daten repliziert und Kerndienste an; Anwendungsserver abgeschaltet | Cold bis Warm |
| Warm Standby | Eine verkleinerte, aber voll funktionsfähige Kopie, die sofort Datenverkehr übernehmen kann | Warm Site |
| Hot Standby / Multi-Site Active/Active | Volle Kapazität, entweder wartend (Active/Passive) oder Nutzer bedienend (Active/Active) | Hot Site |
AWS bezeichnet Multi-Site Active/Active als den komplexesten und teuersten Ansatz, sagt aber, dass er die Wiederherstellungszeit bei den meisten Katastrophen nahe null bringen kann. Zudem weist AWS darauf hin, dass die meisten Kunden, die eine vollständige zweite Umgebung aufbauen, sie am Ende im Active/Active-Betrieb nutzen, da sie ohnehin dafür bezahlen.
Ein Cloud-Setup hat gegenüber einem physischen zwei Vorteile. Sie können den Failover testen, ohne Personal zu verlegen, und Sie können die gesamte Umgebung aus Code neu aufbauen, wenn etwas abweicht. Der Preis dafür: Sie zahlen die volle Kapazität an zwei Orten, zuzüglich Datentransfer für die Replikation.
Lohnt sich eine Hot Site?
Nur für Systeme, bei denen die Kosten eines Ausfalls höher sind als die Kosten für den Betrieb einer zweiten Umgebung. Gehen Sie von einer Business-Impact-Analyse aus, legen Sie für jedes System eine RTO und ein Recovery Point Objective (RPO) fest und ordnen Sie den Standorttyp diesen Zielen zu. Unser Leitfaden zu RPO und RTO zeigt, wie Sie sie festlegen.
NIST macht hier einen nützlichen Punkt: Ein System kann für verschiedene Funktionen unterschiedliche Strategien brauchen. Die Auftragsabwicklung kann einen sofortigen Failover erfordern, während der Monatsbericht auf derselben Plattform tagelang warten kann. Eine solche Stufung hält den dauerhaft aktiven Teil klein und die Rechnung beherrschbar.
Checkliste vor dem Aufbau
- Weit genug vom Primärstandort entfernt, damit ein regionales Ereignis nicht beide treffen kann.
- Kapazität für die kritische Last, nicht zwingend für alles.
- Replikationsverzögerung wird gegen Ihr RPO überwacht, mit Alarmen.
- Point-in-Time-Backups werden getrennt aufbewahrt, um sich von Korruption oder Ransomware zu erholen, die die Replikation mitkopieren würde.
- Sicherheitskontrollen auf Produktionsniveau: Identität, Firewalls, Logging und Verschlüsselung.
- Ein Failover-Runbook mit namentlich benannten Verantwortlichen und ein Failback-Plan.
- Regelmäßige Failover-Tests, dokumentiert in Ihrem Disaster-Recovery-Plan.
Wie Opsio unterstützt
Opsio entwirft und betreibt Cloud Disaster Recovery auf AWS, Azure und Google Cloud, von Pilot Light bis zu vollständigen Multi-Region-Setups, und testet den Failover gemeinsam mit Ihrem Team. Für WorkBuster, eine globale SaaS-Recruiting-Plattform, haben wir die AWS-Umgebung auf Multi-AZ MySQL RDS und Auto Scaling aufgebaut, mit CloudFormation-Vorlagen, damit sich die Infrastruktur konsistent neu bereitstellen lässt. Lesen Sie die WorkBuster-Fallstudie.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Hot Site und einer Cold Site?
Die erste hat Ausstattung, Software und aktuelle Daten bereit und kann schnell übernehmen. Die zweite bietet nur Fläche, Strom und Netzwerkanschlüsse, sodass Systeme installiert und aus dem Backup wiederhergestellt werden müssen, bevor die Arbeit weitergeht.
Wie schnell kann eine Hot Site den Betrieb übernehmen?
Typischerweise in Minuten bis Stunden, abhängig davon, wie aktuell die Daten sind und wie stark das Umschalten automatisiert ist. Ein Active/Active-Setup in der Cloud kann die Wiederherstellungszeit bei den meisten Ausfällen nahe null bringen, doch die Wiederherstellung nach Datenkorruption hängt weiterhin von Backups ab.
Ist eine Hot Site dasselbe wie eine Mirrored Site?
Sie liegen nah beieinander. Eine Mirrored Site betreibt eine identische, kontinuierlich synchronisierte Kopie der Produktion. Das NIST-Beispiel mit zwei identischen Produktivsystemen, die jeweils die volle Last tragen, ist praktisch eine Mirrored Site.
Brauche ich eine Hot Site, wenn ich in der Cloud arbeite?
Nicht automatisch. Der Betrieb über mehrere Availability Zones schützt bereits vor dem Verlust eines Rechenzentrums. Ein Hot Standby in einer zweiten Region lohnt sich, wenn regionale Ausfälle, Regulierung oder Verträge sehr kurze Wiederherstellungszeiten verlangen.
Was bedeutet „Hotsite“ im Marketing?
Im Marketing, besonders in Brasilien, ist eine „Hotsite“ eine kleine, befristete Website für eine Kampagne oder einen Produktstart. Mit Disaster Recovery hat sie nichts zu tun.
Verfasst von
Group COO & CISO
Fredrik ist Group COO und CISO bei Opsio. Er konzentriert sich auf operative Exzellenz, Governance und Informationssicherheit und arbeitet eng mit den Liefer- und Führungsteams zusammen, um Technologie, Risiko und Geschäftsergebnisse in komplexen IT-Umgebungen in Einklang zu bringen. Er leitet die Sicherheitspraxis von Opsio, einschließlich SOC-Services, Penetrationstests und Compliance-Frameworks.
Redaktionelle Standards: Dieser Artikel wurde von der oben genannten Cloud-Fachperson verfasst. Wir überarbeiten ihn, wenn sich die behandelte Technologie oder Regulierung ändert; die Daten auf dieser Seite zeigen die letzte Aktualisierung. Opsio ist redaktionell unabhängig.