Helyszíni vagy felhős mentés egy növekvő cégnél

Hétfő reggel a számlázás nem indul el. A szerveren lévő adatbázis sérült, az előző esti mentés pedig ugyanazon a tárolón van, mint az éles rendszer. A csapat tudja, hogy valahol megvan az adat, de nem tudja, mikor és milyen állapotban lesz újra használható. Ilyenkor a helyszíni vagy felhős mentés kérdése már nem informatikai részlet, hanem működési kockázat: kiszállítható-e az áru, kiállítható-e a számla, elérhetőek-e az ügyféladatok, és meddig marad állva a munka.

Sok vállalatnál a mentési stratégia történetileg alakult ki. Volt egy szerver, mellé került egy hálózati tároló, később egy külső merevlemez vagy egy felhős tárhely. Ezek önmagukban nem feltétlenül rossz megoldások. A probléma akkor kezdődik, amikor senki nem tudja biztosan, mely rendszerekről készül mentés, hol található, meddig őrzik meg, és valóban visszaállítható-e.

A mentés célja nem a fájlok másolása

Egy vállalkozás mentési igénye nem abból indul ki, hány terabájt adatot tárol. Abból indul ki, hogy egy hiba után milyen üzleti folyamatokat kell újra működésbe hozni.

Más következménye van annak, ha egy archív szerződés nem érhető el néhány óráig, és másnak, ha a webshop készletadata, a gyártási rendszer, a rendeléskezelés vagy a pénzügyi adatbázis áll le. Az első kellemetlenség lehet. A második közvetlen bevételkiesést, hibás teljesítést, vevői bizalomvesztést és jelentős túlórát okozhat.

Ezért két kérdést kell külön kezelni. Az egyik a helyreállítási idő: mennyi idő alatt kell újra működnie egy rendszernek? A másik az elfogadható adatvesztés: legfeljebb mennyi friss adat tűnhet el? Ha egy raktári rendszer csak az előző napi állapotra állítható vissza, akkor a közben feladott, átvett vagy átvezetett árumozgások manuális rekonstruálása válik szükségessé. Ez gyakran nagyobb probléma, mint maga az informatikai leállás.

A jó mentési megoldás tehát nem attól jó, hogy automatikusan fut. Attól jó, hogy a vállalat egy ismert incidenshelyzetben, elfogadható időn belül, ellenőrzött adatokkal képes folytatni a munkát.

Helyszíni vagy felhős mentés: nem kizáró választás

A helyszíni mentés jellemzően a vállalat telephelyén vagy saját szervertermében működő tárolóra készül. Előnye a gyors helyi visszaállítás és a közvetlen kontroll. Ha nagy adatbázist, több virtuális szervert vagy jelentős méretű fájlkészletet kell visszatölteni, a helyi hálózati kapcsolat lényegesen gyorsabb lehet, mint egy internetes letöltés.

Ez különösen releváns lehet termelési, logisztikai vagy olyan irodai környezetben, ahol több rendszer szorosan függ egymástól. Egy helyi mentési infrastruktúra akkor is értékes, ha az internetkapcsolat átmenetileg nem elérhető, vagy ha egy teljes rendszerkép gyors visszaállítása szükséges.

Ugyanakkor a helyszíni mentésnek van egy alapvető korlátja: ugyanazokat a fizikai kockázatokat viseli, mint az éles környezet. Tűz, beázás, elektromos hiba, lopás, zsarolóvírus vagy egy hibás adminisztrátori művelet egyszerre érintheti a szervert és a mentést is. Ha a mentési tárhely folyamatosan írható és ugyanazzal a jogosultsági körrel érhető el, egy támadás nem feltétlenül áll meg az éles rendszernél.

A felhős mentés ezzel szemben fizikailag elkülöníti a mentett adatot a telephelytől. Egy megfelelően kialakított szolgáltatás verziókezelést, titkosítást, földrajzi redundanciát és hosszabb megőrzési időt is biztosíthat. Ez különösen hasznos, ha a vállalat több telephelyen működik, távoli munkavégzést támogat, vagy nem rendelkezik saját, megfelelően védett infrastruktúrával.

A felhős mentés sem varázslat. Visszaállítási idejét befolyásolja az internetkapcsolat, az adatmennyiség, a kiválasztott szolgáltatási szint és az, hogy egyetlen fájlt vagy teljes szerverkörnyezetet kell helyreállítani. Egy több terabájtos rendszer mentése a felhőben lehet biztonságos, de egy sürgős teljes visszaállítás mégis órákat vagy napokat igényelhet, ha a kapcsolat vagy a terv nincs ehhez méretezve.

A gyakorlatban ezért a legtöbb növekvő vállalat számára nem a kizárólag helyszíni vagy kizárólag felhős modell a legjobb. A két megközelítés együtt ad érdemi védelmet: gyors helyi helyreállítást a gyakori hibákra, valamint elkülönített másolatot a súlyosabb incidensekre.

Előbb a folyamatot és a függőségeket kell feltérképezni

Egy mentési projekt gyakran technikai kérdésként indul: milyen tárolót vegyünk, melyik felhőszolgáltatót válasszuk, mennyi kapacitás kell? Ezek jogos kérdések, de túl korán kerülnek elő.

Először azt kell megérteni, hogyan mozog az információ a cégben. Egy webshop rendelése bekerülhet a webshopmotorba, onnan egy ERP-be, majd számlázóba, raktári rendszerbe és futárintegrációba. Ha csak az egyik rendszer visszaállítható egy régebbi állapotra, miközben a többi rendszerben frissebb adatok vannak, könnyen eltérés keletkezik. A rendelés teljesítettnek látszik az egyik helyen, de hiányzik a másikból. Ilyenkor a visszaállítás után az üzleti egyeztetés legalább akkora feladat lehet, mint maga a technikai helyreállítás.

Ugyanez igaz a gyártásra is. Előfordulhat, hogy a termelési terv, a gépadatok, a minőségbiztosítási dokumentáció és a készletnyilvántartás külön rendszerekben él. Nem szükséges minden adatnak ugyanazt a helyreállítási célt adni. De tudni kell, melyik kiesése állítja meg a termelést, melyik adat rekonstruálható, és melyiknek van jogszabályi vagy szerződéses megőrzési kötelezettsége.

A mentési stratégia így valójában üzletmenet-folytonossági döntés. Rendszereket, adatokat, felelősségeket és helyreállítási sorrendet kell kijelölni. Nem elég annyit mondani, hogy „mindenről készül mentés”.

Mire kell választ adnia egy működő mentési tervnek?

Egy használható tervnek világossá kell tennie, hogy pontosan mely szerverekről, adatbázisokról, felhasználói fájlokról és felhős üzleti alkalmazásokról készül mentés. Gyakori tévedés, hogy egy SaaS rendszer használata automatikusan teljes körű adatvédelmet jelent. A szolgáltatás rendelkezésre állása és a vállalat saját adatainak hosszú távú, részletes visszaállíthatósága nem mindig ugyanaz.

A tervnek azt is rögzítenie kell, ki kap riasztást sikertelen mentés esetén, ki jogosult visszaállítást indítani, és ki dönt arról, hogy melyik mentési pontból történjen a helyreállítás. Ezek a felelősségek különösen akkor fontosak, amikor egy kulcsember szabadságon van, vagy az incidens munkaidőn kívül történik.

A megőrzési időt üzleti igényhez kell igazítani. Egy napi mentés kevés lehet, ha nap közben sok megrendelés és pénzügyi tranzakció keletkezik. Egy néhány napos megőrzés pedig nem véd egy olyan hiba ellen, amelyet csak hetekkel később vesznek észre. A verziók száma, a megőrzési idő és a visszaállítás gyakorisága együtt alakítja a kockázatot és a költséget.

Külön figyelmet érdemel a mentések védelme. A titkosítás, a többtényezős hozzáférés, az elkülönített adminisztrátori fiókok és a módosítás ellen védett mentési példányok nem túlzó óvintézkedések. Zsarolóvírusos incidensnél éppen ezek dönthetik el, hogy rendelkezésre áll-e tiszta, használható állapot.

A visszaállítási próba az egyetlen valódi bizonyíték

A legtöbb mentési hiányosság nem a mentés elkészítésekor, hanem a visszaállításkor derül ki. Lehet, hogy a feladat naponta zöld státuszú. Ettől még előfordulhat hibás adatbázismentés, hiányzó titkosítási kulcs, nem dokumentált függőség vagy túl lassú visszatöltés.

Érdemes rendszeresen próbát végezni, mégpedig nem csak egyetlen fájl visszaállításával. Egy üzletileg kritikus rendszer teljes helyreállítását is ellenőrizni kell elkülönített környezetben. A próba során mérhetővé válik, mennyi idő kell a rendszer elindításához, rendelkezésre állnak-e a szükséges hozzáférések, és milyen utómunkát igényel az adatok konzisztenciájának ellenőrzése.

Ez a teszt nem az IT hibáztatásáról szól. A cél az, hogy egy éles incidens ne legyen az első alkalom, amikor a szervezet megpróbálja végrehajtani a helyreállítást.

A megfelelő arány a vállalat működéséhez igazodik

Egy kisebb, kevés kritikus rendszerrel dolgozó vállalkozásnak elegendő lehet egy egyszerűbb, de rendszeresen ellenőrzött helyi és felhős másolat. Egy több telephelyes kereskedelmi vagy gyártó cégnél már részletesebb helyreállítási sorrendre, gyors helyi mentésre, elkülönített távoli példányra és dokumentált incidenskezelésre lehet szükség.

Nem a legtöbb tárolókapacitás vagy a leghosszabb funkciólista jelenti a biztonságot. A jó döntés abból indul ki, hogy egy rendszer kiesése pontosan milyen munkát állít meg, ki érintett, mennyi adat keletkezik, és milyen gyorsan kell visszatérni a normál működéshez.

Érdemes egy nyugodt időszakban végigvenni: ha holnap reggel nem indulna el a legfontosabb rendszer, ki tudná megmondani, melyik mentésből, milyen sorrendben és mennyi idő alatt áll helyre a munka? Ha erre nincs egyértelmű válasz, akkor nem elsősorban új technológiára, hanem tisztább működési tervre van szükség.