これまで、WordPressのバックアップとして、エクスポートやプラグインのWP-DBManagerを使っていましたが、ブログの記事だけしかバックアップがとれておらず、画像のバックアップがないことが不安でした。
画像は、パソコン上にあるとはいっても、万が一の時に画像を一つ一つアップすることは非常に手間がかかります。
ファーストサーバーの障害でデータが消失したことも関係するのか、エックスサーバーでは、7月13日より、7日分のサーバーデータを自動でバックアップする機能が追加されます。それでも、ローカルにブログの全データのバックアップがほしいところです。
そこで、いい方法がないかと探したところ、WordPress全体をバックアップするプラグインが見つかりました。BackWPupというプラグインです。次のサイトが参考になりました。
今こそ安心できるWordPressバックアップを！復旧作業まで実際にやってみたWordPress丸ごとバックアップ法 | 情報科学屋さんを目指す人のメモ
この方は、BackWPupでバックアップを取るだけではなく、実際にリストア作業もやられたそうです。具体的な設定は、このサイトに細かく書かれていますので、ここでは、私が設定を変更したところだけを説明します。
１．Job Schedule
いつバックアップをとるかの指定ですが、既定値は午前３時となっています。既定値のままだと、皆がバックアップする時間と重なり、性能面で影響が出る可能性を考えて、あえて変更しました。
２．バックアップ先
バックアップ先としては、WordPressをインストールしているサーバ、E-Mail、FTPサーバ、Dropbox、SugarSync、Amazon S3、Google storage、Microsoft Azure、Rackspace Cloudが指定できるようになっています。
WordPressをインストールしているサーバは、そもそもそのサーバが障害を起こした時のためにバックアップをとるのであり、バックアップ先の候補から最初に外しました。
E-Mailはバックアップファイルの大きさがE-Mailで送るには大きすぎます。FTPサーバは、適当なFTPサーバがありません。
残りのオンラインストレージの中から、5GBまで無料のGoogle storageを最初に試してみました。設定が非常に複雑でした。最終的にバックアップは正常終了するにもかかわらず、Google storageにはバックアップファイルが格納されず、原因もすぐにはわかりませんでした。
次に試したのが、同じく5GBまで無料のSugarSyncでした。設定は、Google storageと比較するとはるかに楽でした。バックアップを実行すると、SugarSync上とパソコンの同期フォルダーの両方にバックアップファイルが格納されていました。
バックアップファイルを解凍してみると、サーバ上のファイルがすべて含まれているようです。画像ファイルがサーバ上と同じフォルダに格納されていることも確認しました。
結果として、バックアップはSugarSyncにとるようにしました。
３．リストア作業
リストア作業は実施していません。リストア作業をやってみたほうが良いことは明らかですが、そのためにはリストア先の確保が必要です。リストア作業の確認のためだけに、新たにレンタルサーバを借りることは費用対効果を考えると割に合いません。
仮に、今使っているサーバでリストア作業を試してみると、その間、ブログの閲覧ができなくなることは言うまでもありません。きちんとリストアできるかどうかのリスクもあります。
また、異なるドメインにリストアする作業は、同じドメインにリストアする作業よりもはるかに複雑です。実際に、障害が発生してリストアするときは、同じドメインに対して実施します。実際のリストア時と異なり、しかもはるかに手間のかかる作業を行う気になりませんでした。
【2016年3月28日追記】
2014年1月にSugarSyncの使用をやめました。
BackWPupの出力先はWordPressを動かしているレンタルサーバに変更し、毎日手動でFTPによりパソコンに転送しています。
