Om nogen reagerer, når backuppen fejler, kan ses i historikken: jobloggen over en periode, de advarsler, systemet har sendt, og de spor, der viser, at nogen har handlet på dem. Et job, der har fejlet i ugevis uden en sag, en kommentar eller en genkørsel, viser, at advarslerne ikke bliver læst.
Backupsystemer sender advarsler. De går til en fælles postkasse, en tidligere medarbejder eller en leverandør, der har skiftet kontaktperson. Efter et stykke tid vænner modtagerne sig til, at der kommer mange, og holder op med at åbne dem. Jobbet fejler stille videre.
Målestokken
Bilagets punkt 4.2.3 i forordning 2024/2690 kræver regelmæssig kontrol af backupkopiernes integritet. Punkt 3.2.3, litra f, siger, at logfilerne, hvor det er relevant, dækker adgang til og ændringer i kritiske filer med konfiguration og backup. Og punkt 3.2.4 siger, at logfiler gennemgås regelmæssigt, at der fastsættes tærskler for alarmer, og at der rettidigt sikres en kvalificeret reaktion. Kredsen, forordningen binder, står i artikel 1 og tæller fx udbydere af cloudtjenester og administrerede tjenester. Alle andre kan vælge bilaget som målestok.
Delegeret forordning 2024/1774, som udfylder DORA, siger i artikel 23, stk. 2, at finansielle enheder har værktøjer med automatiske varslinger ved anomalier, der påvirker fuldstændigheden og integriteten af datakilderne. Bestemmelsen handler om logkilder. At bruge den på backup er en tolkning.
Ingen af kilderne siger, hvor ofte jobloggen skal læses. Ordet er “regelmæssig”. At historikken er beviset for, at nogen læser, er praksis.
Historikken
Første udtræk er jobloggen for en periode, fx de seneste tre måneder, med status for hver kørsel: vellykket, med advarsler eller fejlet. Udtrækket kommer fra backupsystemet selv, ikke fra en rapport, nogen har lavet bagefter.
Gennemgangen ser efter mønstre:
- Job, der har fejlet flere gange i træk.
- Job, der altid ender med advarsler, som ingen har undersøgt.
- Job, der er slået fra eller sat på pause, og hvornår det skete.
- Job, hvis datamængde pludselig er faldet, fordi en mappe eller en server er faldet ud af omfanget.
Det sidste er ikke en fejl i jobloggens forstand. Jobbet kører grønt, det tager bare mindre med. Den slags opdages kun ved at sammenligne datamængden over tid eller ved den afstemning, der står i er alt med i backuppen?.
Advarslerne
Det andet udtræk er opsætningen af advarsler: hvilke hændelser udløser en advarsel, og hvem modtager den? Gennemgangen tjekker, at modtagerne findes, at de stadig har opgaven, og at advarslerne ikke ender i en postkasse, ingen har ansvaret for.
Et godt kontrolpunkt er at finde en kendt fejl i jobloggen og følge den. Blev der sendt en advarsel? Til hvem? Hvornår blev der reageret, og hvad blev gjort? Kan sporet følges fra fejl til løsning, virker kæden. Kan det ikke, er der et hul et sted.
Sporet af en reaktion
Forordningens ord om en rettidig og kvalificeret reaktion peger på, at reaktionen skal kunne ses. Det kan være en sag i sagssystemet, en kommentar i backupsystemet eller en genkørsel med en note. Det er almindelig praksis, at hver fejlet kørsel får en kort registrering af årsag og handling. Uden den kan ingen se forskel på en fejl, der blev løst, og en fejl, der gik over af sig selv.
Er backuppen drevet af en leverandør, gælder det samme. Kontrolpunktet er, at I modtager en rapport over fejlede job og handlinger, og at nogen hos jer læser den.
Integritetskontrol
Et vellykket job betyder, at kopien blev skrevet. Det betyder ikke, at den kan læses. Forordningens krav om regelmæssig integritetskontrol handler om det. Har backupsystemet en funktion, der kontrollerer kopien efter kørslen, spørger gennemgangen, om den er slået til, og hvad resultatet har været. Har det ikke, skal kontrollen ske på anden vis. Den endelige kontrol er en gendannelse, som beskrevet i gendannelsestesten.
Ændringer i backupopsætningen
Punkt 3.2.3, litra f, om logning af ændringer i backupfiler giver et kontrolpunkt mere. Er et job slået fra, eller er omfanget ændret, skal det kunne ses, hvem der gjorde det og hvornår. Gennemgangen tjekker, om backupsystemets egen log viser ændringer i job og politikker, og om den log gemmes et sted, hvor den ikke kan slettes af den samme administrator.
Hvad det kræver, og hvad det koster at lade være
Det kræver et udtræk af jobloggen, opsætningen af advarsler og en time til at følge et par fejl fra advarsel til løsning. Arbejdet er lille. Det svære er at få en navngiven person til at eje advarslerne bagefter.
Uden kontrollen kan backuppen have fejlet i ugevis, uden at nogen ved det. Den dag, der skal gendannes, er den nyeste brugbare kopi ældre end nogen regnede med.
Det skal I lade være med
- At sende advarsler til en fælles postkasse uden ejer · giv dem en navngiven modtager.
- At regne et grønt job som en brugbar kopi · integriteten skal kontrolleres.
- At slå et job fra uden at registrere hvorfor · ændringen skal kunne findes bagefter.
Det skal gennemgangen kunne vise
- ☐ Jobloggen for en periode med status for hver kørsel.
- ☐ Job, der har fejlet gentagne gange, og hvad der blev gjort.
- ☐ Modtagerne af advarsler, og at de har opgaven i dag.
- ☐ Et fulgt eksempel fra fejl til løsning.
- ☐ Status for integritetskontrol og log over ændringer i job og politikker.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690, artikel 1, bilagets punkt 3.2.3, 3.2.4 og 4.2.3, læst 13. november 2026.
- Kommissionens delegerede forordning (EU) 2024/1774, artikel 23, stk. 2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste fejlede kørsel i jobloggen, og følg den fra advarsel til løsning.
Læs også: Alarmer: findes reglerne, og reagerer nogen? · Mål for gendannelsestid og datatab
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
