{"id":981,"date":"2015-12-05T12:50:13","date_gmt":"2015-12-05T11:50:13","guid":{"rendered":"http:\/\/blog.imagmbh.de\/?p=981"},"modified":"2020-06-11T20:52:53","modified_gmt":"2020-06-11T19:52:53","slug":"wann-ist-ein-backup-erfolgreich","status":"publish","type":"post","link":"https:\/\/blog.imagmbh.de\/index.php\/wann-ist-ein-backup-erfolgreich\/","title":{"rendered":"Wann ist ein Backup erfolgreich?"},"content":{"rendered":"

In den letzten Tagen wurden wir mit einer eigentlich banalen Frage konfrontiert: Wann ist ein Backup erfolgreich? Das Ergebnis ist ein Pl\u00e4doyer f\u00fcr die Einfachheit und das KISS-Prinzip: Keep it small and simple!<\/a><\/p>\n

Der Fall<\/h2>\n

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

Leider verbirgt sich in dieser Aussage ein Pferdefu\u00df: „Hat man also ein laufendes System“. Es wird nun etwas philosophisch: Wann „l\u00e4uft 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\u00fcllte. Von diesem System gab es ein Backup in Form von Kopien der virtuellen Festplatten, also einem typischen Systemabbild. Da der Kunde keine Downtime f\u00fcr das Backup erlaubte, wurde das Backup per Snapshot durchgef\u00fchrt und damit nicht nur die Platten, sondern auch der RAM-Inhalt und der Prozessorzustand etc. gesichert. Wird das Backup also „zur\u00fcck gesichert“, steht direkt ein aktiv laufendes System bereit. Soweit, so gut.<\/p>\n

Durch einen Schaden musste auf das Backup zur\u00fcckgegriffen werden, was auch funktionierte. Das ja direkt laufende System wurde, um die letzten Datei\u00e4nderungen seit dem Snapshot einzuspielen, einmal runter gefahren und wieder hoch gefahren und lief auch. Beim zweiten Hochfahren<\/strong> jedoch weigerte sich Windows mit einem Bluescreen, zu starten. Wie sich herausstellte, reagierte Windows ebenso bei allen \u00e4lteren Backups, bis zu 3 Wochen zur\u00fcck.<\/p>\n

Wir hatten also ein erfolgreiches Backup, aber offensichtlich ein Backup von einem, obwohl es lief, nicht lauff\u00e4higen System. Zwar gingen keine Daten verloren, aber das Windows-System und der Exchange musste neu aufgesetzt werden, was zu einer Unterbrechung der Verf\u00fcgbarkeit f\u00fchrte.<\/p>\n

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\u00fcgt. Erst beim zweiten Hochfahren trat der Fehler auf. Aber selbst wenn man die Tests beliebig ausf\u00fchrlicher macht und ein Backupsystem n-fach hochf\u00e4hrt und den Produktivbetrieb \u00fcber 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.<\/p>\n

Das f\u00fcr den Administrator einfache Fazit: Vor Softwaresch\u00e4den sch\u00fctzt kein Backup. Und das Zwischenfazit f\u00fcr eine Unternehmensleitung: Ein Ausfallrisiko kann zwar – um den Preis hohen Aufwandes – minimiert werden, aber das u.U. erhebliche Restrisiko bleibt.<\/p>\n

Die L\u00f6sung?<\/h2>\n

Doch wie kann sich ein Unternehmen vor einem solchen Fall sch\u00fctzen 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\u00f6glich. 2. verwende man simple, unkomplizierte Systeme. Einfache Systeme sind schneller ausf\u00fchrlicher zu testen, sie k\u00f6nnen bei einem Ausfall schneller wieder aufgesetzt werden, ihre Schw\u00e4chen sind leichter zu erkennen.<\/p>\n

Im konkreten Fall war ein Exchange-Server im Einsatz, der jedoch nur f\u00fcr die E-Mail-Verwaltung genutzt wurde. Exchange speichert Mails in einer eigenen und f\u00fcr die Anwender nicht dokumentierten Datenbank, Exchange ben\u00f6tigt f\u00fcr die Benutzerverwaltung einen Active-Directory-Server etc. Der Exchange-Einsatz bedeutet also eine komplexe und vielfach miteinander verzahnte Infrastruktur.<\/p>\n

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\u00f6nnen die Zugangsdaten mit einem Active-Directory synchronisiert werden, aber es ist sicherlich zur Vermeidung von Ausf\u00e4llen 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\u00fcck sichern, ein solches System ist in kurzer Zeit wieder aufgesetzt.<\/p>\n

Dies ist nur ein Beispiel. Man beachte in der IT immer das KISS-Prinzip: Keep it small and simple!<\/a> Gegebenenfalls geht etwas Komfort verloren – aber h\u00e4ufig ist dieser Komfortverlust harmlos gegen\u00fcber den Risiken, die man sich sonst einhandelt. Unternehmen m\u00fcssen leider abw\u00e4gen und sich entscheiden.<\/p>\n

 
\n