I løpet av de siste årene selve innholdet av datasenter sikkerhetskopier har utviklet seg til noe nesten ugjenkjennelig. I en ikke altfor fjern fortid, den aksepterte måten å utføre backup var å sette inn en haug med bånd til en tape magasin og la backup kjøre sent på kvelden. I dag er denne tilnærmingen sjelden et levedyktig alternativ. De fleste datasentre operere 24 timer i døgnet, noe som gjør konseptet med en nattlig backup foreldet.

I tillegg til tidspress, er det mange andre faktorer som endrer måten sikkerhetskopier må gjøres. Disse faktorene kjøre gamut fra utvinning tid målene til Service Level Agreements. På grunn av disse og utallige andre faktorer, har organisasjoner blitt tvunget til å vedta neste generasjons backup teknologier som snap shot sikkerhetskopier eller kontinuerlig databeskyttelse sikkerhetskopier. Atter andre har vedtatt en mye mer radikal tilnærming - rett og slett forlate begrepet sikkerhetskopier til sammen

Konseptet med backup oppgivelse har kommet for å bli kjent som null backup.. Den grunnleggende ideen bak null backup er at hvis du har nok redundans på plass så er det ikke behov for backup

Teknisk null sikkerhetskopier kan fortsatt sees på som backup -. Riktignok veldig utradisjonell seg. Tross alt, er en backup egentlig ikke noe mer enn en kopi av data som er lagret på et sikkert sted, slik at det kan gjenopprettes hvis noe noensinne skjer med den primære datakilden. Null sikkerhetskopier kan ikke innebære kopiering av data til tape eller andre backup medier, men redundans involvert i den underliggende arkitekturen sikrer at det finnes flere kopier av en organisasjons data. Derav null sikkerhetskopier kan fortsatt sees på som en form for backup.

Så hvordan gjør null backup fungere? Første gang jeg hørte om konseptet om et år siden med hensyn til Exchange Server 2010, men konseptet har siden utvidet til å omfatte andre serverprodukter. Likevel vil jeg snakke om null sikkerhetskopier fra en Exchange Server prospektiv siden null backup for Exchange har vært i bruk en stund.

Det som gjør null backup for Exchange Server mulig er en struktur kjent som en Database Tilgjengelighet Group. Database tilgjengelighet grupper er lik failover klynger i at de gir Exchange-postboksen servere med redundans og feiltoleranse. Faktisk database tilgjengelighet grupper selv er avhengige av Windows Failover Cluster Service. I motsetning til mange andre typer failover klynger imidlertid ikke Veksling Database Tilgjengelighet Grupper ikke stole på delt lagring.

Mangelen på delt lagring er en av nøklene til å gjøre null backup praktisk. I en klynge som er avhengig av delt lagring, kan lagrings selv (og dataene som er lagret i lagringsarray) blitt et single point of failure. I en database tilgjengelighet Group, er postboks databaser replikert blant klyngenoder.

De som er kjent med Exchange Server kan være raske til å påpeke at Exchange 2007 tilbudt database replikering evner så godt gjennom Lokal Continuous Replication og Standby Continuous replikering. Database tilgjengelighet grupper kan være tenkt som en neste generasjons kontinuerlig replikering løsning.

Cluster Continuous Replication distribusjoner vanligvis besto enten av tre klyngenoder eller to cluster noder og en fildeling vitne. I kontrast, kan en Exchange 2010 database tilgjengelighet gruppen omfatter opptil 16 postboksservere.

I de fleste tilfeller har seksten replikaer av en postkasse databasen vil være overkill, men antall postboks servere i en database tilgjengelighet gruppe gjør ikke nødvendigvis gjenspeiler antall kopi databaser. Grunnen til dette er enkel. Hver postkasse server er kapasitet til flere Exchange Server databaser. Exchange 2010 database tilgjengelighet grupper la deg vertsdatabaser lokalt på ethvert medlem av databasen tilgjengelighet gruppe, men de er også mulig å gjenskape noen database til noen database tilgjengelighet gruppemedlemmet som du velger. Replikering er gjort på en per databasenivå, ikke på en per server nivå. Det betyr at du står fritt til å gjenskape noen databaser og ikke andre eller å gjenskape ulike databaser til ulike medlemmer database tilgjengelighet gruppe.

Så hva betyr alt dette har å gjøre med null backup? I tilfelle av Exchange Server, er postboksen database replikering normalt konfigurert på en måte som gir størst fleksibilitet til katastrofe.

Selvfølgelig er det en forskjell mellom feiltoleranse og sikkerhetskopiering av data, slik at du kan lure hvordan database tilgjengelighet grupper kan lette ting som punkt i gang utvinning eller ekstern lagring.

Ekstern lagring er gjort mulig ved at en enkelt database tilgjengelighet gruppen er i stand til å strekke seg over datasentre. For eksempel, hvis organisasjonen hadde datasentre i Miami og Las Vegas så du kan opprette en enkelt database tilgjengelighet gruppe og inkluderer postboks servere fra begge steder. Du har kanskje noen Exchange-servere i Miami som normalt betjene brukere i Miami kontoret. De serverens postkasse databaser kan replikeres til Las Vegas datasenter for lagring. Likeledes Exchange-servere i Las Vegas kontoret inneholde trolig postkassene for brukerne i Las Vegas kontoret, men disse postboks databaser kan replikeres til Miami. I hovedsak kan hver postkasse server i databasen tilgjengelighet gruppe potensielt vert database kopier fra både Miami og Las Vegas. Du står fritt til å mikse og matche replikaer takt med behovet.

Selv offsite replikaer gi deg en måte å lagre en kopi av epost-serveren data offsite, er det fortsatt spørsmålet om tidspunkt utvinning. Anta for eksempel at en postkasse-databasen ble infisert med et virus. Skaden på databasen vil bli replikert til alle de andre database kopier. Så hvordan kan du gå tilbake databasen til et tidligere tidspunkt hvis du ikke gjør backup?

Exchange 2010 har en funksjon som kalles lagged eksemplarer. En lagged kopi er en database kopi som er satt opp slik at endringene ikke er umiddelbart forpliktet til databasen. For eksempel kan du sette opp en database replica med en forsinkelsestid på én dag. En annen kopi kan ha en forsinkelsestid på en uke. Hvis det utenkelige skulle skje så kan du bruke tilbakedaterte kopier for å gå tilbake til et tidspunkt før databasen korrupsjon noensinne skjedd.

Konklusjon

I denne artikkelen, jeg har vist deg hvordan database tilgjengelighet grupper kan tenkes å gjengi tradisjonelle backup unødvendig. Selv så må man spørre om dette og lignende teknologier virkelig gjøre unna med behovet for tradisjonelle backup.

Noen organisasjoner har faktisk forpliktet til å bruke null sikkerhetskopier. Slike organisasjoner har nok redundans på plass at de ikke føler seg som om de selv trenger for å lage sikkerhetskopier noe mer.

Personlig ville jeg være veldig nervøs for ideen om å gi opp mine sikkerhetskopier i favør av null backup . Selv om database tilgjengelighet grupper og lignende teknologier kan potensielt eliminere behovet for backup, har jeg jobbet i IT for lenge nok til å vite at noen ganger uventet skjer. Hvis en katastrofe noensinne gjorde det føre til tap av data, jeg kan ikke forestille å måtte forklare for min klient at deres data er borte fordi jeg valgte ikke å ta en sikkerhetskopi. For de som jobber i næringslivet, vil jeg tro at det ville være like ubehagelig å prøve å forklare til sjefen din at du ikke har noen backup. Anmeldelser