Eine funktionierende Backup-Aufbewahrungsrichtlinie für Websites
Veröffentlicht am 14. August 2026
Eine Backup-Aufbewahrungsrichtlinie für Websites sollte Ihnen mehrere aktuelle Wiederherstellungspunkte, einige ältere Wiederherstellungsoptionen und mindestens eine Kopie außerhalb des Servers bieten, auf dem die Website läuft. Wenn ein Plugin-Update um 10:15 Uhr den Checkout beschädigt, brauchen Sie eine saubere Version von 10:00 Uhr, nicht ein Backup vom letzten Dienstag und einen hoffnungsvollen Gesichtsausdruck.
Der richtige Zeitplan hängt davon ab, wie oft sich Ihre Daten ändern, wie viel Ausfallzeit kostet und wie schnell Ihr Team erkennen kann, wann ein Problem begonnen hat. Eine statische Unternehmenswebsite und ein stark frequentierter WooCommerce-Shop sollten nicht auf dieselbe Weise geschützt werden. Der Dienst mag online sein, aber wenn die Bestellungen, Formulareinsendungen oder Kundenänderungen von gestern fehlen, ist noch nicht wieder vollständig Ruhe eingekehrt.
Was eine Backup-Aufbewahrungsrichtlinie für Websites abdecken muss
Aufbewahrung ist nicht einfach nur die Anzahl der Backups, die Sie behalten. Sie ist die Gesamtheit der Regeln, die festlegt, welche Backup-Kopien verfügbar bleiben, wo sie gespeichert werden, wie lange sie dort verbleiben und wann sie gelöscht werden.
Eine nützliche Richtlinie berücksichtigt drei getrennte Wiederherstellungsanforderungen. Erstens benötigen Sie eine schnelle operative Wiederherstellung für aktuelle Fehler: ein fehlerhaftes Deployment, gelöschte Dateien, ein fehlgeschlagenes Update oder eine versehentliche Konfigurationsänderung. Zweitens benötigen Sie eine historische Wiederherstellung, wenn ein Problem wochenlang unbemerkt bestanden hat, etwa kompromittierter Admin-Zugriff oder infizierter Code. Drittens benötigen Sie möglicherweise Aufzeichnungen, die aus geschäftlichen, vertraglichen oder regulatorischen Gründen aufbewahrt werden müssen.
Diese Ziele können miteinander in Konflikt geraten. Jedes Backup für immer aufzubewahren verursacht Speicherkosten, langsamere Backup-Jobs und eine verwirrende Wiederherstellungsliste. Zu wenig aufzubewahren spart Platz – genau bis zu dem Moment, in dem das eine Backup, das Sie brauchen, bereits abgelaufen ist. Die sinnvolle Antwort ist eine gestufte Aufbewahrung, nicht eine lange Reihe identischer täglicher Backups.
Beginnen Sie mit Wiederherstellungszielen, nicht mit einer Speicherzahl
Bevor Sie Aufbewahrungszeiträume festlegen, definieren Sie zwei praktische Zielgrößen: Recovery Point Objective und Recovery Time Objective.
Ihr Recovery Point Objective, oft RPO genannt, beantwortet die Frage, wie viele aktuelle Daten Sie sich leisten können zu verlieren. Ein E-Commerce-Shop, der den ganzen Tag über Bestellungen verarbeitet, benötigt möglicherweise stündliche Datenbank-Backups oder transaktionsbewusste Backups. Eine Broschüren-Website, die zweimal im Monat aktualisiert wird, kann möglicherweise ein tägliches Backup akzeptieren, sofern kritische Kontaktformulardaten anderweitig verarbeitet werden.
Ihr Recovery Time Objective oder RTO beantwortet die Frage, wie schnell die Website wiederhergestellt sein muss. Ein aktuelles Backup, das lokal oder in einem nahegelegenen Backup-Speicher gespeichert ist, kann in der Regel schneller wiederhergestellt werden als ein Kaltarchiv. Aber lokale Kopien allein reichen nicht aus. Ein Serverausfall, ein Ransomware-Vorfall, ein fehlerhafter Datenträgervorgang oder eine Kompromittierung auf Kontoebene kann die Website und ihre lokalen Backups gleichzeitig betreffen.
Für die meisten Unternehmenswebsites sollten Sie diese Zielwerte in klarer Sprache definieren. Zum Beispiel: „Wir können höchstens eine Stunde an Bestellungen verlieren, und der Storefront muss innerhalb von zwei Stunden wiederhergestellt sein.“ Das ist weitaus nützlicher, als zu sagen „wir machen täglich Backups“ und später festzustellen, dass täglich nur einmal alle 24 Stunden bedeutet.
Prüfen Sie, was sich tatsächlich ändert
Website-Dateien und Datenbankdaten ändern sich nicht mit derselben Geschwindigkeit. WordPress-Core-Dateien können monatelang unverändert bleiben, während die Datenbank den ganzen Tag über Bestellungen, Kommentare, Buchungen, Mitgliedschaftsänderungen und Formulareinträge erhält.
Ein vollständiges Backup sollte Anwendungsdateien, Datenbanken, Konfigurationsdateien, hochgeladene Medien, SSL-bezogene Konfiguration, sofern relevant, Definitionen geplanter Aufgaben und alle benutzerdefinierten Anwendungsdaten umfassen, die außerhalb des Web-Roots gespeichert sind. Wenn ein Datenbank-Backup erfolgreich ist, aber das Upload-Verzeichnis ausgeschlossen wird, funktioniert die wiederhergestellte Website möglicherweise, während Produktbilder oder Kundendokumente still und leise verschwinden.
Bei einer größeren Anwendung sollten Sie auch Abhängigkeiten dokumentieren. Objektspeicher, Mail-Dienste, Zahlungssysteme, externe Datenbanken und DNS-Einträge gehören möglicherweise nicht in ein Server-Backup. Sie gehören dennoch in den Wiederherstellungsplan.
Ein praktischer Aufbewahrungsplan für die meisten Websites
Ein häufiger Ausgangspunkt ist es, häufige Backups für einen kurzen Zeitraum und weniger häufige Backups für längere Zeit aufzubewahren. Das bietet nützliche Wiederherstellungsoptionen, ohne dass der Speicherverbrauch wie eine verlassene Garage anwächst.
Für eine typische Website eines kleinen Unternehmens, eine von einer Agentur verwaltete Website oder eine Marketing-Website sollten tägliche Backups 14 bis 30 Tage, wöchentliche Backups 8 bis 12 Wochen und monatliche Backups 6 bis 12 Monate aufbewahrt werden. Erstellen Sie ein zusätzliches Backup vor größeren Änderungen wie einem CMS-Upgrade, dem Start eines Redesigns, einer Migration, dem Austausch eines Plugins oder Arbeiten an der Serverkonfiguration.
Für Shops, SaaS-Dashboards, Mitgliederseiten, Buchungsplattformen und andere datenbanklastige Dienste sollten Sie häufigeren Datenbankschutz hinzufügen. Stündliche Datenbank-Backups, die 24 bis 72 Stunden aufbewahrt werden, können angemessen sein, gefolgt von täglichen Backups für 30 Tage, wöchentlichen Backups für 12 Wochen und monatlichen Backups für 12 Monate. Das genaue Intervall hängt vom Transaktionsvolumen und davon ab, ob die Anwendung aktive Daten zuverlässig sichern kann.
Agenturen sollten klientenspezifische Richtlinien erwägen, anstatt einen Zeitplan auf jedes Konto anzuwenden. Eine Website für Restaurantmenüs braucht nicht dieselbe Aufbewahrung wie ein Kundenportal, das hochgeladene Dokumente verarbeitet. Gruppieren Sie Websites nach Risiko und geschäftlichen Auswirkungen und machen Sie die Richtlinie dann in der Kundenvereinbarung oder im Leistungsumfang sichtbar.
Bewahren Sie Wiederherstellungspunkte vor Änderungen getrennt auf
Automatisierte Zeitpläne sind kein Ersatz für bewusste Backups vor riskanten Arbeiten. Erstellen Sie einen gekennzeichneten Wiederherstellungspunkt vor Updates, Migrationen, Datenbankwartung, Template-Änderungen oder Anpassungen auf Serverebene.
Bewahren Sie Backups vor Änderungen nach Abschluss der Arbeiten mindestens sieben bis vierzehn Tage lang auf. Einige Probleme treten erst nach einem Abrechnungszyklus, einem Hintergrundjob oder wenn eine Integration läuft auf. Sobald die Änderung als stabil bestätigt ist, kann die normale Aufbewahrung übernehmen.
Befolgen Sie das 3-2-1-Prinzip mit realistischen Betriebsabläufen
Das klassische 3-2-1-Modell bleibt praxisnah: Bewahren Sie drei Datenkopien auf, auf zwei verschiedenen Speichertypen, wobei eine Kopie außerhalb des Standorts liegt. Für den Betrieb von Websites bedeutet das oft die Produktionsdaten, eine Backup-Kopie in der Hosting-Umgebung und eine verschlüsselte Kopie in einem unabhängigen Offsite-Speicher.
Das Schlüsselwort ist unabhängig. Ein Backup, das auf demselben virtuellen Server gespeichert ist, ist bequem, aber kein Schutz vor einem Ausfall auf Serverebene. Ein Backup, das im selben Hosting-Konto gespeichert ist, kann ebenfalls gefährdet sein, wenn ein Angreifer Zugangsdaten für das Konto erhält oder eine umfassende Löschaktion durchgeführt wird.
Offsite-Kopien sollten bei der Übertragung und im Ruhezustand verschlüsselt sein. Der Zugriff sollte, wo möglich, separate Zugangsdaten verwenden, idealerweise mit Multi-Faktor-Authentifizierung und eingeschränkten Berechtigungen. Berechtigungen zum Löschen von Backups verdienen besondere Aufmerksamkeit. Wenn Ransomware oder ein kompromittierter Administrator Produktionsdaten und jeden Wiederherstellungspunkt in einer einzigen Sitzung löschen kann, sieht der Aufbewahrungsplan auf dem Papier hervorragend aus und ist in der Praxis hilflos.
Bei kodu.cloud können verwaltete Backup- und Monitoring-Regelungen die Routinearbeit verringern, aber die Verantwortung für die Wiederherstellungsanforderungen sollte dennoch klar sein. Ihr Anbieter kann das System warten; Ihr Unternehmen sollte entscheiden, wie viel Datenverlust und Ausfallzeit es akzeptieren kann.
Machen Sie die Aufbewahrung sicherheitsbewusst
Ein kurzes Aufbewahrungsfenster kann gefährlich sein, wenn Malware spät entdeckt wird. Eine Website kann mehrere Wochen kompromittiert sein, bevor verdächtige Weiterleitungen, Spam-Aktivitäten oder nicht autorisierte Admin-Konten sichtbar werden. Wenn jedes Backup nach sieben Tagen überschrieben wird, behalten Sie möglicherweise nur infizierte Kopien.
Deshalb sind wöchentliche und monatliche Wiederherstellungspunkte wichtig. Für Umgebungen mit höherem Risiko sollten Sie unveränderliche oder schreibgeschützte Backup-Kopien für einen definierten Zeitraum in Betracht ziehen. Unveränderlichkeit macht ein Backup nicht auf magische Weise korrekt, aber sie kann verhindern, dass ein Angreifer es nach einer Kompromittierung verändert oder löscht.
Führen Sie Protokoll über Backup-Erfolg, Fehler, Löschung und Wiederherstellungsaktivität. Warnmeldungen sollten eine Person erreichen, die handeln kann, nicht ein Postfach, das zu einem kleinen digitalen Museum geworden ist. Das Monitoring sollte auch die Speicherkapazität, die Backup-Dauer und ungewöhnliche Änderungen der Backup-Größe prüfen. Ein plötzlich winziges Backup kann auf eine ausgeschlossene Datenbank oder eine fehlgeschlagene Dateisammlung hinweisen; ein plötzlich riesiges kann auf Protokolle, Cache-Dateien oder unerwünschte Daten hindeuten, die in den Backup-Satz gelangen.
Testen Sie Wiederherstellungen, bevor Sie eine brauchen
Ein Backup ist erst dann ein Wiederherstellungswerkzeug, wenn es erfolgreich wiederhergestellt wurde. Der Status eines Backup-Jobs bestätigt, dass Daten kopiert wurden. Er beweist nicht, dass das Archiv vollständig, lesbar, mit der aktuellen Umgebung kompatibel oder unter Zeitdruck nutzbar ist.
Testen Sie eine Wiederherstellung mindestens vierteljährlich für eine normale Unternehmenswebsite und häufiger für umsatzkritische Anwendungen. Stellen Sie in einer Staging-Umgebung oder an einem isolierten Ort wieder her, an dem die Produktion nicht überschrieben werden kann. Bestätigen Sie, dass die Anwendung startet, die Datenbank eine Verbindung herstellt, Mediendateien geladen werden, Formulare funktionieren, geplante Aufgaben vorhanden sind und kritische Benutzeraktionen sich normal verhalten.
Halten Sie fest, wie lange die Wiederherstellung gedauert hat und welche manuellen Schritte erforderlich waren. Wenn die Wiederherstellung davon abhängt, dass sich ein Entwickler an ein Datenbankpasswort, eine DNS-Abfolge und einen fünf Jahre alten Shell-Befehl erinnert, ist das kein Plan. Das ist ein Folklore-Artefakt.
Dokumentieren Sie Ausnahmen und überprüfen Sie die Richtlinie
Ihre Aufbewahrungsrichtlinie sollte auf eine Seite passen und ein paar direkte Fragen beantworten: Was wird gesichert, wie oft, wo Kopien gespeichert werden, wie lange jede Kopie aufbewahrt wird, wer eine Wiederherstellung anfordern kann und wie Wiederherstellungstests dokumentiert werden. Benennen Sie auch Systeme, die nicht enthalten sind, damit niemand annimmt, ein Backup decke einen Drittanbieterdienst ab, auf den es nicht zugreifen kann.
Überprüfen Sie die Richtlinie nach einer größeren Website-Änderung, einer neuen Compliance-Anforderung, steigendem Traffic oder einem Wiederherstellungsvorfall. Häufigere Backups können notwendig werden, wenn ein Online-Shop wächst. Andererseits kann das Speichern täglicher Backups über mehrere Jahre hinweg für eine Website mit wenigen Änderungen Kosten verursachen, ohne nützlichen Schutz zu bieten.
Richten Sie die Aufbewahrungsrichtlinie auf den Moment aus, in dem Sie sie am dringendsten brauchen: ein überhastetes Freitag-Deployment, ein bösartiges Plugin-Update oder ein Festplattenproblem zur falschen Stunde. Klare Wiederherstellungspunkte, eine unabhängige Kopie und ein getesteter Prozess geben Ihrem Team etwas Besseres als Zuversicht. Sie geben Ihnen einen praktikablen nächsten Schritt.
Andres Saar Customer Care Engineer