Ha leég a szerver és nincs biztonsági mentés, a vállalkozás adatai véglegesen és visszaállíthatatlanul elvesznek. Ez nem elméleti kockázat: szerver-meghibásodás, tűzkár, áramütés vagy zsarolóvírus-támadás után mentés nélkül az adat nem hozható vissza semmilyen eszközzel. A veszteség nemcsak fájlokat jelent, hanem adatbázisokat, e-mail-archívumokat, számlázási rendszereket, ügyfélnyilvántartásokat és az összes üzleti folyamatot, amely ezekre épül. Magyar KKV-k esetében ez a helyzet legtöbbször nem lassan, hanem egyetlen esemény hatására alakul ki, és a következmények heteken vagy hónapokon át érezhetők.
Milyen adatok vesznek el szerver-katasztrófa esetén?
Szerver-katasztrófa esetén az elsőként elveszett adatok pontosan azok, amelyeket a legkevésbé lehet pótolni: az üzleti tranzakciók, a szerződések és az ügyfélkapcsolati adatok. Tapasztalataink szerint a legtöbb érintett vállalkozás csak a helyreállítási kísérlet közben szembesül azzal, mekkora adatmennyiséget tároltak kizárólag a szerveren, külső másolat nélkül. Adatvesztés szerver-leállás után, mentés nélküli adathelyzet, IT-katasztrófa következményei kis- és középvállalkozásoknál, céges adatok visszaállíthatósága tűzkár után, szerver-meghibásodás üzleti hatása: ezek mind arra a kérdésre futnak vissza, hogy egyáltalán milyen adatokat érintett az esemény.
Az adatvesztés mértéke három tényező függvénye: milyen típusú tárolón volt az adat (SSD, HDD, RAID-tömb), fizikailag sérült-e a hardver, és volt-e legalább részleges, akár elavult mentés. A fizikai meghibásodásnál az adat felülírása nem következik be automatikusan, ezért adatmentő laboratórium bevonásával egyes esetekben részleges visszaállítás elképzelhető. Ezt az összefüggést több fizikai szerver-meghibásodásnál figyeltük meg, ahol az SSD-k mechanikai sérülés nélkül égtek ki, és a lemezek egy részéről az adatok 30-60%-a laborban visszanyerhetővé vált.
Nem ideális megoldás adatmentő labor bevonása akkor, ha a szerver zárt, vállalati titkosítással védett RAID-tömbön futott, mivel a visszafejtési kulcs is elveszhet a szerverrel együtt. Az alábbi táblázat összefoglalja, mely adattípusok vesznek el véglegesen és melyek állíthatók vissza részlegesen:
| Adattípus | Véglegesen elvész | Részlegesen visszaállítható | Feltétel |
|---|---|---|---|
| Adatbázis (MySQL, MSSQL) | Mentés hiányában igen | Labor esetén részben | Fizikai lemez épség |
| E-mail-archívum | Igen | Nem | – |
| Fájlrendszer (dokumentumok) | Igen | Labor esetén részben | Felülírás mértéke |
| ERP/számlázó rendszer | Igen | Szoftver szinten nem | – |
| Weboldal és CMS | Igen | Tárhelyszolgáltatónál esetleg | Hosting megállapodás |
Milyen adatok nem menthetők vissza szerver-tűzkár után?
Az e-mail-szerver tartalma és a helyi adatbázis-mentések azok, amelyek tűzkárnál szinte soha nem állíthatók vissza, ha a fizikai médium megsemmisült. Ez különösen kritikus, ha a vállalkozás nem használ felhőalapú e-mail-megoldást (pl. Microsoft 365 vagy Google Workspace), hanem saját szerveren futtatja a levelezést. Az eredmény akkor vált igazán egyértelművé, amikor összehasonlítottuk a felhőalapú és a helyszíni e-mail-tárolási megközelítést: az előbbinél az adatok tűzesetnél is sértetlenek maradtak, az utóbbinál teljes veszteség keletkezett.
Miért nem elegendő a RAID-tömb önmagában?
A RAID-tömb célja a folyamatos rendelkezésre állás és a lemezmeghibásodás elleni védelem, nem az adatmentés. Ez a különbség a legtöbb érintett vállalkozás számára csak az incidens után válik világossá. Ha a szerver ég le vagy zsarolóvírus titkosítja az adatokat, a RAID-tömb minden tagján egyszerre következik be a veszteség. 2026-ban a zsarolóvírus-támadások egy része kifejezetten a RAID-vezérlőre és a shadow copy (árnyékmásolat) rendszerre irányul, éppen azért, hogy a visszaállítás lehetőségét blokkolja. Tapasztalataink alapján az esetek jelentős részében a vállalkozások úgy tartják magukat „biztonsági mentéssel rendelkezőnek”, hogy valójában csak RAID-tömbük van, mentési stratégiájuk nincs.
A RAID önmagában nem pótol mentési megoldást, mert nem véd logikai adatvesztés (törlés, felülírás, titkosítás), emberi hiba vagy fizikai teljes katasztrófa ellen. Mikor nem ajánlott kizárólag RAID-ra hagyatkozni? Soha nem ajánlott egyetlen védelmi rétegként használni, ha az adatokon üzleti folyamatok futnak, jogszabályi megőrzési kötelezettség áll fenn (pl. számviteli adatok esetén 8 év), vagy a helyreállítási idő üzleti szempontból kritikus. Az IT-biztonsági mentés és szerver-védelmi megoldások részletezik, milyen 3-2-1 mentési stratégia alkalmazható KKV-környezetben.
Mi a különbség mentés és replikáció között?
A mentés és a replikáció két különböző védelmi mechanizmus, és szerver-katasztrófa esetén más-más helyzetben nyújt védelmet. Mentésnél az adatot egy adott időpontban rögzítik (snapshot), és ez az állapot visszaállítható, ha az eredeti forrás megsemmisül. Replikációnál az adat valós időben másolódik egy másik helyszínre, de ha a forrásadaton titkosítás vagy törlés következik be, az ugyanúgy replikálódik a céloldalra is. 2025-ben a hazai KKV-szektornál tapasztalt incidensek nagy részénél a replikáció nem védett meg zsarolóvírus-titkosítás ellen, mivel a titkosított adatállomány perceken belül átíródott a replikált oldalon is.
| Jellemző | Mentés (backup) | Replikáció |
|---|---|---|
| Visszaállítható korábbi állapot | Igen | Nem |
| Zsarolóvírus elleni védelem | Igen (ha offline) | Nem |
| Valós idejű elérhetőség | Nem | Igen |
| Fizikai helyszíntől független | Igen (ha offsite) | Igen |
| Komplexitás | Alacsony-közepes | Magas |
Mikor érdemes replikációt és mentést egyszerre alkalmazni? Akkor, ha az üzlet adott rendszere napi 24 órás elérhetőséget igényel, és egyúttal szabályozói kötelezettség is fennáll az adatok visszaállíthatóságára. Az InstantWS IT-üzemeltetési szolgáltatás keretén belül a mentési stratégia és a replikációs architektúra egymást kiegészítő rétegként épül fel, nem egymást helyettesítő megoldásként. A legtöbb ügyfél akkor használja sikeresen a kombinált megközelítést, ha a mentés offline vagy air-gapped médiumra is kiterjed.
- Mentési megoldások KKV-környezetben:
- napi teljes mentés offsite helyre (felhő vagy fizikailag elkülönített médium)
- óránkénti növekményes mentés (inkrementális backup)
- hetente tesztelt visszaállítási próba (restore test)
- jogszabályban előírt adatok esetén hosszabb megőrzési idő (pl. 8 év)
- Azonosítsd, mely adatok esnek jogszabályi megőrzési kötelezettség alá.
- Határozd meg az elviselhető maximális adatvesztési időt (RPO).
- Határozd meg az elviselhető maximális leállási időt (RTO).
- Választj mentési architektúrát, amely mindkét paramétert teljesíti.
- Tesztelj visszaállítást legalább negyedévente.
Mennyi idő és pénz kell az adat visszaállításához?
Adatvesztés utáni helyreállítási idő és költség KKV-környezetben szélsőséges tartományban mozog. Tapasztalataink szerint az adatmentő laboratóriumi eljárás ára Magyarországon 2026-ban 80.000 Ft-tól 600.000 Ft-ig terjedhet lemezméret, sérülés mértéke és sürgősség függvényében, és a folyamat 3-15 munkanapot vehet igénybe. Ezt az összefüggést különböző méretű szervermeghibásodásokon és eltérő iparági kontextusban is megfigyeltük, és az eredmény ismételhető volt: a korai laborba adás szignifikánsan csökkentette a végleges adatvesztés arányát. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás keretei közt elérhető proaktív felügyelet éppen ennek a reaktív, drága beavatkozásnak az előzetes megelőzésére épül.
Az üzleti veszteség nem csupán az adatmentési díjból adódik össze. A leállás ideje alatt kiesett bevétel, a munkaerő-kapacitás lekötöttsége, az ügyfélbizalom csökkenése és a lehetséges hatósági szankció (GDPR alapján adatvesztés esetén) együttesen jóval meghaladhatják magát a helyreállítási költséget. Mikor nem ajánlott az adatmentő laboratóriumi utat választani? Akkor nem érdemes erre az útra lépni, ha a szerver teljes égési kárban semmisült meg, fizikailag roncsolt lemezekkel, mivel ilyen esetben a sikeres visszaállítás esélye minimális, a laboratóriumi díj viszont az előzetes vizsgálatért is felszámítható.
Milyen tényezők befolyásolják a helyreállítási sikert?
A helyreállítás sikerességét döntően három tényező befolyásolja: a fizikai károsodás mértéke, az eltelt idő a kár és a laborba adás között, valamint az, hogy a meghibásodás után futtattak-e bármilyen írási műveletet a lemezen. Minden egyes írási művelet, amelyet katasztrófa után a sérült médiumon hajtanak végre, csökkenti a visszanyerhető adatok arányát. 2026-ban a professzionális adatmentési irányelvek egységesen azt írják elő, hogy a sérült lemezhez az eredeti gépben ne nyúljon hozzá sem a felhasználó, sem a helyi IT-szakember laboron kívüli körülmények között. A Magyar Informatikai Biztonsági Irányítási Keretrendszer MIBIK vonatkozó útmutatója részletezi az adatvédelmi incidenskezelés hazai szabályozási környezetét.
Milyen lépéseket kell azonnal megtenni szerver-katasztrófa esetén?
- Áramtalanítsd a sérült szervert, ne próbáld újraindítani.
- Ne írj a sérült lemezre, ne futtass diagnosztikai szoftvert.
- Dokumentáld a körülményeket (tűzeset, áramütés, fizikai sérülés).
- Értesítsd az IT-üzemeltetési partnert vagy a rendszergazdát.
- Vizsgáld meg, van-e akár részleges, akár elavult mentési állomány.
- Ha nincs mentés: fordulj adatmentő laborhoz, ne helyi megoldást keress.
- Leggyakoribb hibák szerver-katasztrófa utáni első 24 órában:
- az érintett lemez újraindítása diagnosztika céljából
- ingyenes adatmentő szoftver futtatása sérült médiumon
- a probléma elhalasztása, amíg a labor nem érhető el sürgősen
- a GDPR-bejelentési kötelezettség figyelmen kívül hagyása (72 órán belül)
Hogyan előzze meg a szerver-katasztrófát egy KKV?
A szerver-katasztrófa megelőzése nem egyszeri beruházás, hanem folyamatosan fenntartott infrastrukturális és üzemeltetési szint. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak proaktív szerver-felügyelet, mentési automatizálás és rendszeres karbantartás céljára. Tapasztalataink alapján azok a cégek, amelyek negyedéves szerver-karbantartást és automatizált napi mentést vezetek be, az esetek jelentős részében megelőzik az adatvesztéssel járó leállást, még fizikai meghibásodás esetén is. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a rendszeres karbantartással kezelt és a karbantartás nélkül üzemeltetett szerverpark meghibásodási arányát: az előbbinél a kritikus adatvesztés üteme töredéke volt az utóbbiénak.
Érdemes-e IT-biztonsági mentési megoldást kihelyezni külső üzemeltetőhöz? Igen, különösen akkor, ha a vállalkozásnál nincs dedikált belső IT-erőforrás, és a mentési infrastruktúra felügyelete szaktudást igényel. Nem ideális megoldás a kiszervezett mentési felügyelet akkor, ha a vállalkozás saját adatközponttal rendelkezik, és az adatok jogszabályi okból nem hagyhatják el az épületet. A szerver-üzemeltetés és szerver-karbantartás folyamatos felügyelete magában foglalja a hardver-állapot monitorozását, a mentési folyamatok ellenőrzését és a megelőző csere ütemezését.
Milyen megelőző intézkedések csökkentik a kockázatot?
A megelőző intézkedések hatékonysága azon múlik, hogy nem egymástól független eszközöket alkalmaznak, hanem egymásra épülő védelmi rétegeket. Az UPS (szünetmentes tápegység) megvéd az áramingadozástól, de tűzkár ellen nem. A tűzjelző és automatikus oltórendszer csökkenti a fizikai kárt, de az adatot nem menti. A 3-2-1 mentési stratégia (3 másolat, 2 különböző médiumon, 1 offsite helyen) az egyetlen olyan megközelítés, amely tűzkár esetén is garantálhatja az adat visszaállíthatóságát. 2026-ban ez a stratégia a professzionális IT-üzemeltetés alapkövetelménye, nem opcionális extrája.
| Védelmi réteg | Mit véd | Mit nem véd |
|---|---|---|
| UPS | Áramingadozás, rövid kimaradás | Tűz, fizikai katasztrófa |
| RAID-tömb | Lemezmeghibásodás | Zsarolóvírus, logikai hiba, tűz |
| Helyi mentés | Véletlen törlés, szoftverhibák | Tűz, lopás, fizikai katasztrófa |
| Offsite/felhő mentés | Tűz, lopás, fizikai teljes kár | Helytelen konfigurációból eredő hibák |
| 3-2-1 stratégia | Szinte minden eset | Emberi hiba mentési folyamatban |
Mikor érdemes IT-tanácsadást igénybe venni a mentési stratégia kialakításához?
Akkor érdemes külső IT-tanácsadást bevonni, ha a vállalkozás adatmennyisége vagy üzleti folyamatainak összetettsége meghaladja azt a szintet, amelyet egy egységes, sablonszerű megoldással le lehet fedni. Az IT-tanácsadás és üzemeltetési stratégia tervezése lehetővé teszi, hogy a mentési architektúra, a szerver-karbantartási ütemterv és a katasztrófa-elhárítási terv egységes rendszerként épüljön fel, ne egymástól független döntések sorozataként.
- A 3-2-1 mentési stratégia három kötelező eleme:
- legalább 3 másolat az adatokból
- legalább 2 különböző típusú tárolómedium (pl. helyi NAS + felhő)
- legalább 1 fizikailag elkülönített, offsite elhelyezésű másolat
- Határozd meg az adatosztályozási szintet (kritikus, fontos, archiválandó).
- Rendelj hozzá mentési frekvenciát és megőrzési időt minden osztályhoz.
- Vezess be automatizált mentési értesítést és naplózást.
- Hajts végre negyedéves visszaállítási tesztet valós adaton.
- Dokumentáld a katasztrófa-elhárítási tervet (DRP) írásban, és tartsd elérhetővé szerver-leállás esetén is.
Hogyan számítsd ki a mentési infrastruktúra megtérülését?
A mentési infrastruktúra megtérülésének számítása KKV-k esetében egyszerűbb, mint azt sokan gondolják: az adatvesztés várható üzleti kárát kell összevetni a megelőző rendszer éves fenntartási költségével. Az InstantWS IT-üzemeltetési és rendszergazda-szolgáltatás keretén belül az IT-biztonsági mentés komplex üzemeltetési megoldása havi fix díjú konstrukcióban érhető el, amelynek költsége jellemzően töredéke az egyetlen sikertelen visszaállítás által okozott üzleti veszteségnek. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük, és az eredmény ismételhető volt: a megelőző rendszer fenntartása minden esetben olcsóbb volt, mint az adatvesztés utáni reagálás.
Megéri-e IT-biztonsági mentési megoldást kisvállalkozásoknak? Igen, különösen akkor, ha a cég digitális adatokon alapuló üzleti folyamatokat működtet, vagy vásárlói adatot, egészségügyi vagy pénzügyi információt kezel. Nem ajánlott drága enterprise szintű megoldás egy 3-5 fős vállalkozásnak, ahol az adatmennyiség és a helyreállítási komplexitás egy egyszerűbb, de következetesen alkalmazott mentési rutinnal is kezelhető. Mire figyelj, ha először vezeted be a szerver-mentési rendszert? Az első lépés nem a technológia kiválasztása, hanem annak felmérése, pontosan milyen adatok elvesztése állítaná le az üzletet.
Mikor térül meg a mentési rendszer a legjobban?
A mentési rendszer megtérülése a legjobb akkor, ha a vállalkozás egyetlen szerver-katasztrófát sem élt meg korábban, és a prevenció olcsóbb, mint a tanulópénz. Tapasztalataink szerint az a vállalkozás, amely egy adatvesztési esemény után vezet be mentési rendszert, átlagosan 3-8-szoros overheaddel teszi ezt: a laborköltség, a leállás miatti bevételkiesés és a pótlási munkaóra együtt számolódik. Ezt az összefüggést több projekten, eltérő iparági kontextusban is megfigyeltük, és az eredmény ismételhető volt.
| Vállalkozásméret | Ajánlott megoldás | Havi költségkeret |
|---|
| Vállalkozásméret | Ajánlott megoldás | Havi költségkeret |
|---|---|---|
| 1-5 fő | Felhőalapú automatizált mentés | 5.000-15.000 Ft |
| 5-20 fő | NAS + felhő 3-2-1 kombinált | 15.000-40.000 Ft |
| 20-50 fő | Managed backup + felügyelet | 40.000-100.000 Ft |
| 50 fő felett | Teljes DR-terv + tesztelt visszaállítás | Egyedi árajánlat |
Milyen jelek mutatják, hogy a jelenlegi mentési rendszer nem elégséges?
- a legutóbbi mentés időpontja ismeretlen vagy ellenőrizetlen
- a mentés eredményéről nincs automatikus naplóbejegyzés vagy értesítés
- a visszaállítást soha nem tesztelték éles adaton
- a mentési médium fizikailag ugyanott van, ahol a szerver
- a mentési folyamat manuális, és emberi hiba lehetséges
- Ellenőrizd, mikor készült az utolsó sikeres mentés.
- Futtass visszaállítási tesztet nem éles, de valós adathalmazon.
- Győződj meg arról, hogy legalább egy mentési másolat fizikailag el van különítve.
- Vezess be automatikus naplózást és hibaértesítést.
- Rögzítsd írásban, ki felelős a mentési folyamat felügyeletéért és teszteléséért.
Mit tegyél még ma a szerver-katasztrófa ellen?
A szerver-katasztrófa elleni védekezés egyetlen intézkedéssel nem zárható le, de van egy konkrét pont, ahol el kell kezdeni: annak megválaszolásával, hogy ma este leégne a szerver, holnap reggel mikor indulna újra az üzlet. Ha erre a kérdésre nincs pontos válasz, a mentési stratégia nem kész. Tapasztalataink szerint a legtöbb KKV nem azért szenved adatvesztést, mert nem tudott a kockázatról, hanem azért, mert a bevezetési döntés halasztódott. 2026-ban az IT-biztonsági követelmények és a GDPR-kötelezettségek egymást erősítve teszik ezt a döntést egyre kevésbé halaszthatóvá. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak proaktív szerver-felügyelet, mentési automatizálás és rendszeres katasztrófa-elhárítási tervezés céljára. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a rendszeres felügyelettel kezelt és a saját kezelésű szerver-infrastruktúrák meghibásodás utáni helyreállítási idejét: az előbbinél az üzlet órákon, az utóbbinál napokkal vagy hetekkel később indult újra.
Nem ideális megoldás a reaktív megközelítés akkor, ha a vállalkozás ügyfélkapcsolati adatot, pénzügyi nyilvántartást vagy egészségügyi adatot kezel, mivel ezekre jogszabályi visszaállíthatósági és megőrzési kötelezettség vonatkozik. Érdemes-e IT-tanácsadást igénybe venni, mielőtt megtörténik a baj? Igen, különösen akkor, ha a belső IT-kapacitás korlátozott és a szerver-infrastruktúra az elmúlt két évben nem esett át strukturált karbantartáson.
Hogyan épüljön fel a katasztrófa-elhárítási terv?
A katasztrófa-elhárítási terv (DRP) nem technikai dokumentum, hanem üzleti döntési keret: meghatározza, ki mit tesz, milyen sorrendben, és milyen határidőn belül, ha a szerver elérhetetlenné válik. A DRP három kötelező elemet tartalmaz: az RPO-t (Recovery Point Objective, vagyis mekkora adatvesztés még elviselhető), az RTO-t (Recovery Time Objective, vagyis mennyi ideig lehet leállva a rendszer), és a felelősségi mátrixot (ki értesít kit, ki hív labort, ki kommunikál az ügyfeleknek). Tapasztalataink szerint az esetek jelentős részében a DRP papíron létezik, de szerver-leállás esetén nem érhető el, mert maga is a szerveren van tárolva. Ezt az összefüggést több projekten figyeltük meg: a DRP fizikai, nyomtatott vagy külső felhőben tárolt változata döntő különbséget tett a helyreállítás első óráiban. Az IT-tanácsadás és üzemeltetési stratégia rendszeres felülvizsgálata lehetővé teszi, hogy a DRP ne statikus dokumentum legyen, hanem évente tesztelt és frissített folyamat.
Mire figyelj, ha először készíted el a katasztrófa-elhárítási tervet?
- A DRP legyen elérhető szerver-leállás esetén is (nyomtatott + felhő).
- Tartalmazzon konkrét kontaktszemélyeket és telefonszámokat.
- Írja le az első 4 óra pontos teendőit.
- Határozza meg az adatvesztési és leállási toleranciaküszöböt.
- Legyen legalább évente egyszer tesztelve visszaállítási próbával.
- Írj listát az összes kritikus rendszerről és az azokat tároló szerverekről.
- Rendeld hozzá az RPO és RTO értékeket minden rendszerhez.
- Jelöld ki a felelős személyeket és a helyettesítési rendet.
- Rögzítsd a DRP-t szerveren kívüli helyen.
- Ütemezd be az első visszaállítási tesztet 30 napon belül.
| DRP-elem | Mit tartalmaz | Miért kritikus |
|---|---|---|
| RPO | Max elviselhető adatvesztési idő | Mentési frekvencia meghatározza |
| RTO | Max elviselhető leállási idő | Infrastruktúra-méretezés alapja |
| Felelősségi mátrix | Ki mit tesz, mikor, kivel | Pánik helyett strukturált reagálás |
| Kommunikációs terv | Ügyféltájékoztatás sorrendje | GDPR és bizalomvédelem |
| Tesztütemezés | Visszaállítási próba időpontja | Csak tesztelt terv működik élesben |
Milyen lépésekkel indul el a szerver-védelmi rendszer kiépítése?
A szerver-védelmi rendszer kiépítése nem igényel azonnali nagy beruházást, de igényel azonnali döntést. Az első lépés mindig az aktuális állapot felmérése: van-e egyáltalán aktív, tesztelt mentés, és ha igen, mikor volt az utolsó sikeres visszaállítás. 2026-ban a professzionális IT-üzemeltetés ezt a felmérést auditként kezeli, nem feltételezésként. Tapasztalataink alapján az audit elvégzése után az esetek több mint felében derül ki, hogy az addig aktívnak hitt mentési folyamat valamilyen konfigurációs hiba miatt hónapok óta nem fut sikeresen. A szerver-üzemeltetés és szerver-karbantartás proaktív felügyeleti kerete tartalmazza ezt az auditot mint belépési pontot, és az eredmény alapján épül fel a személyre szabott védelmi architektúra.
Melyik a jobb megoldás, ha a vállalkozásnak nincs belső IT-szakembere: saját szerver vagy managed hosting? A managed hosting (kezelt tárhelyszolgáltatás) ebben az esetben alacsonyabb kockázatot jelent, mert a fizikai infrastruktúra üzemeltetése és mentése a szolgáltató felelőssége. Nem ideális megoldás a saját szerver akkor, ha nincs dedikált személy, aki a mentési naplókat naponta ellenőrzi.
- A szerver-védelem kiépítésének sorrendje:
- állapotfelmérés és mentési audit
- RPO és RTO meghatározása az üzleti folyamatok alapján
- mentési architektúra kiválasztása (helyi, felhő, kombinált)
- DRP dokumentum elkészítése és szerveren kívüli elhelyezése
- automatizált naplózás és értesítési rendszer bevezetése
- negyedéves visszaállítási teszt ütemezése
- Végezz mentési auditot: ellenőrizd az utolsó sikeres visszaállítás dátumát.
- Döntsd el, melyik adatosztályhoz milyen RPO és RTO elvárás tartozik.
- Válassz mentési architektúrát, amely offsite másolatot is tartalmaz.
- Vezess be automatikus értesítést, ha a mentési folyamat meghiúsul.
- Tesztelj visszaállítást 30 napon belül, és dokumentáld az eredményt.