本稿ではKUSANAGIでWP-CLIとcronを使ってデーターベース最適化およびバックアップを自動化する方法について記します。
WP-CLIはKUSANAGIに予め入っています。
非常に便利なので使わない手はありません。
さらにOSのcronと組み合わせることでスケジュールに従った自動化が可能になります。
その帰結としてwp-optimizeなどデータベース管理プラグインを外すことができます。
サーバーに支払うバックアップのオプション料金を節約できます（例えばConoHaは有料）。
なお、KUSANAGI9のバージョン9.6.1-1で動作確認しています。
アイキャッチの画像は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」と呼びます。
前者のWP-cronは記事の投稿予約などで使われます。
ただサーバー負荷やセキュリティ上の問題もあることから、使わないなら機能を止めてしまうこともあります。
WP-CLIとcronを使った自動データベース最適化
WP-CLIのデータベース最適化コマンド
WP-CLIにはデータベース最適化コマンドがあります。
s wp db optimize
これをcronに登録することで自動化します。
シェルスクリプトの作成
wpoptimize.shというシェルスクリプトを作ります。
（拡張子さえ.shなら名前は任意）
中身に次の記述をします。（KUSANAGI9の場合）
#!/bin/sh cd /home/kusanagi/（プロファイル名）/DocumentRoot /usr/local/bin/php /opt/kusanagi/bin/wp db optimize --allow-root
KUSANAGI8の場合はwpファイルの場所が異なります。
/usr/local/bin/wp
シェルスクリプトをサーバーにアップします。
どこでもいいのですが、ここではプロファイルの下にSHフォルダを作り、その直下にアップロードします。
/home/kusanagi/（プロファイル名）/sh
アップしたら実行権（x)を与えます。
パーミッションを755に設定してください。
シェルスクリプトが動作するかチェックします。
ファイル名がwpoptimize.shの例です。
$ /home/kusanagi/（プロファイル名）/sh/wpoptimize.sh
動けば結果が滝のように表示されるのでわかります。
動かない場合は実行権を与え忘れているか記述ミスの可能性が高いです。
cronに設定する
次のコマンドを打ち込みます（rootログインなら１行目は不要）
sudo su
crontab -e
編集画面が開きます。
KUSANAGIの場合、恐らく次の記述がされていると思います。
07 03 * * 0 /opt/kusanagi/bin/kusanagi update cert
この下に次の記述を追加します。
ファイル名がwpoptimize.shの例です。
1 15 * * * （シェルスクリプトのパス）/wpoptimize.sh >>/home/kusanagi/（プロファイル名）/DocumentRoot/wp-content/uploads/wpotimize.log 2>&1
シェルスクリプトのパスは、本稿に従った場合は以下です。
/home/kusanagi/（プロファイル名）/sh
以下、最小限必要な説明のみさせていただきます。
1 15 * * *は「毎日15時1分にデータベース最適化を実行する」です。
自分に合わせて調整してください。
残りの*（アスタリスク）は「日・月・曜日」です。
wpotimize.log 2>&1
これはエラー出力も標準出力ファイルにまとめて出力するという意味。
変更の必要はありません。
動作テスト
とりあえず10分後くらいに設定してみて動くかテストします。
ログに結果が吐き出されていればOKです。
注意点として、ログを見た時に驚くかもしれません。
「Table does not support optimize, doing recreate + analyze instead」ってエラー!?
エラーじゃないわ
ちゃんと最適化されてるから大丈夫
動かない場合はログファイルをチェックしてみてください。
less +F /var/log/cron
手掛かりが掴めるかもしれません。
パーミッションエラーが出ている場合は「kusanagi、www、wheel」の各グループに属する作業ユーザーを作ってみてください。
WAFを設定している場合は切ってみてください。
WP-CLIとcronを使った自動バックアップ
プラグインBackWPupのセッティング
BackWPupをインストールする。
BackWPupはWordPressの超定番バックアッププラグインです。
管理画面サイドバーの「プラグイン」→「新規追加」から「BackWPup」で検索してインストールしてください。
WEXALの設定
元々KUSANAGI・WEXALユーザー対象の記事ですが、それゆえの注意点を記しておきます。
BackWPupの他にWEXALの設定も必要となります。
具体的には、「backwup-○○-backups」、「backwup-○○-temp」、「backwup-○○-logs」など。
バージョンによって名前が違うかもですし、場所も違うかもしれません。
御自身の環境にあわせて確認してください。
以前のWEXALではパーミッションエラーを起こしました。
現在は異なるかもしれませんが記しておきます。
BackWPupを設定する
管理画面サイドバーの「BACKWPup」から「設定」を開きます。
以下は私の設定です。
必要に応じて変更してみてください。
ジョブ
「サーバーの負荷を軽減」だけ「最大」に変更。
ログ
デフォルトのまま。
サイトネットワーク
認証方法は「なし」。
WP-CLIで動かしますから不要です。
APIキー
設定不要です。
BackWPupのジョブを作成する
管理画面サイドバーの「BACKWPup」から「新規ジョブを追加」を開きます。
一般
「このジョブの名前」は任意の名前を入力。
「このジョブは…」は全てにチェック。
「アーカイブ名」はデフォルトのまま。
「アーカイブ形式」は「Zip」（自分の操作できる形式ならどれでもいいです）
「バックアップファイルの保存方法」は「フォルダーへバックアップ」にチェック。
ここは各人によります。
ログ関連は、必要なら自分のメールアドレスを入力。設定しておく方が無難です。
また、パーミッションを適切に設定しないと出力されません。
スケジュール
「手動」を選択します。
DBバックアップ
バックアップするテーブルは「全て」。
バックアップファイル名は任意。
形式も任意ですが圧縮した方がいいと思います。
ファイル
詳しくはこちらをどうぞ
XMLエクスポート
「すべてのコンテンツ」を選択。
残りはデフォルトです。
プラグイン
チェックを外します。
DBチェック
「WordPressテーブルのみ」にチェックを入れています。
宛先：フォルダー
場所はデフォルト（もちろん任意の場所でOKです）。
注意すべきはパーミッション。
適切に設定しないとエラーが出て保存できません。
「ファイルを削除」は一週間分の「７」に設定しています。
BackWPupが動かない場合
理由の一つとして考えられるのはパーミッションエラーです
作業ユーザーと所有者・所有グループが一致しているか確認します。
違っていればchownコマンドで一致させてから755に設定してみてください。
WEXALの場合は最適化除外を忘れていないかチェックしてください。
WP-CLIのBackWPup操作コマンド
WP-CLIにはBackWPupを操作するコマンドがあります。
s wp backwpup start （ジョブID）
これをcronに登録することで自動化します。
ジョブIDはジョブ名をホバーする（マウスを乗せる）とわかります。
例えばジョブ名を「autobk」とするなら、こんな感じです。
シェルスクリプトの作成
fullbackwup.shというシェルスクリプトを作ります。
中身に次の記述をします。
例として、ジョブIDは「１」としておきます。
#!/bin/sh cd /home/kusanagi/belle/DocumentRoot /usr/local/bin/php /opt/kusanagi/bin/wp backwpup start 1 --allow-root
アップロードしたらパーミッションを設定。
シェルスクリプトが動作するかチェックします。
ファイル名が「fullbackwup.sh」の例です。
$ /（シェルスクリプトのパス）/fullbackwup.sh
cron設定＆動作テスト
データベース最適化の時と同じです。
sudo su
crontab -e
編集画面が開きますので次の記述を追記します。
ファイル名が「fullbackwup.sh」の例です。
10 3 * * 0 （シェルスクリプトのパス）/fullbackwup.sh >>/home/kusanagi/（プロファイル名）/DocumentRoot/wp-content/uploads/backwpup.log 2>&1
保存したらテストします。
WordPress上で「ジョブ」を開けば進行状況が表示されます。
エラーが出た場合はログファイルを確認してみてください。
備考 環境による違い
私の環境はKUSANAGI9、WEXAL（PST3.x）、ConoHa VPSです。
それ以外ですと、本稿の記述で動くとは限りません。
もし間違いなく記述も設定も正しいのに動かない場合。
自分と似た環境の方の記事を探して、他の記述を試してみてください。
まとめ
楽ちん！ 便利！ プラグインが減った！
WP-CLIは慣れると色々できます
他についても今後紹介していきますね！
