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
Hogyan határozzuk meg az RPO-t?
Az RPO meghatározásához minden tevékenység esetében fel kell tenni a kérdést: „ha elveszítenénk az elmúlt X óra adatrögzítéseit, mit kellene újra elvégezni, és mennyibe kerülne ez?” Az X még elfogadható legnagyobb értéke az RPO. Ezután a mentést úgy kell beállítani, hogy két sikeres másolat közötti időköz kisebb legyen ennél az X-nél.
A lényeg
- A kérdést tegye fel az egyes eszközök felhasználóinak, ne csak az informatikusnak.
- Három szempont: az adatok változásának sebessége, újraépíthetőségük, az elvesztésük költsége.
- A 24 órás RPO reggeli riasztást feltételez: két egymást követő sikertelen mentés, és a valós RPO már 48 óra.
- Egy óra alatt tervezzen replikációt vagy adatbázis-naplómentést, valamint zsarolóvírus elleni előzménytárat.
- Az előzmények mélysége (30 nap, egy év) az RPO-tól különálló beállítás.
A módszer egyetlen megbeszélésben
A NIST ezt a gyakorlatot üzleti hatáselemzésnek (BIA) nevezi: a folyamatok azonosítása, egy leállás következményeinek felmérése, majd a helyreállítási prioritások meghatározása. Egy kkv esetében egyetlen megbeszélés elegendő. Minden létfontosságú eszköz esetében tegyen fel három kérdést azoknak, akik használják, ne csak az informatikusnak.
- Milyen gyorsan változnak az adatok? Percenként, óránként vagy hetente egy bejegyzés?
- Újraépíthetők-e? Egy kívülről érkezett e-mail nem. Egy számla, amelynek másodpéldánya még az ügyfél asztalán van, részben. Egy műhelyi termelési adatrögzítés nem.
- Mennyi elveszett idő után válik elfogadhatatlanná a költség? Újrarögzítés költsége, újra leadandó rendelések, emlékezetből újranyitandó ügyek.
A választ órában rögzítse. Gyakori példák kkv-knál:
| Tevékenység | Általában ésszerű RPO | Miért |
|---|---|---|
| Ritkán módosuló irodai fájlok | 24 óra | Egy nap elvesztése látható és pótolható |
| Egész nap használt ERP vagy árajánlat-készítő szoftver | 1–4 óra | Egy nap elveszett árajánlatai nem állíthatók helyre |
| Levelezés | 1–8 óra | A beérkező üzenetek nem rögzíthetők újra |
| Könyvelés | 24 óra, plusz külön hosszú távú archiválás | Egy nap pótolható; az üzleti évet viszont archiválni kell |
| Pénztár-adatbázis | Néhány perc – 1 óra | A beszedett pénznek nyomon követhetőnek kell maradnia |
Ez a táblázat nem szabvány. Kiindulópont, amelyet az operatív munkatársakkal meg kell erősíteni vagy cáfolni.
Az RPO átületése gyakoriságra
- 24 órás RPO: naponta egy sikeres mentés, és reggeli riasztás, ha nem sikerült. Ha két egymást követő éjjel sikertelen, a valós RPO 48 órára nő. A felügyelet az RPO része.
- 4 órás RPO: munkaidőben legalább négyóránként egy másolat.
- Egy óránál rövidebb RPO: replikáció vagy nagyon gyakori másolatok, valamint külön egyeztetés a zsarolóvírusról, mert lehet, hogy a legfrissebb másolat már hibás. Az ANSSI, a francia nemzeti kiberbiztonsági ügynökség, egyébként azt javasolja, hogy ha az elfogadható adatvesztés 24 óránál kevesebb, a mentés mellett replikációt is fontoljanak meg.
Adatbázisok esetében a gyakoriság nem csak teljes mentésekkel állítható be. A Microsoft szerint teljes helyreállítási modellben a tranzakciós napló gyakori mentése lehetővé teszi egy pontos időpontra való visszaállítást. Gyakran ez a leggazdaságosabb módja annak, hogy egy üzleti szoftvernél néhány perces RPO-t érjenek el.
Tervezze meg a mélységet is: az, hogy 30 napra vissza lehet menni, nem változtat az RPO-n (amely a frissességről szól), de megmenti azt a helyzetet, amikor a legutóbbi másolatok sérültek. Az ANSSI például 15 nap napi, egy év havi és öt év éves mentést említ. A két beállítás egymás mellett létezik.
Annak ellenőrzése, hogy az RPO tartható
Az RPO a konzolban ellenőrizhető, nem a szerződésben:
- minden reggel az egyes szerverek utolsó sikeres másolatának időpontja;
- a feladatok időtartama: egy öt óráig tartó mentés nem futhat négyóránként;
- az elküldött változások mennyisége a telephely feltöltési sávszélességéhez képest;
- egy visszaállítási próba, legalább egy fájlon, annak igazolására, hogy a másolat olvasható. Lásd: Hogyan ellenőrizhető, hogy egy mentés működik?
Gyakori hibák
- Hagyni, hogy a szoftver gyártója határozza meg az RPO-t („valós idejű mentés”), anélkül hogy megnéznénk a feladatok tényleges időközét.
- Egyetlen RPO az egész vállalatra, a legtöbb változást generáló alkalmazáshoz igazítva, ami statikus fájlokért is a legmagasabb szintet fizetteti meg.
- Elfelejteni, hogy a felhőalapú levelezés RPO-ja a saját másolaté, nem a szolgáltató lomtáráé.
A WeDoBacknél
A gyakoriság a konzolban állítható be: az RPO az ügyfél e döntésétől függ. Az előfizetett tárhelynek fel kell tudnia venni ezt a gyakoriságot, mert a sűrűbb másolatok több változást őriznek meg. Az induláshoz közzétett nagyságrend a jelenlegi adatmennyiség háromszorosa, amelyet egy hét használat után kell pontosítani. A WeDoBack nem ír elő RPO-t. Ha az ügyfél kapcsolata nem tudja a változásokat a választott időközön belül elküldeni, a valós RPO hosszabb lesz a megjelenítettnél: ez fizikai korlát, amelyet az első hónapban kell mérni, nem részletkérdés. A mentések felügyelete a nap 24 órájában működik; 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. A SMART és az INTEGRAL ajánlat díjait az ajánlatok és árak oldal részletezi.
Gyakori kérdések
Ki határozza meg az RPO-t, a vezetés vagy az informatika?
A vezetés és az üzleti területek vezetői, mert az RPO gazdasági döntés: mennyi elveszett munkát fogad el a vállalat. Az informatika ezután ezt a döntést mentési gyakorisággá alakítja, és jelzi, mi technikailag lehetetlen a rendelkezésre álló sávszélesség vagy költségvetés mellett.
Minden szerverre ugyanaz az RPO kell?
Nem. Egyetlen, a legaktívabb alkalmazáshoz igazított RPO a legmagasabb szintet fizetteti meg olyan fájlokért is, amelyek alig változnak. Tevékenységenként egy sor, a hozzá tartozó gyakorisággal, pontosabb és gyakran olcsóbb.
A Microsoft 365 vagy a Google Workspace RPO-ja a szolgáltatóé?
Nem. A szolgáltató lomtárai és megőrzési beállításai nem olyan másolatok, amelyek felett Ön rendelkezik. Levelezésének RPO-ja a saját mentéséé: annak gyakorisága és utolsó sikeres futása.
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)
- Back up and Restore of SQL Server Databases — Microsoft Learn
- Külső mentési ajánlatok és árak — 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.