mysqldumpによる定期バックアップを運用していると、こういう問いに直面することがあります。
この記事では、MySQLのバイナリログ（binlog）を有効化し、mysqldumpのフルバックアップと組み合わせて特定時点に復元する手順を解説します。my.cnfへの設定追加からmysqlbinlogコマンドの実行まで、RHEL 9系／Ubuntu 24.04 LTSを想定環境として説明します。
この記事のポイント
・フルバックアップ（mysqldump）＋binlogで任意の時点に復元できる
・my.cnfにlog_binを追加するだけでbinlogが有効になる
・mysqlbinlogの--stop-datetimeで誤操作直前の時刻を指定して復元する
・binlog_expire_logs_secondsで自動削除の日数を設定する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜmysqldumpだけでは不十分なのか
mysqldumpによる定期バックアップは、前日夜中のスナップショットを保存するのに適しています。ただし、前回バックアップ以降に発生した変更は含まれません。
「WHERE句を忘れた全件UPDATE」「誤ったテーブルへのDELETE」といった操作ミスは、前回のフルバックアップ取得後に起きることがほとんどです。
この場合、mysqldumpだけでは「直前の状態」には戻れません。
MySQLのバイナリログ（binlog）はデータ変更を時系列で記録するログです。フルバックアップ取得後から誤操作の直前までの変更を再生できます。
フルバックアップとbinlogを組み合わせることで、誤操作の直前の状態に復元することが可能になります。これがポイントインタイムリカバリー（PITR）と呼ばれる手法です。
バイナリログを有効にする
MySQLのバイナリログはバージョンによってデフォルト設定が異なります。まず現在の状態を確認してから設定を進めてください。
1. 現在のbinlog状態を確認する
MySQLにログインして以下のSQLを実行してください。mysql -u root -p
SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | OFF | +---------------+-------+
2. my.cnfにbinlogの設定を追加する
設定ファイルを編集します。RHEL 9系は /etc/my.cnf、Ubuntu 24.04 LTSは /etc/mysql/mysql.conf.d/mysqld.cnf が対象です。作業前に設定ファイルのバックアップを取ってから編集してください。
# RHEL 9系の場合 cp /etc/my.cnf /etc/my.cnf.bak vi /etc/my.cnf # Ubuntu 24.04 LTSの場合 cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.bak vi /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld] log_bin = /var/lib/mysql/mysql-bin binlog_format = ROW binlog_expire_logs_seconds = 604800
・log_bin：binlogファイルの保存先とプレフィックスを指定します
・binlog_format：ROWは行レベルで変更を記録します。STATEMENTより確実に変更を再生できます
・binlog_expire_logs_seconds：604800秒（7日間）経過したbinlogを自動削除します
3. MySQLを再起動して有効化を確認する
設定を追加したらMySQLを再起動します。# RHEL 9系 systemctl restart mysqld # Ubuntu 24.04 LTS systemctl restart mysql
SHOW VARIABLES LIKE 'log_bin'; SHOW BINARY LOGS;
+---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000001 | 180 | No | +------------------+-----------+-----------+
フルバックアップを取得する
binlogと組み合わせて使うフルバックアップには、--single-transactionと--master-dataオプションが必要です。・--single-transaction：トランザクション整合性を保ったままInnoDBをダンプします
・--master-data=2：ダンプファイルにbinlogのファイル名と位置をコメントで記録します
以下のコマンドでバックアップを取得してください。
mysqldump \ --user=root \ --password \ --single-transaction \ --master-data=2 \ --all-databases \ > /backup/full_$(date +%Y%m%d_%H%M%S).sql
grep 'MASTER_LOG_FILE' /backup/full_20261111_020000.sql | head -3
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=4;
Linuxサーバーの運用では、このフルバックアップをcronで毎日深夜に自動実行するのが一般的です。バックアップ設計と復元操作の実践を体系的に身につけたい方は、Linux Master Pro Seminar でハンズオン形式で体験できます。
mysqlbinlogで特定時点に復元する
フルバックアップ取得後に誤操作が発生したケースを例に、復元手順を説明します。1. 誤操作の発生時刻を特定する
mysqlbinlogコマンドでbinlogの内容を確認できます。mysqlbinlog -v /var/lib/mysql/mysql-bin.000003 | grep -A 5 'UPDATE\|DELETE' | head -40
出力例（環境により異なります）：
#261111 15:23:14 server id 1 end_log_pos 1024 ... ### UPDATE `appdb`.`orders` ### WHERE ### @1=1001 /* INT meta=0 nullable=0 is_null=0 */ ### SET ### @3='deleted' /* STRING(16) meta=65040 nullable=1 is_null=0 */
復元先は「15:23:13」（誤操作の1秒前）に設定します。
2. フルバックアップを復元する
まず、フルバックアップをMySQLにインポートします。mysql -u root -p < /backup/full_20261111_020000.sql
3. mysqlbinlogで誤操作直前まで変更を再生する
フルバックアップ取得後から誤操作の直前までの変更を、mysqlbinlogコマンドで抽出してMySQLに適用します。mysqlbinlog \ --start-position=4 \ --stop-datetime='2026-11-11 15:23:13' \ /var/lib/mysql/mysql-bin.000003 \ | mysql -u root -p
・--stop-datetime：この日時の直前までの変更を再生します。誤操作の1秒前を指定してください
複数のbinlogファイルにまたがる場合は、ファイル名を並べて指定します。
mysqlbinlog \ --start-position=4 \ --stop-datetime='2026-11-11 15:23:13' \ /var/lib/mysql/mysql-bin.000002 \ /var/lib/mysql/mysql-bin.000003 \ | mysql -u root -p
4. 復元結果を確認する
対象テーブルのレコード数や内容を確認して、期待どおりのデータに戻っているかをチェックしてください。-- 対象テーブルのレコード数を確認 SELECT COUNT(*) FROM orders; -- 更新日時を確認してデータが戻っているか確認 SELECT id, status, updated_at FROM orders ORDER BY updated_at DESC LIMIT 10;
トラブルシュートとよくあるエラー
「mysqlbinlog: File 'mysql-bin.000003' not found」が出た時
binlogファイルのパスが正しいかを確認してください。MySQLにログインして現在のbinlogファイルを確認できます。
SHOW BINARY LOGS; SHOW VARIABLES LIKE 'log_bin_basename';
「ERROR 1049 (42000): Unknown database」が出た時
フルバックアップが --all-databases で取得されていない場合、特定のデータベースが存在しないエラーになることがあります。データベース名を指定してフルバックアップを取得し直してから、binlogの再生を実行してください。
復元に必要なbinlogファイルが存在しない
binlog_expire_logs_secondsで設定した期間（前述の設定例では604800秒=7日間）を超えると、binlogは自動削除されます。復元に必要なbinlogファイルが削除されていた場合、その期間への復元はできません。
binlogの保存期間はバックアップポリシーに合わせて設定してください。
ROWフォーマットのbinlogが読みにくい時
binlog_format=ROW のとき、mysqlbinlogの出力はBase64エンコードになっています。-v オプションを追加すると人が読める形式で出力されます。
mysqlbinlog -v /var/lib/mysql/mysql-bin.000003 | grep -A 10 'UPDATE\|DELETE'
まとめ
| やりたいこと | コマンド・設定 |
|---|---|
| binlogを有効にする | my.cnf の [mysqld] に log_bin = /var/lib/mysql/mysql-bin を追加 |
| 現在のbinlog状態を確認する | SHOW VARIABLES LIKE 'log_bin'; |
| binlogのファイル一覧を表示する | SHOW BINARY LOGS; |
| binlog位置を記録したフルバックアップを取得する | mysqldump --single-transaction --master-data=2 --all-databases > file.sql |
| binlogの内容を確認する | mysqlbinlog -v /var/lib/mysql/mysql-bin.000003 |
| 特定時点の直前まで変更を再生する | mysqlbinlog --start-position=N --stop-datetime='YYYY-MM-DD HH:MM:SS' binlog-file | mysql -u root -p |
MySQL／MariaDBのバックアップ設計と復元操作も含め、Linuxサーバーの実務を2日間で体系的に学ぶセミナーを開催しています。
＞＞ Linux Master Pro Seminar の詳細と日程を確認する
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：MySQLのperformance_schemaで遅いクエリとロック待ちを特定する方法｜events_statementsとwait_summaryを使った実務調査
- この記事の属するカテゴリ：データーベース管理へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます