2026年8月27日

Redisのバックアップ設定方法（RDBとAOFの違い・取得と復元の手順）

データベースサーバー

Redisのデータを守る方法は、ある時点の内容をまるごと書き出す「RDB」と、書き込みコマンドを順に記録していく「AOF」の2つです。結論から言うと、失ってもよいキャッシュ用途ならRDBだけ（または永続化なし）、セッションやキューなど消えると困るデータならRDBとAOFの併用が基本です。この記事では、両方の設定方法、稼働中に安全にバックアップを取る手順、復元のときにつまずきやすい点を順に説明します。

RDBとAOFの違い

RDBは、Redisのメモリ上のデータを dump.rdb という1つのファイルに書き出すスナップショットです。ファイルが小さく、復元（起動時の読み込み）も速いのが利点です。一方、スナップショットの間に書き込まれたデータは、障害時に失われます。たとえば5分おきに保存しているなら、最大で5分ほどのデータを失う可能性があります。

AOF（Append Only File）は、データを変更するコマンドをファイルに追記していく方式です。設定によっては失うデータを1秒程度に抑えられます。そのかわりファイルが大きくなりやすく、起動時の読み込みにもRDBより時間がかかります。ファイルが肥大化しないよう、Redisは定期的にAOFを書き直します（リライト）。

用途ごとの目安は次のとおりです。

WordPressのオブジェクトキャッシュなど、消えても作り直せるデータ: RDBのみ、または永続化なし
ログインセッション、ジョブキュー、カウンターなど、消えると困るデータ: RDBとAOFを併用
バックアップファイルを別の場所へ保管したい: RDBファイルのコピーが扱いやすい

AOFを有効にしても、バックアップとして別の場所へ持ち出すにはRDBファイルが便利なので、併用にしておくと両方の利点を得られます。

現在の設定を確認する

設定を変える前に、今どうなっているかを確認します。

redis-cli CONFIG GET dir
redis-cli CONFIG GET save
redis-cli CONFIG GET appendonly
redis-cli INFO persistence

dir はRDBやAOFが保存されるディレクトリです。INFO persistence では、最後のRDB保存が成功したか（rdb_last_bgsave_status）、最後に保存した時刻（rdb_last_save_time、UNIX時間）、AOFが有効か（aof_enabled）などが分かります。ここで保存の失敗が出ている場合は、ディスク容量やディレクトリの権限を先に疑ってください。

RDBの設定

RDBの保存タイミングは save で指定します。「◯秒の間に◯回以上の変更があったら保存する」という条件を並べる形式です。

# /etc/redis/redis.conf の例
save 3600 1 300 100 60 10000
dir /var/lib/redis
dbfilename dump.rdb
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes

この例では「1時間に1回以上」「5分に100回以上」「1分に1万回以上」の変更がいずれかで成り立つと保存します。save "" と書くとRDBの自動保存を止められます。

stop-writes-on-bgsave-error yes は、保存に失敗したときに書き込みを拒否する設定です。気づかないうちにバックアップが止まっている事態を防げますが、ディスクが満杯になるとアプリケーション側でエラーが出始めます。監視でディスク容量を見ておくと、原因にすぐ気づけます。

手動で保存したいときは BGSAVE を使います。バックグラウンドで保存するので、処理は止まりません。SAVE は保存が終わるまでほかのコマンドを受け付けないため、本番では使わないでください。

AOFの設定

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

appendfsync は、ディスクへ書き込みを確定させる頻度です。everysec は1秒ごとで、性能と安全性のバランスが良く、一般的な選択です。always は書き込みのたびに確定させるため最も安全ですが遅くなり、no はOSに任せるため速いものの、失うデータが増える可能性があります。

auto-aof-rewrite-percentage と auto-aof-rewrite-min-size は、AOFのリライトを起こす条件です。上の例では、ファイルが64MB以上で、前回のリライト後から2倍の大きさになったときに書き直します。aof-use-rdb-preamble yes にすると、リライト後のファイルの先頭がRDB形式になり、読み込みが速くなります。

Redis 7.0以降、AOFは appenddirname で指定したディレクトリの中に、ベースファイル・追記ファイル・それらを束ねるマニフェストの複数ファイルで管理されるようになりました。バックアップのときは、このディレクトリをまとめて扱う必要があります。

稼働中のRedisでAOFを有効にするなら、設定ファイルを書き換えて再起動するより、先に redis-cli CONFIG SET appendonly yes を実行し、INFO persistence でAOFの作成が終わったのを確認してから設定ファイルにも反映するほうが安全です。いきなり設定ファイルだけ変えて再起動すると、バージョンや状況によっては空のAOFから起動してしまい、データが空に見える事故につながります。起動時の挙動はバージョンで差があるため、公式ドキュメントの永続化の章で手元のバージョンの扱いを確認してください。

稼働中にバックアップを取る

RDBファイルのコピー

RDBファイルは、Redisが一時ファイルに書き終えてから名前を差し替える方式で作られるため、稼働中にコピーしても壊れた途中のファイルをつかむ心配は小さいです。手順は次のとおりです。

redis-cli BGSAVE
# 完了を確認（rdb_bgsave_in_progress:0 になり、保存時刻が更新される）
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_save_time|rdb_last_bgsave_status'
cp /var/lib/redis/dump.rdb /backup/redis/dump-$(date +%Y%m%d%H%M).rdb

別のサーバーから取得したい場合は、redis-cli --rdb /backup/redis/dump.rdb で、接続先RedisのRDBを手元に保存することもできます。

AOFディレクトリのコピー

Redis 7.0以降でAOFをコピーする場合は、コピー中にリライトが走ってファイル構成が変わらないようにします。

redis-cli CONFIG SET auto-aof-rewrite-percentage 0
redis-cli INFO persistence | grep aof_rewrite_in_progress   # 0 であること
cp -r /var/lib/redis/appendonlydir /backup/redis/appendonlydir-$(date +%Y%m%d%H%M)
redis-cli CONFIG SET auto-aof-rewrite-percentage 100        # 元の値に戻す

最後に元の値へ戻すのを忘れると、AOFが際限なく大きくなります。スクリプト化して戻し忘れを防いでください。

保管先と世代管理

同じサーバーの中にあるバックアップは、ディスク故障やサーバーの乗っ取りで一緒に失われます。cronなどで定期的に取得し、別のサーバーやオブジェクトストレージへ転送し、日付付きで複数世代を残すのが基本です。中身にセッション情報などが含まれる場合は、転送前に暗号化しておきます。

復元の手順

復元は、まずステージング環境で手順を試してから本番で行います。本番では、復元前に今のデータもバックアップしておきます。

Redisを停止する（sudo systemctl stop redis-server など。サービス名はディストリビューションで異なります）
dir のディレクトリにある既存の dump.rdb と appendonlydir を退避する
バックアップの dump.rdb を配置し、所有者をRedisの実行ユーザー（例: redis）に合わせる
Redisを起動し、DBSIZE やいくつかのキーで中身を確認する

ここで最も多い失敗が、AOFが有効なままRDBを戻すケースです。Redisは起動時、AOFが有効ならAOFを優先して読み込みます。そのため、RDBだけを戻しても、退避し忘れたAOFの内容（古い内容や空の状態）で起動してしまうことがあります。RDBから戻すときは、いったん appendonly no で起動してデータを確認し、その後 CONFIG SET appendonly yes でAOFを作り直し、作成完了後に設定ファイルも appendonly yes に戻す、という順番にします。

ファイルの破損が疑われる場合は、付属の redis-check-rdb と redis-check-aof で確認できます。redis-check-aof --fix は末尾の壊れた部分を切り捨てて修復するため、実行前に元のファイルをコピーしておいてください。

運用上の注意

RDBの保存やAOFのリライトでは、Redisがプロセスを複製（fork）して書き出します。書き込みが多いと、その間にメモリ使用量が一時的に増えます。サーバーのメモリに余裕がないと保存に失敗するため、maxmemory を物理メモリいっぱいに設定しないこと、Linuxでは公式ドキュメントが推奨する vm.overcommit_memory = 1 を設定しておくことが大切です。設定値や推奨事項はRedisのバージョンで変わることがあるため、利用中のバージョンのドキュメントも確認してください（2026年10月現在）。

まとめ

RDBはスナップショットで小さく復元が速い、AOFは失うデータを小さくできる。消えると困るデータは併用する
設定前に CONFIG GET と INFO persistence で現状と保存の成否を確認する
バックアップは BGSAVE 後のRDBコピーが扱いやすい。Redis 7.0以降のAOFはリライトを止めてディレクトリごとコピーする
AOFが有効なままRDBを戻すとAOFが優先される。復元は appendonly no で起動してから切り替える
バックアップは別の場所へ転送し、複数世代を残す。手順はステージングで試しておく