2026 Redis 8.0: Was tun bei fehlgeschlagener AOF-Neuschreibung? Zuerst Datenträger und Wiederherstellungskette prüfen

Die AOF-Neuschreibung schlägt fehl, das Datenverzeichnis meldet wenig freien Speicher oder Sie wissen nicht, ob eine Kopie vollständig ist.

Geeignet: Prüfen Sie zuerst Redis-Persistenzstatus, Dateisystem und zusammengehörige AOF-Dateien; testen Sie die Wiederherstellung anschließend isoliert. Nicht geeignet: Löschen Sie nicht vorschnell AOF-Dateien und starten Sie Redis nicht blind neu. Redis 8.0 erreicht sein Supportende am 01.12.2026; prüfen Sie deshalb auch Ihren Wartungsplan, ohne ein Upgrade mit einer Datensicherung zu verwechseln. Redis führt das Datum in der Versionsverwaltung auf.

Für DBAs, die die Wiederherstellbarkeit einer selbst betriebenen Redis-8.0-Instanz prüfen müssen.
Für Anwendungs- und Plattformteams, die Speicheralarme, einen festhängenden Rewrite oder das Risiko eines Neustarts bewerten.
Für technische Verantwortliche, die persistenten Speicher, externe Sicherungen und Versionspflege in ihre Redis-Planung aufnehmen.

Stand: 04.11.2026. Der Versionsstatus wurde mit der offiziellen Redis-Versionsverwaltung abgeglichen. Prüfen Sie vor einem Eingriff zusätzlich die Dokumentation der tatsächlich eingesetzten Redis-Version; bei Änderungen am Supportstatus oder an den Hinweisen zur Dateiverarbeitung muss dieser Beitrag neu bewertet werden.

Redis 8.0 AOF-Neuschreibung: Fehlerbild statt Vermutung

Eine fehlgeschlagene Neuschreibung sagt für sich genommen nicht, ob Daten verloren sind. Die AOF-Neuschreibung erzeugt einen kompakten Stand, während Redis weiterhin Schreibvorgänge verarbeitet. Je nach Konfiguration und Dateiformat müssen alter Stand, neue Basis und währenddessen angefallene Änderungen als zusammengehöriger Satz betrachtet werden. Die Redis-Dokumentation zur Persistenz und mehrteiligen AOF beschreibt diesen Zusammenhang.

Unterscheiden Sie zunächst zwischen drei Ursachenklassen: nicht verfügbarem Speicherplatz oder Inodes, Schreib- beziehungsweise Synchronisationsfehlern und einem Rewrite, dessen Fortschritt unklar ist. Ein voller Datenträger ist eine naheliegende, aber nicht die einzige Erklärung. Ebenso beweist ein scheinbar ausreichend großes Dateisystem nicht, dass Schreiben und Synchronisieren fehlerfrei funktionieren.

Beginnen Sie mit INFO persistence:

redis-cli INFO persistence

Achten Sie insbesondere auf aof_rewrite_in_progress, aof_rewrite_scheduled, aof_last_bgrewrite_status und aof_last_write_status. Die Dokumentation zum INFO-Befehl beschreibt die verfügbaren Persistenzfelder. Die dort dargestellten Statuswerte sind Momentaufnahmen: Ein erfolgreicher vorheriger Rewrite belegt nicht, dass der aktuelle Schreibpfad in Ordnung ist. Ein einzelner Statuswert erklärt auch nicht die Ursache eines Fehlers.

Wenn Sie den Rewrite manuell anstoßen möchten, lesen Sie zunächst die Dokumentation zu BGREWRITEAOF und prüfen Sie, ob der laufende Zustand und die aktuelle Fehlerlage einen erneuten Versuch überhaupt sinnvoll machen. Ein weiterer Schreibvorgang ersetzt keine Diagnose und kann die Situation verschärfen, wenn der Datenträger bereits unter Druck steht.

Speicherplatz und Dateisystem gemeinsam prüfen

Ermitteln Sie, auf welchem Dateisystem das Redis-Datenverzeichnis liegt. Prüfen Sie dort sowohl die verfügbaren Datenblöcke als auch die Inodes; ein Verzeichnis kann trotz freier Kapazität an der Inode-Grenze scheitern. Die GNU-Dokumentation zu df beschreibt die Anzeige von Dateisystembelegung und Inodes.

df -h -- /pfad/zum/redis-datenverzeichnis
df -i -- /pfad/zum/redis-datenverzeichnis
findmnt --target /pfad/zum/redis-datenverzeichnis

Ersetzen Sie den Beispielpfad durch den tatsächlichen Datenpfad Ihrer Instanz. Bewerten Sie nicht nur die Ausgabe des Verzeichnisses, sondern prüfen Sie, ob der erwartete Mount tatsächlich eingebunden ist. Kontrollieren Sie anschließend Redis-Protokolle und Systemmeldungen auf Schreib-, Synchronisations- oder Dateisystemfehler. Falls die Redis-Dateien auf einem anderen Datenträger liegen als angenommen, ist die Kapazität des falschen Mounts für die Diagnose ohne Aussagekraft.

Beim Rewrite können vorhandene und neu erzeugte Dateien zeitweise nebeneinander bestehen; zusätzlich fallen während der Verarbeitung neue Änderungen an. Daraus folgt keine allgemeingültige feste Platzreserve. Ermitteln Sie den tatsächlichen belegten Speicher Ihrer AOF-Dateien und des gesamten Dateisystems, berücksichtigen Sie das Wachstum während des Schreibbetriebs und vergleichen Sie diese Werte mit der verfügbaren Kapazität. Eine pauschale Multiplikation ersetzt diese Bestandsaufnahme nicht.

Ist der Platz knapp, identifizieren Sie zuerst nicht zu Redis gehörende temporäre oder entbehrliche Dateien. Löschen Sie nichts aus dem aktiven Redis-Dateisatz. Wenn eine Bereinigung nicht sicher möglich ist, bewerten Sie eine kontrollierte Erweiterung des verfügbaren Speichers oder einen geplanten Umzug. Halten Sie den ursprünglichen Zustand und relevante Protokolle fest, bevor Sie Änderungen vornehmen.

Stillstand und Dateisatz getrennt untersuchen

Wenn die Kapazitätsprüfung keinen Engpass zeigt, gehen Sie nicht direkt von einem Redis-Fehler aus. Prüfen Sie, ob der Rewrite laut Persistenzstatus noch läuft, ob das Betriebssystem den zugehörigen Prozess zeigt und ob sich die I/O-Aktivität verändert. Vergleichen Sie diese Beobachtungen mit Redis-Protokollen und Systemmeldungen. Eine Momentaufnahme ist dabei weniger aussagekräftig als wiederholte Beobachtungen, die denselben Zeitraum abdecken.

Sichern Sie bei unklarer Ursache diese Befunde, die genaue Redis-Version, die Build-Umgebung und die zeitlich passenden Protokolle. Leiten Sie aus einer einzelnen Community-Diskussion oder einem GitHub-Einzelfall keine allgemeine Fehlerursache ab: Solche Beiträge können auf ein Untersuchungsfeld hinweisen, belegen aber weder ein verbreitetes Redis-8.0-Problem noch eine für Ihre Installation passende Reparatur.

Behandeln Sie Redis AOF bei der Sicherung als Dateisatz. Bei mehrteiliger AOF müssen Manifest, Basisdatei und zugehörige inkrementelle Dateien gemeinsam und zeitlich konsistent erfasst werden. Eine Kopie einzelner Dateien, während Redis sie verändert, kann einen unbrauchbaren oder uneindeutigen Sicherungsstand erzeugen. Dokumentieren Sie, welcher Sicherungsweg eingesetzt wurde und zu welchem Zeitpunkt der Stand gehört. Die Redis-Persistenzdokumentation erläutert die Struktur und den Ablauf; prüfen Sie die Anweisungen gegen Ihre konkrete Version.

Beschädigte AOF auf einer Kopie behandeln

Bevor Sie ein Prüf- oder Reparaturwerkzeug einsetzen, erstellen Sie eine geschützte Kopie der betroffenen Dateien. Bewahren Sie den unveränderten Originalsatz getrennt auf und notieren Sie, welche Dateien und Protokolle zum Vorfall gehören. Bei einer mehrteiligen AOF genügt es nicht, nur eine Datei herauszulösen und als vollständige Sicherung zu behandeln.

redis-check-aof kann bei bestimmten AOF-Fehlern zur Untersuchung oder Reparatur verwendet werden. Prüfen Sie in der offiziellen Anleitung zur AOF-Prüfung und -Reparatur, welche Vorgehensweise für das konkrete Format und die eingesetzte Redis-Version dokumentiert ist. Führen Sie eine Reparatur nur auf der Kopie aus und halten Sie fest, was das Werkzeug meldet sowie ob ein unvollständiges Ende verworfen werden könnte. Verwenden Sie keine ungeprüfte Anleitung zum manuellen Ändern eines Manifests.

Ein erfolgreich beendetes Werkzeug belegt nicht, dass der Dienst alle fachlich erforderlichen Daten wiederherstellen kann. Starten Sie die bearbeitete Kopie daher separat und prüfen Sie den Zustand, bevor Sie Entscheidungen zur Produktion treffen. Lassen Sie Originaldateien unangetastet, bis die Wiederherstellung verifiziert und ein Rückweg festgelegt ist.

Wiederherstellung isoliert verifizieren

Eine erfolgreiche Prozessinitialisierung ist nur ein technischer Anfangstest. Verwenden Sie eine Umgebung, die vom Produktionsdatensatz getrennt ist, und starten Sie dort eine Kopie, die mit dem tatsächlich genutzten Sicherungsverfahren erstellt wurde. Wenden Sie die gleiche Redis-Version und denselben relevanten Startablauf an, soweit das für Ihren Wiederherstellungstest erforderlich ist. So reduzieren Sie das Risiko, dass ein Testschritt den Produktionsstand verändert.

Vergleichen Sie das Ergebnis mit dem Sicherungszeitpunkt. Prüfen Sie die für Ihren Dienst kritischen Schlüssel und Datentypen, die erwarteten Ablaufzeiten sowie anwendungsspezifische Invarianten. Verwenden Sie Streams nur dann als Prüfkriterium, wenn sie in Ihrem Dienst tatsächlich eingesetzt werden; kontrollieren Sie dann auch deren fachlich relevante Einträge und Zustände. Halten Sie fest, welche Abweichungen durch den Zeitpunkt der Sicherung erklärbar sind und welche ungeklärt bleiben.

RDB und AOF sind unterschiedliche Persistenzwege. Ein erfolgreicher RDB-Test verdeckt nicht automatisch einen defekten AOF-Sicherungsweg; umgekehrt belegt ein erfolgreicher AOF-Start nicht, dass die RDB-Sicherung verwendbar ist. Führen Sie für jeden Wiederherstellungsweg, auf den sich Ihr Betrieb verlässt, einen passenden Test durch. Bis die Prüfungen erfolgreich sind, überschreiben Sie keine Produktionsdateien und erklären Sie die Daten nicht pauschal für vollständig wiederhergestellt.

Entscheidungswege für den nächsten Schritt

Wählen Sie die Maßnahme anhand der Befunde, nicht anhand der Vermutung, ein Neustart werde das Problem beseitigen:

• Wenn das Datenverzeichnis auf dem erwarteten Mount liegt, aber Speicherplatz oder Inodes knapp sind, dann bereinigen Sie nur nachweislich entbehrliche Dateien außerhalb des aktiven Redis-Dateisatzes oder planen eine kontrollierte Speichererweiterung. Andernfalls prüfen Sie zunächst Mount und Dateisystemzustand.
• Wenn Redis einen Schreibfehler meldet oder Systemprotokolle einen Datenträgerfehler zeigen, dann sichern Sie Dateien und Protokolle und untersuchen den Speicherpfad. Andernfalls vergleichen Sie den Rewrite-Status mit Prozess- und I/O-Beobachtungen, statt eine Hardwareursache zu unterstellen.
• Wenn Manifest und zugehörige AOF-Dateien vollständig und konsistent gesichert sind, dann testen Sie die Kopie isoliert. Andernfalls vervollständigen Sie die Sicherung, bevor Sie eine Reparatur versuchen.
• Wenn der isolierte Start und die fachlichen Prüfungen erfolgreich sind, dann dokumentieren Sie den getesteten Wiederherstellungsweg und planen eine kontrollierte Rückkehr. Andernfalls bewahren Sie Original und Kopien getrennt auf und untersuchen die Abweichung weiter.
• Wenn Ihre Betriebsplanung Redis 8.0 noch über den 01.12.2026 hinaus vorsieht, dann prüfen Sie den Versions- und Wartungsplan anhand der offiziellen Redis-Versionsverwaltung. Andernfalls behandeln Sie das Supportende dennoch als Anlass, den gewählten Zielstand und die nötigen Tests festzuhalten.

Häufige Fragen zur AOF-Reparatur

Welche Prüfungen sind nach einer fehlgeschlagenen AOF-Neuschreibung zuerst sinnvoll?

Sichern Sie zunächst Protokolle und den aktuellen Dateisatz, ohne Redis-Dateien zu löschen oder den Dienst vorschnell neu zu starten. Prüfen Sie danach mit INFO persistence den Rewrite- und Schreibstatus und ermitteln Sie mit df freien Speicherplatz sowie Inodes auf dem Dateisystem des Datenverzeichnisses. Erst diese Befunde zeigen, ob Speicherknappheit, ein Schreibfehler oder ein anderer Zustand untersucht werden muss.

Wie sichern Sie mehrteilige AOF-Dateien vollständig, wenn während des Kopierens weitergeschrieben wird?

Behandeln Sie Manifest, Basisdatei und zugehörige inkrementelle Dateien als zusammengehörigen Dateisatz. Ein Kopiervorgang während laufender Änderungen kann einen zeitlich uneinheitlichen Stand erzeugen. Verwenden Sie deshalb einen konsistenten Sicherungsweg, den Sie für Ihre Redis-Version geprüft haben, und testen Sie die Kopie durch einen Start in einer isolierten Umgebung. Eine einzelne Datei zu kopieren genügt bei mehrteiliger AOF nicht automatisch.

Ist eine AOF-Reparatur mit redis-check-aof gleichbedeutend mit einer vollständigen Wiederherstellung?

Nein. Das Werkzeug kann je nach Dateiformat und Fehlerbild bei Prüfung oder Reparatur helfen, beweist aber nicht, dass alle fachlich wichtigen Daten vorhanden sind. Arbeiten Sie auf einer Kopie und halten Sie fest, ob die Reparatur ein unvollständiges Ende verwirft. Anschließend prüfen Sie Schlüssel, Datentypen, Ablaufzeiten und anwendungsspezifische Invarianten beim isolierten Start.

Woran erkennen Sie, ob eine wiederhergestellte Redis-AOF-Datei für den Produktivbetrieb taugt?

Starten Sie die gesicherte Dateikopie getrennt von der Produktion und vergleichen Sie das Ergebnis mit dem Sicherungszeitpunkt. Kontrollieren Sie nicht nur, ob Redis startet, sondern auch die fachlich kritischen Schlüssel, Ablaufzeiten und gegebenenfalls Stream-Zustände. Wenn Prüfungen fehlschlagen oder der Sicherungszeitpunkt unklar ist, überschreiben Sie keine Produktionsdateien und erklären Sie die Wiederherstellung nicht für vollständig.

Speicherplanung, Sicherung und Serverwahl

Eine größere Speicherkapazität kann Platzengpässe entschärfen, ist aber weder eine AOF-Reparatur noch ein Schutz vor Dateibeschädigung. Ebenso schafft ein dedizierter Server allein keine Datenredundanz. Sie benötigen einen nachvollziehbaren Sicherungsweg, eine vom Redis-Server getrennte Sicherungskopie und wiederkehrende Wiederherstellungstests. Wenn Ihre Sicherung und Redis-Daten auf demselben Ausfallpfad liegen, kann ein einzelner Speicherfehler beides betreffen.

Planen Sie Ihre Speicherbelegung anhand des beobachteten AOF-Wachstums, des Speicherbedarfs während des Rewrites und der tatsächlich vorhandenen Wiederherstellungskopie. Entscheiden Sie anschließend, ob die Ursache eine Kapazitätsgrenze, eine ungünstige Dateiaufteilung oder ein ungetesteter Sicherungsablauf ist. Bei einer selbst verwalteten Installation ohne Hardware-RAID müssen Sie Redundanz selbst über Software-RAID oder Replikation planen; auch das ersetzt keine externe Sicherung.

Wenn Sie den Speicherbedarf und die Aufteilung Ihrer Serverlaufwerke bewerten, können Sie die Informationen zu Arbeitsspeicher und Datenträgern als Orientierung für Ihre Planung heranziehen. Für eine konkrete Entscheidung prüfen Sie die aktuell tatsächlich auswählbaren Optionen im Produktangebot von OSFP Cloud. Leiten Sie daraus keine Annahmen über die Integrität Ihrer AOF-Dateien oder die Wiederherstellbarkeit Ihrer Daten ab.

Bei einer gemeinsamen Cloud-Instanz können geteilte Ressourcen, weniger Kontrolle über die Speicheraufteilung oder ein nicht zu Ihrem Betrieb passender Abrechnungsumfang die Ursachenanalyse erschweren. Eine dedizierte AMD-Physikmaschine ist dagegen vor allem dann erwägenswert, wenn Sie dauerhaft eigene Ressourcen und eine selbst bestimmte Speicher- und Sicherungsarchitektur benötigen. Für kurzlebige Tests oder sehr geringe Last kann eine geteilte Instanz weiterhin die passendere Wahl sein. OSFP Cloud kann in die Prüfung einbezogen werden, wenn Ihr Redis-Dienst dauerhaft betrieben wird; entscheidend sind die real verfügbaren Laufwerksoptionen und Ihr unabhängig organisierter Backup- und Wiederherstellungsprozess, nicht der Wechsel der Hardware allein.

Häufige Fragen

Welche Prüfungen sind nach einer fehlgeschlagenen AOF-Neuschreibung zuerst sinnvoll?

Sichern Sie zunächst Protokolle und den aktuellen Dateisatz, ohne Redis-Dateien zu löschen oder den Dienst vorschnell neu zu starten. Prüfen Sie danach mit INFO persistence den Rewrite- und Schreibstatus und ermitteln Sie mit df den freien Speicherplatz sowie die verfügbaren Inodes auf dem Dateisystem des Datenverzeichnisses. Erst diese Befunde zeigen, ob Speicherknappheit, Schreibfehler oder ein anderer Zustand untersucht werden muss.

Wie sichern Sie mehrteilige AOF-Dateien vollständig, wenn während des Kopierens weitergeschrieben wird?

Behandeln Sie Manifest, Basisdatei und zugehörige inkrementelle Dateien als zusammengehörigen Dateisatz. Ein Kopiervorgang während laufender Änderungen kann einen zeitlich uneinheitlichen Stand erzeugen. Nutzen Sie daher einen konsistenten Sicherungsweg, den Sie für Ihre Redis-Version geprüft haben, und testen Sie die Kopie durch einen Start in einer isolierten Umgebung. Eine einzelne AOF-Datei zu sichern genügt bei mehrteiliger AOF nicht automatisch.

Ist eine AOF-Reparatur mit redis-check-aof gleichbedeutend mit einer vollständigen Wiederherstellung?

Nein. Das Werkzeug kann je nach Dateiformat und Fehlerbild bei der Prüfung oder Reparatur helfen, beweist aber nicht, dass alle fachlich wichtigen Daten vorhanden sind. Arbeiten Sie auf einer Kopie und halten Sie fest, ob die Reparatur ein unvollständiges Ende verwirft. Anschließend prüfen Sie Schlüssel, Datentypen, Ablaufzeiten und anwendungsspezifische Invarianten beim isolierten Start.

Woran erkennen Sie, ob eine wiederhergestellte Redis-AOF-Datei für den Produktivbetrieb taugt?

Starten Sie die gesicherte Dateikopie getrennt von der Produktion und vergleichen Sie das Ergebnis mit dem Sicherungszeitpunkt. Kontrollieren Sie nicht nur, ob Redis startet, sondern auch die fachlich kritischen Schlüssel, Ablaufzeiten und gegebenenfalls Stream-Zustände. Wenn diese Prüfungen fehlschlagen oder der Sicherungszeitpunkt unklar ist, überschreiben Sie keine Produktionsdateien und erklären Sie die Wiederherstellung nicht für vollständig.