Az Ön szakértője a biztonsági mentés és az adatvédelem terén!Az Ön igényeire szabott megoldás
DRP és BCP
Mi az RTO?
Az RTO (Recovery Time Objective, helyreállítási idő célkitűzés) az a leghosszabb idő, ameddig egy szolgáltatás elérhetetlen maradhat. Az incidenstől, vagy az átállásról szóló döntéstől mérjük addig a pillanatig, amikor egy felhasználó ismét szokásos üzleti műveletet végez. Nem addig, amíg bekapcsol egy gép, amelynek alkalmazását még senki sem ellenőrizte.
A lényeg
- Az RTO hat időszak összege: észlelés, döntés, a hozzáférések felkutatása, technikai idő, üzleti ellenőrzés, a felhasználók visszatérése.
- A NIST megkülönbözteti a legnagyobb elviselhető kiesési időtől (MTD): az RTO-nak normál esetben rövidebbnek kell lennie az MTD-nél.
- Az RTO-t szolgáltatásonként kell rögzíteni: a telefonközpontnak és az archívumnak nem ugyanaz.
- Csak egy időméréssel kísért próba mutatja meg, hogy a leírt RTO tartható-e.
- Az ügyfélszolgálat elérhetőségi ideje és az ügyelet hiánya is a valós RTO része.
Hivatalos definíció
A NIST az RTO-t úgy határozza meg, mint azt a leghosszabb időt, ameddig az informatikai rendszer egy erőforrása elérhetetlen maradhat, mielőtt a hatás elfogadhatatlanná válik az általa támogatott tevékenységek számára. Megkülönbözteti a legnagyobb elviselhető kiesési időtől (MTD), amely az a teljes leállási idő, amelyet a vezetés egy tevékenység esetében elfogad. Az RTO-nak biztosítania kell, hogy az MTD ne legyen túllépve: ezért normál esetben rövidebb.
Az ANSSI, a francia nemzeti kiberbiztonsági ügynökség, a legnagyobb elfogadható kiesési idő (DMIA, durée maximale d’interruption admissible) kifejezést használja. Elvárja, hogy a mentési stratégia minden üzleti érték esetében vegye ezt figyelembe, és hogy a visszaállítási sorrendet előre határozzák meg, a függőségek (DNS, címtár…) és az alkalmazások kritikussága alapján.
Miből adódik össze az RTO
Egy hagyományos visszaállítás esetében:
- a hiba észleléséhez szükséges idő;
- a döntéshez és a hozzáértő személy eléréséhez szükséges idő;
- a kulcsok, jelszavak és az eljárás megtalálásához szükséges idő;
- a másolás vagy az indítás technikai ideje;
- az üzleti oldalról végzett ellenőrzés ideje;
- az az idő, amíg a munkaállomások vagy a távoli ügyfelek ismét elérik a szolgáltatást (DNS, VPN, IP).
Egy szoftver által ígért „kétórás” RTO gyakran csak a 4. lépést veszi figyelembe, laboratóriumi körülmények között. A valós RTO mind a hat lépést összeadja. Éjjel és hétvégén magában a 2. lépés is meghaladhatja a két órát, ha senki sincs ügyeletben.
BCP esetén a 4. és a 6. lépés előre elő van készítve. Megmarad az észlelés, valamint annak kockázata, hogy senki sem meri jóváhagyni az átállást.
Az RTO és az RPO nem egymás rovására alkudható meg
Lehet rövid az RPO (gyakori másolatok) és hosszú az RTO (nagy adatmennyiség lassú visszaállítása). Lehet rövid az RTO (már bekapcsolt tartalékrendszer) és gyenge az RPO, ha a tartalékrendszer két órával le van maradva. Mindkét számot rögzíteni kell.
RPOLegnagyobb elfogadható adatvesztés
RTOLegnagyobb elfogadható leállási idő
visszafelé mérjük
előre mérjük
Az incidens előtti adatok
!Incidens
A szolgáltatások újraindítása
| RPO | RTO | |
|---|---|---|
| Feltett kérdés | Mennyi munkát veszíthetünk el? | Meddig állhatunk le? |
| Mérés iránya | Visszafelé, az incidenstől | Előre, az incidenstől |
| Mi szabályozza | A másolatok gyakorisága | A tartalékrendszer előkészítése |
| Mivel ellenőrizhető | Az utolsó sikeres másolat dátuma | Időméréssel kísért próba |
Szolgáltatásonként egy RTO
A telefonközpontnak és az archív dokumentumkezelő rendszernek nem ugyanaz az RTO-ja. Ha az egész vállalatra „4 órás RTO”-t írunk, akkor vagy túlfizetjük a dokumentumkezelőt, vagy valótlant állítunk a telefonközpontról. Szolgáltatásonként egy sor elegendő.
Honnan tudható, hogy az RTO tartható
Kizárólag egy próba során végzett időmérésből. Ha a próba hat óráig tartott, a leírt RTO pedig két óra, akkor a leírt RTO a hibás, amíg az architektúra meg nem változik. Nem lehet „megcélozni” egy olyan RTO-t, amelyet a legutóbbi mérés cáfolt. Az ANSSI ezt külön hangsúlyozza: a visszaállítási eljárást írásba kell foglalni és rendszeresen végre kell hajtani. A próbák ütemét a Milyen gyakran teszteljük a DRP-t? című útmutató tárgyalja.
A WeDoBacknél
A weboldalon nem szerepel egyetlen számszerű RTO sem, és félrevezető lenne kitalálni egyet: az adatmennyiségtől, a kapcsolattól, a példány méretétől és az ügyfél oldali munkatársak elérhetőségétől függ. Az architektúra az időtartam jellegét változtatja meg. Egyszerű visszaállításnál az adatokat vissza kell hozni, és adott esetben újra kell telepíteni. A DRP esetében a szerverek tartalékpéldányokon indulnak újra a kiválasztott verzióból: a technikai idő ennek az újraindításnak az ideje, nem egy szervervásárlásé. Havonta indítási teszt történik, az éles üzem érintése nélkül. A BCP esetében a felhőpéldányok folyamatosan be vannak kapcsolva, és az ügyfél hálózatán futó ügynök továbbítja a forgalmat hozzájuk, IP-cím-változás nélkül: a fennmaradó RTO főként az észlelés és a döntés ideje. A BCP-példány és az eredeti szerver közötti adatreplikáció vagy -szinkronizálás nem beépített funkció: egy, az igényekhez igazított egyedi folyamatot igényel, amelyet a WeDoBack árajánlat alapján ki tud alakítani. Mindhárom esetben az üzleti ellenőrzés is beletartozik a mért időbe. Az emberi ügyfélszolgálat 9:00 és 13:00, valamint 14:00 és 17:30 között (párizsi idő szerint) érhető el.
Gyakori kérdések
Mi a különbség az RTO és az MTD között?
Az MTD (Maximum Tolerable Downtime) az a teljes leállási idő, amelyet a vezetés egy tevékenység esetében elfogad, minden hatást figyelembe véve. Az RTO egy informatikai erőforrás újbóli üzembe helyezésének határideje. A NIST pontosítja, hogy az RTO-nak normál esetben rövidebbnek kell lennie az MTD-nél, hogy maradjon tartalék a helyreállítás többi lépésére.
Egy szoftver néhány perces RTO-t ígér. Reális ez?
Ez a szám általában csak az indítás technikai idejét tartalmazza, laboratóriumi körülmények között. Nem foglalja magában sem az észlelést, sem a jogosult személy eléréséhez szükséges időt, sem a felhasználói ellenőrzést. Az Ön valós RTO-ja az, amelyet a legutóbbi próbán mért, az incidens bejelentésétől az első sikeres üzleti műveletig.
Jogszabályi kötelezettség az RTO?
Egyetlen jogszabály sem ír elő számszerű időtartamot egy kkv számára. A GDPR (32. cikk) ugyanakkor olyan eszközöket követel meg, amelyekkel incidens esetén a személyes adatok rendelkezésre állása és az azokhoz való hozzáférés „megfelelő időn belül” helyreállítható. Az RTO e megfelelő idő konkrét meghatározásának módja.
További olvasnivaló
Források
A dokumentumok megtekintésének ideje: 2026. október.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Az informatikai rendszerek mentése – Alapok (ANSSI-BP-100, v1.1, 2025. november 27.) — ANSSI (francia ügynökség)
- Az (EU) 2016/679 rendelet (GDPR), 32. cikk — EUR-Lex
- DRP ajánlat: üzletmenet helyreállítása katasztrófa után — WeDoBack
Biztonsági mentési, DRP- vagy BCP-projektje van?
Több mint 20 év tapasztalat a vállalati adatok védelmében.
Árajánlatot kérek+33 9 72 50 78 28Védje adatait a WeDoBack segítségével
Titkosított, telephelyen kívüli biztonsági mentés, megváltoztathatatlan tárolás, DRP és BCP: írja le nekünk szervereit, mi pedig javasoljuk a megfelelő kombinációt.