Backup af hjemmeside: hvor ofte er nok i en virksomhed?

Hvor ofte skal en hjemmeside tage backup?

Det er et spørgsmål, de fleste virksomheder aldrig stiller sig selv, før det er for sent. Og det er præcis problemet.

Du har fået bygget en flot hjemmeside, den kører fint, folk finder jer, og hverdagen ruller. Så en dag trykker du på opdater i WordPress, og pludselig er forsiden hvid. Eller din webshop holder op med at acceptere betalinger. Eller dit hostingfirma ringer og fortæller, at serveren er gået ned.

I det øjeblik er der kun ét spørgsmål, der betyder noget: hvornår tog vi sidst backup, og kan vi bruge den?

Svaret på, hvor ofte du skal tage backup af din hjemmeside, er ikke en fast regel, der gælder alle. Det afhænger fuldstændig af, hvad din side gør, og hvad du mister, hvis den forsvinder i fire timer eller fire dage. Men lad os starte med at forstå, hvad der rent faktisk adskiller de forskellige typer hjemmesider fra hinanden.

Forskellen på brochure side, webshop og portal

En simpel brochureside, altså en side der præsenterer virksomheden, viser kontaktoplysninger og måske et par sider med ydelser, ændrer sig sjældent. Indholdet er statisk, og en ugentlig backup af hjemmeside er som udgangspunkt tilstrækkelig for langt de fleste i den kategori.

Men en webshop er en anden sag. En WooCommerce-butik kan modtage tredive ordrer om dagen. Hver ordre gemmes i databasen med kundedata, betalingsstatus og lagertal. Hvis du tager backup én gang om ugen og siden crasher om torsdagen, har du tabt alt fra mandagen. Ingen ordrehistorik, ingen kundeoplysninger, ingen sporbarhed.

En portal eller et system med brugerlogins, formularer, bookinger eller dynamisk indhold befinder sig i den absolut kritiske ende. Her er det ikke usædvanligt, at der sker ændringer mange gange i timen. Backup af webshop og portaler bør som minimum ske dagligt, og i mange tilfælde adskillige gange om dagen.

Tabellen nedenfor giver et hurtigt overblik over anbefalede frekvenser baseret på sidetypen:

Sidetype	Anbefalet backup-frekvens	Vigtigste element
Brochureside	Ugentlig	Filer og database
Blog/nyhedssite	Daglig	Database og uploads
Webshop (WooCommerce)	Daglig eller oftere	Database med ordrer
Portal/booking-system	Flere gange dagligt	Database i realtid

Når nye ordrer og formularer ændrer behovet

Der er mange virksomheder, der tager backup af hjemmesiden én gang om ugen, fordi de altid har gjort det sådan. Problemet opstår, når siden pludselig begynder at modtage tilmeldinger til et arrangement, håndtere kundeforespørgsler via formular, eller sælge produkter online. Med ét er siden ikke længere statisk.

Databasebackup bliver i det scenarie langt vigtigere end filbackup. Filerne ændrer sig sjældent, men databasen ændrer sig ved hvert eneste køb, hvert login og hver formularudfyldelse. Det er her, forretningsdata lever.

En god tommelfingerregel er at spørge sig selv: hvad koster det os i kroner, tid og troværdighed, hvis vi mister de seneste 24 timers data? Hvis svaret er: en del, så er du allerede for langt bag ud med din backup-frekvens.

Hvad skal en backup af hjemmeside egentlig indeholde?

De fleste tror, at backup er backup. Det er det ikke. En fuld og brugbar backup af hjemmeside indeholder ikke bare én enkelt fil. Det er en samling af separate dele, der alle skal være intakte og koordinerede med hinanden, for at gendannelsen rent faktisk virker.

Det er en af de mest oversete fejl i praksis. Man har en backup, men den er ufuldstændig, fordi man ikke vidste, hvad der egentlig skulle gemmes. Og det finder man typisk først ud af, den dag man faktisk har brug for den.

Filer, database, uploads og e-mails er ikke det samme

En WordPress hjemmeside består groft sagt af tre hoveddele: programfilerne (WordPress-kernen og dine plugins og temaer), databasen (alt indhold, indstillinger og metadata) og uploads-mappen (billeder, dokumenter og medier).

Hvis du kun gemmer filerne, men ikke databasen, har du en tom WordPress-installation uden indhold. Hvis du kun gemmer databasen, men ikke uploadsmappen, mangler alle dine billeder. En komplet fil backup og database backup skal gå hånd i hånd.

Og så er der e-mails. Hvis din virksomhed bruger e-mail knyttet til dit domæne, og den lever på samme server som hjemmesiden, kan en server-crash betyde, at du mister indgående mails og historik. Det er ikke en del af en standard WordPress backup, og det kræver en separat løsning.

WordPress, WooCommerce og plugin data bliver tit glemt

Når man taler om backup af wordpress hjemmeside, er der en detalje, der næsten altid falder ned imellem stolene: plugin-specifikke data og indstillinger.

Et bookingplugin gemmer sine data i egne tabeller i databasen. Et formularværktøj gemmer indgange samme sted. WooCommerce backup handler ikke kun om produkterne. Ordrer, kunder, lagerstatus, rabatkoder og forsendelsesindstillinger lever alle i databasen i separate tabeller, som kun gendannes korrekt, hvis hele databasen er med.

Derudover er der konfigurationsfilen wp-config.php, som indeholder databaseforbindelsen og sikkerhedsnøgler. Den er ikke en del af standard WordPress-kernen og skal gemmes separat. Glemmer du den, kan du ikke forbinde en gendannet database til installationen.

Backup database wordpress er med andre ord ikke blot et klik på en knap. Det kræver, at du ved, hvad der rent faktisk er med, og hvad der måske er glemt.

Cloud lager alene er ikke en brugbar backup

Mange forveksler cloud-synkronisering med cloud backup hjemmeside, og det er en dyr misforståelse. Hvis du bruger Dropbox, Google Drive eller en lignende tjeneste til at spejle dine filer, synkroniserer du i realtid. Det lyder godt, men det betyder også, at en korrupt fil, et hacket system eller en slettet database med det samme kopieres og overskriver den "gode" version i din cloud.

En reel backup kræver versionering. Det vil sige, at du kan gå tilbage til en specifik dato og et specifikt tidspunkt, ikke bare til den seneste version. Cloud-lager uden versionering er ikke backup. Det er et spejl, og spejle viser det samme, uanset hvad det er.

Hvorfor er gendannelse vigtigere end selve backupen?

Det er en provokerende påstand, men den holder. Du kan have den mest disciplinerede backup-rutine i verden. Daglig backup, ekstern lagerplads, krypteret, konfigureret og glemt i et hjørne. Men hvis du aldrig har testet, om du rent faktisk kan gendanne din hjemmeside, ved du ikke, om din backup er brugbar.

Gendannelse, eller restore hjemmeside som det ofte hedder, er den del, ingen øver sig på. Det er først, når krisen er der, at man opdager, at backup-filen er korrupt. At adgangskoden til backup-lageret ikke virker. At man ikke ved, hvilken version der er den rigtige. At gendannelse på en ny server kræver manuelle skridt, ingen husker.

Hvis du ikke har prøvet at gendanne din hjemmeside i et testmiljø, har du ikke en backup-strategi. Du har en backup-intention. Og det er to meget forskellige ting.

Backup og gendannelse hører uløseligt sammen. En kopi, du aldrig har prøvet at åbne, er som en brandslukkер, ingen har tjekket om virker. Den hænger der, den ser ud til at virke, men du finder ud af sandheden, når ilden er der.

En gammel eller ødelagt kopi redder ingen drift

Der er to scenarier, der igen og igen viser sig i praksis. Det første er den gamle backup: man gendanner fra en kopi, der er tre uger gammel, fordi der ikke findes noget nyere. Resultatet er et hul i ordrehistorikken, manglende kundeprofiler og en webshop, der teknisk nok kører, men som er ude af sync med virkeligheden.

Det andet scenarie er den korrupte backup. Zip-filen er ufuldstændig. Databasedumpen afbrydes midt i eksport. Plugin-mappen er tom, fordi backup-processen løb tør for plads på serveren. Man opdager det ikke, fordi ingen tjekkede, om eksporten faktisk lykkedes.

En automatisk backup hjemmeside løser ikke i sig selv disse problemer. Du er nødt til at have en proces for at verificere, at backuppen rent faktisk er komplet og brugbar. Det behøver ikke at være kompliceret. En månedlig testgendannelse i et staging-miljø er ofte tilstrækkeligt til at afsløre fejl, før de koster dig dyrt.

De mest dyre fejl i backup af webshop og hjemmeside

Når det går galt, er det sjældent fordi ingen tog backup. Det er fordi backuppen var forkert opsat, forkert opbevaret eller aldrig testet. Her er de tre fejl, der går igen og igen hos virksomheder med mistet hjemmeside data.

Backup på samme server beskytter ikke mod nedbrud

Det er den mest klassiske fejl af dem alle. Din hjemmeside og din backup ligger begge på den samme server hos dit hostingfirma. Serveren bryder ned, går i brand, bliver hacket eller slettes ved en fejl. Og med den forsvinder også din backup.

En server backup er ikke en ekstern backup. Det er en kopi på samme sted. Og det svarer til at tage en kopi af et vigtigt dokument og lægge den i samme skuffe som originalen.

En brugbar backup af hjemmeside kræver, at kopien opbevares på en anden fysisk eller logisk lokation. Det kan være en ekstern cloud-tjeneste, en lokal harddisk hjemme på kontoret, eller en dedikeret backup-server. Kombinationen af to separate steder er den sikreste løsning.

Ingen test betyder falsk tryghed på en travl dag

Man regner med, at backuppen virker, fordi systemet siger, den er kørt. Men der er stor forskel på, at en backup er startet, og at den er fuldført korrekt. Mange automatiske backup-løsninger melder success, selvom processen er afbrudt midtvejs, eller selvom lagerplads er brugt op.

Falsk tryghed er farligere end ingen backup, fordi du tror du er dækket. Du handler ikke, du forbereder dig ikke, og du opdager fejlen den dag, du absolut mindst kan bruge det.

Test gendannelse regelmæssigt. Ikke bare en gang, da du satte systemet op, men kvartalsvis. Et staging-miljø hos dit hostingfirma er det ideelle sted at gøre det. Gendannelse af backup wordpress i et testmiljø tager sjældent mere end en time, men den time kan spare dig for dage af kaos.

Uklar ansvarsfordeling giver lange driftsstop

Hvem tager backup hos jer? Tager hostingfirmaet den? Tager dit webbureau den? Tager I den selv via et plugin? I mange virksomheder er svaret: vi tror, det er nogen andre.

Det er ikke et spørgsmål om, hvem man kan skyde skylden på efterfølgende. Det er et spørgsmål om, at ingen faktisk gør det, fordi alle forudsætter, at det er den andens ansvar. Resultatet er, at der enten slet ikke tages backup, eller at de tre parter tager tre forskellige backups, der ikke koordineres med hinanden.

Afklar ansvaret konkret og skriftligt. Hvem tager backup, hvornår, af hvad, og hvem kan gendanne den? Det er ikke et teknisk spørgsmål. Det er et organisatorisk spørgsmål, og det skal besvares, inden krisen opstår.

Sådan vælger du en frekvens der matcher risikoen

Frekvensen på din backup af hjemmeside skal ikke bestemmes af, hvad din host tilbyder som standard. Den skal bestemmes af, hvad din virksomhed har råd til at miste. Det er den eneste rette tilgang til backup strategi hjemmeside.

Tænk på det som et simpelt regnestykke: hvad er din maksimale acceptable datatab-periode? I branchen kalder man det RPO, Recovery Point Objective. Altså: hvor langt tilbage i tid kan du maksimalt acceptere at gendanne fra?

En virksomhed med en statisk hjemmeside kan sagtens leve med en uge. En virksomhed med en aktiv webshop og daglige ordrer bør ikke acceptere mere end et par timer. Og en virksomhed med en bookingplatform eller betalingsløsning i realtid bør kigge på kontinuerlig database backup.

Time, dag eller uge afhænger af tabt data og omsætning

Hvis din webshop omsætter for femti tusinde kroner om dagen, og du mister en dags ordrer, er det ikke bare frustrerende. Det er direkte tab, dobbeltarbejde og sandsynligvis sure kunder, der aldrig kommer tilbage. I det scenarie er en daglig backup ikke nok, du skal op på adskillige daglige backups af databasen.

For en blog eller en portfolio-side, hvor det nyeste indhold er et indlæg fra i torsdags, giver en ugentlig backup god mening. Du har ikke dynamisk data, du mister ikke transaktioner, og gendannelse fra en uge gammel kopi er næsten smertefri.

Vurder din side ud fra disse tre spørgsmål:

• Hvor ofte ændrer indholdet sig? Konstant, dagligt eller ugentligt?
• Hvad mister du i kroner, hvis du ruller 24 timer tilbage? Beregn det konkret.
• Hvem er påvirket udover dig selv? Kunder, leverandører, samarbejdspartnere?

Svarene giver dig svaret på, hvilken frekvens der giver mening. Ikke hvad der er nemmest at sætte op, men hvad der reelt beskytter din forretning.

Retention og versionshistorik er lige så vigtige

Backup-frekvens er kun halvdelen af ligningen. Den anden halvdel er retention, altså hvor længe du gemmer dine kopier og hvor mange versioner du beholder.

Lad os sige, du opdager i dag, at din hjemmeside har været inficeret med malware i tre uger. Hvis din backup-løsning kun gemmer de seneste syv dage, er alle dine kopier allerede inficerede. Du har ingen ren version at gendanne fra.

En god tommelfingerregel er at gemme daglige backups i mindst 30 dage, ugentlige backups i 3 måneder, og månedlige backups i 12 måneder. Det giver dig versionshistorik, der faktisk hjælper i et virkelighedsscenarie og ikke bare i det bedste tilfælde.

Versionshistorik er det, der adskiller en professionel backup-løsning fra en gratis plugin, der overskriver den samme fil hver uge. Når du vælger din backup-løsning, er antallet af gemte versioner mindst lige så vigtigt som selve frekvensen.

Backup er ikke en teknikalitet, det er et forretningsansvar

Denne artikel er startet med det øjeblik, alle frygter: opdateringen der gik galt, ordren der forsvandt, serveren der ikke svarede. Og undervejs har vi gennemgået præcis, hvad det kræver at stå stærkt i det øjeblik.

Backup af hjemmeside handler om, hvor ofte du tager kopier, men det handler i langt højere grad om, hvad du gemmer, hvor du gemmer det, og om du rent faktisk kan bruge det, når det brænder på. En backup strategi hjemmeside, der kun lever på papir, er ikke en strategi. Den er en hensigt.

Du har nu fået et realistisk billede af forskellen på brochureside, webshop og portal. Du ved, hvad en komplet backup af wordpress hjemmeside skal indeholde, og du ved, at filer og database ikke er det samme. Du har set, hvorfor gendannelse er vigtigere end selve backuppen, og du kender de fejl, der gang på gang gør en backup værdiløs præcis når den skal bruges.

Og du ved nu, at frekvensen skal matche din risiko: at backup wordpress ikke er en standard-indstilling, men et aktivt valg baseret på, hvad din virksomhed har råd til at miste. Hverken mere eller mindre.

Tag backup-snakken internt, afklar ansvaret, test din gendannelse, og sørg for, at din kopi aldrig bor alene på den server, den skal beskytte dig imod. Det er ikke raketvidenskab. Det er bare god forretningsfornuft.