- RTO = elfogadható leállási idő (milyen gyorsan állsz vissza); RPO = elfogadható adatvesztés (mennyit veszíthetsz).
- Az RTO a helyreállítási architektúrát, az RPO a mentés/replikáció gyakoriságát dönti el.
- A célokat üzleti hatáselemzés (BIA) adja, nem műszaki tipp — a számokat az üzlet hagyja jóvá.
- Négy DR-stratégia: backup & restore → pilot light → warm standby → active-active; csökkenő RTO, növekvő költség.
- 3-2-1-1-0 mentés: a leggyakrabban kihagyott a „0" — a rendszeres, valódi visszaállítási teszt.
01RTO és RPO 30 másodpercben
A legtisztább, ha egy idővonalon nézed: középen az incidens, balra az RPO (mennyi adatot veszítünk az utolsó jó állapotig), jobbra az RTO (mennyi idő, míg a szolgáltatás visszaáll).
Az RTO azt mondja meg, milyen gyorsan állsz vissza; az RPO azt, mennyi adatot veszítesz. Két külön szám, rendszerenként más — és minél kisebb, annál drágább.
02Mi az RTO
Az RTO (Recovery Time Objective) az elfogadható leállási idő: az incidens kezdetétől a szolgáltatás működőképes helyreállásáig eltelhető maximális idő. Ha az RTO 1 óra, akkor a rendszernek egy órán belül újra szolgálnia kell — a mögöttes DR-architektúrának ezt kell tudnia.
Az RTO közvetlenül meghatározza a helyreállítási megoldást: egy órás RTO-t mentésből visszaállítással nehéz tartani, viszont egy warm standby vagy active-active topológiával igen. Minél kisebb az RTO, annál „forróbb" (és drágább) a készenléti környezet.
03Mi az RPO
Az RPO (Recovery Point Objective) az elfogadható adatvesztés: meddig mehetünk vissza időben az utolsó visszaállítható, konzisztens állapotig. Ha az RPO 15 perc, akkor maximum 15 percnyi adatot veszíthetünk egy incidensnél — tehát legalább 15 percenként kell konzisztens mentés vagy replikáció.
Az RPO tehát a mentés/replikáció gyakoriságát és technológiáját dönti el: napi mentés → RPO akár 24 óra; folyamatos (CDP) vagy szinkron replikáció → RPO közel nulla. Minél kisebb az RPO, annál drágább és összetettebb a megoldás.
04Hogyan határozd meg — BIA
Az RTO/RPO nem műszaki tipp, hanem üzleti döntés. Az üzleti hatáselemzés (BIA — Business Impact Analysis) rendszerenként/folyamatonként felméri, mekkora kárt okoz a kiesés az idő függvényében:
- Bevételkiesés (pl. webshop: x Ft/óra), kötbér, szerződéses SLA-büntetés
- Jogszabályi / megfelelőségi mulasztás (pl. adatszolgáltatási határidő)
- Reputációs kár, ügyfélvesztés
- Működési bénulás (gyártás-leállás, kézi kerülőút költsége)
Ebből jön a kritikussági sorrend és rendszerenként az RTO/RPO. A kritikus, bevételtermelő vagy szabályozott rendszerek alacsony célt kapnak (percek), a háttér-rendszerek magasabbat (órák–napok). A számokat az üzlet hagyja jóvá — az IT ehhez rendeli a stratégiát és a költséget.
| Rendszer-típus | Tipikus RTO | Tipikus RPO |
|---|---|---|
| Tranzakciós / pénzügyi mag | < 1 óra | perctől közel nulláig |
| Webshop / ügyfél-felület | 1–4 óra | perctől 1 óráig |
| Belső ügyviteli (ERP back-office) | 4–24 óra | 1–8 óra |
| Archív / riport / fejlesztői | 1–3 nap | 24 óra |
05A költség-kompromisszum
Az alapszabály: minél kisebb az RTO/RPO, annál drágább a megoldás — exponenciálisan. A „nulla leállás, nulla adatvesztés" elvileg lehetséges (active-active, szinkron replikáció), de nagyon drága, és a legtöbb rendszernél nincs rá üzleti indok.
A jó tervezés nem a leghidegebb vagy legforróbb megoldást választja mindenre, hanem rendszerenként a BIA szerinti minimumot: a kritikus magra forró megoldás, a háttérre olcsóbb. Így a DR-büdzsé oda megy, ahol az üzleti kockázat van — nem egyenletesen szétkenve.
Az RTO≈0 és RPO≈0 (active-active, szinkron replikáció) elvileg lehetséges, de exponenciálisan drága, és a legtöbb rendszernél nincs rá üzleti indok. Ne kend szét egyenletesen a DR-büdzsét — rendszerenként a BIA szerinti minimumot válaszd.
06DR-stratégiák és a hozzájuk tartozó RTO
Négy fő szint, növekvő költséggel és csökkenő RTO-val. Az ábra a tipikus relatív helyreállítási időt mutatja (hosszabb sáv = lassabb visszaállás):
Részletesen: Backup & restore — mentésből visszaállítás, legolcsóbb; Pilot light — a mag-rendszer minimális készenléti másolata, kieséskor felskálázva; Warm standby — folyamatosan futó, kisebb másodlagos környezet, gyors átkapcsolással; Active-active — két aktív telephely terheléselosztással, közel nulla RTO. A modellek hibrid és felhő-környezetben egyaránt megvalósíthatók — lásd a felhő vs. on-premise megközelítést.
07RTO/RPO és a 3-2-1-1-0 mentés
A DR-stratégia alapja a megbízható mentés. A modern, ransomware-tudatos szabály a 3-2-1-1-0:
- 3 másolat az adatból
- 2 különböző adathordozón
- 1 offsite (telephelyen kívül)
- 1 offline vagy változtathatatlan (immutable / air-gapped) — ransomware ellen
- 0 hiba a rendszeres, valódi visszaállítással végzett helyreállítási teszt során
A leggyakrabban kihagyott elem a 0: a mentés csak akkor ér valamit, ha rendszeresen tesztelt visszaállítással. Sok cég akkor szembesül a hibás vagy hiányos mentéssel, amikor élesben kellene visszaállítania — ekkor a papíron jó RPO a valóságban végtelen. A 3-2-1-1-0 megvalósítását a gyakorlatban az IT Infrastruktúra / DRP szolgáltatásunk fedi le.
A mentés léte még nem DR: a helyreállítás idejét és a környezet újraépítését is teszteld. A kritikus rendszereknél legalább évente futtass éles DR-drillt, valódi visszaállítással — ne papíros átnézést.
08Gyakori hibák
- Nincs BIA: az RTO/RPO-t az IT „belőtte" üzleti jóváhagyás nélkül — vagy túlköltés, vagy alultervezés.
- Egységes szám mindenre: ugyanaz az RTO a kritikus magra és a fejlesztői környezetre — pazarlás vagy kockázat.
- Mentés ≠ DR: a mentés megléte nem garantálja az RTO-t; a visszaállítás ideje és a környezet újraépítése a tényleges RTO.
- Tesztelés hiánya: a „0" elem kihagyása — sosem próbált helyreállítás élesben bukik.
- Függőségek figyelmen kívül hagyása: egy rendszer RTO-ja annyit ér, amennyit a függőségei (DNS, AD, hálózat, külső API) is tudnak.
09GYIK
Mi az RTO és RPO egyszerűen?
Az RTO: milyen gyorsan állunk vissza egy incidens után (elfogadható leállás). Az RPO: mennyi adatot veszítünk maximum (elfogadható adatvesztés). Az RTO a helyreállítási architektúrát, az RPO a mentés gyakoriságát határozza meg.
Lehet az RPO és az RTO is nulla?
Közel igen — szinkron replikációval (RPO≈0) és active-active topológiával (RTO≈0) —, de ez drága és összetett. A legtöbb rendszernél nincs rá üzleti indok; a BIA dönti el, hol éri meg.
Hogyan kapcsolódik a DR a BCP-hez?
A DR (Disaster Recovery) a technológiai helyreállítás (rendszerek, adat). A BCP (Business Continuity Plan) tágabb: az egész üzletmenet folytonossága, beleértve az embereket, folyamatokat és kézi kerülőutakat. A DR a BCP technológiai pillére; az RTO/RPO a kettő közös nyelve.
Milyen gyakran teszteljük a DR-t?
A kritikus rendszereknél legalább évente, és minden lényeges változás után; a pénzügyi szektorban a DORA ezt kifejezetten elő is írja (legalább éves teszt, valamint teszt a kritikus vagy fontos funkciókat támogató rendszerek lényeges változásakor). A teszt valódi visszaállítás legyen, nem papíros átnézés — ez a 3-2-1-1-0 „0" eleme.
Hogyan határozzam meg az RTO-t és az RPO-t?
Üzleti hatáselemzéssel (BIA), nem műszaki tippeléssel. Rendszerenként/folyamatonként meg kell becsülni, mekkora kárt okoz egy óra/egy nap leállás (bevételkiesés, kötbér, jogszabályi mulasztás, reputáció), és mennyi elveszett adat tolerálható. A kritikus, bevételtermelő vagy szabályozott rendszerek alacsony RTO/RPO-t kapnak (percek), a háttér-rendszerek magasabbat (órák-napok). A számokat az üzlet hagyja jóvá, az IT pedig hozzárendeli a megfelelő DR-stratégiát és költséget.
Mennyi legyen az RPO?
Annyi, amennyi adatvesztést az adott rendszer üzletileg elvisel. Tranzakciós, pénzügyi vagy rendelési rendszernél jellemzően percek vagy közel nulla (szinkron replikációval). Belső, ritkán változó rendszernél órák–egy nap is elfogadható (napi mentés). Nincs univerzális szám: az RPO közvetlenül meghatározza a mentés/replikáció gyakoriságát és technológiáját, ezért minél kisebb az RPO, annál drágább a megoldás.
Milyen DR-stratégiák léteznek?
Négy fő szint, növekvő költséggel és csökkenő RTO-val: (1) Backup & restore — mentésből visszaállítás, legolcsóbb, RTO órák-napok; (2) Pilot light — a mag-rendszer minimális készenléti másolata, felskálázás kieséskor, RTO tíz perctől órákig; (3) Warm standby — folyamatosan futó, kisebb méretű másodlagos környezet, RTO percek; (4) Active-active / hot site — két aktív telephely terheléselosztással, RTO közel nulla. A választást az üzletileg meghatározott RTO/RPO és a költségvetés dönti el.
Mit jelent a 3-2-1-1-0 mentési szabály?
3 másolat az adatból, 2 különböző adathordozón, ebből 1 offsite (telephelyen kívül), 1 offline vagy változtathatatlan (immutable / air-gapped) másolat ransomware ellen, és 0 hiba a rendszeres helyreállítási teszt során. Ez a klasszikus 3-2-1 szabály modern, ransomware-tudatos kiterjesztése. A leggyakrabban kihagyott elem a 0: a mentés akkor ér valamit, ha rendszeresen, valódi visszaállítással tesztelt — sok cég csak akkor szembesül a hibás mentéssel, amikor élesben kellene visszaállítania.
Mi az a BIA (üzleti hatáselemzés)?
A BIA (Business Impact Analysis) az a folyamat, amely felméri, hogy az egyes üzleti folyamatok és az őket támogató rendszerek kiesése milyen hatást (pénzügyi, jogi, reputációs, működési) okoz az idő függvényében. A BIA adja meg a kritikussági sorrendet és ebből az RTO/RPO célokat — ez a DR/BCP-tervezés kiindulópontja. A BIA nélkül a DR-stratégia tippelés: vagy túlköltünk a nem kritikus rendszerre, vagy alultervezzük a kritikusat.
10Konzultáció
Ha DR-tervre, RTO/RPO-meghatározásra vagy a meglévő mentés/DR auditjára van szükséged, írj nekünk — munkanapokon 24 órán belül válaszolunk, és egy 30 perces ingyenes konzultáció után BIA-alapú kritikussági besorolást, rendszerenkénti RTO/RPO-javaslatot és a hozzá illő DR-stratégiát adunk — számszerű költségkerettel.
A kivitelezést az IT Infrastruktúra (DRP/BCP), a Cloud & Hibrid és a 24/7 NOC szolgáltatásaink keretrendszerével támogatjuk — banki éles tapasztalatból, negyedéves DR-drill gyakorlattal.