【WordPress】phpMyAdminでDBのバックアップと復旧（エクスポート・インポート）を行う方法
2015/09/22
今回はWordPressのデータベースのバックアップと、復旧手順を説明したいと思います。
特にWordPressに限った話でもないので、他のWebサービスで使用しているデータベースも同じように進められます。
スポンサーリンク
WordPressを利用中の方へ
前回、WordPressに用意されているツールの、インポートとエクスポートと、ファイルのバックアップについて説明した記事がありますので、そちらも是非確認してみて下さい。
【WordPress】簡単なバックアップの取り方と復旧の方法【初心者向け】
今回もそんなに難易度は高くないので、中級者向け？程度の内容です。
phpMyAdminでデータベースのバックアップを取得する（エクスポート）
まず、phpMyAdminにログインしましょう。
こういう画面が表示されます。（もちろん装飾はありませんｗ）
バックアップの対象を決める
今回バックアップするにあたって、何をバックアップするのかを決める必要があります。
え？データベースじゃないの？と思うかもしれませんが、データベースの認識が合っていない可能性が高いので軽く説明します。
まず、MySQLというデータベースサーバがあります。
先ほどの画像の今いる場所で示すサーバという場所です。
このサーバが、データベースを持っています。
そして、データベースがテーブルを持っています。
最後に、テーブルがレコード（肝心のデータ）を持っています。
なので、サーバからバックアップを取得する場合は、どのデータベースをバックアップするかという単位で指定します。デフォルトでは全データベースを選択した状態になります。
同じ様に、データベースからのバックアップはテーブル単位、テーブルからのバックアップはレコード単位になります。
もし、サーバーの移行などを考えていれば、サーバからのバックアップで、全データベースを取得したら良いと思います。
phpMyAdminでエクスポートする際の注意点
先ほど、全データベースのバックアップを取得したらいいと軽く話ましたが、これはあくまでもデータベースサーバを直接触る時の話を想定してのことです。
今回扱う「phpMyAdmin」はWebアプリケーションです。そして恐らくレンタルサーバーでの利用を考えているのではないかと思います。
その際注意するべきことがあります。それはWebサーバのタイムアウトの時間です。
殆どの人は共用サーバーをご利用中のことだと思います。
VPSやクラウドなどを借りるような人が「phpMyAdmin」を使うとは思えないし、使うとしても自分でタイムアウトの時間を設定して回避出来るはず…。
そしてそのレンタルサーバーのタイムアウトの時間が大体10秒～15秒位のところが多いです。
ただでさえパフォーマンスの出ないサーバーです。この短時間で処理できることは限られています。
なので、データベース丸ごとのバックアップは、かなりの小規模なシステムでないかぎり厳しそうです。
そもそもSQLからデータベースを作成する権限を与えられていないと思いますので、テーブルのバックアップになると思います。
ただ、エクスポートはそこまで時間がかかるわけではないので、データベース丸ごとでも、もしかしたら可能かもしれません。
しかしエクスポートは出来ても肝心のインポートはエクスポートの何倍も時間がかかるので、復旧作業がうまく行えない可能性が高いです。
もしローカルの開発環境用にデータを移したいとかであれば、最大限にエクスポートしても問題ないでしょう。
（さすがにローカルPCの性能が共用サーバーに劣ることはないはず…。）
テーブルのエクスポート
というわけで、まずはテーブルに対象を絞って説明していきます。データベースは同じ様な手順なので説明しません。
まず左の一覧から、バックアップを取りたいデータベースを選択し、「エクスポート」をクリックします。
エクスポート方法を詳細に設定出来るので、「詳細」を選びます。
もし、新しいデータベースに全テーブルのデータを移したいという目的であれば、このまま「実行」でも問題ありません。
エクスポート方法で詳細を選ぶと詳細な設定項目が表示されます。
長くなるので全項目の説明はしません。オススメする設定だけピックアップして説明します。
テーブル
これはとても重要です。どういう基準で選んだら良いかですが、当サイト「はぴすぷ」の現在のWordPressのテーブルデータはこのようになっています。
「wp_posts」だけで3.8MB。全体で5MB程度です。
試しに全部エクスポートしてインポートしましたが、タイムアウトしました。
ただ、これはサーバーの性能によるので一概には言えません。恐らく大体のサーバで２MBくらいまでなら耐えられると思います。
一度限界値を探ってみることをおすすめしますが、私の借りているお名前.comの共有サーバーSDでは3MB程度であれば正常にインポートできました。
なので、全体の5MBは耐えられないし「wp_posts」単体でも耐えられません。
しかし「wp_posts」を除いた全テーブルでは1.2MB程度なので、これらはまとめてエクスポートするという様に選定します。
出力
「圧縮」ですが、もしテーブルのデータの合計が２MB近くかそれ以上であれば、「zip形式」か「gzip形式」を選択することをお勧めします。
「phpMyAdmin」でインポート出来るファイルのサイズが2MB以下に制限されているので、手動で圧縮する手間が省けます。
「Skip tables larger than」で、先ほどの「wp_posts」みたいな巨大なテーブルを含めないように出来るみたいですね。
フォーマット
これはSQLでいいでしょう。他のシステムに読み込む時以外は変更する必要はないです。
フォーマット特有のオプション
これもデフォルトで良い。
生成オプション
「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER コマンドを追加する」の項目にチェックを入れておきます。
インポート先に既にテーブルが存在していて、テーブル構造が変わっていた時に困ることになるので、テーブルを確実に作りなおす様にします。
Data creation options
テーブル丸ごと作りなおすのでデフォルトで問題なし。
エンコーディングへの変換
不要なのでデフォルトのままでいいです。
「実行」をクリックしてエクスポートファイルを入手します。少し時間がかかります。
テーブルから行単位でデータをエクスポート（レコード分割）
テーブル丸ごとは、ほぼデフォルトで問題ないのですが、レコードを分割してバックアップを取得する方法は、2つ目以降でオプションを変えたりしないといけないので、少しややこしいです。
まず対象のテーブルのページのエクスポートタブに移動します。エクスポート方法から詳細を選択します。
基本的には、行単位でも同じような項目が表示されます。
必要な部分のみ説明します。
行
デフォルトは「すべての行をダンプする」になっているので「ダンプする行」に変更します。
最初にエクスポートする時は、「開始行」を0、「行数」を２MB程度～自分のレンタルサーバの性能に応じたサイズになりそうな行数を入力します。
2つ目以降は「開始行」に「行数分」足していきます。
生成オプション
最初だけ「DROP TABLE / TRIGGER コマンドを追加する」と「CREATE TABLE コマンドを追加する」にチェックを入れます。
2つ目以降ではチェックを外します。
その他はデフォルトのままで大丈夫です。
全てのレコードが含まれるまで、エクスポートファイルを「実行」ボタンで作成したら完了です。
phpMyAdminでバックアップから復旧させる（インポート）
バックアップの作成（エクスポート）は出来たので、実際に復旧することが出来るのか確認しておきましょう。
ローカル環境でチェックするのもいいですが、やはり本番と同じ環境で行うのがベストです。
データベースを複数作成出来るのであれば、練習用にデータベースを作成して試してみましょう。
もしデータベースを作れる数に余裕がなかったり、1つしか無い場合は仕方ないので最低でもローカルで試しておきましょう。
インポートもテーブルと行単位での手順に限定して説明します。
テーブルのインポート
テーブルをインポートするデータベースを選択し、インポートタブを選択します。
「インポートするファイル」の「ファイルを選択」をクリックして先ほどエクスポートしたファイルを選択します。
一応sqlファイルのままエクスポートして、自分でzip化しても問題なくインポートできました。
「.sql.zip」って名前にしろと書いていたけど「.sql」の入った普通の「.zip」で大丈夫でした(´・ω・｀)
あとはオプションもデフォルトで、特にいじる必要はないと思います。
一応気になったものを一つ。
部分インポートと、はまった注意点
翻訳されてない(´・ω・｀)
Google先生翻訳
スクリプトは、それを検出した場合には、インポートの中断は、PHPのタイムアウト限界に近いことができます。（これは、しかし、それは、トランザクションを破ることができる、大容量のファイルをインポートするには良い方法かもしれません。）
タイムアウトなっても途中まではインポートしてくれるってこと？ でもトランザクション壊れてるからデータがおかしくなってても知りませんと。そういうことなんですか(；・∀・)分かりません。付けた時と外した時で違いを見てみる。
とりあえずチェック付けて、元が5MBくらいの全テーブルを圧縮してやってみた。
まず、タイムアウトで「Internal Server Error」
「wp_posts」の途中まではちゃんとインポート出来てる！と思っていた。
なので「wp_posts」の足りない部分を補うつもりで、行単位エクスポートで「wp_posts」のデータをエクスポートした。
最後の1行が壊れたデータになってないか不安なので1行だけ被せて、コマンドをREPLACEに変更してやってみた。
エラーが出た。
IDにプライマリキー設定しようとしたけど、ID=933が被ってるよと。
要するに、最初のタイムアウトの時に、最後のALTER TABLEにたどり着いてないのでインデックスとか付いてないんですね。
「wp_posts」だけかと思ったら、他のテーブルも全滅でした。
そして、チェック外したら全部無かったことにしてくれるのかと思って試してみる。
結果 → 変わらず ∑(ﾟДﾟ)ｶﾞｰﾝ
何かよく分からんオプションですね…。
どっちにしろ中途半端なデータが残っちゃうので、タイムアウトにならないようにきちっと分けた方がいいです。
自分でSQLファイル見て、ALTERかけるなり調整出来る人ならいいですが、あんまり分かってない人には辛いです。
というわけで、2MB以下に分けたテーブルだけのデータをインポートさせました。
やたら大きかった「wp_posts」だけは行単位でインポートさせます。
テーブルに行単位でインポート
エクスポートではテーブルを選択してから行いましたが、インポートではデータベースが選択された状態であれば、テーブルを選択していなくても問題ありません。
そもそも最初にインポートする時はテーブルありませんしね(^q^)
というわけで、インポートする対象のデータベースを選択して、インポートタブを選択します。
インポートするファイルから、行単位で最初にエクスポートしたファイルを選択して下さい。
最初のファイルにしかテーブルを作成する為の情報が入っていません。
そのまま実行したら「wp_posts」テーブルができました。
もちろんレコードは指定した分の600件のみです。
あとは繰り返し、分割したファイル分インポートします。
キャプチャ取りなおしたりしてるので数値が最初と一致してないのは気にしないでくださいｗ
これで無事にバックアップから復旧させることが出来ました。
終わりに
今回の手順をマスターしておけば、WordPressのツールのエクスポートでは取れなかった情報も全て復元可能になります。
しっかりバックアップを取っておけば、完全に元通りに復旧させることが出来るようになったわけです。
もちろん障害対策ではなくサーバの引っ越し時にも、この方法で対応できます。ドメインが変わるとかになるともう少し手間がかかりますが(´・ω・｀)
というわけで、私もこれでプラグインの設定含めバックアップ取れたので、ちょっと思い切ったカスタマイズや、プラグインの導入が出来そうです。
一応まだ不安が残るので、ステージング環境を準備してる途中です。この手順も後日共有する予定なのでお楽しみに(^q^)それでは。