Exit-plan

Gendannelse et andet sted: den test, der beviser planen

Gendannelse et andet sted: den test, der beviser planen

Gendannelse et andet sted er testen, hvor I tager jeres kopi og får et arbejdende system op, uden for det miljø og den leverandør, I er afhængige af. Den beviser, at data, opsætning, nøgler og viden tilsammen er nok til at fortsætte. En almindelig restore-test af backup viser, at filer kan komme tilbage til samme sted. Denne test viser, om planen holder, når stedet er væk.

Hvordan testen passer ind i et samlet forløb med overgang og tilbagefald, står kort i trin 9 på digital-suveraenitet.dk. Her er hele fremgangsmåden. Den er generel viden, og den egner sig til de få systemer, hvor et stop ville ramme hårdest. Det er et arbejde, der skal vælges til med omtanke.

Formål

Testen skal besvare tre spørgsmål. Kan systemet bringes op uden den nuværende leverandørs hjælp? Hvor lang tid tager det sammenlignet med det, forretningen kan tåle? Hvad manglede undervejs, som ingen havde skrevet ned?

Som model kan I bruge kravene til dem, der er underlagt regler. Art. 12, stk. 2 og 3, i DORA kræver regelmæssig test af sikkerhedskopiering, gendannelse og genopretning hos finansielle enheder. Bilaget til gennemførelsesforordning 2024/2690 taler i punkt 4.2.6 om, at backup skal kunne bruges i en rigtig genopretning og dække både kopier, processer og viden. Den forordning gælder bestemte digitale tjenester. Uden for de to kredse er begge dele modeller og ingen krav.

Forudsætninger

  • En kopi, I kan nå uden leverandøren, se egen kopi uden for leverandøren.
  • En gennemført eksporttest, så I ved, at data kan læses.
  • Et sted at gendanne: en konto hos en anden udbyder, et lejet miljø eller egen infrastruktur. Det skal være adskilt. DORA art. 12, stk. 3, kræver hos finansielle enheder, at egne systemer til gendannelse er fysisk og logisk adskilt fra kildesystemet, og det er en god regel for alle.
  • Software og licenser til at køre systemet. Ved købt standardsoftware skal I undersøge, om I må gendanne det et andet sted.
  • En gennemlæst vejledning, skrevet som om testlederen var ny.
  • Et aftalt tidsrum og folk, der er frigjort.

Ved SaaS, altså software I bruger som abonnement i leverandørens miljø, kan testen ikke gennemføres på denne måde. Se gendannelse i SaaS.

Fremgangsmåde i trin

  1. Skriv kriterierne, og få dem godkendt, før noget sker.
  2. Afgræns. Vælg ét system med de integrationer, der er nødvendige for én forretningsgang. Skriv, hvad der er uden for testen.
  3. Start uret ved beslutningen. Testen begynder, som en rigtig hændelse ville gøre, med at nogen siger “nu”.
  4. Skaf kopien. Brug den kopi, der ligger klar, og ingen særlig nytagning. Notér dens alder.
  5. Byg miljøet efter vejledningen. Skriv alle steder ned, hvor vejledningen slog fejl.
  6. Gendan data og opsætning. Alt, der ikke står skrevet, tæller som fund.
  7. Tilslut login, nøgler og den nødvendige integration. Her opstår tit de største overraskelser, se login som afhængighed.
  8. Lad en forretningsbruger gennemføre et rigtigt forløb, fx oprette en ordre og sende en testfaktura til sig selv.
  9. Stop uret. Skriv tiden, og sammenhold med den tid, forretningen kan undvære systemet.
  10. Afslut og ryd op. Luk miljøet, slet kopien der, og fjern adgange.

Hold testen helt adskilt, så der ikke går mails eller fakturaer ud til rigtige modtagere, og så to systemer ikke skriver til samme data. Mere om det står i sådan tester I uden at forstyrre driften.

Kriterier, skrevet på forhånd

Kriterierne skal være målbare og knyttet til jeres egne krav. Gode kriterier her er: systemet kom i drift inden for ledelsens tidsramme. Kopien var yngre end det acceptable datatab. En forretningsbruger klarede det udvalgte forløb selv. Den nuværende leverandør blev ikke kontaktet. Tallene kommer fra RTO og RPO for ledelsen, og opbygningen fra hvad er en bestået test?.

Det, der skrives ned

Skriv tidslinjen med klokkeslæt, kopiens alder, hvad der blev brugt, hvor vejledningen slog fejl, hvem der måtte spørges, og hvert fund med en ansvarlig og en dato. Felterne står i testrapporten. Ret vejledningen samme dag, mens det er friskt.

Hvem der godkender

Den, der ejer planen, godkender kriterierne før testen. Den forretningsbruger, der gennemførte forløbet, bekræfter, at det virkede. Ledelsen modtager resultatet og tager stilling til de fund, der kræver penge eller accept. Lad en anden end testlederen læse resultatet igennem.

Hvad det kræver, og hvad det koster at lade være

Testen er det dyreste niveau af test. Den kræver forberedelse, et midlertidigt miljø, licenser, teknikere og en forretningsbruger, måske i dagevis. Anslå arbejdet i dage, lavt og højt, med dato, og lad kronerne blive i jeres eget ark.

Over for det står, hvad et stop koster pr. dag i jeres egne tal, gange forskellen på den tid, I tror, I bruger, og den tid, det faktisk tager. Det er derfor, testen er pengene værd på netop de systemer, hvor de to tal er store, og næppe på andre. Den giver desuden noget, selv om intet flytter: en rettet vejledning, trænede folk og en dokumentation, få kan fremvise.

Det skal I lade være med

  • At gendanne i samme miljø som produktion · så viser testen ikke, at I kan klare jer uden det.
  • At sende de bedste folk alene · vejledningen skal kunne følges af andre.
  • At stoppe, når data er tilbage · testen er først færdig, når en bruger har arbejdet i systemet.
  • At bruge en særlig frisk kopi · så måler I noget, der ikke findes på den dårlige dag.

Det skal planen kunne vise

  • ☐ Hvilke systemer der er udvalgt til gendannelse et andet sted, og hvorfor.
  • ☐ Godkendte kriterier med tider fra forretningen.
  • ☐ Tidslinje og målt tid.
  • ☐ Fund, ansvarlige og datoer.
  • ☐ Rettet vejledning med versionsdato.
  • ☐ Bekræftelse fra forretningsbrugeren.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Peg på det ene system, hvor et stop koster mest, og afgør, om det fortjener denne test. Lad ledelsen vælge på baggrund af en lav og en høj vurdering.

Læs også: Skrivebord, delvis eller fuld · Backup er ikke en exit-plan

→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have en plan B?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad der sætter arbejdet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.

Seneste på bloggen