per lolk bloghoved

Remote backup har ingen sammenhæng med remote recovery

VMware er lige kommet med en rapport, der konkluderer, at en disaster recovery-plan skal implementeres FØR uheldet sker. ”Selvfølgelig!”, tænker du måske. Men det er bare slet ikke en selvfølgelighed ude i danske virksomheder. Rigtig mange virksomheder har kun implementeret backup og har ikke skænket recovery-planer en tanke. Eller de har muligvis skænket det en tanke, men har skubbet det fra sig igen, fordi det virker uoverskueligt at opstille de katastrofescenarier, man kunne komme ud for, hvis ens systemer brød ned. For slet ikke at tale om at lave planer for, hvad man så skulle gøre hvornår, og hvor lang tid det ville tage at komme op at køre igen, hvis uheld af større eller mindre karakter skulle være ude.

Når jeg støder på virksomheder, der får kørt remote backup, er situationen tit endnu værre: Her adopterer man som regel helt ukritisk den backup-politik, som remote backup-leverandøren foreslår. Og man tager det uden at blinke for givet, at leverandørens recovery-plan virker.

Nu forholder det sig bare sådan, at man godt kan outsource dét at tage backup, men man kan ikke outsource ansvaret for, at det rent faktisk kan lade sig gøre at restore data og komme i luften med sine systemer, når uheldet indtræffer. Jeg er i hvert fald aldrig stødt på en remote backup-kontrakt, der dækker alle tab, hvis leverandøren ikke kan restore data i forlængelse af nedbrud.

Så der er mig bekendt ikke mange, der har prøvet at lave en komplet restore ud fra remote backup’ede data, og det er rent faktisk den eneste måde, man kan finde ud af, OM det overhovedet kan lade sig gøre, og ikke mindst hvor lang tid det tager.

Det, man som minimum skal lave, er planen for, hvad man vil gøre, hvis uheldet er ude. Hvis man ikke vil teste fra den ene ende til anden, bør man i hvert fald afprøve, om man kan reetablere de mest vitale systemer. Derudover bør man teste, hvilken restore-hastighed man egentlig kan forvente fra sin leverandør. For én ting er den teoretiske makshastighed på ens linje eller det netværk, der forbinder én til backup-serveren. En anden er, hvordan leverandørens isenkram er bestykket. Det er jo ikke sikkert, det er kraftigt nok til at kunne levere samtlige de nødvendige data.

Det andet, man skal huske at tage stilling til, er, hvilke scenarier man kunne forestille sig at restore fra. Det kan være dagligdags ting, som at en bruger har slettet en fil eller en mail. Eller det lidt værre scenarie, at man har lavet en fejl i en database og gerne vil have databasen reetableret. Og så er der worst case scenario, hvor alt brager ned, og hele systemet skal reetableres.

Rigtig mange steder, hvor man får kørt remote backup, ved man ikke, hvad leverandørens politikker går ud på. Og der, hvor man anvender leverandørernes standard-backup-politikker, indeholder de som oftest kun fem eller helt ned til to versioner af kundernes data.

Når vi er ude hos en virksomhed og opdager, at der kun er gemt fx to versioner af data, er det, når vi skal installere et andet backup- system. Pludselig fylder backup’ede data markant mere, for vi anbefaler generelt, at man gemmer mindst 14 versioner, fordi de fleste gerne vil kunne reetablere data 14 dage tilbage. For alle kan blive enige om, at hvis man mister data, så vil man bare gerne have det sidste, der virkede, tilbage! Men problemet er, at hvis man kun har to versioner, så har man kun to dage til overhovedet at opdage, man mangler data. Er der gået tre dage, er lige præcis de ønskede data måske væk!

Eller endnu værre: Man har en database, og en udvikler sletter ved en fejl en tabel, der indeholder data, man kun bruger en gang om måneden, fx i forbindelse med fakturering eller afskrivning på anlægsaktiver. Hvis der så er gået mere end to dage, siden tabellen blev slettet, og man kun har gemt to versioner, ja så er data endegyldigt tabt.

Man kunne også forestille sig, at man fredag morgen modtager en mail inficeret med mallware. Det bliver ikke opdaget med det samme, fordi ens antivirusprogram endnu ikke kender lige præcis denne type mallware. Så går man på weekend. Og mandag morgen møder man ind og opdager, at ens antivirus hen over weekenden endelig har detekteret mallwaren. Men nu er det jo tre dage siden, man havde en sund mailstore, så hvis ikke ens antivirusprogram er i stand til at fjerne virus, så har man en virusinficeret mailstore, uden mulighed for at kunne komme tilbage til den sunde via ens backup-data.

Så mine råd er:

  • Stil krav – også til remote backup-leverandørerne.
  • Få overblik over virksomhedens recovery-muligheder.
  • Tænk over, om I kan leve med disse recovery-muligheder, hvis uheldet skulle være ude.
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Knud Jensen

Undrer mig lidt over hvilken type backup du hentyder til i artiklen. Er det en komplet backup hver gang, eller en komplet backup én gang med inkrementelle tilføjelser?

Må ærligt sig jeg ikke aner hvilken type backup der er på kritiske systemer på min arbejdsplads. Men hver PC kan få rullet et nyt image ud på cirka 15 minutter, og der er en generel politik om at data ikke må opbevares på PC'erne, men i stedet i de systemer som kommunen/staten har pålagt os at bruge.

2 til 14 dage tilbage i tiden lyder for mig som værende meget kort mulighed for at reagere.

Privat har jeg en komplet backup hvert halve år, og daglig inkrementel backup. Selv efter et halvt år med daglig inkrementel backup synes jeg ikke det fylder alverden.

  • 0
  • 0
#2 Brian Hansen

"You dont backup, to backup. You backup, to restore." Jeg har kvartalsvise afviklinger af disaster recovery planen. Alt lige fra restore af enkelte filer, til hele virtuelle servere, SQL, mail, restore til baremetal, you name it. Mange klager over de mangler tid til den slags, men så bør man få sine prioriteter på plads.

  • 7
  • 0
#3 Joe Sørensen

En del af en katastrofeplan er også underholdning af kunder.

Hvis det er lukkes dig at få en kundes system til at gå ned vil de uden tvivl forsøge at kontakte dig. Hvis din virksomhed har succes betyder dette typisk at nu er dit telefon system også nede, fordi den bliver overlæsset med opkald.

Derfor at det meget rart at have email adresse på nøglepersoner hos kunderne så man kan skrive til dem. Det er bare lidt svært at maile kunder, hvis adresserne ligger i CRM systemet, som bruger samme SAN som email systemet, hvis det er det SAN der er nede.

Hvis sådan en situation kan opstå, så vær klar med nogle adresselister og en alternativ vej til at sende mange mails. Overvej eventuelt muligheden for at have en ekstern hjemmeside, som I kan henvise til. Og sørg for at denne eksterne side faktisk kan holde til at have besøg af alle kunder samtidig.

  • 0
  • 0
#4 Jens Jönsson

Jeg er i hvert fald aldrig stødt på en remote backup-kontrakt, der dækker alle tab, hvis leverandøren ikke kan restore data i forlængelse af nedbrud.

Det giver vel sig selv. Remotebackup leverandøren har jo ikke nogen som helst mulighed for at vide om det data du tager backup af er validt. En backup er i princippet intet andet end en kopiering af noget data. Jeg har da ofte oplevet at der er taget backup af data der har været "defekt". F.eks. en defekt database, hvor de data der lå i backuppen var korrupte og dermed ubrugelige, når de først blev restoret. Systemet kunne sagtens læse dataerne og filerne, men pga. diskfejl, var indeholdet af dem reelt ubrugelige.

For én ting er den teoretiske makshastighed på ens linje eller det netværk, der forbinder én til backup-serveren. En anden er, hvordan leverandørens isenkram er bestykket. Det er jo ikke sikkert, det er kraftigt nok til at kunne levere samtlige de nødvendige data.

Hvis det store uheld er ude, så er det vel de færreste der forventer at de kan hive de flere hundrede GB data ned over deres Internetforbindelse. Hvis din remote backup leverandør ikke har mulighed for at kopiere data ud til dig på en harddisk og smide den afsted med kurér, så ville jeg da personligt vælge en anden leverandør.

  • 1
  • 0
#5 Micki Pedersen

Hvis det store uheld er ude, så er det vel de færreste der forventer at de kan hive de flere hundrede GB data ned over deres Internetforbindelse. Hvis din remote backup leverandør ikke har mulighed for at kopiere data ud til dig på en harddisk og smide den afsted med kurér, så ville jeg da personligt vælge en anden leverandør.

Hvis vi kun taler en så lille datamængde at det måles i GB, og man har fx 1gbit forbindelse hele vejen, så burde det vel snildt kunne klares remote. Det er her ikke båndbredden der er flaskehalsen, men leverandørens evne til at kunne udtrække data tilbage til en dato hurtigt i et fornuftigt format (herunder hive data frem fra backupmedierne, processere incremental og levere over en egnet protokol), samt selvfølgelig din evne til at kunne reetablere systemerne, når du har fået data tilbage. Sidstnævnte er nok som regel den største hurdle.

Med VM's er det vel nemmere at reetablere hosts, men hvor nemt kan folk få fx. 100 servere i et prod miljø reetableret, hvor alle diskene står af på samme tid (lad os sige pga fejlstrøm, oversvømmelse eller brand) eller det centrale SAN'et slår fejl og alle data eller dele heraf bliver korrupte (begge to grelle eksempler).

Interessant emne. :)

  • 0
  • 0
#7 Per Lolk

De backupsystemer vi bruger, er TSM eller Veeam, og de tager begge to en fuld backup første gang og herefter laver man inkremental backup. Jeg er da enig i, at 14 dage ikke er meget, men hvis man vil lave backup længere tilbage, er det noget man henter fra arkiv. Det vil i sagens natur tage længere tid, med det kan både ledelsen og resten af organisationen typisk bedre acceptere, fordi arkiverede data er mindre vigtige for den daglige drift, end data fra de seneste 14 dage.

Derudover slår Dilbert filmen jo hovedet meget godt på sømmet i forhold til, hvorfor ikke alle har en disaster recovery plan og ikke får den testet jævnligt :)

  • 0
  • 0
Log ind eller Opret konto for at kommentere