ブログ | 2026年8月6日

実績のある 8 つの手法による MySQL データベースのバックアップ方法

MySQLデータベースのバックアップは、ハードウェア障害、ランサムウェア、人為的ミスによるデータ損失を防ぐために不可欠です。本ガイドでは、全バックアップ、増分バックアップ、ホットバックアップ、コールドバックアップといったすべてのバックアップ種別、実践可能な8つの手法、信頼性の高いバックアップ戦略を構築するための専門家のベストプラクティスを解説します。

By: Emma

MySQLデータベースのバックアップは、ハードウェア障害、人為的ミス、サイバー脅威からデータを守るために不可欠です。この記事では基本的なコマンドラインツールから高度なエンタープライズ向けソリューションまで複数の手段を紹介し、用途に合った方式を選択できるように解説します。MySQLではダウンタイムとデータ損失を最小限に抑えるため、定期的なバックアップとポイントインタイムリカバリ（PITR）を組み合わせることが推奨されています。

MySQLバックアップの種類を理解する

自環境に最適な戦略を選ぶためには、各バックアップ方式の技術的な違いを把握する必要があります。それぞれバックアップ速度、ストレージコスト、リカバリ時間のバランスが異なります。

フルバックアップ：データベースインスタンス全体の完全なコピーです。リカバリの基礎となりますが、最も多くのストレージと時間を消費します。
増分バックアップ：前回のバックアップ（フルまたは増分）以降に変更されたデータのみを取得します。バックアップは高速ですが、フルバックアップとその後のすべての増分データを適用するため、復元に時間がかかります。
差分バックアップ：前回のフルバックアップ以降に変更されたデータを取得します。フルバックアップと最新の差分ファイルのみを使用するため、増分バックアップの連鎖より復元が高速です。
トランザクションログバックアップ：MySQLではバイナリログを利用します。ポイントインタイムリカバリ（PITR）に不可欠で、特定の秒までデータを復元しデータ損失を最小限に抑えられます。
ホットバックアップ：データベースが完全に稼働し読み書きトラフィックを処理している状態で実行します。テーブルをロックせずデータの一貫性を確保するため、Percona XtraBackupやMySQL Enterprise Backupなどの専用ツールが必要です。
コールドバックアップ：MySQLサービスを完全に停止した状態で実行します。生ファイルをコピーする単純な手法ですが、計画的なダウンタイムが発生します。
論理バックアップ：mysqldumpなどを使用し、CREATE TABLE、INSERT INTOといったSQL文としてデータを出力します。MySQLのバージョンをまたいで移植できますが、データベースがSQL文を再実行するため復元速度は遅くなります。
物理バックアップ：ディスク上の実際のデータベース生ファイルをコピーします。復元速度が最速ですが、基本的にMySQLバージョンやOSに依存します。

MySQLデータベースのバックアップ手順（各種手法）

基本概念を理解した上で、具体的なツールと戦略を用いたMySQL環境のバックアップ方法を見ていきます。以下の手法は標準のコマンドラインユーティリティから高度なエンタープライズソリューションまでを対象としています。

一般的な手法から専門的な手法へ順に記載していますので、自身のインフラとRTO、RPOなどのリカバリ目標に合った運用方法を選択できます。

手法1：mysqldumpによるバックアップ（最も一般的）

mysqldumpはMySQLに標準搭載されている論理バックアップツールです。データベースを再構築するためのCREATE、INSERTコマンドを含むSQLスクリプトを生成します。

手順ガイド：

単一データベースのバックアップ：

特定のデータベースをバックアップするには下記コマンドを実行します。MySQLデータを安全にバックアップする基本的な方法です。

mysqldump -u [username] -p [database_name] > backup.sql

InnoDB向け（ロックなし）：

mysqldumpは既定でテーブルをロックします。InnoDBテーブルの場合は–single‑transactionを使用し、書き込みをブロックせずに一貫性のあるバックアップを取得します。

mysqldump -u [username] -p --single-transaction --quick [database_name] > backup_innodb.sql

全データベースのバックアップ：

mysqldump -u [username] -p --all-databases > full_server_backup.sql

データベースの復元

mysql -u [username] -p [database_name] < backup.sql

メリット：

標準搭載・無料：追加インストール不要
移植性：SQL形式によりバージョンやOSをまたいで利用可能
柔軟性：オプション引数により特定テーブルのみバックアップやデータ除外が容易

デメリット：

復元が低速：SQL文をすべて再実行するため物理バックアップより復元時間が長い
パフォーマンスへの影響：バックアップ実行時にCPU使用率が高くなる場合がある
ロックの問題：–single‑transactionなど適切なオプションを使用しない場合、MyISAMテーブルをロックしアプリケーションを停止させる可能性がある

適した用途：

小規模～中規模データベース（通常50GB未満）、開発環境、異なるサーバー間のデータ移行時。

手法2：バイナリログによる増分バックアップとPITR

フルバックアップが特定時点（例：午前2時）のデータを保存するのに対し、バイナリログ（binlogs）はそれ以降に発生したデータベースのすべての変更を記録します。ポイントインタイムリカバリ（PITR）にはバイナリログが不可欠で、クラッシュや人為的ミスの直前の秒までデータベースを復元可能にします。

手順ガイド：

バイナリロギングを有効化：

MySQL設定ファイル（my.cnfまたはmy.ini）を確認し、[mysqld]セクションに下記の記述を追加した後サービスを再起動します。

[mysqld]

log_bin = /var/log/mysql/mysql-bin.log

server_id = 1

expire_logs_days = 7 #7日より古いログを自動削除

一貫性のあるスナップショットを作成：

手法1でフルバックアップを取得する際、現在のバイナリログ位置を記録します。mysqldumpに–master‑data=2オプションを指定します。

mysqldump -u root -p --all-databases --master-data=2 --single-transaction > full_backup.sql

注記：このコマンドはバックアップヘッダーにログファイル名と位置を自動的に記録します。増分復元の開始点として重要な情報です。

バイナリログファイルをバックアップ：

バイナリログはディスク上の物理ファイルです。クラウドストレージや別ディスクなど安全な場所へ単純にコピーします。

rsync -av /var/log/mysql/mysql-bin.* /backup/location/

ポイントインタイムリカバリを実行：

復元時はまずフルバックアップを読み込み、続いてmysqlbinlogユーティリティを使用し特定時点までの変更を再生します（例：午前10時のDROP TABLE事故の直前まで）。

# 1.フルバックアップを復元

mysql -u root -p < full_backup.sql

# 2.特定時刻までbinlogを再生

mysqlbinlog --stop-datetime="2023-10-27 09:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -p

メリット：

データ損失を最小化：障害発生の数秒前まで復元可能（低いRPO）
効率性：繰り返しフルバックアップを実行するよりログのバックアップは高速でストレージ消費が少ない
監査：誰がいつデータを変更したかログから確認可能

デメリット：

複雑さ：復元はフルバックアップ＋ログ再生の複数ステップとなりDBAの知識が必要
依存関係：連鎖するバイナリログファイルのいずれかが破損または削除されると、それ以降のデータを復元できない
ストレージ管理：負荷の高いサーバーではログが急速に増大するためディスク使用量の監視が必要

適した用途：

1時間のデータ損失も許容できない基幹本番環境（ECサイト、銀行系アプリケーションなど）。

手法3：Percona XtraBackup（ホット物理バックアップ）

データベースが50GBを超える規模になると、mysqldumpのような論理バックアップは処理速度が遅くなります。Percona XtraBackupは物理バックアップ向け業界標準のオープンソースツールです。論理出力とは異なり、サーバー稼働中にディスク上の実データファイルをコピーします。InnoDBテーブルのトランザクション一貫性を保つホットバックアップ技術により、ダウンタイムなしでデータベースをバックアップできる効率的な手段として広く利用されています。

手順ガイド：

Percona XtraBackupのインストール：

MySQLのバージョンに合ったバージョンをインストールします（例：MySQL 8.0にはXtraBackup 8.0）。

sudo apt-get install percona-xtrabackup-80

フルバックアップを作成：

下記コマンドを実行し、データファイルを対象ディレクトリへコピーします。

xtrabackup --backup --target-dir=/data/backups/full --user=root --password=your_password

バックアップの準備（重要ステップ）：

手順2でコピーした生ファイルはコピー実行中にデータベースが書き込みを行うため一貫性がありません。redoログをデータファイルに適用するprepare処理を実行する必要があります。この手順を省略すると復元データが破損する可能性があります。

xtrabackup --prepare --target-dir=/data/backups/full

データベースを復元：

復元時はMySQLサービスを停止し、データディレクトリを空にした後、準備済みのファイルをコピーバックします。

systemctl stop mysql

rm -rf /var/lib/mysql/*

xtrabackup --copy-back --target-dir=/data/backups/full

#権限修正（必須）

chown -R mysql:mysql /var/lib/mysql

systemctl start mysql

メリット：

高速：SQL実行ではなく生ファイルコピーのためバックアップと復元がmysqldumpより大幅に速い
ノンブロッキング：InnoDBに対し真のホットバックアップを実行、テーブルロックやアプリケーションの中断が発生しない
高度な機能：圧縮、暗号化、他サーバーへのストリーミングバックアップに対応

デメリット：

インストールが必要：MySQL標準ツールではなくPercona製のサードパーティツール
OSレベルアクセスが必要：サーバーへのシェルアクセスを要し、MySQLクライアントだけでは実行不可
バージョン依存：XtraBackupのバージョンをMySQLサーバーのバージョンと厳密に合わせる必要がある

適した用途：

大規模エンタープライズデータベース（50GB～TBクラス）、ダウンタイムを許容できない高負荷本番サーバー、高速なRTOが求められる環境。

手法4：MySQL Enterprise Backup

厳格なコンプライアンス環境で運用する組織、またはMySQL商用版を利用する場合、MySQL Enterprise Backupが公式ソリューションとなります。Percona XtraBackupと同様のホットバックアップ機能を備え、Oracleによる公式サポートとMySQLエコシステムとの深い統合が得られます。ベンダーの直接サポートを受けながらMySQLデータベースをバックアップできる信頼性の高い手段です。

手順ガイド：

インストールと設定：

前述のオープンソースツールと異なり商用ライセンスが必要です。Oracle Software Delivery Cloudからパッケージをダウンロードし、バックアップコマンドラインツールがインストールされていることを確認します。

mysqlbackup --version

フルバックアップを実行：

mysqlbackup --defaults-file=/etc/my.cnf --user=root --password=secret --backup-dir=/data/backups/full backup-and-apply-log

ヒント：backup‑and‑apply‑logオペレーションの使用を強く推奨します。バックアップ実行と同時にファイルのprepare（トランザクションログ適用）を行い、即座に復元可能なバックアップを作成します。

増分バックアップを実行：

Enterprise Backupは変更されたページを追跡する効率的な増分バックアップに対応します。

mysqlbackup --defaults-file=/etc/my.cnf --incremental --incremental-base=dir:/data/backups/full --backup-dir=/data/backups/inc backup

データベースを復元：

復元時はサーバーを停止しcopy‑backコマンドを使用します。

systemctl stop mysqld

mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/data/backups/full copy-back

chown -R mysql:mysql /var/lib/mysql

systemctl start mysqld

メリット：

ベンダーサポート：Oracle直接のサポートが受けられ、企業SLAやコンプライアンス上必須となる場合が多い
GUI統合：MySQL Workbench、MySQL Enterprise Monitorとネイティブ連携し、コマンドラインを使わずGUIからバックアップ管理が可能
クラウド対応：AWS S3などクラウドオブジェクトストレージやテープドライブへ直接ストリーミングバックアップする機能を標準搭載
圧縮・暗号化：高度に最適化された圧縮アルゴリズムによりストレージコストを大幅に削減

デメリット：

コスト：有料のMySQL Enterprise Editionライセンスが必要、無料ソフトウェアではない
互換性：MySQL Enterprise Edition向けに設計されており、MariaDBやPercona Serverでは機能が制限または利用不可となる場合がある

適した用途：

認証済みソフトウェア、24時間365日ベンダーサポート、MySQL Enterpriseエコシステムとのシームレスな連携を必要とする大企業、金融機関、政府機関。

手法5：ファイルシステムスナップショット（LVM/ZFS）

標準的なコピーベースのバックアップに数時間を要するTBクラスの巨大データセットを扱う場合、LVMまたはZFSを利用したファイルシステムスナップショットが有効です。ファイルを一つずつコピーする代わりに、OSのストレージレイヤーを利用しファイルシステムの仮想的な「凍結」イメージを作成します。データベースサイズに関わらず数秒で完了する、物理的なMySQLバックアップの高速な手法の一つです。

手順ガイド：

データベースの準備（ロック）：

スナップショットの一貫性を確保するため、データベースファイルを安定した状態にします。コマンドラインセッションを開きグローバルリードロックを実行します。

FLUSH TABLES WITH READ LOCK;

LVMスナップショットを取得：

最初のターミナルはロックを保持したまま、別のターミナルウィンドウを開きます。Logical Volume Manager（LVM）を使用しスナップショットを作成します。

#構文：lvcreate -L [サイズ] -s -n [スナップショット名] [元ボリュームパス]

lvcreate -L 10G -s -n mysql_backup_snap /dev/vg0/mysql_data

データベースのロック解除：

スナップショットコマンドが完了したら（通常即時）、最初のターミナルに戻りロックを解除します。アプリケーションは再び完全に書き込み可能になります。

UNLOCK TABLES;

マウントとアーカイブ：

スナップショットは凍結された参照イメージです。データを保護するためマウントし、ファイルをリモート先へコピーします。

mount /dev/vg0/mysql_backup_snap /mnt/snapshot

tar -czf /backup/location/mysql_backup.tar.gz /mnt/snapshot

#後始末

umount /mnt/snapshot

lvremove /dev/vg0/mysql_backup_snap

メリット：

ほぼ瞬時：スナップショット作成は数秒で完了し、ロック時間（ダウンタイム）を極小に抑えられる
パフォーマンス低下なし：mysqldumpや圧縮ツールと異なり、スナップショット作成時のCPU・I/O消費はほとんど発生しない
完全な複製：データディレクトリ全体のバイナリ的に一貫した物理コピーを作成

デメリット：

root権限必須：OSレベルでsudoまたはroot権限が必要、システム管理者権限のないDBAは利用不可
復元が複雑：ボリュームのアンマウントやファイルコピーバックを伴うため、初心者には単純なSQLインポートよりリスクがある
依存関係：スナップショットを別の場所へコピーする前に元の物理ディスクが故障すると、運用データとスナップショットの両方を失う

適した用途：

メンテナンスウィンドウの最小化が最優先の超大規模データベース（VLDB）、または本番データベースをステージング環境へ迅速にクローンする場面。

手法6：レプリケーションを利用したバックアップ

高負荷環境では、最適化されたバックアップスクリプトでもプライマリサーバーのパフォーマンス低下（レイテンシ）を引き起こす場合があります。レプリケーションベースの戦略では、本番データをリアルタイムでミラーリングするセカンダリMySQLサーバー（レプリカ）を構築し、バックアップ処理をこのセカンダリサーバー上で実行します。これにより本番プライマリサーバーはバックアップ中の負荷やロックの影響を一切受けません。

手順ガイド：

レプリケーション状態を確認：

バックアップ前にレプリカがプライマリに完全に追いついていることを確認します。レプリカサーバーのコマンドラインにログインします。

SHOW REPLICA STATUS\G

レプリケーションを一時停止：

バックアップ中にデータが変更されないよう、レプリケーションのSQLスレッドを停止します。これによりレプリカは新しい更新に対し「凍結」した状態になりますが、マスターとの接続は維持されます。

STOP REPLICA SQL_THREAD;

バックアップを実行：

データが静的になったので、レプリカサーバー上で任意のバックアップ手法（mysqldumpまたはxtrabackupなど）を実行します。

#レプリカ上でmysqldumpを使用する例

mysqldump -u [username] -p --all-databases > /backup/replica_backup.sql

レプリケーションを再開：

バックアップ完了後、レプリケーションスレッドを再起動します。レプリカはバックアップ期間中にマスターで発生したすべての変更を自動的に取得・適用します。

START REPLICA SQL_THREAD;

メリット：

本番環境への影響ゼロ：プライマリマスターサーバーはバックアップの圧縮やI/Oによるパフォーマンス影響を受けずユーザーにサービスを提供
高速なリカバリ：障害発生時、ファイルを復元する代わりにレプリカを即座に新しいマスターに昇格（フェイルオーバー）可能な場合が多い
柔軟性：レプリカ側では速度の重要度が低いため、強い圧縮や処理時間の長いバックアップ手法を利用できる

デメリット：

「レプリケーション＝バックアップではない」（DBAの重要な注意点）：マスター上で誤ってDROP TABLEを実行すると、そのコマンドは瞬時にレプリカへレプリケートされ両方のサーバーのデータが削除されます。レプリカからオフラインバックアップを取得する運用が依然必要です。
コスト：2台目のサーバーの費用と保守が必要
複雑さ：レプリケーションの健全性を管理する必要があり、レプリケーションが切断されるとバックアップが古くなる可能性がある

適した用途：

プライマリサーバーのパフォーマンス低下を一切許容できない24時間365日稼働の高可用アプリケーション、または災害復旧（DR）サイトを構築する組織。

手法7：GUIツール（phpMyAdmin/Workbench）

すべての管理者がコマンドラインインターフェースに慣れているわけではありません。初心者や簡易な共有ホスティング環境を管理する場合は、GUI（グラフィカルユーザーインターフェース）ツールがクリック操作でMySQLデータをバックアップする手段を提供します。代表的なツールは公式デスクトップクライアントのMySQL WorkbenchとWebベースのphpMyAdminです。

手順ガイド：

MySQL Workbench（公式デスクトップツール）

データエクスポートを開く：Workbenchを起動しサーバーに接続。左側ナビゲーターパネルからData Exportをクリック。
データベースを選択：保護対象のデータベースにチェックを入れる。
オプション設定：Self‑Contained Fileへエクスポートを選択（単一の.sqlファイルを作成）。
エクスポート実行：Start Exportをクリック。プログレスバーで状況を確認。

phpMyAdmin（Webベース）

データベース選択：ログインし、左サイドバーのデータベース名をクリック。
エクスポートタブを開く：上部メニューバーのExportボタンをクリック。
エクスポート方式選択：Quick：基本的なバックアップに適します。
実行：Goをクリック。ブラウザからSQLファイルがローカルPCにダウンロードされます。

手法8：集中型自動MySQLバックアップソリューション

手動スクリプトや個別ツールの管理が複雑になるエンタープライズ環境では、i2Backupのような集中型自動プラットフォームが理想的なソリューションとなります。

i2Backupは物理、仮想、クラウド環境にまたがる構造化・非構造化データを扱うプロ向けデータ保護プラットフォームです。バラバラなバックアップタスクを脱却し、最新の分散アーキテクチャによる「設定したら放置」の統一された運用フローを実現します。

i2Backupの主な機能

集中管理：使いやすいB/S Webインターフェースにより、ITチームは単一画面からすべてのMySQLバックアップタスクのスケジュール設定と制御が可能
リアルタイム・スケジュールデータベース保護：MySQLをはじめ各種データベースに対応し、スタンドアロンインスタンスとクラスタ環境（HA、RACなど）の両方をサポート
多層的なセキュリティ：サイバー攻撃や不正アクセスから守るためWORM（一度書き込み多数読み取り）準拠ストレージを利用し、バックアップをイミュータブル（改変不可）に
柔軟なリカバリオプション：テーブル単位復元、ファイルレベルリカバリ、元の場所または全く別のデータベースホスト・物理サーバーへの復元を含む高速リカバリを提供
幅広いストレージ・プラットフォーム対応：Windows、Linux、Unixに完全互換。ローカルディスク、テープライブラリ、NAS、オブジェクトストレージ、S3クラウドストレージなど多様なメディアへデータを保存可能

メリット：