Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
リストアを実施する前に、自身のバックアップファイル形式を把握する必要があります。MySQLのバックアップは論理バックアップ（SQLスクリプト）と物理バックアップ（生データファイル）の2種類に大別されます。ファイル形式に適していないリストア手法を使用するとエラーが発生する、最悪の場合データが静かに破損する恐れがあります。
| ファイル種別 | 作成ツール | 適した用途 | リストア方法 |
|---|---|---|---|
| .sql / .dump | mysqldump、mysqlpump | 環境移行、中小規模データベース | MySQLコマンドライン |
| .sql.gz | mysqldump＋圧縮 | 大規模データベース、遠隔転送 | 解凍後インポート |
| .ibd | InnoDBストレージエンジン | 単一テーブル復旧 | 手動ファイル置き換え |
| .ibdata | InnoDBストレージエンジン | InnoDBシステムテーブルスペース全体の復旧 | 手動ファイル置き換え |
| .frm | MySQL 5.7以前 | テーブル構造メタデータ | 手動ファイル置き換え |
| .MYD / .MYI | MyISAMストレージエンジン | MyISAMテーブルのデータ・インデックス復旧 | 手動ファイル置き換え |
CREATE TABLE、INSERT INTOなどのSQL文が記録されており、データベースを最初から再構築できます。可読性に優れ転送が容易で、複数のMySQLバージョン間で互換性があります。SQLダンプファイルは最も普及しているMySQLバックアップ形式です。可搬性が高く人間が読めるテキストで、大半のMySQLバージョンに対応しているため、環境移行や定時リストアの標準手段として採用されています。
事前作業：多くのダンプファイルにはCREATE DATABASE文が含まれていません。リストア先のデータベースが存在しない場合は事前に作成してください：
CREATE DATABASE your_database_name;
mysqlコマンドラインクライアントを使用し、ファイルをリストア先DBに直接パイプで渡します：
mysql -u username -p database_name < backup.sql
パスワード入力を求められた後、MySQLはファイル内のすべてのSQL文を実行し、テーブルとデータを再作成します。
.dumpファイルは拡張子以外、.sqlファイルと構造が完全に同一です。実行するコマンドも同じです：
mysql -u username -p database_name < backup.dump
大容量データベースの場合は容量削減のため.sql.gz形式で保存されることが多いです。事前にファイルを解凍せず、1ステップでMySQLにパイプ出力可能です。
Linux / macOS：
gunzip < backup.sql.gz | mysql -u username -p database_name
Windows（PowerShell）：
cmd /c "gunzip -c backup.sql.gz | mysql -u username -p database_name"
よくあるトラブル
ALL PRIVILEGES権限を保有しているか確認してください。max_allowed_packet値を拡大してください。SET FOREIGN_KEY_CHECKS=0;、末尾にSET FOREIGN_KEY_CHECKS=1;を追記してください。物理データファイル（フラットファイルまたはコールドバックアップと呼ばれることもある）はMySQLがディスクにデータを保存する生バイナリファイルです。SQLダンプの実行よりリストア速度が速い一方、ファイル権限とバージョン互換性に細心の注意を払う必要があります。
この手法は下記のシナリオに最適です：
/var/lib/mysqlディレクトリ全体のシステムバックアップまたはスナップショットから復旧する場合手順を順番に実行してください。ファイル配置や所有者設定のミスが物理リストア失敗の最大要因となります。
手順1：MySQLサービスを停止
MySQL稼働中にデータファイルを移動・置き換えてはいけません。未完了の書き込みによりファイル破損が発生するリスクがあります。
sudo systemctl stop mysql手順2：データベースファイルを置き換え
バックアップファイルをMySQLデータディレクトリにコピーします：
/var/lib/mysql C:\ProgramData\MySQL\MySQL Server X.X\Data手順3：ファイル権限を調整
Linux環境では、データディレクトリ内のすべてのファイルの所有者をmysqlユーザーに統一する必要があります。この手順が最も見落とされやすいポイントです。
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod -R 750 /var/lib/mysql
Windowsは権限管理方式が異なるため、MySQLサービスアカウントがデータフォルダに読み書き権限を持っていれば追加設定は不要です。
手順4：MySQLを再起動
サービスを起動し、エラーが出力されないか確認します。
sudo systemctl start mysqlsudo journalctl -u mysqlコマンドで確認可能です。テーブルスペース不整合や権限の問題はここに出力され、重大な障害に発展する前に検知できます。データの完全性を確認して初めてリストア作業が完了します。検証を省略すると、DB自体は起動していてもテーブル欠損やレコード破損によりアプリケーションがクラッシュする、静的な障害が発生する恐れがあります。
手順1：データベース構造の確認
想定するすべてのテーブルが再作成されたか確認します。MySQLシェルにログインし下記コマンドを実行：
USE your_database_name;
SHOW TABLES;
出力結果を元のスキーマまたは仕様書と照合します。テーブルが欠けている場合はインポート処理が途中で中断した可能性が高いです。
手順2：テーブルのレコード件数確認
リストアが途中停止した場合、テーブルは存在してもレコードが空になるケースがあります。重要なテーブルのレコード数を確認します：
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;
max_allowed_packet制限が原因です。手順3：データ完全性の抜き取り検証
最新更新レコードに対してクエリを実行し、データが正常に読み取れるか確認します：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 5;
文字化けが発生していないか確認してください。異なるOSやMySQLバージョン間でファイルを移行する際、文字コードの不整合がよく発生する問題です。
手順4：アプリケーション接続テスト
アプリケーションまたはWebサーバーを再起動し、ログイン、ダッシュボード表示、レポート出力など基本的な操作を実行します。これによりアプリがDBに接続し、正常にクエリを実行できることを確認できます。
HOST値を確認してください。'user'@'localhost'で定義されたユーザーは外部ホストからの接続に対応しないため、アプリが別ホストから接続する場合は'user'@'%'を使用してください。手動のリストア手順は実行可能ですが、障害発生時に完全かつ正常なバックアップファイルが用意されていることが前提となります。実運用では臨時バックアップの作成を忘れやすく、検証も難しいため、実際に復旧が必要なタイミングで不完全なバックアップしか存在しないケースが多発します。専用のバックアップソリューションを導入することで、スケジューリングからリカバリまで一連の処理を自動化し、この不安を解消できます。
i2Backupはエンタープライズ向けバックアッププラットフォームで、視覚的なWebコンソールからMySQLデータベースのバックアップとリストアを実行可能です。物理サーバー、仮想マシン、クラウド環境に対応し、すべてを単一画面で統合管理できます。
本ガイドの手順で手動によるMySQLリストアを完全に制御できます。しかし確実なリカバリ体制は障害発生以前から、一貫性のある検証済みバックアップを作成することで構築されます。i2Backupはこの基盤を自動化するため、復旧作業が必要になった際に慌てることなくスムーズに処理を実施できます。
Q1：Windows上のデータファイルからMySQLデータベースを復旧する方法は？
services.mscからMySQLサービスを停止します。.ibd、ibdata1、.frmファイルをC:\ProgramData\MySQL\MySQL Server X.X\Dataにコピーし、MySQLサービスアカウントが新規ファイルに完全な読み書き権限を保有していることを確認後、サービスを再起動します。
Q2：バイナリログからMySQLをリストアする方法は？
mysqlbinlogユーティリティでログファイルをSQL文に変換し、MySQLにパイプ出力します：
mysqlbinlog binlog.000001 | mysql -u username -p
バイナリログによる復旧は完全バックアップに追加して実施する手法です。必ずベースとなるバックアップを先にリストアした後、binlogを再生して障害発生時点までの変更を復元してください。
Q3：dataフォルダのファイルを使用してMySQLをリストアする方法は？
MySQLをシャットダウンし、DBフォルダをdataディレクトリに移動します。ibdata1はテーブルファイルと同一のバックアップから取得する必要があります。Linux環境では再起動前にchown -R mysql:mysqlでファイル所有者を再設定してください。
Q4：.sqlダンプファイルから単一テーブルのみリストアできますか？
一時的なステージングDBにダンプ全体をリストアした後、必要なテーブルのみ出力します：
mysqldump -u username -p staging_db table_name > single_table.sql
mysql -u username -p target_db < single_table.sql
Q5：「テーブルが既に存在する」エラーが発生した場合はどうすれば良い？
インポート前にリストア先DBを削除し再作成します：
DROP DATABASE your_database_name;
CREATE DATABASE your_database_name;
MySQLデータベースのリストアの鍵はバックアップ形式の把握です。SQLダンプファイルはmysqlコマンドラインで簡単にインポート可能です。物理データファイルは大容量データのリストア速度が速い反面、ファイル権限とテーブルスペースの整合性に厳格な管理が求められます。いずれの手法においても、アプリケーションの接続先をDBに戻す前に必ずリストア結果を検証してください。
リカバリ手順の検証は実際に障害が発生する前に実施するのが最善です。i2Backupのような専用ソリューションを活用しMySQLバックアップを自動化することで、常に正常かつ検証済みのリストアポイントを確保できます。
