WordPressのBackWpUpによる肥大化するバックアップファイルの対処方法（ついに300MB超えてしまった。）
WordPressのバックアップファイルの大きさをご存じですか？
私はブログをWordPressで書いています。
そのWordPressの環境をBackWpUpで丸ごとバックアップしていますが、バックアップファイルの大きさが、ついに300MBを超えてしまいました。
写真を沢山使ってブログを更新すると、どんどんとWordPressの環境が肥大化していきます。・・・ある意味仕方ないですね。
BackWpUpはWordpressのバックアップファイルを1つのZIP形式のファイルに圧縮したあと、クラウドのSugarSyncにファイル転送して万一サーバー環境に支障があってもバックアップファイルからリストア（復元）することで安全性を確保しています。
ところで、BackWpUpのログを見ると、300MBのファイルに対して、バックアップ全体で23分かかり、中でもSugarSyncへのファイル転送で17分かかっていることが分かりました。
- 2013/01/29 03:08.21: Archive size is 297.34 MB
- 2013/01/29 03:08.26: Upload to SugarSync now started…
- 2013/01/29 03:25.42: Job done in 1426 sec.
仮に2012年の1年間だけ限定してバックアップすると、バックアップファイルの大きさが168MBもあり、このままバックアップ方法を変えなければ来年の今頃は470MB、3年後には800MBに膨れ上がり、ある閾値を超えたところでバックアップできなくなったり、リストアできなくなったりします（するはずです）。
それが、明日かもしれないし、1年後かもしれません。
そのため、バックアップファイルの大きさを知っていた方が良いと思います。
バックアップやリストアが出来なくなる理由はいろいろ考えられますが、SugarSyncが大きくなり過ぎたファイルのアップロードを拒否する場合、転送時間が長くなり過ぎてネットワークがタイムアウトする場合、サーバを管理しているレンタルサーバ会社がネットワーク負荷を警戒して遮断する場合などがあります。
そこで、バックアップやリストアで身動きが取れなくなる前に、その対策を行うことにしました。
対策の概要
大きくなりすぎるバックアップファイルを①2010年～2012年までの過去の全データのバックアップ と ②2013年以降のバックアップに分割してバックアップすることにします。
①の過去のバックアップファイルは300MB程度の大きさになりますが、現在この大きさのファイルをバックアップ出来ているので今後も大丈夫だと思われます。
また過去のデータなので今後ファイルの大きさが増えることはありません。
バックアップは週1回実行する。・・・過去のデータなので修正しないと思うけど、絶対修正しないとは言い切れないので、このくらいの低頻度でバックアップします。
②のバックアップファイルは現状で35MB程度あり、ブログを更新するとこのバックアップファイルが大きくなっていきます。
バックアップは毎日実行する。・・・更新頻度が高いので、毎日バックアップを実行します。
バックアップ方法
下の画面が、バックアップジョブの一覧です。
1番上のジョブは今まで実施していた全データのバックアップジョブです。今後これを使う予定はありません。
2番目のジョブは①2010年～2012年までの過去の全データのバックアップジョブです。（データの容量が増えることはありません。）
3番目のジョブは②2013年以降のデータのバックアップジョブです。（データの容量が増えます。）
①のバックアップジョブの詳細画面です。
どうもピンとこないのですが、Blog Uploadsでは、Exclude（除外）を指定します。
そのため、2010年・2011年・2012年のデータのバックアップを取得したいときは、除外する2013年をチェックします。
バックアップは毎週（Weekly）月曜日の2時から開始します。
※ ①で取得したバックアップファイルを「2010-2012_blog_2013-01-30_00-00-15.zip」として説明します。
②のバックアップジョブの詳細画面です。
同様にBlog Uploadsで、Exclude（除外）を指定します。
そのため、2013年以降のデータのバックアップを取得したいときは、除外する2010年・2011年・2012年をチェックします。
バックアップは毎日（Daily）月曜日の3時から開始しします。
※ ②で取得したバックアップファイルを「2013_blog_2013-01-29-23-55-14.zip」として説明します。
これで火曜日～日曜日まで午前3時に毎日バックアップジョブが開始され、たった3分程度で終了します。そして月曜日だけ全データのバックアップが開始されますが、これも午前2時と午前3時の2回に分けて行われるので、サーバやネットワークにかかる負荷が分散されます。
実際にリストアしてみると・・・
いきなり本番環境でリストアのテストをしてはいけません。
必ず、予備のテスト環境を用意して、リストアが出来ることを確認をしてから本番環境にリストアしてください。
リストア方法
ここでリストア方法を2つに分けます。
① バックアップファイルの中身をftpやWinSCPソフトを使って公開サーバのWordpressのファイルに上書きできる場合（ほとんどの人がこちらだと思います。）
Windowsパソコンで「2010-2012_blog_2013-01-30_00-00-15.zip」と「2013_blog_2013-01-29-23-55-14.zip」を解凍して、古いデータ「2010-2012_blog_2013-01-30_00-00-15」に新しいデータ「2013_blog_2013-01-29-23-55-14」を上書きして1つに纏めます。
纏めたファイルは公開サーバのWordpressの階層構造と同じものなので、公開サーバに上記ソフトでファイル転送して上書きします。
※ 古いデータを公開サーバに転送してから新しいデータを転送して上書きしても一緒ですが、トラフィックが無駄なので、パソコンで1つに纏めてから転送する方法をお勧めします。
この時点で、BackWpUpのToolsを選択するとRestoreボタンが表示されるので、このボタンを押してデータベースを復元します。
これでリストア作業はお終いです。
問題なくリストア出来ていることを確認します。
② バックアップファイルの中身をftpやWinSCPソフトを使って公開サーバのWordpressのファイルに上書きできない場合。（私の場合はこちらです。）
Windowsパソコンでバックアップしたデータの「2010-2012_blog_2013-01-30_00-00-15.zip」と「2013_blog_2013-01-29-23-55-14.zip」からWordpress.sqlを取り出します。
この時点で、ファイルが4つあります。
- 2010-2012_blog_2013-01-30_00-00-15.zip と これから取り出したwordpress.sql
- 2013_blog_2013-01-29-23-55-14.zip と これから取り出したwordpress.sql
- 上記wordpress.sqlは同じものなので、どちらか一方あれば大丈夫です。
これらの3つのファイルを公開サーバのwordpressの一番上の階層（ルート）にftpやWinSCPソフトを使ってファイル転送します。
この時点で、BackWpUpのToolsを選択するとRestoreボタンが表示されるので、このボタンを押してデータベースを復元します。
次にサーバにリモートログインし、「2010-2012_blog_2013-01-30_00-00-15.zip」 と 「2013_blog_2013-01-29-23-55-14.zip」を解凍して元の環境に上書きして画像データをリストアします。
下の画面は、管理者（root）でログインし、unzipコマンドで2010-2012_blog_2013-01-30_00-00-15.zip（古いデータ）を解凍して上書きするところです。
続いて、同様に 2013_blog_2013-01-29-23-55-14.zip（新しいデータ）も解凍して上書きします。
基本的に古いデータを解凍して上書きしてから、新しいデータを解凍して上書きします。
# unzip -o 2010-2012_blog_2013-01-30_00-00-15.zip
# unzip -o 2013_blog_2013-01-29-23-55-14.zip
リストアしたファイルやフォルダの所有者が管理者（root）のままなので、apacheに変更します。
これは、自分のいる位置（カレント）を1つ上の階層に上げて、chown コマンドを実行します。
# cd ..
# chown -R apache:apache wordpress
これでリストア作業はお終いです。
問題なくリストア出来ていることを確認します。
＊＊＊ 2013年2月5日 追加 ＊＊＊
スケジュールどおりsugarsyncへの自動バックアップ、バックアップしたファイルのPCとの同期も問題なしです。
