Webサイト・データベースを遠隔バックアップ

「Webサーバーを冗長化しているから不要だよ。」という話があります。これは、Webサーバーを正系＆副系の二台で稼働させているから、片方に問題があっても大丈夫、というものです。

Webサーバー1 とWebサーバー2 に同じホームページのコンテンツを保管して、どちらかに問題が発生したとしてももう片方でホームページの公開を継続することができます。
つまり、例えWebサーバー1 のデータに問題があったとしてもWebサーバー2 にデータがあるから大丈夫だ、という主張です。
ですが、本来こういった冗長化においては正系＆副系の二台のWebサーバーで同一のデータを保持することが前提で動作していることが通常です。データが同期しているということは「失われた一週間前のあのファイルを復旧したいんだけど…。」と言われたとしても、既に”ファイルを削除した状態が同期されている”ことになるため、データの復旧ができないことがほとんどです。

主張2：パソコンにコンテンツがあるから不要

「Web制作者のパソコンにコンテンツがあるのだからWebサーバーにバックアップは不要だよ。」という話も良く聞く話です。
これは、Web制作者のパソコンはそもそもホームページを公開するためのコンテンツデータを作成しているのだから、そのデータがバックアップとしての備えにもなるだろう、という考え方です。

これも概ね誤ってはいませんが、いくつか条件を考えておく必要があります。
まず、ホームページ更新の作業手順を考えてみましょう。

1. Web制作用PCのコンテンツを編集
2. WebサーバーにFTPでデータ上書き（コンテンツ更新）

という流れでホームページ更新を実行します。つまり「最初に編集するのはWeb制作用のPC 上にあるホームページのデータ、ということになります。Web制作用のPC でちょっと編集したけどやっぱりやめた、という場合にはWebサーバーで公開されているホームページのデータとWeb制作用PCに保管されている編集中のホームページのデータは相違していることになってしまいます。このケースではWeb制作用PCで編集作業を実行した人が必ず漏れなくホームページを更新する、という編集作業を実施する人に依存した形でしかパソコン上のデータがバックアップになることはありません。しかもWeb制作用PCのコンテンツは過去のデータ、というよりはこれから更新する未来のデータ、というべきコンテンツが保管されているため、ホームページを新しいコンテンツで公開後に問題が発生したからといって過去のデータにすぐ差し替えて復旧させる、ということができません。

つまりバックアップとしては何かしらの形で別途取得する必要があることになります。ベストなのは編集の都度データの状態が変わってしまうPC 上のデータよりは、実際に公開しているホームページ上のデータ、つまりWebサーバー上のコンテンツデータをバックアップとして収集する方が正しいといえます。

バックアップが大事というのは方々でよく言われていますが、意外とバックアップについて正しく認識できていない状況に出会うことがあります。
まずはバックアップについて基本的な事項について考えてみましょう。

そもそもバックアップにとって一番大切なことはなんでしょうか？

バックアップを考えるときに一番大切なのは、守るべきなのは何か、ということです。つまりバックアップによってデータを保護すると一口に言ってもそのデータの指すところは何か、という点をしっかり観察する必要があります。
取得したバックアップがあるべき姿に復元できるからこそ、そのデータは保護されている状態にある、と言えます。

しかし、データを保護するという観点でバックアップを取得しているはずなのですが、いつの間にかバックアップを取得することが目的になりがちです。バックアップの取得は意外と大変な作業になるので、大変な作業であるバックアップジョブが想定通りに動作するようになって「ふぅ、やれやれ・・・。」、この時点でかなり疲弊してしまい実際のデータ復元をテストするところまで手が回らないことが多々あります。バックアップとして収集したデータをいざというときに実際に復元しなければならない状況に陥った際に
「どうやって（どんな操作で）復元すればいいの？」
「そもそも収集したバックアップデータはどこに保管されているの？」
とデータの復旧手順をアレコレ模索しながら復旧処理に追われることになりがちです。

これはなぜかといいますと、バックアップツールはリストアツールではない、という点がポイントとなります。
バックアップに使った道具であるバックアップツールが、リストアするときにそのまま使えるかといえばそうとは限りません。リストアに必要なリストアツールというべき道具が用意されていないこともあります。
つまりバックアップの取得はアレコレと苦労してデータを収集するのですが、いざそのバックアップをリストア（復元・復旧）するときに様々な操作を要求されることが多くあります。つまり、単純に収集したバックアップが単純にリストアできるかという点には注意が必要になります。バックアップのための道具であってリストアのための道具ではない、ということもあります。

バックアップの取得もリストアによる復旧も容易に可能なバックアップ体制の構築が基本です。それを実現するために如何にシンプルにバックアップを構成するか、がポイントとなります。

一番シンプルで分かりやすく、かつ理想的なバックアップは「毎回フルバックアップを取得」することです。
すなわちバックアップを取得した時の状態がいつでもそのままに復元できること、これが理想形です。
それを毎日実行すれば、「○月○日の時点に戻ろう。」という戻し方ができますし、毎週実行していれば、「先週の状態に戻そう。」という戻し方ができるようになります。
しかしこの毎回フルバックアップを取得する、というバックアップ方法では二つの悩みがあります。

1. 容量が大きい場合、バックアップを取得するために用意する領域が手狭になる
2. 容量が大きければ大きいほど、バックアップを取得する時間が足りない

近年は動画をWebサーバーに配置することも珍しくなくなってきており、ホームページコンテンツのデータ量が大きくなっていることも散見されます。
例えば動画を含む1GB 程度のホームページデータを1日/1回、毎日フルバックアップし、30日分のバックアップを保管するとなると、合計30GB以上の記憶容量が必要になってきます。
また、数MB/s 程度の速度しか出ないインターネット上の回線速度で1GBのバックアップを収集するとなると、それなりの時間は必要になってきます。

そんなときに出会ったのがWebサイトバックアップ専用のSaaSサービス「torocca!」です。

現状のバックアップはFTPによるファイルのコピーでサーバーAからサーバーBへバックアップを取得しています。サーバーAとサーバーBの間は概ね2MB/s～10MB/s の速度で通信が可能になっています。
だいたい100MBで1分程度、4GBで30分強の時間を要しています。実際のバックアップを実行した時の画面表示では、119MBのバックアップが100%完了した時に速度2.0MB/s で動作し01:01（1分1秒）で完了、と表示されていました。これが、3833MBに容量が増えると、速度は2.0MB/s で変わらず32:36（32分36秒）で完了と表示されました
ちなみに手元のPCからSFTPでデータを送信したところでも概ね2MB/s 程度の速度で4GBのデータは30分程度掛かりました。つまり、インターネットを経由して外部へデータバックアップを実施する場合、当方の環境では100MBで1分、4GBで30分を必要とします。

これが「torocca!」を使うことでどのように変化するかを試してみました。

Webサーバーをtorocca!で取得する場合、バックアップの取得もバックアップデータからの復元もtorocca!の操作ページから操作することになります。言い換えると、バックアップとリストアに使う道具は同一になっているといえます。

Webサイトに100MB 程度のデータを配置してtorocca!からバックアップの取得を実行してみました。
結果としてバックアップに掛かる時間は1分掛からないくらいで終わってしまいました。

実際に取得したバックアップデータをtorocca!からPC でダウンロードしてみると、しっかりバックアップが取得できていることも確認できました。
このように100MB ではすぐ終わってしまいます。
そこで4GBのデータをWebサイトに配置してバックアップを取得してみることにしました。4GBもあるWebサイトはそうそうないと思いますが、前述の通り動画データを自社Webサイトに配置することで容量は増えている傾向がありますし、torocca!がどれくらいのパフォーマンスを発揮してくれるかという点も気になるところです。

実際のバックアップの実行時刻と終了時刻をtorocca!の画面から確認したところ、下記のようになりました。

最初に実行した100MB 程度のバックアップが9:55 から9:56と1分で完了していることが分かります。
二回目に3.61GBのバックアップを実行したところ、10:30に開始したバックアップが10:49に完了していました。おおよそ20分弱で完了したことになります。10分の時間短縮となりました。
たまたま早かったのかもしれない、ということで別のタイミングでtorocca!のバックアップジョブを別途作成し、もう一度実行してみることにしましたが2回目の時間よりバックアップの取得に時間が掛かるようなことはありませんでした。同じサイトであれば概ねバックアップに掛かる時間は安定して期待値通りの結果になります。従来のFTPを使った別サーバーへのバックアップ方法と所要時間を比べてみました。

たとえバックアップに必要な容量が増えたとしてもtorocca!はFTPによるサーバー間のデータ転送よりも優秀な速度で完了させることができます。

こうなるとリストアも気になるところです。試しに、上記4GBのデータについてバックアップを取得したサーバーの同一ディレクトリに対してリストアを実行してみることにしました。復元のテストということです。
13:45にリストア開始し、リストアが完了したのは14:20でした。概ね35分程度でリストアが完了したことになります。
取得したバックアップをリストアするときには道具が変わることによって時間が掛かることもあります。torocca!ではバックアップとリストアは同じコントロールパネルの画面から似通った手順で同じくらいの時間を掛けることでデータを書き戻すことができる、ということになります。

torocca!はMySQLを直接バックアップできる機能を有しています。
データベースのバックアップはmysqldumpが利用されていることが一般的です。
何しろMySQL Serverがインストールされていれば標準機能として利用可能ですし、MySQL Serverを停止する必要もないのでバックアップとしてはまずこのmysqldump コマンドを利用する、というケースが多いと考えられます。このmysqldumpではデータをテキストデータとして書き出します。

簡単に図にしてみました。

mysqldumpで一旦テキストファイルを生成し、このテキストファイルを安全な別のバックアップ用のサーバーにコピーすることによってDBサーバーの障害に備えてバックアップデータを保管することになると思います。
収集したバックアップデータは世代別に保管することになります。つまりDB のデータが1GBあれば3世代取得するには3GBの容量が必要になります。バックアップ用のサーバーが保管できる記憶容量を超える世代を取得するためには古いバックアップデータから順番にテープや光学メディアなどの外部記憶媒体に移動し媒体ごと保管をすることになります。

こう考えるとtorocca!のMySQLバックアップは実にシンプルです。というのもtorocca!ではMySQLへの接続情報をtorocca!に入力するだけでバックアップが取得できるため、実際のMySQL が動作しているサーバーに対してのバックアップ設定は不要なのが大きなアドバンテージとなります。

バックアップにtorocca!を使うことでmysqldump によってファイルを生成する必要もありませんし、バックアップ用サーバーがデータを収集する必要もなければ○世代以降は外部記憶媒体に保管して・・・といったバックアップに掛かる手間が省けることになります。丸ごとtorocca!に最大30世代までを保管することができますし、その設定はクリック一つで切り替えることができます。

torocca!は本来であれば様々な知識とリソースが要求されるバックアップという業務をシンプルに構成することができるクラウドサービスです。

• バックアップはWebサーバーの冗長化や、パソコンとサーバーでデータを持ち合っているからといって必ずしも代用できるわけではない。
• バックアップは復旧を考えて取得するようにする必要がある。
• 理想的なバックアップは、毎回フルバックアップ、シンプルに取得するのがコツ。
• 毎回フルバックアップを取得するために必要なことは二点。
  
  1. サーバー全体を取得できる容量がバックアップ領域に備わっていること
  2. バックアップの取得に使える時間内でサーバー全体のデータを取得できる通信速度
• バックアップを取得したデータの有効性を確認するためには、復旧のリハーサルも実行しておくことが有効。

MySQLにおいてもメリットが存在します。

• 通常のMySQL のバックアップ運用で要求されるようなバックアップを取得して保管するためのコマンドラインを調べて覚える必要なし。
• 通常のサーバーであればスケジュールして自動化するためのサーバー知識が要求されますが、そういった自動化もtorocca!の設定としてクリックするだけで完了する。

明日からはもっと楽にバックアップを取ろっか（torocca!）です。

torocca!の特長を見る