Assurance)バックアップの基礎知識2020-01-18開発支援ツール2020-01-15開発ツールフレームワークの機能について。.NET開発基盤部会」によって運営されています。仮想化・クラウドの流れの中で少々古くなっていますが、バックアップ技術の基礎知識です。「可用性」の高いシステムを構築する上で重要である。これは、場合によっては、障害発生後のシステムの復旧方法が、バックアップ・データをリストアする。システムをゼロから構築し直す。いった対応だけに限定される可能性があるためである。「業務データ」のバックアップがないと、システムを完全に(元通りに)復旧できないことになる。基幹サービスが長期間利用できなくなる可能性がある。バックアップ~リストア手順の整備が重要である。†このページでは、バックアップ・システムの構築バックアップ・タスクの設計に必要な基礎知識として、バックアップ・システムの構築のポイントバックアップ方式、ローテーションバックアップ・ソフトウェアその他、バックアップ技術について説明する。†バックアップ・システムの構築のポイントとなる項目を列挙する。「システム状態データ」や「業務データ」など、バックアップ対象のデータを選定する。一般的に、PC上の個人用ワーク・ファイルなどのローカル・データは、バックアップの対象にならないことが多い。「容量の現状の把握」と、「容量増加の予測」をする。†バックアップ処理に使用できる時間が限られる場合、バックアップ処理にかかる時間を短縮する必要がある。ミッション・クリティカル(24時間365日、稼動することを要求される)なシステムの、DBのデータ・ファイルなどは、常時アクセスされているためファイルのコピーができないなどの問題がある。バックアップ対象となるデータの種類によって特別な対策が必要ないか、事前に確認する必要がある。†バックアップの「世代数」とは、一時的に保持する、異なる世代の「完全バックアップ」の数である。「完全バックアップ」は「世代の保護」のために、他の世代と重複しない領域に保存するのが一般的である。保存期間を考慮した「世代管理」をするために必要である。完全バックアップ差分バックアップ増分バックアップを考慮し、適切なバックアップ・タスクを設計する。†バックアップ・サーバの台数は、バックアップ・ソフトウェアのライセンス、バックアップ・デバイスのコストに影響する。バックアップの対象となるクライアント機、サーバ機のデータ量を検討し、ネットワーク経由でのバックアップが行えるようであれば、バックアップ・サーバを統合することで、「導入コスト」と「管理コスト」を抑えることが可能である。†バックアップ・サーバとバックアップ・ソフトウェアを導入し、バックアップ・システムを構築する場合、バックアップ・ソフトウェアが、採用するバックアップ・デバイス、OS、アプリケーションに対応できるか確認する。複数のOS、アプリケーションにも対応できるバックアップ・ソフトウェアを使用したバックアップ・システムは、マルチプラットフォーム環境の統合「バックアップ・ソリューション」と呼ばれる。一般的に、バックアップ対象のOSやアプリケーション毎にオプションを購入する形になっている。バックアップ・ソフトウェアによるが、バックアップ・クライアント毎に、クライアント・エージェントアプリケーション・プラグイン・モジュールなどと呼ばれる機能をインストールする必要がある。「ディザスタ・リカバリ」と言うとリモート・サイトへのデータ同期を示すこともあるが、バックアップ・ソフトウェアで言う「ディサスタ・リカバリ」とは、システム・ディスクの障害時にOSやアプリケーションの再導入を実施せずにリカバリ可能な、バックアップ・ソフトウェアの専用オプションを示すケースが多い。「ディサスタ・リカバリ」機能の導入を考慮する。完全バックアップ差分バックアップ増分バックアップなどがある。これらの各バックアップの長所・短所を理解し、正しいバックアップ方式を選択してバックアップ・タスクを設計する必要がある。以下、各バックアップ方式について説明する。指定されたデータをすべて一括してバックアップする。「差分バックアップ」や、「増分バックアップ」のベースにもなる。常に1回分の「完全バックアップ」から「リストア」が可能。「差分バックアップ」や、「増分バックアップ」と比べ、バックアップするデータ量が大きい。指定されたデータのうち、前回の「完全バックアップ」以降に、追加および更新されたデータのみをバックアップする。「完全バックアップ」よりもバックアップ量が少なくなる。「完全バックアップ」と最新の「差分バックアップ」があればリストアが完了するため、「増分バックアップ」よりも時間が短縮できる。木曜の「差分バックアップ」の順でリストアする。前回の「完全バックアップ」以降に、追加および更新されたデータのみをバックアップするため「増分バックアップ」に比べて、バックアップ量が多い。指定されたデータのうち、前回のバックアップ以降に、追加および更新されたデータをバックアップする。前回のバックアップ以降に、追加および更新されたデータのみバックアップするため、最もバックアップ量が最も少ない。短所リストア時に使用するテープ本数が多くなり、リストアに時間がかかることがある。木曜の「増分バックアップ」の順でリストアする。「統合(合成)バックアップ」は、「完全バックアップ」や「差分バックアップ」のバックアップ・データを合成し、最新の「完全バックアップ」を作成する処理をバックアップ・サーバ内で実行する。「統合(合成)バックアップ」により、バックアップを永遠に差分(増分)のみにできる。「統合(合成)バックアップ」は、バックアップ量が多く、週に一度の「完全バックアップ」がままならない環境で利用する。「増分バックアップ」では、リストアに複数巻のテープを必要とすることがあり、リストアに時間がかかることがあるが、「統合(合成)バックアップ」によりこの問題を解決できる。バックアップを、永遠に差分(増分)のみにすることで、バックアップのデータ量(バックアップ処理時間、ネットワーク・トラフィック)を減少できる。短所すべてのバックアップ統合処理を、バックアップとは異なるジョブとしてアックアップ・サーバ内で行う必要があり、ジョブ作成の考慮が必要。パーソナル・ユースの小規模なバックアップ。大規模システムでは、管理が難しい。デバイスに対応していないなど、機能的に劣る。バックアップ・システムの構成を検討する。場合によっては、バックアップ・サーバの導入を検討する。自分の使用したいデバイスが対応しているかどうかを確認する。バックアップ対象マシンのOSがサポートされていないと、そのボリュームを他のサポートされているOSのマシンにアタッチしてバックアップするなど、煩雑な作業が必要になる。DBMSのオンライン・バックアップなどがサポートされていないと、DBMS側で作成したバックアップ・ファイルをネットワーク経由でバックアップするなど、煩雑な作業が必要になる。製品の機能を簡単に紹介するレベルのカタログでは、十分な仕様を確認できないことがある。PDF等により提供されているマニュアルを確認したり、Web上のFAQ等を参照する。ほとんどのベンダでは、ダウンロードまたはCD-ROM送付による評価版を提供している。事前に自分の要件にあっているか確認することが必要。†ファイル・システムのデータをバックアップする場合、ファイル単位でデータを取得する。殆どのバックアップ・ソフトウェアは、バックアップ・リストアの操作についての情報をファイル単位で、「バックアップ・カタログ」に格納する。このため、場合によっては、1ファイルあたりの管理情報のサイズを考慮し、「バックアップ・カタログ」のサイズも見積もる。†ほとんどのアプリケーションは、データをファイル・システム上にファイルという形で配置する。一部のDBMSや特殊なアプリケーションの場合、ディスクに直接アクセスしてデータを書き込む場合がある。Device」のバックアップ機能が必要になる。Device」でバックアップできる。一般的なOS(Windows、Unixなど)にはオープン・ファイル(ファイル・ロック)という考え方があり、他のユーザが使用している場合、ファイルはロックされる。この状態では、バックアップ・ソフトウェアからも正しくデータを取得することができない。その為、一時的に書き込みが無い状態で「スナップショット(シャドウ・イメージ)」を作成し、整合性を保った状態で正常にバックアップできる(「スナップショット」を作成するには、対象のパーティションを一時的に書き込みが無い状態にする必要がある)。(VSS)」と呼ばれる「スナップショット」機能が実装されている。VSSは「スナップショット」の機能が実装されているだけで、その制御を行うにはバックアップ・ソフトウェアの支援が必要になる。DBの「データ・ファイル」、「トランザクション・ログ・ファイル」なども、オープン・ファイルのバックアップと同様に、「スナップショット」を作成する間、DBを停止することができれば、ファイルとしてのバックアップが可能である。ミッション・クリティカルなシステムの、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は常時アクセスされるため、オンラインの状態でバックアップをおこなうための手段を持っている。「スナップショット」とは、ある瞬間のボリュームのイメージを保持したものである。「スナップショット」は、後述する処理方法で作成されるため、ミラー・コピーを作成するより処理量・容量が格段に少なくて済む。「スナップショット」後は元のボリュームに対して、通常通りファイルの更新や参照を許可するが、「スナップショット」を取っておくことで特定の時点のデータにアクセスすることが可能となる。※1から実現されている。「Cowテーブル」の参照先を「オリジナル・ボリューム」から、「スナップショット・ボリューム」へ変更するという方式が取られている。変更が無いブロックにアクセスした場合は、「オリジナル・ボリューム」を参照。このような処理により「スナップショット」は成り立っている。一部の特殊なケース(RawDevice?)を除けば、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は、通常のファイルとして格納されている。そのためDBを停止すれば、他の一般的なファイルと同様にバックアップすることができる。†しかし、VPNやWebオンラインの普及で、ミッション・クリティカルなシステムが運用されるようになった現在では、DBを停止することが不可能なケースも増えてきた。オンライン・バックアップ(スナップショット)バックアップのためにDBを停止できない、ミッション・クリティカルなシステムは、一時的に書き込みが無い状態で「スナップショット」を作成し、その後、オンラインに戻し、整合性を保った状態で「データ・ファイル」、「トランザクション・ログ・ファイル」をバックアップする。この場合、ファイル・システムのバックアップとなるため、「完全バックアップ」、「差分バックアップ」などのバックアップ方式の使い分けができない。オンライン・バックアップ(API)ミッション・クリティカルなシステムの、DBの「データ・ファイル」、「トランザクション・ログ・ファイル」は常時アクセスされるため、「スナップショット」を作成するタイミングがない。このため、ミッション・クリティカルな用途に適用可能なDBMSは、「データ・ファイル」、「トランザクション・ログ・ファイル」を、それぞれ整合性を保った状態でバックアップするためのAPIを持っている。Serverでは、T-SQLの「Backup」コマンドを使用して、オンライン処理中のバックアップが可能である。「Backup」コマンドでは、「完全バックアップ」、「差分バックアップ」といったバックアップ方式の使い分けも可能である。DBMSのAPIを使用したバックアップ処理のデータ・ストリームは低速である場合もあるため、場合によっては検証が必要になる。