Egy vállalkozás informatikai adatainak elvesztéséhez nem szükséges látványos informatikai katasztrófa. Egy hibás merevlemez mellett ugyanúgy okozhat adatvesztést egy téves törlés, hibás programfrissítés, zsarolóvírus, eszközlopás vagy akár egy rosszul kialakított szinkronizálási rendszer.
A biztonsági mentés feladata ezért nem egyszerűen az, hogy legyen még egy példány az adatainkból. A cél az, hogy egy káresemény után elfogadható időn belül vissza tudjunk térni egy használható állapothoz.
Emberi hiba
A felhasználó véletlenül töröl egy könyvtárat. Valaki felülír egy dokumentumot. Hibás parancs fut le egy szerveren. Téves adat kerül egy adatbázisba.
Ezek ellen a RAID vagy egy második merevlemez önmagában nem véd.
Sőt, egy szinkronizált rendszer a hibás változtatást nagyon hatékonyan továbbíthatja a többi példányra is.
Ezért fontos különbséget tenni redundancia, szinkronizálás és biztonsági mentés között.
Műszaki meghibásodás
A merevlemezek és SSD-k meghibásodhatnak. Tönkremehet a tápegység, a vezérlő vagy maga a szerver.
A redundáns tárolás csökkentheti egyes hardverhibák következményeit, de nem helyettesíti a biztonsági mentést.
Egy RAID például segíthet abban, hogy egy meghajtó kiesésekor a rendszer tovább működjön. Ha azonban valaki töröl egy állományt, a RAID minden lemezén eltűnik.
Vírusok és zsarolóprogramok
A modern kártevők különösen fontossá tették, hogy a mentési rendszer ne legyen korlátlanul elérhető ugyanabból a környezetből, amelyet védeni szeretnénk.
Ha egy támadó rendszergazdai jogosultságot szerez, a folyamatosan csatlakoztatott vagy ugyanazzal a hitelesítéssel elérhető mentések is veszélybe kerülhetnek.
Ezért lehet jelentősége az offline, fizikailag elkülönített vagy módosíthatatlan – immutable – mentési példánynak.
Fizikai károk és lopás
Két merevlemez ugyanabban a szerverben két példány, de nem feltétlenül két egymástól független biztonsági másolat.
Ugyanez igaz arra is, ha az eredeti adatok és valamennyi mentés ugyanabban az épületben található.
Tűz, vízkár, villámcsapás vagy betörés egyszerre érintheti valamennyit.
Legalább egy mentési példányt ezért célszerű fizikailag elkülönített helyen tárolni.
Hibás szoftver és frissítés
Az adat nemcsak eltűnhet: használhatatlanná is válhat.
Egy sikertelen frissítés, hibás adatbázis-migráció vagy programhiba olyan állapotot hozhat létre, amelyet csak egy korábbi, ismerten működő állapot visszaállításával lehet korrigálni.
Ez egy másik fontos követelményhez vezet: nem mindig a legfrissebb mentésre van szükségünk.
Előfordulhat, hogy csak napokkal vagy hetekkel később vesszük észre a problémát.
Mennyi adatot veszíthetünk el?
Ezt a kérdést érdemes üzleti oldalról megközelíteni.
Ha a mentés naponta egyszer készül, egy hiba esetén akár egy teljes munkanap változásai elveszhetnek. Ha óránként, akkor legfeljebb körülbelül egy órányi.
Nem minden rendszer igényel ugyanolyan gyakoriságot.
A kérdés az:
mennyi idő munkájának elvesztése elfogadható a vállalkozás számára?
Ebből már meghatározható a szükséges mentési gyakoriság.
Mennyi ideig állhat a rendszer?
A másik üzleti kérdés, hogy egy káresemény után mennyi idő alatt kell újra használhatóvá tenni az informatikát.
Nem ugyanaz a megoldás szükséges akkor, ha egy archív dokumentum visszaállítása ráér másnapig, és akkor, ha egy termelést kiszolgáló rendszernek egy órán belül működnie kell.
A mentési rendszer tehát nem pusztán tárhely kérdése.
A vállalkozás működéséhez kell méretezni.
A mentést ellenőrizni is kell
Az automatikusan lefutó mentési feladat önmagában még nem bizonyítja, hogy szükség esetén vissza lehet állítani az adatokat.
A rendszernek ezért legalább három dolgot biztosítania kell:
- a mentések automatikus elkészítését;
- a hibák és elmaradt mentések észlelését és jelzését;
- időszakos visszaállítási próbát.
A biztonsági mentés valódi mércéje ugyanis nem az, hogy létrejött-e egy fájl tegnap éjjel.
Hanem az, hogy abból működő rendszert és használható adatokat tudunk-e visszaállítani.