残っていた課題も前回でほぼ解決したので、しばらく関連ネタを投稿しようと思うのですが、今回は割と重要な事柄かも。数年前まで手打ちHTMLでホームページを公開していた頃は、データのバックアップはローカルの外付けHDやMOディスク（！）等にそのままファイルとして保存していました。しかしブログに移行した当時、投稿記事の全テキストは丸ごとサーバー上のデータベースにお預けしたまま。サーバーがトラブルを起こしたら蓄積してきた記事が一瞬でパーになってしまうという状態におののき、ひとまず「Wordpress Backup (by BTE)」というプラグインをインストールし、データベースを圧縮したzipファイルを定期的に当方のemail宛てに送信するよう設定していますが、実はよく解っていません…。

　幸い、バックアップのお世話になるような事態にはまだ遭遇していないのだけれど、それ故、いざその状況が訪れた時に受信ボックスに溜まっているzipファイルをどう扱えばよいのか未だ知らないままです。改めて今回の引っ越し先で使用しているデータベースのバックアップは、どのように運営管理すべきなのか。

マニュアル同期という力技

　flfl.meは、まずローカル（MacBook Air）のMAMP上でブログ構築後にアップロードしたのですが、ならば、ローカルとリモート（サーバー）の投稿記事も両方全く同じにしておけば、それがそのままバックアップと同義になるんじゃないか、と思いました。日々の運営としてはつまり、先にローカルのWordPressで記事を推敲してレイアウトし、完成したらサーバーのWordPressにそのまま記事内容をペーストする、という手順を踏めば、ローカルとリモートで常に同一の状態が保たれるというワケです。つまり手動バックアップ。

初めてのインポート＆エクスポート

　現時点で、ローカルのWordPressにはテスト投稿記事ばかり溜まっているのだけれど、もう必要も無いのでこれを機会にリモートのデータベースをインポートしてみることにしました。まずflfl.meにログインして、投稿記事やタグなどのデータをエクスポート。今回は全てのコンテンツを選びました。

すると、ローカルにxmlファイルが保存されました。

　次にローカルMAMP上のWordPressから、上記xmlファイルをインポートしてみます。気になるのは、既存のテスト投稿を全て破棄して置き換えてしまうのか（上書き）、それとも追加するのか？です。後者の場合、タグのID番号などのバッティングは起きないのでしょうか？物凄く気になる！

　公開中のサーバー（右側）からローカルMAMP（左側）へ。余談ですが、サーバーは右側というイメージがあります。たぶん、既存のFTPアプリ等が右側にリモートサーバーを配置しているからでしょう。

　ローカルMAMP上のWordPressにログインして、インポートをクリックすると、リストがずらっと現れるのでWordPressをチョイス。するとプラグインのインストール画面が出てきました。何とインポート機能は内包されているのではなく、外部パーツ化されているのですね。

　インストール後、先にDLしておいたxmlファイルを指定して「ファイルをアップロードしてインポート」をクリック。
　すると、ユーザーの割当てをどうするか聞いてきたので、これまで通りの自分のアカウントを指定。さらに添付画像などのダウンロード→インポートも同時に行うか聞いてくるので、今回はチェックを入れてみました。

　インポート処理はすぐ終了。

データベースは追加処理された

　インポート後、ローカルMAMP上のWordPressにアクセスしてみると…投稿記事などの情報は上書きではなく、追加処理されていました。下図で丸アイコンが空白になっているのは、追加されたカテゴリーのID番号が書き換えられていて、該当する番号の画像ファイルが不在のため。投稿記事内で使用していた画像ファイルやmp3は、flfl.meからダウンロードされてローカルMAMP内にインポート、リンクのURLもローカルに修正され問題なくページ内にレイアウトされていました。

　カテゴリーIDやタグなども上書きではなく、同じ名称であってもID番号が変更されて追加登録されています。

　今回の例だとローカルMAMP上で登録していたカテゴリー「動作テスト」「Night Head」のIDはそれぞれ１、２番。サーバー側の「Night Head」のIDは１番でしたが、インポート後は自動的に11番に変更されて追加登録されました。さて、どうするべきか。

　ローカルMAMPの「動作テスト」を「Night Head」に変更し、インポートした投稿記事のカテゴリーを改めてその変更した「Night Head」に割り当てれば済むような気がします。しかしここで気になるのは、データベース追加時に生成されたカテゴリーID11番は、今後カテゴリーが増えた場合に上書きされるのか、それとも保留され続けるのかという事（保留になる可能性が濃厚のような）。もし11番が欠番状態になるとすると、いずれサーバー側に生成される11番以降、ID番号の割当てにズレが生じることになる…。そうなると、ローカルMAMPとサーバーで、アイキャッチ画像のID番号を変えなければならなくなります。微妙に面倒くさい。

※自動生成された11番に「保留」と名前を付けておいて温存し、11番目のカテゴリーを追加する時が来たら、その「保留」を変更して割り当てれば大丈夫かも。

まっさらの新規データベースにインポートしてみる

　いろいろ考えるのも面倒になってきたので、改めてローカルMySQLにまっさらの新規データベースを作成し、そこにインポートしたらどうなるか実験してみることにしました。
　そこでまずCoda 2からローカルMAMP上のMySQLにログインします。

　新規のデータベースを作成。エンコーディングはUTF-8。

　wo-config.phpファイルのDB名を新規のものに変更します。ユーザーやパスワードは変更なし。

　コンフィグを修正した後に改めてローカルのWordPressをリロードすると、インストール画面が現れてちょっとビビり、念のためWordPress全体のバックアップを取ったのですが、コチラの記事で行ったような情報入力をしてすぐ完了しました。上書きインストールするのではなくて、初期設定のみの確認ですね。既に追加インストールしていたプラグインや自作FLFLテーマ、アップロードした画像などはそのままローカルに残ってました。

　新規データベースとの接続もでき、ダッシュボードが開くことを確認し、デフォルトで登録される「Hello World!」の投稿記事を削除。そして改めて、先ほどのエクスポートしていたxmlファイルのインポートを行います。その結果。

　カテゴリーIDの1番は「未登録」という名称でデフォルトで確保されていて、追加したカテゴリーはID2番に変更されていました。今回は「未登録」を「Night Head」に名称変更して、４つの投稿記事を再割当てすることにします。
※逆に「Night Head」のID2番は「保留」に変更し、今後の新規カテゴリー作成時に再利用。

　では、タグIDはどうか。実はタグでも同様、追加分は全て番号割当てがズレて登録されてしまいました。しかし不思議なのは、ID1番が確保されてズレるのなら理解できるのだけれど、新規データベースを作成後、こちらは何も操作していないのに、追加登録分のタグはID3番から割当てが始まっていたことです。サーバーの方は２番からなのです。なんで？？ローカル上のID2番はどこに行ったの？

　ちょっと面白くなってきたので、記事IDもチェックしてみると、これがまた微妙にズレていたりしました。各IDの割り振りはもう完全に気ままにやってるようで「そのデータベース内で辻褄が合ってさえいれば問題ないでしょう？」という感じ。

　まだ記事数も４つしかないし、今のうちに手動でチマチマとリナンバリングしようかと思いましたが、今後ローカルでの記事作成中に試行錯誤したりして、投稿を削除したり新規作成したりするうちにその都度IDが自動生成され、完成した記事をコピペしてもサーバーの方では失敗してないからIDがズレる…という状況になりそうです（一度生成されたID番号は温存され、上書きされないという仕様らしいので）。

※インポート時の注意事項として、パーマリンク設定とメディア設定内の「画像サイズ」をテーマのルールに従って事前に変更しておくこと。今回のインポート時に、ページ内で使用している画像の全てについて、サムネール画像も自動作成されてしまいました。
※また、インポートした記事に割当ているカテゴリーですが、改めてチェックを入れ直して「更新」しないと、ファイルはちゃんとアップロードしているのにも関わらず、アイキャッチ画像が「？」となる不具合がありました。
※wp-config.phpで参照DBを変更した後、記事編集時のプレビューが表示されない場合はコチラの記事を参照して、認証用ユニークキーを書き換えておく。

意外に堅実なバックアップ方法かも

　今回、初めてデータベースのエクスポート＆インポートを試してみたのですが、かなり勉強になりました。一度はやっておくべきですね。当初、ローカルとサーバーそれぞれのデータベース内容を完全一致させることを目標に企画スタートしましたが、各種ID番号の完全一致は諦めることにしました。

　今後はちょっとラテン系でお気楽に「内部構造はともかく、表面上の見た目が合致して、リンクの整合性が取れていればOK」というユルいポリシーで行こうと思います。運営ルールとしてはこんな感じで。

　実際のところデータベースが壊れるよりも、自分の操作ミスでサーバー自体が起動不可になる可能性の方が高いと思うし、そうなった場合は結局１から構築し直しということになるので、プラグインを使った自動定期バックアップも今後導入するかもしれないけれど、あまり意味は無いのかも…。　

　おそらく、今この記事を書いている時点では気付いていないトラップが何処かに仕掛けられていて、いずれその罠にハマる確率は高いと踏んでいるのですが、ローカルとTimeMachine、加えてCarbon Copy ClonerによるMacBook Air内蔵SSDの全データ手動バックアップをしておけば、データの保全面については、かなり堅実なんではないかと勝手に思っています。つづく。

2014-08-16 ＞ VPS＆WordPress引っ越しメモ