En melding om at «backup er inkludert» sier nesten ingenting om hvor mye data dere kan miste, hvor lenge kopiene beholdes eller hvor raskt nettsiden kan gjenopprettes. En god plan begynner med virksomhetens behov og ender med en test som viser at planen virker.

Backup er ikke det samme som synkronisering

Disse mekanismene kan være nyttige, men løser ulike problemer:

MekanismeHva den hjelper medViktig begrensning
SikkerhetskopiGjenopprette data og systemtilstand fra et tidligere tidspunktMå være komplett og mulig å lese tilbake
SynkroniseringHolde to steder oppdatertSletting og skade kan synkroniseres til begge steder
VersjonskontrollHistorikk for kode og tekstfilerInneholder ofte ikke database, opplastinger eller hemmeligheter
SnapshotRask kopi av et lagringsvolum eller en tjenesteKan være bundet til samme konto, region eller leverandør
EksportFlyttbar kopi av utvalgte dataKan mangle design, konfigurasjon eller relasjoner

Bruk gjerne flere av dem, men ikke kall en synkronisert mappe eller et Git-repositorium en komplett sikkerhetskopi av nettstedet uten å kontrollere resten av systemet.

Bestem hvor mye data og nedetid dere tåler

To spørsmål styrer resten av løsningen:

  • RPO, recovery point objective: Hvor langt tilbake kan dere måtte gå, og hvor mye nytt arbeid eller nye data kan gå tapt?
  • RTO, recovery time objective: Hvor lenge kan nettsiden være utilgjengelig før konsekvensen blir uakseptabel?

Hvis en nettbutikk maksimalt kan miste 15 minutter med bestillinger, holder ikke én daglig databasekopi. Hvis en enkel informasjonsside endres fire ganger i året og kan være nede noen timer, kan en mindre omfattende løsning være forsvarlig.

Skriv målene som konkrete grenser:

Maksimalt datatap: 4 timer
Maksimal gjenopprettingstid: 2 timer
Oppbevaring: daglige kopier i 30 dager, månedlige i 12 måneder
Test: full gjenoppretting hvert halvår

Dette er eksempler, ikke standardkrav. Virksomheten må velge tall ut fra innhold, transaksjoner, lovkrav og konsekvensen av bortfall.

Kartlegg alt som må kunne gjenopprettes

En nettside er ofte mer enn filene som vises i nettleseren. Kartlegg minst:

  • kildekode eller publisert side
  • database og innholdsregister
  • bilder, dokumenter og andre opplastinger
  • tema, maler og egne tilpasninger
  • konfigurasjon av hosting, bygg og publisering
  • omdirigeringer, skjemainnstillinger og planlagte jobber
  • nødvendige lisenser og versjonsoversikt
  • DNS-poster og tredjepartsintegrasjoner
  • fremgangsmåte for å hente hemmeligheter fra et sikkert lager

Passord og API-nøkler bør ikke spres ukryptert i backupfiler. Sikkerhetskopier konfigurasjonen som trengs, men la hemmelighetene ligge i en egnet passord- eller nøkkeltjeneste med egen beredskap.

En statisk nettside som kan bygges på nytt fra versjonskontroll har et annet behov enn WordPress eller en nettbutikk. Se den separate guiden til sikkerhetskopi av WordPress for filer, database og praktisk gjenoppretting i WordPress.

Velg frekvens etter endringstakten

«Daglig backup» er ikke automatisk riktig. Frekvensen må være kortere enn det akseptable datatapet og må dekke hver datakilde.

EndringEksempel på vurdering
Nye ordre eller reservasjoner hele dagenDatabasekopi eller transaksjonslogg langt oftere enn daglig
Daglig publiseringMinst én kopi etter eller mellom publiseringsøktene
Ukentlige innholdsendringerKopi etter endring og før tekniske oppdateringer
Kode som bygges fra GitRepositoriet beskytter kodehistorikken, men ikke nødvendigvis data og driftsoppsett

Overvåk at jobbene fullføres. En automatisk jobb som har feilet stille i tre måneder er bare en falsk trygghet.

Beskytt kopien mot samme hendelse som originalen

En angriper med administratortilgang prøver ofte å slette eller kryptere sikkerhetskopiene før produksjonsdataene. En kopi i samme hostingkonto med samme administratorrettighet er derfor ikke uavhengig nok for alle risikonivåer.

NSM anbefaler at produksjon og sikkerhetskopi har egnede skiller i nettverk, domene og rettigheter og at tidligere kopier beskyttes mot overskriving og manipulering.

Vurder:

  • separat konto eller leverandør for minst én kopi
  • egne driftsbrukere og tofaktorautentisering
  • skrivebeskyttelse eller uforanderlig oppbevaring
  • kopi i en annen fysisk region når konsekvensen tilsier det
  • kryptering under overføring og lagring
  • varsling ved sletting, endret policy eller mislykket jobb
  • begrenset tilgang til personopplysninger i kopiene

Klassifiser innholdet før dere sender kopier til en skytjeneste. Backupen kan inneholde kundedata, skjemainnsendinger og andre personopplysninger som omfattes av de samme sikkerhets- og databehandlerkravene som produksjonssystemet.

Oppbevar flere tidspunkter

Én overskrevet «siste kopi» beskytter dårlig mot feil som oppdages sent. Skadevare, en feilkonfigurasjon eller slettet innhold kan ligge ubemerket i uker.

En oppbevaringsplan bør angi:

  • hvor mange korte intervaller som beholdes
  • hvor lenge daglige, ukentlige og månedlige kopier lagres
  • når kopier slettes av personvern- eller kostnadshensyn
  • hvem som kan endre eller forkorte perioden
  • hvordan dere finner siste kjente, rene tidspunkt ved et angrep

Lengre oppbevaring er ikke alltid bedre. Den øker lagringskostnad og kan beholde persondata lenger enn nødvendig. Begrunn perioden.

Kopier som lagres på samme webhotell kan også fylle både disk- og filkvoten og dermed hindre neste backup. Følg guiden til lagringsplass, inodes og trygg opprydding hvis forbruket vokser uten kjent årsak.

Test hele gjenopprettingen

En filkontroll eller grønn status viser bare at noe ble skrevet. En full test viser om nettsiden kan tas tilbake i drift.

Testen bør måle:

  1. hvor lang tid det tar å finne riktig kopi
  2. om en ny, ren konto eller server kan brukes
  3. om database, filer og konfigurasjon passer sammen
  4. om domenet kan kobles til den gjenopprettede tjenesten
  5. om innlogging, skjema, søk, betaling og e-post virker
  6. om tilgangsnøkler må roteres etter en sikkerhetshendelse
  7. om faktisk RPO og RTO holder målene

NSM anbefaler å øve og måle gjenoppretting periodisk fordi prosessen ofte tar mer tid enn virksomheten forventer.

Dokumenter testen, avvikene og neste forbedring. Bruk den detaljerte protokollen for test av backup og gjenoppretting når dere skal planlegge øvelsen. En plan som bare finnes hos leverandøren hjelper lite hvis leverandørkontoen samtidig er utilgjengelig.

Spør leverandøren før dere kjøper

Be om skriftlige svar på:

  • Nøyaktig hvilke data inngår?
  • Hvor ofte tas kopiene?
  • Hvor lenge beholdes hver versjon?
  • Er kopien skilt fra produksjonen med egne rettigheter?
  • Kan kunden laste ned en portabel kopi?
  • Hvem kan starte gjenoppretting, og hva koster det?
  • Hvor lang tid forplikter leverandøren seg til å bruke?
  • Hvordan varsles en mislykket jobb?
  • Når ble full gjenoppretting sist testet?
  • Hva skjer med kopiene ved oppsigelse eller leverandørsvikt?

Et uklart svar som «backup tas jevnlig» kan ikke sammenlignes med et definert intervall, en oppbevaringsperiode og en dokumentert gjenopprettingstid.

Sikkerhetskopi i Vymos standardtilbud

Vymos publiserte standardtilbud for én enkel nettside spesifiserer foreløpig ikke fast sikkerhetskopifrekvens, oppbevaringsperiode eller selvbetjent gjenoppretting. Vi lover derfor ikke disse egenskapene som en del av standardtilbudet.

Hvis nettsiden er kritisk eller har data som endres løpende, må krav til kopi, eksport, oppbevaring og gjenoppretting avklares skriftlig før bestilling. Beskriv behovet for drift og beredskap , eller se hva som faktisk er inkludert i den enkle nettsiden med hosting .

Trenger bedriften en enkel nettside?

Vi lager én enkel nettside for bedriften og inkluderer hosting de første 12 månedene.