Hvis du tror, at OneDrive/Google Drive/Dropbox “sikrer” dine filer, så prøv lige at forestille dig dette: En medarbejder overskriver et vigtigt regneark fredag kl. 16, og mandag morgen opdager I, at den rigtige version er væk. Synk’en virkede perfekt. Det var bare den forkerte fil, der blev synkroniseret.
I denne artikel får du en jordnær forklaring af 3-2-1-reglen, hvorfor cloud-sync ikke er backup, og hvordan du tester gendannelse uden at gøre det til et stort IT-projekt. Du får også en konkret “månedlig backup-test”-rutine, plus de klassiske fejl jeg ser igen og igen: manglende versionshistorik og manglende offline kopi.
Hvad er backup (kort definition), og hvorfor betyder det noget?
Backup er en uafhængig kopi af dine data, som kan gendannes, hvis originalen går tabt, bliver ødelagt eller låst af ransomware. Det betyder noget, fordi en backup ikke handler om “om vi mister data”, men om hvornår vi får en hændelse: fejlklik, hardwarefejl, tyveri, synk-konflikter, sletninger eller angreb.
Cloud-sync (synkronisering) er derimod en mekanisme, der holder flere enheder ens. Synk er genialt til samarbejde og adgang på tværs af enheder, men det er ikke designet som datagendannelse.
Mini-konklusion: Backup er din redningsbåd. Cloud-sync er din færge. Begge kan være nyttige, men de løser ikke samme problem.
Hvorfor cloud-sync ikke er backup (med eksempler fra virkeligheden)
Jeg har set flere virksomheder miste data, selv om “alt lå i skyen”. Ikke fordi skyen gik ned, men fordi fejlen blev synkroniseret lynhurtigt til alle enheder.
1) Sletning og overskrivning synkroniseres også
Når en fil slettes eller overskrives lokalt, bliver ændringen typisk synkroniseret til skyen og videre til andre enheder. Resultatet: Du mister ikke bare én kopi, men alle “kopier”, fordi de i praksis er samme datasæt.
Eksempel: Et marketingteam har en mappe i OneDrive. En nyansat rydder op og sletter “gamle” billeder. Synk gør sit arbejde, og hele teamets enheder opdateres. Hvis I opdager det for sent, kan papirkurven være tømt eller retention-perioden udløbet.
2) Ransomware og “krypteret synk”
Hvis en pc bliver ramt af ransomware, kan krypterede filer blive synkroniseret tilbage i skyen som “nye versioner”. Nogle tjenester kan rulle tilbage, men det kræver, at I opdager det i tide, og at versionshistorik/retention er korrekt sat op.
Mini-konklusion: Synk er fremragende til tilgængelighed, men den beskytter ikke mod den type fejl, der sker i praksis: menneskelige fejl, ondsindede ændringer og tidsforsinket opdagelse.
3-2-1-reglen forklaret, så den kan bruges mandag morgen
3-2-1 er en enkel tommelfingerregel for robust backup:
- 3 kopier af data (1 original + 2 backup-kopier)
- 2 forskellige medier/placeringer (fx NAS + cloud, eller server + ekstern disk)
- 1 kopi offsite og/eller offline (uden for huset eller frakoblet)
Det jordnære “hvorfor”: Hvis alt ligger samme sted eller på samme type system, kan én hændelse tage det hele. Brand, tyveri, overspænding, en defekt controller i en NAS, eller en fejlkonfiguration kan ramme samtidig.
Hvad betyder “offline” i praksis?
Offline er en backup, der ikke konstant er tilgængelig fra dit netværk. Det kan være en ekstern disk, som kun tilsluttes under backup og derefter frakobles, eller en cloud-backup med immutability/locked retention, så data ikke kan ændres i en periode.
Hvad betyder “offsite” i praksis?
Offsite kan være en cloud-backup i et datacenter, eller en fysisk kopi, der opbevares et andet sted. Pointen er at overleve hændelser, der rammer lokationen.
Mini-konklusion: 3-2-1 er ikke et produktvalg. Det er en struktur, der gør din backup modstandsdygtig mod de mest almindelige tabsscenarier.
Backup som driftssikring (og hvorfor det ikke kun handler om “katastrofer”)
Mange tænker backup som noget, man kun bruger, hvis hele systemet går ned. I praksis handler backup lige så meget om drift: hurtigt at få en fil tilbage, rulle en folder tilbage efter en fejl, eller genskabe en pc efter tyveri. Det er her, backup bliver en del af daglig driftssikring, og hvor en løsning for backup og sikkerhed typisk tænkes sammen med adgangsstyring, versionshistorik og en klar gendannelsesplan.
Den mest oversete værdi er tid: Hvis det tager 2 dage at gendanne, er det i praksis en driftsstopper, selv om data “findes et sted”.
RTO/RPO light: sådan tester du gendannelse uden enterprise-buzzwords
Du behøver ikke et stort beredskabsdokument for at teste, om din backup virker. Du skal bare kende to begreber i en praktisk version:
- RPO (Recovery Point Objective): Hvor meget data må du højst miste? Målt i tid. Fx “maks 4 timer” eller “maks 1 dag”.
- RTO (Recovery Time Objective): Hvor hurtigt skal I være kørende igen? Fx “inden 2 timer” eller “næste arbejdsdag”.
Et godt sted at starte er at sætte RPO/RTO per datakategori. Bogføring og kundedata har ofte en strammere RPO end fx arkiverede billeder.
Sådan oversætter du RPO til backup-frekvens
Hvis jeres RPO er 4 timer for kritiske dokumenter, nytter en natlig backup ikke. Så risikerer I at miste op til en arbejdsdag. Typisk ser jeg små og mellemstore virksomheder lande på:
- Kritiske data: backup hver 1–4 time
- Vigtige data: daglig
- Mindre kritiske data: ugentlig eller efter behov
Sådan oversætter du RTO til en konkret gendannelsesplan
Hvis jeres RTO er “2 timer”, skal I vide præcis, hvordan I gendanner: hvor backup’en ligger, hvem der har adgang, og om der er båndbredde nok til at hente flere hundrede GB hjem. Her falder mange på “vi kan altid hente fra skyen” uden at teste, hvad det tager i praksis.
Mini-konklusion: RPO handler om hvor meget, I kan tåle at miste. RTO handler om hvor længe, I kan tåle at være nede. Begge dele skal måles, ikke gættes.
Månedlig backup-test: en rutine der faktisk bliver gjort
Backups fejler oftere stille, end folk tror. Derfor anbefaler jeg en fast, månedlig test, der tager 20–45 minutter, og som kan udføres af en ansvarlig (ikke nødvendigvis en IT-specialist), så længe proceduren er dokumenteret.
- Vælg 3 gendannelsesscenarier: 1 enkelt fil, 1 mappe og 1 “større” gendannelse (fx en pc-profil eller et systemimage, hvis I bruger det).
- Vælg data fra forskellige tidspunkter: fx “i går”, “sidste uge” og “sidste måned” for at teste retention/versionshistorik.
- Gendan til et test-sted: aldrig oven i produktion. Brug en “Restore-Test”-mappe eller en testmaskine.
- Mål tiden: hvor lang tid tog det fra start til filen kunne åbnes? Notér som jeres faktiske RTO for det scenarie.
- Kontrollér integritet: kan Excel-filen åbnes uden fejl, virker makroer, er billeder ikke korrupt, matcher antal filer forventningen?
- Log resultatet: dato, hvad der blev testet, hvem der testede, og eventuelle fejl. En enkel log i et delt dokument er nok.
- Ret én ting med det samme: fx manglende adgang, forkert retention, eller uklare instruktioner. Små løbende forbedringer slår store planer.
Praktisk tip: Sæt en fast gentagelse i kalenderen den første tirsdag i måneden. Det lyder banalt, men “backup-test” uden kalender bliver ofte til “backup-test en dag”.
Mini-konklusion: Den bedste backup-plan er den, der bliver testet jævnligt og forbedret i små skridt.
Typiske fejl jeg ser (og hvordan du undgår dem)
Her er de mest almindelige årsager til, at virksomheder tror de har backup, men alligevel står uden brugbar gendannelse.
Ingen versionshistorik eller for kort retention
Hvis versionshistorik er slået fra, eller retention kun er 7–30 dage, kan en fejl, der opdages sent, være umulig at rulle tilbage. Det gælder især ved stille datakorruption (filer bliver gradvist ødelagt) eller langsomme ransomware-angreb.
- Gør retention til et aktivt valg: fx 90 dage for dokumenter og 180–365 dage for kritiske forretningsdata.
- Test gendannelse af en “gammel” version hver måned.
Ingen offline kopi (alt er altid tilgængeligt)
Hvis din backup-destination altid er monteret og tilgængelig, kan malware potentielt nå den. En offline kopi (frakoblet disk) eller en “write-once/immutable” cloud-backup reducerer risikoen markant.
Man gendanner “til samme sted” og overskriver beviser
Ved en hændelse vil man ofte hurtigt “fikse” problemet og gendanne direkte tilbage. Men så risikerer du at overskrive spor, fejlbehæftede filer eller den eneste brugbare version. Gendan først til et sikkert test-sted, verificér, og flyt derefter tilbage.
Backup af “filer” men ikke af det, der gør dem brugbare
Jeg ser ofte, at man har taget backup af dokumenter, men glemt:
- mail (hvis den ikke er korrekt dækket af politik/backup)
- adgangsrettigheder og delinger
- systemkonfigurationer
- licensnøgler og 2FA-recovery-koder
Mini-konklusion: De farligste backup-fejl er dem, der ikke opdages før en stresset gendannelse. Derfor skal rutinen teste mere end “kan vi hente en fil?”.
Hvad koster det at gøre det rigtigt (uden at overkøbe)?
Prisen afhænger af datamængde, frekvens, retention og om I vil have offline/immutable kopier. Som tommelfingerregel er det ikke lagerpladsen alene, der koster, men drift og sikkerhed: overvågning, alarmer ved fejl, og muligheden for hurtig restore.
Et pragmatisk niveau for mange mindre virksomheder er at kombinere en lokal backup (hurtig gendannelse) med en offsite/immutable kopi (beskyttelse mod større hændelser). Hvis du kun vælger én ting at forbedre, så gør det gendannelsen hurtigere og mere sikker, ikke bare “mere plads i skyen”.
Bedste praksis: en kort tjekliste du kan bruge i dag
- Skeln tydeligt mellem synk og backup i jeres politik og værktøjer
- Implementér 3-2-1 med mindst én offsite og én offline/immutable kopi
- Definér RPO/RTO “light” for 2–3 datatyper (kritisk/vigtig/øvrigt)
- Aktivér og verificér versionshistorik og retention
- Test gendannelse månedligt og log resultater
- Adskil adgang til backup fra almindelige brugerkonti (mindst mulig adgang)
- Overvåg backup-jobs og få alarmer ved fejl (ikke kun “grøn status”)
Mini-konklusion: Når du kan gendanne en fil, en mappe og et større scenarie inden for jeres RTO, og du ved præcis hvor langt tilbage I kan rulle (RPO), så har I reelt en backup — ikke bare en synk.
