Kontinuitet og gjenoppretting

Retningslinjen sier hva som skjer når Verid, en underleverandør eller en kilde er nede, og hvordan data hentes tilbake. Den skiller mellom det Verid har prøvd, det plattformene tilbyr men Verid ikke har prøvd, og det som ikke er på plass. Tall som ikke er målt, står ikke her.

Sist oppdatert: 28.09.2026, etter gjenopprettingstesten.

1. Hva Verid består av

2. Mål for gjenoppretting

Verid har ikke satt mål for hvor mye data som kan gå tapt (RPO) eller hvor lenge tjenesten kan være nede (RTO). Ingen gjenoppretting er målt.

Det som er kjent:

• Applikasjonen kan rulles tilbake til en tidligere utrulling i Vercel. Funksjonen finnes i Vercel. Verid har ikke skrevet ned når den sist ble brukt.
• Databasen kan gjenopprettes til et hvilket som helst tidspunkt det siste døgnet. Neon holder historikk i 24 timer i Verids prosjekt (history_retention_seconds: 86400, lest 28.09.2026). Det er det største tapet av data en gjenoppretting kan dekke: skjer feilen mer enn et døgn før den blir oppdaget, finnes ikke tilstanden før feilen lenger.

3. Gjenoppretting per del

Applikasjonen. Hver push til main gir en ny utrulling. Er en utrulling feil, velger vi en tidligere utrulling i Vercel og gjør den til produksjon («Instant Rollback»). Det krever ikke nytt bygg.

Merk: en tilbakerulling tar ikke skjemaet i databasen med seg. Migreringer kjøres for hånd med pnpm --filter @workspace/db migrer (packages/db/package.json), og filene ligger i packages/db/migrasjoner/. En migrering som ikke virker med forrige utrulling, må rettes framover.

Databasen. Neon tilbyr gjenoppretting til et tidspunkt og grener av databasen, med 24 timers historikk. Gjenopprettingen er prøvd — se «Gjenopprettingstest 28.09.2026» under. Planen er:

1. Ta et øyeblikksbilde av main fra tidspunktet før feilen, og gjenopprett det med `finalize: false` (i konsollen: «Restore» uten å fullføre). Se advarselen under før du gjør dette.
2. Kontroller grenen: antall saker, siste hendelse, siste rapport.
3. Pek DATABASE_URL og DATABASE_URL_UNPOOLED i Vercel mot grenen, eller gjenopprett hovedgrenen fra tidspunktet.
4. Rull ut på nytt, og kontroller innlogging og en sak.
5. Skriv i hendelsesnotatet hvilket tidspunkt det ble gjenopprettet til, og hva som ble skrevet etter det og gikk tapt.

Rapportarkivet. PDF/A-filene i Vercel Blob har ingen sikkerhetskopi i Verid. Hash-summen av PDF-en står i rapport.pdf_sha256, så en fil som er endret, kan påvises. En fil som er slettet, kan ikke hentes fra Verid. Rapporten kan lages på nytt fra saksdataene, men den nye filen er ikke den arkiverte.

Sletting og gjenoppretting. En gjenoppretting til et tidspunkt før slettejobben kan hente tilbake saker som skulle vært slettet. Etter en gjenoppretting skal slettejobben (apps/web/app/api/cron/slett-utlopte) kjøres med én gang, ikke vente til neste natt. Skriptet pnpm --filter @workspace/db slett-utlopte kan bare vise hva som ville blitt slettet. Det sletter ingenting.

Jobben sletter arkivet i Vercel Blob før radene i databasen. Arkivfiler som jobben har slettet, kommer ikke tilbake med en gjenoppretting av databasen.

Gjenopprettingstest 28.09.2026

Resultat: gjenopprettingen virker. Et øyeblikksbilde av main fra 07:00 UTC ble hentet tilbake som en egen gren, med tilstanden fra 06:51:

Kopien hadde nøyaktig det som fantes før tidspunktet, og ingenting etter. Operasjonen tok under ett sekund.

Advarsel — det som gikk galt under testen. restore_snapshot uten finalize: false lager ikke en frittstående kopi. Den tar over kildegrenens navn, rollen som hovedgren og compute-en. I ca. 45 sekunder (09:20:42–09:21:27 UTC) pekte produksjonens compute (ep-patient-cell) på kopien fra 06:51. Compute-en sov hele tiden, og kopien skrev 0 byte, så ingen data gikk tapt. Den ble flyttet tilbake til den opprinnelige grenen (br-cool-sun-b12y6nvu), som igjen er main, hovedgren og standard.

Derfor, ved neste test eller ekte gjenoppretting:

• Bruk finalize: false, og les kopien før noe flyttes.
• Sjekk hvilken gren ep-patient-cell peker på før og etter.
• main er beskyttet i Neon (protected) fra 28.09.2026, så den ikke kan slettes eller nullstilles ved et uhell.

4. Når en kilde er nede

Kildene er registrene og tjenestene Verid slår opp i. En kilde som er nede, stopper ikke saken. Den blir et dokumentert hull.

• Hvert oppslag har et tidsavbrudd på 15 sekunder og to nye forsøk ved 429 og 5xx (packages/sources/src/kilde.ts).
• Svaret føres med en av fire statuser: ok, ikke-funnet, utilgjengelig (driftsfeil) eller ikke-tilgang (vi mangler nøkkel eller tilgang). Status, URL og tidspunkt lagres uansett.
• Er Enhetsregisteret, grunnboken eller Register over reelle rettighetshavere utilgjengelig, blir det en observasjon med alvorlighet «oppfølging» og tekst om at oppslaget må gjentas eller gjøres manuelt (packages/pipeline/src/observasjoner.ts).
• Feiler screeningen hos OpenSanctions eller søket hos Serper, blir det et punkt på sjekklisten (packages/pipeline/src/sjekkliste.ts).
• Er språkmodellen utilgjengelig, blir søketreffene stående uvurdert og går på sjekklisten (.env.example, README.md).
• Er Vercel Blob utilgjengelig, kan rapporten godkjennes uten arkivert PDF/A (README.md).

Megleren kan kjøre saken på nytt når kilden er tilbake.

5. Når en underleverandør er nede

Er Verid nede over fire timer i arbeidstid, varsler vi foretakene. Et foretak som ikke kan bruke Verid, må gjøre kundetiltakene manuelt i mellomtiden. Plikten etter hvitvaskingsloven ligger hos foretaket.

Gjenstår