Azure Blob のバックアップと回復を設計する
Azure Backup には、Azure Blob Storage のローカル バックアップ ソリューションである、Azure BLOB の運用バックアップが用意されています。 このバックアップ方法では、バックアップ データは Azure Backup ストレージ コンテナーに転送されるのではなく、ソース Azure ストレージ アカウントに格納されます。
Azure Blob Storage のバックアップと回復について知っておくべきこと
Azure Blob Storage のバックアップと回復に使用できる主な機能の一部を次に示します。
Azure BLOB の運用バックアップでは、"継続的バックアップ" ソリューションが提供されます。 バックアップをスケジュールする必要はありません。
運用 BLOB バックアップでのすべての変更は、指定した期間保持され、選択した時点から復元できます。
論理的な削除機能を使用すると、誤った削除や破損からデータを保護できます。 保有期間中は、論理的に削除された BLOB オブジェクトを削除された時点の状態に復元することができます。 論理的な削除は、BLOB とコンテナーで使用できます。
削除された BLOB またはコンテナーの保有期間は、1 日から 365 日の間で指定できます。 既定の期間は 7 日間です。
運用バックアップ ソリューションでは、BLOB のバージョン管理がサポートされています。 以前のバージョンの BLOB を復元したり、誤った変更や削除の後にデータを回復したりできます。
ブロック BLOB のポイントインタイム リストア機能を使うと、誤った削除や破損から保護できます。 保持期間中は、ブロック BLOB を現在の状態から以前の状態に復元できます。
リソース ロック機能を使用して、リソースが誤って削除または変更されるのを防ぐことができます。 リソース ロックを設定して、削除を禁止したり、読み取り専用にしたりすることができます。
これらの機能の一部について、詳しく見てみましょう。 これらのオプションを確認しながら、どの機能が Tailwind Traders のソリューションにとって有益かを考えてください。
論理的な削除とバージョン管理を使うときに考慮すべきこと
論理的な削除機能を実装して、個々の BLOB、スナップショット、コンテナー、または BLOB のバージョンを誤った削除や上書きから保護できます。 論理的な削除では、指定された保有期間にわたって削除されたデータをシステム内に保持します。 保持期間中は、論理的に削除されたオブジェクトを削除された時点の状態に復元することができます。
次の図は、コンテナーと BLOB の論理的な削除機能の概要と、BLOB のバージョンを示しています。
論理的な削除と BLOB のバージョン管理を実装するには、さまざまなオプションがあります。
BLOB の論理的な削除を実装して、特定の削除されたファイルを復元します (BLOB、スナップショット、BLOB のバージョンなど)。
コンテナーの論理的な削除を使用して、コンテナーとその内容を復元します。
Note
コンテナーの論理的な削除は、ストレージ アカウントの削除から保護するのではなく、ストレージ アカウント内のコンテナーの削除から保護するにすぎません。
BLOB のバージョン管理を追加して、以前のバージョンの BLOB を自動的に維持します。 以前のバージョンの BLOB を復元したり、この機能を使ってデータを回復したりできます。 BLOB のバージョン管理は、複数の作成者が同じファイルを編集する場合に便利です。 BLOB のバージョン管理を実装して、各作成者が行う個々の変更を維持または復元します。
ポイントインタイム リストアを使うときに考慮すべきこと
論理的な削除と同様に、ブロック BLOB のポイントインタイム リストアも、誤った削除や破損から保護します。 ソース ストレージ アカウントの管理ポリシーを作成し、保有期間を指定します。 保持期間中は、ブロック BLOB を現在の状態から以前の状態に復元できます。 ポイントインタイム リストアにより、データ セットを既知の状態に戻す必要があるシナリオをテストしてから、さらなるテストを実行することができます。
次の図は、ポイントインタイム リストアがどのように機能するかを示しています。 1 つ以上のコンテナーまたは BLOB の範囲が以前の状態に復元されます。 このプロセスの結果は、保有期間中に発生した書き込みと削除の操作を元に戻すことです。
リソース ロックを使う場合に考慮すべきこと
リソース ロックを使用して、データを保護し、誤った変更を回避できます。 この機能により、リソースが誤って削除または変更されるのを防ぐことができます。 CanNotDelete と ReadOnly という 2 つのロック レベルがあります。
CanNotDelete では、許可されているユーザーはリソースの読み取りと変更を実行できますが、先にロックを削除しないとリソースを削除することはできません。
ReadOnly では、許可されているユーザーはリソースを読み取ることはできますが、リソースを削除または変更することはできません。 このロックの適用は、すべての承認されたユーザーを、Azure RBAC の閲覧者ロールによって付与されるアクセス許可に制限するのと似ています。