Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 11. november 2005.
Backup-rutinerne hos virksomheder og organisationer kører i døgndrift. Investeringen ses som en forsikring mod it-mæssige katastrofer. Men når katastrofen alligevel sker, er det ikke altid, forsikringen holder. Det sker nemlig hyppigt, at restore-processen fejler.
Virksomhederne har stort fokus på backup, men for lidt fokus på restore-processen, lyder meldingerne fra leverandørside. Men kunderne er tavse.
Når uheldet for alvor er ude, og data skal genskabes, ender virksomheden ofte med store problemer. Restoreprocessen mislykkes. Der skal flere forsøg til, og ikke sjældent tabes der data i processen.
Sådan lyder meldingen fra en række af de it-selskaber, der via deres leverance af backuphardware og -software har fingeren på pulsen. Samme melding høres fra konsulenthuse, der bliver tilkaldt, når restore-processen er fejlet.
Hvor hyppigt det går galt, er der mange forskellige bud på. Hos lagringsgiganten EMC nævner administrerende direktør Kurt Bager en undersøgelse fra Enterprise Strategy Group, der har fokus på lagring og informationsstyring. Analysehuset siger, at 60 procent af backup-job fejler, hvilket også fortæller, hvor mange procent af restore-jobbene, der fejler.
Hos en anden lagringsgigant, StorageTek, lyder budet fra administrerende direktør Nils Kierkegaard på "mindst 50 procent", og det samme siger Mogens Nørgaard, teknisk direktør hos Miracle, der typisk optræder som troubleshooter, når der er problemer med Oracles database eller Microsofts SQL server.
De gør dog opmærksom på, at tallene gælder de tunge restoreopgaver - dem, der følger et nedbrud eller en "korrumperet" database. Tallene gælder ikke genskabelse af en enkel fil, som hr. Jensen ved en fejl fik slettet sidste torsdag.
At få en vurdering af restoreproblemet fra den anden side er overmåde svært, erfarer Computerworld. De it-ansvarlige lægger låg på, hvis det er muligt. Hvem har for eksempel hørt om den store danske eksportvirksomhed, der for nylig måtte slås i tre uger for at få sine data genskabt?
Da Københavns Politikreds blev ramt i maj, var det særdeles synligt, da politiet ikke kunne bruge sine vigtigste systemer. Hos Danske Bank, der står for de mest omtalte restore-problemer i nyere tid, kunne der heller ikke lægges låg på.
Jesper Matthiesen, administrerende direktør for B4restore, som overvåger backup og restore for 50 større virksomheder, giver følgende bud på tavsheden:
- Backup og restore betragtes som grundlæggende discipliner, som it-organisationen skal have styr på. Alt andet er pinligt. Det er mere acceptabelt at fortælle om nedbrud, der skyldes angreb udefra såsom virusangreb.
En af landets mest garvede mænd på backup- og restore-fronten, Symantecs Per Larsen, tilføjer, at mister virksomheden tilmed data i forbindelse med restoreprocessen, sænkes jerntæppet for alvor.
Per Larsen, der har titlen principal systems engineer, begyndte at arbejde med backup og restore tilbage i 1994. Da skete det med produkter fra it-selskabet Open Vision, der udviklede backupsoftware. Firmaet blev opkøbt af Veritas, som nu er opkøbt af Symantec, der dermed er blevet verdens største leverandør af backup-software. Nogle af problemerne skyldes, at restore-erfaringer hurtigt ruster, påpeger Per Larsen. De bliver i sagens natur aldrig daglig rutine.
Han nævner en lang række typiske årsager til, at restore går galt eller ikke nås på den tid, der er til rådighed:
• Der kan være tale om en banal fejl på en slidt backup-tape, så informationerne ikke kan læses. Båndet kan også ved en fejltagelse være blankt, men ingen har tjekket, om data også blev overført.
• Backup-løsningen, der passede systemerne og data for 12 måneder siden, er ikke blevet opdateret med, hvad der er tilføjet eller har ændret sig siden.
• Ofte har kunden ikke taget højde for, at hvis en central server bryder sammen, er det ikke nok blot at reinstallere det oprindelige operativsystem samt restoreapplikationer og produktionsdata. Der vil typisk være sket modifikationer i kernen af operativsystemet netop med henblik på at afvikle applikationerne.
• Hvis serveren er kaput, så der skal købes en ny, koster den godt nok typisk mindre end den døde server og kan det dobbelte, men der er også tale om en ny arkitektur, som ikke harmonerer med backuppen af operativsystemet.
• Backup-værktøjet går ud fra, at databasen er lukket, men den kører fortsat online og opdateres. Ved restore mangler der konsistens, da backuppen opdateres med transaktioner, som er registreret i den periode, hvor backuppen blev taget.
• Restore-processen tager lang tid, især for servere med backup af brugernes harddiske, da de typisk rummer mange små filer. Her baseres backup typisk på brug af RAID-5 (redundant array of inexpensive disks) "layout", hvilket giver en hurtig backup, men langsom restore.
Kunder undlader typisk at regne på restore-tider, fortæller Per Larsen. Hurtig backup tæller mest. Den ubehaglige sandhed viser sig først, når det er gået galt.
- I visse tilfælde kan stopuret være overflødigt. Så er det afrivningskalenderen, der gælder, siger Per Larsen galgenhumoristisk. Han peger på tre klassiske årsager til databaseproblemerne, der er de værste:
• Der er sket en fejl i databaseapplikationen, så data ikke længere er intakt. Her er der dog typisk databaseværktøjer, der kan håndtere situationen.
• Nogle er kommet til at gøre noget med databasen, de ikke skulle have gjort. Her kan man typisk nøjes med at restore den berørte del af databasen.
• Hardwaren, som databasen kører på, går i stykker. Her er konsekvenserne alvorlige.
Hans vigtigste budskab er, at restoredelen er det essentielle.
- Som en kollega engang sagde: Man kommer ikke til at svede af at tage backup, men kan godt få behov for en ren undertrøje, hvis man ikke kan restore, siger Per Larsen.
Alligevel kniber det med forståelsen for alvoren hos kunderne, mener StorageTek-direktør Nils Kierkegaard:
- Det er min oplevelse, at flertallet af danske virksomheder lukker øjnene for de potentielle risici, siger direktøren og fortsætter:
- I nogle tilfælde er det it-chefen, der vurderer, at det ikke er realistisk at bede direktionen om midler til denne type projekter, og derfor lever direktionen i lykkelig uvidenhed om, hvor udsat deres forretning i virkeligheden er.
- I andre tilfælde er det direktionen, der aktivt afviser at investere i de "forsikringspræmier", som it-chefen anbefaler. Der er fokus på besparelser på it-budgettet, og kun investeringer med hurtigt og synligt forretningsudbytte går igennem.
Boks:
Vi har talt med
• Regnar Knudsen, it-driftschef, Bestseller.
• Kurt Bager, administrerende direktør, EMC.
• Nils Kierkegaard, administrerende direktør, StorageTek.
• Jesper Matthiesen, administrerende direktør, B4restore.
• Poul Erik Johansen, landechef, Hitachi Data Systems.
• Mogens Nørgaard, teknisk direktør, Miracle.
• Per Larsen, principal systems engineer, Symantec/Veritas.
• Peter Nielsen, leder af backup og disaster recovery, Munk IT.
Boks:
Når uheldet er ude...
Det kan gå galt med restore af mange forskellige årsager. Nogle hændelser er kendte, mens andre aldrig kommer frem.
Danske Bank stod i centrum for den værste, kendte sag. Den 10. marts 2003 blev banken ramt af et nedbrud, forårsaget af en fejl i udskiftningen af strømforsyningen i en ældre lagringsenhed. 90 databaser blev lammet. Først den 17. marts var alle systemers databaser på plads igen.
I hele perioden var banken ude af stand til at udbetale penge, så Nationalbanken måtte træde til med overførsler af milliardbeløb.
Den lange restoreproces skyldtes ikke lagringsenheden, men en række fejl i DB2-databasen fra IBM. Alene internt blev regningen for katastrofen på ti millioner kroner, og dertil kom erstatninger til ramte kunder.
Blot fem måneder tidligere var banken også ramt i flere dage grundet fejl i håndteringen af et IBM-lagringssystem. Fem mainframes i bankens Brabrand-center måtte opgive ævred, men Brøndby-centret blev ikke ramt, hvorfor en række systemer klarede skærene. Men bankens 450.000 netbankkunder måtte i nogle dage opgive at "gå" i banken.
Banken har siden outsourcet sin drift - og dermed også backup og restore - til IBM.
Politiet blev ramt i maj i år. En softwareændring med relevans for Københavns Politikreds resulterede i, at systemet gik ned. Først efter fem dage lykkedes det at få genetableret data, men ikke alle. Ifølge politiet, der får kørt sine it-opgaver hos CSC, var der tale om en fejl i Oracle-databasesoftwaren.
Politiet kørte på en så gammel version af databasen, at leverandøren for længst havde ophørt med supporten.
De følgende eksempler er ikke bredt kendt, hvorfor virksomhederne er anonymiseret.
En opgradering af firmware på database-serverne fik hele virksomhedens SAN (Storage Area Network) til at gå ned, inklusive en del databaser. Det viste sig, at der ikke var taget korrekt backup af databaserne.
Det tog tre uger at få lavet restore og recovery af miljøet, og det har ikke været uden økonomiske mén for kunden.
Der opstod brand i serverrummet hos en dansk produktionsvirksomhed. Intet stod til at redde. Desværre havde virksomheden arkiveret sine backup-tapes i et skab i serverrummet, så de brændte også.
Firmaet måtte taste alt ind om kunder, ordrer og alt andet ud fra, hvad man havde journaliseret på papir. Det tog 14 dage, og it-stoppet kostede millioner på bundlinjen.
En virksomhed blev "bombet" 14 dage tilbage, hvad e-mails angår. Alle indgående mails var gået tabt, heriblandt ordrer. Maildatabasen var korrumperet, men ingen opdagede det under backup. Da det omsider blev opdaget, og man ville restore data, måtte man 14 dage tilbage for at finde en ukorrumperet backup.
