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.