ひとまずサーバー上へのバックアップは問題なし
先日、WordPressのバックアップ用プラグイン「BackWPup」で、DropboxやSugarSyncなどの、いわゆる「クラウド」への保存処理がことごとく失敗したという記事を書きました。
巷で最近話題の「BackWPup」がクラウドに保存できなくて発狂した
いろんなブログで最近「これは便利！」と絶賛されているWordPressのバックアップ用プラグイン「BackWPup」。私も導入してみたのですが、DropboxやSugarSyncなど、いわゆる「クラウド」への保存がことごとくエラーになってしまいます。
あの時点では解決策がまったく分からず、クラウドへの保存は断念してサーバー上へのバックアップをスケジューリングするということで、ひとまず完了としました。
その後、バックアップ処理がどうなってるかというと、
↑今のところ、ほぼ問題なく動いてくれているようです。ただ6月22日のところで1回エラーが発生してます。
↑ログを確認すると、「database optimize」の処理途中で、前回記事と同じ現象、つまり「処理時間が10分で終了しなかった」ためにエラーとなり、2回目の「database optimize」が始まっていることが分かります。
しかしログを最後まで見ると、最終的には6月22日のバックアップデータも保存されているようでした。
FTPソフトでバックアップ先を確認してみると、
↑問題なく3世代分のバックアップデータが保存されています。6月22日の分もキチンと保存されてました。
「最大3個保存」と設定していますので、次回処理の完了後は、現時点でもっとも古い6月22日分が自動的に削除される仕組み。
ということで、クラウドへの保存は残念ながら実現できなかったけど、バックアップデータは確保できているので、これでいいや、と思っていたわけです。
ところが。
記事を読んで下さった方のツイートで調査開始
私の記事を読んで下さった方から貴重なご意見をいただきました。その方のブログ記事を引用すると、
wp-content/plugins/backwpup にある、backwpup-functions.php というファイルの 326 行目、
$revtime=time()-600; //10 min no progress.
この 600 が、リトライ間隔です。
これを適当な大きめの値に変更します。
私は 6000 にしました。100 分ですね。これだけあれば大丈夫だろうと。
10分エラーはDropboxやSugarSyncなどのクラウド側ではなく、プラグイン側で時間を制御してたということが判明。
この修正により、SugarSyncへのバックアップに成功されたとのこと。これってDropboxでも同じ理屈ですよね？
Dropboxへのバックアップ再挑戦
↑「BackWPup」の設定画面。前回の失敗によりDropboxへの保存は断念したため認証も解除していましたが、再挑戦のため認証をやり直します。「Authenticate!」をクリック。
↑認証を求められますので、「許可」をクリック。
↑認証完了のメッセージ。
↑Dropboxの設定欄も表示が変更されました。設定内容は以前登録済みなので、このまま変更しません。
続いてプラグインのPHPコードを変更します。管理画面の「プラグイン」＞「インストール済みプラグイン」で、プラグイン一覧を表示させます。
↑プラグイン「BackWPup」の「編集」をクリック。「backwpup-functions.php」というファイルを見つけたら編集画面を表示させます。
↑ありました。
↑600を6000に増やしました。
↑再び「BackWPup」の管理画面に移動。すぐにバックアップ処理を実行させたい時は「Run Now」をクリックします。さあ～、うまくいくか。
↑ドキドキ…
↑ソワソワ………
前回はここから先に進むことなく全滅だったのですが、さてどうなるか…
エラーになりました……orz
30分経ってもウンともスンとも言わない辺りで、ものすごくイヤ～な予感はしてました。
今回設定し直した6000秒（1時間40分）が経過するまで待ちましたが、結果は上の通り。10分でも100分でも結局はタイムアウトでした。
待ち耐性がないので、2回目でまた100分待つなんて考えられず、ここで強制終了させました。
なんでだろ。そんなに我が家のネット環境って悪いんだろうか。回線遅いとか？ 光なんだけどなぁ。そういう問題じゃないのかな。
↑ただ、ログの表示が1時間40分もの間ずっと固まってるときにも、裏でサーバーには正常にバックアップが保存されていました。要は今回もDropboxへの保存だけが失敗しているという状況。
その後もいろいろと設定を変更してテストを続けましたが、ことごとく失敗。
作業が深夜に及んでしまい、睡魔も襲ってきたので、ひとまずDropboxの認証を解除し、上で設定した「6000秒」を「1200秒（20分）」に変更し、落胆しつつ眠りについたのでありました。
翌朝、設定をまた変更して再々テスト
そして翌朝、ファイルサイズを確認。
↑上は昨夜失敗した際のログなのですが、一番上の行で「144.77MB」と表示されています。これが私の「圧縮されたバックアップデータのサイズ」でした。
サイズが150MBを超えるとDropboxのAPIがエラーにしてしまう、という件はいろいろ調べて把握済みだったので、144MBなら大丈夫だろうと考えていました。
ところが、144MBも微妙なラインなのではないかとの意見も。
さらに「データベースのみバックアップしてみるのはどうか」とアドバイスを頂きました。
早速やってみました。
↑BackWPupの設定画面、右上にある「Job Type」を「データベースのバックアップ」1つだけの指定に変更。
Dropboxへの認証も完了し（認証したり解除したり何回くり返してんのって話ですが）、バックアップ処理を実行。
↑バックアップ成功！ 「やったー！」というより、「あらま！」という感じ。
データベースのみをバックアップ対象にしたことにより、ファイルサイズは「19.13MB」と大幅に小さくなっています。処理時間はわずかに「1分8秒」。
ってことは、やっぱり「ファイルサイズが大きい」ことが問題だったのか…。
↑Dropboxに保存されたというメッセージも表示されました。
↑エクスプローラーで確認すると、Dropboxの該当フォルダにはバックアップファイルがキチンと保存されてる。
↑サーバー側も保存成功していました。Dropboxとサーバーの2箇所にバックアップファイルを保存できたということになります。
ひとまず成功してホッとしました。ご協力いただいた方々、ありがとうございました。
今後は、データベースだけのバックアップではプラグインの意味がないので、ファイルサイズを小さくするためにいろいろ対象となるデータやファイルを絞り込んでいかないといけないですね。
ということで、今回のテストで得た知識。
◆ファイルサイズは極力抑える（150MB前後はエラーになる）
これに加えて、
プラグイン内の時間制御を600秒から6000秒に改造しましたが、プラグインがアップデートされたら当然上書きされて改造内容が消えちゃうので、再び改造する必要があります。
上記に加えて。
上の記事では「BackWPup」によるバックアップ方法の解説だけでなく、リストア（復元）作業も実際にテストされていて、その解説も詳しく記事にされています。ものすごく勉強になりました。
私はさすがにローカル環境ですらスクラップ＆ビルドで復元テストをする度胸がありませんでした。ですので上の記事は速攻でブックマークさせていただきました。
いつか私のブログが斃（たお）れてしまった時には、こちらの記事を参考にカムバックしたいと思っています。
【2013年2月追記】
その後もいろいろと試行錯誤を重ね、現在はバックアップ処理を分散させることでDropboxとサーバの両方にバックアップするようにしてます。記事を書きましたので合わせて読んで頂ければ幸いです。
バックアップ大事！BackWPupの設定は現在こんな感じで落ち着きました
WordPressのデータやファイルをバックアップしてくれるプラグイン「BackWPup」。保存する容量が大きくなったせいもあり最近エラーが多発していたため、バックアップ方法を見直してみました。
