In den letzten Tagen wurden wir mit einer eigentlich banalen Frage konfrontiert: Wann ist ein Backup erfolgreich? Das Ergebnis ist ein Plädoyer für die Einfachheit und das KISS-Prinzip: Keep it small and simple!

Der Fall

Man sagt, ein Backup ist erfolgreich durchgeführt, wenn es wiederhergestellt werden kann und die wiederhergestellten Daten den Originaldaten entsprechen. Technisch ist das Backup damit erfolgreich durchgeführt. Hat man also ein laufendes System und von diesem ein solches Backup, so ist man auf der sicheren Seite, oder?

Leider verbirgt sich in dieser Aussage ein Pferdefuß: „Hat man also ein laufendes System“. Es wird nun etwas philosophisch: Wann „läuft ein System“? Betrachten wir unseren konkreten Fall, einen Windows Server 2008 R2 mit Exchange 2010 SP3. Dieses System war virtualisiert und lief in dem Sinne, dass es die erwarteten Aufgaben (Mailversand, Outlookzugriff etc.) erfüllte. Von diesem System gab es ein Backup in Form von Kopien der virtuellen Festplatten, also einem typischen Systemabbild. Da der Kunde keine Downtime für das Backup erlaubte, wurde das Backup per Snapshot durchgeführt und damit nicht nur die Platten, sondern auch der RAM-Inhalt und der Prozessorzustand etc. gesichert. Wird das Backup also „zurück gesichert“, steht direkt ein aktiv laufendes System bereit. Soweit, so gut.

Durch einen Schaden musste auf das Backup zurückgegriffen werden, was auch funktionierte. Das ja direkt laufende System wurde, um die letzten Dateiänderungen seit dem Snapshot einzuspielen, einmal runter gefahren und wieder hoch gefahren und lief auch. Beim zweiten Hochfahren jedoch weigerte sich Windows mit einem Bluescreen, zu starten. Wie sich herausstellte, reagierte Windows ebenso bei allen älteren Backups, bis zu 3 Wochen zurück.

Wir hatten also ein erfolgreiches Backup, aber offensichtlich ein Backup von einem, obwohl es lief, nicht lauffähigen System. Zwar gingen keine Daten verloren, aber das Windows-System und der Exchange musste neu aufgesetzt werden, was zu einer Unterbrechung der Verfügbarkeit führte.

Dem entsprechend war hier das Backup nicht als Schutz vor einem Hardwareschaden gefragt, sondern als Schutz vor einem Softwareschaden. Und hier stellt sich die Frage, wie ein solcher Softwareschaden gefunden werden kann. Im konkreten Fall hat ein einfacher Test, Hochfahren des Backupsystems und kurzer Funktionstest, nicht genügt. Erst beim zweiten Hochfahren trat der Fehler auf. Aber selbst wenn man die Tests beliebig ausführlicher macht und ein Backupsystem n-fach hochfährt und den Produktivbetrieb über viele Stunden simuliert – den Softwarefehler, der sich eingeschlichen hat und erst beim n+1ten Hochfahren auftritt, wird man nicht finden. Es bleibt immer ein Restrisiko.

Das für den Administrator einfache Fazit: Vor Softwareschäden schützt kein Backup. Und das Zwischenfazit für eine Unternehmensleitung: Ein Ausfallrisiko kann zwar – um den Preis hohen Aufwandes – minimiert werden, aber das u.U. erhebliche Restrisiko bleibt.

Die Lösung?

Doch wie kann sich ein Unternehmen vor einem solchen Fall schützen oder zumindest die Folgen klein, also die Ausfallzeiten kurz halten? Die Antwort auf diese Frage besteht aus zwei Teilen: 1. ist ein sicherer Schutz nicht möglich. 2. verwende man simple, unkomplizierte Systeme. Einfache Systeme sind schneller ausführlicher zu testen, sie können bei einem Ausfall schneller wieder aufgesetzt werden, ihre Schwächen sind leichter zu erkennen.

Im konkreten Fall war ein Exchange-Server im Einsatz, der jedoch nur für die E-Mail-Verwaltung genutzt wurde. Exchange speichert Mails in einer eigenen und für die Anwender nicht dokumentierten Datenbank, Exchange benötigt für die Benutzerverwaltung einen Active-Directory-Server etc. Der Exchange-Einsatz bedeutet also eine komplexe und vielfach miteinander verzahnte Infrastruktur.

Wenn es „nur“ um E-Mails geht, warum wird kein Linux-System mit z. B. Dovecot genutzt und die Mails als einzelne Dateien in Verzeichnissen abgelegt? Gerne können die Zugangsdaten mit einem Active-Directory synchronisiert werden, aber es ist sicherlich zur Vermeidung von Ausfällen besser, nicht online auf das AD zuzugreifen. Bei einem solch einfachen System besteht keine Gefahr eines Datenbancrashs, einzelne Dateien lassen sich problemlos sichern und zurück sichern, ein solches System ist in kurzer Zeit wieder aufgesetzt.

Dies ist nur ein Beispiel. Man beachte in der IT immer das KISS-Prinzip: Keep it small and simple! Gegebenenfalls geht etwas Komfort verloren – aber häufig ist dieser Komfortverlust harmlos gegenüber den Risiken, die man sich sonst einhandelt. Unternehmen müssen leider abwägen und sich entscheiden.

 

The frameworks vary according to the subject and the https://proessaywriting.org/ field you are into, and the type of case being considered must inform the one you choose.
Dr.-Ing. Martin H. Ludwig

Von Dr. Martin H. Ludwig

Dr. Martin H. Ludwig ist Geschäftsführer der ima GmbH, leidenschaftlicher IT-ler und Datenschutzexperte. Wenn er Zeit findet, schreibt er über IT-Probleme oder -Besonderheiten im Blog.

Schreibe einen Kommentar