Biztonsági mentés: hogyan álljon helyre az üzleti rendszer?

Mikor használható valóban egy biztonsági mentés? Gyakorlati helyreállítási terv üzleti rendszerekhez: adatvesztés, időcél, rendszerkapcsolatok és ellenőrzött próba.

Szerző: Buda Sándor · Megjelent: 2026-10-19

A biztonsági mentés akkor segíti a vállalkozást, ha egy hiba után valóban visszaállítható belőle a működés. A sikeres mentési értesítés önmagában nem mondja meg, hogy meglesznek-e a csatolmányok, elindul-e a szoftver, és egyezni fognak-e a rendelések a külső rendszerek adataival.

Ez az útmutató egyedi üzleti szoftverek megrendelőinek és felelőseinek szól. Végigvezet azon, hogyan határozd meg az elfogadható adatvesztést, mit kérj a fejlesztőtől és az üzemeltetőtől, valamint milyen próbával igazold a helyreállítást. A végére egy használható terv vázát kapod, amelyet a saját folyamataidhoz lehet igazítani.

Miért üzleti döntés a biztonsági mentés tervezése?

Egy hétfő reggeli rendszerleállás hatása attól függ, mire használjátok az alkalmazást. Egy belső tudástár rövid kiesése kellemetlen lehet. A kiszállításokat irányító rendszer kiesése viszont megállíthatja a napi munkát. Ugyanaz a mentési beállítás ezért két vállalkozásnál egészen más védelmet jelent.

Először a folyamatot nevezd meg: ajánlatadás, rendelésfeldolgozás, munkalapkezelés vagy ügyfélkiszolgálás. Ezután írd le, kik nem tudnak dolgozni a rendszer nélkül, milyen átmeneti megoldásuk van, és meddig tartható az fenn. A technikai megoldás ezekre a válaszokra épüljön.

Az egyedi üzleti szoftver követelményeinek meghatározásakor a helyreállíthatóság ugyanúgy legyen átadási feltétel, mint egy riport vagy jóváhagyási folyamat működése. Ha csak az élesítés végén kerül szóba, könnyen kimarad hozzá egy fontos adatforrás, hozzáférés vagy tesztkörnyezet.

Két kérdés: mennyi adat és mennyi idő veszhet el?

Az elfogadható adatvesztés: RPO

Az RPO azt fejezi ki, milyen régi állapotig elfogadható visszalépni. Ha a legutolsó használható mentés éjfélkor készült, és délután következik be a hiba, a kettő közötti változásokat más forrásból kell helyreállítani, vagy elveszhetnek. A napi mentés tehát nem feltétlenül felel meg egy egész nap rendeléseket rögzítő rendszernek.

A döntéshez vizsgáld meg, újra előállítható-e az adat. Egy külső rendszerből ismét lekérhető termékleírás más helyzet, mint egy csak nálatok rögzített helyszíni jegyzet. A gyakoriságot a ténylegesen elérhető, ellenőrzött visszaállítási pontok alapján értékeld, ne pusztán a mentési feladat ütemezéséből.

A helyreállítás célideje: RTO

Az RTO a működés visszaállítására kitűzött idő. Ebbe a tervben számítsátok bele az észlelést, a döntést, a szükséges környezet elindítását, az adatok visszatöltését és az üzleti ellenőrzést is. Rögzítsétek, honnan indul az óra, és pontosan milyen működés jelenti a végét.

A „négy órán belül működjön” csak cél, amíg próbán nem igazoltátok. A visszatöltés lehet gyors, de ha a hozzáférés egy szabadságon lévő embernél van, a teljes helyreállítás mégis elhúzódik. Külön kezeljétek a minimálisan használható működést és a teljes szolgáltatás visszatérését.

Mit kell megőrizni az adatbázison túl?

Készíts függőségi leltárt arról, mi szükséges egy üres környezetből történő újrainduláshoz. Ne abból indulj ki, hogy minden egy szerveren található. A dokumentumok, a bejelentkezés, az e-mail-küldés és a háttérfeladatok külön szolgáltatásban is működhetnek.

• Üzleti adatok: ügyfelek, rendelések, állapotok, kapcsolatok és az értelmezésükhöz szükséges törzsadatok.
• Fájlok: feltöltött dokumentumok, képek, aláírások és olyan mellékletek, amelyeket nem lehet újragenerálni.
• Alkalmazásverzió: a mentett adatszerkezettel együtt használható kiadás és a telepítés dokumentációja.
• Beállítások: környezeti konfiguráció, időzítések, domain- és szolgáltatásfüggőségek leírása.
• Hozzáférések: a szükséges jogosultságok és titkosítási kulcsok biztonságos elérési módja, kijelölt felelőssel.
• Folyamatállapotok: folyamatban lévő importok, kiküldések és külső műveletek egyeztetéséhez szükséges nyilvántartás.

A leltár nem jelent egyetlen közös, mindent tartalmazó fájlt. A titkokat külön, megfelelően védett rendszerben kell kezelni. A helyreállítási dokumentumban azt írd le, hogy a jogosult személy hogyan éri el őket; jelszavakat ne másolj egy szabadon megosztott munkafüzetbe.

Fontos az összetartozó adatok időbeli összhangja is. Ha az adatbázis egy dokumentumra hivatkozik, de a fájlmentésből az hiányzik, a felület akár hibátlanul elindulhat, miközben a munka nem folytatható. Ezt a kockázatot a mentési eljárásban és a próbában egyaránt kezelni kell.

Miért nem helyettesíti a mentést a szinkronizálás?

A szinkronizálás célja jellemzően az állapotok egyeztetése. Emiatt egy téves törlés vagy hibás módosítás is továbbterjedhet. A második példány ilyenkor ugyanazt a hibát tartalmazza. A mentés értéke abban is áll, hogy korábbi, kiválasztható állapotot őriz meg.

A rendelkezésre állást növelő másodlagos kiszolgáló, a forráskód tárolása és az adatmentés külön problémákat old meg. A kódtárból újratelepíthető lehet az alkalmazás, de abból nem kerülnek vissza a tegnapi ügyféladatok. A másodlagos kiszolgáló pedig nem feltétlenül véd a logikai hibák ellen.

A CISA helyreállítási és zsarolóvírus-megelőzési útmutatója offline, titkosított mentést és rendszeres helyreállítási ellenőrzést is javasol. Ennek gyakorlati üzenete: a mentés ne legyen ugyanolyan könnyen törölhető vagy módosítható ugyanazzal a hozzáféréssel, mint az éles adat. A konkrét elkülönítést a rendszerhez kell megtervezni.

Kitölthető helyreállítási adatlap: egy rendelési példa

Az alábbi helyzet szemléltető példa, nem BudaWeb-ügyfélprojekt és nem teljesítményígéret. Egy vállalkozás belső rendszerben fogadja a rendeléseket, majd továbbítja őket a raktárnak. Hiba esetén rövid ideig kézi átvételt tud szervezni, de minden beérkezést egyértelműen azonosítania kell.

1. Kritikus folyamat: új rendelés rögzítése, visszakeresése és raktári átadása.
2. Adatvesztési cél: legfeljebb harmincpercnyi változást kelljen más forrásból egyeztetni; a megvalósíthatóságot a műszaki terv és próba igazolja.
3. Időcél: a kiesés kezdetétől négy órán belül legyen ellenőrzött rendelésfeldolgozás; a teljes riportkészítés később is visszatérhet.
4. Felelősök: az üzemeltető vezeti a technikai helyreállítást, az operációs vezető ellenőrzi a rendelési folyamatot.
5. Ideiglenes működés: kijelölt, védett nyilvántartás egyedi rendelésazonosítóval és későbbi egyeztetési felelőssel.
6. Elfogadás: ellenőrzött mintarendelések, hozzájuk tartozó dokumentumok, helyes jogosultságok és egyeztetett raktári státuszok.

Az adatlap mellé írjátok oda a legutóbbi próba dátumát és mért eredményét. Ha a négyórás cél mellett hatórás eredmény születik, az eltérés legyen látható. Ekkor a technikai megoldáson, a folyamaton vagy az üzleti elváráson kell változtatni, majd újra ellenőrizni.

A visszaállítás után a rendszerkapcsolatokat is egyeztetni kell

A belső alkalmazás visszaállítása nem forgatja vissza automatikusan a külvilágot. Egy értesítés már kimehetett, egy csomag átadásra kerülhetett, miközben a visszatöltött állapot ezekről még nem tud. Ha az automatizmus gondolkodás nélkül újrafut, megismételheti a műveletet.

A CRM-folyamatok és automatizált utánkövetések kialakításánál ezért legyen rögzítve, mely külső események tényét kell visszaellenőrizni. Egy korábbi állapot visszaállítása után ne induljon újra ellenőrzés nélkül minden emlékeztető és ügyfélértesítés.

Az egyeztetéshez használható egyedi üzleti azonosító, a külső rendszerben tárolt státusz és feldolgozási nyilvántartás. A fejlesztővel tisztázzátok, mely műveletek ismételhetők biztonságosan, és hol szükséges kézi döntés. Ezt valósághű próbával érdemes ellenőrizni, nem pusztán az integráció leírásából feltételezni.

A háttérfeladatok újraindításának sorrendje

Elsőként az adatokat és a fontos üzleti állapotokat ellenőrizzétek. Ezután, felügyelten induljanak újra a várakozó feladatok. Egy Laravel-alapú háttérrendszer fejlesztésénél például a sorban álló feldolgozások és az időzített műveletek visszaindítását is a helyreállítási eljárás részévé kell tenni.

A pontos sorrend rendszerfüggő. A tervben azonban egyértelműen szerepeljen, ki engedélyezi az újraindulást, milyen feltételekkel, és mit kell figyelni az első feldolgozások alatt. A „minden szolgáltatás fut” állapot még nem igazolja, hogy az üzleti folyamat helyesen folytatódik.

Hogyan zajlik egy használható visszaállítási próba?

A próbát elkülönített környezetben végezzétek, a szükséges hozzáférési korlátozásokkal. A visszatöltött adatok ugyanolyan érzékenyek lehetnek, mint az éles adatok. A tesztkörnyezet ne küldjön valódi ügyféllevelet, ne indítson fizetést, és ne írjon engedély nélkül éles külső rendszerbe.

Induljatok egy konkrét hibaforgatókönyvből: például sérült adatállományból vagy elveszett kiszolgálóból. Válasszátok ki a megfelelő mentési pontot, majd a dokumentáció alapján építsétek fel a működő állapotot. Mérjétek az egyes szakaszokat, beleértve a hozzáférések megszerzését és az üzleti ellenőrzést.

Ne csak azt nézzétek meg, hogy lehet-e bejelentkezni. Keressetek vissza ismert ügyletet, nyissatok meg csatolmányt, ellenőrizzetek jogosultságot, majd futtassatok le egy teljes, tesztként elkülönített munkafolyamatot. Az összesített darabszám mellett néhány fontos rekord tartalmi ellenőrzése is szükséges.

A jegyzőkönyvben szerepeljen a mentés időpontja, a használt alkalmazásverzió, a mért helyreállítási idő, a vizsgált esetek és minden eltérés. Minden hibához legyen felelős, javítási határidő és ismételt ellenőrzés. A próba értéke éppen az, hogy még valódi kiesés előtt mutatja meg a hiányokat.

Miből látszik időben, hogy baj van a mentéssel?

A felügyelet ne csak a hibásan lefutó feladatot jelezze. Az elmaradó mentés is probléma: előfordulhat, hogy a feladat el sem indult, ezért hibajelzést sem küldött. Legyen ellenőrizhető a legutolsó sikeres mentés kora, a védett adatkör és a következő próba esedékessége.

A riasztásnak legyen címzettje és helyettese, valamint egyértelmű intézkedési rendje. Ha minden nap ugyanaz a figyelmeztetés érkezik következmény nélkül, a felügyelet elveszíti az értelmét. A kivételeket dokumentáljátok, és javítás után ellenőrizzétek, hogy ismét rendelkezésre áll-e használható mentés.

A próbák gyakoriságát az üzleti kockázat és a változások határozzák meg. Nagyobb verzióváltás, új fájltároló, új integráció vagy jelentős adatnövekedés után külön ellenőrzés lehet szükséges. A korábbi gyors visszatöltésből nem következik automatikusan, hogy a többszörös adatmennyiség is belefér ugyanabba az időkeretbe.

Mit egyeztess a fejlesztővel és az üzemeltetővel?

Válasszátok külön a mentés elkészítését, a tárolás felügyeletét és a helyreállítás végrehajtását. Ezek külön szereplőhöz is tartozhatnak. A szolgáltatói ajánlatban szereplő „napi backup” mellé kérj pontos adatkört, megőrzési időt, elérési feltételeket és leírást arról, mit vállalnak hiba esetén.

Kérdezz rá arra is, ki fizeti és szervezi a próbához szükséges környezetet, mikor elérhető a helyreállítást végző csapat, és milyen dokumentációt kaptok. Ha a vállalkozás munkaidőn kívül is működik, a kizárólag munkaidős segítség nem feltétlenül egyezik a kitűzött helyreállítási céllal.

A megőrzést ne határozatlan „mindent örökre” elv szerint tervezzétek. Legyen indokolt időtáv, több szükséges visszaállítási pont és szabályozott hozzáférés. A részleteket az üzleti igényekkel és az alkalmazandó adatkezelési követelményekkel együtt kell meghatározni.

Tízpontos ellenőrzőlista a következő egyeztetésre

• Megneveztük a kieséskor elsőként helyreállítandó üzleti folyamatot.
• Rögzítettük az elfogadható adatvesztést és a helyreállítás időcélját.
• A leltár az adatbázison túl a fájlokat és függőségeket is tartalmazza.
• Van az éles rendszertől megfelelően elkülönített mentési példány.
• A hozzáférések és kulcsok jogosult helyettes számára is elérhetők.
• Az elmaradt és a sikertelen mentésről is érkezik kezelhető jelzés.
• A tesztkörnyezet nem indít valódi külső üzleti műveleteket.
• Ismert a külső rendszerek és a várakozó feladatok egyeztetési sorrendje.
• A legutóbbi visszaállítási próbának van dátuma, eredménye és hibajegyzéke.
• Kijelöltük a következő ellenőrzés felelősét és időpontját.

Összegzés: a helyreállítható működés legyen az eredmény

A jól megtervezett biztonsági mentés mögött üzleti cél, teljes adatkör, védett tárolás és kipróbált visszaállítás áll. A legfontosabb kérdés nem az, hogy készült-e valamilyen másolat, hanem az, hogy a csapat ellenőrzött adatokkal, vállalható időn belül folytathatja-e a munkát.

Kezdésként válassz ki egy kritikus folyamatot, töltsd ki hozzá a helyreállítási adatlapot, és szervezz dokumentált próbát. Ha új rendszert tervezel vagy meglévő alkalmazást fejlesztenél tovább, a BudaWeb egyedi szoftverfejlesztési egyeztetésére hozd el ezt a folyamatot, a függőségi listát és a megengedhető kiesésre vonatkozó elvárásaidat. Így a mentés és helyreállítás konkrét, ellenőrizhető követelménnyé válhat.