バックアップ/災害対策にクラウドを使いこなす【第1回】
クラウドをバックアップ/DRに活用するには? 目的別に要件を固める(2/2 ページ)
3.下記のどれを想定しているか
| 3 | 下記のどれを想定しているか | |
|---|---|---|
| 3-1 | クラウドを「長期保管先の安価なストレージ」として利用したい | |
| 3-2 | クラウドを「バックアップデータの複製先」として利用したい | |
| 3-3 | オンプレミスからクラウドへ「サイト間のシステム切り替え」をしたい | |
3-1.クラウドを「長期保管先の安価なストレージ」として利用したい
長期保管先の安価なストレージとしてクラウドの活用を想定している人は、DRをしたいというより、安価なデータの保存先としてクラウドを使用したいという目的が強いと思われる。バックアップデータをオンプレミスに保存せず、クラウドに直接保存したいと思っているかもしれない。
PC/モバイルデバイスのデータのバックアップであれば、対象データの総容量や日次更新量、リストア容量も少ないことが想定されるので、オンプレミスに保存せず直接クラウドに保存することも可能だろう。もし総容量が多いシステムでも、「リストアは一度に数ファイル程度で全体をリストアする必要がない場合」「リストアすることはほぼ無く時間を要しても問題がない場合」は、直接クラウドに保存するだけで事が足りるケースだ。これらのケースは非常にまれだろう。
リストアの頻度が多く、何TBもの容量をフルリストアしたい要件がある場合は、クラウドから直接のリストアは困難である。オンプレミスへの保存に加えて、クラウドに複製することをお勧めする(次項参照)。
3-2.クラウドを「バックアップデータの複製先」として利用したい
バックアップデータの複製先としてクラウドの活用を想定している人は、オンプレミスにバックアップデータを保存し、そのバックアップデータをクラウドに複製することで、保護レベルを上げることが目的だろう。
複製先は、クラウドストレージまたはIaaSで稼働するバックアップサーバを選択できる。システムの復旧場所はオンプレミスを想定している。オンプレミスのサイト全体の障害が発生する可能性より、部分的なシステム障害の発生の可能性が高い。その場合にバックアップデータがオンプレミスに保存されているので、サイト内でリストアができるから効率的だ。
さらに、例えば東京サイト全体が有事の際に、クラウドにバックアップデータが存在するので、大阪サイトを構築し、クラウドからバックアップデータをリストアすることも可能である。ただ、オンプレミスのサイト障害からの復旧のRPO(目標復旧時点)/RTO(目標復旧時間)が想定範囲内であるかどうかを検討する必要がある。バックアップは通常日次で運用されるためRPOは1日となる。RTOはサイトの施設復旧に加え、クラウドからの全データリストアのため、数日~数週間と長時間を要することが考えられる。
| 用語 | 意味 |
|---|---|
| RTO(目標復旧時間) | 許容できる復旧に要する時間 |
| RPO(目標復旧時点) | 失っても構わないデータの時間の範囲 |
3-3.オンプレミスからクラウドへ「サイト間のシステム切り替え」を行いたい
サイト間のシステム移行先としてクラウドの活用を想定するのは、オンプレミスのサイト全体が有事の際に、システムをクラウドに切り替えることで、RTOを短縮させ、ビジネスの継続性を高めたい要件がある場合だろう。
サイトの復旧場所はクラウドである。この場合はクラウドストレージだけでは実現できず、システムを復旧させるためのIaaSが必要である。オンプレミスは「VMware ESXi」「Microsoft Hyper-V」といったハイパーバイザーで構成されていることが多いが、仮想マシン全体のバックアップデータをパブリッククラウドのインスタンス(仮想マシン)としてリストアできるかどうかは、使用するバックアップ製品を確認する必要がある。
サイト復旧に1日~数日かけてよいのであれば、IaaSでバックアップデータをフルリストアすることで対応できるだろう。バックアップデータはリストアしないと使用できないため、総容量が大きいと復旧に長時間を要する。
システムの規模にもよるが、1日未満でのサイト復旧を目指すのであれば、バックアップデータに加え、本番データのレプリケーションも必要になるだろう。本番データのレプリケーションデータは、マウントを切り替えるだけで使用できるため、復旧時間を短縮することができる。本番データのレプリケーションについては、技術の進歩が著しい。RTO/RPOやバックアップ/DR方式にも大きく影響するため、レプリケーション単位(仮想マシン、ストレージのボリュームなど)、レプリケーション対象(アプリデータのみ、システム全体など)について要件を詰める必要がある。
ビジネスの継続性の向上に加えて、オンプレミスとのクラウドの統合管理/連携、運用状況の可視化を行い、シームレスなハイブリッドクラウド/マルチクラウドを実現したい場合は、本番データのレプリケーションの方式を正しく選択し、システム切り替えの自動化の仕組みが必要となる。
上記のヒアリング項目への回答を検討することで、バックアップ/DRにクラウドを利用したい目的とその際の方式を、おおまかにイメージできただろう。想定していた要件が現在の技術で不可能な場合や、想定以上にコストがかかりそうな場合は、要件を変更する必要がある。今回は要件を整理するためのヒアリング項目と、目的の整理についてお伝えした。次回以降、それぞれの要件ごとの方式の詳細と注意事項について解説していく。
Copyright © ITmedia, Inc. All Rights Reserved.
バックアップ/災害対策にクラウドを使いこなす
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー