Backup

En backup er en kopi af de data og filer, der skal bruges for at genskabe en hjemmeside eller webshop. På WordPress betyder det normalt både installationsfiler, temaer, plugins, uploads og den database, hvor sider, indstillinger, brugere og ordrer ligger.

En backup er ikke det samme som høj oppetid eller god sikkerhed. Hosting kan være stabil, og siden kan stadig blive ødelagt af en fejlbehæftet opdatering, menneskelig fejl eller kompromitterede loginoplysninger. Backup er det sikkerhedsnet, der gør en kontrolleret gendannelse mulig.

Det er også vigtigt at skelne mellem backup og synkronisering. Hvis en mappe spejles automatisk, kan en slettet eller krypteret fil blive fjernet i begge kopier. En rigtig backup bør have historik, så en tidligere tilstand kan vælges.

Behovet afhænger af sidens aktivitet. En enkel virksomhedshjemmeside ændrer sig måske kun ugentligt. En webshop kan modtage ordrer og lagerændringer hvert minut. Frekvensen skal derfor følge, hvor meget data virksomheden kan tåle at miste.

Backup bliver først rigtig værdifuld, når ansvar, placering og gendannelsesvej er kendt. “Webhotellet tager nok en kopi” er ikke en plan. Virksomheden bør vide, hvem der gør hvad, hvor langt historikken går, og hvordan en kritisk gendannelse startes.

Kortlæg først de dele, løsningen består af. På WordPress er database og wp-content typisk centrale, men specialintegrationer, miljøvariabler, licensnøgler og serverkonfiguration kan også være nødvendige. Dokumentér hvad der ikke automatisk følger med.

Vælg en passende rytme. En almindelig hjemmeside kan tage daglig backup og ekstra kopi før større ændringer. En travl WooCommerce-butik kan have brug for hyppigere databasebackups, så tabet af nye ordrer bliver begrænset.

Opbevar mindst én kopi separat fra den server, der beskyttes. Hvis både den aktive hjemmeside og alle backups ligger på samme konto, kan en kontoovertagelse eller serverfejl ramme det hele. En ekstern lagring med begrænset adgang giver et ekstra lag.

Brug versionshistorik. En fejl bliver ikke altid opdaget samme dag. Hvis malware har ligget skjult i tre uger, hjælper syv dages historik ikke meget. Afvej længere opbevaring mod datamængde, pris og krav til persondata.

Tag en manuel backup før opdatering af kerne, tema eller WordPress-plugin. Test større ændringer i et stagingmiljø, men husk at staging ikke er en permanent backup. Det er en arbejdskopi, som også kan gå i stykker.

Test gendannelse efter en fast plan. En backupfil kan være korrupt, ufuldstændig eller låst til et bestemt værktøj. En prøvegendannelse på et isoleret miljø viser, om filer, database, login og centrale funktioner faktisk kommer tilbage.

En webshop får installeret en opdatering mandag klokken 10. Kort efter begynder checkout at fejle. Webhotellet har natlig backup fra klokken 02, men butikken har modtaget 37 ordrer siden da. En fuld tilbagerulning vil derfor fjerne nye forretningsdata.

Fordi virksomheden har separat databasebackup hver time, kan udvikleren først tage en kopi af den nuværende fejlramte løsning, derefter gendanne filerne fra før opdateringen og bevare de relevante nye ordredata. Arbejdet kræver stadig forsigtighed, men datatabet bliver mindre.

Efter gendannelsen flyttes opdateringen til staging. Fejlen viser sig at være en konflikt mellem temaet og et plugin. Den løses og testes, før ændringen igen kommer på live. Backuppen gjorde ikke fejlen umulig; den gjorde konsekvensen håndterbar.

Virksomheden opdaterer samtidig sin procedure: Hvem tager beslutningen om rollback, hvor ligger adgangene, og hvordan kontrolleres betaling, e-mail og lager efter gendannelse? Det er lige så vigtigt som selve backupfilen.

Guiden om hvad et CMS er kan give ikke-tekniske medarbejdere en bedre forståelse af, hvorfor indhold og filer ligger forskellige steder, og hvorfor begge dele skal med.

Den mest alvorlige faldgrube er aldrig at teste kopien. En planlagt backupjob kan fejle på grund af lagerplads, adgangsrettigheder eller timeout, mens dashboardet stadig ser normalt ud. Kontrollér både log og indhold.

En anden fejl er kun at tage backup af filer. WordPress-sider, indstillinger, formularposter og WooCommerce-ordrer ligger primært i databasen. Uden den kommer designet måske tilbage, men ikke den levende forretning.

Pas på at overskrive den eneste gode kopi. Når en fejl undersøges, bør den aktuelle tilstand først gemmes separat, også selv om den er defekt. Den kan indeholde nye ordrer, logs eller spor, der er nødvendige for at løse problemet.

Backupfiler indeholder ofte persondata og adgangsoplysninger. De skal beskyttes, krypteres hvor relevant og slettes efter en fast politik. Et åbent link til en databasekopi kan være en større risiko end selve driftsfejlen.

Endelig kan en ukritisk fuld gendannelse skabe nye problemer. På en aktiv butik kan den fjerne ordrer, lagerbevægelser eller kundekonti. Beslutningen skal tage højde for, hvilke data der er ændret siden kopien.

To begreber bruges ofte i backupplaner: RPO beskriver, hvor meget data virksomheden kan tåle at miste, mens RTO beskriver, hvor længe løsningen må være utilgængelig. En webshop kan eksempelvis kræve kortere RPO end en statisk firmaside.

WordPress anbefaler backup før opgraderinger. Det er en fornuftig minimumsvane, men den løbende plan bør ikke kun afhænge af, hvornår nogen husker at trykke på opdater.

En server-snapshot kan være hurtig at gendanne, men den bør forstås i forhold til udbyderens setup. Nogle snapshots omfatter hele serveren, andre kun bestemte diske. Spørg præcist, hvad der er inkluderet.

På WooCommerce kan ordredata ændre sig konstant. Brug løsninger og processer, der tager højde for høj aktivitet, og vær forsigtig med at importere en gammel database oven i en nyere uden en plan.

Efter en gendannelse skal mere end forsiden testes. Kontrollér login, formularer, e-mails, betaling, lager, søgning, integrationer, cache og eventuelle planlagte opgaver. En side kan se rigtig ud og stadig være defekt.

Backup bør indgå i aftalen med hosting eller leverandør. Beskriv frekvens, retention, placering, ansvar og gendannelseshjælp. Så bliver forventningerne konkrete, før en kritisk situation opstår.

Skriv de første fem handlinger ned: stop ændringer, gem den aktuelle tilstand, identificér tidspunktet for fejlen, vælg kopi og afgør hvem der godkender gendannelsen. Den rækkefølge dæmper panik.

Gem kontaktoplysninger og adgange sikkert, så de kan findes uden den ramte hjemmeside. En supportside på samme server hjælper ikke, hvis hele kontoen er utilgængelig.

Efter gendannelse dokumenteres årsag og løsning. Var det et plugin, en brugerfejl eller et angreb? Beredskabet bør justeres, så samme hændelse bliver mindre sandsynlig og lettere at håndtere.

En backupplan er god, når en anden ansvarlig kan følge den. Hvis alt kun findes i én udviklers hukommelse, er løsningen stadig sårbar.

Dokumentationen bør navngive systemerne, backupfrekvensen, opbevaringsperioden og den eksterne placering. Skriv også om kopien er fuld, inkrementel eller kun omfatter bestemte dele.

Angiv hvem der modtager fejlbeskeder. Et backupjob, der fejler i tre måneder uden modtager, er i praksis ingen plan. Varsler bør føre til en konkret handling og kunne ses af mere end én person.

Beskriv gendannelsen i den rækkefølge, den skal udføres. Medtag DNS, database, filer, cache, e-mail og integrationer, hvis de er relevante. Screenshots og præcise navne er bedre end “gendan siden som normalt”.

Notér hvor ofte prøvegendannelse udføres, og hvad testen skal kontrollere. En succesbesked fra værktøjet er ikke nok; siden skal kunne åbnes, og de kritiske funktioner skal virke.

Når leverandør eller hosting ændres, skal backupplanen gennemgås igen. Gamle kopier kan ligge på en konto, som snart lukkes, mens den nye løsning endnu ikke har opbygget tilstrækkelig historik.

Ved et leverandørskifte bør virksomheden få en afsluttende, dokumenteret kopi og kontrollere, at den kan åbnes. Aftal også hvornår den tidligere leverandør sletter sine kopier og adgange.

Den nye leverandør bør ikke antage, at gamle backups fortsætter. Etabler den nye rytme fra første driftsdag, og lav en test, før historikken fra den gamle løsning udløber.

Selv en mindre firmaside har brug for en gendannelsesvej. Forskellen ligger mest i, hvor ofte data ændres, og hvor hurtigt driften skal tilbage – ikke i om backup er relevant.