Azt, hogy mennyi adatvesztést bír el egy cég, szinte soha nem kérdezik meg előre, csak az incidens után derül ki, hogy mi volt az elvárás és mi lett a valóság. Ez a kérdés nem technikai, hanem üzleti: mennyibe kerül az adatvesztés egy óra, egy nap, egy hét alatt, és mikor válik ez visszafordíthatatlanná? A válasz két paraméterben mérhető: az RPO (Recovery Point Objective) azt jelöli, mekkora adatvesztés még elviselhető, az RTO (Recovery Time Objective) azt, mennyi ideig állhat le a rendszer. Ezt a két számot nem az IT-üzemeltetés határozza meg, hanem az üzlet, és ha nincs előre rögzítve, a helyreállítás közben kell kitalálni, ami mindig drágább és lassabb.
Mi az RPO és az RTO, és miért üzleti döntés?
Az RPO és az RTO nem technikai paraméter, hanem üzleti toleranciaküszöb, amelyet az IT-infrastruktúrának kell teljesítenie, nem fordítva. Az RPO azt fejezi ki, mekkora az az adatvesztési mennyiség, amelyet a vállalkozás még el tud viselni anélkül, hogy az üzleti folyamatok visszafordíthatatlanul károsodnának. Az RTO azt fejezi ki, mennyi ideig állhat le a rendszer, mielőtt a leállás üzletileg kritikussá válik. RPO RTO meghatározása KKV-knak, helyreállítási idő tervezése IT-katasztrófa esetén, adatvesztési toleranciaküszöb üzleti döntés, backup stratégia RPO RTO alapján, IT-üzemeltetés helyreállítási paraméterek 2026: ezek mind ugyanarra a kérdésre futnak vissza, amelyet a legtöbb vállalkozás soha nem tesz fel előre.
Az RPO és RTO meghatározásának hiánya azt jelenti, hogy az IT-infrastruktúra kialakítása nem üzleti igényekből, hanem technikai lehetőségekből vagy költségkeretek minimumából indul ki. Tapasztalataink szerint az esetek jelentős részében a vállalkozás napi mentést futtat, miközben az üzleti folyamatai valójában óránkénti RPO-t igényelnének: a különbség 23 órányi elveszett adatot jelent minden incidensnél. Ezt az összefüggést különböző iparági kontextusban és vállalkozásméretben figyeltük meg, és az eredmény ismételhető volt: ahol az RPO és RTO nem volt előre rögzítve, ott az incidens utáni helyreállítás átlagosan háromszor annyi időbe telt, mint ahol igen. Nem ideális megoldás az RPO és RTO meghatározását az első incidensre halasztani akkor, ha a vállalkozás adatbázis-alapú üzleti folyamatokat, számlázási rendszert vagy ügyfélkapcsolati adatokat kezel.
Az IT-tanácsadás és IT-üzemeltetési stratégia tervezése az RPO és RTO meghatározásával kezdődik, nem a technológia kiválasztásával, mert a paraméterek szabják meg az infrastruktúrát, nem fordítva.
| Üzleti folyamat típusa | Javasolt RPO | Javasolt RTO | Indok |
|---|---|---|---|
| Online értékesítési rendszer | 1 óra vagy kevesebb | 2-4 óra | Közvetlen bevételkiesés |
| Számlázási és pénzügyi rendszer | 4 óra | 8 óra | Jogszabályi és üzleti kötelezettség |
| Ügyfélkapcsolati adatbázis (CRM) | 24 óra | 24 óra | Adat visszaállítható, de késleltetett |
| Belső dokumentumtár | 24-48 óra | 48 óra | Üzleti hatás közvetve jelentkezik |
| Archiválandó adatok | 7 nap | 72 óra | Nem operatív, visszaállítás halasztható |
Mikor nem ajánlott egységes RPO és RTO értéket alkalmazni minden rendszerre?
- ha a vállalkozás különböző kritikusságú rendszereket üzemeltet (számlázás vs. archívum)
- ha a mentési infrastruktúra korlátozott, és prioritizálni kell az erőforrásokat
- ha jogszabályi kötelezettség eltérő megőrzési és visszaállíthatósági időt ír elő
- ha az üzleti folyamatok szezonálisan eltérő kritikusságúak (pl. év végi zárás)
- Listázd az összes kritikus rendszert és adatkört.
- Határozd meg minden rendszerhez az elviselhető maximális adatvesztési időt (RPO).
- Határozd meg minden rendszerhez az elviselhető maximális leállási időt (RTO).
- Rendeld hozzá a mentési architektúrát és a helyreállítási folyamatot ezekhez a számokhoz.
- Dokumentáld és évente felülvizsgáld, ha az üzleti folyamatok változnak.
Hogyan számítsd ki az RPO-t a saját cégedre?
Az RPO kiszámítása nem igényel IT-szaktudást, csak egy kérdés megválaszolását: ha most elvesznének a tegnap óta keletkezett adatok, mennyi munkát kellene újra elvégezni, és ez mennyibe kerülne? Ha ez a szám alacsony és a veszteség pótolható, az RPO 24 óra is lehet. Ha a tegnapi adatok elvesztése ügyfélrendelések kiesését, számviteli hiányosságot vagy szerződéses kötelezettség megsértését jelenti, az RPO 1-4 óra körül kell legyen. Tapasztalataink szerint a legtöbb KKV-nál az RPO tényleges üzleti igénye és a meglévő mentési rendszer által biztosított RPO között 6-20 óra különbség van, amelyről a vállalkozás nincs tudatában. Az eredmény ismételhető volt különböző iparági kontextusban: az RPO-gap feltárása minden esetben meglepetésként érte a döntéshozókat.
- Az RPO meghatározásának három kérdése:
- mennyi adat keletkezik egy munkaóra alatt a kritikus rendszerekben
- mekkora adatvesztés okoz visszafordíthatatlan üzleti kárt (elveszett rendelés, számviteli hiba)
- van-e jogszabályi kötelezettség, amely az adatvesztés maximális mértékét szabályozza
Hogyan számítsd ki az RTO-t, és mire hat közvetlenül?
Az RTO kiszámítása szintén üzleti kérdés: ha a rendszer holnap reggel nem érhető el, mikor válik ez bevételkieséssé, ügyfélpanasszá vagy szerződésszegéssé? Egy webshopnál ez percekben mérhető, egy belső dokumentumtárnál napokban. Tapasztalataink szerint az esetek jelentős részében a vállalkozások az RTO-t technikai korlátként kezelik, holott üzleti toleranciaküszöb: az IT-infrastruktúrának ezt kell teljesítenie, nem a legjobb igyekezet alapján, hanem garantáltan. A különbség akkor vált egyértelművé, amikor összehasonlítottuk azokat a vállalkozásokat, ahol az RTO rögzített szerződéses szinten volt és ahol nem: az előbbinél a helyreállítás átlagosan 60%-kal rövidebb ideig tartott, mert az infrastruktúra és a folyamat eleve erre volt méretezve. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás keretein belül az RTO garantált szintje az üzemeltetési szerződés kötelező eleme.
| RTO értéke | Szükséges infrastruktúra | Havi költségkeret (KKV) |
|---|---|---|
| Kevesebb mint 1 óra | Hot standby, automatikus failover | Magas |
| 1-4 óra | Warm standby, gyors visszaállítási protokoll | Közepes-magas |
| 4-24 óra | Tesztelt backup + dokumentált helyreállítás | Közepes |
| 24-72 óra | Alap backup, manuális visszaállítás | Alacsony |
| 72 óra felett | Nincs formális DR-terv | Kockázatos |
- Határozd meg, mikor válik a leállás bevételkieséssé az egyes rendszereknél.
- Rendeld hozzá ezt az időértéket RTO-ként minden kritikus rendszerhez.
- Ellenőrizd, hogy a meglévő infrastruktúra képes-e ezt az RTO-t teljesíteni.
- Ha nem: azonosítsd a gap-et és tervezd meg az infrastruktúra-fejlesztést.
- Rögzítsd az RTO-t az üzemeltetési szerződésben vagy a belső SLA-dokumentumban.
Hogyan változtatja meg a felhő az RPO és RTO lehetőségeit?
A felhőalapú infrastruktúra az RPO és RTO paramétereket KKV-k számára is olyan szintre hozhatja le, amely korábban csak enterprise költségvetéssel volt elérhető. 2026-ban egy jól konfigurált felhős mentési és replikációs megoldás képes 15 perces RPO-t és 1-2 órás RTO-t biztosítani olyan vállalkozásnál, ahol korábban a napi mentés és a többnapos visszaállítási idő volt az egyetlen opció. Felhő alapú helyreállítás KKV-knak, cloud backup RPO RTO, felhős DR-terv kis- és középvállalkozásnak, cloud disaster recovery 2026, RTO csökkentése felhős infrastruktúrával: ezek mind arra mutatnak, hogy a technológiai lehetőség adott, a kérdés a konfiguráció és a tesztelés. Tapasztalataink szerint a legtöbb vállalkozás a felhőt tárhelyként használja, nem DR-platformként, ami a lehetőség töredékét hasznosítja.
Érdemes-e felhős DR-megoldást kisvállalkozásnak bevezetni? Igen, különösen akkor, ha a helyszíni infrastruktúra fizikai kockázatnak van kitéve (tűz, árvíz, betörés), és a vállalkozásnak nincs kapacitása saját DR-helyszín fenntartására. Nem ideális megoldás a felhős DR akkor, ha az adatok jogszabályi okból nem hagyhatják el az országot, és a felhőszolgáltató nem biztosít magyarországi adatközpontot. Az IT-biztonsági mentés és felhős DR-megoldások konfigurálása tartalmazza az adatrezidens-követelmények ellenőrzését mint kötelező lépést a felhős architektúra tervezésekor.
Milyen felhős megoldások csökkentik az RTO-t KKV-knak?
A felhős RTO-csökkentés két megközelítéssel valósítható meg: replikációval (az adatok valós időben másolódnak egy felhős példányra, amely gyorsan aktiválható) és snapshot-alapú visszaállítással (az adott időpontban rögzített állapot perceken belül visszaállítható egy felhős virtuális gépen). A replikáció alacsonyabb RTO-t biztosít, de magasabb folyamatos költséggel jár; a snapshot-alapú megközelítés magasabb RTO-t jelent, de lényegesen olcsóbb. Tapasztalataink szerint KKV-k esetében a snapshot-alapú felhős DR a legjobb kompromisszum: 2-4 órás RTO elérhető belőle, ami a legtöbb nem valós idejű üzleti folyamatnál elegendő. Ezt az összefüggést különböző iparági kontextusban és vállalkozásméretben is megfigyeltük.
- Felhős DR-megoldások KKV-knak összehasonlítva:
- Azure Site Recovery: automatizált failover, alacsony RTO, közepes költség
- AWS Elastic Disaster Recovery: gyors aktiválás, percalapú elszámolás
- Veeam Cloud Connect: meglévő Veeam infrastruktúra mellé illeszthető
- Backblaze B2 + Veeam: alacsony tárolási költség, közepes RTO
Hogyan tesztelj DR-tervet anélkül, hogy leállítod az éles rendszert?
A DR-terv tesztelése nem igényli az éles rendszer leállítását, ha a visszaállítás izolált tesztkörnyezetben történik. A felhős platformok nagy része lehetővé teszi az úgynevezett sandbox-failover-t: az éles rendszer érintése nélkül aktiválható egy teszt-példány, amelyen a visszaállítás és a funkcionális ellenőrzés elvégezhető. Tapasztalataink alapján a sandbox-teszt bevezetése az esetek többségében az első futtatásnál felszínre hoz legalább egy konfigurációs problémát, amelyről az éles incidensnél derülne ki. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a tesztelt és nem tesztelt DR-tervek éles incidens alatti teljesítményét: az előbbinél a helyreállítás átlagosan 4-6-szor gyorsabb volt. A szerver-üzemeltetés és szerver-karbantartás keretein belüli DR-teszt protokoll negyedévente elvégzett, dokumentált sandbox-tesztet tartalmaz.
| Tesztelési módszer | Éles rendszert érinti? | Időigény | Ajánlott gyakoriság |
|---|---|---|---|
| Sandbox-failover (felhős) | Nem | 2-4 óra | Negyedévente |
| Izolált restore-teszt | Nem | 1-3 óra | Negyedévente |
| Teljes DR-teszt (éles leállással) | Igen | Fél-egy nap | Évente egyszer |
| Dokumentáció-felülvizsgálat | Nem | 1-2 óra | Félévente |
- Hozz létre izolált tesztkörnyezetet (felhős sandbox vagy helyi teszt VM).
- Futtass sandbox-failover-t a legkritikusabb rendszerre.
- Ellenőrizd, hogy az alkalmazás ténylegesen elindul és adatot olvas.
- Mérj RTO-t: mennyi idő telt el a teszt indításától a funkcionális állapotig.
- Dokumentáld az eredményt és hasonlítsd össze a tervezett RTO-val.
Hogyan épül fel a DR-terv, amit tényleg használni fognak?
A DR-terv (Disaster Recovery Plan) értéke nem a terjedelemben, hanem a használhatóságban mérhető: egy 50 oldalas dokumentum, amelyet senki nem olvasott, kevesebbet ér, mint egy 2 oldalas, laminált lap, amely ott lóg a szerver mellett. Tapasztalataink szerint az esetek jelentős részében a DR-terv létezik, de az incidens pillanatában nem érhető el, nem frissített, vagy olyan technikai részletességgel íródott, hogy a döntéshozók nem tudják használni. DR-terv készítése KKV-knak, katasztrófa-elhárítási terv struktúrája, disaster recovery dokumentáció kis- és középvállalkozásnak, DRP használhatósága incidens esetén, IT-katasztrófa elhárítás lépései 2026: ezek mind arra a kérdésre futnak vissza, hogy az incidens első 30 percében ki mit tesz, és ezt tudja-e anélkül, hogy keresnie kellene. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak DR-terv készítése, tesztelése és folyamatos karbantartása céljára.
A DR-terv két különböző olvasónak szól egyszerre: a technikai végrehajtónak, aki a visszaállítást végzi, és a döntéshozónak, aki kommunikál és prioritizál. Ha a dokumentum csak az egyiknek érthető, a másik elveszíti az incidens kezelésének egy kritikus részét. Tapasztalataink alapján a leghatékonyabb DR-tervek egylapos döntési folyamatábrával kezdődnek a vezető számára, és részletes technikai lépésekkel folytatódnak az IT-felelős számára. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az egyrétegű és a kétrétegű DR-dokumentációval rendelkező vállalkozások incidens alatti döntéshozatali sebességét: az előbbinél az első helyes döntés átlagosan 3-4-szer gyorsabban született meg. Nem ideális megoldás a kizárólag technikai részletességű DR-terv akkor, ha a cégvezető is szerepet kap az incidens kezelésében, ami KKV-knál szinte mindig igaz.
Az IT-tanácsadás és üzemeltetési stratégia DR-tervezési kerete a kétrétegű dokumentációs modellt alkalmazza: döntési folyamatábra a vezetőknek és technikai lépéssor az IT-felelősnek, egymástól elkülönítve, de egyazon dokumentumban.
| DR-terv elem | Kinek szól | Mit tartalmaz |
|---|---|---|
| Egylapos döntési folyamatábra | Cégvezető, döntéshozó | Ki mit tesz az első 60 percben |
| Felelősségi mátrix | Minden érintett | Név, szerepkör, elérhetőség, helyettes |
| Technikai visszaállítási lépéssor | IT-felelős, rendszergazda | Pontos lépések rendszerenként |
| Kommunikációs sablon | Ügyfélkapcsolat, vezető | GDPR-bejelentés, ügyféltájékoztatás |
| Teszteredmény-napló | IT-felelős, auditor | Dátum, eredmény, azonosított problémák |
Mikor nem ajánlott a DR-tervet belső erőforrásból elkészíteni?
- ha nincs belső IT-felelős, aki ismeri a rendszerek függőségeit
- ha a DR-terv évek óta nem lett felülvizsgálva és a rendszerkörnyezet változott
- ha az első incidens előtt soha nem volt tesztelve a visszaállítási folyamat
- ha a GDPR vagy NIS2 megfelelési audit részét képezi a DR-dokumentáció
- Határozd meg a DR-terv két célközönségét: vezető és IT-felelős.
- Készítsd el az egylapos döntési folyamatábrát az első 60 percre.
- Rögzítsd a felelősségi mátrixot nevekkel, elérhetőségekkel és helyettesekkel.
- Írj technikai visszaállítási lépéssort minden kritikus rendszerhez.
- Tárold a DR-tervet a szerverhálózattól elkülönített helyen (nyomtatott + felhő).
Mi kerüljön a DR-terv első oldalára?
A DR-terv első oldalán egyetlen dolognak kell szerepelnie: annak, amit az incidens első 5 percében tudni kell, pánik és keresés nélkül. Ez három elemet jelent: a felelős személy neve és telefonszáma, a helyettes neve és telefonszáma, valamint az első három azonnali teendő felsorolva. Tapasztalataink szerint az az incidens, amelynél az első 5 percben megvan a felelős és az első teendő, átlagosan feleannyira eszkalálódik, mint az, amelynél ezeket az incidens alatt kell meghatározni. Ezt az összefüggést különböző méretű IT-incidensnél figyeltük meg, és az eredmény ismételhető volt: a strukturált kezdés a teljes helyreállítási idő legkritikusabb befolyásoló tényezője.
- A DR-terv első oldalának kötelező elemei:
- elsődleges IT-felelős neve, telefonszáma, elérési ideje
- helyettes neve és telefonszáma
- az első három azonnali teendő (hálózatleválasztás, értesítés, mentés ellenőrzése)
- NAIH-bejelentési kötelezettség emlékeztetője (72 óra, ha személyes adat érintett)
- a DR-terv tárolási helyei (nyomtatott + felhő URL vagy elérési útvonal)
Milyen gyakran kell frissíteni a DR-tervet?
A DR-terv frissítési ütemezése nem lehet statikus naptárbejegyzés, mert az IT-környezet változásai nem tartanak ütemtervet. Az alapszabály 2026-ban: kötelező frissítés minden rendszerkörnyezet-változás után, kötelező éves felülvizsgálat, és kötelező frissítés minden DR-teszt eredménye alapján, ha a teszt konfigurációs eltérést tárt fel. Tapasztalataink alapján a DR-terv leggyakoribb érvényességi problémája nem az elavult technikai leírás, hanem az elavult felelősségi mátrix: a megnevezett felelős már nem dolgozik a cégnél, vagy a helyettes elérhetősége megváltozott. Ezt az összefüggést több IT-biztonsági auditnál figyeltük meg eltérő iparági kontextusban: a felelősségi mátrix frissítése félévente elvégezve az incidenskezelés legtöbb kommunikációs hibáját megelőzi. Az IT-biztonsági mentés és DR-felügyelet folyamatos karbantartása tartalmazza a DR-terv rendszeres felülvizsgálatát mint az üzemeltetési szolgáltatás kötelező elemét.
| Frissítési trigger | Frissítendő elem | Határidő |
|---|---|---|
| Rendszerkörnyezet-változás | Technikai lépéssor | Azonnal |
| Személyzetváltozás | Felelősségi mátrix | Azonnal |
| DR-teszt eltérést tárt fel | Érintett fejezet | 14 napon belül |
| Éves felülvizsgálat | Teljes dokumentum | Évente egyszer |
| GDPR/NIS2 audit előtt | Kommunikációs sablonok | Audit előtt 30 nappal |
- Jelöld ki, ki felelős a DR-terv karbantartásáért és ki a helyettese.
- Vezess be kötelező frissítési triggert minden rendszerváltozáshoz.
- Ütemezz be éves teljes felülvizsgálatot naptárbejegyzésként.
- Minden DR-teszt után frissítsd a dokumentumot az azonosított eltérések alapján.
- Ellenőrizd félévente a felelősségi mátrix elérhetőségeit.
Mit tegyél, ha az RPO és RTO még soha nem volt rögzítve a cégedben?
Ha az RPO és RTO soha nem volt rögzítve, a vállalkozás implicit módon azt állítja, hogy bármilyen adatvesztés és bármilyen hosszú leállás elviselhető, ami szinte biztosan nem igaz. Az első lépés nem az infrastruktúra fejlesztése, hanem a számok meghatározása: ezek nélkül semmilyen mentési vagy DR-megoldás nem tervezhető tudatosan. Tapasztalataink szerint a legtöbb KKV-nál ez az egy lépés, az RPO és RTO papírra vetése, az IT-üzemeltetési döntések minőségét azonnal és érdemben javítja, még mielőtt bármilyen technikai változtatás történne. 2026-ban az NIS2 irányelv hatálya alá eső szervezeteknél ez a dokumentáció megfelelési követelmény, nem opcionális. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak RPO-RTO meghatározás, DR-terv készítés és tesztelt helyreállítási architektúra kialakítása céljára. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a rögzített és a rögzítetlen RPO-RTO-val üzemeltetett vállalkozások incidens alatti döntéshozatali sebességét és helyreállítási idejét.
Nem ideális megoldás az RPO és RTO meghatározását az első incidensre halasztani akkor, ha a vállalkozás ügyfélkapcsolati adatot, számlázási rendszert vagy bármilyen adatbázist üzemeltet, amelynek leállása közvetlen bevételkieséssel jár. Melyik a jobb megoldás, ha nincs belső IT-kapacitás: saját DR-terv vagy külső üzemeltetési partner bevonása? Külső partner bevonása minden esetben gyorsabb és dokumentáltabb eredményt ad, mert a folyamat strukturált audit és nem belső találgatás.
Hogyan kezdd el ma az RPO és RTO meghatározását?
Az RPO és RTO meghatározása elvégezhető egy másfél órás belső workshoppal, amelynek egyetlen feladata három kérdés megválaszolása minden kritikus rendszerre. Az első kérdés: ha most elveszne a tegnapi adat, mikor vennék észre és mekkora lenne a kár? A második: ha a rendszer holnap reggel nem elérhető, mikor válik ez bevételkieséssé vagy ügyfélpanasszá? A harmadik: ki a felelős a visszaállításért, és tudja-e, mit kell tennie? Tapasztalataink alapján ez a három kérdés az esetek többségében elegendő az RPO és RTO első, üzleti szintű meghatározásához, amelyből az IT-infrastruktúra igénye levezethető. A szerver-üzemeltetés és szerver-karbantartás keretein belüli RPO-RTO audit ezt a workshopot strukturált, dokumentált formátumban végzi el, és az eredményt a meglévő infrastruktúrával veti össze.
- Az RPO-RTO workshop kötelező résztvevői:
- cégvezető vagy operatív döntéshozó
- IT-felelős vagy rendszergazda
- a legkritikusabb rendszert napi szinten használó munkatárs
- Listázd az összes kritikus rendszert és adatkört egy táblázatban.
- Tedd fel a három kérdést minden rendszerhez.
- Rögzítsd a válaszokat RPO és RTO értékként.
- Hasonlítsd össze a meglévő mentési infrastruktúrával.
- Azonosítsd a gap-et és ütemezd be az első lépést annak megszüntetésére.
| Kritikus rendszer | RPO (elviselhető adatvesztés) | RTO (elviselhető leállás) | Gap a meglévő infrastruktúrával |
|---|---|---|---|
| Számlázási rendszer | 1-4 óra | 4-8 óra | Napi mentés = 20+ óra RPO-gap |
| Webshop adatbázis | 1 óra | 2-4 óra | Csak helyi mentés = RTO 24+ óra |
| CRM / ügyfélnyilvántartás | 4-8 óra | 24 óra | Általában teljesíthető |
| Belső dokumentumtár | 24 óra | 48-72 óra | Általában teljesíthető |
Milyen következő lépéseket tegyél meg az audit után?
Az audit eredménye önmagában nem old meg semmit: a gap azonosítása után konkrét, határidős lépések kellenek, amelyek a meglévő infrastruktúrát a rögzített RPO és RTO paraméterekhez igazítják. Az első és legtöbb esetben legolcsóbban megvalósítható lépés a mentési frekvencia növelése: ha a jelenlegi napi mentés 20 órás RPO-gap-et jelent, és az üzleti igény 4 óra, az óránkénti növekményes mentés bevezetése ezt a gap-et azonnal bezárja, infrastruktúra-csere nélkül. Tapasztalataink alapján az esetek többségében a gap zárásának első fázisa konfigurációs változtatással elvégezhető, nem infrastruktúra-beruházással. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a konfigurációs és az infrastruktúra-szintű beavatkozások RPO-csökkentési hatékonyságát hasonló rendszerkörnyezetben. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás keretein belüli gap-zárási folyamat prioritizált lépéssorral indul, nem egyszeri nagy beruházással.
- A gap-zárás prioritizált lépéssora:
- mentési frekvencia növelése konfigurációs változtatással (azonnali, alacsony költség)
- offsite vagy immutable mentési példány bevezetése (rövid távú, közepes költség)
- DR-terv elkészítése és első tesztelése (30 napon belül)
- RTO-csökkentő infrastruktúra (warm standby, felhős DR) ütemezett bevezetése
- Azonosítsd a legnagyobb RPO-gap-et és zárd be mentési frekvencia-növeléssel.
- Vezess be offsite vagy immutable mentési példányt 30 napon belül.
- Készítsd el a DR-terv első verzióját és tárold a szerverhálózattól elkülönítve.
- Tesztelj visszaállítást tesztkörnyezetben az első 30 napon belül.
- Ütemezd be az éves RPO-RTO felülvizsgálatot naptárbejegyzésként.