バックアップポリシーのベストプラクティス

今日は、バックアップおよび災害復旧プロセスのいくつかの重要な原則に触れたいと思います。 特に、次のような問題：

1. 生産的なシステム更新手順とそのバックアッププロセスの相互接続
2. バックアップからの回復のテスト
3. バックアッププロセスと生産的なネットワークのネットワークインフラストラクチャの要素との相互作用
4. 災害復旧の文書化

バックアップ

システムをアップグレードする前にバックアップする

アプリケーションとオペレーティングシステムの更新プログラムをインストールし、新しいソフトウェアバージョンにアップグレードし、機器をアップグレードし、システムにその他の重要な変更を加える前に、バックアップが推奨されます。更新が失敗し、システムが誤った状態になった場合、管理者は変更をロールバックし、ビジネスの損失が最小の安定した状態に戻ります（ RPOの観点から）。

次のシナリオを想定します。

1. 火曜日から水曜日の夜にスケジュールされたバックアップが行われます
2. 水曜日までは、システムは通常どおり使用されます
3. 水曜日の夜に、システムが更新されます（システムソフトウェアの新しいバージョンがインストールされます）。 リリースノートをインストールする前にリリースノートを注意深く読んでいないため、システムは不安定な状態になります。
4. システムは、火曜日の状態の時点でデータを損失して再インストールされます
5. 木曜日に、ユーザーは水曜日に作成されたすべてのデータを再作成する必要があります

この例は少し誇張されているように見えますが、それでもマーフィーの法則は情報技術に完全に適用できます。 したがって、システムを更新する前に「余分な」増分バックアップの作成を無視しないでください。 会社が「予防的な」バックアップに「無駄な時間」をかける余裕がない場合、フェイルセーフクラスター、 ストレージシステムの自動ハードウェアスナップショット 、またはデータの信頼性を損なうことなくシステムの継続的な可用性を確保するその他の方法の使用を検討する価値があります。

システムを大幅にアップグレードした直後に完全バックアップを実行する

例：

1. 完全バックアップは金曜日に作成され、増分バックアップは残りの日に作成されます。
2. 水曜日に、データベースサーバーが新しいバージョンに更新され、オペレーティングシステムに関連するいくつかの一般的なシステムファイルが更新されました。
3. 木曜日の夜に通常どおり増分バックアップが受信されました
4. 木曜日の朝、システムの復旧が必要な重大な誤動作が発生しました
5. 障害の性質を調べた後、管理者はシステムファイルのみが破損していることを理解し、システムの機能を復元するには、最後の完全バックアップを使用して多くのシステムファイル（システム状態）のみを復元すれば十分です。 ただし、それだけを行うと、更新されたバージョンのデータベースサーバーは動作を停止します。これは、インストールされた新しいバージョンのシステムファイル（たとえば、最新バージョンの.NET Framework）を必要とするためです。 これにより、システム状態への変更を含む必要な増分コピーを確認して、リカバリプロセスを続行する必要があります。 これは最終的に、SLA違反に至るまで、リカバリプロセスの複雑さの増加とRTO時間の増加につながります。

一般的な推奨事項は、次のように定式化できます。増分バックアップの累積ボリュームが完全バックアップのボリュームを超える場合、予定外の完全バックアップを作成するのが合理的です。

システム復旧後、すぐに完全バックアップを実行します

実際、これは前の段落のバリエーションです。 障害後のシステム回復は時間のかかるプロセスであり、多くの場合、かなりの時間が必要です（増分バックアップ、バックアップに含まれないさまざまなパッチなどを使用する必要があるため）。 場合によっては、ユーザーは基本機能が復元されるとすぐにシステムでの作業を開始し、それによって状態の変更を開始します。 さらに、繰り返し発生する障害は、最初の障害の直後に除外することはできません。 したがって、復元後すぐに、システムの新しい現在の状態を完全バックアップに記録することをお勧めします。

「1石で2羽の鳥を追いかけるな」または「近代化は悪」

障害後のシステム回復プロセスとその近代化プロセスを組み合わせてはなりません。 これは明白に思えるかもしれないという事実にもかかわらず、システムの連続生産操作中の技術手順の時間不足、および「必要な場合でも」「正常に機能している」変更の不本意により、システムダウンタイムの瞬間を使用したいという欲求につながる可能性があります近代化を実行するための失敗の間、いわば「for one」。

これがもたらす可能性のあるいくつかの例を見てみましょう。

1. システムはクラッシュ後に正常に復元されましたが、管理者は、これらの目的でユーザーを中断しないように、システムに最新の更新プログラムをすぐにインストールすることにしました。 ただし、パッチの1つが正しくインストールされておらず、システムがクラッシュします。 その結果、システムを再び最初から復元する必要があります。
2. アプリケーションサーバーバージョンX.1の重大な障害が発生しました。 システムは障害の影響を受けませんでした。 リカバリプロセス中に、管理者は、インストールディスクからX.2の新しいバージョンをインストールし、バックアップコピーから特定のビジネスロジックを実装するアプリケーションデータと追加のプログラムモジュールを復元することを決定しました。 ただし、データとモジュールを回復した後、一部のソフトウェア機能のロジックと一部のプログラムインターフェイスの仕様がわずかに変更されたため、新しいバージョンX.2と互換性がないことが判明しました。 その結果、アプリケーションサーバーはアプリケーションサーバーバージョンX.1を復元する必要がありました。
3. オペレーティングシステムバージョンXの重大な障害が発生し、ユーザーはバージョンXのインストールディスクを見つけられませんでした（このバージョンは3年前にインストールされていたため）。 管理者はライセンスを考慮に入れるのに問題があり、さらに、以前使用していたビジネスアプリケーションの1つが新しいバージョンのオペレーティングシステムと互換性がありませんでした。 システムを再インストールする必要がありました。

その結果、災害復旧手順に関するポリシーの確立を推奨できます。このポリシーでは、近代化アクションは許可されないと見なされます。 回復手順の目的は、ソースシステムの正常性を最短時間（RTO）で復元することのみです。 システムの最新化作業は、特別にスケジュールされた時間に個別に実行する必要があり、インストールを計画しているアップデートの予備テスト手順を伴う必要があります。

すべてについて少し

バックアップを設定する前にドキュメントを読む

アプリケーションをバックアップおよび復元する手順には、考慮に入れる必要のあるさまざまなニュアンスが含まれる場合がありますが、これらは常に明らかではありません。 これらのニュアンスは通常、アプリケーションのドキュメントからのみ学習できますが、多くの場合、ドキュメントはタイムリーに読まれません（またはまったく読まれません）。

この種の「ニュアンス」の例：

1. バックアッププロセス中、さまざまなパスワードとライセンス情報は保存されません。 これは、リカバリ中に実行可能なアプリケーションまたはオペレーティングシステムを取得することができなくなり、宣言されたRTOの一部で障害が発生した後のリカバリ計画がイライラすることを意味します。
2. アプリケーションのシステム構成は、データ自体のバックアップ手順とは別の特別な手順に従って保存する必要があります
3. 記録用に開かれたファイルのバックアップ手順は、ドキュメントに特別に規定されています（事前にアプリケーション構成に特定の設定を含める必要があります）。

回復プロセスは管理者が行う必要があります。

一般的な場合の会社のシステム回復は、ネットワーク管理者、HelpDeskスペシャリスト、およびユーザー自身が実行できます。 後者のオプションは、中小企業またはIT業界のみの特徴とは見なしません。 HelpDeskスペシャリストに関しては、通常、個々のファイルの回復など、基本レベルの一般的な問題を解決できます。 しかし、システム全体を復元することについて話す場合は、そのようなタスクを管理権限を持つ人に委ねることをお勧めします。

1. 回復は、ワークステーションをドメインに含めるタスクに影響を与える可能性があり、これにはドメイン管理者の権限が必要です
2. システムをゼロから復元するには、HelpDesk担当者の能力を超える問題（たとえば、RAIDのドライバーに関する問題）を解決する必要がある場合があります。 さらに、管理者の資格が高いため、システムの回復中に発生したエラーをより正確に優先順位付けして、生産的なネットワークの迅速な復元タスクに直接干渉しない問題の解決を後日延期することができます。
3. 管理権限を必要とする他の問題が発生する場合があります（ネットワークリソースのパスワード、ネットワーク全体へのアクセス不能、企業のファイアウォール設定によるアクティベーションの問題など）。

回復テストは定期的に行う必要があります。

バックアップだけを持っているからといって、復旧がスムーズに進むわけではありません。 第一に、データが正しく保存されない場合があります。第二に、保存中のデータが時間とともに歪む場合があります。または、復元すると、必要なデータがすべてバックアップされていないことが突然明らかになります。 これについての詳細は、「 バックアップからのリカバリのテスト」の記事にすでに記載されています。

ネットワークインフラストラクチャコンポーネントへの依存を考慮する

DNSサーバーで障害が発生したと仮定します。 リカバリ手順を開始した後、使用されたバックアップ製品は独自のインフラストラクチャの一部としてDNSを使用することが判明しました（たとえば、サーバー名のFQDNを使用してバックアップリポジトリに接続します）。 結果は、障害後に自動的に復元されない「循環依存関係」です。 ドメインコントローラーでも同様の状況が見られます（ただし、通常、会社内に複数のドメインコントローラーが存在することはありません）。

このような循環依存は避けてください。 これらは、たとえばVeeam SureBackupテクノロジーを使用して、本番ネットワークから分離されたサンドボックスへのバックアップの復元をテストすることで特定できます。

回復段階の手順を文書化する

災害復旧を正確に文書化する

次の2つのことを避ける必要があります。

• バックアップ製品に完全に依存する必要はありません（「その場合-すべてを復元する-インストールして忘れた」という意味で）。 バックアップに保存されない、またはアプリケーションによって意図的に（コピー防止の一部として）認識されるシステム構成パラメーター（オペレーティングシステムのアクティベーションステータス、ライセンス情報、ネットワークリソースのパスワード付きの保存されたアカウントなど）が常に存在する可能性があります回復時に無効（アクティベーションステータスなど）。 実際には、これは、バックアップ製品がすべてを完全に自動的に復元できない場合に備えて、アプリケーションのパフォーマンスの最終的な復元に関するドキュメントを常に手元に用意する必要があることを意味します。
• バックアップ製品が世界中のインフラストラクチャと完全に互換性があるという前提に頼る必要はありません。 製品が既存のハードウェアと互換性があり、特定のモードの条件下で正常に動作することを確認する必要があります（たとえば、SANでLUNの再バインドを実行するとき、またはRAID-5アレイでボリュームを再構築するとき）。 製品の動作と互換性方法の特殊なケースが文書化されています。

障害回復時に作成するために推奨されるドキュメントの例：

1. 構成設定の定期的な自動ダンプ。たとえば、設定のバージョン管理および/またはその整合性の制御を可能にするソフトウェア製品を使用して実行されます。 アプリケーション構成のバージョン管理は、場合によってはRTOを削減できる場合があるため、原則として、バックアップシステムへの便利な追加機能です。 バックアップ製品とは異なり、構成バージョン管理製品では、設定の変更を保存できるだけでなく、（1）そのような変更を調整します（2）構成の特定の安定状態を特別なタグでマークします。
2. アプリケーションの復元後の再入力に必要なライセンスキー
3. システム回復の際に必要となるパスワードは、セキュリティポリシーに従って、紙または電子形式で回復シートに記録し、アクセスが制限された場所に保存する必要があります。 これは、システムが別の管理者によって復元される場合（最初の管理者が休暇中の場合など）に最低限必要です。
4. 回復のために上記の情報をバックアップする必要があります。必要に応じて、別の会社のオフィスにバックアップすることもできます。 この情報は、すべてのストレージポイントでのウイルスとスパイウェアの可能なアクションから可能な限り保護する必要があります。

障害後の回復プロセスのチェックの一環として何をテストしますか？

障害からの回復プロセスで使用される指示を可能な限り正確にするには、「トレーニングの復元」を実行する必要があります。 回復プロセスをテストするプロセスでは、少なくとも次のような質問に注意する必要があります。

1. サイトが完全に破壊された場合、バックアップには復元に必要なすべての情報が含まれますか？
2. メインシステム管理者が不在の場合（たとえば、海外で休暇中の場合）、回復プロセスはどのように進みますか？
3. リカバリプロセスでの使用に最適なバックアップコピーを含むストレージメディア（テープ/ディスク）が破損した場合はどうなりますか？
4. いわゆるの場合に何が起こるか 「二次故障」？ つまり、復旧プロセスが正常に完了した後、復元されたシステムが機能しないことが判明した場合、
5. 回復プロセスに費やされた時間は、合意されたSLAに適合していますか？ プロセスに関係する人々は、SLAの存在とそのパラメーターについて知っていますか？そして彼らは彼らの仕事でそれを考慮しますか？
6. 復旧プロセスは、本稼働ネットワークのインフラストラクチャコンポーネント（メールサーバー、インスタントメッセージングサーバー、DNS、ドメインコントローラーなど）の障害にどのように影響しますか
7. 文書の品質：トレーニングを受けていない管理者は、書面による指示に従って本稼働システムを復元できますか？
8. 情報破壊の原因がウイルス（あらゆるタイプ）である場合の会社の反応速度。 この脅威の特異性は、ウイルスが可用性を損なうことなくデータおよびアプリケーションを歪める可能性があることです。その結果、フォールトトレランスシステムは障害を修正しません。クラスター/ジオクラスターノード）。
9. 回復プロセスは特定の機器に依存していますか（回復時に失敗する可能性があります）？
10. リカバリプロセスを完全にリモートで実行することは可能ですか？
11. 会社のバックアップサイトを接続するチャネルが中断した場合はどうなりますか？

もちろん、本番システムの健全性に対する脅威のリストを作成するときは、これらの脅威の可能性も考慮に入れ、それぞれの場合にシステムのダウンタイムによる潜在的な損害と比較する必要があります。

一般的な結論

バックアップとリカバリの計画とテストは、RTOを最小化し、SLA条件を満たしていくための重要な要素です。 バックアップからのリカバリのテストの自動化に関して、バックアップ製品に機能が存在することは非常に重要です。

バックアップのテストと特許取得済みのVeeam SureBackupテクノロジーの詳細については、こちらをお読みください。

1. Veeamウェブサイトの説明： Veeam vPower Technology for VMware
2. ウェビナー： 仮想化環境向けの最新のデータ保護
3. 投稿「 SureBackup-バックアップからデータを復元する可能性の自動検証 」
4. 投稿「 バックアップからのデータ復旧のテスト 」