Biztonsági mentés és magas rendelkezésre állás a gyakorlatban
Backup és magas rendelkezésre állás: miért nem ugyanaz a kettő?
Egy üzleti rendszer működésénél gyakran ugyanabban a mondatban hangzik el a biztonsági mentés, a redundancia és a magas rendelkezésre állás. Pedig három különböző fogalomról van szó, amelyek más problémát oldanak meg. Attól, hogy egy szerverről rendszeresen készül backup, még ugyanúgy leállhat órákra egy hardverhiba miatt. És attól, hogy egy rendszer több szerveren fut, még nem biztos, hogy visszaállítható egy tegnap véletlenül törölt adatbázis.
A valóban megbízható infrastruktúrában ezért nem a backup vagy a redundancia közül kell választani. Mindkettőre szükség lehet, csak más szerepben.
A backup az adatot védi
A biztonsági mentés elsődleges feladata, hogy egy korábbi állapot visszaállítható legyen. Ha valaki véletlenül töröl egy fájlt, megsérül egy adatbázis, egy hibás frissítés tönkreteszi az alkalmazást vagy egy támadás módosítja az adatokat, a megfelelő backup segítségével vissza lehet térni egy korábbi, működő állapothoz.
Ez azonban időt igényel.
Egy több száz gigabájtos vagy több terabájtos rendszer visszaállítása nem feltétlenül néhány perc. Először rendelkezésre kell állnia egy működő szervernek, vissza kell tölteni az adatokat, ellenőrizni kell azok konzisztenciáját, majd el kell indítani és tesztelni a szolgáltatásokat.
A backup tehát alapvetően azt a kérdést válaszolja meg:
Mi történik, ha elveszítjük vagy elrontjuk az adatot?
A magas rendelkezésre állás a szolgáltatás működését védi
A magas rendelkezésre állás, vagyis High Availability más célt szolgál. Itt az a kérdés, hogyan lehet egy szolgáltatást akkor is működésben tartani, ha valamelyik infrastruktúra-elem meghibásodik.
Egy megfelelően kialakított rendszerben például több webszerver, több hálózati útvonal, redundáns tápegység vagy több virtualizációs host állhat rendelkezésre. Ha az egyik komponens kiesik, egy másik átveheti a szerepét.
A felhasználó ebből ideális esetben semmit vagy csak minimális zavart érzékel.
A magas rendelkezésre állás tehát erre a kérdésre ad választ:
Mi történik, ha most meghibásodik valami?
Ez jelentős különbség.
Egy RAID sem backup
Az egyik leggyakoribb félreértés a RAID használatához kapcsolódik. Ha egy szerverben több merevlemez vagy SSD dolgozik redundáns RAID konfigurációban, egy meghajtó meghibásodása valóban nem feltétlenül okoz adatvesztést vagy azonnali leállást.
De ettől még nincs biztonsági mentés.
Ha valaki töröl egy könyvtárat, az ugyanúgy törlődik a redundáns lemezekről. Ha az adatbázis megsérül, a sérült adat kerül minden lemezre. Ha egy támadó titkosítja az állományokat, a RAID tökéletesen eltárolhatja a titkosított verziót is.
A RAID a hardverhiba egy bizonyos típusával szemben ad védelmet. A backup egy korábbi adatállapot megőrzését szolgálja.
A replikáció sem feltétlenül mentés
Hasonló probléma jelentkezik adatbázis-replikációnál.
Tegyük fel, hogy egy üzleti adatbázis két szerveren működik, és az elsődleges példány minden módosítást azonnal továbbít a másodlagos szervernek. Ha az első gép meghibásodik, a második átveheti a szerepét.
Ez kiváló magas rendelkezésre állási megoldás lehet.
Ha azonban valaki véletlenül kiad egy hibás törlési műveletet, a replikáció azt is gyorsan és pontosan továbbíthatja a második szerverre. Néhány másodperc múlva mindkét példányból ugyanaz az adat hiányzik.
Ilyenkor már nem a redundáns adatbázis segít, hanem egy megfelelő időpontból rendelkezésre álló backup.
Az idő is része a biztonsági tervnek
A biztonsági mentés tervezésénél nem elég azt mondani, hogy „van backup”. Két fontos kérdést is meg kell válaszolni.
Az egyik az, hogy mennyi adat elvesztése elfogadható. Ha naponta egyszer készül mentés, egy súlyos hiba esetén akár egy teljes munkanap adatai is elveszhetnek. Más rendszereknél óránkénti vagy akár sokkal gyakoribb mentési stratégia szükséges.
A másik kérdés, hogy mennyi idő alatt kell helyreállnia a szolgáltatásnak. Egy kisebb bemutatkozó weboldal esetén elfogadható lehet hosszabb visszaállítási idő. Egy rendelési rendszer, üzleti levelezés vagy folyamatosan használt vállalati alkalmazás esetén néhány óra kiesés már komoly problémát okozhat.
A megfelelő infrastruktúrát ezért mindig az üzleti követelményekhez kell igazítani.
A monitoring kapcsolja össze a rendszert
A redundancia önmagában sem sokat ér, ha senki nem veszi észre, hogy az egyik tartalék komponens már napok óta hibás.
Tipikus példa, amikor két tápegységgel rendelkező szerver tovább működik egyetlen táppal, ezért kívülről minden rendben lévőnek tűnik. Valójában azonban megszűnt a redundancia, és a következő hiba már teljes leállást okozhat.
Ugyanez igaz a mentésekre is. Egy backup-folyamat hónapokon keresztül szerepelhet a rendszerben úgy, hogy közben valamilyen hiba miatt már nem készít használható mentést.
Ezért a Nagios, Zabbix vagy más monitoring rendszer nem csak a CPU-terhelést és a szabad lemezterületet figyelheti. Ellenőrizhető vele a mentések frissessége, a RAID állapota, a hálózati kapcsolatok, a szolgáltatások működése, az UPS-ek állapota és számos más infrastruktúra-elem is.
A jó infrastruktúra több védelmi rétegből áll
Egy üzletileg fontos rendszer megbízhatósága ritkán oldható meg egyetlen technológiával. A szerverhardver, a virtualizáció, a hálózat, az adatközponti háttér, a monitoring és a mentési stratégia együtt határozza meg, hogy egy meghibásodásból kisebb kellemetlenség vagy hosszabb szolgáltatáskiesés lesz.
Az 1B Telecom infrastruktúrájában saját szerveres, adatközponti, virtualizált és felhős környezeteket is használunk. A megfelelő megoldás kiválasztásánál nem az a cél, hogy minden rendszerből indokolatlanul bonyolult klaszter épüljön, hanem hogy a rendelkezésre állás, a visszaállíthatóság és a költség arányban legyen az adott szolgáltatás jelentőségével.
Egy kevésbé kritikus weboldalnál lehet, hogy egy jó szerver, automatizált külső backup és megfelelő monitoring teljesen elegendő. Egy üzletileg kritikus alkalmazásnál viszont már redundáns infrastruktúra, több hálózati útvonal, folyamatos felügyelet és részletes helyreállítási terv indokolt.
A mentést vissza is kell tudni állítani
A backup akkor ér valamit, amikor használni kell.
Ezért időnként nemcsak azt érdemes ellenőrizni, hogy a mentési folyamat sikeresnek jelenti-e magát, hanem azt is, hogy az elkészült állomány valóban visszaállítható-e. Egy használhatatlan adatbázismentés vagy sérült archívum csak a hiba pillanatában derül ki – hacsak korábban nem tesztelték.
A rendszeres restore-teszt az egyik legegyszerűbb módja annak, hogy a papíron működő mentési rendszerből valódi helyreállítási megoldás legyen.
Nem backup vagy magas rendelkezésre állás, hanem backup és magas rendelkezésre állás
A két technológia nem helyettesíti egymást.
A magas rendelkezésre állás azt segíti, hogy egy meghibásodás esetén a szolgáltatás lehetőleg tovább működjön. A backup pedig azt biztosítja, hogy szükség esetén egy korábbi adatállapot visszaállítható legyen.
A megbízható informatikai rendszerben ezért a kérdés nem az, hogy „van-e mentés?”, hanem az, hogy milyen hibák ellen véd a teljes infrastruktúra, mennyi adat veszhet el, mennyi ideig állhat a szolgáltatás, és valóban működik-e a helyreállítás akkor is, amikor szükség van rá.