2026年7月30日
2026年7月30日
Redisの永続化(RDB・AOF)の設定方法|違い・切り替え手順・バックアップ
Redisはデータをメモリに置くため、設定によっては再起動やサーバー障害でデータが消えます。ディスクにデータを残す仕組みが「永続化」で、RDBとAOFの2つの方式があります。この記事では、2つの違い、redis.conf の設定、稼働中のサーバーでの切り替え、動作の確認、バックアップまでを説明します。内容は2026年10月時点のRedis公式ドキュメント(redis.io)に合わせ、Redis 7.0以降を前提にしています。
RDBとAOFの違い
| RDB | AOF | |
|---|---|---|
| 仕組み | 決めた間隔で、その時点の全データを dump.rdb に書き出す(スナップショット) |
データを変更するコマンドを受け付けるたびに、ファイルに追記する |
| 失う可能性のあるデータ | 最後のスナップショット以降の変更(設定によっては数分ぶん) | 既定の appendfsync everysec なら最大で約1秒ぶん |
| ファイルの大きさ | 小さい | RDBより大きくなりやすい(定期的に書き直して縮める) |
| 再起動時の読み込み | 速い | データが大きいとRDBより時間がかかる |
| 向いている用途 | バックアップ、数分の損失を許せるデータ | 損失を小さくしたいデータ |
公式ドキュメントは、データの安全性を重視するならRDBとAOFを両方使うことを勧めています。数分ぶんの損失を許せるならRDBだけでもかまいません。AOFだけの運用は、バックアップや再起動の速さの面からRDBも併用することが勧められています。キャッシュとしてだけ使い、消えても困らない場合は、永続化を無効にする選択肢もあります。
両方を有効にした場合、Redisは起動時にAOFからデータを読み込みます。AOFのほうが新しい変更まで含んでいるためです。
設定ファイルの場所
UbuntuやDebianの redis-server パッケージでは、設定ファイルは /etc/redis/redis.conf、データの保存先(dir)は /var/lib/redis、サービス名は redis-server です。ほかのディストリビューションや自分でビルドした場合は場所が異なるので、動いているRedisに問い合わせて確認します。
redis-cli CONFIG GET dir
redis-cli INFO server | grep config_file
パスワード(requirepass やACL)を設定している場合は、redis-cli に -a を付けるか、redis-cli に入ってから AUTH を実行してください。
RDBの設定
redis.conf の主な設定は次のとおりです。
# 3600 秒以内に 1 回以上、300 秒以内に 100 回以上、60 秒以内に 10000 回以上の変更があれば保存する
save 3600 1 300 100 60 10000
# スナップショットのファイル名と保存先
dbfilename dump.rdb
dir /var/lib/redis
# 最後のバックグラウンド保存が失敗したら書き込みを受け付けない(既定 yes)
stop-writes-on-bgsave-error yes
# RDB ファイルを LZF で圧縮する(既定 yes)
rdbcompression yes
save 秒数 変更回数 は「この秒数のあいだに、この回数以上の変更があったら保存する」という条件で、1行に複数の組を書けます。上の値はRedis 7の既定値です。save "" と書くとRDBの自動保存を無効にします。
stop-writes-on-bgsave-error を no にすると、ディスクがいっぱいなどで保存に失敗していても書き込みを受け付け続け、失敗に気づきにくくなります。監視の仕組みがない場合は yes のままにしてください。
手動で保存することもできます。BGSAVE は子プロセスで保存し、その間も応答を続けます。SAVE は保存が終わるまでほかの要求を止めるので、本番では使いません。
redis-cli BGSAVE
redis-cli LASTSAVE # 最後に保存できた時刻(UNIX 時間)
AOFの設定
# AOF を有効にする
appendonly yes
# AOF のファイル名の元になる名前と、ファイルを置くディレクトリ(dir の下に作られる)
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
# ディスクへの書き込み(fsync)の頻度
appendfsync everysec
# AOF が大きくなったら自動で書き直す条件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 書き直したベースファイルを RDB 形式にする(既定 yes)
aof-use-rdb-preamble yes
appendfsync の値の意味は次のとおりです。
| 値 | 動作 | 失う可能性のあるデータ |
|---|---|---|
always |
追記のたびにfsyncする | ほぼ無いが、非常に遅い |
everysec |
1秒ごとにfsyncする(既定・推奨) | 約1秒ぶん |
no |
fsyncせず、OSに任せる(AOFが無効になるわけではない) | OSの設定による(Linuxでは通常30秒程度) |
Redis 7.0以降のAOFは、1つのファイルではなく、dir の下の appendonlydir に複数のファイルとして保存されます。
| ファイル | 内容 |
|---|---|
appendonly.aof.1.base.rdb |
書き直した時点のデータ(aof-use-rdb-preamble yes ならRDB形式) |
appendonly.aof.1.incr.aof |
その後の変更の追記 |
appendonly.aof.manifest |
どのファイルを使うかを記録した管理ファイル |
番号は書き直しのたびに増えます。AOFは使い続けると大きくなるので、Redisは auto-aof-rewrite-* の条件を満たすと、現在のデータを最小のコマンドで表すように書き直します。手動で書き直す場合は redis-cli BGREWRITEAOF を実行します。
RDBで動いているサーバーをAOFに切り替える
すでにRDBでデータを持っているサーバーで、redis.conf の appendonly を yes に書き換えて再起動するだけにすると、データが消えることがあります。起動時にRedisは(まだ空の)AOFからデータを読み込むためです。公式ドキュメントの手順に沿って、稼働中に切り替えます。
手順1: dump.rdbをバックアップする
最新の dump.rdb を保存し、別の場所にコピーしておきます。
redis-cli BGSAVE
redis-cli LASTSAVE
sudo cp /var/lib/redis/dump.rdb /root/dump-$(date +%Y%m%d%H%M).rdb
手順2: 稼働中にAOFを有効にする
稼働中のサーバーでAOFを有効にします。AOFの書き直しが始まり、現在のデータがAOFに書き出されます。
redis-cli CONFIG SET appendonly yes
手順3: 書き直しの完了を待つ
書き直しが終わるのを待ちます。aof_rewrite_in_progress と aof_rewrite_scheduled が 0、aof_last_bgrewrite_status が ok になれば完了です。
redis-cli INFO persistence | grep -E 'aof_enabled|aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status'
手順4: 設定ファイルに反映する
変更を設定ファイルにも反映します。これを忘れると、次の再起動で古い設定に戻り、データを失うおそれがあります。
redis-cli CONFIG REWRITE
CONFIG REWRITE は、Redisが起動時に読んだ設定ファイルを、今の設定に合わせて書き換えます。失敗する場合(設定ファイルにRedisの実行ユーザーが書き込めないなど)は、redis.conf の appendonly を手で yes に直してください。
手順5: 再起動後にキーの数を確かめる
次に再起動したら、キーの数が切り替え前と同じかを確かめます。
redis-cli DBSIZE
動作を確認する
INFO persistence に、永続化の状態がまとめて表示されます。
redis-cli INFO persistence
| 項目 | 見るところ |
|---|---|
rdb_last_bgsave_status |
ok なら最後のRDB保存は成功している |
rdb_last_save_time |
最後に保存できた時刻(UNIX時間) |
rdb_changes_since_last_save |
最後の保存から何回変更があったか |
aof_enabled |
1 ならAOFが有効 |
aof_last_write_status |
ok ならAOFへの書き込みは成功している |
aof_last_bgrewrite_status |
ok なら最後のAOF書き直しは成功している |
設定値は CONFIG GET で確認できます。
redis-cli CONFIG GET save
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
ls -lh /var/lib/redis/dump.rdb /var/lib/redis/appendonlydir/
保存に失敗している場合は、Redisのログ(Ubuntuでは /var/log/redis/redis-server.log)に理由が出ます。よくある原因は、ディスクの空き不足、dir にRedisの実行ユーザーが書き込めないこと、メモリ不足で子プロセスを作れない(fork できない)ことです。RDBの保存とAOFの書き直しは子プロセスで行うため、Linuxでは vm.overcommit_memory = 1 を設定するよう、Redisが起動時のログで警告することがあります。
バックアップの取り方
RDBファイルは、書き出しが終わってから一時ファイルを置き換える方式で作られるので、Redisの稼働中にコピーしてもかまいません。公式ドキュメントは、cronで1時間ごと・1日ごとにコピーを取り、古いものを削除し、1日1回は別のマシンに転送することを勧めています。
# 例: 日時付きでコピーし、7 日より古いものを削除する
sudo cp /var/lib/redis/dump.rdb /backup/redis/dump-$(date +%Y%m%d%H%M).rdb
sudo find /backup/redis -name 'dump-*.rdb' -mtime +7 -delete
AOFだけで運用している場合、書き直しの最中に appendonlydir をコピーすると、使えないバックアップになることがあります。コピーの間だけ自動の書き直しを止めます。
redis-cli CONFIG GET auto-aof-rewrite-percentage # 今の値を控える
redis-cli CONFIG SET auto-aof-rewrite-percentage 0
redis-cli INFO persistence | grep aof_rewrite_in_progress # 0 になるまで待つ
sudo tar czf /backup/redis/aof-$(date +%Y%m%d%H%M).tar.gz -C /var/lib/redis appendonlydir
redis-cli CONFIG SET auto-aof-rewrite-percentage 100 # 控えた値に戻す
Redis 8.10以降には、書き込みを止めずにバックアップを作る BACKUP コマンド群もあります。使っているバージョンの公式ドキュメントで確認してください。
AOFが壊れたとき
書き込み中のクラッシュやディスク不足で、AOFの末尾が途中で切れることがあります。既定の aof-load-truncated yes では、Redisは最後の不完全なコマンドを捨てて起動し、ログに警告を残します。
ファイルの途中が壊れている場合は起動できません。AOFのファイルをコピーして残してから、redis-check-aof で確認します。--fix は、壊れた位置からファイルの終わりまでを捨てることがあるので、まず --fix なしで実行して壊れた位置を確かめてください。
sudo cp -a /var/lib/redis/appendonlydir /root/appendonlydir.bak
redis-check-aof /var/lib/redis/appendonlydir/appendonly.aof.manifest
まとめ
- RDBは定期的なスナップショット、AOFは変更の追記ログ。データを守りたいなら両方を有効にする
- RDBは
save 秒数 変更回数、AOFはappendonly yesとappendfsync everysecが基本 - RDBで動いているサーバーをAOFに切り替えるときは、
CONFIG SET appendonly yesで稼働中に切り替え、書き直しの完了を待ってからCONFIG REWRITEで設定ファイルに残す INFO persistenceで保存と書き込みの成否を確認する- RDBは稼働中にコピーしてよい。AOFは自動の書き直しを止めてからコピーする
関連記事: