3-2-1 biztonsági mentés a gyakorlatban: mit ér önmagában a tárhelyes backup?
A visszaállított staging oldal betölt, de a tegnapi rendelés hiányzik az adatbázisból. A biztonsági mentés megvan, a helyreállítás útja viszont még nincs bizonyítva.
A biztonsági mentésnél a 3-2-1 szabály három adatpéldányt, két eltérő tárolási típust és egy elkülönített, külső helyen őrzött másolatot ír elő. A tárhelyszolgáltató backupja fontos réteg, de önmagában nem igazolja mindhárom feltételt vagy a sikeres visszaállítást.
Fejlesztőként vagy ügynökségként ne csak azt kérdezd meg, készült-e mentés. Azt is tudd, mi van benne, hol találod, ki fér hozzá, és mennyi idő alatt áll helyre belőle a webhely. Nézzük meg, hogyan lesz a szolgáltatói mentésből egy ellenőrizhető backup stratégia.
Mit jelent a 3-2-1 szabály a biztonsági mentésnél?
A 3-2-1 mentési szabály adatvédelmi irányelv, amely szerint a fontos adatokról három példányt tartasz, legalább két különböző tárolási típuson vagy rendszeren, és egy másolatot az elsődleges helyszíntől elkülönítve őrzöl. Célja, hogy egy eszköz, fiók, hozzáférés vagy helyszín hibája ne tüntessen el minden visszaállítható verziót.
Mit jelent a három példány és a két tárolási típus a gyakorlatban?
Egy webes rendszerben az első példány maga az éles webhely és az aktuális adatbázis. A második lehet egy automatikus szolgáltatói mentés, a harmadik pedig egy külön kezelt offsite mentés, amely nem ugyanattól az egyetlen tárhelyfióktól függ. A három példány tehát nem feltétlenül három manuálisan másolt mappát jelent.
A két tárolási típus sem két almappa ugyanazon a tárhelyen. Két mappa, két fájlnév vagy két mentési dátum nem ad önmagában független védelmet, ha ugyanaz a meghajtó, fiók vagy adminisztrátori hozzáférés mindkettőt eléri. A másolatok elkülönítése csökkenti annak esélyét, hogy egyetlen hozzáférési hiba vagy tárolási probléma az összes verziót érintse.
Mitől lesz valóban offsite egy mentés?
Az offsite mentés az elsődleges környezettől elkülönített helyen tárolt példány. Ez lehet másik telephely vagy külön szolgáltatási környezet, de a „felhőben van” önmagában nem bizonyítja az elkülönítést. Ellenőrizd, hogy a mentési hely, a fiókhozzáférések és a törlési jogosultságok mennyire függetlenek az éles rendszertől.
A három példány számlálásánál indulj ki konzervatívan: az éles oldal az első, a szolgáltatói backup a második, a saját külső példány a harmadik. A szolgáltatói mentés több napi vagy heti visszaállítási pontja értékes, de nem jelenti automatikusan azt, hogy megvan a harmadik, elkülönített példány is. A pontos tárolási felépítést mindig a szolgáltatás dokumentációjából vagy a szolgáltató válaszából ellenőrizd.
A 3-2-1 szabály a tárolási elrendezést írja le, nem a helyreállítás sikerét. A CISA üzleti adatmentési útmutatója is külön kiemeli a mentések rendszeres tesztelésének fontosságát: a CISA mentési ajánlásában további gyakorlati szempontokat találsz.
Mit fed le és mit nem a szolgáltatói biztonsági mentés?
A szolgáltatói mentés a szolgáltatásban dokumentált adatokat őrzi meg, de nem feltétlenül tartalmaz minden, a teljes alkalmazás helyreállításához szükséges külső összetevőt. Ellenőrizd külön a mentés hatókörét, megőrzési idejét, elkülönítését és visszaállítási módját.
Egy WordPress- vagy WooCommerce-projektnél legalább a webfájlokat, az adatbázist, a feltöltött médiát és az e-mail-adatokat vedd számba. A tárhelyen kívül működhet Git-repó, külön DNS-szolgáltató, CI/CD-konfiguráció, külső objektumtár vagy fizetési integráció is. Ezek nem kerülnek automatikusan egy webtárhely mentésébe, ezért mindegyikhez rendelj felelőst és helyreállítási lépést.
🛡️ A Sybell Hostingnál automatikus mentés készül a weboldalról, az adatbázisról és az e-mailről, és az utolsó 6 napi és 4 heti mentést őrizzük meg. Ez adja a 3-2-1 szabály második példányát: ha hiba történik, több visszaállítási pont közül választhatsz, és a cPanelben a Backuply felületén néhány kattintással vissza is állíthatsz belőle. A harmadik, saját offsite példány elkészítése is egyszerű, mert ugyanitt a mentést le is töltheted, és a saját külső tárolódon őrizheted.
Szolgáltatói mentés vagy saját másolat: mi a különbség?
| Szempont | Szolgáltatói mentés | Saját, elkülönített másolat |
|---|---|---|
| Hatókör | A szolgáltatás által dokumentált web-, adatbázis- és e-mail-adatok | A projektleltár alapján kiválasztott fájlok, adatok és konfigurációk |
| Megőrzés | A szolgáltató által meghatározott visszaállítási pontok | Az ügynökség RPO-ja és helyreállítási igényei szerint beállított rend |
| Elkülönítés | A tárolási hely és a hozzáférések függetlenségét ellenőrizni kell | Az éles fióktól külön kezelt offsite hozzáférés |
| Visszaállítás | A szolgáltatás dokumentált folyamata szerint | Az ügynökség által kipróbált és naplózott folyamat |
| Felelősség | A szolgáltatói mentési réteg fenntartása | A saját leltár, külső példány és restore-teszt kezelése |
A táblázat nem azt jelenti, hogy az egyik mentést válaszd a másik helyett. A szolgáltatói mentés gyorsan elérhető visszaállítási réteget adhat, a külön kezelt másolat pedig olyan további példányt jelent, amelynek hozzáférése és megőrzése a saját folyamatodhoz igazítható. A két réteg együtt erősebb tervet ad, ha a tartalmuk és a visszaállítási útjuk is ismert.
A saját leltárban jegyezd fel, hogyan áll helyre a domain DNS-e, a deployment-folyamat, az alkalmazáskonfiguráció és a szükséges hozzáférések. A titkokat ne másold egyszerű szövegként a mentési tárba, inkább használd a csapatod védett secret managerét, és írd le, hogyan állíthatók vissza a jogosultságok. A kiberbiztonsági önellenőrzésünk segít a webhely körüli alapvető üzemeltetési kérdéseket is áttekinteni.
💡 WordPress-oldalaknál a harmadik példányhoz az All-in-One WP Migration Pro bővítményt is használhatod, amelyet az 1 GB-os és nagyobb tárhelycsomagjainkhoz ingyen adunk: a teljes oldalt egyetlen exportfájlba menti, amelyet a saját tárolódon őrizhetsz. A mentések letöltésének lépéseit tudásbázisunkban találod.
Hogyan automatizáld a visszaállítási tesztet negyedéves rutinná?
A negyedéves visszaállítási teszt akkor bizonyítja a mentés használhatóságát, ha egy kijelölt mentési pontot elkülönített környezetben ténylegesen helyreállítasz, majd az eredményt naplózod. Évente négy alkalommal így ellenőrizheted, hogy a mentési folyamat a gyakorlatban is megfelel-e a projekt elvárásainak.
- Válassz tesztoldalt és mentési pontot. Jelölj ki egy reprezentatív WordPress-oldalt vagy WooCommerce-projektet, majd válassz meghatározott dátumú mentést. Rögzítsd az elfogadható adatvesztési időt, az RPO-t, valamint a helyreállítás célidejét, az RTO-t. Ezeket a projekt tranzakcióihoz és üzleti szerepéhez igazítsd, ne egy általános mintaszám alapján döntsd el.
- Készíts elkülönített tesztkörnyezetet. A staging ne írjon az éles adatbázisba, ne küldjön valódi e-mailt, és ne indítson éles fizetést vagy webhookot. Ha ügyféladatot használsz, a teszthez szükséges adatok körét csökkentsd, és ahol lehet, anonimizáld. A tesztkörnyezet címét és hozzáférését korlátozd.
- Indítsd el a helyreállítást. Használd a szolgáltató vagy a saját mentési rendszer dokumentált folyamatát. Ha rendelkezésre áll dokumentált API vagy ütemezhető felület, a csapat automatizálhatja az indítást és az eredménygyűjtést. Ha nincs, automatizáld a tesztjegy létrehozását, felelős kijelölését és határidős emlékeztetőjét, majd rögzítsd manuálisan a restore eredményét.
- Ellenőrizd az alkalmazást, ne csak a fájlokat. Nézd meg, hogy az oldal HTTP-válasza rendben van-e, be tudsz-e lépni, működik-e az adatbázis-kapcsolat és megnyílnak-e a médiák. Futtass le egy biztonságos, kritikus felhasználói útvonalat, például egy tesztűrlap beküldését vagy a WooCommerce tesztmódú rendelési folyamatát. Ellenőrizd a PHP- és alkalmazásnaplókat is.
- Mérd meg az eredményt és zárd le a tesztet. Jegyezd fel a mentési pont dátumát, a restore indításának és befejezésének idejét, az ellenőrzések eredményét és a felelőst. A mentési pont és az utolsó elvárt adat közti idő mutatja, hogy az RPO teljesült-e; a teljes helyreállítási időt az RTO-hoz hasonlítsd. Hibánál rögzítsd a javítandó lépést, majd a javítás után futtasd újra az ellenőrzést.
Mit rögzíts a visszaállítási teszt jegyzőkönyvében?
Egy tesztjegy lehet rövid, de legyen visszakereshető: dátum, webhely, mentési pont, RPO, RTO, vizsgálati eredmény, hiba és felelős. Például ha az adatbázist egy előző napi mentésből állítod vissza, nézd meg, hogy a kiválasztott pont után keletkezett rendelések vagy űrlapbejegyzések hiánya belefér-e az elfogadott adatvesztési ablakba. A teszt nem törölheti vagy módosíthatja az éles adatokat.
Mikor tesztelj a negyedéves rutinon kívül?
A rutinon kívül is végezz külön tesztet, ha mentési eszközt váltasz, új tárhelyre költöztetsz, nagy adatbázis-migrációt végzel vagy megváltozik a restore-folyamat. Ezek a változások új függőségeket hoznak be, amelyeket a következő negyedéves teszt előtt érdemes ellenőrizni. A visszaállítás dokumentálása azt is megmutatja, hol hiányzik hozzáférés, friss leírás vagy kijelölt felelős.
A cél nem az, hogy minden teszt automatikusan zöld legyen. Az a hasznos eredmény, ha a csapat meg tudja nevezni, melyik mentési pontból, milyen lépésekkel és mennyi idő alatt állt helyre az oldal, és a hibák javításának van gazdája. Így az offsite mentés és a szolgáltatói réteg egyaránt kipróbált folyamat része lesz.
Gyakori kérdések
Mi a különbség a biztonsági mentés és a replikáció között?
A biztonsági mentés időpontra visszaállítható másolatot őriz, a replikáció pedig a változásokat folyamatosan továbbítja egy másik rendszerbe. Ha törlés vagy hibás módosítás történik, a replikáció azt is továbbíthatja, ezért a replikáció önmagában nem helyettesíti a mentést.
Meddig őrizd meg az offsite mentéseket?
Az offsite mentések megőrzési idejét az elfogadható adatvesztés, a visszaállítási igények és az alkalmazandó jogszabályi vagy szerződéses kötelezettségek alapján állítsd be. Nincs minden webhelyre érvényes időtartam; a rövid napi verziók mellett olyan visszaállítási pontokat is tarts, amelyek lefedik a későn észlelt hibákat.
A Git kiváltja a webhely biztonsági mentését?
Nem, a Git és a webhely biztonsági mentése eltérő adatokat és visszaállítási célokat szolgál. A repository a forráskód változásait követi, a mentési tervnek pedig a működő alkalmazás adataira, feltöltéseire és a külső konfigurációkra is ki kell terjednie.
Összegzés
A biztonsági mentés akkor válik helyreállítási lehetőséggé, ha a másolatok elkülönítése, tartalma és visszaállítása is ellenőrzött. A 3-2-1 szabály mellé tervezz külön offsite példányt, és negyedévente próbáld ki a teljes folyamatot. Ha több ügyfél weboldalát kezeled, nézd meg viszonteladói tárhelyeinket: minden ügyfélfiókról automatikus mentés készül, amelyet a cPanelben vissza is állíthatsz és le is tölthetsz, így a 3-2-1 szabályt minden ügyfelednél könnyebben felépítheted.
Nézd meg viszonteladói tárhelycsomagjainkat »