バックアップの取得方法を理解して、最適なバックアップ戦略を考えよう

具体的なバックアップ戦略を考えよう

バックアップの重要性が理解できても、具体的に何をどのようにバックアップすればいいのかがわからなければ、バックアップは行えません。掛けられるコストや満たすべきRPO/RTOを踏まえた上で、バックアップの対象・取得方法・取得形式・バックアップ先の媒体などを具体的に決定していきましょう。

バックアップの対象となるのは、ディスク上のファイルやサーバーのディスク全体などです。まずは、バックアップすべき対象（失ってはならないデータとその範囲）を明確にする所から始めましょう。バックアップの取得方法は、大きく「オフラインバックアップ」と「オンラインバックアップ」に分けられます。それぞれにメリットとデメリットがありますが、バックアップにかかる時間やシステムの一時停止が許容されるかどうかといった点を考慮して、取得方法を決定するとよいでしょう。代表的なバックアップの取得形式には、「フルバックアップ」「差分バックアップ」「増分バックアップ」などがあります。それぞれバックアップにかかる時間・容量・バックアップデータの管理・リストアにかかる手間などが異なります。バックアップ先の媒体には、古典的なテープデバイスやハードディスクからクラウドまで、幅広い選択肢が存在します。

それぞれの項目に対して、メリット/デメリットと注意点を解説します。

ファイル単位でのバックアップとイメージ単位でのバックアップ

最もシンプルなバックアップが、単純なファイル単位でのコピーです。サーバーの設定ファイルやデータベースファイルなど、重要なファイルやディレクトリを別の場所へコピーするだけでよいため、専用のツールがなくても行えます。異なるOSなど、バックアップ元とは違う環境へのリストアも単純なコピーで済むため、簡単です。

これに対して、イメージ単位でのバックアップは、サーバーのディスク全体をイメージファイル化するバックアップです。OSやアプリを含む環境全体をバックアップできるのがメリットで仮にサーバーOSのアップグレードに失敗し、システムが起動しなくなってしまったような場合でも、イメージをまるごとリストアすることで、OS全体をバックアップ取得時点の状態に復元することができます。

ファイル単位のバックアップでは、必要なファイルのみに絞ってバックアップすることが可能です。これは言いかえると、必要なファイルと不要なファイルを選別しなければならないということです。そのため、重要なファイルをバックアップし忘れてしまう可能性もあるでしょう。

ディスク全体をイメージ化してバックアップすれば、このような選択は不要となり、バックアップの抜け漏れも発生しません。ただし、環境をまるごとバックアップするため、イメージファイルのサイズが大きくなりやすいというデメリットがあります。また、OSのユニークIDやSSHのサーバー鍵といった環境固有のデータも新しい環境にリストアされてしまいます。このような場合は、リストア後にサーバーの再設定が必要になることもあります。

アプリケーションが作成したデータやミドルウェアの設定ファイルのみがあればよい環境なら、ファイル単位でのバックアップがシンプルでお勧めです。具体的には、クラウド上の仮想サーバーやコンテナのように環境そのものを手軽に再生成できたり、使い捨てにできる環境が該当します。逆にオンプレミスのサーバーであれば、OSやミドルウェアの再インストールは大きな手間となりますから、環境全体をイメージ化してバックアップしておくと便利です。

オフラインバックアップとオンラインバックアップ

バックアップの対象となるアプリケーションやサーバーを停止させた状態で行うバックアップを「オフラインバックアップ」や「コールドバックアップ」と呼びます。システムが停止しているため、バックアップ中にデータの更新が行われて、データの不整合を起こすような心配がないのがメリットです。

しかし、システムを停止させる都合上、ダウンタイムを許容できないシステムでは行うことができません。また、バックアップするデータの量が多くなればなるほど、バックアップにかかる時間（システムのダウンタイム）も増加します。システムの一時停止が許容できる場合であっても、運用を続けていくうちに許容できる停止時間をオーバーしてしまう可能性もあります。

そのため、オフラインバックアップはOSやアプリケーションのように更新頻度が低く、かつシステム全体を保存/復元したいような用途に向いています。都度システムを停止させる必要があるため、高い頻度でバックアップを取得する（短いRPOが要求される）システムには向かないでしょう。

オフラインバックアップに対して、サーバーやアプリケーションが稼動した状態のまま行うバックアップを「オンラインバックアップ」や「ホットバックアップ」と呼びます。ダウンタイムが許容できず、オフラインバックアップが選択できないシステムでは、必然的にこちらを選択することになります。システムを動かした状態でバックアップが行えるため、データベースのように常時稼動し続けることが要求され、更新頻度が高いシステムのバックアップに向いています。

システムが稼動しているということは、バックアップの取得中にもデータが更新される可能性があるということです。そのため、ファイルを順番にコピーするような方式では、データの不整合が発生しやすくなります。そこで、データベースのバックアップであれば、バックアップが完全性を損わないようにバックアップ中は書き込みをロックするといったアプリケーションごとに適切なケアを行う必要があります。データのリストアも単にファイルを書き戻すのではなく、複雑な手順が必要となることもあります。

オフラインバックアップとオンラインバックアップのどちらが優れているとは一概には言えません。どちらの取得方法を選択すべきかは、システムの要件や状況によって異なります。判断の基準としては、バックアップのためにシステムを停止することが許容されているかどうかです。もしも、バックアップのためにシステムを停止させることが可能であれば、シンプルに完全なバックアップが可能なオフラインバックアップを検討するとよいでしょう。逆にシステムの停止が許されないのであれば、オンラインバックアップを選択することになります。

バックアップは、CPU・ストレージ・ネットワークなどに負荷のかかる処理のため、オンラインバックアップ中はサーバーのリソースが割かれ、業務への影響が発生する可能性があります。また、前述のデータベースの例のように「システム自体は停止せずにバックアップが可能だが書き込みはロックされるため、バックアップ中はクライアントの機能に制限がかかる」といったこともあります。このような点にも十分に留意する必要があるでしょう。

バックアップの取得形式

バックアップの取得形式には、完全なバックアップを取得する「フルバックアップ」のほかに前回のフルバックアップからの差分のみを取得する「差分バックアップ」や前回のバックアップからの増分を取得する「増分バックアップ」などがあります。

一番シンプルで確実なのが、常にすべてのデータを複製するフルバックアップです。しかし、バックアップ対象のサイズが大きくなると、バックアップ先に必要な容量は大きく、そしてバックアップにかかる時間は長くなってしまいます。一般的にサーバー上にあるデータのすべてが毎回更新されるということは稀です。そのため、更新されていないデータを何度も重複してフルバックアップするのは、容量・バックアップ時間のどちらにおいても無駄だと言えます。

一度だけフルバックアップを取得しておき、以降はそこから更新されたデータのみを追加でバックアップするのが「差分バックアップ」です。更新されていないデータのバックアップは省かれるため、比較的短時間でバックアップを完了でき、バックアップ先の容量も節約できるのがメリットです。データをリストアする際は、基準となるフルバックアップと差分バックアップを組み合わせる（マージする）ことで、復元用のデータを作成します。リストア時にデータをマージするという手間がかかることとバックアップデータが複数に分割されてしまうため、管理がやや煩雑になるというデメリットはありますが、フルバックアップに比べて効率のよいバックアップが行えます。

しかし、差分バックアップは「前回のフルバックアップからの差分」をバックアップするため、「今日バックアップする差分」の中には「昨日バックアップした差分」も重複して含まれており、完全に無駄を省けるわけではありません。特に基準となるフルバックアップから長い時間が経過すると、差分が蓄積され、バックアップすべきサイズも大きくなってしまいます。この問題を解消するには、基準となるフルバックアップを定期的に更新する必要があります。

「基準となるフルバックアップからの差分」ではなく、「前回のバックアップからの差分」を積み重ねていくのが「増分バックアップ」です。前回のバックアップから今回までの間に更新されたデータのみを積み重ねて行く方式のため、一度取得したバックアップを重複して取ることがなく、差分バックアップと比較してもさらに効率のよいバックアップが可能です。

増分バックアップのデメリットは、その効率のよさゆえのバックアップデータの管理の煩雑さです。差分バックアップは「基準となるフルバックアップ」＋「差分データ」の2つのデータでバックアップが構成されていましたが、増分バックアップは「基準となるフルバックアップ」＋「増分データ×取得した回数」のデータで構成されます。リストア時には、これらすべてのデータをマージしなければなりません。そして、フルバックアップ時からの時間が経過すればするほど、マージすべき増分の数は増えてしまいます。また、万が一、途中の増分の取得に失敗していた場合は、それ以降のすべてのバックアップが復元できなくなる可能性もあります。

この問題を解決できるのが「永久増分バックアップ」です。永久増分バックアップでは、あらかじめ設定した回数（世代）の増分バックアップを行った場合に、フルバックアップとそれまでの増分を組み合わせて、基準となるフルバックアップを自動的に更新します。これによって、増分バックアップのデメリットであった増分データが増え続けてしまうという問題を解決できるのです。

バックアップを保存する記憶媒体

バックアップは非常に重要ですが、それゆえ「バックアップを取得することが目的」となってしまいがちです。大切なのはデータの喪失を防ぐことであり、バックアップはそのための手段でしかありません。バックアップは取得できればよいのではなく、正しくリストアができて、初めて目的を達成できるものだと心得ましょう。そのためには、バックアップを保存する媒体も信頼性の高いものを選択する必要があります。現在のバックアップの保存先としては、テープ・ハードディスク・クラウドなどが主な選択肢となります。

テープと聞くと、フロッピーディスクよりも昔のPCを思い出すかもしれません。確かに現在の一般的なPCではあまり使用されないテープですが、メディアが大容量かつ故障率が低いという特性を持つため、サーバーなどにおける大容量のデータのバックアップ先として、現在でも利用され続けているメディアです。テープは、シーケンシャルアクセス性能が高いため、巨大なイメージファイル全体を丸ごと読み書きするような用途に向いています。しかし、ランダムアクセス性能は低いため、ファイル単位で読み書きするような用途には不向きです。また、容量あたりで考えると単価は安いもののメディアやドライブがそれなりに高価なため、大容量を使い切れない場合は、逆にコストが高くついてしまうこともあります。さらに、ドライブが定期的なクリーニングを必要とするなど、メンテナンスの手間も無視できません。

ハードディスクは、PC・サーバーを問わず広く普及している記録メディアです。安価で調達もし易く、使い勝手が良いメディアだと言えるでしょう。テープほどではないにしろ、容量も大きく、データの読み書き速度もバックアップ用途としては必要十分です。実用的な速度でのランダムアクセスが可能なため、ファイル単位でのバックアップであれば、テープよりも向いていると言えます。しかし、本来リムーバブルなメディアではないため、メディアの交換がしづらく、テープと比較するとメディアの可搬性は落ちてしまいます。

最近では、バックアップをクラウド上に保存するのも一般的となっています。クラウドを利用するメリットは、何よりドライブやメディアなどの初期投資が不要となる点です。料金は従量制で実際に使用した分だけが課金されるため、コストの最適化も容易です。データを保存するストレージ自体の管理はクラウド事業者に任せられるため、自社でメンテナンスのために技術者を確保する必要もありません。また、ネットワークを経由してデータをやり取りするため、メディアの可搬性を気にする必要もありません。東京のサーバーで取得したバックアップを大阪のサーバーに即時リストアするといったことも手軽に行えます。しかし、クラウドはその特性上、インターネットに接続できないオフライン環境下では利用できないというデメリットもあります。ローカルなメディアに比べると、データの読み書き速度は遅く、セキュリティリスクも無視できません。サービスがクラウド事業者の管理下にある都合上、カスタマイズ性も低い、あるいはできないことも珍しくありません。

バックアップの保存先にも、それぞれのメディアごとに一長一短が存在します。保存するバックアップの形式・サイズ・リストアの手順・目標とするRTO/RPOなどと相談した上で、最適なバックアップ先を選定しましょう。

おわりに

本記事では、一般的なバックアップの手法について解説しました。今後、クラウドナビではサーバーに焦点を当てて、オンプレミスとクラウドでのバックアップの考え方や取得方法の違いなどを解説していきます。