Backup er ikke beredskap før nettsiden er gjenopprettet og testet
En backupfil gir falsk trygghet hvis ingen vet hvordan den skal gjenopprettes. Slik bygger dere en praktisk og testbar plan for nettsiden.
De fleste profesjonelle driftsmiljøer tar backup. Det betyr likevel ikke at nettsiden kan gjenopprettes raskt når noe går galt. Backupen kan være ufullstendig, databasen kan være tatt på et annet tidspunkt enn filene, eller gjenopprettingen kan avhenge av én person som ikke er tilgjengelig.
Den nyttige testen er derfor ikke om driftsleverandøren kan vise en liste over sikkerhetskopier. Spørsmålet er om virksomheten kan få tilbake en fungerende nettside, med riktige data og nødvendige integrasjoner, innenfor et akseptabelt tidsrom.
En planlagt gjenopprettingstest gjør backup til reell beredskap. Samtidig avdekker den svakheter i hosting, dokumentasjon, tilgangsstyring, overvåking og teknisk vedlikehold.
Start med å definere hva som faktisk skal reddes
En nettside består sjelden bare av filer og en database. Den kan ha mediebibliotek, skjemaoppføringer, produktdata, ordre, søkeindekser, cache, DNS-oppsett, sertifikater og koblinger mot eksterne systemer.
Lag først en oversikt over komponentene som må være på plass for at nettstedet skal fungere. For et vanlig WordPress-nettsted kan dette blant annet være:
- WordPress-filer, temaer og utvidelser
- Database med innhold, brukere og innstillinger
- Bilder, dokumenter og andre opplastede filer
- Konfigurasjon for webserver og PHP-miljø
- DNS, sertifikater og videresendinger
- Skjemaer, e-postutsending og lagrede henvendelser
- Integrasjoner mot CRM, økonomisystem eller andre tjenester
- Cache-regler og CDN-konfigurasjon
For en nettbutikk må listen også omfatte ordre, lagerstatus, betalingsflyt, fraktoppsett og automatiske meldinger. En gjenopprettet forside er ikke nok dersom kundene ikke kan fullføre et kjøp.
Avklar hvor mye data dere kan miste
To spørsmål bør avklares med ledelsen og systemeier før driftsmiljøet velges eller backupplanen utformes.
Hvor gamle kan de gjenopprettede dataene være?
Hvis backup tas én gang i døgnet, kan data som er opprettet etter siste sikkerhetskopi, gå tapt. For en enkel informasjonsside kan det være akseptabelt. For en nettbutikk med løpende ordre eller en tjeneste som mottar viktige skjemaer, kan det være et alvorlig problem.
Behovet bør bestemmes av hvor ofte data endres og hvilke konsekvenser et tap får. Hyppigere backup er ikke automatisk riktig løsning for alle, men intervallet må være et bevisst valg.
Hvor lenge kan nettstedet være utilgjengelig?
Det er forskjell på å ha en backup og å kunne bruke den raskt. Nedlasting, klargjøring av server, import av database, kontroll av konfigurasjon og funksjonstesting kan ta tid. Hvis gjenopprettingen krever manuelle avklaringer eller tilgang fra flere leverandører, øker tidsbruken ytterligere.
Avtal derfor en realistisk målsetting for hvor raskt nettstedet skal være tilbake. Prioriter gjerne de viktigste funksjonene først. En midlertidig løsning med fungerende kontaktinformasjon kan være bedre enn å vente på at alle mindre funksjoner blir perfekte.
Test gjenoppretting i et isolert miljø
En gjenopprettingstest skal normalt ikke utføres direkte på produksjonsmiljøet. Opprett et separat testmiljø som i størst mulig grad ligner den tekniske plattformen nettstedet faktisk bruker.
Testmiljøet bør ha kompatibel serverkonfigurasjon, database og nødvendige programvarekomponenter. Hvis produksjonen bruker spesielle cachelag, bakgrunnsjobber eller bildelagring, må dette tas med i vurderingen.
En praktisk test kan gjennomføres slik:
- Velg et konkret gjenopprettingstidspunkt og registrer hvilken backup som skal brukes.
- Opprett et tomt, isolert driftsmiljø.
- Gjenopprett filer, database og nødvendige konfigurasjoner.
- Bytt midlertidige adresser og miljøinnstillinger uten å påvirke produksjonen.
- Deaktiver reelle betalinger, e-postutsendinger og eksterne oppdateringer.
- Kontroller innhold, funksjoner, integrasjoner og administrative tilganger.
- Dokumenter tidsbruk, feil, mangler og manuelle avhengigheter.
- Oppdater rutinen og gjennomfør en ny test når vesentlige feil er rettet.
Testen bør utføres av personene som faktisk skal håndtere en hendelse. Hvis rutinen bare fungerer når den opprinnelige utvikleren leder arbeidet, er virksomheten fortsatt sårbar.
Kontroller mer enn at forsiden åpner seg
En vellykket innlasting av forsiden sier lite om nettstedet som helhet. Bruk en fast kontrolliste basert på de viktigste brukerreisene og forretningsprosessene.
For et bedriftsnettsted kan kontrollen omfatte navigasjon, søk, kontaktskjema, filnedlastinger, innlogging og publisering. For en nettbutikk bør dere i tillegg teste produktvisning, handlekurv, utsjekk, betaling i testmodus, ordrebekreftelse og administrasjon av ordre.
Se også etter mindre synlige feil:
- Manglende bilder eller dokumenter
- Feil i interne videresendinger
- Planlagte oppgaver som ikke kjører
- Skjemaer som ser ut til å virke, men ikke leverer data
- Integrasjoner som bruker produksjonsnøkler i testmiljøet
- Brukere eller roller som mangler
- Feil tidssone eller serverinnstillinger
Noter hvilken backup som ble brukt, hvem som utførte testen, hvor lang tid hvert trinn tok, og hvilke avvik som ble funnet. Da kan neste test sammenlignes med den forrige.
Cache og CDN kan skjule feil
Cache og CDN er viktige for ytelse og stabilitet, men kan gjøre en gjenoppretting vanskeligere å vurdere. En mellomlagret side kan vises selv om den gjenopprettede applikasjonen eller databasen ikke fungerer riktig.
Under testen bør dere derfor kontrollere nettstedet både med og uten relevante cachelag. Tøm cache på en kontrollert måte, og verifiser at dynamiske sider henter oppdaterte data. For nettbutikker gjelder dette særlig handlekurv, kasse, kundesider og lagerstatus.
Avklar også hvem som har tilgang til å endre CDN- og DNS-oppsett under en hendelse. Hvis disse tilgangene ligger hos en tidligere ansatt eller en ukjent underleverandør, kan gjenopprettingen stoppe selv om backupen er intakt.
Overvåking må bekrefte at tjenesten virker
Tradisjonell oppetidsovervåking sjekker ofte bare om serveren svarer. Et nettsted kan returnere en side og samtidig ha ødelagte skjemaer, tomme produktlister eller feil i betalingsflyten.
Etter en gjenoppretting bør overvåkingen kontrollere funksjonene som betyr mest for virksomheten. Det kan være at en bestemt side inneholder forventet innhold, at et testskjema kan behandles, eller at en sentral integrasjon svarer korrekt.
Varslene må dessuten ha en tydelig mottaker. En overvåkingsmelding som havner i en ubemannet innboks, gir liten beskyttelse. Definer hvem som vurderer varselet, hvem som kan gjøre tekniske endringer, og når saken skal eskaleres.
Backupen må være beskyttet mot samme hendelse
Hvis backup og produksjon ligger i samme miljø med de samme administrative tilgangene, kan én feil eller kompromittert konto ramme begge. Det bør finnes kopier som er logisk eller fysisk adskilt fra produksjonen, og sletting av backup bør kreve strengere kontroll enn vanlig drift.
Tilgang til sikkerhetskopier må begrenses fordi de kan inneholde personopplysninger, kundedata, interne dokumenter og tekniske hemmeligheter. Kryptering og tilgangslogging er derfor en del av backupstrategien, ikke et tillegg.
Oppbevaringstiden bør samsvare med behovet. Mange korte intervaller hjelper ved ferske feil, mens eldre kopier kan være nødvendige dersom en feil eller uønsket endring oppdages sent. Samtidig må virksomheten unngå å oppbevare persondata lenger enn nødvendig.
Vedlikehold endrer forutsetningene
En gjenopprettingsrutine blir utdatert når nettstedet endres. Nye utvidelser, integrasjoner, serverkomponenter og publiseringsløsninger kan innføre avhengigheter som ikke finnes i den gamle planen.
Backup og gjenoppretting bør derfor vurderes ved større tekniske endringer. Det gjelder særlig flytting av hosting, bytte av CDN, nye betalingsløsninger, endret lagring og større oppgraderinger.
Før risikofylte vedlikeholdsoppgaver bør dere ta en fersk backup og kontrollere at den kan brukes. Etter endringen bør nettstedets kritiske funksjoner testes, og overvåkingen følges tettere i en avtalt periode.
Bruk gjenopprettingstesten når dere velger driftsmiljø
Ved valg av hosting er det lett å sammenligne lagringsplass, kapasitet og pris. Gjenopprettingsevnen gir ofte et bedre bilde av hvor profesjonell driften faktisk er.
Be leverandøren beskrive hele prosessen: hva som sikkerhetskopieres, hvor ofte det skjer, hvor kopiene lagres, hvem som kan starte en gjenoppretting, og hvordan resultatet kontrolleres. Avklar også om gjenoppretting er inkludert i avtalen, eller om det faktureres som ekstraarbeid.
Det viktigste er ikke at leverandøren lover at backup finnes. Dere trenger en løsning som er tilpasset nettstedets endringstakt, dataverdi og akseptable nedetid.
Gjør testen til en fast driftsoppgave
En gjenopprettingstest bør gjennomføres regelmessig og etter vesentlige endringer i nettstedet eller driftsmiljøet. Hyppigheten må tilpasses risikoen. Et nettsted med daglige transaksjoner trenger tettere kontroll enn en statisk informasjonsside som sjelden oppdateres.
Plasser ansvaret hos en navngitt rolle, ikke bare hos leverandøren generelt. Ledelsen eller systemeieren bør få en kort rapport med tidspunkt, brukt backup, faktisk tidsbruk, testede funksjoner, avvik og planlagte tiltak.
Da blir backup mer enn en avkrysset funksjon i hostingpakken. Den blir en testet beredskap som viser hvor raskt virksomheten kan komme tilbake i normal drift når noe faktisk svikter.
