In fast jedem Projekt, in das ich schaue, existiert ein Löschprozess für Daten. Er heißt „irgendwann mal“. Der Grund ist ökonomisch nachvollziehbar: Ein Terabyte Speicher kostet monatlich einen niedrigen zweistelligen Eurobetrag, das Nachdenken über Aufbewahrungsfristen kostet Arbeitszeit. Speichern ist billiger als Entscheiden. Die Folge ist ein Datenbestand, von dem Schätzungen zufolge weit über die Hälfte nie wieder gelesen wird. Diese „Dark Data“ verursacht trotzdem Last: Sie belegt Platten, die produziert werden mussten, sie wird bei jedem Backup mitkopiert, sie wandert bei jeder Migration mit um. Und bei Speichermedien entfällt ein erheblicher Teil der Lebenszyklus-Emissionen nicht auf den Betrieb, sondern auf die Herstellung. Eine SSD, die halb leer laufen könnte, aber voll ist, wurde umsonst gebaut.
Die fünf Erfolgskriterien von Guideline 4.12
Ungenutzte Daten entfernen: Entferne regelmäßig ungenutzte oder veraltete Daten (sogenannte Dark Data), um Speicher- und Energiekosten zu senken, und steuere bewusst, ob und wie lange Daten überhaupt gespeichert werden.
Lebenszyklus-Management: Nutze Klassifizierungs- und Tagging-Richtlinien, um Regeln für den Datenlebenszyklus festzulegen und zu verwalten, einschließlich Aufbewahrung, Ablauf und Archivierung. Richte die Wahl des Speichers daran aus, wie häufig auf die Daten zugegriffen wird, und verlagere seltener genutzte Daten auf energieeffizientere Speicher.
Effiziente Speicherung: Speichere Daten nur dort, wo sie dauerhaften betrieblichen, analytischen oder rechtlichen Wert haben und sich nicht einfach neu erzeugen oder ersetzen lassen. Entferne oder archiviere sie, sobald sie veraltet sind. Vermeide unnötige Dopplungen und nutze effiziente Speicherpraktiken wie Komprimierung, Caching und Speicheroptimierung.
Optimiertes Logging: Verwalte Logdateien mit regelmäßiger Rotation, klaren Aufbewahrungsfristen, Komprimierung und Backup-Praktiken. Lege ressourcenintensive Vorgänge nach Möglichkeit in Zeiten geringer Aktivität, um Energiebedarf und Betriebsaufwand zu senken. Nutze widerstandsfähige Backup-Strategien einschließlich externer Speicherung, wo sie für Ausfallsicherheit oder Wiederherstellung nötig ist, und entferne sensible Informationen aus Logdateien, wo immer das möglich ist, um Sicherheits- und Datenschutzrisiken zu minimieren. Setze Logs, Monitoring und Alerts in einer Frequenz und einem Umfang ein, die Nutzen bringen, ohne unnötige Verarbeitung, Speicherung und Netzwerkübertragung zu verursachen. Nutze die erhobenen Daten, um vermeidbaren Ressourcenverbrauch zu erkennen und zu reduzieren, etwa unnötige automatisierte Anfragen.
Asset-Downloads: Mache große, dauerhaft genutzte Dateien einfach herunterladbar, damit Nutzende dafür nicht wiederholt Anfragen an den Server stellen müssen.
Meine Einordnung
Die Guideline klingt abstrakt, betrifft aber lauter sehr konkrete Bestände. Nutzerkonten und Logins, von denen sich viele seit Jahren nicht mehr angemeldet haben. Newsletter-Abonnenten, die seit vierzig Ausgaben nichts geöffnet haben. Mailkorrespondenz, die vollständig auf dem Server liegt, weil niemand je aufgeräumt hat. Server-Logfiles, die unbegrenzt mitlaufen. Und die Rohdaten von Analytics-Werkzeugen wie Google Analytics oder Matomo.
Rechne das am Newsletter durch, das Beispiel ist besonders anschaulich. Eine Ausgabe mit 100 KB an 10.000 Empfänger sind 1 GB pro Versand. Wenn 20 Prozent der Adressen inaktiv sind, verschickst Du bei zwölf Ausgaben im Jahr rund 2,4 GB an Menschen, die nicht lesen. Dazu kommt die dauerhafte Speicherung dieser Adressen samt Öffnungs- und Klickhistorie. Eine Liste zu bereinigen senkt also nicht nur die Übertragung, sondern auch den gespeicherten Bestand und die Zustellraten gleich mit.
Bei Logfiles ist der Effekt schleichender. Eine typische Zeile im Access-Log wiegt ein paar hundert Byte. Bei einer Million Anfragen im Monat sind das grob 250 MB, unkomprimiert und dauerhaft, wenn niemand rotiert. Nach drei Jahren liegen einige Gigabyte auf der Platte, die niemand je ausgewertet hat.
Beim Logging ist ein Gedanke hinzugekommen, der die Richtung umdreht. Bisher galt das Logfile als Kostenstelle: Es wächst, es muss rotiert, komprimiert und irgendwann gelöscht werden. Jetzt verlangt das Kriterium zusätzlich, die erhobenen Daten zu nutzen, um vermeidbaren Verbrauch zu erkennen, ausdrücklich auch unnötige automatisierte Anfragen. Damit wird das Log vom Ballast zum Messinstrument. Ich nutze meine Server-Logs genau so: Sie zeigen mir, welche Bots welche Last erzeugen, und sie zeigen mir, wie oft eine Fallback-Datei überhaupt noch abgerufen wird. Beides sind Zahlen, die ich nirgendwo sonst bekomme. Wer seine Logs nur aufbewahrt, zahlt für Speicher. Wer sie liest, bekommt eine Einsparung dafür zurück.
Am meisten Substanz steckt aber im dritten Kriterium: speichern nur, wo sich Daten nicht einfach neu erzeugen lassen. Das ist ein Prüfkriterium, das ich in der Praxis kaum jemanden anwenden sehe. Generierte Thumbnails, Cache-Dateien, abgeleitete Exporte, Zwischenstände: alles reproduzierbar, alles trotzdem gesichert und archiviert.
Wo ich weiter gehe
Die WSG denken beim Löschen an Speicherplatz. Ich denke zusätzlich an Haftung. Datenhygiene ist der Punkt, an dem Klimaschutz und Datenschutz dieselbe Maßnahme verlangen. Die DSGVO kennt mit Datenminimierung und Speicherbegrenzung genau die beiden Prinzipien, die hier als Nachhaltigkeitskriterien auftauchen. Wer Rohdaten seiner Analytics zwei Jahre vorhält, hat nicht nur Speicher belegt, sondern auch ein Risiko konserviert. Das erklärt, warum die aktuelle W3C-Fassung beim Logging ausdrücklich verlangt, sensible Informationen zu entfernen. Diesen Satz gab es in der älteren Interpretation so nicht.
Neu ist außerdem die Aufforderung, die Wahl des Speichers an der Zugriffshäufigkeit auszurichten und selten genutzte Daten auf energieeffizientere Medien zu verlagern. Das ist vernünftig und trotzdem nur die zweitbeste Frage. Kalter Speicher ist sparsamer als warmer, aber er ist nicht umsonst: Die Platte wurde produziert, sie wird gesichert, sie zieht bei jeder Migration mit um. Speicherklassen sind Effizienz. Nicht zu speichern ist Suffizienz, und nur die zweite Größe kann null werden.
Und es gibt einen blinden Fleck, über den fast alle stolpern.
Konsequent weitergedacht führt das zur Frage vor der Frage: Muss dieser Datenpunkt überhaupt entstehen? Ein Analytics-Werkzeug, das nur aggregierte Berichte behält statt jeder einzelnen Sitzung, erzeugt weniger Bestand, den Du später verwalten, schützen und löschen musst. In meinem Buch steht die Datenhygiene nicht ohne Grund im Kapitel 3.9 zwischen den technischen Optimierungen. Sie ist eine.
Dein erster Schritt heute
Du brauchst keine Datenstrategie. Du brauchst drei Fristen.
Danach trage Dir einen jährlichen Termin ein, an dem Du prüfst, ob die Fristen noch passen. Aufräumen, das nicht im Kalender steht, findet nicht statt.
Daten, die Du nie gespeichert hast, musst Du weder sichern noch schützen noch löschen.
Quelle: W3C-Fassung von Guideline 4.12