• Live chat
  • Facebook
  • Google Plus
  • rss

Hatékony katasztrófa-helyreállítás a KKV-knál

×
×
Megjelent: 2015.04.27 Vissza

A teljes körű katasztrófa-helyreállításnak része kellene, hogy legyen az elsődleges rendszer tökéletes működése, és az, hogy a teljes rendszert redundánsan üzemeltessük – azaz a szolgáltatásokat, adatbázisokat és minden egyebet ugyanúgy el lehessen érni akkor is, ha az elsődleges helyszínen valamilyen baj történik. Ez pedig nem csak igen költséges folyamat, de problémákat is felvet.

Jól tudjuk, hogy semmilyen rendszer nem mentes a hibáktól. Soha nem lehetünk biztosak abban, hogy minden hardver és szoftver, amelyet használunk, tökéletesen működik. Ennek pedig nagy jelentősége van a katasztrófa helyreállításban is, hiszen elég egy kis hiba, és máris létfontosságú adatokat veszíthetünk el örökre, helyreállíthatatlanul.

Ideális és irreális

Egy tökéletes világban a költség nem volna akadály, és minden vállalatnak lehetősége volna arra, hogy egyszerre legalább három adatközpontban tárolja adatait – két egymáshoz közeliben, amelyek klasztert formálnak, és egy harmadik, távoli adatközpontban, amely akkor is működőképes marad, ha a két első központ elérhetetlenné válik.

Ezeket a létesítményeket több redundáns, független, dedikált üvegszálas kábel kötné össze egymással, és mindhárom létesítmény teherbírását a megfelelő hibatűréssel alakítanák ki. Az olyan vállalkozások azonban, akik egy ilyen rendszert megengedhetnek maguknak, elenyésző kisebbségben vannak. A nagy bankok hasonló rendszereket üzemeltetnek, és néhány szolgáltató is, de rajtuk kívül nem sokan.

A legtöbb vállalatnál van valamilyen típusú redundancia, ez azonban a legtöbb esetben koránt sem képes arra, hogy az elsődleges rendszer működését bármikor zökkenőmentesen és teljes mértékben kiváltsa. Az ilyen redundáns rendszerek általában legfeljebb a létfontosságú adatok mentésére jók. Ez pedig azt jelenti, hogy kemény döntéseket kell hoznunk, és meghatározni azokat az adatokat, amelyekre ki kell terjednie a szükségszerűen korlátozott biztonsági intézkedéseknek.

Mi a fontos, és mi nem az?

A munkaterheléseket alapvetően négy kategóriába oszthatjuk. Az elsőbe kerülnek azok, amelyeknél valóban minden létező adatot meg kell őriznünk, a másodikba pedig azok, ahol egy napnyi adat elvesztése még elfogadható. A harmadik csoport az, amelyet elegendő úgy évente egyszer lementeni, a negyedik csoportot pedig azok adják, amelyek teljesen értelmüket vesztik, ha az elsődleges létesítmény megsemmisül, tehát duplikálni sem érdemes őket. Ezek adják meg az adatvesztési tűrést (Recovery Point Objective, vagyis RPO). A kérdés itt az, hogy mennyi adatot veszíthetünk el. A másik fontos szempont a kieséstől az újraindításig eltelt idő (ez a Recovery Time Objective, vagyis RTO).

A kevésbé fontos vagy kisebb méretű adatokat egyszerűen szinkronizálhatjuk valamilyen felhőszolgáltatás segítségével is – bár a legjobb, ha ezekből egyszerre többet is használunk, a minél biztonságosabb adattárolás végett. Az olyan adatokat, mint maguk a weboldalak vagy a rajta tárolt fájlok, elegendő naponta menteni. Legrosszabb esetben is csak minimális mennyiségű munka, valamennyi fájl, feltöltött adat veszik el, ami kicsit kényelmetlen lehet ugyan, de nem dől tőle össze a világ. A valós idejű szinkronizáció ebben ennél a kategóriánál túlzott óvintézkedés.

A számokkal számolnunk kell

Az első kategóriába tartoznak például a számviteli és rendeléskövetési adatok.

Egy gyár esetén nem nagy tragédia, ha elveszik egy napnyi adat, mert mindenről lesz papíralapú másolat – ha a rendszer csütörtököt mond, a legrosszabb annak a szegény alkalmazottnak lesz, akinek majd manuálisan újra fel kell vinnie az adatokat, ha a rendszer helyreállt.

Az adóhatóság azonban már egyetlen napnyi elveszett adat esetén is összevonja a szemöldökét. Ha az épület leég, akkor is biztosítanunk kell a percre pontos adatok meglétét – és a papíralapú másolatok itt nem jelentenek megoldást, mert azok bennégnek majd az épületben. (A tűzoltólétráról senki nem fordul majd vissza, hogy a könyvelést mentse.) De még ha meg is lennének ilyen formában az adatok, az IT-részleg előtt csakhamar vasvillás-fáklyás tömeg kezdene gyülekezni.

Kinek mikor mi?

A rendelési adatok szintén percre pontosan szinkronizálásra kell, hogy kerüljenek. Tudnunk kell, hogy ki mit rendelt, mit fizetett, mit vett át, mi van úton és mi áll a raktárban (vagy változott rövid úton hamuvá), és kinek kell szólnunk, hogy később/sohasem kapja meg, amit kért. Abban a pillanatban, hogy kiderül, valami baj történt, az összes telefonvonalon érdeklődő ügyfelek kapaszkodnak majd.

Ez utóbbit a MariaDB segítségével szokás megoldani, ez ugyanis képes arra, hogy két helyszínen replikálja valós időben az adatbázisokat.

A legfontosabb adatok esetében az egyik legjobb megoldásnak az kínálkozik, ha a helyszínen egy ioSafe-et alkalmazunk, amely tűz- és vízálló, illetve az Azure Site Recovery szolgáltatását. Ez utóbbi negyed órával le lesz maradva a frissítésekkel, ez azonban bőven elég, amíg az ioSafe-et elő tudjuk kaparni a romok alól.

http://www.theregister.co.uk/2015/04/07/can_you_recover_your_data_if_disaster_strikes_sure/