Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
492 lines
21 KiB
Markdown
492 lines
21 KiB
Markdown
# 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](#introduksjon)
|
|
- [Inkrementell versus full backup](#inkrementell-versus-full-backup)
|
|
- [Point-in-time Recovery for datasett](#point-in-time-recovery-for-datasett)
|
|
- [Snapshot-administrasjon og retensjon](#snapshot-administrasjon-og-retensjon)
|
|
- [Off-region backup-lagring](#off-region-backup-lagring)
|
|
- [Automatisering og planlegging av backups](#automatisering-og-planlegging-av-backups)
|
|
- [Kostnadsstyring for backup](#kostnadsstyring-for-backup)
|
|
- [Sjekkliste for backup-strategi](#sjekkliste-for-backup-strategi)
|
|
- [Referanser](#referanser)
|
|
- [For arkitekten](#for-arkitekten)
|
|
|
|
## 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 arkitekten
|
|
|
|
- **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.
|