ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/backup-recovery-strategies-ai-workloads.md

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  |
| Azure AI 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:

# 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:

# 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

# 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:

# 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:

# 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:

{
  "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

# 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

{
  "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

// 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

{
  "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
• Azure Blob operational backup
• Azure Storage redundancy
• Continuous backup with point-in-time restore in Azure Cosmos DB
• Azure Disk Backup overview
• Management recommendations for AI workloads on Azure infrastructure
• Azure security baseline for Azure AI Foundry - Backup and recovery
• 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.