2026 Redis 8.0 AOF書き換え失敗はどうする？まずディスクと復旧経路を確認

AOF書き換えに失敗し、ディスク警告や復旧結果への不安が出ている場合は、まずRedisの永続化状態、ファイルシステムの空き容量、AOFファイル一式を確認してください。ファイルを削除したり本番環境をすぐ再起動したりせず、複製したデータを隔離環境で検証します。

向いている方： Redis 8.0の永続化を担当し、AOFの障害が復旧に与える影響を確認したいDBAや運用担当者。
ディスク不足や書き換え停滞の原因を切り分け、安全に復旧できるか確かめたいアプリケーション・プラットフォーム担当者。
ストレージの割り当て、機外バックアップ、バージョン保守をまとめて見直したい技術責任者。

Redis 8.0のAOF書き換え失敗は、何から確認する？

Redis 8.0のAOF書き換え失敗は、すべてを「ディスク容量不足」と決めつけず、容量・書き込みや同期のエラー・書き換え処理の停滞に分けて調べます。AOFは書き込みを記録する永続化方式で、バックグラウンド書き換え中も新しい書き込みを処理するため、古いファイルだけでなく新しいファイルや処理中に追加されるデータも考慮が必要です。RedisのAOFと書き換えの説明

最初に状態を読み取り専用で確認します。INFO persistence には、AOFが有効か、書き換えが進行中か、直近の書き換え結果や書き込み状態がどうかを確認する項目があります。INFOの永続化項目

redis-cli INFO persistence

出力では、次の項目を探します。環境やバージョンに応じて、表示される項目をRedisの文書と照合してください。

aof_enabled:<値>
aof_rewrite_in_progress:<値>
aof_rewrite_scheduled:<値>
aof_last_bgrewrite_status:<値>
aof_last_write_status:<値>

AOF書き換えを依頼するBGREWRITEAOFは調査の代わりにはなりません。失敗の記録やストレージ状態を保存する前に、追加の書き換えを要求しないでください。実行するとバックグラウンドでAOFの書き換えを開始するコマンドなので、再実行は原因と負荷を確認してから判断します。BGREWRITEAOFの動作

空き容量不足と書き込みエラーをどう区別する？

Redisのデータディレクトリがあるファイルシステムで、空き容量、inode、マウント状態を確認します。df -hだけではinodeの枯渇を見落とす可能性があるため、df -iも実行し、対象のマウント先が想定どおりかを確認してください。GNU Coreutilsのdf説明

df -h /path/to/redis
df -i /path/to/redis
findmnt /path/to/redis

パスは実際の設定に置き換えます。空き領域があっても、書き込みエラーやストレージ側の問題がないとは限りません。Redisのログ、OSのログ、プロセス状態、ディスクI/Oを同じ時間帯で確認し、どの層でエラーが出ているか記録します。

容量不足の場合は、AOFファイル、清掃対象の一時ファイル、別用途のファイルを先に区別します。書き換え時に必要な容量は、現在のデータ量だけで固定的に計算できません。既存ファイル、新しく生成されるファイル、書き換え中に追加される内容を踏まえて、実際のファイルサイズと利用可能容量から見積もってください。根拠のない「何倍」という値を当てはめないことが重要です。

空き容量の確保が必要でも、稼働中のAOFやマニフェストを直接削除してはいけません。Redis以外の不要ファイルを安全に整理できるか、保存先を拡張できるかを評価し、作業前にファイル一式とログの保全を優先します。設定変更で解決するように見える場合も、実行中の変更が可能な項目と永続化設定の扱いをCONFIG SETの仕様で確認してください。

Redis 7以降の複数ファイルAOFは、どう一式で退避する？

Redis 7以降では、複数のAOFファイルと、それらの構成を示すマニフェストを使う形式があります。単一のファイルだけをバックアップすると、復旧に必要なファイルを欠くおそれがあるため、マニフェストから参照されるファイルを含めて一式を扱います。複数ファイルAOFの構成

稼働中のディレクトリから各ファイルを順番にコピーしただけで、同一時点の整合したバックアップになるとは限りません。停止してから取得する方法、または一貫した時点を保てるストレージ側の取得手順を選び、復旧側でファイル一式を読み込めるか確認してください。実際の取得方法は、運用環境とRedisの該当バージョンに合わせて決めます。

退避前後に、ファイル名、サイズ、更新時刻、マニフェストの内容、コピー結果を記録します。バックアップ先は本番サーバーとは別にし、AOFだけでなくRDBを使う運用なら、そのバックアップも別の復旧経路として確認します。Redisの永続化方式の違いは公式の永続化説明を参照してください。

AOF修復後、復旧できる状態をどう確かめる？

AOFの破損が疑われる場合は、先に原本を別の場所へ複製し、修復作業は複製側で行います。redis-check-aofは、対象ファイルや修復オプションの利用条件を該当バージョンの公式文書で確かめてから実行してください。修復が末尾の不正部分を切り詰める可能性があるため、コマンドの終了だけでデータの完全性を判断できません。Redis公式文書のAOF確認・修復の注意点

# まず原本を保全し、複製したファイルを対象にする
redis-check-aof --fix /path/to/copied-aof-file

上記は実行形の例であり、稼働中のファイルや唯一の原本を指定する手順ではありません。対象が複数ファイルAOFの場合は、マニフェストと参照先を含めた構成を確認し、単一ファイル用の想定で処理しないでください。

復旧確認は隔離したRedisで行い、本番のファイルを上書きしません。バックアップを復元して、キーの存在だけでなく、データ型、重要な値、期限切れの挙動、Streamなど業務上必要な不変条件を確認します。バックアップ時点以降の書き込みが含まれない場合は、その差分を復旧時点と照らして記録してください。AOFでの復旧とRDBでの復旧もそれぞれ検証し、一方が起動できたことを理由に、もう一方の欠陥を見過ごさないようにします。

調査からサーバーとバックアップの見直しまで進める

次の順で作業すると、原因調査と復旧判断を分けて進められます。

1. 現状を記録する： INFO persistence、RedisとOSのログ、プロセス状態、ファイル一覧を保存します。調査中に設定変更や再起動を加えず、取得時刻も残してください。
2. 保存先を調べる： Redisのデータディレクトリがあるマウント先で、容量、inode、マウント状態、I/Oエラーを確認します。
3. AOF一式を保全する： マニフェストと参照先のファイルを特定し、原本を保護します。稼働中のコピーが整合していると仮定しないでください。
4. 原因を分けて対処する： 空き容量、書き込み・同期エラー、処理停滞のどれに該当するかを、ログと状態の根拠で判断します。原因が不明なら、ファイル操作より追加の記録を優先します。
5. 複製データで復旧を試す： 修復またはバックアップ復元を隔離環境で行い、アプリケーションが必要とするデータと業務上の条件を検証します。
6. 再発防止を決める： データ増加と書き換え用の余裕、保存先の構成、機外バックアップ、復旧演習の実施方法を見直します。

条件に応じた判断

• 容量不足の証拠があり、書き込みエラーがない場合： 原本を保全し、Redis以外の安全に整理できる領域やストレージ拡張を検討します。利用中のAOF削除は選びません。
• 容量に余裕があるのに書き換えが進まない場合： ログ、プロセス、I/Oの状態を照合します。原因が特定できないうちは、追加書き換えや本番再起動を避けて調査を続けます。
• ファイルの破損や書き込み中断が疑われる場合： 原本の複製を作り、対応バージョンの手順に沿って隔離環境で修復します。検証が終わるまで本番データを置き換えません。
• 復旧結果が業務要件を満たさない場合： AOFの修復成功だけで完了とせず、別時点のバックアップやRDBを使った復旧を検証します。機外バックアップがない場合は、復旧手順より先にバックアップ経路の整備を計画します。

2026年12月1日の保守期限とストレージ選択の判断基準

公開情報の確認日である2026年11月4日時点で、Redis公式のバージョン管理ページにはRedis 8.0のサポート終了日が2026年12月1日と記載されています。保守計画にはバージョンの確認と移行準備を含めますが、アップグレードはバックアップや復旧演習の代わりにはなりません。Redis Open Sourceのバージョン管理

データ量と障害時の要件を確認したうえで、次の条件で選択してください。

• 負荷が軽く、短期間の実験が中心なら： 専有サーバーへ移す前に、現行環境でAOF一式を取得できるか、復旧手順を実行できるかを確認します。
• 共有環境のストレージ制約が原因調査や復旧を妨げるなら： 保存先やファイル配置を自分で制御できる構成を比較します。専有型を選ぶ場合も、冗長化とバックアップは別途必要です。
• マネージド環境を使い続けるなら： AOF、RDB、機外バックアップの取得可否と、復元を検証できる手段を契約条件と運用手順で確認します。
• 復旧確認が済んでいないなら： ハードウェア変更やRedisのアップグレードを復旧完了とみなさず、隔離環境での検証を先に行います。

OSFP CloudのAMD物理サーバーは専有型ですが、ハードウェアRAIDやデータ保護を自動で提供するものとして扱うことはできません。専有サーバーに移しても、AOFの障害原因が直るわけではなく、ソフトウェアRAIDやレプリケーション、機外バックアップの設計が必要です。ディスク構成を検討するときは、ストレージ構成の案内も確認し、サービス範囲は利用条件の説明と照らし合わせてください。

共有型の仮想サーバーでは、近隣利用者との資源共有やストレージ構成の制約が調査・復旧の選択肢を狭める場合があります。マネージドデータベースでは、ファイルへのアクセスやバックアップの取り出し方が提供範囲に左右されます。安定して稼働する専有環境でRedisを長期運用し、ストレージの使い方を自分で組み立てたい場合は、OSFP Cloudの製品構成で現在選べる内容を確認したうえで、機外バックアップと復旧演習をセットで計画してください。AOFの復旧可否は、構成変更ではなく、実データを使った検証で判断します。