Server-Backup richtig planen: Was wirklich zählt
Ein Server-Backup ist erst dann eines, wenn die Wiederherstellung schon einmal geklappt hat. Diesen Satz hört jeder Administrator irgendwann, meistens zu spät. In der Praxis scheitern Rücksicherungen selten daran, dass gar nicht gesichert wurde, sondern daran, dass die falschen Daten gesichert wurden, dass das Backup auf demselben System lag wie die Originale oder dass niemand wusste, wie lange eine Wiederherstellung dauert. Dieser Beitrag geht die Fragen durch, die ein belastbares Server-Backup beantworten muss, und zeigt, wo Standardlösungen enden.
Was muss ein Server-Backup überhaupt sichern?
Die erste Entscheidung ist der Umfang. Ein Dateibackup sichert Verzeichnisse, ein Image-Backup sichert das gesamte System einschließlich Betriebssystem und Konfiguration. Für einen Webserver reichen oft Webroot, Datenbank-Dumps und Konfigurationsdateien, weil sich das System selbst schnell neu aufsetzen lässt. Für einen Windows-Server mit Domänenrolle oder eine Branchenanwendung mit vielen Abhängigkeiten ist das Image die sicherere Wahl, weil eine Neuinstallation Tage kosten kann. Datenbanken brauchen in beiden Fällen eine eigene Behandlung: Wer laufende Datenbankdateien einfach kopiert, bekommt inkonsistente Stände. Ein Dump oder ein Snapshot im konsistenten Zustand gehört deshalb in jeden Backup-Plan, und zwar vor dem eigentlichen Sicherungslauf.
Wie oft und wie lange sollten Sie sichern?
Zwei Kennzahlen bestimmen Intervall und Aufbewahrung. Die erste ist der maximal tolerierbare Datenverlust: Wenn ein Shop hundert Bestellungen pro Stunde verarbeitet, ist ein tägliches Backup ein Verlustrisiko von bis zu 2.400 Bestellungen. Dann sind stündliche Sicherungen der Datenbank angemessen. Für einen Fileserver, auf dem ein Team tagsüber arbeitet, reicht oft ein Lauf am Abend. Die zweite Kennzahl ist die Aufbewahrung. Verschlüsselungstrojaner arbeiten oft wochenlang unbemerkt, bevor sie zuschlagen; ein Backup, das nur drei Tage zurückreicht, enthält dann bereits die verschlüsselten Dateien. Ein bewährtes Schema staffelt: tägliche Sicherungen für zwei Wochen, wöchentliche für zwei Monate, monatliche für ein Jahr. Was gesetzlich aufbewahrt werden muss, etwa Buchungsbelege oder geschäftliche E-Mails, gehört nicht ins Backup, sondern in ein Archiv. Das Backup ist für den Wiederanlauf da, nicht für die Betriebsprüfung.
Wo sollte das Backup liegen?
Die 3-2-1-Regel ist alt und trotzdem richtig: drei Kopien der Daten, auf zwei verschiedenen Medien, davon eine außer Haus. Für Server heißt das konkret: Die Originale auf dem Server, ein lokales Backup für schnelle Rücksicherungen einzelner Dateien und eine Kopie an einem anderen Standort für den Fall, dass der Server oder das ganze Rechenzentrum ausfällt. Die externe Kopie ist der Punkt, an dem die meisten Konzepte Lücken haben. Eine externe Festplatte, die am Server hängt, ist nicht außer Haus, und ein Backup auf derselben Hardware ist keines. Ein Cloud Backup in einem deutschen Rechenzentrum löst das mit einem Agenten auf dem Server, der die Daten verschlüsselt überträgt; bei webhostone werden die Sicherungen zusätzlich georedundant an einem zweiten deutschen Standort vorgehalten. Wichtig ist, dass der Schlüssel bei Ihnen liegt. Ein Backup, das der Anbieter entschlüsseln könnte, ist eine Kopie Ihrer Daten in fremder Hand.
Welche Rolle spielt das Backup des Hosters?
Viele gemietete Server bringen ein Backup des Anbieters mit, und es lohnt sich, das Kleingedruckte zu kennen. Beim Root Server von webhostone ist ein georedundantes Backup enthalten, die Rücksicherung liegt aber in Ihrer Verantwortung; Sie entscheiden, was wann zurückgespielt wird. Beim Managed Server übernimmt webhostone Sicherung und Wiederherstellung, was für Unternehmen ohne eigenen Administrator meist der entscheidende Unterschied ist. In beiden Fällen ersetzt das Hosterbackup nicht die eigene Strategie: Es schützt gegen Hardwareausfall und Bedienfehler, nicht gegen ein Schadprogramm, das seit Wochen im System sitzt, und nicht gegen die Notwendigkeit, einen Stand von vor drei Monaten zu rekonstruieren. Fragen Sie deshalb nach Intervall, Aufbewahrung und danach, ob die Wiederherstellung Geld kostet.
Wie prüfen Sie, ob die Wiederherstellung funktioniert?
Ein Wiederherstellungstest ist kein Aufwand, den man einmal im Jahr einplant, sondern ein fester Termin im Quartal. Spielen Sie ein Backup auf ein Testsystem zurück, stoppen Sie die Zeit und prüfen Sie, ob die Anwendung damit startet. Aus dieser Übung ergibt sich die zweite wichtige Kennzahl, die Wiederanlaufzeit. Wenn die Rücksicherung eines 500-GB-Servers aus der Cloud sechs Stunden dauert, müssen alle im Unternehmen wissen, dass ein Ausfall mindestens diesen halben Tag kostet, und die Geschäftsführung muss entscheiden, ob das akzeptabel ist. Dokumentieren Sie den Ablauf so, dass ihn auch jemand ausführen kann, der das System nicht eingerichtet hat. Für Windows-Umgebungen, die noch auf älteren Serverversionen laufen, ist dieser Test besonders dringlich, weil dort mit dem Windows Server ohnehin ein Wechsel ansteht und ein funktionierendes Backup die Grundlage jeder Migration ist.
