Ein Backup fühlt sich wie reine Vorsorge an: je mehr, desto sicherer. Doch jede Sicherung kostet Speicher, und Speicher ist Hardware plus Dauerstrom. Ein vollständiges Tagesabbild einer großen Website, ein Jahr lang aufbewahrt, ist ein Berg fast identischer Daten, der rund um die Uhr Energie zieht – für einen Ernstfall, der meist nie eintritt. Nachhaltige Datensicherung stellt deshalb eine unbequeme Frage: Was muss überhaupt gesichert werden, und wie sparsam geht das?
Das Erfolgskriterium von Guideline 4.8 (meine Übersetzung des Originals):
Datensicherungen: Stelle sicher, dass Sicherungen von Systemen und Nutzerdaten sicher und inkrementell sind, um den Speicherbedarf zu minimieren und die Sicherungszeit zu verkürzen. Beschränke den Zugriff auf Backups und richte Mechanismen ein, die verhindern, dass personenbeziehbare Informationen dauerhaft gespeichert werden. Schütze Backups vor Datenverlust und Missbrauch.
Meine Einordnung
Das entscheidende Wort im Kriterium ist „inkrementell". Ein Backup soll nur die Änderungen speichern, nicht jedes Mal alles neu. Genau hier zeigt sich, dass eine statische Website die Sache erstaunlich elegant löst – wenn man weiß, was überhaupt schützenswert ist.
Denn das meiste, was auf dem Server liegt, ist wiederherstellbarer Abfall. Das erzeugte HTML und die beim Build konvertierten WebP-Bilder muss ich nicht sichern: Ich kann die komplette Seite in wenigen Minuten aus der Quelle neu erzeugen. Kritisch sind nur die Ausgangsdaten – die Markdown-Inhalte, das Theme, die Konfiguration. Und die liegen bei mir in Git.
Git ist von Haus aus ein inkrementelles Backup. Jeder Commit speichert nur die Differenz zum vorherigen Stand, und jede Kopie eines Repositories enthält die vollständige Historie. Bei mir liegt die Quelle in Repositories auf zwei getrennten Rechnern plus dem Bare-Repo auf dem Server – mehrere unabhängige, jeweils komplette Kopien auf unterschiedlichen Geräten. Darüber legt mein Hoster rollierende Tagessicherungen der letzten 14 Tage. Die bewährte 3-2-1-Regel (drei Kopien, zwei Medien, eine außer Haus) erfülle ich damit, ohne eine einzige zusätzliche Backup-Routine zu bauen. Das Werkzeug, mit dem ich ohnehin arbeite, ist zugleich meine Sicherung.
Wo ich weiter gehe
Mein Grundsatz hier lautet: Sichere nur, was sich nicht leicht neu erzeugen lässt. Ein generiertes Artefakt gehört nicht ins Backup – es gehört in den Build-Prozess. Und selbst beim Schützenswerten schlägt Inkrementell jedes Vollabbild. Doch es gibt eine zweite Ebene, die beim Thema Backup fast immer übersehen wird.
Das trifft genau die Datensparsamkeit, für die ich ohnehin plädiere. Wer Analytics-Daten oder Newsletter-Adressen sichert, muss deren Löschfristen bis in die Backups durchdenken. Eine rollierende Aufbewahrung wie meine 14 Tage ist hier übrigens ein Vorteil: Gelöschtes verschwindet von selbst wieder, statt sich unbegrenzt anzuhäufen.
Dein erster Schritt heute
Du brauchst kein neues Werkzeug, nur eine ehrliche Zählung.
Das nachhaltigste Backup sichert genau das, was sich nicht wiederherstellen lässt – und vergisst bewusst alles, was der nächste Build ohnehin neu erzeugt.
Quellen: W3C-Fassung von Guideline 4.8 · Interpretation bei Sustainable Web Design