【おしらせ】RSSフィード配信を停止しました

KUSANAGI(ConoHa VPS)のWP-CLIとOSのCRONを使って自動データーベース最適化&自動バックアップをする

KUSANAGI for ConoHa
この記事は約9分で読めます。

本稿ではKUSANAGI(ConoHa VPS)のWP-CLIで自動データーベース最適化および自動バックアップする方法について記します。

WP-CLIはKUSANAGIに予め入っています。
これを使わない手はありません。
さらにOSのcronと組み合わせることで多大な効果を得られます。
wp-optimizeなどデータベース管理プラグインを外すことができますし、ConoHaに支払うバックアップオプション料金を節約できます。

アイキャッチの画像はKUSANAGIのイメージキャラクター草薙沙耶 ©PRIME STRATEGY

スポンサーリンク
この記事を読む方へのオススメ

WP-CLIについて

WP-CLIとは?

WP-CLIは、ざっくり言うと、超便利なコマンドラインツール。
コマンドライン一覧を見ればわかりますが、もう本当に色々なことができます。

WP-CLI Commands | WordPress Developer Resources

「KUSANAGI MAGAZINE」でもコラムで採り上げられています。
もっと詳しく知りたい方は読んでみてください。

コマンドラインでWordPressを効率的に管理する。
こんにちは 超高速WordPress仮想マシンKUSANAGIを開発している田島と申します。今回はWordPressを管理するにあたって便利な機能について紹介します。 目次 1. 黒い画面2. WP

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は後者、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)を与えます。

解答者の写真
よくわからなければ755にしておいてください

シェルスクリプトが動作するかチェックします。

$ /home/kusanagi/(プロファイル名)/sh/wpoptimize.sh

動かない場合は実行権を与え忘れているか記述ミスの可能性が高いです。

cronに設定する

/etc/crontabを開きます。
例として、毎日夜7時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」ってエラー!?

エラーじゃないわ
ちゃんと最適化されてるから大丈夫

詳しいことは次の記事で説明されています。

OPTIMIZEした際に、Table does not support optimize, doing recreate + analyze instead と出てきたときの対処法
目次 1 テーブルのOPTIMIZEをしたら、Table does not support optimize, doing recreate + analyze insteadと出てきた2 OPTIMIZEはできているので問題ない テーブル

それ以外で動かない場合は次のファイルをチェックしてください。
cronの方のログファイルです。

/var/log/cron

エラーが出ていて、何かしら手掛かりがわかるはずです。

パーミッションエラーが出ている場合は「kusanagi、www、wheel」の各グループに属する作業ユーザーを作ってみてください。
WAFを設定している場合は切ってみてください。

スポンサーリンク

WP-CLIとcronを使った自動バックアップ

プラグインBackWPupのセッティング

BackWPupをインストールする。

BackWPupはWordPressの超定番バックアッププラグインです。

BackWPup – WordPress Backup Plugin
WordPress の完全自動バックアップを予約します。保存するコンテンツ (Dropbox、S3など) を指定できます。これは無料版です。

管理画面サイドバーの「プラグイン」→「新規追加」から「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)。
注意すべきはパーミッション。
適切に設定しないとエラーが出て保存できません。

「ファイルを削除」は一週間分の「7」に設定しています。

BackWPupが動かない場合

理由の一つとして考えられるのはパーミッションエラーです

作業ユーザーと所有者・所有グループが一致しているか確認します。
違っていればchownコマンドで一致させてから755に設定してみてください。
ただパーミッション周りの問題については、kusanagiの他に作業ユーザーを作る方が確実かつ汎用的です。

WEXALの場合は最適化除外を忘れていないかチェックしてください。

WP-CLIのBackWPup操作コマンド

WP-CLIにはBackWPupを操作するコマンドがあります。

s wp backwpup start (ジョブID)

これをcronに登録することで自動化します。

ジョブIDはジョブ名をホバーする(マウスを乗せる)とわかります。
例えばジョブ名を「autobk」とするなら、こんな感じです。

シェルスクリプトの作成

解答者の写真
手順はデータベース最適化の時と同じです

backwpup.shというシェルスクリプトを作ります。
中身に次の記述をします。
例として、ジョブIDは「1」としておきます。

#!/bin/sh
cd /home/kusanagi/belle/DocumentRoot
/usr/local/bin/php /usr/local/bin/php /(シェルスクリプトのパス)/wp backwpup start 1

質問者の写真

実行権(x)の付与を忘れないで!
データーベース最適化のときと同じだよ!

シェルスクリプトが動作するかチェックします。

$ /(シェルスクリプトのパス)/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です。
それ以外ですと、本稿の記述で動くとは限りません。
もし間違いなく記述も設定も正しいのに動かない場合。
自分と似た環境の方の記事を探して、他の記述を試してみてください。

スポンサーリンク

まとめ

質問者の写真

楽ちん! 便利! プラグインが減った!
解答者の写真
WP-CLIは慣れると色々できます
他についても今後紹介していきますね!
タイトルとURLをコピーしました