Der Frozen Tier: selten abgefragte Daten kosteneffizient vorhalten

1. Das Storage-Tiering-Konzept und wo der Frozen Tier einordnet

Storage Tiering in Elasticsearch beruht auf der Beobachtung, dass Zugriffshäufigkeit und Datenalter meist eng zusammenhängen: Frische Daten werden häufig abgefragt, ältere Daten immer seltener, bis irgendwann nur noch gelegentliche, oft rein forensische oder regulatorische Abfragen übrig bleiben. Hot, Warm und Cold Tier unterscheiden sich dabei primär in der Hardware-Qualität, aber alle drei halten die vollständigen Daten weiterhin lokal auf Cluster-Knoten vor, lediglich mit unterschiedlicher Ressourcenausstattung.

Der Frozen Tier bricht mit diesem Muster: Er hält die Daten nicht mehr lokal vor, sondern lässt sie vollständig im Objekt-Speicher liegen und lädt bei Bedarf nur die für eine konkrete Abfrage tatsächlich benötigten Teile nach. Das ist ein qualitativer, kein rein quantitativer Unterschied zu den vorherigen Phasen, denn hier wird nicht mehr an der Hardware-Ausstattung, sondern am Speicherort selbst gespart, was ganz neue Kostenstrukturen ermöglicht.

2. Wie der Frozen Tier technisch funktioniert: partiell eingehängte Indizes

Technisch basiert der Frozen Tier auf sogenannten searchable Snapshots, die als partiell eingehängte Indizes im Cluster registriert werden. Anders als bei einem klassischen Index liegen die eigentlichen Segmentdaten nicht auf lokalem Speicher, sondern im Snapshot-Repository, meist einem S3-kompatiblen Objekt-Speicher. Der Cluster hält lediglich Metadaten sowie einen kleinen, gemeinsam genutzten Cache lokal vor, über den kürzlich abgefragte Datenblöcke zwischengespeichert werden.

Trifft eine Abfrage auf einen Frozen-Index, prüft der Cluster zunächst, ob die benötigten Datenblöcke bereits im lokalen Cache liegen. Ist das nicht der Fall, werden genau diese Blöcke, nicht der gesamte Index, aus dem Objekt-Speicher nachgeladen. Dieser gezielte, blockweise Zugriff unterscheidet den Frozen Tier grundlegend von einem klassischen Restore, bei dem stets der komplette Index vollständig zurückgeholt werden müsste, bevor überhaupt eine Abfrage möglich wäre.

3. Der Unterschied zum Cold Tier: Speicherort statt nur Replikaten-Reduktion

Der Cold Tier reduziert primär die Replikaten-Anzahl und verlagert Indizes auf günstigere, aber weiterhin lokal am Cluster hängende Hardware. Die Daten liegen dabei vollständig auf Cluster-Speicher, lediglich mit reduzierter Redundanz. Der Frozen Tier geht einen entscheidenden Schritt weiter: Hier liegen die Daten überhaupt nicht mehr dauerhaft auf Cluster-Speicher, sondern ausschließlich im Objekt-Speicher, wodurch der pro Index gebundene lokale Speicherplatz nahezu auf null sinkt.

Diese Unterscheidung hat direkte Konsequenzen für die Kapazitätsplanung: Ein Cluster mit Cold Tier muss weiterhin genug lokalen Speicher für alle Cold-Indizes vorhalten, wenn auch günstigeren, während ein Cluster mit Frozen Tier theoretisch Petabytes an Frozen-Daten referenzieren kann, ohne dass die lokale Speicherkapazität proportional mitwachsen muss. Der Preis dafür ist eine spürbar höhere Antwortzeit bei einem Cache-Miss, da die Daten dann erst aus dem Objekt-Speicher geholt werden müssen.

4. Der Latenz-Trade-off bei seltenen Abfragen

Der zentrale Kompromiss des Frozen Tier ist offensichtlich: Abfragen auf Frozen-Indizes dauern länger als auf Hot- oder Warm-Indizes, insbesondere bei einem Cache-Miss, wenn Daten frisch aus dem Objekt-Speicher geladen werden müssen. Während eine Abfrage auf einem Hot-Index typischerweise im niedrigen einstelligen Millisekundenbereich beantwortet wird, können Frozen-Abfragen bei kaltem Cache mehrere Sekunden benötigen, abhängig von der Netzwerklatenz zum Objekt-Speicher und der Menge der nachzuladenden Segmentdaten.

Dieser Trade-off ist aber genau dann akzeptabel, wenn er zum tatsächlichen Nutzungsmuster passt: Für Ad-hoc-Analysen, seltene forensische Abfragen oder regulatorisch geforderte, aber praktisch fast nie genutzte Archivdaten ist eine Antwortzeit von wenigen Sekunden meist völlig ausreichend. Kritisch wird es erst, wenn Frozen-Indizes fälschlich für zeitkritische, interaktive Dashboards genutzt werden, für die Nutzer eine sofortige Antwort erwarten.

5. Konfiguration: Searchable-Snapshot-Mount und Anforderungen an den Objekt-Speicher

Um einen Index in den Frozen Tier zu überführen, wird zunächst ein Snapshot des Index erstellt und anschließend über die Searchable-Snapshot-API im Frozen-Modus eingehängt. Dabei entfällt die Notwendigkeit, den vollständigen Index vorab lokal wiederherzustellen, der Mount-Vorgang selbst ist im Vergleich zu einem klassischen Restore deutlich schneller, da nur Metadaten gelesen werden müssen. Voraussetzung ist ein Objekt-Speicher-Repository mit ausreichender Bandbreite, denn ein zu langsames Repository macht sich bei jedem Cache-Miss unmittelbar in der Abfragezeit bemerkbar.

Zusätzlich benötigen die für den Frozen Tier vorgesehenen Knoten eine eigene, dedizierte Node-Rolle sowie einen konfigurierten shared cache, üblicherweise auf lokalem SSD-Speicher, dessen Größe direkt beeinflusst, wie viele der zuletzt abgefragten Datenblöcke ohne erneuten Zugriff auf den Objekt-Speicher beantwortet werden können. Ein zu klein dimensionierter Cache führt dazu, dass selbst wiederholte, ähnliche Abfragen ständig neu aus dem Objekt-Speicher geladen werden müssen.

POST _snapshot/s3-backup-repo/monthly-snap-2026.05/_mount
{
  "index": "logs-2026.05",
  "renamed_index": "frozen-logs-2026.05",
  "index_settings": {
    "index.number_of_replicas": 0
  }
}

6. Eignung in der Praxis: Archiv-Daten versus aktive Suche

Der Frozen Tier eignet sich hervorragend für Log-Archive, historische Compliance-Daten, alte Transaktionsprotokolle oder Analytics-Rohdaten, die zwar aus regulatorischen Gründen vorgehalten werden müssen, aber praktisch fast nie abgefragt werden. Auch für gelegentliche, aber sehr breite Auswertungen über mehrere Jahre hinweg, etwa einen Jahresvergleich im Rahmen einer Geschäftsanalyse, ist der Frozen Tier eine sinnvolle Wahl, da diese Abfragen selten genug sind, um die höhere Latenz zu verschmerzen.

Für die aktive Produktsuche eines Magento-Shops, für Nutzer-Sessions oder für jede Abfrage, bei der Endkunden auf eine schnelle Antwort warten, ist der Frozen Tier dagegen ungeeignet. Auch Aggregationen über sehr große Frozen-Datenmengen sollten mit Bedacht eingesetzt werden, da eine breite Aggregation potenziell sehr viele Segmentblöcke aus dem Objekt-Speicher nachladen muss und dadurch überproportional lange dauern kann, verglichen mit derselben Aggregation auf einem Hot-Index.

7. Kostenvergleich: Frozen Tier gegenüber Hot- und Warm-Speicher

Der Kostenunterschied zwischen Frozen Tier und den vorherigen Phasen ist erheblich, da Objekt-Speicher pro Gigabyte typischerweise nur einen Bruchteil dessen kostet, was performanter, an Cluster-Knoten gebundener Blockspeicher kostet. Zusätzlich lässt sich der lokale Speicherplatz für Frozen-Knoten drastisch reduzieren, da nur noch ein vergleichsweise kleiner, gemeinsam genutzter Cache statt vollständiger Indexkopien benötigt wird, was auch die Anzahl der überhaupt benötigten Frozen-Knoten senkt.

In der Praxis lohnt sich diese Rechnung besonders bei sehr großen Datenmengen mit langer Aufbewahrungsdauer, etwa mehrjährigen Log-Archiven, bei denen die absoluten Einsparungen schnell in signifikante Beträge übergehen. Bei kleineren Datenmengen relativiert sich der Vorteil dagegen, da der Betriebsaufwand für eine zusätzliche Tier-Stufe, inklusive eigenem Repository-Management und Cache-Dimensionierung, gegen die tatsächlich eingesparten Kosten abgewogen werden muss.

8. Praxisbeispiel: ILM-Richtlinie mit Frozen-Phase für ein Log-Archiv

Eine vollständige ILM-Richtlinie für ein Log-Archiv kombiniert alle vorgestellten Phasen konsequent: Hot für die aktiven, kürzlich geschriebenen Logs, Warm für kürzlich abgeschlossene, aber gelegentlich noch abgefragte Indizes, und schließlich Frozen für alles, was älter als etwa sechs Monate ist und praktisch nur noch bei Audits oder forensischen Untersuchungen benötigt wird. Die Delete-Phase greift dann erst nach mehreren Jahren, entsprechend der regulatorischen Aufbewahrungspflicht.

Diese Kombination senkt die Gesamtkosten der Log-Aufbewahrung erheblich, ohne die regulatorische Verfügbarkeit der Daten zu gefährden: Ein Audit-Team kann jederzeit auf einen sechs Jahre alten Log-Eintrag zugreifen, muss dafür lediglich eine Antwortzeit von wenigen Sekunden statt Millisekunden akzeptieren, was für diesen Anwendungsfall ein völlig vertretbarer Kompromiss ist.

"frozen": {
  "min_age": "180d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "s3-backup-repo"
    }
  }
}

9. Snapshot-Abhängigkeit: warum SLM-Retention Frozen-Indizes nicht treffen darf

Ein Frozen-Index ist technisch nur eine Sicht auf einen bestehenden Snapshot, keine eigenständige Kopie der Daten. Wird dieser zugrunde liegende Snapshot durch eine unabhängige SLM-Retention-Regel gelöscht, während der Frozen-Index noch aktiv darauf verweist, schlagen künftige Abfragen gegen diesen Index fehl, da die referenzierten Segmentdaten im Objekt-Speicher schlicht nicht mehr existieren. Diese Kopplung wird in der Praxis häufig übersehen, weil Snapshot-Verwaltung und Frozen-Tier-Konfiguration oft von unterschiedlichen Teams betreut werden.

Die saubere Lösung besteht darin, den ILM-eigenen Übergang in den Frozen Tier nicht mit einer separaten, generischen SLM-Sicherungsrichtlinie zu vermischen: ILM verwaltet den für den Frozen Tier erzeugten Snapshot selbst und entfernt ihn erst über die Aktion delete_searchable_snapshot in der Delete-Phase, zusammen mit dem gemounteten Index. Ein separates SLM-Repository ausschließlich für reguläre Sicherungen, getrennt vom Repository für Frozen-Snapshots, verhindert zuverlässig, dass eine falsch konfigurierte Retention-Regel versehentlich noch benötigte Frozen-Daten entfernt.

10. Zusammenfassung

11. FAQ: Frozen Tier in Elasticsearch: Das Wichtigste auf einen Blick