RDB vs. AOF: die richtige Wahl für den eigenen Anwendungsfall

1. Warum die Frage RDB vs. AOF keine Formsache ist

Die Entscheidung zwischen RDB vs. AOF wird in vielen Redis-Setups nie bewusst getroffen, sondern läuft mit den Standardeinstellungen der jeweiligen Distribution mit. Das ist riskant, weil beide Mechanismen fundamental unterschiedliche Garantien liefern: RDB sichert periodische Vollzustände in einer kompakten Datei, AOF protokolliert jede einzelne Schreiboperation und erlaubt damit ein viel engeres Verlustfenster. Wer nie explizit zwischen RDB vs. AOF abwägt, übernimmt implizit die Risikobereitschaft, die der Distributions-Maintainer für einen generischen Anwendungsfall für angemessen hielt, nicht die eigene.

Der Unterschied wird erst greifbar, wenn man sich konkrete Ausfallszenarien vorstellt: Ein Prozess-Crash durch OOM-Killer, ein Stromausfall im Rechenzentrum, ein versehentlicher Container-Neustart durch das Orchestrierungssystem. Bei jedem dieser Szenarien verhalten sich RDB und AOF unterschiedlich, sowohl was den Datenverlust als auch was die Zeit bis zur Wiederherstellung angeht. Diese beiden Größen, Verlustfenster und Recovery-Zeit, sind die eigentliche Entscheidungsgrundlage für RDB vs. AOF, nicht abstrakte Bestpractice-Empfehlungen.

Dieser Artikel stellt beide Mechanismen direkt gegenüber, zeigt, wie man sie kombiniert einsetzt, und liefert konkrete Kriterien für Cache-Szenarien einerseits und Durable-Store-Szenarien andererseits. Die technischen Details zu RDB-Snapshots und AOF-Persistence im Einzelnen finden sich in den beiden vorangegangenen Artikeln dieser Reihe.

2. Grundmechanik im direkten Vergleich

RDB arbeitet nach dem Prinzip Point-in-Time-Snapshot: Zu konfigurierbaren Zeitpunkten, gesteuert über save-Direktiven, forkt Redis einen Kindprozess, der den kompletten Speicherinhalt als Binärdatei schreibt. Zwischen zwei Snapshots existiert keine Protokollierung einzelner Operationen, der Zustand zwischen den Snapshots ist bei einem Absturz schlicht verloren. AOF hingegen arbeitet nach dem Write-Ahead-Log-Prinzip: Jedes Schreibkommando wird, abhängig von der appendfsync-Einstellung, nahezu unmittelbar in eine kontinuierlich wachsende Datei geschrieben.

Diese unterschiedliche Grundmechanik hat direkte Folgen für die Dateigröße: Eine RDB-Datei ist immer proportional zur Größe des tatsächlichen Datenbestands, unabhängig davon, wie viele Schreiboperationen dazwischen stattfanden. Eine AOF-Datei ohne regelmäßigen Rewrite kann dagegen erheblich größer werden als der eigentliche Datenbestand, wenn derselbe Key häufig überschrieben wird, weil jede einzelne Operation protokolliert bleibt, bis ein BGREWRITEAOF die Historie kompaktiert.

3. Recovery-Zeit: was passiert beim Neustart wirklich

Beim Neustart mit ausschließlich RDB liest Redis die Binärdatei sequenziell ein und baut die internen Datenstrukturen direkt aus den serialisierten Werten auf. Dieser Prozess skaliert nahezu linear mit der Dateigröße und ist unabhängig davon, wie viele Schreiboperationen ursprünglich zum Datenbestand geführt haben. Ein RDB-Snapshot mit 10 GB lädt in einer vorhersagbaren, messbaren Zeit, typischerweise im Bereich weniger Sekunden bis niedriger einstelliger Minuten, abhängig von Disk-Geschwindigkeit und Datentypen.

Bei AOF muss Redis hingegen jedes einzelne protokollierte Kommando erneut ausführen, als würde ein Client sie nacheinander senden. Bei einer frisch kompaktierten AOF-Datei mit aktueller Basis-Datei ist das kaum langsamer als RDB, weil die Basis-Datei im RDB-Format vorliegt und nur die kleine Inkrement-Datei tatsächlich Kommando für Kommando abgespielt wird. Ohne regelmäßigen Rewrite kann die Recovery-Zeit jedoch deutlich steigen, weil Millionen einzelner Kommandos statt eines kompakten Snapshots verarbeitet werden müssen.

In der Praxis bedeutet das: Die Recovery-Zeit bei AOF hängt direkt von der Rewrite-Disziplin ab. Ein gut konfiguriertes auto-aof-rewrite-percentage mit regelmäßigen Rewrites hält die Inkrement-Dateien klein und die Recovery-Zeit nah an der von RDB. Wird der Rewrite vernachlässigt, etwa weil auto-aof-rewrite-percentage zu hoch gesetzt ist, wächst die Recovery-Zeit spürbar, gerade bei Datensätzen mit hoher Schreibrate auf denselben Keys.

# Compare startup time with RDB-only vs AOF-heavy configuration
time redis-server --dbfilename dump.rdb --appendonly no --daemonize no &
sleep 5 && redis-cli SHUTDOWN NOSAVE

time redis-server --appendonly yes --appenddirname appendonlydir --daemonize no &
sleep 5 && redis-cli SHUTDOWN NOSAVE

# Check AOF file sizes to estimate replay cost
du -sh /var/lib/redis/appendonlydir/*.incr.aof
du -sh /var/lib/redis/appendonlydir/*.base.rdb

4. Datenverlust-Fenster realistisch einschätzen

Ein pauschaler Vergleich der Verlustfenster täuscht oft über die tatsächliche Risikoexposition hinweg. Bei RDB mit save 60 10000 als aggressivstem konfiguriertem save-Punkt kann im Worst Case fast eine Minute an Schreiboperationen verloren gehen, sofern innerhalb dieser Minute weniger als 10.000 Änderungen stattfanden und kein früherer save-Punkt zutraf. Bei sehr hoher, konstanter Schreiblast greift dieser Punkt jedoch häufiger, was das effektive Verlustfenster in der Praxis reduziert.

Bei AOF mit appendfsync everysec bleibt das Verlustfenster konstant bei maximal einer Sekunde, unabhängig von der Schreibrate, weil der Hintergrund-Thread unabhängig von der Anzahl der Operationen fest einmal pro Sekunde synchronisiert. Das macht AOF-Verlustfenster deutlich vorhersagbarer als RDB-Verlustfenster, die von der tatsächlichen Schreibrate zum Zeitpunkt des Absturzes abhängen und daher stärker schwanken.

Für eine belastbare Risikobewertung sollte man das Verlustfenster nicht nur in Zeit, sondern in geschäftlicher Auswirkung denken: Ein Verlust von 60 Sekunden Session-Daten bedeutet meist nur, dass einige Nutzer sich erneut anmelden müssen. Ein Verlust von 60 Sekunden Bestelldaten in einem Checkout-Flow bedeutet potenziell verlorene Umsätze und inkonsistente Zustände zwischen Redis und nachgelagerten Systemen wie einer relationalen Datenbank.

# Compare the effective loss window of both mechanisms via INFO
redis-cli INFO persistence | grep -E "rdb_changes_since_last_save|rdb_last_save_time|aof_last_write_status"
# rdb_changes_since_last_save:8421   -> unsaved writes since last RDB snapshot
# rdb_last_save_time:1721739600
# aof_last_write_status:ok           -> AOF write path healthy

# Estimate the RDB loss window in seconds right now
echo "$(( $(date +%s) - $(redis-cli LASTSAVE) )) seconds since last RDB snapshot"

5. Ressourcenbedarf: Speicher, CPU und Disk-I/O

RDB belastet Ressourcen stoßweise: Während eines BGSAVE steigt der Speicherbedarf durch Copy-on-Write kurzzeitig an, und die CPU wird durch den Fork sowie optional durch LZF-Kompression belastet. Außerhalb dieser Fenster verursacht RDB praktisch keine laufende Last. AOF hingegen belastet Ressourcen kontinuierlich: Jeder Schreibvorgang erzeugt einen zusätzlichen write()-Syscall, und je nach appendfsync-Einstellung kommt ein regelmäßiger oder sogar permanenter fsync()-Overhead hinzu.

Disk-I/O ist bei AOF strukturell höher als bei reinem RDB, weil kontinuierlich geschrieben wird, statt nur zu bestimmten Zeitpunkten. Auf Systemen mit begrenztem I/O-Budget, etwa Cloud-Instanzen mit gedrosselten IOPS, kann dieser Dauerbelastungs-Charakter von AOF stärker ins Gewicht fallen als die stoßweise, aber intensivere Last von RDB. Bei der Kapazitätsplanung sollte man daher nicht nur die Spitzenlast eines BGSAVE, sondern auch die kontinuierliche I/O-Grundlast von AOF einkalkulieren, wenn beide Mechanismen parallel aktiv sind.

Ein praktischer Weg, den tatsächlichen Ressourcenunterschied sichtbar zu machen, ist eine kurze Beobachtung mit Systemwerkzeugen während einer typischen Lastphase. Erhöhte %iowait-Werte während kontinuierlicher AOF-Schreibvorgänge, verglichen mit kurzen, intensiven I/O-Spitzen während eines BGSAVE, zeigen sehr deutlich die unterschiedliche Ressourcen-Charakteristik beider Mechanismen.

# Observe disk I/O characteristics: continuous AOF vs bursty RDB
iostat -x 2 10 | grep -E "Device|sda"
# %util spikes briefly during BGSAVE, stays elevated continuously
# with appendfsync always under sustained write load

# Compare memory growth during a BGSAVE (copy-on-write effect)
watch -n 1 'redis-cli INFO memory | grep -E "used_memory_human|mem_fragmentation_ratio"'

6. Beide zusammen: Mixed Persistence richtig konfigurieren

Die meisten produktiven Redis-Setups aktivieren nicht RDB oder AOF exklusiv, sondern beide gemeinsam, oft als Mixed Persistence oder Hybrid Persistence bezeichnet. Dabei übernimmt AOF die primäre Durability mit engem Verlustfenster, während RDB zusätzlich für schnelle, portable Backups sorgt, etwa um sie einfach auf einen anderen Server zu kopieren oder für Replikations-Bootstrapping zu nutzen. Ein zusätzlicher Vorteil: Seit Redis 4 kann die Basis-Datei eines AOF-Rewrites selbst im RDB-Format vorliegen, sodass der Kompaktierungsschritt von der ohnehin vorhandenen RDB-Serialisierung profitiert.

Bei aktivierter Mixed Persistence lädt Redis beim Start bevorzugt die AOF-Daten, sofern appendonly yes gesetzt ist, weil sie das engere Verlustfenster garantieren. Die RDB-Datei dient in diesem Setup primär als Backup-Artefakt und Replikations-Basis, nicht als primäre Recovery-Quelle. Diese Kombination liefert praktisch das Beste aus beiden Welten: die enge Durability-Garantie von AOF für den Normalbetrieb und die kompakte, portable RDB-Datei für Backup- und Migrations-Szenarien.

# redis.conf - Mixed persistence: RDB + AOF together

# AOF as the primary durability mechanism
appendonly yes
appendfsync everysec

# RDB save points still active for portable backups
save 900 1
save 300 10

# AOF rewrite uses RDB format for the base file (default since Redis 4)
aof-use-rdb-preamble yes

# On startup, AOF takes precedence over RDB if both are present
# (this is Redis's built-in default behavior, not a separate directive)

7. Cache-only-Szenarien: wann Persistenz kaum eine Rolle spielt

Für reine Cache-Anwendungsfälle, bei denen Redis stets aus einer Quelle wie einer relationalen Datenbank oder einem externen Service befüllt werden kann, ist die Persistenz-Entscheidung deutlich entspannter. Hier zählt primär, wie teuer ein Cache-Miss nach einem Neustart ist, nicht ob Daten verloren gehen können, denn ein Verlust bedeutet lediglich, dass der Cache erneut befüllt werden muss. In solchen Szenarien reicht häufig RDB mit moderaten save-Punkten oder sogar komplett deaktivierte Persistenz.

Wichtig ist hier die Unterscheidung zwischen kaltem und warmem Neustart: Ohne jede Persistenz startet Redis komplett leer, was bei großen Cache-Größen zu einem spürbaren Thundering-Herd-Effekt auf das Backend-System führen kann, weil plötzlich alle Anfragen als Cache-Miss bei der Datenquelle landen. Ein RDB-Snapshot, auch mit moderatem Verlustfenster, mildert dieses Problem erheblich, weil der Cache nach einem Neustart größtenteils warm bleibt, statt komplett neu aufgebaut werden zu müssen.

8. Durable-Store-Szenarien: wann AOF Pflicht ist

Sobald Redis nicht mehr nur Cache, sondern primäre oder alleinige Datenquelle für einen Geschäftsprozess ist, etwa bei Warteschlangen für asynchrone Jobs, Rate-Limiting-Zählern mit Abrechnungsrelevanz oder Session-Stores, deren Verlust Nutzer aus laufenden Checkout-Prozessen wirft, wird AOF mit appendfsync everysec praktisch zur Pflicht. Das enge Verlustfenster von maximal einer Sekunde reduziert das Risiko inkonsistenter Zustände zwischen Redis und angeschlossenen Systemen erheblich.

Für Anwendungsfälle mit noch strikteren Anforderungen, etwa Finanztransaktionen oder gesetzlich vorgeschriebener Nachvollziehbarkeit, kann sogar appendfsync always gerechtfertigt sein, trotz des spürbaren Latenz-Overheads. In solchen Fällen lohnt sich häufig eine Architekturentscheidung, kritische Schreibpfade über dedizierte Redis-Instanzen mit always zu leiten, während weniger kritische Workloads auf separaten Instanzen mit everysec laufen, um nicht die gesamte Latenz-Charakteristik des Systems auf den strengsten Anwendungsfall auszurichten.

9. Entscheidungshilfe für den eigenen Anwendungsfall

Die Entscheidung RDB vs. AOF lässt sich anhand von drei Fragen strukturieren: Erstens, wie teuer ist der Verlust der letzten Sekunden bis Minuten an Schreiboperationen für das Geschäft? Zweitens, wie kritisch ist eine schnelle Recovery-Zeit nach einem Neustart, etwa im Rahmen eines Service-Level-Agreements? Drittens, wie viel zusätzlicher Ressourcenbedarf durch kontinuierliches AOF-Schreiben ist im aktuellen Infrastruktur-Budget vertretbar?

Als Faustregel gilt: Reine Caches mit günstiger Backend-Quelle kommen mit RDB allein oder sogar ganz ohne Persistenz aus. Alles, wo Redis primäre Datenquelle ist, sollte AOF mit mindestens everysec nutzen. Und praktisch jedes produktive Setup profitiert von Mixed Persistence, weil die RDB-Komponente zusätzliche Backup- und Migrations-Flexibilität liefert, ohne die Durability-Garantie von AOF zu beeinträchtigen.

#!/usr/bin/env bash
# persistence_decision_check.sh - Quick decision-support snapshot
set -euo pipefail

echo "--- Current persistence configuration ---"
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET save

echo "--- Current risk exposure ---"
redis-cli INFO persistence | grep -E \
  "rdb_changes_since_last_save|aof_enabled|aof_last_bgrewrite_status"

# Decision rule of thumb:
#   Pure cache, cheap backend refill -> RDB only is usually fine
#   Redis as primary data source     -> AOF with at least everysec
#   Most production setups           -> RDB + AOF together (mixed)

10. Zusammenfassung

Die Frage RDB vs. AOF hat keine universelle Antwort, sondern hängt vom Verlustfenster, der geforderten Recovery-Zeit und dem verfügbaren Ressourcenbudget ab. RDB liefert kompakte, schnell ladbare Snapshots mit einem Verlustfenster im Minutenbereich und stoßweiser Ressourcenbelastung. AOF liefert ein Verlustfenster von maximal einer Sekunde bei kontinuierlicher, aber gut kontrollierbarer Ressourcenbelastung. Für die meisten produktiven Setups ist die Kombination aus beiden, Mixed Persistence, die robusteste Wahl.

Cache-only-Szenarien mit günstiger Backend-Quelle kommen meist mit RDB allein aus. Durable-Store-Szenarien, in denen Redis primäre Datenquelle ist, sollten AOF mit mindestens everysec nutzen. Die Entscheidung RDB vs. AOF sollte immer explizit getroffen und dokumentiert werden, statt implizit den Distributions-Standardwerten zu folgen.

11. FAQ: RDB vs. AOF