DBAtlas · データベース運用アトラス

Percona XtraBackup によるバックアップ、リストア、PITR

MySQLレベル: 中級所要時間: 45–90 分

Percona XtraBackup による物理バックアップです。対応する XtraBackup バージョンのインストール、auth_socket を使うバックアップユーザー、圧縮/暗号化付きのフル + 増分バックアップスクリプト、systemd timer または cron によるスケジュール、binlog のコピー、リストア訓練までを扱います。シナリオカードでは、フルリストア、増分チェーンからのリストア、特定時点への復旧 (PITR)、単一テーブルのリストア、バックアップからのレプリカ構築、別サーバーへのリストアを行います。大規模データベースの日次バックアップと障害復旧にはこのガイドを、移行、単一スキーマ/テーブルのダンプ、バージョン間の移行には論理バックアップ (mysqldump / MySQL Shell) のガイドを使います。

構成: サーバー 1 台 (単体サーバー、source、replica、InnoDB Cluster の secondary のいずれか)。バックアップ領域はローカルディスクまたは NFS

シナリオ

  • バックアップを構築し、スケジュールし、リストアを試す (全手順) — XtraBackup のインストール、バックアップユーザー、フル + 増分バックアップスクリプト、スケジュール、リストア訓練 (PITR を含む)。初めて構築する場合はこれを選びます。バックアップはサーバー稼働中に取得します。ダウンタイムはなく、ディスク/CPU 負荷が増えるだけです。
  • フルリストア: 最新のフルバックアップに戻す — データディレクトリが失われた/破損した、またはサーバーが起動しない場合です。チェーンのフルバックアップに戻せば十分です。リストアの間、MySQL は停止しています。
  • フル + 増分チェーンからのリストア (最新の増分まで) — 最新の増分バックアップ (または任意の増分) の時点に戻したい場合です。フルバックアップの上に増分を --apply-log-only で順番に適用します。リストアの間、MySQL は停止しています。
  • 特定時点への復旧 (PITR): 誤った DELETE / DROP の直前へ — 誤って削除または破損したデータの復旧です。最新のバックアップをリストアし、binlog を問題のトランザクションの直前まで (時刻、位置、GTID のいずれかで) 適用します。リストアの間 MySQL は停止し、問題発生後の書き込みもすべて失われます。影響が 1 テーブルだけなら、先に単一テーブルのシナリオを検討してください。
  • 単一テーブルをリストアする (--export + IMPORT TABLESPACE) — 1 つのテーブルのバックアップ時点の内容だけが必要な場合です。サーバー全体をリストアせず、テーブルをバックアップから t_restore という名前でインポートし、そこからデータを修正します。サーバーは稼働したままです。
  • バックアップから新しいレプリカを構築する — 新しい (または再構築する) レプリカを、ネットワーク経由の clone ではなく既存の XtraBackup バックアップから準備し、source に接続したい場合です (大容量データ、source の負荷)。source には影響しません。ターゲットサーバーのデータは置き換えられます。
  • バックアップを別サーバーにリストアする (移行、テスト、クローン) — 本番バックアップをテスト/開発サーバーで開く、サーバーを移行する、あるいはバックアップが本当にリストアできるかを別サーバーで確認したい場合です。ソースサーバーには影響しません。

開始前の確認

  • MySQL … が稼働していること (DBAtlas の MySQL 単体サーバー構築 ガイドで構築した場合はパスも同じです)。OS の root ユーザーが mysql コマンドでパスワードなしに接続できること (auth_socket または ~/.mylogin.cnf)。
  • バックアップディレクトリ … が別ディスク/NFS 上にあり、少なくとも (データサイズ × チェーン数) の容量があること… (zstd で通常 3～6 分の 1 に縮小されます)…。リストアには … 配下にデータサイズの 2 倍以上の空き容量が必要です (展開 + prepare)。
  • バイナリログが有効で、GTID も有効になっていること (PITR と増分の整合性のため)。
  • サーバーが HTTPS で repo.percona.com に接続できること、または社内ミラーが設定されていること。
  • 暗号化キーのコピーをサーバー外の安全な場所 (金庫、パスワードマネージャー) に保管する準備ができていること。キーを失うとバックアップは開けません。
  • リストアテスト用に、できれば別のテストサーバーを用意していること (同じ MySQL バージョン、同じ my.cnf で構築)。リストア手順は実行したサーバーのデータディレクトリを置き換えます。
  • このサーバーが正常なレプリカであること: IO スレッドと SQL スレッドが Yes で、遅延が小さいこと。binlog をコピーする場合 (PITR)、log_replica_updates が有効である必要があります (8.x ではデフォルトで有効)。無効だと、レプリカの binlog に source から来たトランザクションが含まれません。
  • このサーバーが InnoDB Cluster のメンバーで、現在 SECONDARY / ONLINE であること。バックアップはこのメンバーでスケジュールされます。将来メンバーが primary になった場合、スクリプトは警告を出したうえでバックアップを取得します。
  • リストアするバックアップチェーンが … 配下… (… サーバー上)…にそろっていること: フルと使用する増分、-lsn メタデータディレクトリを含む…。暗号化キーは ……。
  • このサーバーに MySQL … と XtraBackup … がインストールされていること。MySQL のマイナーバージョンが、バックアップを取得したサーバーと同じかそれより新しいこと (バックアップの server_version は診断ステップで表示されます)。
  • …ターゲットサーバーに残すべきデータがないこと: データディレクトリはバックアップで置き換えられます (旧ディレクトリは .old-<timestamp> として退避されます)。…メンテナンスウィンドウとアプリケーション停止が承認されていること: リストア中は MySQL が停止します。アプリケーションをこのサーバーに接続させないでください。…
  • テーブルが InnoDB で、innodb_file_per_table = ON (8.x のデフォルト) により独自の .ibd ファイルに格納されていること。バックアップ取得後にテーブル構造 (列、インデックス) が変更されていないこと。サーバーは稼働したままです。

ガイドのフェーズ

  • XtraBackup のインストール — Percona リポジトリを追加する · XtraBackup をインストールする
  • バックアップユーザーとキー — auth_socket プラグインを確認する · バックアップユーザーを作成する · 接続をテストする · 暗号化キーを作成する
  • バックアップスクリプトとスケジュール — バックアップディレクトリを作成する · バックアップスクリプトを作成する · スクリプトを実行可能にする · 最初のフルバックアップを取得する · 増分バックアップを試す · systemd サービスを作成する …
  • リストア — チェーンを作業ディレクトリにコピーする · 復号 / 展開する · フルバックアップを prepare する (apply-log-only) · 増分を順番に適用する · 最終 prepare · MySQL を停止し、既存データを退避する …
  • 特定時点への復旧 (PITR) — ターゲット時刻を特定する · binlog をターゲット時刻まで適用する · 結果を確認し、新しいバックアップを取得する
  • クリーンアップ — 退避したデータと作業ディレクトリを削除する
  • 1. 診断: どのバックアップを、どの方法で使うか — サーバーの状態とバージョンを確認する · バックアップチェーンとその内容を一覧表示する
  • 2. セーフティネット — 現在の状態と設定を記録する
  • 3. 実施: バックアップを prepare する — チェーンを作業ディレクトリにコピーする · チェーンを作業ディレクトリにコピーする · 復号 / 展開する · フルバックアップを prepare する (apply-log-only) · 増分を順番に適用する · 最終 prepare
  • 3. 実施: データをリストアする — MySQL を停止し、既存データを退避する · バックアップをデータディレクトリにコピーする (copy-back) · MySQL を起動して確認する · バックアップから戻ったレプリケーション設定を確認する
  • 3. 実施: binlog をターゲットまで適用する (PITR) — 問題のトランザクションとターゲット地点を確認する · binlog をターゲットまで適用する
  • 4. 検証 — 問題のトランザクションが取り消されたことを確認する · データを確認する
  • 5. 事後作業 — 新しいフルバックアップを取得する · 退避したデータと作業ディレクトリを削除する · 根本原因とトポロジー
  • 1. 診断: テーブルとバックアップは条件を満たしているか — テーブルの現在の状態と構造を表示する · バックアップチェーンとその内容を一覧表示する
  • 2. セーフティネット — テーブルの現在の状態をバックアップする
  • 3. 実施: --export でバックアップを prepare する — チェーンを作業ディレクトリにコピーする · 復号 / 展開する · フルバックアップを prepare する (apply-log-only) · 増分を順番に適用する · 最終 prepare (--export)
  • 3. 実施: テーブルを中間テーブルにインポートする — 中間テーブルを作成し、テーブルスペースを破棄する · バックアップからファイルをコピーしてインポートする (IMPORT TABLESPACE)
  • 4. 検証 — 中間テーブルを確認し、元のテーブルと比較する
  • 5. 事後作業: データをコピーしてクリーンアップする — 必要な行を元のテーブルにコピーする · 中間テーブルと作業ディレクトリを削除する
  • 1. 診断: ターゲットサーバーとバックアップは条件を満たしているか — ターゲットサーバーのバージョン、識別子、ディスクを確認する · バックアップチェーンとその内容を一覧表示する (…)
  • 2. セーフティネット — 現在の状態と設定を記録する
  • 3. 実施: バックアップを取得して prepare する — バックアップサーバーからチェーンを取得する · チェーンを作業ディレクトリにコピーする · 復号 / 展開する · フルバックアップを prepare する (apply-log-only) · 増分を順番に適用する · 最終 prepare
  • 3. 実施: データをリストアする — MySQL を停止し、既存データを退避する · バックアップをデータディレクトリにコピーする (copy-back) · MySQL を起動して確認する · バックアップから戻ったレプリケーション設定を確認する
  • 3. 実施: バックアップの位置からレプリケーションを開始する — 開始点を特定する · レプリケーションを設定して開始する
  • 4. 検証 — データを確認する
  • 5. 事後作業 — 退避したデータと作業ディレクトリを削除する · サーバーを新しいロールで運用に組み込む
環境に合わせた手順プランを開く →