En backup er først verdifull når den kan gjenopprettes

Kategori: Hosting og drift

Mange virksomheter får en daglig bekreftelse på at backupen er gjennomført. Det gir trygghet, men bekrefter bare at en prosess har kjørt. Det sier ikke nødvendigvis om alle nødvendige data er med, om kopien kan leses, eller om noen faktisk klarer å gjenopprette nettsiden innen akseptabel tid.

En realistisk test av gjenoppretting er derfor en sentral del av profesjonell webhosting og drift. Testen avdekker avhengigheter som ellers først blir synlige under en driftsstans: manglende tilgang til domenet, feil databaseversjon, eksternt lagrede mediefiler, utdaterte integrasjonsnøkler eller en CDN-konfigurasjon ingen lenger har oversikt over.

Start med å definere hva dere skal kunne gjenopprette

«Vi tar backup av nettsiden» er for upresist som driftskrav. En moderne nettside består vanligvis av flere deler som må fungere sammen:

• Filer, programkode, temaer og utvidelser
• Database med innhold, brukere, innstillinger og transaksjoner
• Bilder, dokumenter og andre opplastede filer
• Serverkonfigurasjon, miljøvariabler og planlagte oppgaver
• DNS, sertifikater, CDN-regler og cacheoppsett
• Integrasjoner mot skjemaer, betaling, logistikk, CRM eller andre systemer
• Tilganger og nødvendig teknisk dokumentasjon

Ikke alt trenger samme backupmetode. DNS kan være dokumentert og eksportert, mens databasen må kopieres ofte. Store mediearkiver kan ligge i separat objektlagring med egen versjonering. Poenget er at helheten må kunne bygges opp igjen uten at teamet må gjette seg frem.

Bestem hvor mye nedetid og datatap dere tåler

Før testen bør virksomheten ta stilling til to praktiske spørsmål: Hvor lenge kan nettsiden være utilgjengelig, og hvor mye data kan gå tapt?

For en enkel informasjonsside kan noen timers nedetid og ett døgn med tapte redigeringer være håndterbart. For en nettbutikk kan samme hendelse bety tapte bestillinger, uklar lagerstatus og omfattende manuelt etterarbeid.

Formuler kravene konkret. Et eksempel kan være at en ordinær bedriftsnettside skal kunne gjenopprettes innen fire timer, med maksimalt 24 timers tap av innhold. En nettbutikk kan trenge langt hyppigere databasekopier og kortere gjenopprettingstid. Kravene bør bygge på konsekvensene for virksomheten, ikke bare på hva hostingpakken tilbyr som standard.

Gjennomfør testen i et isolert driftsmiljø

En restore-test bør normalt ikke utføres direkte i produksjonsmiljøet. Opprett i stedet et isolert testmiljø som ligner produksjon mest mulig. Det bør ha tilsvarende teknisk plattform, programvare, database og konfigurasjon.

Testmiljøet må samtidig sikres mot uønskede handlinger. E-postutsendelser bør blokkeres eller omdirigeres. Betalingsløsninger skal settes i testmodus. Integrasjoner som kan opprette kunder, ordrer eller supportsaker må kobles fra eller erstattes med trygge testendepunkter.

Et testmiljø som er svært forskjellig fra produksjon, kan gi falsk trygghet. Hvis produksjon bruker en annen database, PHP-konfigurasjon, lagringsløsning eller cachemekanisme, kan gjenopprettingen lykkes i testen og likevel feile under en reell hendelse.

En praktisk plan for restore-testen

1. Velg et tydelig scenario

Testen bør ta utgangspunkt i en konkret hendelse. Eksempler er sletting av hele serveren, ødelagt database, feil etter en oppdatering eller tap av tilgang til dagens hostingleverandør. Scenarioet avgjør hva dere faktisk må gjenopprette.

En full gjenoppretting til et nytt miljø gir vanligvis mer læring enn å rulle tilbake én fil på en eksisterende server. Den viser om virksomheten er avhengig av innstillinger og tilganger som bare finnes hos dagens leverandør.

2. Bruk en reell backup

Ikke lag en ny, spesielt tilrettelagt kopi rett før testen. Velg en backup fra den ordinære rutinen. Registrer tidspunktet den ble tatt, hvor den er lagret, og hvem som har tilgang.

Kontroller også om kopien ligger uavhengig av produksjonsmiljøet. En backup på samme server eller under samme kompromitterte administratorkonto kan forsvinne sammen med nettstedet.

3. Start klokken og dokumenter arbeidet

Mål tiden fra hendelsen oppdages til nettsiden er teknisk gjenopprettet og kontrollert. Noter hvor mye tid som brukes på å finne tilganger, laste ned data, opprette miljøet, importere databasen og rette konfigurasjon.

Dette gir et mer troverdig bilde enn leverandørens rene gjenopprettingstid. En database kan importeres på få minutter, mens avklaringer, DNS-endringer og funksjonstesting tar flere timer.

4. Gjenopprett hele løsningen

Legg tilbake programfiler, database og opplastinger. Konfigurer planlagte oppgaver, sertifikat, e-posttjenester og nødvendige integrasjoner. Kontroller at hemmelige nøkler og miljøvariabler håndteres sikkert, og ikke er skrevet inn i dokumentasjon som mange har tilgang til.

Dersom nettsiden benytter cache eller CDN, må dere vite hva som kan gjenbrukes og hva som må bygges på nytt. Tøm gammel cache når den kan inneholde feil eller utdaterte sider. Kontroller at CDN-et henter innhold fra riktig opprinnelsesserver, og at beskyttelsesregler og videresendinger fortsatt gjelder.

5. Test mer enn forsiden

At forsiden vises, betyr ikke at nettsiden er gjenopprettet. Test de viktigste brukerreisene og administrative funksjonene:

• Innlogging og tilgangsstyring
• Skjemaer og levering av henvendelser
• Søk, filtrering og nedlasting av dokumenter
• Publisering og redigering av innhold
• Handlekurv, kasse og ordrebehandling
• Betaling, lager og andre forretningskritiske integrasjoner
• Planlagte oppgaver og automatiske prosesser
• Logger, overvåking og varsling

Sammenlign også innholdet med tidspunktet backupen ble tatt. Da blir det tydelig hvor mange redigeringer, henvendelser eller transaksjoner som ville gått tapt.

Vanlige svakheter testen avdekker

En restore-test mislykkes sjelden bare fordi selve backupfilen mangler. Problemene ligger ofte rundt den:

• Databasen og filene er tatt på ulike tidspunkter og passer ikke sammen.
• Mediefiler ligger i en ekstern lagring som ikke omfattes av backupen.
• Backupen finnes, men ingen tilgjengelig medarbeider har rettigheter til å hente den.
• Gjenoppretting krever hjelp fra en leverandør uten avtalt responstid.
• Gamle kopier er beholdt for kort til å oppdage en gradvis feil eller skade.
• Nettsiden starter, men skjemaer, betaling eller planlagte oppgaver virker ikke.
• Overvåkingen peker fortsatt mot det gamle miljøet og bekrefter derfor ikke at den gjenopprettede løsningen fungerer.

Slike funn er ikke et tegn på at testen var mislykket. De er selve verdien av testen, så lenge feilene blir prioritert og rettet.

Bruk resultatet til å vurdere driftsmiljøet

Restore-testen gir et bedre grunnlag for å velge hosting enn en sammenligning av lagringsplass og prosessorkapasitet. Et profesjonelt driftsmiljø bør støtte den beredskapen virksomheten faktisk trenger.

Undersøk om leverandøren tilbyr separate og beskyttede sikkerhetskopier, hvor lenge de beholdes, og om enkeltfiler, databaser og hele miljøer kan gjenopprettes. Avklar også hvem som utfører jobben, hva slags responstid som gjelder, og om gjenoppretting er inkludert i driftsavtalen.

Tilgang til logger, testmiljø og overvåkingsdata er også viktig. Uten dette blir det vanskelig å bekrefte at den gjenopprettede løsningen er stabil. Virksomheten bør dessuten kontrollere hvem som eier og administrerer domene, DNS og CDN. Disse delene må kunne flyttes eller rekonfigureres selv om dagens servermiljø er utilgjengelig.

Gjør gjenoppretting til en fast driftsoppgave

En vellykket test er ferskvare. Nettsider endres gjennom nye integrasjoner, oppdateringer, innholdstyper og driftskomponenter. Testen bør derfor gjentas med et intervall som passer nettstedets risiko og endringstakt, og etter større endringer i arkitektur eller leverandør.

Fordel tydelig ansvar. Én person bør eie beredskapsplanen, mens teknisk leverandør kan ha ansvar for gjennomføring. Virksomheten må likevel delta i kontrollen av skjemaer, ordreprosesser og andre funksjoner som krever forretningskunnskap.

Etter testen bør dere sitte igjen med målt gjenopprettingstid, oversikt over faktisk datatap, dokumenterte avvik og en prioritert tiltaksliste. Da er backup ikke lenger bare en grønn statusmelding i et kontrollpanel. Den er en kontrollert og øvd del av nettsidens beredskap.