Disaster recovery plan

Proaktiva förslag till din katastrofplan

Dokumentation

En genomgång av rutinerna vid nödsituationer varje kvartal är en proaktiv strategi i en katastrofplan. Nyckelpersoner bör vara uppdaterade om teknisk dokumentation av primära affärssystem. Detaljerad dokumentation som beskriver figurationer av programvaror och hårdvara ska vara tillgängliga för rätt personer i rätt tid.

Microsoft Exchange Server Redundancy

Om ditt företag till exempel använder Microsoft Exchange – finns det en restore server på plats för att kunna starta en återställning från en backup utan dröjsmål? Alla versioner av Exchange lagrar loggfiler i «Information store» databasen. Även om en ”Circular Logging” kan spara lagringsplats, måste man under en katastrof ha en komplett uppsättning av loggfiler för att kunna göra en restore av «Information store.

Arkiverad data på backupband

En katastrofplan bör innehålla lagring av säkerhetskopior på en annan fysisk adress. Tape-backup kräver en plan för validering av innehållet på banden. Det är bra att ha som vana att testa säkerhetskopior med jämna mellanrum. Tape-rotation bör ske regelbundet och konsekvent och man måste hela tiden säkerställa god kvalitet på media för att inte oönskade läsfel ska uppstå.

RAID System

När katastrofer drabbar RAID lagringssystemer, SAN-systemer, JBOD systemer, og NAS-systemer, bör katastrofplanen innehålla åtgärder även för dessa trots att de har redundancy-arkitektur. Det inbyggda skyddet mot dataförluster innebär ibland en falsk trygghet och det är lätt att glömma de risker som ändå kvarstår.

Ett exempel är när Ibas hjälpte en kund med 40TB lagringsplats fördelat på 20 servrar. Dessa system hade hardware RAID 1+ 0 konfigurationer. Problemen startade på en server när en hårddisk tillfälligt gick offline. Kontrollkortet växlande till en spegelkopia som en del av redundancy processen. Plötsligen gick den första disken online igen. Kontrollkortet bytte tillbaka till den ursprungliga disken vilket resulterade i inkonsekvent data från ett volym- och filsystemsperspektiv. Efter att systemet stängts av och startats om, återställdes också hårdvarukonfigurationen. Operativsystemets automatiska reparationsprocess startade och det skapade ytterligare problem i filsystemets integritet och kunden fick inte längre tillgång till sina data.

Vi löste problemen och räddade situationen genom tjänsten Remote Data Recovery tjeneste.

Detta fall är intressant just på grund av den serie fel som inträffade i snabb följd efter varandra. Kunden lagrar stora datamängder som förändras kontinuerligt under tre arbetsskift per dygn. Att ta backup på en sådan föränderlig miljö varje kväll var inte möjligt. Kunden var övertygad om att säkerheten i systemet var ”hundra procentig” på grund av spegling.

Dessa lösningar är naturligtvis väldigt bra när diskar kraschar, men i det här fallet kraschade inte hårddisken, den försvann bara tillfälligt för att sedan dyka upp igen helt okontrollerat. När den gjorde det blev det problem i filsystemet eftersom den inbyggda säkerheten i systemet inte tog höjd för ett dylikt scenario. Ingen räknar med att en ”död” disk ska kunna vakna till liv igen av sig själv men sådant sker ibland. Som ett resultat försvann allt när det automatiska reparationsverktyget kördes.

Se vad som hände när IT-chefen på ett sjukhus skulle utöka kapaciteten på en filserver som användes av hundratals människor och som innehöll känsliga patientdata.

Det är viktigt att planera inför det värsta och öva på en korrekt ”första hjälpen insats”. Ibas hjälper gärna till när planen ska upprättas, vi vet utifrån vår erfarenhet inom dataräddning vilka fallgropar du ska undvika och vilka tänkbara situationer du ska planera för. Är du ordentligt förberedd så kommer du att göra rätt när katastrofen är ett faktum och på sätt sparar du enormt mycket tid och arbete. Rätt åtgärder i rätt ordning kan vara avgörande för verksamhetens framtid och de som inte har en plan kan i många fall gå i konkurs på grund av att data inte kan räddas.