もしもの時のためにバックアップは必須
学生の頃にもらったラブレター、押し入れのどこかに眠ってたりしませんか?
私は全部捨てちゃった。だったら聞くなよ。りく(@Rikuma_)です。
最近、「ブログのバックアップって大切だよね!」という記事をよく目にします。ブログの挙動や表示がおかしくなって、バックアップのおかげで最悪の事態は防げたという内容。
私も自分のブログを何度「真っ白け」にしたことか。経験することで糧になり学びも増えますが、初めてブログが真っ白になった時は生きた心地がしなかった。
現在、WordPressのバックアップは「BackWPup」というプラグインを利用します。過去にもエントリーを書きました。
いろんなブログで最近「これは便利!」と絶賛されているWordPressのバックアップ用プラグイン「BackWPup」。私も導入してみたのですが、DropboxやSugarSyncなど、いわゆる「クラウド」への保存がことごとくエラーになってしまいます。 WordPressのデータベースなどをバックアップするプラグイン「BackWPup」がDropboxやSugarSyncなどのクラウドに保存失敗した件の続報です。記事を読んで下さった方にTwitterにて解決策を教えて頂きました。巷で最近話題の「BackWPup」がクラウドに保存できなくて発狂した
BackWPupのDropbox保存エラー、解決策が判明しました
この「BackWPup」なんですけど、最近になって保存対象の容量が増えたせいなのか、毎回エラーが発生するようになってしまいました。最終的に保存は出来てるのでイイと言えばイイのでしょうけど、あんまり気持ちは良くない。
最近多発しているエラー
↑「BackWPup」を実行してエラーが発生した時のみメールを自動送信する設定にしてるのですが、最近は毎回送信されてます。つまり毎回エラーやねん。
プラグインの初期設定では10分でタイムアウトになり、リトライになりますが、それでは短すぎるのでプラグインをカスタマイズして100分でリトライするようにしてます。それでも100分後に1回だけエラーが発生してる状況。
最終的には成功してるからいいんですけど、圧縮後でさえバックアップファイルのサイズが約337MBあるんですよ。なんでこんなにデカくなるのか。余計なものを入れ過ぎてるのかな。
エラーログを見ると開始から105分後くらいに終了してるので、だったらリトライの時間を130分とかに再修正すればいいのかなとも思うのですが、なんとなくそれ、やりたくないんですよ。感覚的に。延ばせばいいってもんでもないんじゃないかと思って。
このプラグイン「BackWPup」の売りの一つが「DropboxやSugarSyncなどのクラウドにも保存できること」なんですけど、ファイルが大きかったり処理時間が長かったりで、結局いつ頃からか失敗ばかりなので、現在はサーバのみにしか保存してません。
そこで今回、「分散バックアップ」の出番となるわけです。
3つのバックアップ処理に分散させてみました
↑現在、バックアップ処理は上の3つを設定して運用しています。以前は1と2だけを実行してて、毎回エラーが発生してたのは1です。今回新たに3番目のバックアップ設定を追加しました。
「BackWPup」をある程度ご存知の方であれば、上の設定概要を見ただけで「なるほどね」とご理解頂けるはずなのですが、ここで終わったら記事書く意味がないので、詳細をば。
↑「BackWPup」の設定画面に入り、「Job Type」欄で何をバックアップ対象とするかの設定をします。上から順番に意味を説明すると、
データをXML形式でエクスポート(出力)する。
2. Database Backup
データベースをバックアップする。
3. File Backup
テンプレートやテーマなどのファイルをバックアップする。
4. Optimize Database Tables
データベース(のテーブル)を最適化する。
5. Check Database Tables
データベース(のテーブル)をチェックする。
という風になってます。上で紹介した私の設定だと1・2・3を指定していることになります。
1.の「WP XML Export」は要らないかなぁとも思うのですが(たぶんこれのせいでサイズ大きくなってる気もするし…)、外すと何か困ったことになったらいけないので結局入れてます。
↑さっきと同じ画像ですが、以前は
★処理2:opt_and_chk → 上記4・5のみで、データベース最適化&チェックするだけ
という2段構えのバックアップ処理にしてました。ここに今回、
という3つ目のバックアップ処理を追加。データベースだけの保存なら容量もそれほど大きくならないだろうし、それならDropboxにも保存できるはず。サーバが何らかの問題でおかしくなってもDropboxにデータベースの中身は確保されている。
テンプレートなどのファイルはローカル環境に同じものをコピーしてるので、こちらも二重でバックアップ体制が出来ている。プラグインもアップデートしたら動きがおかしくなることがよくあるので、それに備えてローカル環境に保存するようにしてます(それは手動で)。
ちなみに今回追加した「処理3」ですが、データベースのみだとサイズが約70MBくらいなので、これまで一度もエラーなく保存成功しています。分散させて良かった。
↑「Job Schedule」欄の「Activate scheduling」にチェックを入れることで、自分の好きな時刻にバックアップ処理を起動できるようスケジューリングが出来ます。
私が設定した3つのバックアップ処理はそれぞれ
◆処理2(最適化&チェックのみ) … 週1回、深夜4時から処理開始
◆処理3(Dropboxへバックアップ) … 毎日、深夜2時から処理開始
という指定にしました。基本は日付が重複しないようにして、同じ日に処理する場合も時刻がカブらないようにしています。
サイズ軽減のため、データベースの保存対象を絞り込む
サイズ軽減のために「全てをバックアップする」のではなく、保存対象となるデータベースのテーブルやファイルを絞り込むことは以前からやってました。どれだけ効果あるのかは分からないですけどね(実際、毎回エラーになってるわけだし)。
まず、データベース保存を指定した場合に、保存するデータベースのテーブルを指定できるようになり、設定画面にテーブル一覧が表示されます。
↑「Database Jobs」欄にテーブル一覧が表示されるのですが、この一覧をよ~く見ると、プラグインの名前が付いてたりします。
上の画像だと「wp1_wordbooker」と先頭に付いているテーブルがズラリと並んでますが、これは「Wordbooker」という、記事を更新したら自動でFacebookに更新情報を流してくれるプラグインが使用しているテーブルなんだなと想像が付きます。
私は現在「Wordbooker」を使ってないので、このテーブルを保存する必要がない。不要なテーブルのチェックを外すことでバックアップ対象から除外することが出来ます。
中にはプラグインの名前も付いてない「これ、何のテーブルやろ?」ってのもあると思います。用途や名前に見覚えがなかったり、外していいのか判断に迷ったら、チェックを外すのではなく、逆に必ずチェックを入れてバックアップ対象にしておきましょう。
基本は全てのテーブルを保存対象にしてイイと思います。私の場合はあまりにもサイズがデカかったので、何か削らなきゃ、と苦肉の策だったんですよ。
不要なファイルもバックアップ対象から外してみる
ファイルのバックアップに関しても保存対象を絞り込むことが出来ます。
↑「File Backup」欄に保存対象となるファイル一覧が表示されています。
気を付けないといけないのは、データベースのテーブルとは違い、ファイルの場合はチェックを入れると保存の対象外になります。
データベースのテーブルはチェックを外すと保存の対象外になりましたよね。ファイルの場合は設定が真逆になりますので、お間違えのないようご注意を。
私は、使用していないプラグインは保存対象から外してます。ただし、現在は使ってないけれど以前使ってた頃に細かな設定をしていたプラグインに関しては、もしもいつか再使用することになった場合に再設定が面倒臭そうなので、それは保存するようにしてます。
WordPressテーマについては、私のブログでは自作テーマのみを使用していて、WordPressに標準で入っている「Twenty Eleven」などのテーマファイルは今後も使わないと思います(使うとしてもカスタマイズしまくる)。なので保存する必要がないから外してます。
データベース同様、保存サイズに余裕があるのであれば、無理に対象外にする必要はなく、全てバックアップを取っておいた方がむしろ安全だと思います。
あまりにバックアップファイルのサイズがデカくてお悩みの方で、ある程度プラグインやテーマなど対象外にするものの意味がお分かりな場合は、試してみると多少はサイズ節約できるかもしれません。
世代管理はとても便利だけど、保存数には注意しましょう
「BackWPup」は世代管理機能が付いています。世代管理というのは、指定した個数を超えてファイルを保存した場合、最も古いバックアップファイルを自動的に削除し、保存ファイルの個数を一定に保つ仕組みとお考え下さい。
↑サーバに保存する指定のところに「何個までバックアップファイルを保存するか」の指定欄があります。
私は「3」と指定してますので、例えば月曜から毎日のバックアップ処理を開始した場合、月→火→水と保存し、木曜に4個目のバックアップファイルを保存する際、最も古い月曜のファイルが自動的に削除されるという仕組み。
↑Dropboxに保存する場合も同じように保存個数を入力する欄がありますので、サーバの場合とは別途に指定する必要があります。言い換えると、サーバとDropboxで保存個数を変えることも出来ちゃいます。
あまり保存する数を増やし過ぎると、それだけサーバやDropboxの容量を喰います。毎日バックアップを取るとしても7個あれば十分な訳ですから、3~7個の範囲で指定すればいいのではないでしょうか。
ちなみに世代管理機能がないバックアップ用のプラグインを以前使ってましたが、保存するばっかりでチェックもせず放置していたため、ある日サーバの容量をチェックしたら使用率が99パーセントになっていてブッたまげたことがありました。
まとめ
万が一の場合に備え、バックアップしておくことは大変重要です。ただバックアップ処理がエラー多発してたら本末転倒。もしもの時に復元できなかったら意味がないですよね。
今回紹介したのはあくまで一例ですが、分散させて複数の場所にバックアップファイルを保存するようにしておけば、安心度も増すと思います。お試しあれ。