Både under angrepet på World Trade Center i 2001 og i New Orleans i 2005 ble flere datasenter ødelagt. Men dette er vel noe som kun skjer i USA tenker mange. Vår backup er sikker nok. Er den virkelig det?

Under storflommen i Gudbrandsdalen for noen år siden hadde flere bedrifter sine IT-avdelinger og servere langs den oversvømte elva. Lynnedslag og feil med elektriske anlegg har flere ganger satt fyr på lokaler der bedriftene har sine servere. I følge Aftenposten 28.8. 2005 mangler 5 av 10 småbedrifter og 7 av 10 større bedrifter backup av virksomhetskritisk data.

I følge StorageTek Research har vi i hovedsak følgende årsaker til nedetid:

• 40% driftsfeil
• 40% hardware feil
• 12% software feil
• 5% katastrofer
• og 3 % andre årsaker.

Undersøkelser viser at det er planlagt nedetid som er den vanligste årsaken til nedetid. Tidligere kunne man godt arbeide med en restore i løpet av natta, bare ting var i orden 08:00 på morgenen. Nå skal systememene være i drift 24/7, altså hele tiden.

En undersøkelse gjennomført av Eagle Rock Alliance i USA skulle måle hvor lang tid amerikanske bedrifter kunne klare seg uten IT-systemer før det ble kritisk for driften.

Tid uten IT-systemer:

• 40% kunne klare seg 4-5 dager uten IT
• 36% kunne klare seg et 2-3 dager
• 17% kunne klare seg 4-8 timer uten datasystemene sine
• 7% av bedriftene ville ha store tap og kanskje konkurs ved 0-1 timer nedetid.

Backuptips for IT-ansvarlige

Minimer nedetiden
Jeg skal ikke ta for meg alt vi kan gjøre for å hindre at systemene går ned. Jeg vil konsentrere meg om backup/restore biten. Hvordan gjør vi nedetiden minst mulig?

Backup er viktig, men ikke eneste løsning. Om backuptapen enda ligger i samme bygg eller i nærheten av serverene vil denne kunne bli ødelagt i en katastrofe. Så man må som mange vet sørge for at bakuptape blir lagret et stykke unna på et sikkert sted.

Vi kan jo også replikere data til en ekstern lokasjon, men da har vil ulempen med replikering. Om det blir korrupte data på en lokasjon vil disse korrupte data bli replikert. En løsning på dette kan være forsinket replikering slik at man har litt tid på seg til å hente tilbake frisk data om den orginale skulle bli korrupt.

StorageTek L1400M tape library med støtte for inntil 678 taper.

Information Lifecycle Managment
En forkortelse som er mye brukt innen datalagring om dagen er ILM, Information Lifecycle Managment. Dette er rett og slett en strategi for hvordan man skal lagre data.

Trenger vi backup av alt hver dag? Vi kan sammenligne med huset vi bor i. Det vi ikke bruker kan vi sette inn på en bod eller opp på loftet. Statiske data som vi aldri/sjelden bruker trenger vi ikke å ta backup av hver dag. Det er bortkastet tid siden disse dataene ikke forandrer seg uansett.

Om vi f.eks har et CRM system der man ofte er inne å endrer på kunder et par måneder for så å sjelden eller aldri redigere på dem igjen, kan vi oppbevare data i tre måneder på vanlige diskløsninger med 4 timer recoverytid på backup. Etter tre måneder kan vi flytte data til en annen lagringsløsning der vi oppbevarer den i 1 år med 1 dags recoverytid. Så kan vi fortsette med å flytte data enda “lenger inn på oftet”. Der oppbevares det i tre med 3 dager recoverytid før det til slutt kan legges over til tape som oppbevares i 5 år med en ukes frist for recovery.

En skisse over ILM-strategien.

Når ulykken er ute og vi må legge tilbake mye data fra backup vil det i dagens samfunn ofte ikke være tilstrekkelig å gå tilbake til nattens backup. Vi må også ha tilbake data fra tiden etter forrige backup. Derfor blir løsninger for kontinuerlig backup stadig mer populære. Man tar backup kontinuerlig og setter inn recovery punkt ofte slik at man har faste punkter å gå tilbake til. For eksemel backup recovery punkt for 20 minutter siden.

Husk rask recovery
Men med all den nye teknologien for å ta backup av mye data på kort tid bør vi alikevel tenke strategisk og huske på at dette skal raskt tilbake om ulykken skulle komme. Hvor lang tid en recovery operasjon tar er noe av det viktigste å tenke på når man lager planer for ulykker.

Så lag en nøyaktig strategi over hva som er foretningskritisk å få opp raskt ved en ulykke og husk å få med alle nye servere i backuprutiner. Med en katastofeplan klar kan du slappe litt mer av.

Og til slutt, en ulykke kommer sjelden alene. Ha planer for verst tenkelig scenario.