A backup nem ugyanaz, mint a helyreállíthatóság
A sikeres mentési feladat még nem bizonyítja, hogy egy szerver, adatbázis vagy fontos fájl hiba esetén időben és megbízhatóan helyreállítható.
Egy mentési rendszer naponta küldhet zöld státuszt úgy is, hogy közben senki nem tudja biztosan, mi történne valódi adatvesztés vagy szerverhiba esetén.
A backup ezért csak az egyik része a helyreállíthatóságnak. A fontosabb kérdés az, hogy a szükséges adat és szolgáltatás ténylegesen visszaállítható-e, megfelelő időn belül.
A sikeres mentés mit bizonyít?
A legtöbb mentési rendszer azt tudja ellenőrizni, hogy a mentési feladat lefutott-e, létrejött-e a mentési állomány, illetve történt-e technikai hiba a folyamat közben.
Ez szükséges, de önmagában kevés.
Egy restore során derülhet ki például, hogy:
- a szükséges adat valójában nem került bele a mentésbe;
- a mentési lánc egyik eleme sérült;
- nincs meg a visszaállításhoz szükséges kulcs, jelszó vagy dokumentáció;
- a mentésből az adat visszanyerhető, de a teljes szolgáltatás helyreállítása túl sok időt vesz igénybe;
- a visszaállítás folyamata egyetlen olyan ember tudására épül, aki éppen nem elérhető.
Ezért a mentési státusz és a helyreállítási képesség két külön ellenőrzési pont.
A restore teszt a bizonyíték
A CISA ransomware-útmutatója kifejezetten javasolja a kritikus adatok offline, titkosított mentését, valamint a mentések elérhetőségének és integritásának rendszeres tesztelését helyreállítási helyzetben.
A NIST 2026-os backup útmutatója ugyanezt az irányt erősíti: a mentéseket rendszeresen kell létrehozni, tesztelni, és a helyreállítási gyakorlatok részeként felülvizsgálni.
A gyakorlatban ez azt jelenti, hogy időnként valóban vissza kell állítani egy fájlt, adatbázist, virtuális gépet vagy teljes szolgáltatást egy elkülönített környezetben.
Nem feltétlenül minden rendszerhez ugyanolyan gyakran. Egy kritikus üzleti adatbázis más kockázati kategória, mint egy könnyen újraépíthető tesztrendszer.
Két szám, amelyet érdemes ismerni: RPO és RTO
A helyreállítás tervezésénél két egyszerű kérdés segít.
RPO — Recovery Point Objective: legfeljebb mennyi adat elvesztése fogadható el időben mérve?
Ha például óránként készül használható mentés, akkor egy hiba esetén akár az utolsó egy óra változásai is elveszhetnek. A tényleges RPO természetesen a konkrét mentési és replikációs megoldástól függ.
RTO — Recovery Time Objective: mennyi időn belül kell újra működnie a szolgáltatásnak?
A Microsoft Azure Backup dokumentációja is ebben az értelemben használja a két fogalmat: az RPO az elfogadható adatvesztési időablak, az RTO pedig a helyreállításhoz célként meghatározott idő.
Ezeket nem az informatikának kell önmagában eldöntenie. Egy üzleti folyamat tulajdonosa sokkal jobban meg tudja mondani, hogy elfogadható-e négy óra kiesés vagy egy napnyi adatvesztés.
Mit érdemes dokumentálni?
Egy használható helyreállítási leírásból legalább annak ki kell derülnie:
- mit mentünk;
- milyen gyakran készül mentés;
- hol találhatók a példányok;
- mennyi ideig őrizzük meg őket;
- ki fér hozzájuk;
- ki indítja a helyreállítást;
- milyen sorrendben kell visszaállítani az egymástól függő rendszereket;
- hogyan ellenőrizzük, hogy a visszaállított szolgáltatás valóban működik;
- mennyi időt vett igénybe a legutóbbi teszt.
A dokumentáció akkor igazán értékes, ha nem csak azt írja le, melyik gombot kell megnyomni, hanem a függőségeket is. Egy alkalmazás helyreállítása például kevés, ha közben hiányzik az adatbázis, a DNS-bejegyzés, a tanúsítvány vagy a hozzáférés.
A mentésnek a hibától is túl kell élnie
Ransomware vagy hibás adminisztrátori művelet esetén különösen fontos, hogy ne legyen minden mentési példány ugyanabból a környezetből módosítható.
A CISA ezért is hangsúlyozza az offline mentések és a rendszeres tesztelés jelentőségét: egy technikailag elérhető, de a támadó által ugyanúgy törölhető backup kevés védelmet ad.
A megfelelő megoldás környezetenként eltérhet. Lehet elkülönített tárhely, immutable tárolás, offline példány vagy más, hozzáférésben leválasztott mentési réteg. A lényeg az, hogy egyetlen hiba vagy kompromittált adminisztrátori jogosultság ne tudja egyszerre tönkretenni az éles adatot és az összes használható mentést.
Egy egyszerű ellenőrzési kérdés
Érdemes időnként nem azt megkérdezni, hogy:
„Van mentés?”
hanem ezt:
„Ha ez a szerver vagy adat ma eltűnne, miből, ki és mennyi idő alatt tudná visszaállítani?”
Ha erre nincs konkrét, kipróbált válasz, akkor a következő feladat valószínűleg nem újabb backup-job létrehozása, hanem egy helyreállítási teszt.
Források
- CISA: #StopRansomware Guide
- NIST SP 1339 (2026): OT Backup Quick Start Guide
- NIST SP 800-184: Guide for Cybersecurity Event Recovery
- Microsoft Learn: Azure Backup glossary — RPO és RTO