En WordPress backup er ikke bare en kopi af et website. Den er din hurtigste vej tilbage til drift, når en opdatering fejler, en plugin-konflikt vælter databasen, eller malware rammer. For virksomheder, webshops og bureauer er problemet sjældent kun tabte filer, men tabt omsætning, tabt tillid og spildt arbejdstid. Derfor skal en backup-løsning vurderes på, […]
En WordPress backup er ikke bare en kopi af et website. Den er din hurtigste vej tilbage til drift, når en opdatering fejler, en plugin-konflikt vælter databasen, eller malware rammer. For virksomheder, webshops og bureauer er problemet sjældent kun tabte filer, men tabt omsætning, tabt tillid og spildt arbejdstid. Derfor skal en backup-løsning vurderes på, om den faktisk kan gendanne hele sitet hurtigt, sikkert og uden overraskelser.
En WordPress backup er en fuld kopi af filer og database i WordPress og MySQL. Den løser tab efter fejl, hacking og mislykkede opdateringer, og uden den kan selv et mindre plugin-problem udvikle sig til timer eller dage med nedetid.
WordPress består i praksis af to dele: filer og database. Filerne rummer temaer, plugins, uploads og konfiguration, mens databasen indeholder sider, indlæg, brugere, ordredata og indstillinger. Hvis kun den ene del er reddet, er sitet sjældent brugbart bagefter.
Det er også her mange går galt. De tror, at webhotellets standardkopi automatisk er nok. Det kan den være, men kun hvis du ved, hvor ofte den kører, hvor længe den gemmes, og hvor hurtigt du kan gendanne til et konkret tidspunkt.
Du bør mindst tage daglig backup af WordPress, men WooCommerce og medlems-sites kræver ofte databasekopier hver 2. til 12. time. Hostious.io bruger hver 2. time som standard, og det niveau passer bedre til sider med ordrer, formularer og løbende indhold.
Start med ændringshastigheden. Hvis sitet kun opdateres få gange om måneden, kan daglig backup være tilstrækkelig. Hvis der kommer nye ordrer, kundedata eller formularer hver time, skal databasen sikres langt oftere end filer.
Mål derefter dit acceptable datatab. Hvis du højst vil miste to timers data, skal backup-frekvensen være to timer eller mindre. Det kaldes ofte RPO, Recovery Point Objective. Jo lavere RPO, jo mindre tab, men også højere krav til systemet.
Sæt til sidst forskellige intervaller for forskellige datatyper. Filer ændrer sig sjældnere end databaseindhold. Pro tip: Mange vælger daglig fuld backup af alt, men det er ofte en dyr og tung løsning. En bedre model er hyppig databasebackup kombineret med mindre hyppig filbackup.
Ja, der er otte krav, som skiller en brugbar WordPress backup fra en falsk tryghed. WordPress og WooCommerce kræver både høj frekvens, fuld dækning og hurtig restore, ellers hjælper kopien først, når skaden allerede er blevet dyr.
Når du vurderer en løsning, bør du måle den mod samme faste krav hver gang. Så bliver det tydeligt, om du ser på reel disaster recovery eller blot en kopi uden plan.
wp-config.php, .htaccess og relevante systemfiler skal med.En stærk backup-strategi kombinerer automatisering, retention og ansvar. Google Drive eller Amazon S3 kan være sekundær lagring, men politikken skal også definere, hvem der tester restore, og hvor længe versioner gemmes.
Teknikken alene er ikke nok. En god strategi beskriver, hvilke websites der er kritiske, hvor hurtigt de skal op igen, og hvor meget data virksomheden kan tåle at miste. Det svarer til RTO og RPO, som bør være besluttet før første driftsfejl, ikke midt i den.
Hvis sitet er et leadsite, kan 24 timers restore være acceptabelt. Hvis det er en webshop, er en halv dags nedetid ofte for dyr. Her giver hyppigere backup, staging og hurtig restore klar værdi, selv om prisen er lidt højere.
Nogle enkle kontrolpunkter gør strategien markant stærkere:
En komplet WordPress backup indeholder altid database og filer, herunder wp-content, uploads, temaer, plugins, wp-config.php og ofte .htaccess. Hvis e-mail ligger samme sted som sitet, bør den også indgå, ellers gendanner du kun halvdelen af driften.
For mange WordPress-sites ligger den største værdi i databasen. Her ligger indhold, brugere, formularindsendelser, plugin-indstillinger og ofte også ordredata. Samtidig er det i filsystemet, at temaer, mediefiler og specialtilpasninger bor. Begge dele skal passe sammen tidsmæssigt.
På mere komplekse sites skal du også tænke på specialtabeller. WooCommerce, LMS-løsninger og medlemsplugins bruger egne tabeller eller metadata i stor stil. Hvis disse ikke kommer med, får du et site, der ser rigtigt ud, men ikke fungerer korrekt.
En almindelig misforståelse er, at en databaseeksport alene er en fuld backup. Det er den ikke. Omvendt behøver du heller ikke gemme cachefiler, sessions og midlertidige filer, hvis de kan genskabes. Det er netop her en moden løsning skiller sig ud: den tager det vigtige med og lader støjen blive.
Hosting-backup er normalt stærkest til hastighed og restore, mens plugins som UpdraftPlus og Duplicator giver mere kontrol. Valget afhænger af ansvar: vil du selv styre lagring og versioner, eller vil du have backup som en integreret driftsydelse?
Plugin-baseret backup passer godt, hvis du vil definere egne workflows og selv vælge lagring i Dropbox, S3 eller Google Drive. Hosting-baseret backup er ofte bedre, hvis du vil have stabil drift, mindre serverbelastning og én ansvarlig partner ved restore.
| Kriterium | Plugin-backup | Hosting-backup |
|---|---|---|
| Opsætning | Mere fleksibel | Hurtigere at komme i gang |
| Belastning på server | Kan være mærkbar på store sites | Ofte håndteret uden for live-miljøet |
| Restore | Afhænger af plugin og erfaring | Typisk hurtigere via panel |
| Off-site muligheder | Meget stor valgfrihed | Afhænger af udbyder |
| Ansvar | Ligger hos dig eller bureauet | Ligger mere hos hosten |
Hvis du driver forretning på WordPress, er den vigtigste afvejning ofte ikke pris, men hvor hurtigt du kan gendanne sikkert. Her står managed løsninger som Hostious, Kinsta og WP Engine typisk stærkere end gør-det-selv-opsætninger.
En backup er først troværdig, når restore er testet i staging eller på et separat miljø. WordPress Toolkit og WP-CLI gør testen hurtigere, men selv et simpelt panel-restore er nok, hvis du verificerer indhold, login og ordredata bagefter.
Trin 1 er at vælge et restorepunkt og gendanne til et sikkert testmiljø. Brug staging, hvis hosten tilbyder det. Hvis ikke, så brug et lukket subdomæne eller en lokal kopi.
Trin 2 er at kontrollere de kritiske funktioner. Kan du logge ind? Virker kontaktformularer? Er seneste ordre, bruger eller side med? På WooCommerce skal du også kontrollere ordrestatus, betalingsflow og e-mails.
Trin 3 er at dokumentere resultatet. Notér, hvor lang tid restore tog, hvilke trin der krævede manuel indsats, og om noget manglede. Pro tip: Test lige efter større ændringer i tema, plugin-stack eller PHP-version. Det er dér, skjulte restore-problemer viser sig.
Lokal backup er hurtig, off-site backup er sikker mod serverfejl, og Cloud backup giver skalerbar retention. Amazon S3 og Google Drive er stærke valg, men 3-2-1-reglen er stadig den bedste tommelfingerregel.
Lokal backup betyder, at kopien ligger tæt på produktionen, ofte på samme host eller samme datacenter. Det giver hurtig adgang, men beskytter dårligt mod hardwarefejl, ransomware eller konto-kompromittering.
Off-site backup ligger fysisk eller logisk adskilt fra produktionen. Cloud backup er en praktisk form for off-site backup, men kun hvis den faktisk er uafhængig. Hvis samme kompromitterede konto kan slette både site og backup, er uafhængigheden svagere, end mange tror.
| Type | Fordel | Ulempe | Bedst til |
|---|---|---|---|
| Lokal | Hurtig restore | Risiko ved samme fejlzone | Hurtige snapshots |
| Off-site | Beskytter mod servertab | Kan være langsommere | Kritisk disaster recovery |
| Cloud | Skalerbar og fleksibel | Kræver styr på adgang og retention | Langsigtet lagring |
Den mest robuste model er 3-2-1: tre kopier af data, på to forskellige medier, hvor mindst én kopi er off-site.
Du bør gendanne selektivt, hvis skaden er afgrænset, og fuldt, hvis WordPress eller MySQL er kompromitteret. Hostious.io og andre managed platforme gør dette hurtigere, men rækkefølgen er altid vigtig: stop ændringer, vælg rent restorepunkt, verificér drift.
Først skal du fryse situationen. Sæt sitet i maintenance mode eller begræns adgangen, så nye ændringer ikke overskrives under restore. Hvis skaden skyldes malware, skal du vælge et restorepunkt fra før kompromitteringen.
Derefter vælger du restore-omfang. Hvis en editor kun har slettet indhold, kan database-restore være nok. Hvis et plugin eller en opdatering har ødelagt filstrukturen, skal filer og database ofte tilbage sammen. Hvis både WordPress og mail ligger samme sted, så vurder også mailrestore.
Til sidst verificerer du driften. Tjek frontend, backend, formularer, checkout og e-mail. Hvis du ser mærkelige fejl efter restore, er den typiske årsag mismatch mellem filer og database eller cache, der ikke er ryddet.
WooCommerce, LearnDash og medlemsplugins ændrer data hele dagen, så de kræver tættere databasebackup end et præsentationssite. Hvis der kommer ordrer eller tilmeldinger hvert kvarter, er daglig backup ganske enkelt for grov.
En webshop har sjældent kun ét sandt datalag. Ordrer, lager, kundekonti, kuponer og transaktionslogs kan ligge i både kerne-tabeller og plugin-specifikke tabeller. Derfor skal backup-løsningen kunne håndtere høj databaseaktivitet uden at gøre sitet mærkbart langsommere.
Her er den klassiske afvejning tydelig. Jo hyppigere backup, jo mindre datatab ved fejl. Til gengæld stiger kravene til lagring, I/O og restore-disciplin. En managed platform med hyppige snapshots giver ofte bedre økonomi end et tungt plugin-setup, når sitet omsætter forretning direkte.
Et godt pejlemærke er dette: Hvis du ville ringe til kunder ved tab af data, så er backup-frekvensen for lav.
De fleste backup-fejl handler ikke om teknologi, men om antagelser. cPanel og WordPress kan begge vise, at backup er kørt, mens restore stadig fejler, fordi filer mangler, retention er for kort, eller kopien ligger samme sted som produktionen.
Fejlene er kendte, og de går igen på tværs af bureauer, webshops og interne marketingteams. Den gode nyhed er, at de kan fjernes med enkle krav og faste tests.
Det stærkeste krav, du kan stille, er enkelt: Vis mig ikke bare, at backup findes. Vis mig, at den kan gendannes hurtigt, fuldt og til det rigtige tidspunkt.
Tjenester
Tilmeld dig vores nyhedsbrev