
この記事の内容
LRS・ZRS・GRSでデータを複製していても、それだけで誤って消したデータを元に戻せるとは限りません。 冗長性は主に設備や地域の障害への備え。誤削除や上書きには、過去のデータを保持して復元する仕組みを別に考えます。
この記事では、Azure Storageのストレージアカウントの冗長性と、Blob Storageのデータ保護を扱います。Azureの全サービスに同じ設定がある、という説明ではありません。アカウント作成も操作もせず、架空の会場写真で違いを読んでいきましょう。
冗長性は「どこに複製するか」を考える
Azure Storageはデータを複製し、ハードウェア故障などに備えます。主な名前は、複製する場所から読むと整理できます。
| 方式 | 複製の基本的な範囲 |
|---|---|
| LRS(ローカル冗長ストレージ) | 主リージョンのデータセンター内 |
| ZRS(ゾーン冗長ストレージ) | 主リージョンの複数の可用性ゾーンに同期複製 |
| GRS(geo冗長ストレージ) | 主側はLRSを使い、別リージョンへ非同期複製。副側もLRS |
| GZRS(geoゾーン冗長ストレージ) | 主側はZRSを使い、別リージョンへ非同期複製。副側はLRS |
GRSの「非同期」は、主側で受け付けた最新の変更が、副側にまだ届いていない場合があるということです。別リージョンへの複製があっても、最新データを必ず失わないという保証にはなりません。対応するリージョンやアカウント、サービスの種類も確認が必要です。Azure Storageの冗長性
場所の言葉が混ざるときは、先にリージョンと可用性ゾーンの違いを確認してください。
複製先も「削除後の状態」になる
勉強会アプリが、会場写真を「hall.jpg」というBlobとして保存しているとします。担当者が不要な写真と勘違いし、そのBlobを削除しました。
この削除は、保存装置の故障とは違います。サービスが受け付けたデータの変更なので、冗長なコピーにも反映されます。複製先は、好きな時点までさかのぼれる履歴置き場ではありません。 GRSの複製の遅れを、誤削除を取り消せる猶予として当てにすることもできません。複製とデータ変更の関係
この例で知りたいのは「コピーは何個ある?」に加えて、「削除前の写真を、どの機能で、いつまで保持している?」です。
Blobの論理的な削除とバージョン管理
誤操作への備えとして読む機能に、次の二つがあります。名前が似ていても、残し方は異なります。
論理的な削除:消したデータを期間内だけ残す
Blobの論理的な削除(soft delete)が有効なら、対象となる削除済みデータを設定した期間保持し、その期間内に復元できます。保持期限を過ぎたデータまで、いつでも戻せる機能ではありません。
また、Blob単体を消すことと、入れ物のコンテナーごと消すことは別です。Blobの論理的な削除だけでは、コンテナーやストレージアカウントの削除を保護しません。コンテナーの削除には、コンテナー用の論理的な削除を確認します。Blobの論理的な削除
バージョン管理:変更前の状態を残す
Blobのバージョン管理を有効にすると、以前の状態をバージョンとして保持できます。会場写真を別の写真で上書きした場面なら、以前のバージョンが残っているかが復元を考える手掛かりになります。
ただし、以前のバージョンにも削除や保持の管理が必要です。「変更前の状態が永遠に残る」とは覚えないでください。階層型名前空間を有効にしたアカウントでは、このバージョン管理はサポートされません。機能名だけで判断せず、使うアカウントと操作の対応条件を読みます。Blobのバージョン管理
ここで説明したのはBlob向けの機能です。Azure FilesやVMのマネージドディスクに、そのまま当てはめないようにしましょう。保存先の区別はBlob・Files・マネージドディスクの違いで整理しています。
バックアップも、データの保存場所を確かめる
Azure BackupのBlob向け機能にも違いがあります。「バックアップだから必ず別の保管先へコピーされる」と一括りにしないことが大切です。
- Operational backup:元のストレージアカウント内の保護機能を使う方式。データをBackupコンテナー(Backup vault)へ転送する方式ではありません
- Vaulted backup:バックアップポリシーのスケジュールに従って、データをBackupコンテナー(Backup vault)へコピーし、設定した期間保持する方式
つまり、同じ「バックアップ」でも、元のアカウント内に残すのか、別の保管先に残すのかを確認します。対応するBlobやアカウントの条件、復元できる対象と時点もそれぞれ異なります。Blobバックアップの公式概要
論理的な削除、バージョン管理、バックアップは、保存する量や処理に応じた費用も考える必要があります。この記事は設定の推奨値や料金見積もりを示すものではありません。データ保護の範囲と費用の考え方
最後に、復元のための確認メモを作る
紙に「何が起きたか」「何が消えたか」「どの時点へ戻したいか」の三つを書いて、次の架空の相談を整理してみてください。実際に削除して試す必要はありません。
- 「ZRSを使っています。昨日、会場写真一枚を消しました。戻せますか?」
- 「写真ではなく、写真をまとめたコンテナーを消しました。Blobの論理的な削除は有効でした」
- 「正しい写真を間違った写真で上書きしました。変更前の版に戻したいです」
1は、ZRSという情報だけでは判断できません。 削除前に有効だった保護機能と、保持期間内かを確認します。2は、消えた対象がコンテナーなので、コンテナーの保護やバックアップの対象を確認します。3は、変更前のバージョンや復元点が残っているかを調べる問いです。
どの相談でも、最後は「必要なデータが残っているか」「対象と時点を指定して復元できるか」を確かめます。冗長性の名前と、戻すための備えを、別々の欄に書ければ今回の整理はできています。
出典を開く
- 確認日 https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy
- 確認日 https://learn.microsoft.com/en-us/azure/storage/blobs/data-protection-overview
- 確認日 https://learn.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-overview
- 確認日 https://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview
- 確認日 https://learn.microsoft.com/en-us/azure/backup/blob-backup-overview