ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/backup-recovery-strategies-ai-workloads.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +02:00

21 KiB

Backup and Recovery Strategies for AI Workloads

Last updated: 2026-06-24 Status: GA Category: Business Continuity & Disaster Recovery Type: reference Source: https://learn.microsoft.com/azure/backup/backup-overview


Innhold

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:

# 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

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.