Hovedformålet med backup/recovery-løsningene er å tilby en metode for å gjenopprette data som av en eller annen grunn har gått tapt eller blitt skadet. Systemet lar brukeren (i de fleste tilfeller administrator) gjenopprette dataene slik de var på et spesifikt tidspunkt.
Backup lagres på disk og/eller tape. Ofte skrives de først til en disk før de lagres på tape utenfor huset for langtidslagring. Sikkerhetskopier bør oppbevares atskilt fra produksjonsanlegget for å sørge for katastrofesikring av dataene.
Det finnes utvidelsesmoduler for backup/recovery systemer som kan integreres med de fleste vanlige applikasjoner og databaser.
Hvorfor?
Når man utformer en backup/recovery-løsning, er det viktig å ta hensyn til kravene til RPO (Recovery Point Objective, gjenopprettingspunktet), RTO (Recovery Time Objective, gjenopprettingstiden) og SLA (Service Level Agreement, serviceavtalen) før man velger hvilke metoder som bør brukes.
Recovery Point Objective – RPO (gjenopprettingspunkt)
RPO er det tidspunktet (før det oppstår feil) du må kunne gjenopprette dataene fra, og som er definert av forretningsvirksomheten.
RPO kan uttrykkes som "hvor mye data man har råd til å miste i tilfelle svikt/katastrofe". Dette er den datamengden som har endret seg mellom feilsituasjonen og siste sikring av data, f.eks. backup eller speil.
Null er en gyldig verdi og tilsvarer krav om "null datatap". Dette krever synkron speiling av data, eller tilsvarende sikring.
Recovery Time Objective – RTO (gjenopprettingstid)
Hvor lenge kan vi tillate at en eller flere applikasjoner eller systemer er utilgjengelig?
RTO kan defineres som den lengste ønskelige perioden som er nødvendig for å gjenopprette en eller flere tjenester og deres tilhørende data til riktig, driftsmessig stand. Null er også en gyldig verdi her. Det betyr at data må ligge på disk, tilgjengelig for servere i ”produksjonsformat”, og ikke i backupformat. Det krever også at servere er i en klynge (kanskje strukket over to lokasjoner) og automatisk failover. Hvor oppdaterte disse data er, sier RTO ikke noe om. Det er det RPO som definerer.
LAN-backup
Dette er den vanligste måten å sikkerhetskopiere data på. Metoden er velkjent og støtter så godt som alle kommersielle operativsystemer på markedet. Løsningen er rimelig enkel å innføre og administrere. Alle serverne har en backup-agent installert, og dataene blir overført via nettverket (LAN´et) til backupserveren. Det kan anbefales å bruke et eget backupnettverk. Ytelsen på backup og gjenoppretting er vanligvis begrenset til båndbredden på nettverket eller ytelsen på serveren som er eier av dataene.
LAN-uavhengig backup
Denne metoden kalles også SAN-backup. Med denne fremgangsmåten har serverne en server-/lagringsnode installert i stedet for den vanlige backup-agenten. Det gjør det mulig å overføre data direkte fra serveren til backupenheten (disk eller tape) uten å bruke LAN. Fordelene med denne metoden er bedre ytelse på backup og gjenoppretting. Metoden benyttes på servere som inneholder store datamengder, og/eller til driftskritiske systemer som krever rask gjenoppretting.
Snapshot-basert backup
Med snapshot-baserte backupløsninger er det mulig å eliminere den tradisjonelle backup-programvaren. En av de største fordelene med dette alternativet er at man kan kjøre backup oftere, for eksempel hver time i steden for bare hver kveld. Det anbefales på det sterkeste å replisere snapshotene til et sekundært system, for å unngå å miste data i tilfelle katastrofer. Denne teknikken krever lagringssystemer som kan ta imot og lagre mange snapshots uten at det går ut over ytelsen.
Dette kan kombineres med programvaremoduler som integrerer applikasjonen (f.eks. MS SQL) med snapshot teknologien i lagringssystemet. Man sørger da for konsistente databaser, noe som gir rask og sikker tilbakelegging. Lagringssystemer med effektiv snapshot-teknologi kan ha mange snapshot pr. volum, og dermed mange generasjoner av datamengden på disk.