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: 10.10.2026. Siste gjenopprettingstest er fra 10.10.2026.

Vilkårene punkt 6.8 viser hit: dette er planen for kontinuitet og gjenoppretting, og den testes minst én gang i året. Foretaket får planen og resultatet av siste test på forespørsel.

1. Hva Verid består av

2. Mål for gjenoppretting

Skjer en feil mer enn 7 døgn før den blir oppdaget, finnes ikke tilstanden før feilen lenger. Applikasjonen kan rulles tilbake til en tidligere utrulling i Vercel uten nytt bygg.

Nedetid oppdages av Better Stack, som sjekker /api/helse hvert tredje minutt fra fire regioner og varsler på e-post (monitoren «Verid»). Ruten svarer 503 når databasen ikke svarer. Oppetiden vises på verid.no/status.

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 7 døgns historikk. Gjenopprettingen er prøvd — se testene under. Planen er:

1. Lag en ny gren fra main slik den var før feilen. Det rører ikke main:

`` npx neonctl branches create --project-id late-wildflower-39485757 \ --name gjenoppretting-<dato> --parent <tidspunkt i UTC, ISO 8601> ``

Bruk ikke restore_snapshot for dette. Se advarselen under testen fra 28.09.2026.

1. Kontroller grenen: antall saker, siste hendelse, siste rapport.
2. Pek DATABASE_URL og DATABASE_URL_UNPOOLED i Vercel mot grenen, eller gjenopprett hovedgrenen fra tidspunktet.
3. Rull ut på nytt, og kontroller innlogging og en sak.
4. Skriv i hendelsesnotatet hvilket tidspunkt det ble gjenopprettet til, og hva som ble skrevet etter det og gikk tapt.

Rapportarkivet. PDF-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 10.10.2026

Resultat: gjenopprettingen virker. En ny gren (gjenopprettingstest-2026-10-10, br-raspy-credit-b10t3ew9) ble laget fra main slik den var 09.10.2026 kl. 07:59:35 UTC, med neonctl branches create --parent <tidspunkt>. main ble ikke rørt. Radene som fantes før tidspunktet, ble sammenlignet med produksjon:

Grenen var klar på under ett minutt. Neste test: senest 10.10.2027.

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 Oxylabs, 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 (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