ブログがいない　続報

さて前回「ブログがいない」という記事で、当ブログサイトに一時的にアクセスできなくった経緯と、そのときの対応についてご紹介しましたが、これはちょっと場当たり的すぎたかな、と。

まず前提ですが、このブログはレンタルサーバとして「CONOHA WING」
CMS（注１）としてWORDPRESSを使用しています。

注１）CMSとはContents Management Systemの略で、ブログを個人で簡単に運用できる仕組みのことです。

アクセスできなくなった原因は、CONOHA WINGの初期容量300GBを超えてしまったからなのですが、早急に対応するため400GBの契約に更新しました。
この時点ではWORDPRESS自体がどれくらい容量を消費するものかわからなかったためこのような措置をとっています。
ご存知の通り、当ブログは写真を多用しているため短絡的にそのせいだろうと考えてしまったわけです。現在すでに8,000枚を超える写真データが登録されています。
ただ、落ち着いて考えるとこの写真データは毎回圧縮の上登録しており、ファイルサイズは1枚あたり約1MB。
単純にいうと、1,000MB=1GBですからこれだけでは8GBにしかなりません。
おかしいなぁと思いつつ、今回の対応でまぁこの先何年かは何もする必要がないだろうと考えていました。
ところが１週間後、使用容量を確認すると315GB。
確かに毎日ブログの登録は行なっていますが、１週間で15Gの消費は異常です。
このままでは100GBあっても1年どころか2ヶ月持ちません。
ちょっと真面目に調べてみます。
まず、どこで消費しているか。

とりあえずWORDPRESSの機能で確認します。

アップロードディレクトリのサイズが大きくなりすぎています。
注）このサイズは、これ以降の作業で不要な領域を削除しても変わりませんでした。
　　一旦確保したら、解放されないのか（CONOHA側から見ると解放されているようですが）、一度大きくなった情報は小さくはならないのかちょっとわかりません。
WORDPRESSではこれ以上の情報は得られそうになかったのでCONOHA の方から調べてみることにします。

CONOHAのファイルマネージャーの機能を使います。
アップロードディレクトリの階層構造はこんな感じ。

各年度のデータ以外にBACKUPのディレクトリがあります。
BACKUPディレクトリの下にはec5ce9。
これはぼくの契約番号になるはずですので、バックアップデータはこの下に作られるはずです。
ここで気になるのがbackup-ec5ce9-backupというディレクトリ。
なんだこれは？

中を見てみると、ここだけで238GB。
作成されているファイル名とあわせて考えると、これはあれですね。
バックアップファイルのバックアップファイル。
ちょっととんでもないことをしてくれています。

これはWORDPRESSのPluginのBackWPupの仕業です。
とりあえずこれを削除すれば良いわけですが、同じ運用を続けるとそのうちまた同じことをしでかします。
さてどうしよう。
当初はCMSでバックアップを取るのは当然だろうと考えて入れたBackWPupでしたが、改めて他のサイトを調べると使いづらいとか設定変えたらバックアップのバックアップをとってしまうとかいう評判が見えます。
で、今回別に気がついたのがCONOHAの方で毎日バックアップをとってくれているようです。
こんな感じ。

これでいいや。決めました。WORDPRESS側でバックアップを取るのはやめます。
BackWPupが作ったファイルを消し、スケジュールからも消去します。
結果こうなりました。

実際使っていたのは35GB程度でした。

契約変更する必要なかったじゃん。

まあ変更で、サーバー側のメモリやCPUも上がっているので、今回はもういいことにします。
契約の方は戻しません。

ということで、あと20年くらいはブログが書けそうです。
なおバックアップについては個人の判断なので、WORDPRESS側でバックアップをとっておきたいとお考えの方はそちらで対応してください。
もしWORDPRESS側で取るのであればBackWPupよりはUpdraftPlusの方が良さそうです。

それから今まで写真データをおあげる時、圧縮してからWORDPREESSに取り込んでいましたがWP-OptimizeというPluginを入れておくと、アップロードの際勝手に圧縮してくれるようです。よろしければお試しください。取り込み済みのデータの圧縮にも使用できます。