Az adataink ma legalább olyan értékesek, mint régen a pénz a kasszában. Mégis sokan csak akkor kezdenek el foglalkozni velük, amikor már megtörtént a baj: összeomlott a szerver, hibás lett a lemez, vagy épp zsarolóprogram titkosította a fájlokat. Ezen a ponton derül ki, hogy a védelem nem a tűzoltással kezdődik, hanem azzal, hogy előre felkészülünk a problémákra.
A biztonsági mentés és a rendszeres szerverkarbantartás nem technomániások hobbija, hanem alapvető üzemeltetési feladat. Ugyanúgy be kell épülniük a mindennapokba, mint a számlázás vagy a könyvelés. Ha ez hiányzik, akkor minden, amit az informatikára építettél – weboldal, ügyféladatbázis, levelezés – bármelyik pillanatban elúszhat.
Ebben a cikkben végigmegyek azon, miért létfontosságú ez a terület, milyen mentési megoldások közül lehet választani, hogyan néz ki a gyakorlatban egy alap szerverkarbantartás, és milyen tipikus hibákat kerülök el ma már tudatosan. A végén gyakori kérdéseket is összeszedtem, hogy gyorsan megtaláld a számodra fontos válaszokat.
Miért létfontosságú a biztonsági mentés ma?
A vállalkozások nagy része már nem kartondobozokban tárolja az információt, hanem szervereken, felhőszolgáltatásokban és különféle alkalmazásokban. Ez kényelmes, rugalmas és gyors, viszont minden eddiginél kiszolgáltatottabb a technikai hibáknak. Egy rossz frissítés, egy tönkremenő SSD vagy egy hibás konfiguráció elég ahhoz, hogy teljes folyamatok álljanak le. Ha ilyenkor nincs használható másolat, akkor nemcsak az adat, hanem az ügyfelek bizalma is sérül.
Az elmúlt években látványosan nőtt a zsarolóvírusos támadások száma, és ezek már nemcsak nagyvállalatokat, hanem kisebb cégeket, egyesületeket, sőt, magánembereket is érintenek. A támadók tudják, hogy a legtöbben fizetnének az adataikért, ezért érdemes rájuk célozni. A védekezés kulcsa az, hogy olyan másolatok álljanak rendelkezésre, amelyek nincsenek közvetlenül kitéve a fertőzésnek, és szükség esetén gyorsan visszaállíthatók.
Saját bőrömön tapasztaltam meg, mennyire fájdalmas, amikor nincs megfelelő felkészültség. Egy régi projektnél egy szerverfrissítés során adatbázis-sérülés történt, és csak egy héttel korábbi állapotra tudtunk visszaállni, mert nem ellenőriztük rendszeresen a mentések állapotát. Az ügyfél egy hetes munkája elveszett, a bizonytalanság pedig hetekre megmérgezte az együttműködést. Azóta a mentés nem opcionális extra, hanem kötelezően beépített folyamat.
Milyen mentési típusok léteznek és mikor melyik jó?
Az egyik alapvető fogalom a teljes mentés, amikor minden kijelölt adatot egy az egyben lementünk.
- Egyszerűen érthető és átlátható: ha gond van, ebből minden visszaállítható.
- Hátránya, hogy idő- és tárhelyigényes, ezért napi szinten önmagában ritkán hatékony, főleg nagyobb rendszereknél.
- Olyan helyzetekben használom, amikor új rendszert indítok, vagy jelentős változtatás előtt állok, például nagyobb frissítés, rendszerátalakítás előtt.
A következő lépcső az inkrementális mentés, amikor csak az utolsó mentés óta történt változásokat mentjük.
- Előnye, hogy gyors, kevés tárhelyet foglal, és lehetővé teszi a gyakori (akár óránkénti) mentést.
- Hátránya, hogy visszaállításkor az eredeti teljes mentésre és minden köztes lépésre szükség van, így a helyreállítás időigényesebb és sérülékenyebb lehet.
- Akkor működik jól, ha stabil rendszered van, és fontos a gyakori, részletes visszakövethetőség.
Létezik differenciális mentés is, amely mindig az utolsó teljes mentés óta történt összes változást tárolja.
- Visszaállításkor kevesebb lépésre van szükség, mint az inkrementálisnál: elég az utolsó teljes és az utolsó differenciális csomag.
- Cserébe idővel ezek a mentések nőnek, és egyre tovább tart az elkészítésük.
- Kompromisszumos megoldásként tud jól működni: például heti teljes mentés mellé napi differenciális, így a visszaállítás egyszerűbb, de a napi mentés még nem túl megterhelő.
Szerverkarbantartás lépésről lépésre kezdőknek
Egy alap karbantartási rutin első lépése az állapotfelmérés.
- Ellenőrzöm a lemezhasználatot, hogy ne teljen be a tárhely figyelmeztetés nélkül.
- Megnézem a processzor- és memóriahasználatot, feltűnő tüskéket keresve.
- Átnézem a legfontosabb naplófájlokat (rendszerlog, web-, adatbázis-log), hogy nincsenek-e visszatérő hibák vagy figyelmeztetések.
A következő szint a frissítések és biztonsági javítások rendszeres telepítése.
- Előre ütemezem, mikor történjenek a rendszerfrissítések, hogy ne munkaidőben álljanak le a szolgáltatások.
- Mindig készítek mentést komolyabb frissítés előtt, mert hiba esetén csak így tudok gyorsan visszagurítani.
- A felesleges szolgáltatásokat letiltom, a használtakat pedig naprakészen tartom, ezzel csökkentem a támadási felületet.
Végül a karbantartás része az automatizálás és az ellenőrzés is.
- Ütemezett feladatokat állítok be (cron, task scheduler), hogy a logtisztítás, csomagtakarítás, újraindítások ne kézi módszerrel történjenek.
- Riasztást konfigurálok CPU, RAM, lemez, hálózat és szolgáltatás-elérhetőség alapján, hogy ne a felhasználótól tudjam meg először, ha gond van.
- Időszakosan tesztelem a mentésekből való visszaállítást is, mert a karbantartás nemcsak a szerver futásáról szól, hanem arról is, hogy baj esetén tényleg tudok-e gyorsan reagálni.
Tipikus hibák, amik tönkreteszik a mentési stratégiát
Az egyik leggyakoribb hiba, hogy sokan beállítanak egy mentési folyamatot, aztán soha többé nem nyúlnak hozzá.
- Nem ellenőrzik, hogy a mentés valóban lefutott-e, csak feltételezik.
- Nem próbálják ki a visszaállítást, így derül ki éles helyzetben, hogy a mentés sérült vagy hiányos.
- Ha a környezet változik (új szerver, új adatbázis, másik mappa), gyakran elfelejtik frissíteni a beállításokat, és fél év múlva derül ki, hogy az új adatok nincsenek benne.
Szintén tipikus, amikor minden másolat ugyanazon a helyen van.
- A szerveren fut a rendszer, és ugyanarra a gépre készül a másolat is – ha a hardver tönkremegy, minden odavész.
- Vagy a telephelyen lévő NAS az egyetlen tároló, amelyet egy tűz, betörés vagy árvíz egyszerre el tud vinni.
- Ezen kívül hiba, ha a mentés írási jogosultsággal csatolt hálózati meghajtón van, mert egy zsarolóprogram ugyanúgy titkosítja, mint az aktív adatokat.
Gyakran látom azt is, hogy nincsenek verziók, csak az utolsó mentés.
- Ha valaki véletlenül felülír egy fontos dokumentumot, az új hibás változat kerül a másolatba is.
- Ha napokkal később veszik észre a problémát, nincs hova visszalépni, mert minden friss mentés ugyanarra az állapotra mutat.
- Ezen úgy lehet javítani, hogy több időpontra visszanyúló verziót tartunk, például napi, heti, havi szinteken, jól átgondolt szabályrendszerrel.
Saját tapasztalat: hogyan építettem fel a védelmet
Amikor az első „komolyabb” szervert raktam össze egy kisebb cégnek, bevallom, túlságosan bíztam a hardverben. Új gép, redundáns tápegység, RAID tömb, jó minőségű SSD-k – úgy gondoltam, ez így bőven elég. Készítettem ugyan egy egyszerű mentést egy hálózati meghajtóra, de nem törődtem azzal, hogy kipróbáljam a visszaállítást. Fél év múlva egy hibás frissítés után kiderült, hogy az adatbázis csak részben állítható vissza, mert a mentés közben éppen futott rajta egy karbantartó folyamat. Aznap este nagyon világosan megértettem, hogy a stratégia nem a hardverrel, hanem a folyamatokkal kezdődik.
Azóta több szintet építek egymásra.
- Van lokális mentés a szerveren belül, hogy egy kisebb hiba esetén gyorsan lehessen visszavonni.
- Van külön gépen vagy NAS-on tárolt másolat, amely már egy külön eszközön van, nem ugyanazon a hardveren.
- Van offsite vagy felhős tárolás, amely akkor is megmarad, ha az iroda fizikailag elérhetetlenné válik.
A gyakorlatban ez úgy néz ki, hogy többféle gyakoriságot kombinálok.
- Készül napi mentés az adatbázisról, heti teljes mentés az egész rendszerről, és havi archiválás hosszabb távra.
- Automatikus figyelmeztetést kérek minden sikertelen mentésről, így nem napok múlva derül ki, ha valami elromlott.
- Évente többször is szánok időt arra, hogy tesztkörnyezetben végigcsináljam a teljes visszaállítási folyamatot, így tudom, mire számíthatok éles helyzetben.
Gyakori kérdések adatmentésről és szerverekről
Milyen gyakran érdemes mentést készíteni?
- Attól függ, mennyi adatvesztést tudsz elfogadni.
- Ha napi szinten változik sok információ (rendelések, ügyféladatok), akkor legalább napi mentés kell, kritikus rendszereknél akár óránkénti is indokolt.
- Olyan gyakoriságot válassz, amely mellett egy esetleges hiba után még vállalható mennyiségű munkát kell csak újra elvégezni.
Elég, ha a felhőszolgáltatómra bízom a másolatokat?
- A nagy szolgáltatók adatai jellemzően jól védettek, de ez nem mentesít a saját felelősséged alól.
- Ha valaki véletlenül töröl egy mappát, vagy hibásan szinkronizál, a felhő is a hibás állapotot őrzi meg.
- Érdemes külön, tőle független mentést is tartani, mert így egy szolgáltatói hiba vagy zárolt fiók esetén sem maradsz teljesen eszköztelen.
Mivel érdemes kezdeni, ha most állsz neki ennek az egésznek?
- Először döntsd el, mi az, aminek az elvesztése a legfájóbb lenne: adatbázis, fájlszerver, levelezés.
- Válassz egy egyszerű, megbízható megoldást (akár kész mentőszoftvert), és állíts be legalább egy napi ütemezett mentést, külön eszközre.
- Amint ez stabilan működik, lépésről lépésre bővítsd a rendszert verziózással, offsite tárolással és rendszeres visszaállítási próbákkal.
A hosszú távon biztonságos működés nem azon múlik, hogy mennyire erős a vas, hanem azon, mennyire következetes a gondolkodás a háttérben. A jól felépített mentési folyamat és a fegyelmezett szerverkarbantartás nem látványos, de pontosan akkor fogod értékelni, amikor minden más összeomlik. Ha már ma elkezded átgondolni, mit, hova és milyen gyakran mentesz, és legalább egy alap rutint kialakítasz, akkor egy jövőbeli kritikus hibát egyszerű, kezelhető üzemszünetté tudsz szelídíteni. Ez a különbség aközött, hogy egy hiba tönkretesz egy vállalkozást – vagy csak egy délutánodat.
