IT運用においてはよくある話です。バックアップを実行し、ジョブは正常に完了し、すべて順調に見えます。緑色のチェックマークが次々と表示されてバックアップウィンドウが終了し、チームは次の作業に進みます。
バックアップの存在は忘れられがちです。実際に何かを復元する必要が生じるまでは。
現代のクラウドストレージの現実を実感するのはこの時です。オブジェクトストレージ（Amazon S3またはAzure Blob）は、規模と重要性の両面において劇的に進化しています。それらは、重要なアプリケーションデータ、テレメトリ、メディアアセット、コンプライアンスアーカイブ、その他多くのものを保持しています。
こうしたストレージロケーションの中には、数億個のオブジェクトやテラバイト規模のデータを保持しているものもあります。そのうちの1つを復元するのは、すぐに終わる作業ではありません。しかし、Amazon S3とAzure Blob向けのRubrik Prioritized Recoveryを使用すれば、重要なデータストレージ（およびビジネス）をオンラインに復旧するまでの時間を大幅に短縮できます。
オブジェクトストレージの復旧に時間がかかる理由
このシナリオを完全に理解するには、バックアップは非常に速く感じられるのに、復元は苦痛なほど遅く感じられることが多い理由を理解しておくことが役立ちます。オブジェクトストレージをバックアップする場合、データ保護ベンダーは多くの場合、最適化された並列読み取りを活用してデータを効率的に取得します。この操作は、ワークロードを中断することなくバックグラウンドで実行されるように設計されています。
しかし、復元は全く別の問題です。オブジェクトをバケットに復元するには、各オブジェクトに対して個別のAPI呼び出しが必要です。クラウドプロバイダーのAPIは、これらのPUT操作に対してレート制限を設けています。数百万ものオブジェクトが混在する場合、高度に並列化された復元プロセスであっても、対応するバックアップ処理よりはるかに長い時間がかかることがあります。すべてのオブジェクトはトランザクションです。すべてのトランザクションには時間がかかります。大規模なバケットを扱う場合、数学的には非常に厳しい問題が生じます。
これはバックアップ製品の欠陥ではありません。オブジェクトストレージのAPI動作上の根本的な制約です。
ネイティブサービスは「オール・オア・ナッシング」
AWS BackupやAzure Backupなどのネイティブクラウドサービスは、オブジェクトストレージの基本的な保護を提供する点では優れていますが、その復旧モデルは非常に限定的です。バケット全体またはBLOBコンテナー全体を復元するか、個々のファイルやオブジェクトをいくつか復元するか、あるいはまったく何も復元しないかのいずれかしかありません。バケット全体の復元を実行する場合、優先順位付けという概念はありません。
大規模なバケットやBLOBコンテナーの場合、完全な復旧には数時間から数日かかる場合があります。その間ずっと、そのストレージに依存するアプリケーションやサービスは待機状態にあります。会社のITチームも、お客様も待機せざるを得ません。下流の消費者が実際に必要とするデータが復旧したかどうかに関わらず、ビジネスへの影響は1分経過するごとに累積していきます。
問題は、ほとんどのデータ保護ベンダーが、バケットやBLOBコンテナーを単一の単位として扱っていることです。しかし実際には、すべてのオブジェクトが同等であるわけではありません。事業運営を再開するためにすぐに必要とされるものもあれば、単なるアーカイブ、履歴、または優先度の低いデータにすぎないものもあります。ネイティブバックアップにはその違いを表現する方法がなく、お客様がそれに対処する方法もありません。
つまり、これまではそうだった、という話です。
S3およびBlob向けのRubrik Prioritized Recoveryについて
Amazon S3とAzure Blob向けのRubrik Prioritized Recoveryを利用すると、復旧の制御は再びシステム管理者の手に委ねられます。Rubrik Prioritized Recoveryでは、バケットやBLOBコンテナーの復元を単一の画一的な操作として行うのではなく、どのオブジェクトが最も重要であるかを定義し、最初に復元されるようにすることができます。
globパターンを使用すると、運用に不可欠なファイルやフォルダーのパスを指定できます。Rubrikは、これらのオブジェクトの復元を復旧キューの最優先事項として処理し、バケットの残りの部分がバックグラウンドで復元されている間に、最も重要なデータをオンラインに戻します。
たとえばAmazon S3の場合、以下を優先させることができます。
既知のプレフィックス（例: config/*）に保存されたアクティブなアプリケーション設定ファイル
ダウンストリームアプリケーションが必要とするファイル拡張子に一致する特定のオブジェクトタイプ
運用上の復旧優先順位に対応する名前付きパターン
優先させるものが不明確ですか？ 大丈夫です。Rubrikは、優先順位が付けられたものをすばやくプレビューする機能も提供しています。
バケットの残りの部分（アーカイブ記録、履歴スナップショット、優先度の低いオブジェクトなど）はすべて、優先順位の高いオブジェクトの復元が完了した後に、引き続き自動的に復元されます。完全な復旧が行われることには変わりません。ただ、正しい順序で行われるだけです。また、必要に応じて、優先順位付けされたデータのみを復元するように選択することも簡単に行えます。
現実世界におけるRTOの影響
目標復旧時間（RTO）は、単に復旧が完了するまでにかかる時間ではありません。ビジネスが再開可能になるまでの時間です。大規模なオブジェクトストレージを扱う場合、RTOの数値は大きく異なります。
「オール・オア・ナッシング」の復旧モデルでは、実効RTOはバケットまたはBLOBコンテナー内で最も遅い最後のオブジェクトによって決定されます。Prioritized Recoveryでは、実効RTOはアプリケーションやサービスがオンラインに戻るために必要なオブジェクトを復元する時間のみによって決まるため、全体の復旧時間のごく一部で済む場合があります。
この差異は、実際の障害シナリオにおいて非常に重要です。本番環境のアプリケーションが必要とする重要なオブジェクトがバケット全体のわずか5%にすぎない場合、Prioritized Recoveryを使用することで、完全な復旧にかかる時間のほんの一部でオンラインに戻せる可能性があります。残り95%の復元はバックグラウンドで引き続き行われますが、通常の業務を妨げることはありません。
アルファベット順ではなく、組織の優先事項に合わせた復旧
オブジェクトストレージは、現代のアプリケーションにとって基盤となるインフラストラクチャになっています。バケットやBLOBコンテナーの規模が増大するにつれて、バックアップの完了から業務に必要な復旧までのギャップは著しく広がっています。Amazon S3やAzure Blob向けのPrioritized Recoveryは、最も重要な部分を最初に復旧させることで、そのギャップを埋めます。
建物の壁が崩れ始めたときに必要なのは、完全な建て直しではありません。建物の倒壊を防ぐ構造上重要な壁を元に戻すことなのです。しかも迅速に、です。
Rubrik Exploreのセルフガイド形式ハンズオンラボで、Amazon S3およびAzure Blob向けのRubrik Prioritized Recoveryを今すぐお試しください。