phpmyadminでデータベースのバックアップを取る方法

2026年7月5日

phpMyAdminでデータベースのバックアップを取る場合は、基本的に 「エクスポート」機能を使ってSQLファイルを保存します。

WordPressサイト、ECサイト、会員サイト、業務システムなどで使われているMySQLやMariaDBのデータベースは、phpMyAdminからバックアップを取得できます。

ただし、phpMyAdminでバックアップできるのは、あくまで データベースの中身 です。

WordPressであれば、投稿、固定ページ、コメント、ユーザー情報、各種設定、プラグイン設定などは含まれますが、画像ファイル、テーマファイル、プラグインファイルなどは含まれません。

サイト全体を完全にバックアップしたい場合は、データベースだけでなく、サーバー上のファイルも別途バックアップする必要があります。

phpMyAdminでバックアップを取る基本手順

phpMyAdminにログインする

まず、利用しているサーバーの管理画面からphpMyAdminにログインします。

多くのレンタルサーバーでは、以下のようなメニューからphpMyAdminにアクセスできます。

サーバーパネル
コントロールパネル
データベース管理
MySQL管理
phpMyAdmin

ログインすると、画面左側にデータベース名の一覧が表示されます。

複数のWebサイトを同じサーバーで運用している場合は、データベース名を間違えないように注意してください。

WordPressサイトの場合は、wp-config.php の中にある DB_NAME の値を確認すると、対象のデータベース名を特定できます。

define( 'DB_NAME', 'database_name_here' );

この database_name_here に入っている名前が、WordPressで使用しているデータベース名です。

バックアップしたいデータベースを選択する

phpMyAdminにログインしたら、左側のメニューからバックアップしたいデータベース名をクリックします。

データベースを選択すると、右側にテーブル一覧が表示されます。

WordPressの場合、以下のようなテーブルが表示されることがあります。

wp_posts
wp_postmeta
wp_options
wp_users
wp_usermeta
wp_terms
wp_term_taxonomy
wp_term_relationships

テーブル一覧が表示されていれば、対象のデータベースを選択できています。

「エクスポート」をクリックする

データベースを選択した状態で、画面上部にある 「エクスポート」 をクリックします。

phpMyAdminのバージョンやサーバー環境によって表示は多少異なりますが、上部メニューには以下のような項目が並んでいることが多いです。

構造 / SQL / 検索 / クエリ / エクスポート / インポート / 操作

この中から 「エクスポート」 を選びます。

エクスポート方法の選び方

簡易エクスポート

phpMyAdminのエクスポート画面では、通常、エクスポート方法として 「簡易」 と 「詳細」 を選べます。

簡易エクスポートは、最低限の設定だけでデータベースをバックアップできる方法です。

一般的には、以下の設定で実行します。

エクスポート方法：簡易
フォーマット：SQL

この状態で実行すると、データベース全体をSQLファイルとしてダウンロードできます。

特別な設定が不要な場合や、簡単にバックアップを取りたい場合は、簡易エクスポートでも問題ありません。

詳細エクスポート

より安全に復元できるバックアップを取りたい場合や、サーバー移行前、本番サイトの改修前、WordPressの更新前などには、「詳細」 を選ぶのがおすすめです。

詳細エクスポートでは、以下のような項目を細かく設定できます。

エクスポートするテーブル
出力形式
圧縮の有無
テーブル構造を含めるか
データを含めるか
DROP TABLE文を追加するか
AUTO_INCREMENT値を含めるか
INSERT文の形式

重要なサイトや、後から復元する可能性があるバックアップでは、詳細設定を使ったほうが安心です。

SQLエクスポート時の重要な設定

「構造とデータ」を選ぶ

バックアップでは、基本的に 「構造とデータ」 の両方を含めます。

構造とは、テーブルの設計情報のことです。

データとは、テーブルの中に保存されている実際の内容です。

たとえばWordPressであれば、以下のような情報が該当します。

構造：wp_posts、wp_optionsなどのテーブル定義
データ：投稿内容、設定値、ユーザー情報、コメントなど

「構造のみ」を選ぶと、テーブルの設計だけが保存され、投稿や設定値などの中身は保存されません。

「データのみ」を選ぶと、テーブルの中身は保存されますが、テーブル構造が含まれません。

通常のバックアップでは、必ず 構造とデータの両方 を含めるようにしてください。

AUTO_INCREMENT値を含める

WordPressやCMS、ECサイトでは、AUTO_INCREMENT値も含めてバックアップするのがおすすめです。

AUTO_INCREMENTは、投稿ID、ユーザーID、注文IDなどの連番を管理する仕組みです。

この値が適切に保持されていないと、復元後に新しいデータを追加した際、IDの重複や不整合が起きる可能性があります。

そのため、設定項目がある場合は、AUTO_INCREMENT値を含めてエクスポートしてください。

テーブル名やカラム名をバッククォートで囲む

詳細設定の中に、テーブル名やカラム名をバッククォートで囲む設定がある場合は、有効にしておくと安心です。

バッククォートとは、以下のような記号です。

`wp_posts`
`post_title`

テーブル名やカラム名がMySQLの予約語と重なっている場合や、特殊な名前が使われている場合でも、バッククォートで囲まれていれば復元時のエラーを避けやすくなります。

複数行INSERTを有効にする

複数行INSERTは、複数のデータを1つのINSERT文にまとめる設定です。

通常は有効にして問題ありません。

複数行INSERTを使うと、SQLファイルのサイズが小さくなり、インポート処理も速くなることがあります。

ただし、非常に大きなデータベースでは、1つのINSERT文が大きくなりすぎて、インポート時にエラーが出る場合があります。

その場合は、INSERT文の分割設定や、サーバー側の max_allowed_packet などを確認する必要があります。

完全なINSERT文は必要に応じて使う

「完全なINSERT文」は、INSERT文にカラム名を含める設定です。

通常のINSERT文は、以下のような形式です。

INSERT INTO `wp_posts` VALUES (...);

完全なINSERT文では、以下のようにカラム名も含まれます。

INSERT INTO `wp_posts` (`ID`, `post_author`, `post_date`, `post_content`) VALUES (...);

完全なINSERT文にすると、SQLファイルの内容がわかりやすくなり、復元時の安全性が上がる場合があります。

ただし、ファイルサイズは大きくなります。

通常のバックアップでは必須ではありませんが、移行や検証を重視する場合は有効にしてもよい設定です。

DROP TABLEとIF NOT EXISTSの注意点

DROP TABLEは復元目的では便利だが扱いに注意する

詳細設定には、DROP TABLE文を追加する という項目があります。

DROP TABLE文を追加すると、SQLファイルの中に、既存の同名テーブルを削除する命令が含まれます。

たとえば、以下のようなSQLが追加されます。

DROP TABLE IF EXISTS `wp_posts`;

この設定は、バックアップ時点の状態にしっかり戻したい場合や、新しいデータベースへ移行する場合には便利です。

ただし、既存の本番データベースにインポートすると、同名テーブルが削除される可能性があります。

そのため、DROP TABLEは一律でオンにするのではなく、目的に応じて判断してください。

新規データベースへ移行する場合：オンでもよい
バックアップ時点に完全復元したい場合：オンでもよい
本番DBにインポートする可能性がある場合：注意が必要
既存データを残したい場合：安易にオンにしない

特に初心者の場合、DROP TABLEが含まれたSQLファイルを本番環境にインポートすると、既存データを消してしまうリスクがあります。

必ず事前に現在のデータベースもバックアップしてから作業してください。

IF NOT EXISTSは万能ではない

「IF NOT EXISTSを追加する」という設定がある場合もあります。

これは、同名のテーブルが存在しない場合だけテーブルを作成する設定です。

たとえば、以下のようなSQLになります。

CREATE TABLE IF NOT EXISTS `wp_posts` (
  ...
);

一見すると安全な設定に見えますが、復元目的では注意が必要です。

すでに同名テーブルが存在する場合、そのテーブルは作り直されません。

つまり、既存テーブルの構造がバックアップ時点と違っていても、そのまま残る可能性があります。

その結果、完全な復元にならない場合があります。

そのため、IF NOT EXISTSはエラー回避には役立ちますが、バックアップから正確に復元したい場合には万能ではありません。

復元目的では、DROP TABLEを使って作り直すのか、既存データを残すのかを事前に決めたうえで設定してください。

エクスポートを実行する

設定後に「実行」をクリックする

エクスポート設定が完了したら、画面下部にある 「実行」 をクリックします。

すると、SQLファイルのダウンロードが始まります。

保存されるファイルは、以下のような名前になります。

example_db.sql
example_db.sql.gz

このファイルが、データベースのバックアップファイルです。

ダウンロード後は安全な場所に保存する

バックアップファイルは、PC内だけでなく、できれば複数の場所に保存しておくと安心です。

保存先の例は以下です。

PC内
外付けSSD
外付けHDD
Google Drive
Dropbox
OneDrive
社内の安全なストレージ

サーバー障害に備える場合、バックアップファイルをサーバー内だけに置いておくのは避けたほうが安全です。

サーバー自体に障害が起きた場合、バックアップファイルも一緒に失われる可能性があるためです。

バックアップできているか確認する方法

SQLファイルの中身を確認する

ダウンロードしたSQLファイルは、テキストエディタで開いて中身を確認できます。

正常なSQLファイルであれば、以下のような記述が含まれています。

CREATE TABLE `wp_posts` (
  ...
);

INSERT INTO `wp_posts` VALUES
...

CREATE TABLE はテーブル構造を作成する命令です。

INSERT INTO はテーブルにデータを入れる命令です。

このような記述があれば、少なくともテーブル構造やデータが含まれていることを確認できます。

ファイルが途中で切れていないか確認する

SQLファイルに CREATE TABLE や INSERT INTO が含まれていても、それだけで完全なバックアップとは判断できません。

以下の点も確認してください。

ファイルサイズが極端に小さくないか
SQLファイルの末尾まで出力されているか
必要なテーブルがすべて含まれているか
重要なテーブルのデータが含まれているか
圧縮ファイルが破損していないか

エクスポート処理が途中で止まった場合、SQLファイルが不完全な状態で保存されることがあります。

特にデータベースの容量が大きい場合は注意が必要です。

可能であれば復元テストを行う

重要なサイトでは、バックアップファイルを保存するだけでなく、検証用のデータベースに一度インポートして復元テストを行うのが理想です。

バックアップは、取得すること自体が目的ではありません。

必要なときに復元できて初めて意味があります。

本番サイト、ECサイト、会員サイト、業務システムでは、定期的に復元テストを行うと安心です。

WordPressサイトをバックアップする場合の注意点

phpMyAdminで保存できるもの

WordPressサイトの場合、phpMyAdminで保存できるのはデータベース内の情報です。

主に以下のようなものが含まれます。

投稿
固定ページ
コメント
カテゴリー
タグ
ユーザー情報
サイトURL
管理画面の設定
プラグインの設定
テーマのカスタマイザー設定
ウィジェット設定
WooCommerceの注文情報
カスタム投稿タイプのデータ

WordPress管理画面から保存した設定や投稿データは、基本的にデータベース内に保存されています。

そのため、phpMyAdminでデータベースをバックアップしておけば、これらの情報を復元できる可能性があります。

phpMyAdminでは保存できないもの

一方で、phpMyAdminのバックアップには、サーバー上のファイルは含まれません。

たとえば、以下のものはphpMyAdminのバックアップだけでは保存されません。

画像ファイル
PDFファイル
動画ファイル
テーマファイル
プラグインファイル
WordPress本体ファイル
wp-config.php
.htaccess
独自にアップロードしたファイル

特に画像ファイルは、通常 wp-content/uploads に保存されています。

データベースだけを復元しても、画像ファイルがサーバー上に存在しなければ、メディアライブラリや記事内の画像が正しく表示されません。

WordPressで一緒にバックアップすべきファイル

WordPressサイトを完全に復元できるようにするには、データベースに加えて、以下のファイルやディレクトリもバックアップしてください。

wp-content/uploads
wp-content/themes
wp-content/plugins
wp-config.php
.htaccess

最低限、wp-content ディレクトリはバックアップしておくことをおすすめします。

WordPressサイト全体を復元したい場合は、データベースとファイルの両方が必要です。

バックアップを復元する基本手順

phpMyAdminの「インポート」を使う

phpMyAdminでバックアップを復元する場合は、「インポート」 機能を使います。

基本的な流れは以下です。

1. phpMyAdminにログインする
2. 復元先のデータベースを選択する
3. 「インポート」をクリックする
4. SQLファイルを選択する
5. 「実行」をクリックする

SQLファイルが正常で、データベースの権限や容量に問題がなければ、バックアップ時点のデータを復元できます。

復元前には必ず現在のデータもバックアップする

復元作業を行う前には、必ず現在のデータベースもバックアップしてください。

バックアップファイルをインポートすると、既存データが上書きされたり、削除されたりする可能性があります。

特にDROP TABLE文が含まれているSQLファイルをインポートする場合は注意が必要です。

本番環境で復元する場合は、以下を確認してから作業してください。

現在のDBバックアップを取得したか
復元先のDBを間違えていないか
SQLファイルにDROP TABLEが含まれていないか
復元後にサイトが正常表示されるか確認できるか
作業時間中に新規注文や問い合わせが発生しないか

ECサイトや会員サイトでは、復元作業中に新しい注文や会員登録が発生すると、データの不整合が起こる可能性があります。

必要に応じて、メンテナンスモードにしてから作業してください。

よくあるトラブルと対処法

データベースが大きすぎてエクスポートできない

データベースの容量が大きい場合、phpMyAdminでのエクスポートが途中で止まることがあります。

主な原因は以下です。

PHPの実行時間制限
PHPのメモリ制限
Webサーバーのタイムアウト
ブラウザや通信の中断
データベース容量が大きすぎる

この場合は、以下の方法を検討してください。

gzip圧縮でエクスポートする
テーブルごとに分けてエクスポートする
サーバーのバックアップ機能を使う
SSHでmysqldumpを使う
WordPressのバックアッププラグインを使う
WP-CLIを使う

数百MB以上の大きなデータベースでは、phpMyAdminよりも mysqldump やサーバー側のバックアップ機能を使ったほうが安定することがあります。

インポート時にエラーが出る

バックアップファイルをインポートするときにエラーが出ることもあります。

よくある原因は以下です。

SQLファイルのサイズが大きすぎる
アップロード上限を超えている
PHPの実行時間制限に引っかかっている
既存テーブルと衝突している
文字コードが合っていない
MySQLやMariaDBのバージョン差がある
CREATE DATABASE文で権限エラーが出ている
DEFINERの指定でエラーが出ている
max_allowed_packetに引っかかっている

レンタルサーバーでは、ユーザーに CREATE DATABASE 権限がない場合があります。

その場合、SQLファイル内に CREATE DATABASE 文が含まれているとエラーになることがあります。

また、ビュー、トリガー、ストアドプロシージャ、関数などを含むデータベースでは、DEFINER の指定が原因でエラーになることがあります。

文字化けが起きる

日本語サイトでは、文字コードの不一致によって文字化けが起きることがあります。

WordPressでは現在、utf8mb4 が使われていることが多いですが、古いサイトでは異なる文字セットが使われている場合もあります。

大切なのは、エクスポート時やインポート時に文字コードを不用意に変更しないことです。

基本的には、元のデータベースの文字セットと照合順序を維持してください。

元DBがutf8mb4なら、復元先もutf8mb4系に合わせる
古いDBの場合は、現在の文字セットを確認してから移行する
エクスポート・インポート時に文字コードを適当に変更しない

文字化けが起きると、投稿本文、商品名、顧客情報、コメントなどに影響する可能性があります。

phpMyAdminバックアップの注意点

phpMyAdminは大規模データベースには向かない場合がある

phpMyAdminはブラウザ上で操作できるため便利ですが、大規模なデータベースのバックアップには向かない場合があります。

特に、数百MBから数GB規模のデータベースでは、以下の制限に引っかかる可能性があります。

memory_limit
max_execution_time
post_max_size
upload_max_filesize
Webサーバーのタイムアウト
MySQL側のmax_allowed_packet

大規模サイト、ECサイト、会員サイト、アクセス数の多いメディアサイトでは、phpMyAdminだけに頼らず、サーバーのバックアップ機能やコマンドラインでのバックアップも検討してください。

mysqldumpを使う方法もある

SSHが使えるサーバーであれば、mysqldump を使ってバックアップを取る方法もあります。

基本的なコマンドは以下です。

mysqldump -u ユーザー名 -p データベース名 > backup.sql

gzipで圧縮しながら保存する場合は、以下のようにします。

mysqldump -u ユーザー名 -p データベース名 | gzip > backup.sql.gz

mysqldump はphpMyAdminよりも大容量データベースのバックアップに向いていることが多く、サーバー移行や定期バックアップでもよく使われます。

ただし、SSHの利用権限やコマンド操作が必要になるため、初心者の場合はサーバー会社のマニュアルを確認してから実行してください。

バックアップを取るべきタイミング

WordPressやプラグインの更新前

WordPressサイトでは、以下の作業前にバックアップを取ることをおすすめします。

WordPress本体の更新前
テーマの更新前
プラグインの更新前
PHPバージョン変更前
MySQLやMariaDBの変更前

更新作業後にサイトが表示されなくなったり、管理画面に入れなくなったりするケースがあります。

事前にバックアップを取っておけば、問題が起きた場合に復元しやすくなります。

サイト改修や設定変更の前

大きな変更を行う前にもバックアップは必須です。

たとえば、以下のような作業前には必ずバックアップを取ってください。

デザインリニューアル
テーマ変更
プラグインの入れ替え
大量の記事編集
URL構造の変更
パーマリンク設定の変更
フォーム設定の変更
ECサイトの決済設定変更
会員サイトの権限設定変更

特に、売上や問い合わせに影響するサイトでは、作業前のバックアップが重要です。

サーバー移行前

サーバー移行を行う場合は、データベースとファイルの両方をバックアップします。

移行直前のバックアップを使わないと、移行中に追加された投稿、注文、問い合わせ、会員登録などが反映されない可能性があります。

ECサイトや会員サイトでは、移行タイミングに注意し、必要に応じて一時的に注文受付や会員登録を停止することも検討してください。

サイト種別ごとのバックアップ頻度の目安

更新頻度が低い企業サイト

更新頻度が低いコーポレートサイトであれば、週1回から月1回程度のバックアップでも足りる場合があります。

ただし、WordPressやプラグインを更新する前には、必ず直前のバックアップを取ってください。

ブログやメディアサイト

記事更新が多いブログやメディアサイトでは、毎日から週1回程度のバックアップが目安です。

毎日記事を投稿している場合は、毎日バックアップを取るほうが安心です。

ECサイトや会員サイト

ECサイトや会員サイトでは、注文情報、顧客情報、会員情報などが頻繁に更新されます。

そのため、毎日、または数時間ごとのバックアップが望ましいです。

特に売上に直結するサイトでは、サーバー会社の自動バックアップ機能や専用のバックアップサービスも活用してください。

まとめ

phpMyAdminでデータベースをバックアップするには、対象のデータベースを選択し、「エクスポート」からSQL形式で保存します。

簡単なバックアップであれば、簡易エクスポートでも問題ありません。

一方で、本番サイトや重要なデータベースでは、詳細エクスポートを使い、構造とデータの両方を含めて保存するのがおすすめです。

バックアップ時には、以下の点を意識してください。

対象のデータベースを間違えない
すべてのテーブルを選択する
SQL形式で保存する
構造とデータの両方を含める
AUTO_INCREMENT値を含める
DROP TABLEは目的を理解して使う
文字コードを不用意に変更しない
バックアップファイルが正常か確認する
可能であれば復元テストを行う

また、WordPressサイトの場合、phpMyAdminで保存できるのはデータベースだけです。

画像、テーマ、プラグイン、wp-config.php などのファイルは別途バックアップする必要があります。

データベースのバックアップは、サイト運用における重要な保険です。

特にWordPressの更新前、サーバー移行前、大きな改修前には、必ずバックアップを取ってから作業しましょう。

以上、phpmyadminでデータベースのバックアップを取る方法についてでした。

最後までお読みいただき、ありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！