WordPressサイトのホームページで、容量不足となった

ホームページに表示している画像、動画をアップしていて、どうもサイトが容量不足に陥っていると気が付きました。自分で「var/www/html」配下など、使用率を調べたりしてしながら削除操作していましたが、なかなか容量が回復せずに困っていましたが、盲点がありました。

サイトのデータをバックアップする目的で、「All-in-One WP Migration」プラグインを使っているのですが、この毎回のバックアップデータが、「/var/www/html/wp-content/ai1wm-backups」に溜まっていました5世代前までバックアップファイルがあったので、直前の世代以外を削除したところ、ディスク使用率96%が、79%まで回復しました。

また、バックアップ運用をしていく中で気が付きましたが、「/var/www/html/wp-content/ai1wm-backups」に蓄積されるバックアップは「エクスポート」操作を行うときに、そこにあるエクスポート媒体を含んだ上で、追加で新たなエクスポート媒体を作成し直すので、倍々で増えていってるんではないかなということです。

ある日、エクスポートファイルの容量が500MBを超えて、ファイル容量の制限に引っかかりました。初めは300MB無かったので、気が付かないうちに巨大化していたことになります。

で、それからは、「/var/www/html/wp-content/ai1wm-backups」に溜まっているエクスポートファイルを消してから(バックアック画面で、バックアップファイルを削除しても、OK!)、環境のエクスポートを実施しています。

また、「All-in-One WP Migration」プラグインは無償バージョンの場合は、ファイルの容量が500MB以内でなければエラーになります。また、最近ではその制限が非常に厳しくなり、30MBに減少しているという投稿を発見、all-in-one-wp-migration.6.74ならばその制限に引っかからないというので、ダウンロードしてきて適用しました。

さらにさらに、それでも容量が500MB に近づいてきた場合には、今度はエクスポート操作の際に、高度なオプション指定で「メディアライブラリをエクスポートしない (ファイル) 」を選んで、容量が500MBを超えないようにします。

そして、メディアファイル(/var/www/html/wp-content/uploads配下)は tar圧縮して、SCPでバックアップすることにします。
(メディアファイルを抜くと200MBぐらいになります)

この時、リカバリ時には、uploadsフォルダを元に戻すのですが、WordPress自体がファイルを掴みっぱなしの状態なので、まずuploadsフォルダをリネームします

(mv /var/www/html/wp-content/uploads /var/www/html/wp-content/uploads_old)

その上で、アクセス権限の制約があるので、/home/(ユーザ)などで解凍したuploadsフォルダを本番フォルダに移動します。

(mv /home/(ユーザ)/uploads /var/www/html/wp-content/.)

これでも表示に影響が出てくる場合には、システム自体を立ち上げ直しします。

便利なプラグインですが、落とし穴があるもんですな!