update README.md to enhance Azure Data Protection Backup Vault module documentation

This commit is contained in:
2026-03-01 10:57:58 +01:00
parent f8e85a1563
commit 5898aa087c

View File

@@ -1,3 +1,76 @@
# Azure RM Backup Vault Module # Azure Data Protection Backup Vault Module
This module creates an Azure Recovery Services Backup Vault with the specified name, resource group, and location. This module creates an Azure Data Protection Backup Vault with the specified name, resource group, and location.
## Variables
- `rg_name`: The name of the resource group where the backup vault will be created.
- `location`: The Azure region where the backup vault will be created.
- `base_name`: Optional base name used to generate a unique backup vault name when `name` is not set.
- `name`: Optional explicit backup vault name. If omitted, the module generates a deterministic name from `base_name`.
- `datastore_type`: Type of datastore for the backup vault. Allowed values: `ArchiveStore`, `OperationalStore`, `SnapshotStore`, `VaultStore`.
- `redundancy`: Backup storage redundancy type. Allowed values: `GeoRedundant`, `LocallyRedundant`, `ZoneRedundant`.
- `cross_region_restore_enabled`: Enables cross-region restore. Can only be set to `true` when `redundancy = "GeoRedundant"`.
- `retention_duration_in_days`: Soft delete retention duration in days (`14` to `180`).
- `immutability`: Immutability state. Allowed values: `Disabled`, `Locked`, `Unlocked`.
- `soft_delete`: Soft delete state. Allowed values: `AlwaysOn`, `Off`, `On`.
- `identity`: Optional managed identity configuration object:
- `type`: Identity type. Allowed values: `SystemAssigned`, `UserAssigned`, `SystemAssigned, UserAssigned`.
- `identity_ids`: Optional list of user-assigned identity IDs (required when `type = "UserAssigned"`).
- `tags`: A map of tags to apply to the backup vault.
## Usage scenarios
- **Operational recovery**: Use Backup Vault to manage operational recovery workflows; exact datastore behavior is workload-specific. Example services/use cases: **AKS** (cluster state + PV snapshots), **Azure Blobs** (operational protection where data stays in the source account and backup policy also governs vaulted retention), and **Azure Files** (snapshot-based fast restore patterns).
- **Long-term retention**: Use `VaultStore` for policy-based offsite retention and stronger isolation from production data. Example services/use cases: **Azure Blobs**, **Azure Files (vaulted backup)**, **Azure Database for PostgreSQL**, and **AKS** (vault-tier retention rules).
- **Regional resiliency**: Use `VaultStore` with `redundancy = "GeoRedundant"` and `cross_region_restore_enabled = true` for paired-region restore scenarios. Example services/use cases: **AKS** and other vault-tier backup configurations where cross-region restore is supported.
- **Compliance and low-cost cold retention**: Use `ArchiveStore` where supported for long-term retention with lower storage cost and slower retrieval. Example services/use cases: **Azure VMs**, **SQL Server in Azure VMs**, and **SAP HANA in Azure VMs** (subject to archive eligibility rules).
> Compatibility differs by workload, region, and policy settings. Always confirm current support in the relevant Azure Backup support matrix before rollout.
## Datastore types (concise)
**OperationalStore** is the operational tier designed for faster recovery and short-to-medium retention windows. In Microsoft Learn examples (for example AKS), this tier keeps backup data within your tenant and is typically used for frequent restore points and day-to-day recovery operations.
**VaultStore** is the vault-standard tier for offsite, policy-driven retention in Backup vault storage. It is commonly used when you want stronger isolation from production resources, longer retention than operational snapshots, and optional cross-region restore when combined with geo-redundant vault settings.
**ArchiveStore** represents archive-style retention for infrequently accessed backup data and cost-optimized long-term preservation. Microsoft Learn notes that archive usage is workload-dependent and comes with constraints (such as eligibility and rehydration/restore behavior), so it is best suited for compliance-heavy scenarios rather than frequent restores.
**SnapshotStore** is a legacy/compatibility datastore value that appears in provider schemas and older patterns. For newer Azure Backup workflows, Microsoft guidance and examples more often emphasize `OperationalStore` and `VaultStore`, with `OperationalStore` generally preferred over snapshot-style behavior for active operational protection.
## References (Microsoft Learn)
- [Overview of Azure Blob backup](https://learn.microsoft.com/azure/backup/blob-backup-overview)
- [What is Azure Kubernetes Service backup?](https://learn.microsoft.com/azure/backup/azure-kubernetes-service-backup-overview#which-backup-storage-tier-does-aks-backup-support)
- [Overview of Archive tier in Azure Backup](https://learn.microsoft.com/azure/backup/archive-tier-support)
- [About Azure Files backup](https://learn.microsoft.com/azure/backup/azure-file-share-backup-overview)
## Outputs
- `backup_vault_id`: The ID of the created backup vault.
- `backup_vault_name`: The name of the created backup vault.
- `backup_vault_identity_principal_id`: Principal ID of the assigned managed identity, if configured.
- `backup_vault_identity_tenant_id`: Tenant ID of the assigned managed identity, if configured.
## Example Usage
```hcl
module "backup_vault" {
source = "./modules/backup-vault"
rg_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
base_name = "bv"
datastore_type = "VaultStore"
redundancy = "LocallyRedundant"
soft_delete = "On"
immutability = "Disabled"
retention_duration_in_days = 14
tags = {
environment = "dev"
}
}
```