Disaster Recovery

Kategorie: Allgemein
Erstellt: 10.03.2021

Was ist ein Disaster Recovery Plan?

Ein Disaster Recovery Plan ist die konkrete Vorbereitung auf den Fall, von dem man hofft dass er nie eintitt. Wenn er aber doch eintreten sollte, dann ist man zumindest bestmöglich darauf vorbereitet (genügend andere Probleme hat man dann ohnehin schon).

Wie der Plan genau aussieht lässt sich nicht pauschal sagen, das hängt von den individuellen Risiken ab. Im Folgenden fokussieren wir uns daher auf typische Hosting- und Web-Anwendungen, und geben einen Einblick in unseren eigenen Disaster Recovery Plan.

Erstellung eines Disaster Recovery Plans

1. Identifikation der “Wertgegenstände” (Assets)

Erstellen Sie eine Liste der Assets, welche für den Betrieb Ihrer Dienste zwingend erforderlich sind. Überlegen Sie dabei, für welche Leistung Ihre Kunden Geld bezahlen, und wie lange ein Ausfall tolerierbar wäre. Dabei geht es nicht nur um physische Gegenstände (z.B. Server) sondern auch um Dienstleistungen, externe Dienste oder Daten.

Denken Sie nicht nur an direkte, sondern auch an indirekte Abhängigkeiten. Wie lange könnten Sie z.B. Ihr Geschäft weiter betreiben wenn Sie aus technischen Gründen eine Zeit lang keine Zahlungen empfangen könnten?

Diese Liste sortieren Sie anschließend nach Priorität - meist also nach der tolerierbaren Ausfalldauer.

2. Identifikation der Standorte / Lieferanten

Für jeden Punkt der Liste erfassen Sie dann den Standort bzw. den Lieferanten. Das macht es einfacher, beim Ausfall eines Standortes oder Lieferanten den Überblick zu behalten, wie weit Sie davon betroffen sind.

3. Ausfall-Szenarien skizzieren

Nun entwerfen Sie für alle Punkte die schlimmsten Szenarien. Dabei gilt: think big. Rechnen Sie nicht mit einzelnen Serverausfällen, sondern mit einem kompletten Standort- oder Lieferantenausfall:

• Großereignis: direkt (Brand/Explosion/…) und indirekt (das benachbarte Chemiewerk/Atomkraftwerk/… brennt)
• Insolvenz: ein Lieferant wird zahlungsunfähig, alle Leistungen werden sofort eingestellt
• Beschlagnahmung: es wird gegen einen Kunden ermittelt, dabei werden alle Systeme beschlagnahmt

Die Fälle sind ohne Frage dramatisch. Es geht aber nicht darum, wie wahrscheinlich diese sind, sondern dass sie prinzipiell möglich sind.

4. Maßnahmen entwickeln

Das ist der wichtigste Punkt: mit welchen vorbereitenden Maßnahmen könnte man sich von den einzelnen möglichen Vorfällen schnell erholen? Um Prävention geht es nur nebensächlich: jedes Rechenzentrum verfügt über eine Brandschutzanlage, aber abbrennen kann es dennoch.

Denken Sie auch an die Praxis. In vielen Fällen haftet der Provider nicht für die Daten seiner Kunden (alleine schon weil die Kosten für die IT-Haftpflichtversicherung sonst ins Unermessliche steigt) - aber würden im Falle eines Datenverlusts tatsächlich alle Kunden ihre Wordpress-Websites einfach neu hochladen können, oder wäre das Risiko größer dass diese kündigen und den Anbieter wechseln?

Konkrete Empfehlungen

Off-Site Backup

Es ist immer empfehlenswert, die geschäftskritischsten Daten an einem separaten Ort gesichert aufzubewahren. Dabei gilt:

• die Daten müssen sicher sein (um Himmels Willen keine unverschlüsselten Backups auf externe Festplatten!)
• das Backup muss automatisiert sein
• das Backup muss überwacht werden

Denken Sie dabei an die Dokumentationspflichten gemäß DSGVO, u.a.: wo werden die Daten gespeichert/aufbewahrt, wer hat Zugriff darauf, wie wird sichergestellt dass Daten auch aus Backups gelöscht werden?

Infrastruktur-Dokumentation

Zu jedem System muss dokumentiert sein, wie dies konfiguriert ist bzw. welche Anforderungen an die Infrastruktur zu beachten sind. Je nach Anwendungsfall lässt sich das auch automatisieren (Ansible/Chef/Puppet/Saltstack).

Produkte entwickeln

An irgendeinem Punkt stellt sich auch die Frage, wer die Kosten für den Mehraufwand (z.B. Off-Site-Backup, Standby-Systeme, etc.) tragen soll.

Kalkuliert man dies in die eigenen Preise ein, dann darf man das auch ruhig entsprechend bewerben. Alternativ kann man separate Produkte entwickeln (z.B. Off-Site-Backup, Managed Server mit gespiegelten Standby-Servern, georedundante Storage, …) und als Add-Ons gegen Aufpreis vertreiben.

Disaster Recovery bei uns

Wir nutzen On-Site-Backups (also am selben Standort) um große Datenmengen bei einem möglichen Hardware-Ausfall schnell wiederherstellen zu können. Zusätzliche Off-Site-Backups werden automatisiert an einen externen Standort gesichert.

Für die Backups selbst setzen wir u.a. Borg ein. Die Backups sind selbstverständlich alle verschlüsselt, der Zugriff auf die Backupserver ist zudem nur mit Zwei-Faktor-Authentifizierung möglich.

Die Sicherungsintervalle sind dabei unterschiedlich: das Backup der Entwicklungsumgebung und Codeverwaltung hat ganz andere Anforderungen als das der Testserver.

Ein Monitoring (Nagios/Icinga) überwacht das Alter der Backups und warnt, wenn etwas nicht geklappt hat.

Last but not least versuchen wir regelmäßig ein komplettes Disaster Recovery “durchzuspielen”, d.h. ein zufällig ausgewähltes System muss spontan ausschließlich aus dem Backup wiederhergestellt werden.