Disaster recovery planlæning

Proaktive forslag til din katastrofeplan

Dokumentation

En gennemgang af nødprocedurer hvert kvartal, er en proaktiv tilnærmelse til katastrofegendannelse. Nøglepersoner bør være opdateret på teknisk dokumentation af primære forretningssystemer. Detaljeret dokumentation som beskriver individuelle computerkonfigurationer og softwareindstillinger skal være tilgængelig i serverrummet.

Microsoft Exchange Server Redundancy

For eksempel, i en virksomhed der bruger Microsoft Exchange Server, er der en sekundær restore server til at håndtere genetablering af serverens «Information store» under strømnedbrud. Alle nuværende versioner af Exchange Server lagrer log filer i «Information Store» databasen. Mens "Circular Logging" kan spare lagringsplads, behøver man under en katastrofe et komplet sæt med log filer for at kunne genetablere «Information Store» så brugerne kan få tilgang til deres data.

Arkiveret data på båndmedier

Katastrofeplanlægning bør inkludere planer for off-site lagring af sikkerhedskopier og andre medier. Bånd backup kræver mere testvalidering i planen. Det er god praksis at teste sikkerhedskopier med jævne mellemrum. Bånd rotation bør være regelmæssig og konsekvent og man skal sikre god kvalitet på medierne for at undgå fejl.

RAID Systems

Når det er katastrofer som involverer RAID lagringssystemer, SAN-systemer og NAS-systemer, tager katastrofe planlægning en anden drejning. Disse lagringssystemer har redundancy arkitektur for at forhindre strømnedbrud og katastrofer. Men dette kan give en falsk følelse af tryghed.

For eksempel havde Ibas en kunde med 40TB lagringsplads fordelt på 20 servere. Disse systemer havde hardware RAID 1 + 0 konfigurationer. Problemerne opstod på en server når en harddisk ville gå offline i et øjeblik. Kontrollerkortet bytter til en spejlet kopi som en del af redundancy processen. På et tidspunkt, går den første disk tilbage på nettet. Kontrollerkortet skifter tilbage til den oprindelige disk, og resultatet bliver inkonsekvente data fra et volumen og filsystemperspektiv. Efter at systemet slukkes og genstartes, resettes også hardwaren. Operativsystemets automatiske volumenreparationsprogram starter med at køre reparationsprocesser. Dermed skabes yderligere problemer i filsystemets integritet og de kritiske data var ikke længere tilgængelige.

Ibas løser problemerne ved hjælp af vores Remote Data Recovery tjeneste.

Denne sag er interessant på grund af en række fejl som opstod i hurtig rækkefølge. Klienten behandler store datamængder fra tre skift per dag. At arkivere en sådan datamængde hver aften var ikke muligt. Klienten havde været overbevist om at lagringskonfiguration var "bulletproof" på grund af spejling.

Disse konfigurationer kan fungere når flere harddiske havarerer. I dette tilfælde, derimod, svigtede harddisken aldrig, den gik bare offline. Da harddisken kom tilbage på nettet, opstod der en fejl i filsystemet. Som et resultat, blev dataene utilgængelige da  det automatiske reparationsværktøj begyndte at lave reparationer.

Tjek hvad der skete når IT-chefen på sygehuset forsøgte at udvide kapaciteten på en filserver som støtter hundredevis af brugere.

Det er vigtigt at man planlægger mod det værste, og øver på rigtig førstehjælp. Ibas hjælper gerne, med vores kompetence, i en sådan planlægning. Er man forberedt, gør man det rigtige, når en katastrofe indtræffer.