信頼性の高いバックアップが必要ですか? 適切な指標の追跡を始めましょう。. マルチクラウドバックアップ監視は、すべてを一箇所に統合することでデータ保護を簡素化します。しかし、真の変革をもたらすのは、バックアップの信頼性、迅速なリカバリ、そしてコストの抑制を保証する重要な指標に焦点を当てることです。.

監視対象は次のとおりです。

• 目標復旧時間 (RTO): ビジネスに影響を与える前に、システムのダウンをどれくらい長く維持できますか?
• 復旧ポイント目標 (RPO): どの程度のデータ損失が許容されるのでしょうか?
• バックアップ成功率: バックアップは計画通りに完了していますか?
• データ転送速度: バックアップ中にデータを移動できる速度はどのくらいですか?
• ストレージ使用率: ストレージの限界が近づいていますか?
• データ整合性チェック: バックアップデータは正確で破損していませんか?
• インシデント対応時間: 障害はどのくらい早く解決できますか?
• 保護されたリソース数: すべての重要なシステムがカバーされていますか?
• バックアップ ボールト ストレージ消費量: ストレージコストを効果的に管理していますか?
• アクセスログと監査証跡: 誰がいつバックアップにアクセスしましたか?

これらの指標を追跡することで、ダウンタイム、データ損失、過剰な支出を防ぐことができます。さらに、バックアップシステムがビジネスニーズとコンプライアンス要件に適合していることも確認できます。.

エキスパートに聞くデモセッション：Veeam ONE ハイブリッドクラウドバックアップ監視マスタークラス | ウェビナー

1. 目標復旧時間（RTO）

目標復旧時間（RTO）とは、障害発生後、ビジネスに悪影響が出る前にシステムがどれだけの時間停止できるかを定義することです。簡単に言えば、すべてが完全に復旧するまでに許容できる最大の停止時間です。Backblazeのシニアプロダクトマーケティングマネージャー、Kari Rivas氏は次のように述べています。

"「リカバリとは、システムがバックアップされ、完全に機能し、ユーザー（従業員、顧客など）がデータインシデントの発生前と同じようにシステムを利用できる状態になることを意味します。」"

RTO を適切に設定することは、技術的な復旧計画をビジネスの優先事項に直接結び付けるため、非常に重要です。.

ダウンタイムのコストによってRTO目標が決まる場合が多くあります。例えば、金融取引会社では、数分間のオフラインでも数百万ドルの損失につながる可能性があるため、RTOをほぼゼロにすることを目標としています。一方、社内アーカイブなど、それほど重要でないシステムは、数日間のダウンタイムにも大きな影響なく耐えることができます。.

RTO に対して階層型アプローチを使用します。 重要なアプリケーションには厳格なRTOを設定し、重要度の低いシステムにはより柔軟な対応を許容します。この戦略により、復旧コストを管理可能な範囲に抑えながら、最も重要な業務を確実に保護できます。部門リーダーと連携し、各システムのダウンタイムによる財務的影響を見積もることで、RTOは単なる技術的な指標ではなく、ビジネス主導の指標となります。.

訓練や実際のインシデント発生時に、定期的に「Recovery Time Reality（RTR）」をテストしてください。RTRが常に目標を下回る場合は、バックアップシステムのアップグレードが必要な兆候です。例えば、テープベースのバックアップは物理的な取り出しと読み込みが必要なため、非常に遅いことで知られています。一方、クラウドベースのストレージは瞬時にアクセスできるため、リカバリ時間を大幅に短縮できます。火災訓練や机上演習は、RTO目標が現実的かつ達成可能であることを確認するための優れたツールです。.

2. 復旧ポイント目標（RPO）

RTOは許容可能なダウンタイムに焦点を当てているのに対し、RPOは許容できるデータ損失の量に焦点を当てています。基本的に、RPOは前回のバックアップから復旧できるデータの経過時間を測定し、例えばRPOが1時間の場合、インシデント発生時に最大60分分のデータが失われる可能性があることを認識していることになります。この指標は、マルチクラウド環境では特に重要であり、復旧作業とビジネスの優先順位を一致させるためには、正確な追跡が不可欠です。.

RPOは、バックアップの頻度に直接影響します。1時間のRPOは、少なくとも1時間ごとにバックアップを実行する必要があることを意味します。決済ゲートウェイや患者記録などの重要なシステムでは、RPOは可能な限りゼロに近づける必要があります。一方、マーケティング分析やアーカイブされた発注書など、それほど重要でないデータでは、13時間から24時間のRPOでも大きな混乱を引き起こすことなく対応できます。.

驚くべき統計があります。72%以上の企業が復旧目標を達成できていないのです[1]。これは多くの場合、RPOの決定が戦略的なビジネス上の選択ではなく、純粋に技術的な問題として扱われていることが原因です。Backblazeのシニアプロダクトマーケティングマネージャー、カリ・リヴァス氏はこの点を強調しています。

"「どのような基準を満たすかという決定は、共同責任です。そして、それらの基準は…ITおよびインフラプロバイダーのチームが達成しなければならない目標なのです。」"

1 分間のダウンタイムがビジネスにどれだけのコストをもたらすかを把握することで、現実的な RPO 目標を明確に設定できるようになります。.

マルチクラウド環境では、プロバイダーや地域によってパフォーマンスが異なる可能性があるため、 実際の復旧ポイント（RPA） （インシデント発生時の実際のデータ損失）は非常に重要です。RPAが常に目標値を達成できない場合は、バックアップ頻度を上げるか、より優れたインフラストラクチャに投資する時期です。手動の方法で対応できないため、厳格なRPO（目標復旧時点）を満たすには、自動化された高頻度のバックアップが唯一の方法となることがよくあります。.

コストと保護のバランスをとるには、顧客認証などの重要なシステムには厳格なRPOを設定し、社内在庫などの重要でないデータには緩やかなRPOを設定します。この階層的なアプローチにより、不要なリソースに過剰な支出をすることなく、最も重要な情報を保護できます。.

3. バックアップ成功率

バックアップ成功率は、失敗したバックアップジョブやスキップされたバックアップジョブと比較して、完了したバックアップジョブの割合を表します。これは、バックアップシステムのパフォーマンスレポートのようなものと考えてください。成功率が高いほど、データ保護計画が順調に進んでいることを示しています。一方、この指標が低下すると、特に重要な局面で業務に支障をきたす可能性があります。.

高いバックアップ成功率を維持することは極めて重要です。そもそもバックアップされていないデータは復元できないからです。マルチクラウド環境では、異なるプロバイダーからのデータを統合する必要があるため、この指標を常に把握することが困難になる場合があります。例えば、AWS Backupはジョブ数を5分ごとにCloudWatchに更新しますが、Google Cloudはバックアップ指標を1時間ごとに更新します。これらの更新情報を統合することで、バックアップ全体のパフォーマンスをより明確に把握できます。.

バックアップの失敗にはいくつかの要因が考えられます。例えば、Amazon FSxやデータベースサービスなどのメンテナンスウィンドウとのスケジュールの競合、ストレージ容量の不足、ネットワークの問題によるデータ転送の中断などが挙げられます。 クラウドプロバイダー. これらの問題に先手を打つには、1時間以内に5件以上のジョブの失敗が発生した場合に自動アラートを設定することをお勧めします。30日間以上のトレンドレポートを実行することで、一時的な問題ではなく、繰り返し発生する問題を発見するのに役立ちます。.

失敗が続く場合は、アプローチの調整を検討してください。永久増分バックアップまたは継続的データ保護（CDP）に切り替えると、転送されるデータ量を削減し、システムへの負荷を軽減できます。AWSでは、ジョブがスケジュールされた時間内に開始されない場合、ジョブが「期限切れ」とマークされるため、技術的なエラーが発生していなくても成功率に影響します。バックアップスケジュールを定期的に確認し、調整することで、ピーク時のリソース競合を防ぐことができます。これらのプロセスを微調整することで、他の重要な指標を監視しながら、バックアップの信頼性を維持できます。.

4. データ転送速度

データ転送速度は、バックアップデータがあるポイントから別のポイントに移動する速度を決定し、バックアップの完了時間に直接影響します。 帯域幅 ネットワーク接続の総容量を指します。, スループット データのアップロードまたはダウンロードの実際の速度を測定します。Backblazeのシニアプロダクトマーケティングマネージャー、カリ・リヴァス氏は次のように述べています。

"「スループットは、エンドユーザーが体験するアップロードとダウンロードの速度を示すものであるため、バックアップおよびアーカイブの顧客にとってより重要な測定値となることがよくあります。」"

スループットが不足すると、バックアップスケジュールに支障をきたし、システムパフォーマンスを低下させる可能性があります。転送速度が遅いとバックアップに時間がかかり、業務時間に影響が出る可能性があります。そこで、 バックアップウィンドウ 日々の業務に支障をきたさずにバックアップを実行できる特定の時間枠を確保することが非常に重要になります。スループットがこの時間枠内でデータ負荷を処理できない場合、問題が発生します。Network Worldの寄稿者であるW. Curtis Preston氏は、次のようなリスクを指摘しています。

"「すべてのストレージ システムには、1 日あたり一定量のバックアップを受け入れる能力があります。[これを監視]しないと、バックアップにかかる時間がどんどん長くなり、勤務時間中に及ぶ可能性があります。」"

転送速度を監視することは、 ネットワークのボトルネック 大きな問題につながる前に、対処しましょう。速度が低速な状態が続く場合は、ネットワークの混雑、ハードウェアの制限、あるいはプロバイダーによる速度制限が原因となっている可能性があります。キューの増加に注意してください。これは、システムがデータフローに対応できていない兆候です。.

転送速度を向上させるには、多くの場合、設定を微調整する必要があります。マルチスレッドは、複数のデータストリームを同時に送信することでパフォーマンスを向上させる方法の一つであり、利用可能な帯域幅をより有効に活用します。ブロックサイズまたはパートサイズの調整も効果的です。パートサイズを大きくすると、頻繁なAPI呼び出しによるオーバーヘッドが軽減されますが、必要なメモリ量は増加します。バックアップウィンドウが厳しい組織にとって、永久増分バックアップまたは継続的データ保護（CDP）への切り替えは、大きな変革をもたらす可能性があります。これらの方法は、転送されるデータ量を最小限に抑え、ネットワークの負荷を軽減します。.

5. ストレージ使用率

ストレージ使用率は、転送速度と並んでバックアップ効率において重要な役割を果たします。複数のクラウドプロバイダで使用しているストレージ容量を常に監視することで、コストを管理し、過剰なプロビジョニングを回避できます。バックアップ容量を定期的に監視することで、傾向を把握し、上限に達する前に容量を調整できます。例えば、Google Cloud のバックアップ使用率レポートは、履歴データに基づく線形回帰を使用して将来のストレージニーズを予測し、管理者にスケールアップのタイミングを事前に知らせます。さらに、重複排除とタイムリーな削除がストレージ効率に及ぼす影響を評価することで、パフォーマンスとコストの両方に大きな影響を与えることができます。.

重複排除と圧縮の効率を評価する良い方法は、 仮想サイズ に 保存されたバイト数. これらの数値がほぼ同じ場合、重複排除が期待どおりに機能していない可能性があります。AWS Backupなどのツールは、CloudWatchで5分ごとに最新のストレージメトリクスを提供します。また、Google Cloudはバックアップボールトのストレージデータを1時間ごとに更新するため、ストレージの健全性を頻繁に把握できます。.

期限切れのリカバリポイントを削除しないと、不要な料金が発生する可能性があります。著名なバックアップおよびリカバリの専門家であるW. カーティス・プレストン氏は次のように説明しています。

"追加購入せずに容量を増やす唯一の方法は、古いバックアップを削除することです。ストレージシステムの容量を監視しなかったために、会社が設定した保存要件を満たせなくなるとしたら、それは残念なことです。"

アプリケーションレベルとホストレベルの両方でストレージの増加を監視することで、どのリソースがコスト増加の原因となっているかを特定できます。例えば、1つのデータベースがバックアップストレージを独占している一方で、他のアプリケーションはほとんど変化が見られないことが分かるかもしれません。この詳細な分析情報により、最も重要な領域に最適化の取り組みを集中させることができます。また、しきい値アラート（通常は80%程度の容量）を設定することで、危険なレベルに達する前に十分な時間を確保できます。.

最後に、予期せぬ事態を避けるためには、プロバイダー固有の課金メトリクスを理解することが重要です。例えば、AWS Neptuneの 合計バックアップストレージ請求額 指標には、継続的なストレージとスナップショットストレージの両方が含まれており、1日あたりの無料割り当てがあります。また、Google Cloud では、リソースタイプで指標をフィルタリングできます。これらの詳細を把握することで、適切なストレージ階層を使用し、コストを常に把握できます。.

6. データ整合性チェック

データ整合性チェックは、バックアップされたデータがそのライフサイクル全体を通じて正確かつ破損していないことを保証するために不可欠です。これらのチェックは、次のような技術に依存しています。 チェックサム そして ハッシュ検証 複数のクラウド プロバイダーにまたがって作業する場合でも、転送、保存、取得中にファイルがそのまま保持されることを確認します。.

コアバックアップメトリクスを基盤とした整合性チェックは、異なるクラウド環境間でデータが移動しても、データの安全性を確保するのに役立ちます。例えば、プロバイダー間のデータ移行やウォームストレージからコールドストレージへの移行では、標準的なバックアップログでは見逃される可能性のある破損が発生する可能性があります。部分的なリカバリポイント（開始されたものの完全に完了していないバックアップ）は、リカバリ中に不完全なファイルや破損したファイルが残る可能性があるため、別のリスクをもたらします。.

現代のクラウドプラットフォームは、データの整合性をほぼリアルタイムで監視するためのツールを提供しています。例えば、, AWS バックアップ CloudWatchのメトリクスは5分ごとに更新されるため、潜在的な問題を迅速に特定して対処できます。一部のプラットフォームでは、「完了」と「問題ありで完了」といったステータスを区別し、より詳細な調査が必要なことを知らせるものもあります。一方、, Oracle Cloud Infrastructure オブジェクトストレージ 冗長性を利用して破損したデータを自動的に修復することで、プロアクティブなアプローチを採用しています。整合性監視の真価を検証するには、実際の復元テストを実行することが不可欠です。.

スケジュールされた復元テストは、 回復時間リアリティ（RTR） そして リカバリポイントリアリティ（RPR） – リカバリ目標と比較して、バックアップシステムのパフォーマンスがどの程度優れているかを示す主要な指標です。これらのテストは、バックアップ戦略の実際の有効性に関する洞察を提供します。.

さらなる保護のために、 不変ストレージ 一度だけ書き込み、何度も読み取る（WORM）技術を使用する。 Amazon S3 オブジェクトロック, は、書き込み後のデータ改ざんを防ぐことができます。これは特にランサムウェア攻撃に対する防御において有効です。ただし、エラーが永久に保存されないように、ロックする前にマルウェアや破損がないかデータをスキャンすることが重要です。 データ品質スコア, は、一貫性、完全性、正確性などの指標を統合し、すべてのクラウド環境にわたるバックアップ データの全体的な健全性の明確なスナップショットも提供できます。.

sbb-itb-59e1987

7. インシデント対応時間

インシデント対応時間は、障害の検出から解決までの期間を追跡します。これは2つの主要なサブメトリックに分類されます。 平均確認応答時間（MTTA）, チームがアラートにどれだけ早く対応するかを測定する指標です。 平均回復時間（MTTR）, は、通常の業務を復旧するまでにかかる時間を測定します。これらの指標は、前述の他のパフォーマンス指標と連携して機能します。.

"最初のバックアップジョブが失敗すると、後続のタスクも失敗する可能性が高くなります。このようなシナリオでは、監視と通知を通じてイベントの進行状況を最もよく把握できます。 – AWS 規範的ガイダンス

インシデントの重大度に基づいて明確な対応基準を定義することが不可欠です。組織は、インシデントへの効率的な対応を確保するために、サービスレベル目標（SLO）を優先度レベルと整合させることがよくあります。

• P1（クリティカル）: 5分以内に認識し、4時間以内に回復
• P2（高）: 15分以内に認識し、12時間以内に回復する
• P3（中）: 1時間以内に確認し、24時間以内に回復する

強力なアラートシステムは、効果的なインシデント対応の基盤となります。バックアップ監視をAmazon CloudWatchやGoogle Cloud Monitoringなどのツールと統合することで、Amazon SNSなどのサービスを通じてリアルタイム通知を設定できます。例えば、1時間以内に5件以上のバックアップジョブが失敗した場合に、高優先度のチケットをトリガーするようにアラームを設定できます。.

"MTTAが低い場合、アラートが適切な担当者に迅速に届いていることを意味します。MTTAが高い場合、アラート疲れ、通知過多、または責任の所在が不明確である可能性が高くなります。 – Wiz

これらの目標を達成するには、自動化が重要な役割を果たします。Amazon EventBridge などのツールはエスカレーションプロセスを自動化し、迅速なチケット作成と一貫した MTTA 追跡を実現します。正確性を維持するには、マルチクラウド環境全体で「確認済み」の意味を明確に定義し、実用的な指標について全員が共通の認識を持つことが重要です。.

8. 保護されたリソースの数

保護対象リソース数は、バックアップサービスによって保護されている仮想マシン、データベース、ファイルシステム、その他のインフラストラクチャコンポーネントの数を測定します。これは、バックアップシステムがマルチクラウド環境をどの程度カバーしているかを評価するための重要な指標です。正確な数を把握することは、適切なデータガバナンスを確保する上で非常に重要です。特に、民間部門と公共部門の両方でマルチクラウドの導入が90%を超えていることを考えると、その重要性はさらに増しています。これらの保護対象資産を追跡することは、クラウド環境におけるコンプライアンスとガバナンスの基盤となっています。.

この指標の真の価値は、インフラ全体のインベントリと比較することで明らかになります。多くのクラウドプラットフォームは、保護対象資産をカウントするツールを提供しており、これにより保護範囲のギャップを特定できます。このカウントをインベントリ全体と相互参照することで、保護されていない可能性のあるリソースを迅速に特定できます。.

常に先手を打つためには、自動検出ツールが不可欠です。動的なクラウド環境では、新しいリソースが絶えず追加されるため、自動スキャンがなければ、一部のリソース（いわゆる「シャドウ」リソース）がバックアップポリシーを回避してしまう可能性があります。例えば、Azureの「保護可能なリソース」ブレードでは、まだバックアップされていない資産が強調表示されるため、これらのギャップにすぐに対処できます。.

アラートを設定することで、監視をさらに強化できます。例えば、保護対象資産の割合がしきい値（例えば、総インベントリの95%）を下回った場合に通知を送信するように、CloudWatchまたはGoogle Cloud Monitoringを設定できます。このプロアクティブなアプローチにより、潜在的な脆弱性がデータ損失につながる前に発見できます。さらに、「BackupTier: Gold」や「BackupTier: Silver」などのラベルでリソースにタグを付けることで、ポリシーの適用を効率化し、複数のチームや部門にまたがる追跡を簡素化できます。.

一元化されたダッシュボードは、マルチクラウド環境全体の可視性を維持するために不可欠なツールです。例えば、AWS BackupはCloudWatchのメトリクスを5分ごとに更新し、Google Cloudはストレージ使用状況に関する1時間ごとの更新情報を提供します。JSONやSyslogを取り込むプラットフォームなど、データ形式を標準化するプラットフォームを利用することで、さまざまなクラウドプロバイダー間で一貫したレポートを作成できます。インフラストラクチャAPIの定期的な監査により、すべてのリソースがカバーされていることがさらに検証され、コンプライアンスを維持し、保護のギャップを回避するのに役立ちます。.

9. バックアップボールトストレージ消費量

バックアップ保管庫のストレージ使用量を監視することは、コスト管理と容量計画を効果的に行うために不可欠です。追跡すべき重要な指標の一つは、 保存されたデータ量 （GiB または TB で測定）。この指標は、使用されているスペースの量を明らかにし、容量制限に達したり、予期しない請求問題に遭遇したりすることを防ぐのに役立ちます。.

もう一つの重要な指標は ストレージプールの使用率, は、バックアップシステムの使用済み容量と使用可能容量の割合を示します。使用量が事前定義されたしきい値に近づき始めたら、容量を拡張するか、古いバックアップを削除する時期です。例えば、AWS Backup は CloudWatch を使用してこれらの指標を 5 分ごとに更新しますが、Google Cloud は値を 1 時間ごとに更新し、5 分ごとに最新のデータを繰り返し表示します。.

監視することも重要です 最小保管日数 必要な期間、データが確実に保持されるようにするためです。さらに、最初の復元と最後の復元のタイムスタンプを追跡することで、バックアップのライフサイクルを検証し、規制へのコンプライアンスを確認するのに役立ちます。.

潜在的なコスト要因の一つは 削除に失敗した期限切れの回復ポイント. AWS Backupはメトリクスを提供します 有効期限切れリカバリポイント数, は、削除されるべきであるにもかかわらず、依然としてスペースを占有しているバックアップを特定します。これは、ストレージコストの増加につながる可能性があります。同様に、 コールドリカバリポイント数 この指標は、古いデータが意図したとおりに低コストのアーカイブ層に移行していることを確認するのに役立ちます。アーカイブストレージは安価ですが、このデータの取得コストが高くなる可能性があることに注意してください。.

先を行くには、 閾値アラート プロアクティブな管理を実現します。監視システムは、ストレージ使用率が設定された上限を超えた場合や、期限切れのリカバリポイントの数が増加し始めた場合に通知を送信する必要があります。また、Compute Engineインスタンス、SQLデータベース、Oracleシステムなど、リソースの種類ごとに消費指標をセグメント化することも有効です。これにより、どのワークロードがストレージ使用量の増加を引き起こしているかを特定し、それに応じて保持ポリシーを調整できます。.

ご利用の方へ Serverion‘のマルチクラウドバックアップソリューション（Serverion）、これらの監視戦略を統合することで、パフォーマンスとコスト効率の両方を向上させることができます。これらのプラクティスは、次のセクションでより詳細な運用指標を掘り下げるための基礎となります。.

10. アクセスログと監査証跡

バックアップインフラストラクチャに関わるすべてのアクション（データの復元、ポリシーの変更、あるいは単なる情報の読み取りなど）は、綿密に記録する必要があります。アクセスログと監査証跡は、誰が、いつ、どこから、何にアクセスしたかを詳細に記録します。このレベルの透明性は、セキュリティ調査と規制要件の遵守の両方にとって不可欠です。.

監査ログには、すべてのイベントに関する重要な詳細情報がすべて記録される必要があります。これには、関連するユーザーまたはIAMロール、実行されたアクションの種類（例：RestoreBackup、DeleteBackup、CreateBackupPlan）、ソースIPアドレス、影響を受けたリソース、タイムスタンプ、アクションの結果が含まれます。長時間実行されるプロセスの場合、Google Cloud Backup and DRは、オペレーションの開始時と終了時にそれぞれ2つのログエントリを個別に生成します。.

クラウド プラットフォームでは通常、ログを次の 2 つのカテゴリに分類します。 管理者アクティビティログ 設定の変更と データアクセスログ 機密データに関わる操作については、管理アクティビティログは通常デフォルトで有効になっていますが、データアクセスログは手動で有効化する必要があることがよくあります。例えばGoogle Cloudでは、データアクセスログはサイズが大きいため、デフォルトで無効になっています（BigQueryを除く）。しかし、これらのログを有効にすることは、機密データを閲覧または復元したユーザーを追跡し、プライバシー規制の遵守を確保する上で不可欠です。.

監視を強化するには、DeleteBackup などの重要なアクションに対してリアルタイムアラートを設定します。さらに、コンプライアンス基準に応じて 30 日から最長 10 年まで変化する保存期間要件を満たすために、ログを集中型ストレージソリューションにルーティングします。集中型ストレージの選択肢としては、Azure Log Analytics や Cloud Storage などのプラットフォームがあります。.

マルチクラウド環境では、次のようなツールが役立ちます。 Serverion ログ管理を簡素化できます。AWS CloudTrail、Azure Activity Logs、Google Cloud Audit Logs のログを単一の SIEM システムに統合することで、バックアップ インフラストラクチャ全体にわたる統合的な可視性を実現できます。このアプローチは、監視を効率化するだけでなく、プラットフォーム間のコンプライアンス維持能力も向上させます。.

比較表

分かりやすくするために、この表では主要なバックアップ指標を3つのカテゴリー（パフォーマンス、セキュリティ／健全性、容量）に分類しています。このように指標をグループ化することで、潜在的な問題を特定し、対処のための明確なロードマップを構築できます。以下に、9つの重要な指標について、それぞれの目的、測定方法、そして注意が必要な状況を示すアラートしきい値をご紹介します。.

パフォーマンス指標 バックアップとリカバリの速度に焦点を当てます。バックアップは時間どおりに完了しているか？危機的状況において、データは十分な速さで復元できるか？といった疑問に答えます。例えば、目標復旧時間（RTO）が4時間と設定されているにもかかわらず、実際の復旧時間（RTR）が定期的に6時間かかる場合、システムの全面的な見直しが必要であることを明確に示しています。.

セキュリティと健康の指標 バックアップが正常に機能しているかどうかを追跡し、データが損なわれていないことを確認してください。例えば、バックアップの成功率が99%を下回ったり、1時間に5件以上のジョブが失敗した場合は、調査が必要です。.

容量メトリック 使用状況を監視することで、ストレージ関連の障害を回避できます。例えば、ストレージ使用率が80～90%に達した際にアラートを設定することで、容量不足による障害を回避できます。.

カテゴリ	メトリック	目的	測定例	推奨アラートしきい値
性能	目標復旧時間 (RTO)	回復速度がビジネスニーズを満たすことを保証する	復元には数分または数時間かかります	RTR がビジネス定義の RTO を超える
性能	データ転送速度（スループット）	バックアップと復元の速度を測定する	MB/秒またはTB/時間	最小ハードウェア速度未満
性能	バックアップウィンドウの使用率	バックアップが割り当てられた時間内に完了することを確認する	時間の長さ（HH:MM）	定義されたウィンドウの100%以上
セキュリティ/健康	バックアップ成功率	データ保護の信頼性を追跡する	%の成功/失敗回数	1時間あたり99%未満の成功または5回以上の失敗
セキュリティ/健康	データ整合性チェック	データが破損しておらず、回復可能であることを確認する	成功したテストの数	24時間以内に復元に成功した回数は1回未満
セキュリティ/健康	健康状態イベント	永続的な障害と一時的な障害を識別する	健康、不健康、劣化状態	「持続的な不健康」状態
容量	ストレージ使用率	ストレージ枯渇を防ぐ	% 使用 / 保存バイト	> 80～90%の容量
容量	バックアップ ボールト ストレージ消費量	クラウドストレージのコストと使用量を追跡する	GBまたはTB	合計データが予算のしきい値を超えています
容量	保護されたリソース数	すべての重要な資産がカバーされていることを確認する	保護されたインスタンスの数	数量 < 予想在庫

この表は、しきい値を超えた際に迅速に行動することの重要性を強調しています。これらの指標を監視することで、バックアップシステムの信頼性とセキュリティを維持し、あらゆる状況に対応できるようになります。.

結論

適切な指標を追跡することで、マルチクラウドバックアップ運用を、問題発生時の対応から、問題発生を事前に予防する運用へと転換できます。監視することで、 仕事の成功率, ストレージ使用率、 そして 回復パフォーマンス, 、データ損失やダウンタイムのリスクを軽減するセーフティネットを構築します。.

これまで取り上げた指標は、次の 3 つの主要領域に重点を置いています。 データ保護, 安全、 そして コスト管理. しきい値アラートを設定し、実際の復旧時間をRTO（目標復旧時間）およびRPO（目標復旧時点）の目標と定期的に比較することで、潜在的な問題を深刻化する前に発見することができます。FinOps認定プラクティショナーのCody Slingerland氏は次のように述べています。

"「測定できないものを修正することはできません。」"

この洞察は、ビジネスの継続性を確保するために徹底した監視を行うことの重要性を浮き彫りにしています。.

これらの指標を活用することで、リソースの割り当てに関するよりスマートな意思決定、緊急時のデータ削除の回避、そしてバックアップが時間どおりに完了することの保証が可能になります。組織がこれらの指標を文書化し、経営陣と共有することで、インフラストラクチャのアップグレードの正当性やバックアップシステムの価値の実証が容易になります。.

1時間あたり5ジョブを超える障害に対する自動アラートの設定、RTOとRPOを検証するための定期的なリストアテスト、注意が必要なプラットフォームやリソースを特定するための多次元フィルターの適用など、実践的な対策を講じてください。これらのアクションは、生データを有意義な改善へと変換し、バックアップインフラストラクチャを強化します。.

これらの監視手法を採用することで、マルチクラウドバックアップを効果的に管理するための明確さと自信が得られます。これにより、リスクを軽減し、コストを管理し、データの安全性を確保できます。.

よくある質問

マルチクラウド バックアップ操作を成功させるために監視する主な指標は何ですか?

適切な指標を監視することは、マルチクラウドバックアップ運用をスムーズかつ確実に実行し続けるための鍵となります。 復旧時間目標 (RTO) そして リカバリポイント目標 (RPO) これらの指標は、必要なときにどれだけ迅速かつ効果的にデータを復元できるかを示します。もう一つの重要な要素は、 データ転送速度 そして レイテンシー クラウド環境全体で中断なく、時間どおりにバックアップが実行されるようにします。.

追跡することも重要です ストレージ使用率, 総容量や利用可能なスペースなど、リソースを最大限に活用するための情報を把握しましょう。 バックアップジョブの成功率 そして 処理されたデータの総量 潜在的な問題を、それが深刻化する前に早期に発見するのに役立ちます。これらの指標を継続的に監視することで、信頼性が高く効率的なバックアップ戦略を維持できます。.

企業は、RTO と RPO の目標を設定する際に、コストと保護のバランスをどのように取ればよいでしょうか?

コストと保護のバランスを適切に取るために、 目標復旧時間 (RTO) そして リカバリポイント目標 (RPO), 最初のステップは、徹底的なビジネスインパクト分析です。これにより、どのアプリケーションが極めて重要で、最短のRTOとRPOを必要とするのか、そしてどのアプリケーションが長いリカバリ時間と多少のデータ損失を許容できるのかを特定できます。例えば、重要なワークロードは頻繁にバックアップを行うべきであり、それほど重要でないデータは、より経済的なオプションを使用して、より長いバックアップ間隔で保存できます。.

バックアップを頻度とストレージの種類に基づいて階層化することで、すべてのデータに高性能ストレージを使用する際の無駄なコストを回避できます。現在の設定でRTOとRPOの目標が達成可能かどうかを確認するには、定期的なリカバリテストが不可欠です。目標が達成できない場合は、増分バックアップ、重複排除、効率的なクラウドネイティブツールなどのオプションを検討し、保護性能を損なうことなくコストを管理する必要があります。.

Serverionは、マルチクラウド・バックアップ・ソリューションでこのプロセスを簡素化します。ミッションクリティカルなデータ用の高性能SSDストレージから、アーカイブ用の予算に優しいオブジェクトストレージまで、柔軟なオプションにより、予算内でRTOとRPOの目標を達成できます。しかも、ビジネス継続性のための信頼性を犠牲にすることなく実現できます。.

マルチクラウド バックアップのデータ転送速度を向上させるにはどうすればよいですか?

マルチクラウドバックアップでデータ転送速度を向上させるには、いくつかの重要なテクニックに注目してください。まずは、 並列処理 ネットワーク経由で送信されるデータ量を削減しながら、複数のバックアップチャネルを設定し、中程度の圧縮を有効にすると、CPUに過度の負担をかけずに帯域幅を最大限に活用できます。もう一つのヒントは？大きなファイルを1GB程度の小さなチャンクに分割し、それぞれのチャンクを別々のチャネルに割り当てることです。これにより、複数のデータストリームが同時に処理されるようになり、スループットが大幅に向上します。.

ペアリング 毎週の完全バックアップ と 毎日の増分バックアップ これも賢いアプローチです。変更されたデータブロックのみを転送することで、帯域幅を節約し、定期的なバックアップタスクを高速化できます。転送メトリックを監視し、ネットワークの混雑を回避するために、オフピーク時間帯にバックアップをスケジュールすることを検討してください。さらに一歩進めたい場合は、エッジキャッシングやクラウドエントリポイント付近の高速ストレージを使用することで、レイテンシを削減し、転送をさらにシームレスにすることができます。.

Serverion のマルチクラウド ホスティング プラットフォームは、堅牢なインフラストラクチャとグローバルに分散されたデータ センターでこれらの方法をサポートし、より迅速で効率的なバックアップを実現するのに役立ちます。.

関連ブログ投稿

• ハイブリッド クラウド バックアップのベスト プラクティス 5 つ
• クラウド DR メトリクス: RTO と RPO の説明
• 追跡すべきバックアップ パフォーマンス メトリックのトップ 5
• リアルタイムクラウドストレージ監視の究極ガイド