• TOP > インフラストラクチャ > バックアップのいろいろ
  • バックアップの基礎知識
  • Volume Shadow Copy Service (VSS)

仮想化・クラウドの流れの中で少々古くなっていますが、バックアップ技術の基礎知識です。

「システム状態データ」や「業務データ」を、
障害発生に備えてバックアップすることは
「可用性」の高いシステムを構築する上で重要である。

これは、場合によっては、障害発生後のシステムの復旧方法が、

• バックアップ・データをリストアする。
• システムをゼロから構築し直す。

といった対応だけに限定される可能性があるためである。

このような障害が発生した場合、少なくとも、

• 「システム状態データ」
• 「業務データ」

のバックアップがないと、システムを完全に（元通りに）復旧できないことになる。

また、復旧作業を迅速に遂行する手順が整備されていないと、
基幹サービスが長期間利用できなくなる可能性がある。

「可用性」を向上させるためには、

• バックアップ・システムの構築
• ～ バックアップ～リストア・タスクの設計
• ～ バックアップ～リストア手順の整備

が重要である。

このページでは、

• バックアップ・システムの構築
• バックアップ・タスクの設計

に必要な基礎知識として、

• バックアップ・システムの構築のポイント
• バックアップ方式、ローテーション
• バックアップ・ソフトウェア
• その他、バックアップ技術

について説明する。

バックアップ・システムの構築のポイントとなる項目を列挙する。

「システム状態データ」や「業務データ」など、バックアップ対象のデータを選定する。
一般的に、PC上の個人用ワーク・ファイルなどのローカル・データは、バックアップの対象にならないことが多い。

バックアップ対象のデータの容量について、
「容量の現状の把握」と、「容量増加の予測」をする。

バックアップ処理に使用できる時間が限られる場合、
バックアップ処理にかかる時間を短縮する必要がある。

例えば、ミッション・クリティカル（24時間365日、稼動することを要求される）なシステムの、
DBのデータ・ファイルなどは、常時アクセスされているためファイルのコピーができないなどの問題がある。
バックアップ対象となるデータの種類によって特別な対策が必要ないか、事前に確認する必要がある。

• バックアップの「世代数」とは、一時的に保持する、異なる世代の「完全バックアップ」の数である。
• 「完全バックアップ」は「世代の保護」のために、他の世代と重複しない領域に保存するのが一般的である。

「ローテーション」の検討は、

• 世代数
• 世代の保護
• 保存期間

を考慮した「世代管理」をするために必要である。

• 世代管理
• ローテーション
• バックアップ方式
  • 完全バックアップ
  • 差分バックアップ
  • 増分バックアップ

を考慮し、適切なバックアップ・タスクを設計する。

バックアップ・サーバの台数は、

• バックアップ・ソフトウェアのライセンス、
• バックアップ・デバイスのコスト

に影響する。

バックアップの対象となるクライアント機、サーバ機のデータ量を検討し、ネットワーク経由でのバックアップが行えるようであれば、
バックアップ・サーバを統合することで、「導入コスト」と「管理コスト」を抑えることが可能である。

バックアップ・サーバとバックアップ・ソフトウェアを導入し、バックアップ・システムを構築する場合、
バックアップ・ソフトウェアが、採用するバックアップ・デバイス、OS、アプリケーションに対応できるか確認する。

複数のOS、アプリケーションにも対応できるバックアップ・ソフトウェアを使用したバックアップ・システムは、
マルチプラットフォーム環境の統合「バックアップ・ソリューション」と呼ばれる。

一般的に、バックアップ対象のOSやアプリケーション毎にオプションを購入する形になっている。

バックアップ・ソフトウェアによるが、バックアップ・クライアント毎に、

• クライアント・エージェント
• アプリケーション・プラグイン・モジュール

などと呼ばれる機能をインストールする必要がある。

単に「ディザスタ・リカバリ」と言うと
リモート・サイトへのデータ同期を示すこともあるが、

バックアップ・ソフトウェアで言う「ディザスタ・リカバリ」とは、
システム・ディスクの障害時にOSやアプリケーションの再導入を実施せずに
リカバリ可能な、バックアップ・ソフトウェアの専用オプションを示すケースが多い。

費用対効果になるが、

迅速に復旧しないと影響が大きいものについては、
「ディザスタ・リカバリ」機能の導入を考慮する。

移行メモ（表記ゆれ）: 原文には「ディサスタ・リカバリ」という表記が混在していたため、 「ディザスタ・リカバリ」に統一した。

バックアップ方式には、

• 完全バックアップ
• 差分バックアップ
• 増分バックアップ

などがある。

これらの各バックアップの長所・短所を理解し、正しいバックアップ方式を選択してバックアップ・タスクを設計する必要がある。以下、各バックアップ方式について説明する。

• 指定されたデータをすべて一括してバックアップする。
• 「差分バックアップ」や、「増分バックアップ」のベースにもなる。
• 長所
  常に1回分の「完全バックアップ」から「リストア」が可能。
• 短所
  指定されたデータをすべてバックアップする「完全バックアップ」は、
  「差分バックアップ」や、「増分バックアップ」と比べ、バックアップするデータ量が大きい。

指定されたデータのうち、前回の「完全バックアップ」以降に、追加および更新されたデータのみをバックアップする。

• 長所
  • 「完全バックアップ」よりもバックアップ量が少なくなる。
  • 「完全バックアップ」と最新の「差分バックアップ」があればリストアが完了するため、「増分バックアップ」よりも時間が短縮できる。
  • 下の図で、金曜日の「差分バックアップ」完了前に障害が発生した場合、月曜の「完全バックアップ」 ⇒ 木曜の「差分バックアップ」の順でリストアする。
• 短所
  前回の「完全バックアップ」以降に、追加および更新されたデータのみをバックアップするため「増分バックアップ」に比べて、バックアップ量が多い。

指定されたデータのうち、前回のバックアップ以降に、追加および更新されたデータをバックアップする。

• 長所
  前回のバックアップ以降に、追加および更新されたデータのみバックアップするため、バックアップ量が最も少ない。
• 短所
  • リストア時に使用するテープ本数が多くなり、リストアに時間がかかることがある。
  • 下の図で、金曜日の「増分バックアップ」完了前に障害が発生した場合、月曜の「完全バックアップ」 ⇒ 火曜の「増分バックアップ」 ⇒ 水曜の「増分バックアップ」 ⇒ 木曜の「増分バックアップ」の順でリストアする。

• 「統合（合成）バックアップ」は、「完全バックアップ」や「差分バックアップ」のバックアップ・データを合成し、最新の「完全バックアップ」を作成する処理をバックアップ・サーバ内で実行する。
• 「統合（合成）バックアップ」により、バックアップを永遠に差分（増分）のみにできる。「統合（合成）バックアップ」は、バックアップ量が多く、週に一度の「完全バックアップ」がままならない環境で利用する。
• 長所
  • 「増分バックアップ」では、リストアに複数巻のテープを必要とすることがあり、リストアに時間がかかることがあるが、「統合（合成）バックアップ」によりこの問題を解決できる。
  • また、バックアップを、永遠に差分（増分）のみにすることで、バックアップのデータ量（バックアップ処理時間、ネットワーク・トラフィック）を減少できる。
• 短所
  すべてのバックアップ統合処理を、バックアップとは異なるジョブとしてバックアップ・サーバ内で行う必要があり、ジョブ作成の考慮が必要。

古い。

• Son方式
• Father－Son方式
• Grandfather－Father－Son(GFS)方式

• 主にパーソナル・ユースの小規模なバックアップ。
• 大規模システムでは、管理が難しい。
• デバイスに対応していないなど、機能的に劣る。

#	選定ポイント	説明
1	構成検討	バックアップ・システムの構成を検討する。場合によっては、バックアップ・サーバの導入を検討する。
2	対応デバイス	自分の使用したいデバイスが対応しているかどうかを確認する。
3	対応OS	バックアップ対象マシンのOSがサポートされていないと、そのボリュームを他のサポートされているOSのマシンにアタッチしてバックアップするなど、煩雑な作業が必要になる。
4	対応アプリケーション	DBMSのオンライン・バックアップなどがサポートされていないと、DBMS側で作成したバックアップ・ファイルをネットワーク経由でバックアップするなど、煩雑な作業が必要になる。
5	仕様の確認	製品の機能を簡単に紹介するレベルのカタログでは、十分な仕様を確認できないことがある。必ずPDF等により提供されているマニュアルを確認したり、Web上のFAQ等を参照する。 ほとんどのベンダでは、ダウンロードまたはCD-ROM送付による評価版を提供している。事前に自分の要件にあっているか確認することが必要。

ファイル・システムのデータをバックアップする場合、ファイル単位でデータを取得する。

• 殆どのバックアップ・ソフトウェアは、バックアップ・リストアの操作についての情報をファイル単位で、「バックアップ・カタログ」に格納する。
• このため、場合によっては、１ファイルあたりの管理情報のサイズを考慮し、「バックアップ・カタログ」のサイズも見積もる。

• ほとんどのアプリケーションは、データをファイル・システム上にファイルという形で配置する。
  しかし、一部のDBMSや特殊なアプリケーションの場合、ディスクに直接アクセスしてデータを書き込む場合がある。
  そのような際には、ファイルのバックアップ機能ではなく「Raw Device」のバックアップ機能が必要になる。
• 細かいファイルが多すぎて、ファイル・システムのファイル単位だとバックアップに膨大な時間がかかってしまうような場合に「Raw Device」でバックアップできる。

• 一般的なOS（Windows、Unixなど）にはオープン・ファイル（ファイル・ロック）という考え方があり、他のユーザが使用している場合、ファイルはロックされる。この状態では、バックアップ・ソフトウェアからも正しくデータを取得することができない。
• その為、一時的に書き込みが無い状態で「スナップショット（シャドウ・イメージ）」を作成し、整合性を保った状態で正常にバックアップできる（「スナップショット」を作成するには、対象のパーティションを一時的に書き込みが無い状態にする必要がある）。
• Windows Server 2003から標準で「Volume Shadow Copy Service (VSS)」と呼ばれる「スナップショット」機能が実装されている。
  しかし、VSSは「スナップショット」の機能が実装されているだけで、その制御を行うにはバックアップ・ソフトウェアの支援が必要になる。
• DBの「データ・ファイル」、「トランザクション・ログ・ファイル」なども、オープン・ファイルのバックアップと同様に、「スナップショット」を作成する間、DBを停止することができれば、ファイルとしてのバックアップが可能である。
  しかし、ミッション・クリティカルなシステムの、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は常時アクセスされるため、オンラインの状態でバックアップをおこなうための手段を持っている。

「スナップショット」とは、ある瞬間のボリュームのイメージを保持したものである。

「スナップショット」は、後述する処理方法で作成されるため、ミラー・コピーを作成するより処理量・容量が格段に少なくて済む。

「スナップショット」後は元のボリュームに対して、通常通りファイルの更新や参照を許可するが、「スナップショット」を取っておくことで特定の時点のデータにアクセスすることが可能となる。

「スナップショット」は、

• スナップショット・ボリューム
• チャンク単位のポインタ・テーブル ※１

から実現されている。

※１：これを「CoW（Copy on Write）テーブル」と呼ぶ

元のボリュームが更新される場合、チャンク単位でデータを「スナップショット・ボリューム」に退避し、
「CoWテーブル」の参照先を「オリジナル・ボリューム」から、「スナップショット・ボリューム」へ変更するという方式が取られている。

「スナップショット」を読み取る場合は、「CoWテーブル」にアクセスし、

• 変更が無いブロックにアクセスした場合は、「オリジナル・ボリューム」を参照。
• 変更されたブロックにアクセスした場合は、「スナップショット・ボリューム」を参照

というように読み取る。

このような処理により「スナップショット」は成り立っている。

参考：SQL Server のバックアップ

一部の特殊なケース（Raw Device）を除けば、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は、通常のファイルとして格納されている。そのためDBを停止すれば、他の一般的なファイルと同様にバックアップすることができる。

しかし、VPNやWebオンラインの普及で、ミッション・クリティカルなシステムが運用されるようになった現在では、DBを停止することが不可能なケースも増えてきた。

• オンライン・バックアップ（スナップショット）
  バックアップのためにDBを停止できない、ミッション・クリティカルなシステムは、一時的に書き込みが無い状態で「スナップショット」を作成し、その後、オンラインに戻し、整合性を保った状態で「データ・ファイル」、「トランザクション・ログ・ファイル」をバックアップする。ただし、この場合、ファイル・システムのバックアップとなるため、「完全バックアップ」、「差分バックアップ」などのバックアップ方式の使い分けができない。
• オンライン・バックアップ（API）
  ミッション・クリティカルなシステムの、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は常時アクセスされるため、「スナップショット」を作成するタイミングがない。このため、ミッション・クリティカルな用途に適用可能なDBMSは、「データ・ファイル」、「トランザクション・ログ・ファイル」を、それぞれ整合性を保った状態でバックアップするためのAPIを持っている。例えば、SQL Serverでは、T-SQLの「Backup」コマンドを使用して、オンライン処理中のバックアップが可能である。また、「Backup」コマンドでは、「完全バックアップ」、「差分バックアップ」といったバックアップ方式の使い分けも可能である。ただし、DBMSのAPIを使用したバックアップ処理のデータ・ストリームは低速である場合もあるため、場合によっては検証が必要になる。

補足（最新化）: テープ／世代管理を前提とした本ページの体系は現在も有効だが、 昨今は以下が加わっている。

• 重複排除・圧縮を前提とした D2D（Disk to Disk）とクラウド階層化（D2D2C）
• イミュータブル バックアップ（WORM / オブジェクト ロック）— ランサムウェア対策として、 バックアップ自体を暗号化・削除されないようにする
• 3-2-1-1-0 ルール（3コピー／2媒体／1オフサイト／1オフラインまたはイミュータブル／復旧テストでエラー0）

---

Tags: インフラストラクチャ, バックアップ, 障害対応