ファーストサーバの事例で学んだら、サーバーのデータバックアップ対策を！

2012年6月20日、国内大手サーバー会社の一つファーストサーバーにて障害（ファーストサーバ、共有サーバーとVPSサービスで「データ復旧は不可能」）が起こりました。

障害で閲覧できないというケースはありますが、データが消えてしまったようです…。私のクライアントでファーストサーバーを使ってなかったのは幸いでしたが、どのサーバー会社でも同じようなことが起こらないという確証はありません。自らでリスク管理を行っておく必要があります。

制作会社という立場から考える

クライアントのデータがサーバーの障害によって消失した場合、サーバー会社に責任はあっても、制作会社に責任はありません。しかし、本当にクライアントのことを考えるのなら、いざという時に困らないように、このようなリスクがあることを事前に説明しておく必要があると思います。

具体的にバックアッププランを提案して、どの位の頻度でバックアップを行うのか、いざ障害が起きてデータが消えてしまったら、どのような手順で復帰を行うのかまで想定しておきます。いざ障害が起こるとパニックで何をどうしたらいいのか判断を間違うことがありますので。

リスクを説明した上で「そんなことはめったにないものだから、費用をかけてまでバックアップとらなくていいよ」と断られたら、それはそれで仕方ありませんけどね…。

バックアップの種類

HTMLや画像ファイルは、制作時のデータがありますし、ファイルをアップロードするだけで動作しますので、迅速に復旧できると思いますが、システムを使っているサイトだとデータベースにデータを保存していることが多く、サイズが大きかったりすると大変です。特にワードプレスやムーバブルタイプを使ったCMSで、サイトを構築している場合など。

利用が少ない時間にバックアップ

サーバーのアクセスが多い、データサイズが大きいサイトの場合、利用が多い時間帯を避けてバックアップ。データベースのバックアップはサーバーに負担がかかるので、バックアップ中はサイトの表示が重たくなることがあります。

データベースの中に画像ファイル等のバイナリファイルを格納しない

データベースのサイズが大きくなるほど、バックアップ時間・復旧時間が長くなります。また、表示する際にも毎回データベースを読み込むため、負担が大きくなります。設計時点で避けた方がいいと思います。

自動的にデータベースのバックアップをとる

以下、私のサーバーでの設定例です。手作業だと時間もかかりますし、忘れてしまうこともありますので、自動的に過去5日間まで遡って毎日深夜にバックアップをとるようにしています。

backup5mysql.shなど、適当な名前でシェルスクリプトファイルを作ります。

#!/bin/sh

//過去何日分を保存するか
period=5

dirpath='バックアップファイルを置きたいディレクトリ'

//ファイル名を日付で保存する
filename=`date +%y%m%d`

//mysqldumpコマンドを実行する
mysqldump --opt --password=パスワード データベース名 > $dirpath/$filename.sql

//作ったバックアップファイルの権限設定
chmod 700 $dirpath/$filename.sql
chown FTPユーザ名:FTPグループ名 $dirpath/$filename.sql

//5日間より前のファイルは削除
oldfile=`date --date "$period days ago" +%y%m%d`
rm -f $dirpath/$oldfile.sql

まずはbackup5mysql.shを直接指定して実行し、動作確認を行います。
問題なかったら、cronで定期的に実行するようにしておきます。

crontab -e

0 4 * * * /ディレクトリ/backup5mysql.sh

後はFTPでHTML・画像ファイルとともに、バックアップファイルをダウンロードすれば完了です。

自動化する上での注意点は、バックアップを何世代か遡ってとっておくことです。自動化がゆえに、定期的に実行されますが、データが壊れたものをバックアップとして上書きしてしまったら、戻せなくなってしまいます。これを何世代かとっておくことで避けることができます。

いざという時、困らないためにぜひバックアップはとっておきましょう！

レンタルサーバー導入時に気をつけたい8つの注意点！

この記事をシェアする