タグ別アーカイブ: バックアップ

[WordPress] シェル + cron でデータベースをバックアップする

ロリポップのレンタルサーバを使って WordPress を運用している場合の例です。
以下のスクリプトを backup.sh などのファイル名で保存し、FTP ソフトでサーバにアップロードします。
レンタルサーバが提供している cron 機能でスクリプトを定期的に実行するようにします。(私は毎日1回実行させています。)


#!/bin/sh

# Mysqlユーザ名
mysql_user=xxxxxxxx

# Mysqlユーザパスワード
mysql_pw=xxxxxxxx

# ホスト名
host_name=xxxxxxxx

# バックアップ先
save_dir=~/web/xxxxxxxx/backup/

# バックアップファイル名
bak=`date +%Y_%m_%d`

# バックアップするDB
mysql_db_name=xxxxxxxx

# バックアップファイルを残す数
max_save_count=3

mysqldump --opt -u $mysql_user --password=$mysql_pw -h $host_name $mysql_db_name > $save_dir$bak.sql
chmod 644 $save_dir$bak.sql

zip $save_dir$bak.sql.zip $save_dir$bak.sql

rm -rf $save_dir$bak.sql

file_count=`ls -F1 $save_dir | grep -v / | wc -l`
if [ $file_count -gt $max_save_count ] ; then
rm -rf $save_dir`ls -F1tr $save_dir | grep -v / | head -n 1`
fi

私の場合は、バックアップ先を WordPress インストールディレクトリ内にすることで、ファイルのバックアップ時に一緒にデータベースのバックアップもダウンロードしています。

WordPressのバックアップと復元の手順書

バックアップと復元の手順書です。
(※レンタルサーバにロリポップを使った環境でテストをした方法を記載しています。)

<バックアップの方針>

  • 毎月1回と、WP 本体・プラグイン・テーマ等のバージョンアップ前にバックアップをとる。
  • バックアップは、過去3世代分をデスクトップとオンラインストレージに保管する。(長期スパンで過去のバックアップもいくつかとっておく。)
  • バックアップ後、テスト環境で復元テスト。

 

<バックアップと復元>

  • WordPress のバックアップ
    1. サイト全体(ファイル)のバックアップ
    2. データベース(投稿、コメント、リンク、サイト情報など)のバックアップ
    3. 復元テスト
    4. リビジョンを削除して DB を軽くする
  • WordPress の復元

※私の個人的な環境に基づいた手順書です。参考程度にしてください。

 

WordPress のバックアップ

1. サイト全体(ファイル)のバックアップ

FileZilla などの FTP ソフトで WP ディレクトリ全体をダウンロードします。
ダウンロードしたファイルを zip 形式で圧縮します。
圧縮した zip ファイルをデスクトップのバックアップ用ドライブに移動し、オンラインストレージ(google ドライブ)にも保存します。(3世代分のみ保管)

2. データベース(投稿、コメント、リンク、サイト情報など)のバックアップ

シェル + cron で、毎日 WP インストールディレクトリ内にデータベースのバックアップをとります。(3世代分のみ保管)
バックアップ場所は以下のディレクトリとします。

WPインストールディレクトリ/wp-content/cron-db-backup/

「シェル + cron」の設定ができていれば、常に新しいデータベースのバックアップがサーバ上保存されている状態となるため、「1. サイト全体(ファイル)のバックアップ」を行えば、データベースのバックアップも一緒にローカルやオンラインストレージにバックアップされることになります。
→ cron でバックアップするサンプルスクリプトはこちら

3. 復元テスト

テスト環境(別ドメイン)でバックアップファイルから復元ができるかテストします。
※予め作成してある、テスト用データベース(xxxx4test)、テスト用ドメイン(xxxx4test)、レンタルサーバ上のテスト用ディレクトリ(xxxx4test)でテストします。

WordPress Codex で手順を確認しながら行います。

<1>レンタルサーバ上のテスト用ディレクトリ(xxxx4test)にバックアップファイルをアップロードします。

<2>wp-config.php を修正します。
→ データベース名を修正。
→ define( ‘DOMAIN_CURRENT_SITE’, ‘xxxx4test.example.com’ );のように修正。

<3>テスト用データベース(xxxx4test)に、バックアップしたデータベースのsqlファイルをインポートします。

<4>データベース内のドメインを置換する。
<マルチサイトではない場合>
・(マルチドメインではない場合は)全データを安全に変更するため、「Database Search and Replace Script in PHP」を使う。使い方↓

  1. ダウロードファイルを解凍し、フォルダ(Search-Replace-DB-master)ごとテスト環境のインストールディレクトリ(wp-config.php があるディレクトリ)にアップロードする。
  2. ブラウザで「xxxx4test.example.com/Search-Replace-DB-master/」アクセスする。
  3. replace に本番ドメイン、with にテスト用ドメインを入力。database の name に間違いがないか確認し、all tables にチェックを入れて、live run をクリック。
  4. すぐに「Search-Replace-DB-master」フォルダを削除する。

<マルチサイトの場合>
「Database Search and Replace Script in PHP」を使わないで WordPress Codex(WordPress マルチサイトの移動)を参照してドメインの置換を行います。

<5>テスト用ドメイン(xxxx4test.example.com)にアクセスし、表示されるか確認します。

<6>復元テストが成功したら、テスト用データベース内の全テーブルを削除し、テスト用ディレクトリを空にします。

4. リビジョンを削除して DB を軽くする

プラグイン「Better Delete Revision」を使用し、次回バックアップのためにリビジョンを削除してDBを軽くしておきましょう。

WordPress の復元

1. データベースのインポート

バックアップしたサイト全体のデータの中にデータベースのバックアップが含まれています。
データベースのバックアップは以下のディレクトリにあります。

WPインストールディレクトリ/wp-content/cron-db-backup/

レンタルサーバの phpMyAdmin にアクセスし、データベースをインポートします。

2. バックアップのサイト全体ファイルをアップロード

FileZilla などの FTP ソフトでバックアップしたサイト全体をアップロードします。

robocopyコメンドでミラーリングバックアップ

windows7でディレクトリを効率よく完全にバックアップするスクリプト

大地震・暴風豪雨・大停電・ミサイル・隕石衝突・テポドン(w)など、あらゆる震災に備え、PCデータはバックアップをとり、物理的に離れた実家などに保管しておくのが私のルールです。

500GBのポータボーハードディスクを2つ購入し(コスパの良いBUFFALO HD-PVRU2を2つ購入)、バックアップファイルの入ったポータボーHDDが必ず1つは150km離れた実家に保管されている状態をとっています。
帰省する度に、最新のバックアップをとったポータボーHDDを実家へ持って行き、実家に保管してあったポータボーHDDを自宅へ持って帰ります。(企業並みの事業継続性!とはいかないけど、怠りません♪)

毎回のバックアップにあまりにも時間がかかるので、これまで効率の悪かったスクリプトを改修しました。(今までは、一度ドライブを空にしてからコピーしていました。そんなことをしていてはバックアップに何時間も費やすことになり、その間にちっさいテポドンが飛んできて家はほぼ無傷なのに運悪くPCのみに直撃して破壊されたら悔みに悔やみきれません。)

robocopy.exeで堅牢性の高いファイルコピー!

robocopy.exeは、Windows Vista/Windows Server 2008/Windows 7/Windows Server 2008 R2で用意されているOS標準コマンドです。安心して使えますね!
robocopyは、リモートのファイル・サーバ同士でフォルダを同期させるために作られたコマンドですから、ミラーリングコピーをしたい場合には打って付けですね。

それではまず、これまで使っていたスクリプトをお披露目します。(恥ずかしすぎて死にそうです)

ECHO OFF
ECHO;
ECHO F:が対象のドライブであるか確認します。
TIMEOUT /T 3 /NOBREAK > NUL
ECHO;
F:
SET filename="これはバックアップ用ドライブです.txt"
ECHO 「F:\%filename%」が存在するか確認します。。。
TIMEOUT /T 3 /NOBREAK > NUL
IF EXIST %filename% GOTO RM
ECHO %filename%が見つかりません!F:が対象ドライブではない可能性があります。
ECHO 「F:\%filename%」を作成してから再実行してください。
pause
EXIT

:RM
ECHO F:が対象のドライブであることを確認しました。
TIMEOUT /T 3 /NOBREAK > NUL
ECHO;
ECHO 10秒後にドライブを空にします。
TIMEOUT /T 10
RMDIR F:\backup /s /q
ECHO ドライブを空にしました。
TIMEOUT /T 3 /NOBREAK > NUL

ECHO 3秒後にバックアップを開始します。
TIMEOUT /T 3 /NOBREAK > NUL

XCOPY "K:\Users\ahoman\AppData\Local\Evernote\Evernote" "F:\backup\Evernote" /e /h /y /i

XCOPY "K:\仕事のファイル" "F:\backup\仕事のファイル" /e /h /y /i

XCOPY "K:\ユーザー\ahoman" "F:\backup\ユーザー\ahoman" /e /h /y /i

スクリプトの解説・・・
まず、ポータボーHDDを空にします。このとき、ドライブレター(「C:」や「D:」など)がいつもと変わっていてローカルのドライブを削除してしまったら大変です!なので、空にする対象のドライブが本当にバックアップ用ポータボーHDDかどうかをアナログな方法で調べています。
その方法が、ポータボーHDDのトップディレクトリに
「これはバックアップ用ドライブです.txt」
という名前の空ファイルを置いておく、という方法です。
ドライブにこのファイルが無ければスクリプトはそこで終了、ファイルが有ればドライブを空にするステップに進みます。
空にするまでに更に10秒間の猶予を与え(どんなけ慎重やねん!)、そして空にし、バックアップを開始します。

さて、こんなバックアップの仕方をしていたら寿命が3倍伸びても収入は3%くらいしか増えません。

そこで今回、robocopyコマンドを使って効率よくバックアップをとるスクリプトに改修したいと思います。

変更点は以下です。
・ドライブを空にするステップを削除する。
・XCOPYコマンドをROBOCOPYコマンドに変更する。

robocopy.exeの便利なオプションの1つに「/MIR」があります。このオプションを使えばミラーリングが可能です。新しいファイルはコピーし、更新されたファイルは上書きし、コピー元に無いファイルはコピー先から削除してくれます。つまり、この最小限の働きで全く同じディレクトリ構造を作るという最大限の結果をもたらしてくれる、まさにリオネル・メッシのようなコマンドなのです!
(私のPCなんてコマンドでmessiと入力するとrobocopyが実行されるようにしているんですから!)

では、改修後のスクリプトを見てみます。

ECHO OFF
ECHO;
ECHO F:が対象のドライブであるか確認します。
TIMEOUT /T 3 /NOBREAK > NUL
ECHO;
F:
SET filename="これはバックアップ用ドライブです.txt"
ECHO 「F:\%filename%」が存在するか確認します。。。
TIMEOUT /T 3 /NOBREAK > NUL
IF EXIST %filename% GOTO RM
ECHO %filename%が見つかりません!F:が対象ドライブではない可能性があります。
ECHO 「F:\%filename%」を作成してから再実行してください。
pause
EXIT

:RM
ECHO F:が対象のドライブであることを確認しました。
TIMEOUT /T 3 /NOBREAK > NUL
ECHO;
ECHO 10秒後にミラーリングを開始します。
TIMEOUT /T 10

ROBOCOPY "K:\Users\ahoman\AppData\Local\Evernote\Evernote" "F:\backup\Evernote" /MIR

ROBOCOPY "K:\仕事のファイル" "F:\backup\仕事のファイル" /MIR

ROBOCOPY "K:\ユーザー\ahoman" "F:\backup\ユーザー\ahoman" /MIR

一部のみの改修ですが、バックアップ時間がかなり短縮しました。
これまでは「あ、実家に帰ろ!」と突発的に思っても、バックアップに半日かかるので、結局バックアップをせず、故に事業継続性に不安がある状態が続いており、つまりテポドンの危機に少しだけ直面していたのですが、これからは帰省の支度をしている間にバックアップが完了するということになります。(普段から頻繁にミラーリングバックアップをしておけば、帰省直前のバックアップにかかる時間は更に短縮されますね!ま、面倒なのでしませんけど!w)