Share via


Azure Backup 用語集

この用語集は、Azure Backup を使用する場合に役立ちます。

Note

  • "(ワークロード固有の用語)" というプレフィックスでマークされている用語は、Azure Backup がサポートするワークロードの特定のサブセットのコンテキストにのみ関連する用語を指します。
  • Azure Backup ドキュメントで一般的に使用されているものの、他の Azure サービスを指す用語については、関連する Azure サービスのドキュメントへの直接リンクが提供されています。

AFS (Azure ファイル共有)

Azure Files のドキュメントを参照してください。

別の場所の復旧

復旧ポイントからバックアップが作成された元の場所以外の場所に対して実行される復旧。 Azure VM バックアップを使っている場合、これはバックアップが作成された元のサーバーとは別のサーバーに VM を復元することを意味します。 Azure ファイル共有のバックアップを使っている場合、これはバックアップされたファイル共有とは異なるファイル共有にデータを復元することを意味します。

アプリケーション整合性バックアップ

(ワークロード固有の用語)

アプリケーション整合性バックアップによって、メモリの内容と保留中の I/O 操作がキャプチャされます。 アプリ整合性スナップショットでは、バックアップが発生する前にアプリ データの整合性を保証するために、VSS ライター (または Linux の事前/事後スクリプト) が使用されます。 詳細については、こちらを参照してください

Azure Resource Manager (ARM) テンプレート

ARM テンプレートのドキュメントを参照してください。

自動保護 (データベースの場合)

(ワークロード固有の用語)

自動保護は、スタンドアロンの SQL Server インスタンスまたは SQL Server Always On 可用性グループのすべてのデータベースを自動的に保護できる機能です。 これにより、既存のデータベースのバックアップが有効になるだけでなく、将来追加されるすべてのデータベースも保護されます。

可用性 (ストレージ レプリケーションの種類)

Azure Backup では、ストレージとデータの高可用性を維持するため、次の 3 種類のレプリケーションが提供されます。

LRS

ローカル冗長ストレージ (LRS) では、データセンターのストレージ スケール ユニットにバックアップ データが 3 回レプリケートされます (バックアップ データのコピーが 3 つ作成されます)。 バックアップ データのすべてのコピーは、同じリージョン内に存在します。 LRS は、ローカル ハードウェアの障害からバックアップ データを保護するための低コストのオプションです。

GRS

geo 冗長ストレージ (GRS) は、既定の推奨レプリケーション オプションです。 GRS では、セカンダリ リージョン (ソース データのプライマリの場所から数百マイル離れた場所) にバックアップ データがレプリケートされます。 GRS は LRS よりもコストがかかりますが、地域的な障害が発生しても、高いレベルの持続性がバックアップ データに提供されます。

Note

リージョン間の復元機能が有効になっている GRS コンテナーの場合、バックアップ ストレージが GRS から RA-GRS (読み取りアクセス geo 冗長ストレージ) にアップグレードされます。

ZRS

ゾーン冗長ストレージ (ZRS) は、可用性ゾーン内のバックアップ データをレプリケートし、同じリージョン内でバックアップ データ所在地と回復性を保証します。 そのため、データ所在地を必要とするクリティカルなワークロードは、ZRS にバックアップすることができます。

Azure CLI

Azure CLI のドキュメントを参照してください。

Azure Policy

Azure Policy のドキュメントを参照してください。

Azure PowerShell

Azure PowerShell のドキュメントを参照してください。

Azure Resource Manager (ARM)

Azure Resource Manager のドキュメントを参照してください。

Azure Disk Encryption (ADE)

Azure Disk Encryption のドキュメントを参照してください。

バックエンド ストレージ/クラウド ストレージ/バックアップ ストレージ

バックアップ インスタンスによって使用される実際のストレージ。 バックアップ インスタンスに存在するすべての保有ポイント (バックアップとアイテム保持ポリシーによって定義) のサイズが含まれます。

ベア メタル バックアップ

オペレーティング システム ファイルとクリティカルなボリューム上のすべてのデータ (ユーザー データを除く) のバックアップ。 定義上、ベア メタル バックアップには、システム状態のバックアップが含まれます。 これは、コンピューターが起動せず、すべてを復旧する必要があるときの保護を提供します。 詳細については、こちらを参照してください

バックアップ拡張機能/VM 拡張機能

(Azure VM ワークロードの種類に固有)

Azure 仮想マシン (VM) 拡張機能は、Azure VM でのデプロイ後の構成と自動タスクを提供する複数の小さなアプリケーションです。 Azure Backup では、マシンで実行されている Azure VM エージェントに拡張機能をインストールすることで、Azure VM がバックアップされます。 Azure Backup はこれらの拡張機能を自動的に管理するため、ユーザーはこれらの拡張機能を手動で更新する必要がありません。

バックアップ インスタンス/バックアップ項目

特定のバックアップとアイテム保持ポリシーを使用してコンテナーにバックアップされたデータソースによって、バックアップ インスタンスまたはバックアップ項目が構成されます。

バックアップ規則/バックアップ ポリシー

バックアップ規則は、データソースでバックアップを実行するタイミングと頻度を指定する、ユーザー定義の規則です。 ワークロードの種類によっては、バックアップ ポリシーによって、データソースに適用されるスナップショット方法 (完全、増分、差分) を指定する方法も用意されています。 バックアップ ポリシーは、多くの場合、バックアップ規則と保持規則の組み合わせとして作成されます。

バックアップ資格情報コンテナー

Microsoft.DataProtection/BackupVaults 型の Azure Resource Manager リソースです。 現時点では、バックアップ コンテナーは、PostgreSQL サーバーに Azure データベースをバックアップするために使用されます。 バックアップ コンテナーに関する詳細情報を参照してください

BCDR (事業継続とディザスター リカバリー)

BCDR には、計画された、または計画外のサービスや Azure の停止時にアプリとワークロードを確実に稼働させ、ビジネスの中断を最小限に抑えるために、組織が採用する必要がある一連のプロセスが含まれます。 Azure が提供する、適切な BCDR 戦略の作成に役立つさまざまなサービスについて、詳細を確認してください

チャーン

2 つの連続するバックアップの間でバックアップされているデータの変更の割合。 これは、新しいデータの追加、または既存のデータの変更または削除が原因である可能性があります。

クラッシュ整合性バックアップ

(ワークロード固有の用語)

クラッシュ整合性スナップショットは、通常、バックアップ時に Azure VM がシャットダウンした場合に発生します。 バックアップ時にディスクに既に存在していたデータのみが、キャプチャされバックアップされます。 詳細については、こちらを参照してください

リージョンをまたがる復元 (CRR)

復元オプションの 1 つである、リージョンをまたがる復元 (CRR) を使用すると、セカンダリ リージョン (Azure のペアになっているリージョン) でバックアップ項目を復元できます。

Data Box

Data Box のドキュメントを参照してください。

データソース

バックアップの候補であるリソース (Azure リソース、プロキシ リソース、またはオンプレミスのリソース)。 たとえば、Azure VM や Azure ファイル共有などです。

DPM (Data Protection Manager)

(ワークロード固有の用語)

DPM のドキュメントを参照してください。

ExpressRoute

ExpressRoute のドキュメントを参照してください。

ファイル システム整合性バックアップ

(ワークロード固有の用語)

ファイル システム整合性バックアップでは、同時にすべてのファイルのスナップショットを作成することで整合性が提供されます。 詳細については、こちらを参照してください

フロントエンド ストレージ/ソース サイズ

データソースにバックアップするデータのサイズ。 データソースのフロントエンドのサイズによって、その保護されたインスタンスの数が決まります。

完全バックアップ

完全バックアップでは、すべてのバックアップでデータ ソース全体のコピーが格納されます。

GFS バックアップ ポリシー

GFS (Grandfather-father-son) バックアップ ポリシーは、毎日のバックアップ スケジュールに加えて、週単位、月単位、および年単位のバックアップ スケジュールを定義できるようにするものです。 週単位のバックアップは "son (息子)" と呼ばれ、月単位のバックアップは "father (父)" と呼ばれ、年単位のバックアップは "grandfather (祖父)" と呼ばれます。 これらのバックアップ コピーの各セットは、さまざまな期間で保持されるように構成できます。これにより、バックアップ コピーの保持期間の選択をさらにカスタマイズできます。 GFS ポリシーは、より保存効率の高い方法でバックアップを長期間保持するのに役立ちます。

IaaS VM/Azure VM

Azure VM のドキュメントを参照してください。

増分バックアップ

増分バックアップでは、前回のバックアップ以降に変更されたブロックのみが格納されます。

インスタント復元

(ワークロード固有の用語) インスタント復元では、コンテナー内のスナップショットのコピーからではなく、バックアップ スナップショットから直接マシンが復元されます。 インスタント復元は、コンテナーからの復元よりも高速です。 使用できるインスタント復元ポイントの数は、スナップショット用に構成された保持期間によって異なります。 現時点では、Azure VM のバックアップにのみ適用されます。

IOPS

1 秒あたりの入出力処理。

項目レベルの復元

(ワークロード固有の用語)

マシン内の復旧ポイントからの個々のファイルまたはフォルダーの復元。

ジョブ

ユーザーまたは Azure Backup サービスによって作成されるバックアップ関連タスク。 ジョブは、スケジュールする、またはオンデマンド (アドホック) にすることができます。 ジョブには、バックアップ、復元、保護の構成など、さまざまな種類があります。 ジョブに関する詳細情報を参照してください

MABS/Azure Backup Server

(ワークロード固有の用語)

Azure Backup Server を使用すると、単一のコンソールから Hyper-V VM、Microsoft SQL Server、SharePoint Server、Microsoft Exchange、Windows クライアントなどのアプリケーションのワークロードを保護することができます。 DPM からワークロードのバックアップ機能の多くを継承していますが、いくつかの違いがあります。 詳細情報

マネージド ディスク

マネージド ディスクのドキュメントを参照してください。

MARS エージェント

(ワークロード固有の用語)

これは Azure Backup エージェントまたは Recovery Services エージェントとも呼ばれ、MARS エージェントは、オンプレミスのコンピューターや Azure VM のデータを Azure の Recovery Services コンテナーにバックアップするために、Azure Backup によって使われます。 詳細情報。

NSG (ネットワーク セキュリティ グループ)

NSG のドキュメントを参照してください。

オフライン シード処理

オフラインシード処理とは、ネットワーク帯域幅を使用せずに、初期 (完全) バックアップをオフラインで転送するプロセスを指します。 バックアップ データを物理ストレージ デバイスにコピーし、それが近くの Azure データセンターに発送され、Recovery Services コンテナーにアップロードされるというメカニズムが提供されます。 詳細については、こちらを参照してください

オンデマンド バックアップ/アドホック バックアップ

ユーザーが 1 回限りのニーズに基づいてトリガーするバックアップ ジョブであり、リソースに対して構成されているバックアップ スケジュール (ポリシー) には基づきません。

元の場所への復旧 (OLR)

復元ポイントから、バックアップが作成されたソースの場所に対して実行される復旧。復旧ポイントに格納されている状態によって、それが置き換えられます。 Azure VM バックアップを使っている場合、これはバックアップが作成された元のサーバーに VM を復元することを意味します。 Azure ファイル共有のバックアップを使っている場合、これはバックアップされたファイル共有にデータを復元することを意味します。

Passphrase

(ワークロード固有の用語)

パスフレーズは、MARS エージェントを使用して Azure との間でオンプレミスまたはローカル マシンをバックアップまたは復元するときに、データを暗号化および復号化するために使用されます。

プライベート エンドポイント

プライベート エンドポイントのドキュメントを参照してください。

保護されたインスタンス

保護されたインスタンスとは、Azure へのバックアップを構成するために使用するコンピューター、物理または仮想サーバーを指します。 課金の観点からは、マシンの保護されたインスタンスの数はそのフロントエンドのサイズと相関しています。 このため、1 つのバックアップ インスタンス (Azure にバックアップされた VM など) が、フロントエンドのサイズに応じて、複数の保護されたインスタンスに対応する可能性があります。 詳細については、こちらを参照してください

RBAC (ロールベースのアクセス制御)

RBAC のドキュメントを参照してください。

復旧ポイント/復元ポイント/保有ポイント/ポイントインタイム (PIT)

バックアップされている元のデータのコピーです。 保有ポイントはタイムスタンプに関連付けられているので、これを使用して特定の時点に項目を復元できます。

Recovery Services コンテナー

Microsoft.RecoveryServices/vaults 型の Azure Resource Manager リソースです。 現時点では、Recovery Services コンテナーを使用して、次のワークロードがバックアップされます: Azure VM、Azure VM 内の SQL、Azure VM 内の SAP HANA、Azure ファイル共有。 また、MARS、Azure Backup Server (MABS)、および System Center DPM を使用して、オンプレミスのワークロードをバックアップするためにも使用されます。 Recovery Services コンテナーに関する詳細情報を参照してください

Resource group

Azure Resource Manager のドキュメントを参照してください。

REST API

Azure REST API のドキュメントを参照してください。

保持規則

バックアップを保持する期間を指定するユーザー定義の規則。

回復ポイントの目標 (RPO)

RPO は時間単位で測定されたデータの最大許容量です。 たとえば、障害が午後 12:00 に発生したとき、最後のバックアップが午前 10:00 であった場合、RPO は 2 時間です。 つまり、組織は 2 時間分のデータを失うことを問題にしません。

目標復旧時間 (RTO)

RTO は目標時間です。受け入れられない結果を回避するため、障害の発生後、その目標時間内にビジネス プロセスを復旧する必要があります。 たとえば、サーバーの障害が原因で重要なアプリケーションがダウンしたとき、そのビジネスで許容できる最大ダウンタイムが 4 時間の場合、RTO は 4 時間です。

次のシナリオ例では、RPO と RTO の両方の概念について説明します。

組織では、顧客のデータベースに 1 時間の RPO を設定しています。つまり、1 時間おきにバックアップを実行します。 データを失う出来事が発生した場合、1 時間分を超えるデータを失うことはありません。 RTO を 3 時間に設定すると、システム障害が発生した場合、業務への影響を最小限に抑えるため、3 時間以内にデータベースへのアクセスを復元することを目指します。

スケジュールされたバックアップ

指定された項目に対して構成されたバックアップ ポリシーによって自動的にトリガーされるバックアップ ジョブ。

セカンダリ リージョン/ペアになっているリージョン

リージョン ペアは、同じ地域内の 2 つのリージョンで構成されます。 1 つはプライマリ リージョンで、もう 1 つはセカンダリ リージョンです。 一部の Azure サービス (GRS 設定を使用した Azure Backup を含む) は、ビジネスの継続性を確保し、データの損失を防ぐために、ペアになっているリージョンを使用します。 詳細については、こちらを参照してください

論理的な削除

論理的な削除は、バックアップ データが誤って削除されるのを防ぐのに役立つ機能です。 論理的な削除を使用すると、悪意のあるアクターによってバックアップが削除 (またはバックアップ データが誤って削除) された場合でも、バックアップ データはさらに一定期間保持されるので、データを失うことなくバックアップ項目を復旧できます。 詳細については、こちらを参照してください

スナップショット

スナップショットは、仮想ハード ドライブ (VHD) または Azure ファイル共有の完全な読み取り専用コピーです。 ディスク スナップショットおよびファイル スナップショットに関する詳細情報を参照してください。

ストレージ アカウント

ストレージ アカウントのドキュメントを参照してください。

サブスクリプション

Azure サブスクリプションは、Azure でリソースをプロビジョニングするために使用される論理コンテナーです。 仮想マシン (VM) やデータベースなど、すべてのリソースの詳細が保持されます。

システム状態のバックアップ

(ワークロード固有の用語)

オペレーティング システム ファイルをバックアップします。 このバックアップでは、コンピューターの起動時に回復を行えます。ただし、システム ファイルとレジストリは失われます。 詳細については、こちらを参照してください

Tenant

テナントは、組織を表したものです。 これは、組織やアプリの開発者が、Azure、Microsoft Intune、または Microsoft 365 へのサインアップのような Microsoft とのリレーションシップを作成するときに受信する、Microsoft Entra ID の専用インスタンスです。

レベル

現在のところ、Azure Backup では次のバックアップ ストレージ層がサポートされています。

スナップショット層

(ワークロード固有の用語) VM バックアップの最初の段階では、作成されたスナップショットはディスクと共に保存されます。 この形態のストレージはスナップショット層と呼ばれています。 スナップショット層の復元は (コンテナーから復元するより) 速くなります。復元を始動させる前にスナップショットがコンテナーからコピーされるのを待つ時間がなくなるためです。

Vault-Standard 層

Azure Backup でサポートされているすべてのワークロードのバックアップ データは、Azure Backup で管理されるストレージ アカウントの自動スケーリング セットであるバックアップ ストレージを保持するコンテナーに保存されます。 Vault-Standard 層は、Microsoft が管理するテナントにバックアップ データのコピーを隔離保存することを可能にするオンライン ストレージ層です。つまり、保護層が一段厚くなります。 スナップショット層がサポートされるワークロードの場合、スナップショット層と Vault-Standard 層の両方でバックアップ データがコピーされます。 Vault-Standard 層によって、バックアップ対象のデータソースが削除されたり、危険にさらされたりした場合でも、バックアップ データを確実に利用できます。

信頼されたアクセス

多くの Azure サービスは、AKS クラスターにアクセスするために clusterAdmin kubeconfig と "パブリックにアクセス可能な kube-apiserver エンドポイント" に依存しています。 AKS の信頼されたアクセス機能を使用すると、プライベート エンドポイントの制限をバイパスできます。 この機能を使用すると、Microsoft Entra アプリケーションを使用せずに、Azure リソース RoleBinding を使用して AKS クラスターへアクセスすることを許可されたリソースのシステム割り当て ID に明示的に同意できます。 信頼されたアクセス機能を使用すると、非公開のクラスター、ローカル アカウントが無効になっているクラスター、Microsoft Entra ID クラスター、承認された IP 範囲のクラスターを始めとするさまざまな構成の AKS クラスターにアクセスできます。 詳細情報。

アンマネージド ディスク

アンマネージド ディスクのドキュメントを参照してください。

コンテナー

バックアップ データを格納する Azure のストレージ エンティティ。 また、RBAC と課金の単位でもあります。 現在、コンテナーには、Recovery Services コンテナーとバックアップ コンテナーの 2 種類があります。

コンテナー資格情報

コンテナー資格情報ファイルは、コンテナーごとにポータルによって生成される証明書です。 これは、オンプレミス サーバーをコンテナーに登録するときに使用されます。 詳細については、こちらを参照してください

VNET (Virtual Network)

VNET のドキュメントを参照してください。

VSS (Windows ボリューム シャドウ コピー サービス)

VSS のドキュメントを参照してください。

次のステップ