WordPressのバックアップファイルあるけど、いざとなったら復元できるの?

このブログはBackWPupというプラグインでバックアップを定期的に実行してDropBoxに保存してあるのですが、ファイル保管して満足しており、実際は一度も復元作業をしたことがありませんでした。(¬ω¬;A)
dropbox
先日、テスト用に使用していたサーバーで複数のWordpressの設置とかいろいろ試しているうちに、元に戻せなくなり、クリーンインストールしなおすハメになった際、せっかくなので、復元作業も試してみようと思い、実施してみたときの所感を備忘録として残しておきます。(無理やり一文にまとめて読みにくいよ。。。)

現在、定期的にバックアップしているファイルは以下の通りです。

  • Databaseファイル(週一)
  • テーマファイル(週一)
  • Uploadsファイル(月一、今年分)
  • これにあとは不定期でPlugin関係をマニュアルで実施したりしなかったり。

    とりあえず、このファイルを元に、テスト環境につっこむところからですが、最初のDatabaseをphpmyadminでインポートするところからつまづきました。
    正確には、インポート自体は特に問題なく成功したのですが、いざテスト環境にログインしようとすると、URLがすでに本番と同じもの(mylifeyourlife.net)となっており、ログイン自体が現在稼働中のこのブログに入ってしまうのです。

    で、いろいろ調べてみると、どうやらDBの中でwp_optionは対象外にしないといけないことが判明。
    【WordPress】ブログのお引越し、サーバ移行方法の手順まとめ
    こちらを参考とさせていただきました。

    今回の場合、テスト環境は本番環境とは異なるURLとなってるため、この措置が必要となりますが、いわゆる本番環境でバックアップを復元したい場合、wp_optionも含める必要があります。

    さて、あらためて、現在保管しているバックアップファイルとは別にwp_optionを外してエクスポートしたDBファイルを用意し、テスト環境でもWordpressをクリーンインストールしなおして、DBのwp_option以外を空にして、インポートしてみたところ、今度は正常にテスト環境にログインできました。d(‘v`●)

    いざ、記事内容がごっそり移ってきているのを見ると、感激しましたが、テーマファイルの移行とかは、メニューとか背景とか、個別に修正しないといけない感じでした。(やり方がまずいのかもですが。。。)

    あと、Uploadsフォルダの画像を一斉に映してみても、記事内でのURLは本番環境のパスを示しています。
    これが先ほどと同じく、本番環境でのバックアップなら問題ないのですが、URLの異なるテスト環境へアップロードしたところで、記事内のパス情報は自動的には変わりません。むぅ。(。・`ω・。)q

    で、先ほどの記事内部で紹介されていたスライドシェアが、ばっちし今回のケース(異なるURLへの移行)を説明する内容でした。

    こういう時のために便利なURL変換スクリプトのツールがあるそうで、以下からダウンロードできます。
    WORDPRESS (AND OTHERS) SEARCH AND REPLACE TOOL

    こちらのツールで文字列を一斉に変換するのであれば、DBのwp_optionも含めてエクスポートしても構わないですね。

    とりあえず無事に変換して画像も正しく参照してくれるようになりましたが、少しでも文字列間違えたりすると、冷や汗ものなので、重々確認しながらですね。といってもバックアップファイル自体があるがら、何回失敗してもやり直せるのですが。

    とりあえず、これで現行サーバーが仮に吹っ飛んだ場合でも、何とかなることが確認できました。
    それにしても普段はDBとかいじらないので、いい勉強になりました。たまにはいいものですね。

    ところで、DBの他のテーブルをのぞいてみると、以前に使用していたプラグインのキャッシュデータの残骸とかがちらほらと見え、そこそこ容量食っているのが判明しました。この際、削除してもいいのですが、どこに影響があるか不明なところもあるので、今回は本番環境は触らないことにし、いざ引っ越すことがあれば、対象から外してもいいかなと思っています。

    あとwp_commentmetaとかwp_postmetaがやたらとレコード数が多くなっており、当然サイズも大きくなっていました。
    中身は_edit_lockとか_edit_lastとか_wp_attachment_metadataとか各種あり、ちょっとどういう影響があるのか不明なので今回は触らないことにしました。
    wp_commentmetaはこれだけで4MBになっていた問題児なのですが、どうも原因はAkismetが活躍したログが全部残っていることにあるようでした。どっかのタイミングで削除しないとですね。

    そもそもWP-OptimizeプラグインのDBの最適化でこの辺もきれいにならないのかな?と新たな疑問が生まれてきますが、今回のところはこのあたりにして、またの機会につっこんでみたいと思います。

    ※追記:wp_commentmeta削除しました。
    WordPressでDBサイズを圧迫している一番の原因はAkismetだった・・・


    スポンサーリンク


    コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


    *

    日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)