BLOG

BackWPupのバックアップ設定が不適切だとサーバ容量が圧迫されるので注意!

BackWPupはWordPressの便利なプラグイン。
ですが、適切に設定しないと、ちょっとした問題を引き起こしてしまうことがわかりました。

きっと同じような罠にハマる人がいると思うので、備忘録として記事にしておくことにします。

レンタルサーバ会社からこんなメールが来た

BackWPupによるCPU負荷増加問題ある日、メールボックスに来ていた一通のメール。

お客様のサーバーアカウントにおいてCPU負荷が著しく高い状況が確認されましたのでお知らせ致します。
(中略)
WordPressプラグイン「backwpup」に関係する処理が起動されており、高負荷の原因である可能性が非常に高くございます。

ぼくはこの文面を見てすぐにピンときました。
前日の夜に、WordPressの管理画面からある処理を実行していたのです。

原因: 大容量(30GB分)のバックアップファイル削除

高いCPU負荷が検出された原因は、BackWPupで大容量のバックアップファイル削除をおこなったため。

ぼくはBackWPupで、1日1回ブログのフルバックアップを行うように設定しています。
フルバックアップ1回あたりのファイルサイズは5GB程度で、これをレンタルサーバ上に生成しています。

これまでは過去のバックアップファイルを7つまで保持し、それより古いものは自動削除していくよう設定していました。

ところが、ブログ運営が長くなるにつれて、徐々に1回あたりのバックアップファイルサイズが大きくなってきていました。
その結果、サーバ上の総ファイル容量が契約50GBのところ使用容量41GBとなっていることに気が付きました。

このままでは、容量圧迫のおそれがある。
そう考えたぼくは、サーバ上のバックアップファイルの保持設定を7から1に変更しました。
これにより、5GB×6ファイル分で30GB分のファイルがいっぺんに削除されることになり、CPUに高い負荷がかかったというわけです。

対策: 大容量ファイルを削除する場合はいっぺんではなく分割して削除したほうが良い

いま思えば、保持するバックアップファイルを一日置きに7→6→……→2→1と減らしていけばよかったな。

一週間くらいかけて徐々にファイル削除していけばCPU負荷も分散できたはず。

これから同じようなことを予定している方は、ぜひそうした方がよろしいかと思います。
俺の屍を越えてゆけ……!

今後: バックアップファイルは古いものをひとつだけ残すことにしました

BackWPupによるCPU負荷増加問題同様の事態の再発を避けるため、今後もバックアップの保持設定は最新のひとつのみを保存するものとし、それより古いものは自動削除する設定で運用していくことにしました。

今回の負荷は、バックアップファイルを一括削除することによる負荷であったことから、今後同様の現象は再発しないはず。

加えて、週に一回、その時点のフルバックアップファイルをローカルにダウンロードして、それを一ヶ月分(4回分)手元に残しておくことにしました。

これならレンタルサーバ上に残るのは直近1日分のバックアップファイルだけだけど、手元には直近ひと月分のバックアップが残るので、何かあっても対応できるはず。
忘れないようTodoistに毎週繰り返しで登録しました。

当然ながらレンタルサーバのCPU資源を使い込んでしまうと機能制限される

ちなみに、今回レンタルサーバ会社から受けたメールによれば、レンタルサーバ会社側でBackWPupプラグインを強制停止させたとのこと。

レンタルサーバは一台の物理サーバのスペースをいくつかに区切って、そのスペースをユーザに貸し出しています。
なので、ひとりのユーザがサーバの資源を使い込むと他のユーザに影響が出てしまうため、こういう場合は強制的に機能を停止させるわけですね。

サーバ運営会社からすると至極当然の処置ですが、こちらとしてはバックアップを取れない状態が続くのはまずい。
速やかに対策、処置してメール返信するように書いてありましたので、すぐに原因の推定と今後の対策についてメールを返信しました。

その後、サーバ運営会社からみて高負荷状態がみられなくなったことを確認してもらい、元の状態に戻してもらいました。
あ〜、もとに戻ってよかった……!

まとめ

今回はプラグインの停止だけで済んだけど、おかしな状態が長期間継続してしまったら他のユーザに迷惑がかかるばかりか、このブログの運営に影響が出ていたかも。
そう考えると、今回の件は一度考え直す良い機会になりました。

BackWPupはとても便利なバックアッププラグインなので使っているひとはたくさんいると思います。
だけど設定によっては、知らぬ間にバックアップファイルがたくさん生成されてしまって、サーバ容量を圧迫していたりするかも。
なので定期的に確認してみたほうが良いかもしれません。

また、蓄積したバックアップファイルを削除する際は、いっぺんに削除するのではなく、何回かに分割して削除したほうが良いと思います。

それにしても、こんな形でレンタルサーバから連絡を受けてしまうとは夢にも思わなかったな……。

皆様もお気をつけてくだされ!


このブログと、書いているひとについてはこちらへどうぞ。

紹介したスポットを記事リンク付きでまとめたGoogleマイマップはこちらです。

これまでの旅行記のまとめ記事はこちらから。


当ブログでは TCDのWordPressテーマ「CORE」を使用しています。



関連記事

  1. ブログの文字数計測にはChrome拡張機能「かんたん文字数カウン…
  2. ブログに書く物事の間口をもっと広くとってみてもいいのかな、と思っ…
  3. ブログタイトルにハッシュタグを入れるという試みについて。これから…
  4. WPtouchをデフォルトの設定から少し変更してみた。デフォルト…
  5. Embedlyにユーザ登録したら使えるオプションが増えてちょっ…
  6. Chrome Keyconfigに代わりブログのリンク挿入に「E…
  7. ブログのテーマを変更しました。レスポンシブデザインってほ…
  8. ウィジェット化したtwitterのタイムラインをWordPre…

これまでの旅行記 まとめ

travel summery

オーブン料理 チャレンジまとめ

oven challenge summery

パン屋さん巡り 記事まとめ

bread move around summery

山登り 記事まとめ

mountaineering summary

フジロック 記事まとめ

fujirock summery

ブログで紹介したスポット

mymap

twitterはこちら

PAGE TOP