Webサイト・データベースを遠隔バックアップ torocca!(トロッカ!)

スナップショットをバックアップの万能薬と考えるべきではない。
その理由とは?


個人事業主としてフリーエンジニアをしている木下です。
近年技術の進歩からバックアップというのもツールや手法が様々に変化しています。一番大きな変化と言えるのは、”スナップショット”によるフルバックアップではないでしょうか?
私の周囲でも、「バックアップって、スナップショット取っておけばいいんでしょ?」と言われることがあります。
スナップショットはバックアップを取得するという視点で見ると簡単でかつ分かりやすい点が特徴的です。例えば近年利用が増加しているパブリッククラウド、IaaSで提供されるクラウドサーバーではほぼ標準機能として提供されていることから、スナップショットを活用されている現場は多いようです。

このスナップショットは手軽にバックアップが取得でき大変便利なのですが、このスナップショットによるバックアップだけですべてのバックアップを賄おうとするといくつか問題があることはご存知でしょうか?


スナップショットの使いどころ

スナップショットは仮想サーバーもしくは仮想サーバーのディスクを丸ごとバックアップすることができます。そのため「環境そのものを対象としたバックアップ」としてはスナップショットに一日の長があります。
環境を丸ごと取得、リストアする時にはその環境丸ごとリストアができます。このため、サーバーシステム内に配置された大量のファイルやWindows Serverなどを利用していればレジストリについてもそっくり丸ごとバックアップデータに落とし込むことができるので、フルバックアップの取得としては非常に効率の良いバックアップ方法となります。
システムが破損してしまい原因が分からない、という時でも正常に稼働していた日にちさえ覚えておけば、その日にちに取得したスナップショットを探し出して復旧作業が可能、ということになります。
このようにスナップショットは「1つの環境を丸ごとバックアップ、有事にリストアする」という点においては非常に便利なバックアップ・リストアを提供してくれます。


スナップショットで苦労するリストア

しかし、このように便利なスナップショットですが、バックアップとしては万能というわけではありません。筆者の失敗談をご紹介します。

ある日、「サーバーがおかしいからバックアップから復元してください。」という依頼が舞い込んできました。確かそのサーバーはルートディスクもデータディスクもスナップショットを取得して定期バックアップとしています。
でも気になったので、もう少し詳しく話を聞いてみると、「サーバーの○○というファイルが破損してしまった。」さらに突き詰めて「実は・・・、サーバーの○○というファイルを誤って上書きしてしまった。」という話になってきました。 つまり、サーバーがおかしくなった、というのはファイルの損傷によって引き起こされてしまった、そのためにバックアップからの復元を依頼してきた、ということのようです。

そういうことならそのファイルだけ・・・、と思ったら、そのサーバーのバックアップはスナップショットなのです。
止むを得ず、取得していたスナップショットをダウンロードし、スナップショットのデータを閉じた別環境にリストアして、対象のファイルだけを取り出すことになりました。しかし、このリストアが長い・・・。
スナップショットはOS領域やデータ領域ないしシステム全体を丸ごとバックアップしていますので、容量は必然的に大容量となってしまいます。まずはその大容量のデータを取得するためにバックアップを別環境にコピーする必要がありました。
続けて、そのデータを要望された1ファイル単位でリストアするためには、まずシステム全体をリストアして丸ごとシステムを別の場所に復旧させ、そのシステム内に保管されているファイルを抜き出す必要がある、という二段階でのリストア作業が必要になります。
途中で「ファイル1つ復旧するのに何時間掛かってんの?」などと怒られてしまいました。


スナップショットだけ、を再考する

この失敗談は、「データの更新タイミングに合わせたデータバックアップをしなかった」ということに結論付けています。
つまり、スナップショットで取得するバックアップというのは「システム全体に影響する変更が発生するとき」のバックアップとしては有用なのですが、一日に何十回/何百回と更新が発生するデータのバックアップとしては適切でない という点が反省点となりました。
システム全体に影響する変更が発生するとき、というのは例えばOSのセキュリティアップデートやシステムメンテナンスなどでサーバー構成が大幅に変更される時、を意味します。
一方で一日に多数の更新が発生するデータは、ユーザーが利用するファイル単位でのデータ、ということです。分かりやすいところではファイルサーバーで共有されたExcelファイルなどがイメージしやすいと思います。共有フォルダ内のExcelファイルはみんなで開いてみんなでデータ入力したりデータ編集したりしますよね。

この例で言えば、どのデータが保護されるべきか、という点において二種類のデータが存在することになります。

データの種類 データの更新タイミング バックアップの単位 バックアップ方法
システムデータ システム全体の変更 OS(ディスク)全体 スナップショット
ユーザーデータ ユーザーがデータを編集したとき ファイル単位 スナップショット

保護されるべきデータは二種類あって、システムの環境全体はシステムがおかしくなった時、ユーザーデータはファイル単位でデータ破損などに備えることになります。バックアップとして取得時のデータにリストアできるということから両方をスナップショットによるバックアップで賄っていましたが、この認識を改める必要がありました。つまりスナップショット以外にも別途バックアップを取得する必要がある、ということです。
具体的には、

データの種類 データの更新タイミング バックアップの単位 バックアップ方法
システムデータ システム全体の変更 OS(ディスク)全体 スナップショット
ユーザーデータ ユーザーがデータを編集したとき ファイル単位 ファイルバックアップ

ユーザーデータはユーザーがデータを編集するタイミングでデータが変化してしまいます。一方でシステム全体のバックアップと言う意味では相変わらずスナップショットは有用なバックアップとして機能してくれます。


バックアップ手法の担当箇所

パソコンでも同じなのですが、一つ一つのファイルが破損したり、誤って消去したりというケースの対処方法としてシステム全体のリストアであるリカバリ作業やクリーンインストールは一般的に実施されません。一方でHDDが故障したりWindows全体の動作が不調になったりすると、パソコン全体の環境を復元(あるいはOS再インストール)することが多いと思います。
サーバーでも同様にリストア対象のデータによってスナップショットとファイルバックアップはそれぞれ担当する領域が違うため使い分ける必要があるといえます。

リストアを実施する時は、何かしらトラブルが発生した時なのでそのトラブルをできるだけ早く(許容される時間内で)復旧させることが要求されます。先ほどの例では「ファイル一つの復元にはそれほど時間も掛かるまい。」と考えていたユーザー側と、「スナップショットからファイルを取り出すにはシステム全体の復元から開始するから時間が掛かる」という管理者側の温度差によって、ユーザーに怒られてしまう結果となってしまいました。

つまり、スナップショットでのバックアップは「ユーザーデータも含めたシステム全体のバックアップを取得した日時に巻き戻す」ということであり、ユーザーデータ単体(ファイル単位で)巻き戻すためには「ユーザーデータ単体でリストアが短時間で簡単に復元できるようファイル単位のバックアップを取得する」必要があるということになります。
使う人別に考えると、この二種類のバックアップはそれぞれの対象者が違うことになります。

サーバーのユーザーが利用するデータはファイル単位となることが一般的ですので、ファイルバックアップを主な保護方法とします。一方でシステム全体を扱う管理者の作業はスナップショットによるバックアップで有事にはシステム全体を復旧させることになります。
これはそのままデータの更新タイミングにも当てはまることになります。つまりユーザーのデータはユーザーが日常業務などで利用する都度、管理者はセキュリティアップデートによる月一回更新やシステムの大規模なメンテナンスを四半期・半期に一度実施するのであればその都度、といった具合にバックアップ取得対象のデータが変化します。

ファイルバックアップの特徴 スナップショットの特徴
  • ユーザーのファイルだけなのでバックアップは短時間で完了でき、取得するバックアップ容量の抑制できる
  • リストアはファイル1つ1つを選択してファイルコピーと同じ感覚で実行できる=手軽
  • バックアップとリストアの操作や設定が簡単に済む
  • リストアは完全にバックアップ取得時の状態に復元できる(部分的に問題が残らない)

お互いの利点となる特徴がそのまま相手側のデメリットとなることも特徴的です。

ファイルバックアップのデメリット スナップショットのデメリット
  • バックアップ取得のための設定や操作はフォルダ(ディレクトリ)やファイル単位で指定する必要がある
  • OS設定(Windowsでいえばレジストリ)のバックアップやリストアはできない
  • システム全体を取得するため、バックアップのデータ容量が多くなりがち
  • リストアは部分的に復元ができないため、バックアップデータに問題があればそのままリストアされる

この関係性を見る限りでは、この二種類のバックアップ方法は「どっちか選ぶ」といった択一的なものではなく、「両方実施しておき、リストアの需要によってどちらのバックアップデータを参照するか選ぶ」という関係性にあることが分かります。


まとめ

  • スナップショットでバックアップは簡単・便利。しかしスナップショットだけではリストアが困難になるケースが存在する。
  • サーバーのバックアップは手軽にファイルバックアップが取得できる仕組みも用意する方がよい。ユーザーの人的ミスや環境の問題によるファイル破損に抗するにはファイルバックアップが有用。
  • サーバーのバックアップはスナップショットとファイルバックアップを組み合わせてシステムのデータ損失に備えるのが基本、そのために使い勝手の良いファイルバックアップツールを用意しましょう。

近年ではスナップショットの技術が進歩しており、一瞬でフルバックアップを取得可能なスナップショットも増えてきています。一瞬でフルバックアップできるスナップショットですが、リストアの要件によっては「一瞬でリストアできるバックアップデータではない」という点を考慮し、バックアップの取得方法も発生するリストアの要件によって複数の手法を用意する必要があります。

この解決策の一つとしてtorocca!というソリューションが提供されています。

スナップショットはクラウドソリューションの標準機能を使いつつ、ファイルバックアップとリストアを補完するソリューションとしてこのtorocca!というSaaSを用意するのは効果的です。25GBのバックアップ領域であれば月額500円から始められる手軽さも魅力の一つです。
一番の魅力はバックアップ対象を柔軟に設定できるため、自社で稼働する複数のサイトを容量一杯までバックアップの取得ができるところが魅力的です。バックアップ対象とスケジュールまでを設定してしまえば、それ以降のバックアップ自体は自動で収集してくれますし、SaaSなのでバックアップを実行するサーバー管理も不要です。リストアも復元範囲を指定すれば手軽に過去に取得したバックアップデータを入手可能です。
UIもシンプルに構成されており、サーバーバックアップの知識がなくても単純に保護したいファイル・フォルダを指定すれば自動的に世代も収集してくれる点、初心者にも使いやすい工夫がされています。


TOP