File Share Backup

Overview

Azure File Share Backup protects Azure Files shares (hosted in a Storage Account) using snapshot-based or vault-tier recovery points. Unlike VM backup, file-share backup is wired through the Storage Account entry rather than a separate VM-level binding: the Storage Account points at a vault, and each share opts in by naming a policy.

Module Structure

Module	Azure Resource	Purpose
backup_policy_file_share	azurerm_backup_policy_file_share	Schedule + retention for file shares; nested under a Recovery Services Vault
backup_container_storage_account	azurerm_backup_container_storage_account	Registers a Storage Account as a backup container in the vault
backup_protected_file_share	azurerm_backup_protected_file_share	Binds a specific share to a file-share policy

The two protection modules (backup_container_storage_account, backup_protected_file_share) read directly from the storage_accounts root variable — there are no separate top-level variables for them.

Architecture

1. Recovery Services Vault owns file-share policies — see Backup Overview.
2. File-share policies are declared inside a vault under backup_policy_file_share = { ... }.
3. Storage Account opts in by setting backupvault = "<vault_key>" — this triggers the backup_container_storage_account registration.
4. Each share opts in by setting backuppolicy = "<policy_key>" on the share entry — this is a bare policy key (no <vault>. prefix), because the vault is already pinned at the SA level.
5. Container registration is all-or-nothing per SA: if any share has backuppolicy set, the container resource is created. SAs with no protected shares don't register.

This wiring shape differs from VM backup (VM Backup) in two important ways: - The vault reference lives on the Storage Account, not on each share. - Share-level backuppolicy is a bare key, not a composite <vault>.<policy> — the module synthesizes the composite as "${sa.backupvault}.${share.backuppolicy}" internally.

Usage

1. Declare a File Share Policy Under a Vault

recovery_services_vault = {
  epic = {
    resource_group    = "recoveryvault"
    storage_mode_type = "GeoRedundant"

    backup_policy_file_share = {
      daily = {}                          # uses defaults: Daily 02:00, 15-day retention

      hourlyVault = {
        backup_tier = "vault-standard"
        backup = {
          frequency = "Hourly"
          hourly = {
            interval        = 4
            start_time      = "08:00"
            window_duration = 12
          }
        }
        snapshot_retention_in_days = 7
        retention_daily = {
          count = "30"
        }
      }
    }
  }
}

The policy key (daily, hourlyVault) is what individual shares will name in step 3.

Note: Hourly schedules require backup_tier = "vault-standard". The snapshot tier supports only daily frequency.

2. Point a Storage Account at the Vault

Set backupvault on the Storage Account entry to the vault key:

storage_accounts = {
  appdata = {
    resource_group              = "hsw"
    public_network_access_enabled = true
    backupvault                 = "epic"
    shares = {
      data = {
        quota        = "100"
        backuppolicy = "daily"
      }
      logs = {
        quota        = "50"
        backuppolicy = "hourlyVault"
      }
      scratch = {
        quota = "20"
        # no backuppolicy — share is not protected
      }
    }
  }
}

The Storage Account registers as a backup container only if at least one share has backuppolicy set. Shares without backuppolicy are left unprotected; this is the right shape for scratch/tempdata shares that don't need recovery points.

3. Composite Key Resolution (Internal)

The module composes the policy reference internally:

backup_policy_id = var.mod_backup_policy_file_share["${sa.backupvault}.${share.backuppolicy}"].id

So backupvault = "epic" + backuppolicy = "daily" resolves to the "epic.daily" policy. If you rename the vault key or the policy key, every share that references it will rewire — and because azurerm_backup_protected_file_share cannot have its backup_policy_id modified in place, this is a destroy + recreate on the protection resource. Treat both keys as load-bearing.

Variable Reference

backup_policy_file_share (nested under recovery_services_vault.<vault_key>)

Field	Type	Description	Default
name	string	Override the resource name	Prefix + key + suffix
timezone	string	Windows-style timezone	Root var.timezone, else "UTC"
backup_tier	string	"vault-standard" (long-term, vaulted) or "snapshot" (legacy, snapshot-only)	"vault-standard"
snapshot_retention_in_days	number	Operational snapshot retention	14
backup	object	Schedule (see below)	{} (Daily at 02:00)
retention_daily	object	{ count }	{ count = "15" }
retention_weekly	object	{ count, weekdays }	{ count = "4", weekdays = ["Sunday"] }
retention_monthly	object	Monthly retention	{} (disabled)
retention_yearly	object	Yearly retention	{} (disabled)

backup (schedule)

Field	Type	Description	Default
frequency	string	"Daily" or "Hourly" (requires vault-standard tier)	"Daily"
time	string	"HH:MM" daily start time	"02:00"
hourly	object	Required when frequency = "Hourly"; see below	null

backup.hourly

Field	Type	Description	Default
interval	number	Hours between backups (e.g. 4 for every 4h)	null
start_time	string	"HH:MM" of the first backup in the window	null
window_duration	number	Total hours the hourly window covers	null

retention_monthly / retention_yearly

Same absolute/relative shape as backup_policy_vm — use either days (absolute) or weekdays + weeks (relative), not both. retention_yearly also takes months to scope which months emit yearly retention points.

Field	Type	Description	Default
count	string	Periods to retain — omit to disable the block	null
weekdays	list(string)	Relative form: weekday names	null
weeks	list(string)	Relative form: "First"–"Fourth", "Last"	null
days	list(string)	Absolute form: day-of-month ("1"–"28")	null
include_last_days	string	Absolute form: include the last day of months that don't reach the listed day	"false"
months	list(string)	retention_yearly only — months to retain	null

Storage Account fields (on storage_accounts.<sa_key>)

Field	Type	Description	Default
backupvault	string	recovery_services_vault key — registers the SA as a backup container	null (not registered)

Share fields (on storage_accounts.<sa_key>.shares.<share_key>)

Field	Type	Description	Default
backuppolicy	string	backup_policy_file_share key (bare, not composite)	null (not protected)

Naming Convention

File-share policies use the backup_policy_file_share prefix/suffix slot:

name_prefixes = {
  backup_policy_file_share = "prod-"
}

name_suffixes = {
  backup_policy_file_share = "-eastus2-bpol-fs"
}

Policy key daily → prod-daily-eastus2-bpol-fs.

Set name on the policy entry to bypass prefix/suffix composition entirely.

Backup policy names allow letters, numbers, and hyphens only. Periods are rejected by the Backup API even though the error message is misleading — keep them out of both the prefix/suffix and the policy key.

The container (backup_container_storage_account) and protected file share (backup_protected_file_share) resources are not named by the user — Azure derives those names from the SA and share names.

Related

• Backup Overview — Recovery Services Vault, diagnostic settings
• VM Backup — VM-level backup wiring (different shape: vault at the VM level, composite policy keys)