Backup og data-export

← Tenant Owner-manual

6. Backup og data-export

Backup er din safety net. Hvis en page bliver ved et uheld slettet, et theme-ændring fucker layout op, eller en migration går galt — så er det en backup-ZIP der får jer tilbage i drift. TesseraCMS har et fuld backup/restore-system bygget ind (TASK-122/155/156).

Hvad er i en backup

En backup-ZIP indeholder en komplet snapshot af jeres tenant:

tenant-{slug}-{timestamp}.zip
├─ manifest.json                # metadata: version, schemaVersion, counts
├─ tables/                       # alle content-tables som JSON
│   ├─ Tenants/                  # tenant-row
│   ├─ ContentItems/Page/        # alle pages
│   ├─ ContentItems/Hero/        # alle hero-records
│   ├─ ContentItems/Form/        # alle formularer
│   ├─ TenantModules/            # modul-konfig
│   ├─ TenantRoles/              # rolle-tildelinger
│   ├─ Counters/                 # sequential ID-tællere
│   └─ ... (alle andre per-tenant-tabeller)
└─ blobs/                        # alle uploadede billeder/dokumenter
    ├─ Hero/.../foo.jpg
    ├─ Page/.../bar.png
    └─ ...

Hvad er NIKKE med

  • Form-submissions fra besøgende (i v1; planlagt til v2)
  • Audit-log over rolle-ændringer (lever separat)
  • AAD-brugere (bor i Microsoft, ikke i vores storage)
  • Theme-overrides der ligger uden for TenantModules-config (sjælden situation)

Hvordan trigger man en backup

Backup-UI'en er Platform-Admin-only (/admin/backups). Du som Owner kan ikke selv trigger backup — du bedst Platform Admin om at gøre det. Workflow:

  1. Kontakt Platform Admin (os) med tenant-navnet
  2. Vi går til /admin/backups → finder tenanten → klikker Download ZIP
  3. Backup-genereringen tager 5-60 sekunder afhængigt af tenantens størrelse
  4. ZIP downloades til vores computer
  5. Vi sender den til jer via sikker kanal (email-link, SharePoint, Drive osv.)

Vi anbefaler at tage backup:

  • Før store content-ændringer — fx omfattende re-org af navigation eller mass-import
  • Før vi flytter jer mellem subscriptions — restore-flow understøtter cross-subscription
  • Periodisk — selvom der ikke er specifikke planer; uger eller måneder mellem hver gang er fint

Schema-version og migrations

Manifest indeholder en schemaVersion-felt der trackes jeres backup's data-model-version:

{
  "version": "1.0",
  "schemaVersion": 1,
  "appCommit": "06e3de9",
  ...
}

Når vi udvikler TesseraCMS og laver brydende ændringer (sjældent), bumper vi SCHEMA_VERSION-konstanten. Restore-flowet køre derefter migration-chain'en for at opdatere gammel backup-data til ny data-model.

Det betyder:

  • Backup-ZIP er forward-compatible — selv backups taget for et halvt år siden kan restores i nyere versioner
  • Du behøver ikke bekymre dig om at "opdatere" backups — opdateringen sker ved restore-tidspunktet

Restore-flow

Restore er også Platform-Admin-styret. Step-by-step:

  1. Backup ZIP-fil er klar (downloaded eller uploaded af jer)
  2. Platform Admin går til /admin/backups → Restore from backup-sektionen
  3. Vælg ZIP-filen via file-picker
  4. Target tenant-slug — kan være:
    • Samme som original — overskriver eksisterende tenant (disaster recovery)
    • Ny slug — opretter en kopi (test, fork, eller cross-subscription migration)
  5. Validate først — viser preview af manifest + counts + pre-flight-check
  6. Restore now — kører den faktiske restore (60 sek - flere min afhængig af størrelse)
  7. Target-tenanten oprettes med status: draft (uanset original status)
  8. Custom domains ryddes (du tilføjer dem manuelt igen hvis det er disaster recovery)
  9. Når restore er færdig, aktiverer Platform Admin tenanten

Cross-subscription migration

Hvis I vil flytte jeres tenant til en helt anden Azure-subscription (fx fra vores prod-environment til jeres egen), kan backup/restore håndtere det:

  1. Vi tager backup af jeres tenant
  2. Vi spinner et fresh TesseraCMS-deployment op i jeres nye subscription
  3. Vi restorer backup'en på det nye deployment
  4. Vi pegede DNS over
  5. Sluk det gamle deployment

Fordi backup-formatet er selv-beskrivende (manifest med schema-version), kan vi flytte mellem helt forskellige miljøer uden custom migration-arbejde.

Best practices

  • Tag backup før risikable operationer — store rolle-ændringer, mass-deletion, theme-overhaul
  • Opbevar ZIP'er et sikkert sted — privat cloud-storage (OneDrive, Dropbox), ikke shared netværksdrev hvor folk kan tilgå
  • Test restore mindst én gang — på en test-tenant. Gå igennem flowet så I ved hvor lang tid det tager og hvad der sker
  • Husk audit-logs er ikke i backup — hvis I har brug for rolle-ændrings-history fra før restore-tidspunktet, kontakt os mens den oprindelige tenant stadig eksisterer
  • Backup pr. kvartal er et rimeligt minimum hvis I ikke har specifikke incident-triggers

← Site-konfiguration