はじめに
Oracle Cloud Infrastructure（以下、OCI）では、Block VolumeやBoot Volumeのバックアップを取得し、そのバックアップを別リージョンへコピーできます。
この Block Volume Backupのクロスリージョンコピー を利用すると、本番リージョンで取得したバックアップをDRリージョンへ保管し、リージョン障害時にDRリージョン側でボリュームを復元できます。
本番リージョン
Compute
├─ Boot Volume
└─ Block Volume
↓
Backup取得
↓
クロスリージョンコピー
↓
DRリージョン
コピー済みBackup
↓
Volumeとして復元
↓
Computeにアタッチして起動
本記事では、OCIの Block Volume Backupのクロスリージョンコピー について、DR対策としての有効性、具体的な活用例、運用方法、設計時の注意点を整理します。
1. Block Volume Backupとは
Block Volume Backup は、OCI Block Volumeサービスで提供されるバックアップ機能です。
Block VolumeやBoot Volumeの特定時点のバックアップを取得し、そのバックアップから新しいボリュームを復元できます。
Block Volume / Boot Volume
↓
Backup取得
↓
Block Volume Backup
↓
Volumeとして復元
主な用途は以下です。
- 誤操作からの復旧
- OSやアプリケーション障害からの復旧
- データ破損時の切り戻し
- 別リージョンへのDR対策
- 検証環境への複製
2. クロスリージョンコピーとは
クロスリージョンコピー は、取得したBlock Volume BackupまたはBoot Volume Backupを、別のOCIリージョンへコピーする機能です。
たとえば、東京リージョンで取得したバックアップを大阪リージョンへコピーできます。
東京リージョン
Block Volume Backup
↓
クロスリージョンコピー
↓
大阪リージョン
コピー済みBlock Volume Backup
コピー先リージョンにバックアップを保持しておくことで、本番リージョンに障害が発生した場合でも、DRリージョン側でボリュームを復元できます。
3. DR対策として有効な理由
Block Volume BackupのクロスリージョンコピーがDR対策として有効な理由は、本番リージョンとは別のリージョンに復元可能なバックアップを保持できる ためです。
本番リージョン内にしかバックアップがない場合、本番リージョン全体の障害時には、そのバックアップをすぐに利用できない可能性があります。
本番リージョン内だけにバックアップを保持
↓
本番リージョン障害
↓
バックアップ利用にも影響する可能性
一方、DRリージョンにバックアップをコピーしておけば、本番リージョンに依存せず復旧手段を確保できます。
本番リージョン障害
↓
DRリージョンのバックアップを利用
↓
DRリージョンでVolume復元
↓
サービス復旧
DR対策としてのメリット
| メリット | 内容 |
|---|---|
| リージョン障害に備えられる | 本番リージョンとは別のリージョンにバックアップを保持できる |
| 低コストに始めやすい | DR側Computeを常時稼働させなくてもよい |
| 世代管理できる | 過去時点のバックアップを保持できる |
| 復旧訓練に使える | DRリージョンで実際に復元テストできる |
| 誤操作・破損対策にも有効 | 過去世代から復元できる |
この方式は、特に コールドスタンバイ型DR と相性がよいです。
4. DR構成の基本イメージ
Block Volume Backupのクロスリージョンコピーを使ったDR構成は、以下のようになります。
本番リージョン
VCN
Compute
Boot Volume
Block Volume
↓
Backup取得
↓
クロスリージョンコピー
↓
DRリージョン
VCN
コピー済みBackup
↓
Boot Volume / Block Volumeとして復元
↓
Compute起動
通常時は本番リージョンのみでシステムを稼働させ、DRリージョン側にはバックアップを保持します。
有事の際に、コピー済みバックアップから必要なボリュームを復元し、Computeインスタンスを作成します。
5. バックアップ対象の考え方
DR目的でバックアップを取得する場合、Boot VolumeとBlock Volumeの両方を考慮します。
| 対象 | バックアップ方法 |
|---|---|
| Boot Volume | Boot Volume Backup |
| Block Volume | Block Volume Backup |
| 複数ボリューム構成 | Volume Group Backup |
| データベース | DBネイティブバックアップも検討 |
OSを含むBoot Volumeだけを復元しても、アプリケーションデータがBlock Volumeにある場合は完全には復旧できません。
Boot Volumeだけ復元
↓
OSは起動する
↓
データボリュームがない
↓
アプリケーションは完全復旧しない
そのため、DR対策としては、Boot VolumeとBlock Volumeの両方を保護対象にすることが重要です。
複数ボリュームで構成されるVMの場合は、Volume Group Backup の利用も検討します。
6. 活用例1：コールドスタンバイ型DR
最も分かりやすい活用例は、コールドスタンバイ型DR です。
通常時は本番リージョンのみでシステムを稼働させ、DRリージョンにはバックアップだけを保管します。
通常時：
本番リージョンでシステム稼働
DRリージョンにはコピー済みバックアップのみ保持
有事：
DRリージョンでバックアップからVolume復元
DRリージョンでCompute作成
サービス再開
向いているケース
| 条件 | 内容 |
|---|---|
| RTO | 数時間〜1日程度を許容できる |
| RPO | バックアップ取得間隔に依存してよい |
| コスト | DR側の常時稼働コストを抑えたい |
| システム規模 | 小〜中規模システム |
| 復旧訓練 | 年次や半期ごとの訓練で確認する |
この方式は、DRリージョンで常時Computeを起動しないため、コストを抑えやすいです。
一方で、有事の際にはボリューム復元、Compute作成、ネットワーク切替などの作業が必要になるため、RTOは長めになります。
7. 活用例2：復旧訓練用のDR環境作成
クロスリージョンコピーされたバックアップは、復旧訓練にも活用できます。
DRリージョンのコピー済みBackup
↓
一時的にVolume復元
↓
検証用Computeにアタッチ
↓
起動確認・アプリ動作確認
↓
訓練後にリソース削除
復旧訓練で確認すること
| 確認項目 | 内容 |
|---|---|
| バックアップ世代 | 想定した世代がDRリージョンに存在するか |
| 復元時間 | Volume復元にどれくらいかかるか |
| Compute起動 | 復元したBoot Volumeから起動できるか |
| Block Volumeアタッチ | データボリュームを正しくアタッチできるか |
| アプリ起動 | アプリケーションが正常に起動するか |
| ネットワーク疎通 | 必要な通信ができるか |
復旧訓練を行うことで、単に「バックアップがある」だけではなく、実際に復旧可能であることを確認できます。
8. 活用例3：通常障害とリージョン障害の両方に備える
おすすめは、同一リージョンのバックアップ と クロスリージョンコピー を組み合わせる運用です。
本番リージョン
Backup取得
├─ 本番リージョンに保持
│ └─ 通常障害や誤操作からの復旧に利用
│
└─ DRリージョンへコピー
└─ リージョン障害時の復旧に利用
使い分け
| 障害パターン | 利用するバックアップ |
|---|---|
| OS障害 | 本番リージョン内のBoot Volume Backup |
| データ破損 | 本番リージョン内のBlock Volume Backup |
| 誤削除 | 本番リージョン内の過去世代バックアップ |
| 本番リージョン障害 | DRリージョンにコピー済みのバックアップ |
| 復旧訓練 | DRリージョンにコピー済みのバックアップ |
リージョン障害だけでなく、誤操作やOS障害などの通常障害にも備えられる点が、この構成のメリットです。
9. 運用方法例：日次バックアップ＋クロスリージョンコピー
DR対策として分かりやすい運用例は、日次バックアップを取得し、DRリージョンへコピーする方式です。
毎日 01:00
本番リージョンでBackup取得
Backup取得後
DRリージョンへクロスリージョンコピー
DRリージョン
コピー済みBackupを保持
運用例
| 項目 | 内容 |
|---|---|
| 対象 | Boot Volume、Block Volume、またはVolume Group |
| 取得頻度 | 日次 |
| 保持期間 | 7日、14日、30日など |
| コピー先 | DRリージョン |
| 復旧用途 | リージョン障害時、復旧訓練時 |
| 確認項目 | コピー完了、保持世代、復元テスト |
RPOはバックアップ取得間隔とクロスリージョンコピーの完了タイミングに依存します。
たとえば日次バックアップの場合、DRリージョンで利用できる最新バックアップは、最大で前日分になる可能性があります。
10. バックアップ・ポリシーの活用
OCIでは、バックアップ・ポリシーを利用してBlock VolumeやVolume Groupのバックアップをスケジュールできます。
ユーザー定義バックアップ・ポリシーでは、スケジュール済バックアップのクロスリージョン自動コピーを構成できます。
ポリシー例
バックアップ頻度：毎日
保持期間：14日
コピー先リージョン：大阪
対象：Volume Group
ポリシー利用のメリット
| メリット | 内容 |
|---|---|
| 自動化できる | 手動バックアップ作成の運用負荷を減らせる |
| 保持期間を管理できる | 古いバックアップを自動削除しやすい |
| コピー漏れを防ぎやすい | DRリージョンへのコピーを自動化できる |
| Volume Groupに適用できる | 複数ボリューム構成の管理に向く |
手動運用ではコピー漏れや削除漏れが起きやすいため、定期運用ではバックアップ・ポリシーを利用するのが現実的です。
11. RPO / RTOの考え方
Block Volume Backupのクロスリージョンコピーを使う場合、RPOとRTOは以下のように考えます。
RPO
RPO =
バックアップ取得間隔
+ バックアップ完了までの時間
+ クロスリージョンコピー完了までの時間
DRリージョンで復元できるのは、クロスリージョンコピーが完了しているバックアップ です。
RTO
RTO =
バックアップ選定
+ Volume復元
+ Compute作成
+ Block Volumeアタッチ
+ アプリ起動
+ ネットワーク / DNS切替
+ 動作確認
この方式は「即時切替」ではなく、復旧作業を伴うDR方式です。
RTOを短くしたい場合は、復旧手順の自動化やDRリージョン側の事前準備が重要になります。
12. DRリージョン側で事前に準備すべきもの
バックアップをDRリージョンにコピーしておくだけでは、DR環境は完成しません。
DRリージョン側では、以下を事前に準備しておく必要があります。
| 項目 | 内容 |
|---|---|
| VCN / Subnet | 復旧先ネットワーク |
| Route Table | 必要なルーティング |
| Security List / NSG | 通信許可ルール |
| DRG | オンプレミス接続やVCN間接続 |
| FastConnect / Site-to-Site VPN | DRサイトへの接続経路 |
| DNS切替手順 | 有事に接続先を切り替える方法 |
| IAMポリシー | DRリージョンで復旧操作できる権限 |
| Vault Key | 顧客管理キー利用時の暗号化キー |
| 復旧手順書 | 誰が、何を、どの順番で実施するか |
特に、ネットワークやIAMは有事にゼロから作ると時間がかかります。
DR対策として利用する場合は、少なくともネットワークと権限まわりは事前に整備しておくことを推奨します。
13. 運用時のチェックポイント
Block Volume BackupのクロスリージョンコピーをDR対策として運用する場合、以下を定期的に確認します。
| チェック項目 | 内容 |
|---|---|
| バックアップ取得状況 | スケジュール通りバックアップが作成されているか |
| コピー完了状況 | DRリージョンへのコピーが完了しているか |
| 保持世代 | 想定した世代数が保持されているか |
| 復元テスト | DRリージョンで実際に復元できるか |
| RPO確認 | 最新コピー済みバックアップの時刻を確認 |
| RTO確認 | 復旧にかかる実測時間を確認 |
| DRネットワーク | VCN、Route、NSGなどが正しいか |
| IAM権限 | 復旧担当者が操作できるか |
| 暗号化キー | DRリージョン側のキーとポリシーが正しいか |
| コスト | バックアップ保存容量とコピー先保存コストを確認 |
特に重要なのは、コピー完了状況 と 復元テスト です。
バックアップが本番リージョンに存在していても、DRリージョンへのコピーが未完了であれば、DRリージョンではその世代を復元できません。
14. 設計時の注意点
1. バックアップだけではDR環境は完成しない
バックアップは復旧元データです。
実際にサービスを復旧するには、Compute、ネットワーク、DNS、セキュリティ、IAM、監視などの準備が必要です。
2. コピー完了済みバックアップだけがDRで利用できる
バックアップ取得済みでも、クロスリージョンコピーが完了していなければDRリージョンでは復元できません。
3. RPOはバックアップ間隔だけで決まらない
RPOには、バックアップ取得時間とクロスリージョンコピー完了までの時間も影響します。
4. 複数ボリューム構成では整合性に注意する
Boot Volumeと複数Block Volumeを個別にバックアップする場合、取得時刻のズレに注意します。
必要に応じて、Volume Group Backupの利用を検討します。
5. 復旧訓練を定期的に行う
DRは設計しただけでは不十分です。
実際にDRリージョンで復元し、起動し、通信できることを確認する必要があります。
15. まとめ
OCIのBlock Volume Backupのクロスリージョンコピーは、DR対策として有効なソリューションです。
本番リージョンで取得したBlock Volume BackupやBoot Volume BackupをDRリージョンへコピーしておくことで、本番リージョン障害時にもDRリージョン側でボリュームを復元できます。
本番リージョンでBackup取得
↓
DRリージョンへクロスリージョンコピー
↓
有事にDRリージョンでVolume復元
↓
Compute起動
↓
サービス再開
特に、以下のような要件に向いています。
DR側の常時稼働コストを抑えたい
RTOが数時間〜1日程度でよい
RPOが日次程度でよい
バックアップ世代を保持したい
復旧訓練を定期的に実施したい
通常障害とリージョン障害の両方に備えたい
一方で、バックアップをコピーしているだけではDR環境は完成しません。
DRリージョン側には、ネットワーク、Compute、IAM、暗号化キー、DNS切替、復旧手順書などを事前に準備しておく必要があります。
また、DRリージョンで利用できるのは、クロスリージョンコピーが完了したバックアップです。
そのため、RPOを考える際は、バックアップ取得間隔だけでなく、バックアップ完了時間とクロスリージョンコピー完了時間も含めて考える必要があります。
設計の目安としては、以下のように考えると分かりやすいです。
低コストなコールドスタンバイ型DR
→ Block Volume Backup + クロスリージョンコピー
低RPOを重視したDR
→ Block Volume Replicationも検討
誤操作・破損対策
→ 世代管理できるBackupを重視
まずはバックアップ・ポリシーを使って定期バックアップとクロスリージョンコピーを自動化し、定期的な復旧訓練で実効性を確認する運用を推奨します。