Biztonsági mentés és visszaállítás a gyakorlatban
A mentési stratégiák alapjai: 3-2-1 szabály, RPO és RTO mutatók, és miért nem számít mentésnek a szerveren tárolott pillanatfelvétel.
Az informatikában létezik egy mondás: csak kétféle üzemeltető létezik – aki már veszített el adatot, és aki fog. Egy weboldal vagy webáruház életében az adatvesztés nem elméleti lehetőség, hanem elkerülhetetlen kockázat. Egy félresikerült bővítményfrissítés, egy nem kívánt törlési parancs, egy adatbázis-korrupció vagy egy rosszindulatú kibertámadás pillanatok alatt megsemmisítheti a cég digitális értékeit.
Sok tárhelyvásárló megnyugszik, amikor a szolgáltató oldalán azt látja: „napi biztonsági mentés tartalmazva”. Azonban a mentések létezése önmagában még nem garantálja az adatok biztonságát. Ebben az elemzésben górcső alá vesszük a profi biztonsági mentések technikai követelményeit, az RPO és RTO mutatók jelentőségét, valamint tisztázzuk, mi a különbség a valódi mentés és a szerveroldali pillanatfelvétel (snapshot) között.
Alapfogalmak: RPO és RTO
Mielőtt mentési rendszert terveznénk vagy mentési szolgáltatást értékelnénk, két alapvető üzemeltetési mutatót kell meghatároznunk:
1. RPO (Recovery Point Objective - Helyreállítási pont célkitűzés)
Az RPO azt a maximálisan elfogadható adatmennyiséget (időben kifejezve) jelöli, amely egy katasztrófa esetén elveszhet.
- Ha egy statikus céges oldal hetente egyszer frissül, az 1 hetes RPO elfogadható lehet.
- Egy naponta több cikket publikáló híroldalnál a 24 órás RPO a minimum.
- Egy pörgős webáruházban, ahol óránként több tucat megrendelés érkezik, az RPO nem lehet több 15-60 percnél, különben a rendszerösszeomlás és az utolsó mentés közötti megrendelések adatai örökre elvesznek.
2. RTO (Recovery Time Objective - Helyreállítási idő célkitűzés)
Az RTO az a maximálisan elfogadható időtartam, ameddig a rendszer állhat a leállástól a teljes működőképesség visszaállításáig.
- Az RTO nemcsak a mentési fájlok letöltési idejét foglalja magában, hanem a fizikai szerver vagy VPS helyreállítását, a webszerver és az adatbázis konfigurálását, a mentés kicsomagolását, az adatbázis importálását és a működés ellenőrzését is.
- Egy nem megfelelően tesztelt mentési eljárás esetén az RTO órákról napokra nyúlhat, ami tetemes kiesést jelent a vállalkozásnak.
A 3-2-1 mentési elv: A biztonság aranyszabálya
A nemzetközi IT biztonsági szabványok által elismert 3-2-1 mentési elv kimondja a megbízható adatvédelem alapfeltételeit:
- 3 példány az adatokból: Legalább 3 független másolattal kell rendelkezned az adatokból (1 éles termelési adat + 2 mentési másolat).
- 2 különböző adathordozón: A mentéseket legalább két eltérő technológiájú vagy fizikai adathordozón kell tárolni (például helyi NVMe tárhely és távoli felhőalapú objektumtárhely).
- 1 távoli (offsite) helyszínen: legalább 1 mentési másolatnak fizikailag teljesen független adatközpontban vagy földrajzi helyszínen kell lennie.
Miért NEM mentés a szerveroldali pillanatfelvétel (snapshot)?
Az egyik legveszélyesebb tévhit a tárhelyszolgáltatás világában a pillanatfelvételek (snapshotok) és a helyi mentések összekeverése.
A snapshot a fájlrendszer vagy a virtuális gép állapotát rögzíti egy adott pillanatban. A legtöbb snapshot technológia (például Copy-on-Write elven működve) nem hoz létre komplett másolatot az adatokról, hanem csak a változásokat (delta fájlokat) követi nyomon az eredeti adatblokkokhoz képest.
Miért nem jelent valódi biztonsági mentést a helyi snapshot vagy a szerverre mentett zip fájl?
- Egyetlen fizikai hiba pont (Single Point of Failure): Ha a mentési fájl vagy a snapshot ugyanazon a fizikai szerveren, ugyanazon a lemez-tömbön (RAID) vagy ugyanabban a tárhelyfiókban található, mint az éles weboldal, akkor a hardver elhalása (lemezvezérlő hiba, fizikai szektorhiba) vagy az adatközponti tűzeset mind az éles adatot, mind a mentést egyszerre semmisíti meg.
- Kiberfertőzések és zsarolóvírusok (Ransomware): Ha egy támadó felügyeletet szerez a weboldalad vagy a tárhelyfiókod felett, az első lépése a fiókban található mentési archívumok törlése lesz. Ha a mentés ugyanott van, a támadó a mentést is törli vagy titkosítja.
- Véletlen törlés: Ha a webadminisztrátor tévedésből törli a tárhely könyvtárát, a helyi mentési könyvtárat is vele együtt törli.
A valódi biztonsági mentés az éles rendszertől elkülönített, írásvédett (vagy elkülönített hozzáférési kulcsokkal védett), távoli tárolóra (például Amazon S3, Backblaze B2 vagy dedikált távoli backup szerverre) továbbított, komplett adatcsomag.
Mentési gyakoriság és megőrzési idő (Retention Policy)
A jó mentési stratégia nem csak a legutolsó állapotot tárolja, hanem időbeli visszatekintési lehetőséget (Point-in-Time Recovery) is biztosít. Ennek klasszikus mintája a GFS (Grandfather-Father-Son) rotációs elv:
- Napi mentések (Son): Az elmúlt 7 nap minden napjáról megőrzött mentés.
- Heti mentések (Father): Az elmúlt 4 hét végén készült mentések.
- Havi mentések (Grandfather): Az elmúlt 12 hónap elsején készült archív mentések.
Ez a többlépcsős struktúra azért elengedhetetlen, mert a káros kódok vagy a rejtett adatbázis-hibák gyakran hetekig észrevétlenek maradnak. Ha csak a tegnapi mentésed van meg, és a fertőzés három napja történt, a tegnapi mentés visszaállításával a fertőzött állapotot állítod vissza.
A visszaállítás tesztelése (Disaster Recovery Testing)
Egy mentési rendszer értéke nem a mentés elkészítésének sikereiben, hanem a visszaállítás igazolt működésében rejlik. A mentési fájlok megsérülhetnek, az adatbázis-mentésekből hiányozhatnak kritikus táblák, vagy a beállítások megváltozása miatt a mentett fájlok nem importálhatók a frissített szoftverkörnyezetbe.
A professzionális üzemeltetés kötelező eleme a rendszeres tesztvisszaállítás:
- Évente legalább 2-4 alkalommal a mentési archívumot egy elszeparált tesztkörnyezetbe (Staging szerverre) kell visszaállítani.
- Ellenőrizni kell az adatbázis integritását, az állományok teljességét és a weboldal funkcionális működését.
- Dokumentálni kell a visszaállítás tényleges időigényét, és összevetni az előre meghatározott RTO értékkel.
Összegzés
Tárhelyválasztáskor ne elégedj meg a „van mentés” állítással. Mindig kérdezz rá a szolgáltatónál a technikai részletekre: milyen gyakran készül a mentés, mennyi a megőrzési idő, fizikailag külön gépen vagy adatközpontban tárolják-e a mentési fájlokat, és biztosítanak-e egykattintásos vagy önkiszolgáló visszaállítási felületet. Ugyanakkor az üzletileg kritikus adatokról mindig tarts saját, távoli, független mentést is.