# Backup and Recovery Strategies for AI Workloads

**Last updated:** 2026-02
**Status:** GA
**Category:** Business Continuity & Disaster Recovery

---

## Introduksjon

Backup- og gjenopprettingsstrategier for AI-arbeidsbelastninger skiller seg vesentlig fra tradisjonelle applikasjoner. En AI-loesning bestar ikke bare av applikasjonskode og databaser, men ogsaa av trenede modeller, datasett, fine-tuning-artefakter, embedding-indekser, agentdefinisjoner, samtalelogger og pipeline-konfigurasjoner. Hvert av disse elementene har ulike krav til backup-frekvens, retensjonstid og gjenopprettingsmetode. Et tap av treningsdata kan bety uker med tapt arbeid, mens et tap av embedding-indekser kan gjenopprettes ved reindeksering fra kildedata.

For norsk offentlig sektor er backup-strategien ogsaa underlagt regulatoriske krav. Arkivloven, Forvaltningsloven og GDPR stiller krav til datalagring, personvern og etterproevbarhet. AI-systemer som prosesserer personopplysninger ma ha backup-rutiner som baade ivaretar gjenopprettingsbehovet og dataminimeringsprinsippet -- man skal ikke oppbevare mer data enn noedvendig, men man ma kunne gjenopprette det som er paakrevd. Azure Backup, Azure Storage-redundans og tjenestespesifikke backup-mekanismer gir et robust verktoeysett for dette.

Denne referansen dekker inkrementell versus full backup, point-in-time recovery for datasett, snapshot-administrasjon og retensjonsregler, off-region backup-lagring, og automatisering og planlegging av backups. Fokus er pa Azure-tjenester som er relevante for AI-arbeidsbelastninger, med konkrete konfigurasjonseksempler og kostnadsoverveielser.

## Inkrementell versus full backup

### Backup-typer for AI-arbeidsbelastninger

| Backup-type | Beskrivelse | Fordeler | Ulemper | Best for |
|-------------|-------------|---------|---------|----------|
| **Full backup** | Komplett kopi av alle data | Enklest gjenoppretting | Stoerst lagringsbehov, lengst tid | Ukentlig baseline |
| **Inkrementell** | Kun endringer siden forrige backup | Minst lagring, raskest | Krever alle inkrementelle + siste fulle | Daglig / flere ganger daglig |
| **Differensiell** | Endringer siden siste fulle backup | Raskere gjenoppretting enn inkrementell | Stoerre enn inkrementell | Daglig supplement til ukentlig full |
| **Continuous** | Lopende replikering av endringer | Lavest RPO (naer sanntid) | Hoeyest kostnad | Virksomhetskritiske data |

### Anbefalt backup-strategi per AI-komponent

| Komponent | Backup-type | Frekvens | Begrunnelse |
|-----------|------------|----------|-------------|
| **Azure OpenAI konfig** | IaC (Git) | Ved endring | Stateless tjeneste, konfig er alt |
| **Cosmos DB (agentdata)** | Continuous | Lopende | Forretningskritisk tilstandsdata |
| **Azure Storage (datasett)** | Inkrementell | Daglig | Store datamengder, lavt endringsvolum |
| **Azure SQL (strukturerte data)** | Full + diff | Full ukentlig, diff daglig | Relasjonelle data med transaksjonslogg |
| **Azure AI Search indekser** | Ingen backup* | Ved behov | Gjenskap fra kildedata |
| **Fine-tuned modellvekter** | Full | Ved ny versjon | Ikke inkrementelt mulig |
| **Treningsdata** | Inkrementell + versjonering | Daglig | Storrelse og endringshastighet |
| **System-prompter** | Git | Ved endring | Tekst, versjonskontroll er nok |
| **Evalueringsresultater** | Full | Etter hver evaluering | Relativt sma data |

> *Azure AI Search-indekser kan ikke backes opp direkte. Gjenopprett ved reindeksering fra originale kildedata i Azure Storage eller Cosmos DB.

### Azure Backup for AI-relaterte ressurser

Azure Backup stoetter foelgende ressurser relevant for AI-arbeidsbelastninger:

```
+------------------------------------------+------------------+------------------+
| Ressurs                                  | Azure Backup     | Nativ backup     |
+------------------------------------------+------------------+------------------+
| Azure Virtual Machines (GPU/compute)     | Ja               | Nei              |
| Azure Managed Disks                      | Ja               | Snapshots        |
| Azure Files (SMB/NFS)                    | Ja               | Snapshots        |
| Azure Blob Storage                       | Ja (operational)  | Versjonering     |
| Azure SQL Database                       | Ja               | Auto-backup      |
| Azure Database for PostgreSQL            | Ja               | Auto-backup      |
| Azure Cosmos DB                          | Nei*             | Continuous/PITR  |
| Microsoft Foundry                         | Nei              | Nei              |
| Azure AI Search                          | Nei              | Nei              |
+------------------------------------------+------------------+------------------+
```

> *Cosmos DB har sin egen continuous backup-mekanisme og bruker ikke Azure Backup.

## Point-in-time Recovery for datasett

### Azure Blob Storage -- Versjonering og Soft Delete

For datasett lagret i Azure Blob Storage er versjonering og soft delete de viktigste mekanismene for point-in-time recovery:

```bash
# Aktiver blob-versjonering pa storage account
az storage account blob-service-properties update \
  --account-name svvaistorage \
  --resource-group rg-ai-prod \
  --enable-versioning true

# Aktiver soft delete for blobs (30 dagers retensjonstid)
az storage account blob-service-properties update \
  --account-name svvaistorage \
  --resource-group rg-ai-prod \
  --delete-retention-days 30 \
  --enable-delete-retention true

# Aktiver soft delete for containere
az storage account blob-service-properties update \
  --account-name svvaistorage \
  --resource-group rg-ai-prod \
  --container-delete-retention-days 30 \
  --enable-container-delete-retention true
```

### Azure Blob -- Operational Backup med Azure Backup

Operational backup for Azure Blobs gir point-in-time restore:

```bash
# Opprett backup vault
az dataprotection backup-vault create \
  --vault-name ddt-ai-backup-vault \
  --resource-group rg-ai-prod \
  --location norwayeast \
  --type SystemAssigned \
  --storage-setting "DataStoreType=VaultStore;Type=LocallyRedundant"

# Opprett backup-policy for blobs (30 dagers retensjon)
az dataprotection backup-policy create \
  --vault-name ddt-ai-backup-vault \
  --resource-group rg-ai-prod \
  --name blob-backup-policy-30d \
  --policy '{
    "policyRules": [{
      "name": "Default",
      "objectType": "AzureRetentionRule",
      "lifecycles": [{
        "deleteAfter": {
          "objectType": "AbsoluteDeleteOption",
          "duration": "P30D"
        },
        "sourceDataStore": {
          "objectType": "DataStoreInfoBase",
          "dataStoreType": "OperationalStore"
        }
      }],
      "isDefault": true
    }],
    "datasourceTypes": ["Microsoft.Storage/storageAccounts/blobServices"]
  }'
```

### Cosmos DB -- Continuous Backup med PITR

Cosmos DB tilbyr to nivaaer av continuous backup:

| Egenskap | Continuous 7-day | Continuous 30-day |
|----------|-----------------|-------------------|
| Retensjonsperiode | 7 dager | 30 dager |
| Backup-lagringskostnad | Gratis | $0.20/GB * antall regioner |
| Restore-kostnad | $0.15/GB | $0.15/GB |
| Granularitet | Vilkaarlig tidspunkt innenfor retensjon | Vilkaarlig tidspunkt innenfor retensjon |
| Restore-mal | Ny konto eller eksisterende konto | Ny konto eller eksisterende konto |

```bash
# Gjenopprett Cosmos DB til et bestemt tidspunkt
az cosmosdb restore \
  --account-name ddt-ai-cosmos-prod \
  --resource-group rg-ai-prod \
  --target-database-account-name ddt-ai-cosmos-restored \
  --restore-timestamp "2026-02-10T14:30:00Z" \
  --location norwayeast
```

> **Viktig:** Ved gjenoppretting opprettes alltid en ny konto. Foelgende konfigurasjoner gjenopprettes IKKE automatisk og ma rekonfigureres: brannmurregler, VNet-innstillinger, RBAC-tildelinger, private endpoints, lagrede prosedyrer, triggere og UDF-er.

### Azure SQL Database -- Point-in-time Restore

For AI-loesninger som bruker Azure SQL for strukturerte data:

```bash
# Gjenopprett Azure SQL til et bestemt tidspunkt
az sql db restore \
  --resource-group rg-ai-prod \
  --server ddt-ai-sqlserver \
  --name ai-metadata-db \
  --dest-name ai-metadata-db-restored \
  --time "2026-02-10T14:30:00Z"
```

| Retensjonsperiode | Standard | Konfigurerbar |
|-------------------|----------|---------------|
| Korttidsretensjon (PITR) | 7 dager | 1-35 dager |
| Langtidsretensjon (LTR) | Ikke aktivert | Opptil 10 aar |

## Snapshot-administrasjon og retensjon

### Snapshot-strategi for AI-infrastruktur

Snapshots er raske, kostnadseffektive kopier av data pa et bestemt tidspunkt. For AI-arbeidsbelastninger er de spesielt nyttige for VM-baserte compute-noder og managed disks.

| Ressurs | Snapshot-type | Maks snapshots | Anbefalt retensjon |
|---------|--------------|----------------|-------------------|
| Azure Managed Disks | Inkrementell | 500 per disk | 30-90 dager |
| Azure Files | Share snapshot | 200 per share | 30 dager |
| Azure Blob | Blob versjon | Ubegrenset* | 30-365 dager |
| VM (via Azure Backup) | App-consistent | Avhenger av policy | 30-90 dager |

> *Ubegrenset antall versjoner, men lagringskostnader oeker. Bruk lifecycle management for a haandtere retensjon.

### Azure Managed Disk Backup

For GPU-VM-er og compute-intensive AI-arbeidsbelastninger:

```bash
# Opprett backup-policy for managed disks
# Daglig backup med 30 dagers retensjon
az dataprotection backup-policy create \
  --vault-name ddt-ai-backup-vault \
  --resource-group rg-ai-prod \
  --name disk-backup-daily-30d \
  --policy '{
    "policyRules": [
      {
        "name": "BackupDaily",
        "objectType": "AzureBackupRule",
        "trigger": {
          "objectType": "ScheduleBasedTriggerContext",
          "schedule": {
            "repeatingTimeIntervals": ["R/2026-01-01T02:00:00+00:00/P1D"]
          }
        },
        "dataStore": {
          "objectType": "DataStoreInfoBase",
          "dataStoreType": "OperationalStore"
        }
      },
      {
        "name": "Default",
        "objectType": "AzureRetentionRule",
        "lifecycles": [{
          "deleteAfter": {
            "objectType": "AbsoluteDeleteOption",
            "duration": "P30D"
          },
          "sourceDataStore": {
            "objectType": "DataStoreInfoBase",
            "dataStoreType": "OperationalStore"
          }
        }],
        "isDefault": true
      }
    ],
    "datasourceTypes": ["Microsoft.Compute/disks"]
  }'
```

> **Merk:** Azure Disk Backup bruker inkrementelle snapshots som er begrenset til 500 per disk. Med daglig backup betyr dette maks ~450 dagers retensjon (50 reservert for on-demand backups).

### Lifecycle Management for Azure Blob Storage

Automatisk haandtering av eldre datasett og backup-data:

```json
{
  "rules": [
    {
      "name": "dataset-lifecycle",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["datasets/", "training-data/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            },
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          },
          "snapshot": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 30
            },
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 30
            },
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}
```

## Off-region backup-lagring

### Azure Storage-redundans for backup

| Redundanstype | Regioner | Tilgjengelighet | Kostnad (relativ) | Anbefaling |
|---------------|---------|-----------------|-------------------|------------|
| **LRS** | 1 region, 3 kopier | 99.999999999% (11 niere) | 1x | Kun utvikling |
| **ZRS** | 1 region, 3 soner | 99.9999999999% (12 niere) | ~1.25x | Produksjon uten DR |
| **GRS** | 2 regioner, 6 kopier | 99.99999999999999% (16 niere) | ~2x | Standard DR |
| **GZRS** | 2 regioner, 6 kopier (3 soner + 3) | Hoeyest | ~2.5x | **Anbefalt for AI prod** |
| **RA-GRS/RA-GZRS** | Som GRS/GZRS + lesetilgang | Hoeyest + lestilgang | ~2.5-3x | Lese-intensiv DR |

### Konfigurering av geo-redundant backup

```bash
# Opprett Recovery Services vault med GRS for VM-backup
az backup vault create \
  --name ddt-ai-recovery-vault \
  --resource-group rg-ai-prod \
  --location norwayeast

# Sett storage-redundans til geo-redundant
az backup vault backup-properties set \
  --name ddt-ai-recovery-vault \
  --resource-group rg-ai-prod \
  --backup-storage-redundancy GeoRedundant

# Aktiver Cross Region Restore
az backup vault backup-properties set \
  --name ddt-ai-recovery-vault \
  --resource-group rg-ai-prod \
  --cross-region-restore-flag Enabled
```

### Off-region backup-arkitektur for AI-data

```
Norway East (primaer)                    Sweden Central (sekundaer)
+---------------------------+            +---------------------------+
|  AI Foundry Project       |            |  (Replikert data)         |
|  +---------------------+ |  async     |  +---------------------+ |
|  | Storage (GZRS)      |------copy--->|  | Storage (read)      | |
|  +---------------------+ |            |  +---------------------+ |
|  +---------------------+ |  auto      |  +---------------------+ |
|  | Cosmos DB            |---failover->|  | Cosmos DB (replica)  | |
|  +---------------------+ |            |  +---------------------+ |
|  +---------------------+ |  geo-rep   |  +---------------------+ |
|  | Container Registry  |------copy--->|  | Container Registry   | |
|  +---------------------+ |            |  +---------------------+ |
|  +---------------------+ |  auto      |  +---------------------+ |
|  | Key Vault            |---failover->|  | Key Vault (replica)  | |
|  +---------------------+ |            |  +---------------------+ |
+---------------------------+            +---------------------------+
```

### Datasuverenitetshensyn

For norsk offentlig sektor er det viktig at off-region backup forblir innenfor EU/EOeS:

| Primaer region | Anbefalt sekundaer | Paringstype | Datasuverenitet |
|----------------|-------------------|-------------|-----------------|
| Norway East | Norway West* | Paret region | Norge |
| Norway East | Sweden Central | Manuell | EU/EOeS |
| Sweden Central | Norway East | Manuell | EU/EOeS |

> *Norway West har begrenset tjenestestotte. Bruk Sweden Central som alternativ sekundaer region.

## Automatisering og planlegging av backups

### Azure Policy for automatisk backup

```json
{
  "type": "Microsoft.Authorization/policyAssignments",
  "properties": {
    "displayName": "Automatisk backup for AI VM-er",
    "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/013e242c-8828-4970-87b3-ab247555486d",
    "parameters": {
      "vaultLocation": { "value": "norwayeast" },
      "backupPolicyId": {
        "value": "/subscriptions/{sub}/resourceGroups/rg-ai-prod/providers/Microsoft.RecoveryServices/vaults/ddt-ai-recovery-vault/backupPolicies/DefaultPolicy"
      }
    }
  }
}
```

### Backup-planlegging for AI-arbeidsbelastninger

| Komponent | Planlagt tid | Frekvens | Vindu | Automatisert |
|-----------|-------------|----------|-------|-------------|
| VM-snapshots (GPU) | 02:00 UTC | Daglig | 2 timer | Azure Backup Policy |
| Blob Storage operational | Kontinuerlig | Lopende | N/A | Azure Backup |
| Cosmos DB | Kontinuerlig | Lopende | N/A | Nativ (innebygd) |
| Azure SQL | 00:00 UTC (full) | Full ukentlig, diff daglig | 4 timer | Automatisk |
| Azure Files | 03:00 UTC | Daglig | 1 time | Azure Backup Policy |
| IaC + kode (Git) | Ved push | Hendelsesbasert | N/A | Git + pipeline |
| Modelleksport | Etter deploy | Ved ny versjon | 1 time | CI/CD pipeline |

### Automatisert backup-overvaking

```kusto
// KQL-query for Azure Monitor -- Sjekk backup-status for siste 24 timer
AzureDiagnostics
| where Category == "AzureBackupReport"
| where TimeGenerated > ago(24h)
| where OperationName == "Job"
| summarize
    SuccessCount = countif(ResultType == "Succeeded"),
    FailedCount = countif(ResultType == "Failed"),
    InProgressCount = countif(ResultType == "InProgress")
| extend HealthStatus = iff(FailedCount > 0, "UNHEALTHY", "HEALTHY")
```

### Varsling ved backup-feil

```json
{
  "type": "Microsoft.Insights/scheduledQueryRules",
  "properties": {
    "displayName": "AI Backup Failure Alert",
    "description": "Varsler ved feil i backup for AI-arbeidsbelastninger",
    "severity": 1,
    "enabled": true,
    "evaluationFrequency": "PT1H",
    "windowSize": "PT1H",
    "criteria": {
      "allOf": [{
        "query": "AzureDiagnostics | where Category == 'AzureBackupReport' | where OperationName == 'Job' | where ResultType == 'Failed' | where TimeGenerated > ago(1h)",
        "threshold": 0,
        "operator": "GreaterThan",
        "timeAggregation": "Count"
      }]
    },
    "actions": {
      "actionGroups": ["/subscriptions/{sub}/resourceGroups/rg-ai-prod/providers/Microsoft.Insights/actionGroups/ai-ops-team"]
    }
  }
}
```

## Kostnadsstyring for backup

### Estimert backup-kostnad per komponent

| Komponent | Datavolum | Backup-type | Estimert kostnad (NOK/maned) |
|-----------|-----------|------------|------------------------------|
| Cosmos DB (30-day continuous) | 50 GB, 2 regioner | Continuous | ~210 |
| Azure Blob (operational) | 500 GB | PITR | ~250 |
| Azure Managed Disk | 1 TB (GPU VM) | Daglig snapshot | ~400 |
| Azure SQL (PITR + LTR) | 100 GB | Auto + LTR | ~150 |
| Azure Files | 200 GB | Daglig snapshot | ~100 |
| Recovery Services vault | N/A | GRS | ~80 |
| **Totalt estimat** | | | **~1 190** |

> **Tips:** Bruk Azure Cost Management for a overvake faktiske backup-kostnader. Sett budsjettvarslinger for a unnga overraskelser.

## Sjekkliste for backup-strategi

- [ ] Kartlegg alle AI-komponenter og deres backup-behov
- [ ] Definer RPO for hver komponent basert pa forretningskritikalitet
- [ ] Aktiver Cosmos DB continuous backup med PITR
- [ ] Konfigurer Azure Blob Storage med versjonering og soft delete
- [ ] Sett opp Azure Backup for VM-er og managed disks
- [ ] Implementer lifecycle management for kostnadsoptimalisering
- [ ] Konfigurer geo-redundant lagring (GZRS) for produksjonsdata
- [ ] Automatiser backup gjennom Azure Policy
- [ ] Sett opp overvaking og varsling for backup-feil
- [ ] Dokumenter og test gjenopprettingsprosedyrer kvartalsvis
- [ ] Verifiser at backup-strategi er i samsvar med regulatoriske krav

## Referanser

- [Azure Backup Overview](https://learn.microsoft.com/en-us/azure/backup/backup-overview)
- [Azure Blob operational backup](https://learn.microsoft.com/en-us/azure/backup/blob-backup-overview)
- [Azure Storage redundancy](https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy)
- [Continuous backup with point-in-time restore in Azure Cosmos DB](https://learn.microsoft.com/en-us/azure/cosmos-db/continuous-backup-restore-introduction)
- [Azure Disk Backup overview](https://learn.microsoft.com/en-us/azure/backup/disk-backup-overview)
- [Management recommendations for AI workloads on Azure infrastructure](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/infrastructure/management)
- [Azure security baseline for Microsoft Foundry - Backup and recovery](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline#backup-and-recovery)
- [Manage AI business continuity](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/manage#manage-ai-business-continuity)

## For Cosmo

- **Bruk denne referansen** nar kunden trenger en helhetlig backup-strategi for AI-arbeidsbelastninger -- fra datasett og modeller til infrastruktur og agentdata.
- **Start med a kartlegge komponentene** -- mange kunder tenker bare pa "backup av modellen" men glemmer Cosmos DB, AI Search-indekser, og pipeline-konfigurasjoner som ogsaa er kritiske.
- **Anbefal Cosmos DB Continuous 30-day** for agentdata og Azure Blob GZRS for datasett som standardkonfigurasjon for norsk offentlig sektor.
- **Bruk kostnadstabellene** for a vise at backup for AI-arbeidsbelastninger er relativt rimelig sammenlignet med konsekvensene av datatap -- dette hjelper med a bygge business case.
- **Paapek regulatoriske krav** -- Arkivloven og Forvaltningsloven kan kreve lengre retensjon enn teknisk noedvendig, og dette ma fanges opp tidlig i planleggingen.