XOOPSのバックアップ

XOOPSのバックアップってどうしてる?
「モジュール使ってる」。うーん、個人的にはバックアップみたいな万一の失敗の許されない機能は、モジュールに頼るよりも、もっと原始的で確実な方法の方がよいように思う。それにバックアップモジュールの多くはMySQLデータベースのバックアップはするけど、ファイルやディレクトリまでまとめてバックアップしてくれるものは少なくない?(俺が知らないだけ?)。
「えっ、うちはFTPで全ダウンロードだけど...」ブーッ。オールFTPだとクライアントがWindowsマシンだったりする場合、パーミッションが正常に保存されない。リストアするのに一苦労なんてことにもなる。大体、時間かかるでしょ?
「うちは、コントロールパネルからやってるよ」。うん、それでもいいんだけど面倒臭くない? せっかくUNIX環境で動いているんだからバックアップみたいな定期ジョブはコマンドでやるかシェルスクリプト書いて一撃で実行させたい。
XOOPSでサイトを構築した場合は、まずフルバックアップ取っておいて、後は毎日の差分を取るようにしたらいい。そうすれば万一のときのリストアも楽だ。

XOOPSでバックアップを取らなくてはいけない場所

とりあえずバックアップ取る時の場所を挙げておこう。

フルバックアップ

  • xoops_trust_pathディレクトリ
  • htmlディレクトリ
  • MySQLデータベース

デイリーバックアップ

  • xoops_trust_path/uploadsディレクトリ
  • html/uploadsディレクトリ
  • html/modules/xpwikiディレクトリ
  • MySQLデータベース

デイリーでは変更のありそうなディレクトリだけピックアップした。両uploadsディレクトリは画像等がアップロードされる場所。ただしxoops_trust_path/uploadsディレクトリはd3downloadsのファイルの置き場なので、結構巨大になることがある。オリジナルファイルを別に保管しているなら、デイリーからは外してもいいだろう。xpWikiは前にも説明したけどコンテンツの内容がMySQL内ではなくてファイルとして格納されているので取らなくてはいけない。MySQLはこれ取らないとCMSの意味がないので忘れないこと。
デイリー適用以外のディレクトリに変更があった(モジュールの追加やバージョンアップがあった)場合は、フルバックアップを取るようにしている。

MySQLのバックアップ・リストア

バックアップ

MySQLのバックアップを取る場合はmysqldumpコマンドを使う。

mysqldump データベース名 --user=データベースユーザー名 --password=パスワード --add-drop-table > ダンプファイル名

がコマンドの構文。例えばデータベース名「taked2_xoops」、データベースユーザー名「taked2_xoops」、パスワード「xxxxxxxx」、ダンプファイル名が「taked2_xoops.dump」だと次のようになる。

mysqldump taked2_xoops --user=taked2_xoops --password=xxxxxxxx --add-drop-table > taked2_xoops.dump

(--add-drop-tableが付いてるのはリストア時の手間を考えてのこと)

リストア

MySQLをリストアする場合は、mysqlコマンドを使う。

mysql データベース名 --user=データベースユーザー名 --password=パスワード < ダンプしたファイル名

上記のバックアップの例だと、リストアする場合は次の通り。

mysql taked2_xoops --user=taked2_xoops --password=xxxxxxxx < taked2_xoops.dump

ファイル/ディレクトリのバックアップ・リストア

バックアップ

ファイルやディレクトリのバックアップを取る場合は、tarコマンドを使う。

tar cvzf アーカイブ名.tar.gz ディレクトリ1 ディレクトリ2 ...

リストア

ファイルやディレクトリのリストアをする場合は、tarコマンドを使う。

tar xvzpf アーカイブ名.tar.gz

パーミションを正常に復元したい場合は「p」オプションを忘れないこと。これを忘れるとxpWikiとかで「パーミッションがおかしいよん」って言われることになる。

シュルスクリプト化

バックアップを取る場所が決まったら、シェルスクリプトにしておいた方が面倒がなくてよい。以下の例はうちの場合のバックアップ用のシェルスクリプト(このままコピっても動かないよ)。

  • fullbackup.sh
#!/bin/sh

/usr/local/mysql/bin/mysqldump taked2_xoops --user=taked2_xoops --password=xxxxxxxx --add-drop-table > taked2_xoops.dump
/bin/tar cvzf taked2_xoops_full_`date '+%Y%m%d'`.tar.gz public_html/default.artsoftwareworks.net xoops_trust_path taked2_xoops.dump
  • dailybackup.sh
#!/bin/sh

/usr/local/mysql/bin/mysqldump taked2_xoops --user=taked2_xoops --password=xxxxxxxx --add-drop-table > taked2_xoops.dump
/bin/tar cvzf taked2_xoops_daily_`date '+%Y%m%d'`.tar.gz public_html/default.artsoftwareworks.net/modules/xpwiki public_html/default.artsoftwareworks.net/uploads xoops_trust_path/uploads taked2_xoops.dump

後は出来上がったアーカイブファイル(taked2_xoops_full_XXXXXXXX.tar.gz、またはtaked2_xoops_daily_XXXXXXXX.tar.gz)をFTPでダウンロードすればいい。
リストアする場合は、tarでほどいて、ダンプファイル(taked2_xoops.dump)をmysqlに食わせる。

tar xvzpf taked2_xoops_full_XXXXXXXX.tar.gz
tar xvzpf taked2_xoops_daily_XXXXXXXX.tar.gz
mysql taked2_xoops --user=taked2_xoops --password=xxxxxxxx < taked2_xoops.dump

CRON設定

デイリーバックアップのように毎日実行するジョブはCRONジョブにしておいたほうが起動忘れがなくていい。CRONジョブの設定はCORESERVERの場合はコントロールパネルからやるしかない。「反映されるまで1時間待ってね」って悠長なことをいわれるが我慢。それと3分以内に終わらないジョブは強制終了されてしまうので注意が必要。一応crontabで設定してみて起動時間を確認する(えっ、crontabの使い方が分からない? そんな人はcron使っちゃ駄目)。いわずもがなのことながら、レンタルサーバで23:59だの0:00正時にCRON実行なんて無茶なことをやってはいけない(なぜかというと、その時間はみんなが設定したがる時間なので、ジョブが混み合う可能性があるから)。

cronの記述例

36 4 * * * /virtual/taked2/dailybackup.sh

(毎日4時36分にデイリーバックアップを起動)

cronから届くお手紙は捨ててもいいのだが、実行結果として保存しておくと役に立つことがある。

サーバの移転

CORESERVERの場合、サーバによって負荷がまちまちでハズレにあたると全然性能が出てないときがある。その場合は軽いサーバへ移転することもあるだろう。
その際、コントロールパネルの「サーバー間コピー」を使ってもいいのだが、xpWiki関連のディレクトリでパーミッションを正常に移し変えられてない場合がある。その場合は上記で説明したフルバックアップ・リストアするといい。