本稿ではKUSANAGI（ConoHa VPS）のWP-CLIで自動データーベース最適化および自動バックアップする方法について記します。
WP-CLIはKUSANAGIに予め入っています。
これを使わない手はありません。
さらにOSのcronと組み合わせることで多大な効果を得られます。
wp-optimizeなどデータベース管理プラグインを外すことができますし、ConoHaに支払うバックアップオプション料金を節約できます。
アイキャッチの画像はKUSANAGIのイメージキャラクター草薙沙耶 ©PRIME STRATEGY
WP-CLIについて
WP-CLIとは？
WP-CLIは、ざっくり言うと、超便利なコマンドラインツール。
コマンドライン一覧を見ればわかりますが、もう本当に色々なことができます。
「KUSANAGI MAGAZINE」でもコラムで採り上げられています。
もっと詳しく知りたい方は読んでみてください。
WP-CLIの一般的な使い方
WP-CLIを動かすには、WordPressをインストールしているフォルダへ移動する必要があります。
$ cd /home/kusanagi/（プロファイル名）/DocumentRoot
移動したらコマンドを叩けばOKです。
CRONについて
cronは、あるコマンドを設定したスケジュール（時間）に従って実行してくれるコマンドです。
CRONにはWordPress上で動くWP-cronとUNIX系OSのcronがあります。
KUSANAGIのCentOSもUNIX系OSの一つであり、後者のcronが積まれています。
以下、後者のcronを単に「cron」と呼びます。
ちなみに前者のWP-cronは記事の投稿予約などで使われます。
ただサーバーに負荷がかかったりセキュリティ上の問題もあることから、使わないなら機能を止めてしまうこともあります。
（この辺りは別稿にて記す予定です）
WP-CLIとcronを使った自動データベース最適化
WP-CLIのデータベース最適化コマンド
WP-CLIにはデータベース最適化コマンドがあります。
s wp db optimize
これをcronに登録することで自動化します。
シェルスクリプトの作成
wpoptimize.shというシェルスクリプトを作ります。
（拡張子さえ.shなら名前はなんでもいい）
中身に次の記述をします。
#!/bin/sh cd /home/kusanagi/belle/DocumentRoot /usr/local/bin/wp db optimize
シェルスクリプトをサーバーにアップします。
どこでもいいのですが、ここではプロファイルの下にSHフォルダを作り、その直下にアップロードします。
アップしたら実行権（x)を与えます。
シェルスクリプトが動作するかチェックします。
$ /home/kusanagi/（プロファイル名）/sh/wpoptimize.sh
動かない場合は実行権を与え忘れているか記述ミスの可能性が高いです。
cronに設定する
/etc/crontabを開きます。
例として、毎日夜７時30分に実行する場合、一番下の行に以下の記述をします。
シェルスクリプトの場所は前項と同じです。
30 19 * * * （作業ユーザー名） /home/kusanagi/（プロファイル名）/sh/wpoptimize.sh >>/home/kusanagi/（プロファイル名）/DocumentRoot/wp-content/uploads/wpotimize.log 2>&1
作業ユーザーは例えば「kusanagi」など。
uploadsフォルダにエラーログを出力しています。
*の意味はcrontabファイル内に説明があります。
左から「分・時・日付・月・曜日」です。
必要に応じて変更してください。
動作テスト
とりあえず10分後くらいに設定してみて動くかテストします。
ログに結果が吐き出されていればOK。
注意点として、ログを見た時に驚くかもしれません。
「Table does not support optimize, doing recreate + analyze instead」ってエラー!?
エラーじゃないわ
ちゃんと最適化されてるから大丈夫
詳しいことは次の記事で説明されています。
それ以外で動かない場合は次のファイルをチェックしてください。
cronの方のログファイルです。
/var/log/cron
エラーが出ていて、何かしら手掛かりがわかるはずです。
パーミッションエラーが出ている場合は「kusanagi、www、wheel」の各グループに属する作業ユーザーを作ってみてください。
WAFを設定している場合は切ってみてください。
WP-CLIとcronを使った自動バックアップ
プラグインBackWPupのセッティング
BackWPupをインストールする。
BackWPupはWordPressの超定番バックアッププラグインです。
管理画面サイドバーの「プラグイン」→「新規追加」から「BackWPup」で検索してインストールしてください。
WEXALのみの手順
以下のフォルダを「最適化除外」してください
デフォルトなら「backwup-○○-backups」、「backwup-○○-temp」、「backwup-○○-logs」。
変更するなら、変更後のバックアップフォルダ・作業フォルダ・ログ格納フォルダ。
BackWPupを設定する
管理画面サイドバーの「BACKWPup」から「設定」を開きます。
以下は私の設定です。
必要に応じて変更してみてください。
一般
全てチェックなし
ジョブ
「サーバーの負荷を軽減」だけ「最大」に変更。
ログ
デフォルトのまま。
サイトネットワーク
認証方法は「なし」。
WP-CLIで動かすわけですから不要です。
APIキー
設定不要です。
BackWPupのジョブを作成する
管理画面サイドバーの「BACKWPup」から「新規ジョブを追加」を開きます。
一般
「このジョブの名前」は任意の名前を入力。
「このジョブは…」は全てにチェック。
「アーカイブ名」はデフォルトのまま。
「アーカイブ形式」は「Zip」。
どれでもいいのですが、Zip形式が扱いやすいと思います。
「バックアップファイルの保存方法」は「フォルダーへバックアップ」にチェック。
ログ関連は、必要なら自分のメールアドレスを入力。設定しておいた方が無難でしょう。
また、パーミッションを適切に設定しないと出力されません。
スケジュール
「手動」を選択します。
DBバックアップ
バックアップするテーブルは「全て」。
バックアップファイル名と形式は任意。
ただサーバーの容量に余裕があるなら、圧縮しない方が扱いやすいと思います。
ファイル
KUSANAGIの場合、ここは注意してください。
まず最初に一番下までいきます。
「特殊ファイルを含める」と「1階層上のフォルダーをWPインストールフォルダーとして使用する」にチェックを入れます。
一旦「変更を保存」を押します。
wp-config.phpの場所を変えているはずなので、そうしないとバックアップされません。
（ただしバックアップ不要ならデフォルトでも構いません）
あとは任意で。
私の場合について、以下に列挙します。
- プラグインはバックアップしていません。リストさえあれば復元できるので。
ただしプラグインの仕様変更で旧版が欲しくなったときなど、バックアップしてあれば対応できます。 - uploadsフォルダはキャッシュフォルダや作業フォルダは除外しています。つまりメディアフォルダだけです。
- 「uploads 内のサムネイル」は「バックアップしない」にチェックを入れてます。後で作り直せばいいので。
XMLエクスポート
「すべてのコンテンツ」を選択。
残りはデフォルトです。
プラグイン
デフォルトのままです。
DBチェック
「WordPressテーブルのみ」にチェックを入れています。
宛先：フォルダー
フォルダーは任意の場所に設定します（デフォルトで指定されている場所でOK）。
注意すべきはパーミッション。
適切に設定しないとエラーが出て保存できません。
「ファイルを削除」は一週間分の「７」に設定しています。
BackWPupが動かない場合
理由の一つとして考えられるのはパーミッションエラーです
作業ユーザーと所有者・所有グループが一致しているか確認します。
違っていればchownコマンドで一致させてから755に設定してみてください。
ただパーミッション周りの問題については、kusanagiの他に作業ユーザーを作る方が確実かつ汎用的です。
WEXALの場合は最適化除外を忘れていないかチェックしてください。
WP-CLIのBackWPup操作コマンド
WP-CLIにはBackWPupを操作するコマンドがあります。
s wp backwpup start （ジョブID）
これをcronに登録することで自動化します。
ジョブIDはジョブ名をホバーする（マウスを乗せる）とわかります。
例えばジョブ名を「autobk」とするなら、こんな感じです。
シェルスクリプトの作成
backwpup.shというシェルスクリプトを作ります。
中身に次の記述をします。
例として、ジョブIDは「１」としておきます。
#!/bin/sh cd /home/kusanagi/belle/DocumentRoot /usr/local/bin/php /usr/local/bin/php /（シェルスクリプトのパス）/wp backwpup start 1
データーベース最適化のときと同じだよ！
シェルスクリプトが動作するかチェックします。
$ /（シェルスクリプトのパス）/backwpup.sh
cron設定＆動作テスト
/etc/crontabを開きます。
例として、毎日夜2時30分に実行する場合、一番下の行に以下の記述をします。
30 2 * * * （作業ユーザー名） /（シェルスクリプトのパス）/backwpup.sh >>/home/kusanagi/（プロファイル名）/DocumentRoot/wp-content/uploads/wpbackwpup.log 2>&1
保存したらテストします。
動けばWordPress上でもBackWPupの「ジョブ」タブを開くことで確認できます。
エラーが出た場合は、先程とはログファイルが違うことに御注意ください。
備考 環境による違い
私のKUSANAGIはConoHa VPSです。
それ以外ですと、本稿の記述で動くとは限りません。
もし間違いなく記述も設定も正しいのに動かない場合。
自分と似た環境の方の記事を探して、他の記述を試してみてください。
まとめ
他についても今後紹介していきますね！
コメント