Kort svar: En gendannelse er et valg mellem tre præcisionsniveauer: fuld gendannelse (alt rulles tilbage – og alt nyt siden backuppen mistes), delvis gendannelse (kun filer ELLER kun database – ofte nok) og kirurgisk gendannelse (enkelte filer eller tabeller hentes ud af backuppen). På en webshop med løbende ordrer er reglen hård: rul ALDRIG hele databasen blindt tilbage – vælg det smalleste indgreb, der løser problemet, og gendan altid til et testmiljø først, hvis du er i tvivl.
Backup-marketing handler om at TAGE backups – men værdien afgøres den dag, du skal GENDANNE. Og dér opstår dilemmaet: backuppen er fra i nat, uheldet skete til middag, og siden da er der kommet tre ordrer, to kundeoprettelser og en blogkommentar. Denne guide lærer dig at gendanne præcist – så du reparerer skaden uden at slette virkeligheden.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Eksemplet i billedet er en illustration.
Diagnosen bestemmer indgrebet. En fejlet opdatering eller ødelagte filer er et fil-problem – databasen fejler intet. Slettede sider, en kørt-galt-import eller ødelagte indstillinger er et database-problem – filerne fejler intet. Kun totalskader (server død, dyb infektion, alt-er-væk) kræver fuld gendannelse. Stil spørgsmålet, FØR du åbner backup-panelet – det er hele forskellen på kirurgi og amputation.
Ordrer, kunder og lagertræk landede i databasen HELE tiden – også mens fejlen stod på. Ruller du databasen seks timer tilbage, forsvinder seks timers ordrer: kunderne har betalt, men shoppen kender dem ikke længere. Derfor: fil-problemer på en shop løses ALTID med fil-gendannelse alene; ægte database-skader håndteres kirurgisk (de ramte tabeller – aldrig ordre-/kundetabellerne blindt) – og er fuld database-gendannelse uundgåelig, skal ordrerne fra mellemperioden først eksporteres og genindlæses bagefter (betalingsgatewayens oversigt er facitlisten for, hvad der mangler). Ved databaseskader efter opdateringer gælder samme princip.
Er du i tvivl om backuppens indhold eller kvalitet, så gendan til et separat testmiljø (staging eller undermappe) og se efter: Er fejlen væk dér? Er indholdet komplet? Hvilket præcist tidspunkt er backuppen fra? Først derefter røres live – og med en frisk backup af det NUVÆRENDE (defekte) site først, så selv gendannelsen kan fortrydes. Testgendannelsen er i øvrigt også svaret på det årlige revisionsspørgsmål “virker vores backup?” – en backup, der aldrig er prøvet gendannet, er et håb, ikke en forsikring; kravene til en ordentlig opsætning står i backup-kravguiden, og på Hostious kører automatisk backup med gendannelse direkte fra panelet.
Gendannelsen er i mål, når den oprindelige fejl er væk, alt indhold og alle ordrer fra EFTER backup-tidspunktet stadig findes (afstem mod betalingsgatewayen på shops), og sitet fungerer ved en fuld gennemklikning. Notér i driftsloggen: hvad der gik i stykker, hvilket niveau der blev gendannet, og hvad tidsvinduet kostede. Og hvis øvelsen føltes som løben på line uden net – så er det opsætningen, ikke dig: backup med enkeltfils-gendannelse og staging gør næste gang triviel.
Det afhænger af aktiviteten: på en statisk side er en uge fint; på en travl shop er selv seks timer dyre. Deraf tommelfingerreglen: backup-frekvensen skal matche, hvor meget du har råd til at miste – daglig er minimum, hyppigere på shops.
Ja – præcis dét er den delvise/kirurgiske tilgang: gendan filerne (eller de ramte tabeller), og lad ordre- og kundetabellerne stå urørt. Kræver det alligevel fuld database-gendannelse, eksporteres dagens ordrer først og genindlæses bagefter.
På Hostious, ja – panelet gendanner selv (fuldt eller pr. fil), og supporten hjælper med de kirurgiske indgreb, hvor præcisionen afgør alt. Sig hvad der gik i stykker og hvornår – så finder vi det smalleste indgreb sammen.
