Problema

Al intentar restaurar una máquina virtual o un disco desde un Azure Backup Vault, el proceso falla porque Azure exige que el destino de la restauración sea una cuenta de almacenamiento ubicada en la misma región que el vault. Además, la documentación oficial menciona que Blob storage no está soportado, lo que deja a los administradores preguntándose qué tipo de cuenta usar y qué configuraciones son aceptables (LRS, ZRS, Standard vs Premium, etc.). El problema se manifiesta con mensajes de error que indican incompatibilidad de la cuenta de almacenamiento o ausencia de una cuenta válida en la región requerida.

Este patrón se repite en entornos donde:

  • Se usan Recovery Services vaults para respaldos de máquinas virtuales (IaaS) o bases de datos.
  • Se necesita validar la restauración antes de una migración o de una recuperación de desastres.
  • Se intenta crear la cuenta de almacenamiento “sobre la marcha” sin conocer las limitaciones de tipo y redundancia.

El síntoma típico es la imposibilidad de iniciar la restauración o la aparición de un mensaje que sugiere crear una cuenta de Azure Files en la misma ubicación.

Causa

  1. Restricción de tipo de almacenamiento
    Azure Backup solo acepta Azure Files (File storage) como destino de restauración porque el proceso necesita un punto de montaje SMB que permita la copia de discos VHD de forma segura. Los contenedores de Blob no proveen la interfaz requerida.

  2. Ubicación geográfica obligatoria
    La cuenta de almacenamiento debe residir en la misma región que el vault. Esto garantiza latencias mínimas y cumplimiento de los requisitos de replicación interna del servicio de backup.

  3. Configuración de redundancia y rendimiento

    • LRS (Locally Redundant Storage) es suficiente para la mayoría de los escenarios de prueba y restauración puntual.
    • Standard performance cubre la velocidad de I/O requerida para la copia de VHDs; Premium Files solo es necesario cuando se restauran volúmenes extremadamente grandes o se necesita alta concurrencia.

  4. Políticas de red y firewalls
    Si la cuenta de Azure Files está restringida a redes específicas o tiene reglas de firewall que bloquean el acceso desde el servicio de backup, la restauración también fallará.

Solución

Paso 1: Seleccionar el tipo correcto de cuenta

Crea una cuenta de StorageV2 (General purpose v2) con el sku Standard_LRS y habilita el File service. No habilites la opción “Blob storage only”.

Paso 2: Ubicación

Asegúrate de que la región (location) coincida exactamente con la del Recovery Services vault. Puedes verificar la región del vault con:

az backup vault show --name MyVault --resource-group MyRG --query location -o tsv

Paso 3: Crear la cuenta y el share

Usa Azure CLI (o PowerShell) para crear la cuenta y un share que será usado como destino de restauración.

az storage account create \
  --name mystorageacct \
  --resource-group MyRG \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2

az storage share create \
  --account-name mystorageacct \
  --name restore-share

Paso 4: Conceder permisos al vault

Azure Backup necesita permiso de Contributor o Storage Blob Data Contributor sobre la cuenta. La forma más sencilla es asignar el rol a la identidad administrada del vault:

az role assignment create \
  --assignee <vault-principal-id> \
  --role "Storage Blob Data Contributor" \
  --scope $(az storage account show -n mystorageacct -g MyRG --query id -o tsv)

Reemplaza <vault-principal-id> con el identity.principalId del vault, que puedes obtener con:

az backup vault show --name MyVault --resource-group MyRG --query identity.principalId -o tsv

Paso 5: Iniciar la restauración

En el portal o mediante CLI, selecciona el backup que deseas restaurar y especifica la cuenta y el share creados. La CLI para restaurar una VM sería:

az backup restore restore-disks \
  --resource-group MyRG \
  --vault-name MyVault \
  --container-name IaasVMContainer;iaasvmcontainerv2;myRG;myVM \
  --item-name myVM \
  --storage-account mystorageacct \
  --target-resource-group MyRG \
  --target-disk-name-prefix restored-

Paso 6: Verificar la copia

Una vez completada la operación, verifica que los discos VHD aparecen en el share y que puedes montar el share desde una VM de prueba:

mount -t cifs //mystorageacct.file.core.windows.net/restore-share /mnt/restore -o vers=3.0,username=mystorageacct,password=<account-key>,dir_mode=0777,file_mode=0777

Cuándo aplicar esta solución

  • Restauraciones de pruebas: Cuando solo necesitas validar que los backups son recuperables.
  • Recuperación de desastres parcial: Si la restauración se realiza en la misma región del vault.
  • Entornos de desarrollo: Donde el costo de Premium Files no está justificado.
  • No aplica:
    • Cuando la política de la empresa exige que los datos se restauren en una región distinta (en ese caso se necesita Azure Site Recovery o copiar los VHD a otra región antes de la restauración).
    • Cuando se requiere restaurar directamente a un disco administrado sin pasar por Azure Files (solo disponible en algunos tipos de backup, como Azure Disk Backup).

Código

# 1. Verificar región del vault
az backup vault show --name MyVault --resource-group MyRG --query location -o tsv

# 2. Crear cuenta de almacenamiento y share
az storage account create \
  --name mystorageacct \
  --resource-group MyRG \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2

az storage share create \
  --account-name mystorageacct \
  --name restore-share

# 3. Asignar rol al vault
VAULT_ID=$(az backup vault show --name MyVault --resource-group MyRG --query identity.principalId -o tsv)
STORAGE_ID=$(az storage account show -n mystorageacct -g MyRG --query id -o tsv)

az role assignment create \
  --assignee $VAULT_ID \
  --role "Storage Blob Data Contributor" \
  --scope $STORAGE_ID

# 4. Iniciar restauración de discos
az backup restore restore-disks \
  --resource-group MyRG \
  --vault-name MyVault \
  --container-name IaasVMContainer;iaasvmcontainerv2;myRG;myVM \
  --item-name myVM \
  --storage-account mystorageacct \
  --target-resource-group MyRG \
  --target-disk-name-prefix restored-

Verificación

  1. Estado de la operación:

    az backup job show --name <job-id> --resource-group MyRG --vault-name MyVault --query status -o tsv

    Debe devolver Completed.

  2. Presencia del VHD:
    Accede al share con Azure Storage Explorer o mediante el comando az storage file list para confirmar que los archivos .vhd están presentes.

  3. Montaje de prueba:
    Monta el share en una VM de prueba y verifica que el VHD se puede leer con lsblk o fdisk -l.

  4. Creación de disco a partir del VHD:

    az disk create \
  --resource-group MyRG \
  --name restoredDisk \
  --source https://mystorageacct.file.core.windows.net/restore-share/<vhd-name>.vhd \
  --os-type Linux

    Si el disco se crea sin errores, la restauración fue exitosa.

Notas adicionales

  • Límites de tamaño: Azure Files tiene un límite de 5 TiB por archivo en Standard tier. Si tus VHD superan ese tamaño, considera usar Premium Files o dividir el backup en varios discos más pequeños.
  • Redes híbridas: Si tu vault está configurado con red privada (Private Endpoint), la cuenta de Files también debe tener un Private Endpoint en la misma VNet para evitar bloqueos de firewall.
  • Política de retención: Asegúrate de que la política de retención del vault no haya expirado el punto de restauración que intentas usar; de lo contrario, la operación no aparecerá como disponible.
  • Costos: LRS Standard es la opción más económica. Si habilitas la replicación ZRS o Premium, revisa el impacto en la factura, especialmente en entornos de pruebas frecuentes.