Milyen gyakran teszteljük a DRP-t?

Legalább havonta ellenőrizze automatikusan, hogy a másolatok még elindulnak, és legalább évente egyszer végezzen valós átállást, egy valódi üzleti művelettel. Ismételje meg a tesztet, amint megváltozik a szerver, a hálózat, a szolgáltató vagy a kulcsot őrző személy.

Frissítve: 2026. október3 perc olvasás6 hivatkozott forrás

A lényeg

  • Naponta: a sikertelen mentések áttekintése. Havonta: a tartalékrendszer technikai indítása.
  • Negyedévente: egy időméréssel kísért visszaállítás. Évente: egy valós átállás visszaállással.
  • A NIST a helyreállítási képességek éves tesztelését írja elő; a GDPR és a francia ANSSI rendszeres tesztelést követel meg.
  • Minden jelentős változás (szerver, főverzió, rendszergazda, szolgáltató, internetkapcsolat) tesztet von maga után.
  • A legfontosabb: az utolsó próba írásban rögzített dátuma és a kijavított eltérések.

Mit mondanak a szakmai ajánlások

  • NIST. Az amerikai szövetségi rendszerek számára készült SP 800-34 útmutató a helyreállítási képességek és a csapatok évente történő tesztelését írja elő, a gyenge pontok feltárása érdekében. Magát a tervet a szervezet által meghatározott gyakorisággal, például évente, valamint minden jelentős változás után frissíteni kell.
  • GDPR. A 32. cikk olyan eszközöket követel meg, amelyekkel a személyes adatok rendelkezésre állása megfelelő időn belül helyreállítható, valamint egy eljárást a biztonsági intézkedések hatékonyságának rendszeres tesztelésére és értékelésére.
  • ANSSI (Franciaország). A francia nemzeti kiberbiztonsági ügynökség szerint a mentéseket rendszeresen tesztelni kell, az informatikai rendszer visszaállítási eljárását pedig írásba kell foglalni és rendszeresen végre kell hajtani. A válsággyakorlatok tekintetében az ügynökség többéves stratégiában való gondolkodást javasol, fokozatosan bővülő formátumokkal.

E szövegek egyike sem írja elő, hogy „havonta, valós körülmények között” kell tesztelni. Mindegyik a gyakori ellenőrzések és a legalább évente elvégzett teljes próba irányába mutat.

Miért nem „havonta, valós körülmények között”

A valós átállás megszakítja vagy megszakíthatja az éles üzemet. Havonta elvégezni sok munkaórába és energiába kerül, és a csapatok végül elnagyolják. Jobb egy alapos éves próba, mint egy havi rituálé, amelyben senki sem nyitja meg az alkalmazást.

Ugyanakkor egy évet várni arra, hogy kiderüljön, egy mentés már nem indul el, túl hosszú idő. Ezért van szükség a gyakori, könnyű technikai ellenőrzésre és a ritka, de teljes üzleti próbára.

Fenntartható ütemterv egy kkv számára

MikorMit
NapontaA sikertelen mentések áttekintése. Egy hibás másolatra épülő DRP maga is hibás
HavontaA tartalékrendszer technikai indítása, az éles üzem leállítása nélkül
NegyedéventeEgy fájl vagy adatbázis visszaállítása, időméréssel
ÉventeValós átállás vagy azzal egyenértékű próba, üzleti felhasználóval és visszaállással
Minden változáskorÚj szerver, új főverzió, a rendszergazda távozása, szolgáltató- vagy internetkapcsolat-váltás

Az erősen szabályozott ágazatok vagy a létfontosságú rendszerek (egészségügy, folyamatos ipari termelés) lerövidítik az „évente” sort, akár félévre is. Ez nem egy szolgáltató kkv minimális követelménye. Az egyes szintek részletei a Hogyan teszteljük a DRP-t? című útmutatóban találhatók.

Ami a gyakoriságnál is fontosabb

Az utolsó próba írásban rögzített dátuma és a kijavított eltérések. Egy tizenegy hónapja, jegyzőkönyvvel tesztelt DRP jobb állapotban van, mint egy „folyamatosan tesztelt” DRP, amelyről semmilyen nyom nem mutatja, mit ellenőriztek. A NIST előírja, hogy minden gyakorlatról jelentés készüljön, amely rögzíti a megfigyeléseket és a fejlesztési javaslatokat.

Ha az utolsó teszt tizenkét hónapnál régebbi, ezt egyenesen közölje a vezetéssel. Ez információ, nem szégyen. A hiba az, ha egy ügyfélnek vagy biztosítónak azt mondjuk, hogy a terv működőképes.

Egy valós incidens után

Egy valódi katasztrófa is teszt, feltéve, hogy egy héten belül jegyzőkönyv készül róla: mi tartott tovább a tervezettnél, mi hiányzott, min változtatunk a tervben. Enélkül kétszer szenvedjük el ugyanazt. Lásd még: Leállt a szerverem: mi a teendő?

A WeDoBacknél

Az indítási ellenőrzés havonta történik, és a DRP része, az éles üzem érintése nélkül: a táblázat „havonta” sorát fedi le a rendszerkép tekintetében, az üzleti művelet tekintetében nem. A valós körülmények közötti teszt legfeljebb tíz óra terjedelemben, árajánlat alapján tervezhető: ez az éves sor természetes jelöltje. Az ajánlat semmilyen eleme nem teszteli Ön helyett az emberi eljárást (ki dönt, hol van a kulcs, hogyan értesítjük a csapatot). Ez a rész a távozások és felvételek ütemét követi, nem a szoftverét.

Gyakori kérdések

Létezik jogszabályi előírás a tesztelés gyakoriságára?

Nincs általános szabály, amely minden kkv-ra vonatkozna. A GDPR (32. cikk) és az ANSSI, a francia kiberbiztonsági ügynökség, „rendszeres” tesztelést követel meg, gyakoriság megadása nélkül. A NIST az amerikai szövetségi rendszerek esetében éves tesztet ír elő. Egyes szabályozott ágazatok, illetve az Ön szerződései és biztosítója sűrűbb ütemet is előírhatnak.

Egy valódi katasztrófa tesztnek számít?

Igen, feltéve, hogy egy héten belül jegyzőkönyv készül róla: mi tartott tovább a tervezettnél, mi hiányzott, mi változik a tervben. Ilyen nyom nélkül az incidens nem segíti a terv javítását.

Mit mondjon egy ügyfélnek vagy biztosítónak, ha az utolsó teszt egy évnél régebbi?

Az igazat, a dátummal együtt. Ha friss próba nélkül jelenti ki, hogy a terv működőképes, a katasztrófa napján szakadék nyílhat az ígéret és a valóság között. Jobb megadni a következő próba tervezett időpontját.

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 28

Vé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.