OCI Block Volumesは、永続的で耐久性があり、ハイパフォーマンスなデータ・ストレージを提供します。OCIでは、コンピュート・インスタンスの有効期間を超えて、ブロックボリュームに独立してデータを保存できます。OCI Block Volumesは、ブロック・ストレージ・ボリュームの動的なプロビジョニングと管理、データの制御、およびアプリケーションに必要なストレージ構成の実現に役立ちます。ストレージとアプリケーションの要件を満たすために、必要に応じてボリュームを作成、アタッチ、接続、移動できます。インスタンスにアタッチして接続すると、通常のハード・ドライブのようなボリュームを使用できます。ボリュームを切り離して、データを失うことなく別のインスタンスに接続することもできます。
ブロックボリュームは、データ・ストレージの一種で、ファイル・ストレージよりも拡張性があります。ブロックボリュームは、iSCSIイーサネット・プロトコルを使用して、オンプレミスのストレージ・エリア・ネットワーク（SAN）と同様の機能とパフォーマンスを提供し、データ・ライフ・サイクルのセキュリティと耐久性を実現できるよう設計されています。OCI Block Volumesは、コンピュート・インスタンスに作成およびアタッチすることができます。
ワークロード・アプリケーションに高可用性ストレージとSANのパフォーマンスが必要な場合、またはデータ・ガバナンスに統合バックアップを含める必要がある場合は、ブロックボリュームを使用することをお勧めします。アプリケーションは、サービスの弾力性、データの永続性、およびパフォーマンスの面でメリットが得られます。OCI Block Volumesは、シンプルな管理オプション、運用の柔軟性、従量制の価格設定に加え、分離と最大限の制御をお客様に提供します。
ローカル・コンピュート・ドライブに保存されたデータは、コンピュート・インスタンスが存在する間のみ存続するため、このストレージ・オプションは一時ファイルにのみ使用する必要があります。耐久性の高いブロックボリュームにデータを保存すると、データはブロックボリュームの有効期間中保持されます。コンピュート・インスタンスが終了した場合、ボリュームを別のコンピュート・インスタンスにアタッチすると、そのボリューム内の永続的なデータに再びアクセスできます。ブロックボリュームを使用すると、統合ブロックボリューム・バックアップを含むようにデータ保護計画を拡張し、バックアップが作成された日にデータのコピーを提供することができます。
コンソール、REST API、またはSDKを使用して、Block Volumesにアクセスすることができます。詳細については、Oracle Cloud Infrastructureを開始するためのガイドおよびブロックボリュームの概要を参照してください。
その答えは「はい」です。業界をリードする最高パフォーマンスの NVMe ソリッド・ステート・ドライブを使用しています。これらのNVMe SSDは、高いパフォーマンスを備え、パフォーマンスSLAによって保証されており、ストレージ・キャッシュを使用せずに有効になります。
50 GB〜32 TBのブロックボリュームを1 GB単位でプロビジョニングできます。
オペレーティング・システムは、データ・ストレージ機能をリンクするためのストレージ・ネットワーク規格であるiSCSIプロトコルを使用してブロックボリュームにアクセスします。
Block Volume Performanceドキュメント を参照してください。
Oracle Cloud Infrastructure Compute仮想マシン・インスタンスにアタッチされているブBlock Volumesのパフォーマンスは、利用可能なネットワーク帯域幅によって制限されます。インスタンスの制限については、コンピュート・サービスに関するよくある質問を参照してください。
ベアメタル・コンピュート・インスタンスで最大700,000以上のIOPSとニアラインレートのスループットを確認できます。詳しくは、Block Volume Performanceドキュメント を参照してください。
コンピュート・インスタンスごとに最大32個のボリュームをアタッチできるため、コンピュート・インスタンスごとに最大32 TB*32=1 PBのアタッチ容量になります。ハイパフォーマンス・アプリケーションのニーズに応じて、アタッチ・ボリュームの数を計測および調整することをお勧めします。
その答えは「はい」です。最高のパフォーマンスを提供するために、Block Volumesは、同じ可用性ドメイン内のどのコンピュート・インスタンスにもアタッチできるように最適化されています。あるコンピュート・インスタンスからボリュームをデタッチし、コンピュート・サーバを再起動せずに、そのボリュームを別のコンピュート・インスタンスにアタッチすることができます。詳細は ドキュメントをご覧ください。
すべてのBlock Volumesとそのバックアップは、暗号化に256ビットのキーを使用するAdvanced Encryption Standard（AES）アルゴリズムを使用して、保存時に常に暗号化されます。インスタンスとBlock Volume間で移動されるすべてのデータは、安全性の高い内部ネットワークを介して転送されます。インスタンスとBlock Volume間でデータを移動する際にデータの暗号化に関連する特定のコンプライアンス要件を適用する場合、準仮想化ボリューム・アタッチを使用すると、転送中の暗号化を有効にできます。
Block Volumeとそのバックアップは、テナント／コンパートメント境界内でのみアクセスでき、テナント／コンパートメントへのアクセス権限が付与されている認証済みユーザーのみがアクセスできます。
ブートボリュームもBlock Volumesサービスによって提供および管理されるため、Block Volumesと同じ方法で保護されます。
その答えは「はい」です。詳細については、Block Volume Elastic Performance Options および Block Volume Pricing を参照してください。
その答えは「はい」です。詳細については、Block Volume Elastic Performance Options および Block Volume Pricing を参照してください。
いいえ。ボリュームがインスタンスにアタッチされているかどうかに関係なく、アプリケーションのダウンタイムなしでボリュームのパフォーマンスを変更できます。
その答えは「はい」です。Block Volumeの自動チューニング機能を使えば、1GBあたり最低10VPU、最高120VPUのパフォーマンスを設定できます。自動チューニング機能を使用することで、ブロックボリュームは必要な時に必要な分だけ使用します。
*注：ブートボリュームと単一パス・アタッチメントは現在この新機能を提供していませんが、この機能のサポートが将来のアップデートで提供される予定です。Block Volumeの自動チューニングの詳細については、Performance-Based Dynamic Scaling のドキュメントをご覧ください。
自動チューニングを使用すると、パフォーマンスの増加は迅速に反映されます。各レベルの調整に対して15秒以内にアクションが繰り返され、必要に応じて安定したパフォーマンスの増加が提供されます。パフォーマンスの減少はゆっくりと行われ、最初の減少は1時間後、その後の減少は数分後に行われ、パフォーマンスが必要とされているときに急激にボリューム・パフォーマンスを減少させないようになっています。詳細については、Performance-Based Dynamic Scaling のドキュメントをお読みください。
はい、できます。しかし、常に保証されるわけではありません。この自動チューニング機能でコスト削減できるかどうかは、ワークロードの使用状況と、設定したパフォーマンスの高さによって決まります。ボリュームに対してこの機能を有効にし、設定する前に、アプリケーションの需要、使用パターン、および予算を理解する必要があります。OCI Block Volumeの価格設定のページを参照して、予算に基づいてボリュームのパフォーマンスの自動チューニング範囲を決定してください。
はい。ボリュームのメトリックと監査ログを使用して、ボリュームのパフォーマンス特性や設定を監視することができます。ブロック ボリュームのメトリックと監査ログの詳細については、ドキュメント をお読みください。
組み込みの修復メカニズムを使用して、データの複数のコピーが複数のストレージ・サーバーに冗長に保存されます。Block Volumesサービスは、ブロックボリュームとブートボリュームに関して年間99.99%（フォー・ナイン）の耐久性を提供するように設計されています。ただし、可用性ドメインの障害から保護するために、定期的にバックアップを作成することをお勧めします。
ダウンタイムなしで、オンラインでボリュームのサイズを増やすことができます。詳しくは、テクニカル・ドキュメントのページ をご覧ください。
ブロックボリュームをアタッチするとき、アクセス・タイプを読み取り専用に指定するオプションがあります。このオプションでは、インスタンスはボリューム上のデータの読み取りのみが可能で、変更はできません。このオプションにより、未テストのアプリケーションや信頼できないアプリケーションによる偶発的または悪意のある変更からデータを保護できます。
また、複数の計算インスタンスがあり、それぞれがクライアント・アプリ（Webフロントエンドなど）を実行している場合に、読み取り専用で同じボリュームにアクセスする場合にも、読み取り専用アタッチを使用することができます。例えば、静的な製品カタログ情報をクライアントに提供するWebフロントエンドの場合です。
ブートボリュームは本質的に変更可能なため、デフォルトでは読み取り専用ではありません。ブートボリュームをデタッチした後、デバッグのために読み取り専用でアタッチすることはできます。
いいえ。そのためには、まずボリュームをデタッチし、「読み取り専用」属性を指定して再アタッチする必要があります。
いいえ。そのためには、まずボリュームをデタッチし、デフォルトのアタッチ・モード（「読み取り／書き込み」）を指定して再アタッチする必要があります。
iSCSIと準仮想化の2つのオプションがあります。準仮想化ボリューム・アタッチは、VMインスタンスでのみサポートされています。
準仮想化ボリューム・アタッチは、iSCSIイニシエータおよびアタッチを必要とせずに、ネイティブのオペレーティング・システムをサポートするブロックボリュームです。すべてのオラクルのオペレーティング・システム、Linux、およびWindowsは、VMデプロイメントのオプションとして準仮想化アタッチをサポートしています。
準仮想化アタッチを使用すると、ブロックボリューム・アタッチの構成プロセスが簡素化されます。ボリューム・アタッチ中にiSCSI構成コマンドを実行したくない場合は、代わりに準仮想化アタッチの使用を検討することをお勧めします。iSCSIでは、追加の初期構成ステップの手間はかかりますが、パフォーマンスが優れていることに注意してください。
その答えは「はい」です。ボリュームをアタッチするときに、CLI/SDKやコンソールで接続タイプを選択できます。アタッチ・タイプを変更するには、ボリュームをデタッチしてから、新しいアタッチ・タイプを指定して再アタッチする必要があります。
準仮想化アタッチのパフォーマンスは、iSCSIアタッチよりも劣ります。詳しくは、Block Volume Performanceドキュメント を参照してください。
その答えは「はい」です。OCI Block Volumesは、統合バックアップ機能を備えており、ブロックボリュームのコピーをOCI Object Storageに保存することによってデータを保護します。
その答えは「はい」です。ブートボリューム・バックアップでは、ブロックボリューム・バックアップのすべての機能を使用できます。Block Volumesは、オペレーティング・システム・ディスクをブートボリュームとして管理します。ブートボリュームの内容をバックアップするには、他のブロックボリュームと同じようにバックアップを作成します。OCIのブートボリュームは、統合バックアップ機能を備えており、ブートボリュームのコピーをOCI Object Storageに保存することによってデータを保護します。インスタンスの実行中にブートボリュームのバックアップを作成すると、クラッシュ整合性のあるバックアップが作成されます。ほとんどの場合、ブートボリューム・バックアップからインスタンスを直接作成したり、ブートボリューム・バックアップをインスタンスにアタッチしてデータを回復したりできます。起動可能なイメージを確保するには、インスタンスからカスタム・イメージを作成します。
バックアップは、そのバックアップが開始されたときのブロックボリューム上のすべてのデータの完全なポイントインタイム・スナップショットのコピーです。バックアップが完了するとすぐに、バックアップを使用してブロックボリュームに復元できます。バックアップは暗号化され、OCI Object Storageのアカウントにコピーされます。
バックアップの主な用途は、ビジネス継続性、災害復旧、および長期アーカイブをサポートすることです。バックアップ・スケジュールを決定するとき、バックアップの計画と目標では以下を考慮する必要があります。
バックアップは、ポイントインタイム・スナップショットを使用して行われます。したがって、バックアップがバックグラウンドで非同期的に実行されている間、アプリケーションは、中断やパフォーマンスへの影響が発生することなく、データへのアクセスを継続できます。2 TBのボリュームを初めてバックアップする場合、バックアップが完了するまで約30分かかります。50 GBのボリュームを初めてバックアップする場合、バックアップが完了するまで数分かかります。以降、同じボリュームのバックアップにかかる時間は、最後のバックアップ以降に変更されたデータの量に依存します。
次の2つのオプションがあります。
1.ポリシーベースの自動スケジュール・バックアップ。オラクルが提供する定義済みのバックアップ・ポリシーを使用するか、独自のカスタム・バックアップ・ポリシーを作成して使用することができます。定義済みおよびカスタムのどちらのバックアップ・ポリシーでも、バックアップの頻度と保持期間を設定します。これにより、データ・コンプライアンスと規制要件を順守することができます。選択したバックアップ・ポリシーに基づいて、データがスケジュールに従って自動的にバックアップされて保持されるため、安心です。後でニーズの変化に応じて、別のバックアップ・ポリシーを選択したり、カスタム・ポリシーを変更したりして簡単に調整することができます。また、バックアップ・ポリシーをまとめて削除することもできます。
2.オンデマンドの1回限りのバックアップ。最後のバックアップ以降に変更されたデータのみをバックアップするか（増分バックアップ）、ボリュームを作成してから変更されたデータすべてをバックアップするか（完全バックアップ）を選択できます。
詳細については、テクニカル・ドキュメントを参照してください。
その答えは「はい」です。最後のバックアップ以降に変更されたデータのみをバックアップするか（増分バックアップ）、ボリュームを作成してから変更されたデータすべてをバックアップするか（完全バックアップ）を選択できます。
バックアップはポイントインタイム・スナップショットで行われるため、データへのアクセスに影響を与えることなく非同期で継続されます。バックアップ中のブロックボリュームへのアクセスは、中断、レイテンシの増加、パフォーマンスへの影響が発生することなく継続されます。
独自のカスタム・バックアップ・ポリシーを作成して適用できます。また、OCI Block Volumeサービスには、このドキュメントに記載されている、3つの異なる定義済みバックアップ・ポリシーが用意されています。
その答えは「はい」です。日次、週次、月次、年次スケジュールを含む独自のバックアップ・ポリシーを作成し、そのポリシーをボリュームに割り当てて自動バックアップを行うことができます。また、既存のポリシーを複製し、必要に応じてスケジュールのパラメータを変更したり、ポリシーのスケジュールを追加または削除したりして、複製したポリシーをカスタマイズすることもできます。詳細については、テクニカル・ドキュメントを参照してください。
既存のバックアップは、そのまま残ります。ただし、ポリシーに基づいて自動的に作成されたすべてのバックアップには有効期限があり、有効期限が切れると自動的に削除されます。手動で作成されたバックアップには有効期限がなく、削除されるまで残ります。
既存のバックアップは、そのまま残ります。ただし、有効期限が切れると、作成時に有効だった設定に基づいて自動的に削除されます。ポリシーに基づいて自動的に作成されたすべてのバックアップには有効期限があり、有効期限が切れると自動的に削除されます。ボリュームのバックアップ・ポリシーを別のポリシーに変更すると、新しいポリシーが有効になり、新しいポリシーに従って新しいバックアップが自動的に作成されます。
バックアップとボリュームのライフサイクルは異なります。ボリュームが削除された場合、作成したバックアップの種類によっては、バックアップがボリュームのライフサイクルを超えて存続することがあります。ポリシーベースのバックアップには有効期限があります。有効期限が切れると、それらのバックアップは自動的に削除されます。バックアップをもっと長く保存したい場合は、手動でバックアップを作成する必要があります。手動で作成したバックアップには有効期限がありません。
その答えは「はい」です。コンソール、CLI/SDK、およびTerraformで変更できます。詳細については、オンラインのテクニカル・ドキュメントを参照してください。
オラクルが提供する定義済みのバックアップ・ポリシーを使用して作成されたバックアップは、ボリュームが存在するOCI可用性ドメインのタイムゾーンに基づいています。リージョン内のすべてのOCI可用性ドメインは同じタイムゾーンにあるため、事実上、スケジュール・バックアップはリージョンのタイムゾーンに基づくことになります。
カスタム・バックアップ・ポリシーでは、ポリシーの各スケジュール項目に対して、UTCとボリュームの存在するデータセンターのタイムゾーンのどちらを使用するかを指定できます。
はい、複数の異なるスケジュールを作成できますが、各ボリュームをバックアップできるのは1日につき1回だけです。各カスタム・バックアップ・ポリシーでは、最大1つの日次スケジュール・エントリー、最大7つの週次スケジュール・エントリー（特定の時間に毎日1つ）、最大31の月次のスケジュール・エントリー（特定の時間に毎日1つ）、最大365の年次のスケジュール・エントリー（月、日、時間を指定）を設定することができます。特定の日にボリュームに対して複数のバックアップがスケジュールされている場合、サービスは年、月、週、日の優先順位でそのうちの1つだけを実行します。詳細については、テクニカル・ドキュメントを参照してください。
たとえば、毎日午前0時に日次バックアップ、毎週月曜日午前0時に週次バックアップを設定した場合、毎週月曜日には2つのバックアップがスケジュールされていることになります。同じ日に2つのバックアップがスケジュールされているため、保持時間が長くなる週次バックアップが優先されます。翌日、日次のバックアップしかスケジュールされていない場合、火曜日のバックアップは日次のスケジュール・バックアップとなり、翌日の次のスケジュール・バックアップまで保持されるように設定されています。
スケジュール・バックアップが、予定どおりに実行されるように最善が尽くされます。ただし、システム負荷に基づいて、システム内の他のすべてのスケジュール・バックアップ・リクエストとともにキューに設定されて処理される場合があります。バックアップ・ステータスをチェックして、バックアップが完了したことを確認し、必要に応じて手動バックアップをトリガーしてください。
ボリューム・サイズに関係なく、1分未満でボリュームを復元できます。ボリュームの復元は高速で、ワークロードのためにボリュームにすぐにアクセスできますが、復元されたボリュームの使用を最初に開始する際に、レイテンシが急上昇する場合があります。
新しく復元されたボリュームへのリクエストは、復元直後の短い期間、レイテンシが高くなる場合があります。
その答えは「はい」です。バックアップは、バックアップが保存されている同じリージョン内の任意の可用性ドメインに復元できます。これは、データを効率的に移動するために推奨される方法です。
はい。ブートボリュームのバックアップは、手動で作成するか、ポリシーベースの自動スケジュール・バックアップを使用して作成できます。また、コンピュート・サービスに関するよくある質問に従って、実行中のインスタンスからイメージを作成するオプションも確認してください。
はい。クロスリージョン・バックアップ・コピー機能を使用して、既存のBlock Volumeバックアップをアクセス可能な別のリージョンにコピーできます。
その答えは「はい」です。バックアップからさらに大きなボリューム（現在サポートされている最大32 TBのボリューム・サイズまで）に復元することができます。
クローンは、Block Volumeの機能の1つで、バックアップおよび復元プロセスを実行することなく、既存のブロックボリューム全体を新しいボリュームにコピーできます。ソース・ボリュームのポイントインタイムのディープ・コピー（シック・クローンとも呼ばれる）を直接バックアップなしで作成します。
はい。ブロックボリューム・クローンを作成するのと同じように、ブートボリューム・クローンを作成できます。インスタンスの実行中にブートボリューム・クローンを作成すると、クラッシュ整合性クローンが作成されます。ほとんどの場合、ブートボリューム・クローンからインスタンスを直接作成したり、ブートボリューム・クローンをインスタンスにアタッチしてデータを回復したりできます。起動可能なイメージを確保するには、インスタンスからカスタム・イメージを作成します。
クローン操作はすぐに実行され、クローン操作を開始するとすぐにクローン・ボリュームを使用できるようになります。実際のデータのコピーは、バックグラウンドで行われます。所要時間は、ソース・ボリュームのデータ量に比例し、1 TBのボリュームに対して最大15分かかる場合があります。
クローンは、ライフサイクルが「利用可能」状態になったら（通常、数秒以内）、通常のボリュームとしてアタッチして使用できます。ハイドレーションは、バックグラウンドで継続されます。まだコピーされていないデータのブロックについては、レイテンシ・スパイクが発生する場合があります。
Block Volumesクローンは、ボリューム全体のポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーです。コピーオンライトまたはソース・ボリュームへの依存関係がないため、スナップショットとは異なります。関連するバックアップもありません。ブロックボリューム・クローンを作成するときに、スナップショットを作成したり、Object Storageにバックアップしたり、バックアップから復元したりすることはありません。
いいえ。クローンは、ソース・ボリュームのポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。ボリュームのクローンを作成する前に、ボリュームをデタッチする必要はありません。
クローンは、ソース・ボリュームのポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。クローンが「使用可能」になった時点のソース・ボリュームのすべてのデータがクローン・ボリュームにコピーされます。ソース・ボリュームでそれ以降に行われた変更は、クローンにコピーされません。
いいえ、ブロックボリュームは、その可用性ドメインに固有です。ボリュームのクローンは、同じ可用性ドメイン内でのみを作成できます。
その答えは「はい」です。クローン元コンパートメントおよびクローン先コンパートメントに対する必要なアクセス権限が必要になります。
いいえ。ボリュームは、テナント境界内でのみアクセスできます。
いいえ。ブロックボリュームは、可用性ドメインに固有のものであり、作成されたリージョンに存在します。ボリュームのクローンは、それらが存在するリージョンの同じ可用性ドメイン内にしか作成できません。
その答えは「はい」です。最大32 TBのクローン・サイズを指定できます。
ソース・ボリュームがアタッチされているかどうかによって異なります。
作成中のクローン・ボリュームのライフサイクルによって異なります。
クローン操作とバックアップ操作は相互に排他的です。ボリュームに対してバックアップが進行中である場合、ボリュームがアタッチされているかどうかに関係なく、クローンを作成したり、再度バックアップしたりすることはできません。ボリュームに対してクローン作成が進行中である場合、ボリュームがアタッチされているかどうかに関係なく、バックアップすることはできません。
いいえ。ソース・ボリュームからいずれかのクローンにハイドレートされている間は、ソース・ボリュームを削除することはできません。
クローンのライフサイクルが「利用可能」状態になると、クローンを削除できます。まだハイドレートされているクローンについても、ライフサイクルが「利用可能」状態になると削除できることに注意してください。
これは、ソース・ボリュームからクローンを開始し、クローンがソース・ボリュームからハイドレートされている間に、ソース・ボリュームをコンピュート・インスタンスにアタッチしてデタッチした場合に発生する可能性があります。この場合、同じソース・ボリュームに対して別のクローン・リクエストを開始すると、新しいクローンが終了状態になります。これにより、ハイドレート中の最初のクローンに影響が生じることはありません。最初のクローンが完全にハイドレートされると、ソース・ボリュームに対する後続のクローン操作が期待どおりに実行されます。
ブートボリュームは、デフォルトで暗号化されたリモート・ブート・ディスクを提供し、ベアメタルおよび仮想マシン・インスタンスに、高速なパフォーマンス、起動時間の短縮、および耐久性の向上をもたらします。さらに、ブートボリュームを使用すると、再起動することなく、実行中の仮想マシンについて非常に高速なカスタム・イメージを作成できます。すべてのベアメタルおよび仮想マシンのコンピュート・インスタンスは、ブートボリュームを使用して起動し、以下のような利点を提供します。
ベアメタルまたは仮想マシン・コンピュート・インスタンスを新しく起動すると、コンパートメント内に新しいブートボリュームが自動的に作成されます。OCIコンソールのインスタンスの詳細ページで、インスタンスにアタッチされているブートボリュームを確認できます。コンパートメント内のすべてのブートボリュームが「ブロック・ストレージ」コンソール・ページの「ブートボリューム」の下にリストされます。ブートボリュームの詳細には、ブートボリュームがアタッチされているインスタンス、ボリュームのサイズ、およびその他のボリューム・メタデータが含まれています。
ブートボリュームは、標準のBlock Volume価格で課金されます。これは、コンピュート・インスタンスの価格とは別に請求されます。
はい。ブートボリュームは、ブロックボリュームと同様に、計測されてテナンシ・ブロック・ストレージ制限に含まれます。そのため、ブロックボリュームの消費量に加えて、ブートボリュームの消費量も、テナンシ・ブロック・ストレージ制限の計算および計画に含める必要があります。
はい。最初に目的のブートボリュームのカスタム・イメージを作成し、そのカスタム・イメージを使用してインスタンスを起動することにより、特定のブートボリュームを使用して別のインスタンスを起動できます。カスタム・イメージを作成したくない場合は、アタッチされていないブートボリュームから直接新しいインスタンスを起動することもできます。
ブートボリュームは、すべて耐久性の高いBlock Volumes上に作成されます。ブートボリュームは、コンピュート・インスタンスのライフサイクルに関係なく保持されます。ブートボリュームは、手動で削除した場合にのみ終了します。
新しいインスタンスには、すべてデフォルトでブートボリュームが使用されます。カスタム・イメージを作成して新しいインスタンスを起動することにより、既存のインスタンスを再プロビジョニングできます。
はい。OCIコンソールの「コンピュート」ページにアクセスするか、API/CLIを使用して、ブートボリュームのバックアップを作成できます。バックアップは、バックアップ元のブートボリュームに関連付けられます。
はい。コンソールまたはAPI/CLIを使用して、アタッチされていないブートボリュームを削除できます。また、インスタンスを終了するときに、削除確認ダイアログでチェックボックスを選択することにより、ブートボリュームを自動的に削除することを選択することもできます。
OCIでは、インスタンスに現在アタッチされているブートボリュームを削除することはできません。インスタンスを停止し、ブートボリュームをデタッチしてから、デタッチしたブートボリュームを削除することができます。ブートボリュームを削除した後は、停止したインスタンスを開始することはできません。インスタンスは終了するほかありません。
いいえ。ブートボリュームは、停止しているインスタンスからのみデタッチできます。インスタンスを終了すると、ブートボリュームを完全に削除することを選択しない限り、ブートボリュームが自動的にデタッチされて保持されます。
その答えは「はい」です。別のインスタンスにアタッチするには、関連付けられているコンピュート・インスタンスから最初にブートボリュームをデタッチする必要があります。
以下の手順に従って、ブートボリュームをデバッグできます。
1. 古いインスタンスを終了し、インスタンスを終了するときに、元のブートボリュームを保持します（ブートボリュームを保持するかどうかを尋ねる確認ダイアログで「はい」を選択します）。
2 古いインスタンスから保持したブートボリュームを選択して、異なるシェイプの新しいインスタンスを起動します。
この方法は、ベアメタル・インスタンスおよびVMインスタンスの両方に適用されます。
*注意：新しいインスタンスは、元のインスタンスとは異なるIPアドレスとネットワーク構成になります。これらのインスタンスを使用するワークロードのシームレスなエクスペリエンスを実現するには、これらの違いを調整する必要があります。
ブートボリュームでは、ローカル・ブート・ディスクと比較して、コンピュート・インスタンスの起動時間を短縮できます。Linuxインスタンスは1分以内に起動し、Windowsインスタンスも5分以内に起動します。
ブートボリュームは、デフォルトでは標準のOracle OSイメージ・サイズとなり、50 GBのブートボリュームに対して、3,000回のIOPSと24 MB／秒のスループットをミリ秒未満のレイテンシで実現します。これより大きなブートボリュームについても、Block Volumesと同様に、サイズに比例してパフォーマンスが向上するため、パフォーマンスを予測することができます。このパフォーマンスは、ワークロードの種類に依存しません（すべての読み取り／書き込みディストリビューションの場合）。詳しくは、Block Volume Performanceドキュメント を参照してください。
OCIプラットフォームですでに使用している既存のカスタム・イメージがある場合は、それを使用してインスタンスを起動することを選択できます。カスタム・イメージを使用してインスタンスを起動した場合に作成されるブートボリュームは、カスタム・イメージと同じサイズになります。
その答えは「はい」です。コンピュート・インスタンスの起動時に、選択したOSイメージのデフォルトのサイズから最大32 TBまで、1 GB単位で任意のサイズを指定できます。ブートボリュームの最小サイズは、選択したOSイメージのサイズによって制限されます。50 GBまたは選択したOSイメージより小さいサイズを指定することはできません。たとえば、サイズが256 GBのOSイメージを選択した場合、使用するように指定できるブートボリュームの最小サイズは256 GBです。
はい。ダウンタイムなしで、オンラインでブートボリュームのサイズを増やすことができます。詳しくは、テクニカル・ドキュメント をご覧ください。
インスタンス起動APIを使用し、bootVolumeSizeInGBsパラメータを使用してもっと大きなブートボリューム・サイズを指定します。指定されたサイズがイメージ・サイズよりも小さい場合、API呼び出しは失敗しますのでご注意ください。
インスタンスは、選択したOSイメージのサイズに等しいデフォルトのブートボリューム・サイズで起動されます。
ボリュームグループは、バックアップやクローン作成で単一のエンティティとして扱うことができるブロックボリュームのセットを表します。ボリュームグループは、単一の可用性ドメインに関連付けられており、グループ内のボリュームも同じ可用性ドメイン内にあります
ボリュームグループには、個々のボリュームと同じバックアップ／復元およびクローン機能があります。つまり、ボリュームグループのポイントインタイム・クラッシュ整合性連携バックアップ（増分または完全）を実行したり、ボリュームグループのポイントインタイム・クラッシュ整合性クローンを作成したりできます。
1つのボリュームグループに最大32個のボリュームを含めることができますが、ボリュームグループの合計サイズは128 TBです。これはソフト・リミットであるため、制限の引き上げをリクエストすることで、テナントごとに増やすことができます。各ボリュームは、1つのボリュームグループにのみ含めることができます。
コンソール、CLI /SDK、API、およびTerraformを使用して、ボリュームグループを管理できます。これには、ボリュームグループの作成と削除、ボリュームグループに含めるボリュームの追加と削除、およびボリュームグループの名前の変更が含まれます。
その答えは「はい」です。ボリュームグループに含まれるボリュームは、グループとして管理できることに加えて、個別にアクセスおよび操作できます。
ボリュームグループに含まれるボリュームセット全体のポイントインタイム・クラッシュ整合性連携バックアップのことです。バックアップ・プロセス中、バックアップ元のボリュームグループおよびボリュームへの影響はありません。
ボリュームグループ・バックアップは、ソースのボリュームグループが存在するリージョン内のすべての可用性ドメインに複製されます。ボリュームグループ・バックアップを使用して、ボリュームグループに含まれるすべてのボリュームを復元することにより、バックアップが存在するリージョン内の任意の可用性ドメインに新しいボリュームグループを作成できます。
その答えは「はい」です。詳細についてはドキュメントをご覧ください。
ボリュームグループ・クローンは、ボリュームグループに含まれるボリュームセット全体のポイントインタイム・クラッシュ整合性ディープ・ディスク・ツー・ディスク・コピーのことです。この操作により、新しいボリュームを含む新しいボリュームグループが作成されます。これらは、ソースのボリュームグループとそれに含まれるボリュームをそのままコピーしたものです。
クローン操作はすぐに実行され、クローン操作を開始するとすぐにクローン・ボリュームグループとそれに含まれるクローン・ボリュームを使用できるようになります。実際のデータのコピーは、バックグラウンドで行われます。所要時間は、ソース・ボリュームのデータ量に比例し、クローン作成には1TBのボリュームに対して最大15分かかる場合があります。
ソースのボリュームグループとそれに含まれるボリュームは、クローン・プロセスの影響を受けません。クローン元とクローン先のボリュームグループとそれに含まれるボリュームセットは、完全に分離されており、何も共有されていません。これにより、クローン操作の進行中およびクローン操作の完了時にソースに影響が出ないようになっています。
ボリュームグループ内のソース・ボリュームがアタッチされているかどうかによって異なります。
これらの機能は、追加料金なしで提供されています。ブロックおよびブートボリューム・ストレージ（Block Volumesの価格）とボリュームグループ・バックアップ（Object Storageの価格）に対してのみ実際の使用量に基づいて課金されます。
ボリュームグループの開始方法と管理方法の詳細については、ボリュームグループのドキュメントを参照してください。
プロビジョニングされたボリューム・サイズ（GB）と各ボリュームに選択されたパフォーマンス・オプションに基づいてBlock Volumesが計測されます。使用されているBlock Volumeに対してBlock Volumesの価格で請求が行われます。
Block Volumesのバックアップは、Object Storageに保存され、それらによって消費されるObject Storageに基づいて計測および請求が行われます。詳細については、Object Storageの価格を参照してください。
OCI Storageの価格を参照してください。クロスリージョン・バックアップは、Object Storageおよびアウトバウンド・データ転送ネットワークの使用量に基づいて計測および請求が行われます。