Disaster Recovery Für Kleine Softwareteams

Disaster Recovery ist in einem kleinen Team meistens eine einzige Zeile in einem Dokument, das nie jemand geöffnet hat: Backups sind aktiviert. Diese Aussage stimmt, und sie ist trotzdem keine Antwort, denn sie sagt nichts darüber, wie alt die Daten im Ernstfall wären, wie lange das Zurückspielen dauert oder ob überhaupt jemals jemand eines durchgeführt hat.

Zwischen Backups haben und wiederherstellen können liegt genau die Lücke, in der aus den meisten Ausfällen echte Vorfälle werden. Ein Backup, das existiert, aktuell ist und nie zurückgespielt wurde, ist eine Hypothese, und der Moment, in dem Sie sie prüfen, ist ein denkbar schlechter Moment für die Erkenntnis, dass sie falsch war.

Zwei Zahlen machen aus einer Meinung einen Plan. Wie viele Daten können Sie sich leisten zu verlieren, und wie lange können Sie sich einen Stillstand leisten? Das sind Ihr Recovery Point Objective und Ihr Recovery Time Objective. Solange niemand auf der Geschäftsseite sie ausspricht, ist jede technische Diskussion über die Backup-Frequenz unentscheidbar, weil schlicht das Kriterium fehlt, gegen das man argumentieren könnte.

RPO und RTO in einfachen Worten

Recovery Point Objective, kurz RPO, beschreibt, wie viele Daten Sie verlieren dürfen. Nächtliche Backups bedeuten ein RPO von 24 Stunden: Ein Ausfall um 17 Uhr kostet alles seit der vorigen Nacht. Wenn das inakzeptabel ist, dann ist der Backup-Zeitplan falsch, und keine noch so große Sorgfalt an anderer Stelle gleicht das wieder aus.

Recovery Time Objective, kurz RTO, beschreibt, wie lange Sie stillstehen dürfen. Darin steckt alles: bemerken, entscheiden, bereitstellen, zurückspielen, verifizieren und den Traffic wieder umschalten. Teams schätzen den Schritt des Zurückspielens und vergessen die anderen fünf, und genau deshalb dauern echte Wiederherstellungen ein Mehrfaches der erwarteten Zeit.

Beides sind kaufmännische und keine technischen Entscheidungen, und beides kostet Geld, je enger die Vorgabe wird. Ein RPO von fünf Minuten verlangt kontinuierliche Replikation. Ein RTO von einer Stunde verlangt eine Infrastruktur, die sich automatisch neu aufbauen lässt, denn unter Druck konfiguriert niemand innerhalb einer Stunde einen Server von Hand.

Das produktive Gespräch dreht sich um die Abwägung. Sagen Sie der Geschäftsseite, was jede Stufe kostet, und lassen Sie sie wählen, statt in der Technik eine Zahl zu setzen und zu hoffen, dass sie zu Erwartungen passt, die nie jemand ausgesprochen hat.

Ein ungetestetes Backup ist kein Backup

Die Ausfälle, die wirklich wehtun, sind selten die ohne Backup. Es sind die Backups, die sich im entscheidenden Moment als unbrauchbar herausstellen.

Häufige Ursachen, die alle erst beim Zurückspielen sichtbar werden: Der Job scheitert seit Wochen lautlos, weil niemand den Erfolg genauso überwacht wie den Fehler. Der Dump hat das Schema erfasst, aber nicht die Daten, oder eine Teilmenge von Tabellen, die jemand einmal auf eine Ausschlussliste gesetzt hat. Die Datei ist mit einem Schlüssel verschlüsselt, der auf der Maschine lag, die gestorben ist. Das Backup liegt im selben Konto oder in derselben Region wie das, was es schützen soll.

Der letzte Punkt wiegt schwerer als noch vor einigen Jahren. Ein Backup in derselben Umgebung wie die Produktion ist gegen Hardwareausfall geschützt und gegen sonst nichts. Es übersteht keine Kontoübernahme, kein versehentliches Löschen auf Kontoebene und keine Ransomware, die alles erreicht, was dieselben Zugangsdaten erreichen.

Die einzige Möglichkeit zu wissen, dass ein Backup funktioniert, ist, es zurückzuspielen. Planen Sie das fest ein, tun Sie es mindestens quartalsweise, und stoppen Sie dabei die Zeit. Diese gemessene Zeit ist Ihr echtes RTO, im Unterschied zu dem, das im Dokument steht.

Was Disaster Recovery abdecken muss

Die Daten sind der offensichtliche Teil und selten der langsame. Was Wiederherstellungen in die Länge zieht, sind meistens genau die Dinge, die niemand aufgelistet hat.

Die Datenbank, an die alle denken. Hochgeladene Dateien, die irgendwo separat liegen und oft überhaupt kein Backup haben. Konfiguration und Secrets, die häufig nur auf der laufenden Maschine existieren. DNS und Zertifikate, die sich nicht schnell neu erzeugen lassen, wenn genau das Konto verloren ist, in dem sie liegen. Die Infrastruktur selbst, also Server, Netze und Regeln, die schnell wieder aufgebaut ist, wenn sie als Code definiert wurde, und quälend langsam, wenn sie zusammengeklickt wurde.

Und das Wissen darüber, wie alles zusammenhängt, das in einem kleinen Team der mit Abstand größte Einzelfaktor für die Wiederherstellungszeit ist. Ein System, das eine einzelne Person aus dem Kopf wieder aufbauen kann, hat eine Wiederherstellungszeit, die der Verfügbarkeit dieser Person entspricht, und das ist kein Plan.

Schreiben Sie die Inventarliste vor dem Plan. Die meisten Teams entdecken beim Erstellen dieser Liste mindestens eine Komponente, für die es gar kein Backup gibt, und dieser Weg der Entdeckung ist erheblich günstiger als die Alternative.

Ein Plan, der auf eine Seite passt

Lange Dokumente werden während eines Vorfalls nicht gelesen. Zielen Sie auf etwas, dem eine müde Person um drei Uhr nachts folgen kann, ohne nachdenken zu müssen.

Enthalten sein muss: wer entscheidet, dass die Wiederherstellung begonnen hat, denn das Zögern bei der Frage, ob das hier schon ein Notfall ist, ist eine der häufigsten Quellen von Verzögerung. Wo die Backups liegen und wie man an sie herankommt, samt Zugangsdaten, die nicht vom ausgefallenen System abhängen. Die Schritte des Zurückspielens in der richtigen Reihenfolge, konkret genug, um ohne Improvisation zu funktionieren. Wie man prüft, dass es geklappt hat, also eine belastbare Kontrolle statt des Eindrucks, dass die Seite lädt. Und wen man informiert, intern wie extern.

Bewahren Sie ihn an einem Ort auf, der den Ausfall übersteht. Ein Wiederherstellungsplan, der nur in dem System liegt, das er wiederherstellen soll, ist ein wiederkehrender und vollständig vermeidbarer Fehler.

Dieselbe Logik gilt für Zugänge. Wenn eine einzige Person die Zugangsdaten für das Hosting-Konto hält, ist Ihre Wiederherstellungszeit davon begrenzt, ob diese Person ans Telefon geht. Unser Leitfaden zum Härten von Linux-Servern behandelt die Zugriffskontrollen, auf denen das alles beruht.

Angemessen statt perfekt

Ein kleines Team braucht kein Hot Standby in einer zweiten Region. Die Kosten sind real, und die zusätzliche Komplexität bringt eigene Fehlerquellen mit.

Was die meisten kleinen Teams brauchen, ist deutlich billiger: Backups in einem separaten Konto mit Zugangsdaten, die die Produktion nicht nutzen kann, eine Wiederherstellung, die planmäßig getestet und dabei gestoppt wird, eine als Code definierte Infrastruktur, die sich ohne Archäologie neu erzeugen lässt, und ein einseitiger Plan, den tatsächlich jemand gelesen hat.

Dieses Paket deckt Hardwareausfall, versehentliches Löschen, Kontoübernahme und Ransomware ab, also das meiste von dem, was tatsächlich passiert. Alles darüber hinaus ist eine Entscheidung darüber, wie viel eine weitere Verkürzung der Ausfallzeit wert ist, und das ist eine Frage für die Geschäftsseite und nicht für die Technik.

Mecanik prüft und baut genau das im Rahmen unserer Server-Sicherheitsanalyse . Die erste Frage ist dabei immer dieselbe, und sie hat nichts mit Technologie zu tun: Wie lange können Sie stillstehen, und wer hat das entschieden?

Siehe auch: Uptime-SLAs, die wirklich etwas bedeuten , Software-Lieferkettensicherheit für kleine Teams , KI-Agenten im Unternehmen: Kosten und Fallstricke und Fintech-Softwareentwicklung UK: FCA, Rails und Kosten .

Häufig gestellte Fragen

Was bedeuten RPO und RTO? Das Recovery Point Objective ist die Datenmenge, deren Verlust Sie sich leisten können, weshalb nächtliche Backups ein RPO von 24 Stunden bedeuten. Das Recovery Time Objective ist die Zeit, die Sie stillstehen können, einschließlich Bemerken, Entscheiden, Bereitstellen, Zurückspielen, Verifizieren und Umschalten des Traffics. Beides sind kaufmännische Entscheidungen, und beides kostet mehr, je enger die Vorgabe wird.

Warum ist ein ungetestetes Backup kein Backup? Weil die Fehlerbilder erst beim Zurückspielen sichtbar werden. Jobs scheitern wochenlang lautlos, wenn niemand den Erfolg ebenso überwacht wie den Fehler, Dumps erfassen das Schema ohne die Daten oder lassen ausgeschlossene Tabellen weg, Schlüssel liegen auf der Maschine, die gestorben ist, und Kopien liegen im selben Konto wie das, was sie schützen sollen. Spielen Sie quartalsweise zurück und stoppen Sie die Zeit.

Wo sollten Backups liegen? In einem separaten Konto oder einer separaten Region, mit Zugangsdaten, die die Produktion nicht nutzen kann. Ein Backup in derselben Umgebung schützt gegen Hardwareausfall und gegen sonst nichts: Es übersteht keine Kontoübernahme, kein Löschen auf Kontoebene und keine Ransomware, die alles erreicht, was dieselben Zugangsdaten erreichen.

Was wird bei Disaster Recovery am häufigsten vergessen? Hochgeladene Dateien, die getrennt von der Datenbank liegen, Konfiguration und Secrets, die nur auf der laufenden Maschine existieren, DNS und Zertifikate in einem Konto, das selbst verloren gehen kann, zusammengeklickte statt als Code definierte Infrastruktur und das Wissen über die Zusammenhänge, wenn es nur eine einzige Person hat.

Braucht ein kleines Team ein Hot Standby? Meistens nicht. Die Kosten sind real, und die zusätzliche Komplexität bringt eigene Fehlerquellen mit. Backups in einem separaten Konto, eine getestete und gestoppte Wiederherstellung, eine als Code definierte Infrastruktur und ein einseitiger Plan, den jemand gelesen hat, decken Hardwareausfall, versehentliches Löschen, Kontoübernahme und Ransomware ab, also das meiste von dem, was passiert.