Biztonsági mentés WordPresshez: mit, milyen gyakran és hova érdemes menteni?

A WordPress biztonsági mentését könnyű kipipálandó feladatnak tekinteni: „Van mentés? Van. Akkor rendben vagyunk.” A fontos kérdések viszont csak ezután jönnek: pontosan mi van a mentésben, milyen régi állapotokat tudsz visszaállítani, hol van a mentés, mi történik, ha maga a tárhely válik elérhetetlenné, és próbáltál-e már ténylegesen visszaállni belőle?

Egy jó mentési stratégia célja, hogy egy hibás frissítés, véletlen törlés, szerverhiba vagy biztonsági incidens után egy megfelelő korábbi állapot tényleg helyreállítható legyen. Az, hogy valahol van néhány ZIP- vagy adatbázisfájl, ehhez még kevés. A WordPress hivatalos dokumentációja is külön kezeli a fájlok és az adatbázis mentését, és egy tipikus WordPress-oldal teljes helyreállításához mindkettővel számol. (developer.wordpress.org)

Mit kell menteni egy WordPress-oldalból?

Egy WordPress-oldal leegyszerűsítve két nagy részből áll:

1. az adatbázisból;
2. a fájlokból.

Mindkettő fontos, csak más adatokat tartalmaz. Ha csak az adatbázist mented, abból nem feltétlenül állítható vissza a teljes oldal, ha pedig csak a fájlokról van másolatod, hiányozhatnak az adatbázisban tárolt tartalmak és beállítások.

Az adatbázist

A WordPress az adatbázisban tárolja többek között a bejegyzésekhez, oldalakhoz, felhasználókhoz, beállításokhoz és más működési adatokhoz tartozó információkat, és a bővítmények is létrehozhatnak saját táblákat, vagy tárolhatnak adatokat a WordPress meglévő tábláiban.

Ez egy dinamikus oldalnál különösen fontos. Egy webáruház, tagsági rendszer vagy rendszeresen frissülő oldal adatbázisa két mentés között is jelentősen változhat: új rendelés, felhasználó, hozzászólás vagy más adat kerülhet bele úgy, hogy közben egyetlen sablonfájl sem változik. Ezért az adatbázis mentési gyakoriságát nem feltétlenül érdemes ugyanúgy kezelni, mint a fájlokét. A WordPress hivatalos dokumentációjában külön útmutató szól az adatbázis mentéséről.

A WordPress fájljait

A fájlmentés nem csak a feltöltött képekről szól. A WordPress hivatalos mentési dokumentációja a mentendő fájlok között sorolja fel többek között:

• a WordPress fájljait;
• a bővítményeket;
• a sablonokat;
• a feltöltött képeket és más fájlokat;
• a wp-config.php fájlt;
• valamint más, az oldalhoz tartozó fájlokat.

(developer.wordpress.org)

A gyakorlatban különösen fontos a wp-content mappa tartalma, mert itt van a legtöbb bővítmény, sablon és feltöltött fájl. Egyedi fejlesztésnél ezen kívül is lehetnek olyan fájlok, amelyek nélkül az oldal nem állítható vissza rendesen.

A WordPress alapfájljait is muszáj menteni?

A WordPress alapfájljai (core) újra letölthetők, ezért elméletileg nem minden helyreállításnál kell ugyanezeket a szabványos fájlokat mentésből visszamásolni. A WordPress fájlmentési dokumentációja is kiemeli, hogy az alapfájlok jelentős része friss WordPress-csomagból pótolható, a wp-config.php és a wp-content viszont fontos saját adatokat tartalmazhat. (developer.wordpress.org)

Egy teljes fájlmentésnek ettől még lehet gyakorlati előnye: egyszerűbb belőle visszaállítani a rendszer állapotát, és a helyreállítás pillanatában nem kell eldöntened, melyik fájl telepíthető újra, és melyikben volt egyedi módosítás. A fontosabb kérdés az, hogy pontosan tudd, mit tartalmaz a mentésed, és mi kell a teljes oldal visszaállításához.

A fájlok és az adatbázis együtt adnak egy helyreállítható állapotot

Egy három hónapos fájlmentés és mellette egy tegnapi adatbázis-export külön-külön lehet használható mentés, együtt viszont nem biztos, hogy egy egységes állapotot adnak. A WordPress hivatalos mentési dokumentációja is külön kezeli a fájlokat és az adatbázist, és a teljes helyreállításhoz mindkettővel számol. (developer.wordpress.org)

Ez dinamikus oldalnál különösen fontos. Ha az adatbázis és a hozzá tartozó feltöltött fájlok jelentősen eltérő időpontból származnak, helyreállítás után előfordulhat, hogy az adatbázis olyan fájlokra hivatkozik, amelyek a visszaállított fájlmentésben még nem léteznek. A pontos technikai megoldás a mentési rendszertől és az oldal működésétől függ, az alapelv az, hogy világos legyen, mely elemek tartoznak ugyanahhoz a helyreállítási ponthoz.

Milyen gyakran érdemes menteni a WordPresst?

Erre nincs minden oldalra érvényes válasz, a jó gyakoriságot elsősorban az határozza meg, hogy mennyi adat elvesztése fér még bele.

Tegyük fel, hogy naponta egyszer készül adatbázis-mentés. Ha délután ötkor történik valami, és csak az előző éjszakai állapot állítható vissza, az azóta keletkezett változások egy része elveszhet. Egy ritkán módosuló bemutatkozó oldalnál ez elfogadható lehet, egy olyan webáruháznál viszont, ahol folyamatosan jönnek a rendelések, egészen más az elvárás. Ezért nem mondanám általánosságban, hogy „minden WordPress-oldalt naponta egyszer kell menteni”. A kérdés inkább ez: ha most kellene visszaállnom az utolsó mentésre, mennyi változás elvesztését engedhetem meg magamnak?

Ennek van szakmai neve is: RPO, vagyis Recovery Point Objective. Leegyszerűsítve azt fejezi ki, hogy egy kiesés után milyen korábbi időponthoz kell tudni visszatérni, vagyis mekkora adatvesztés fér bele. A NIST meghatározása szerint az RPO azt az időpontot jelöli, amelyre az adatokat egy kiesés után helyre kell állítani. (NIST Recovery Point Objective)

A másik hasznos fogalom az RTO, vagyis Recovery Time Objective, amely arra válaszol, mennyi kiesés fér bele, tehát milyen gyorsan kell helyreállítani a működést. (NIST Recovery Time Objective)

A kettő két külön kérdés. Egy ritkán változó bemutatkozó oldalnál elfogadható lehet több óra adatvesztés és hosszabb helyreállítási idő is, egy folyamatosan rendeléseket fogadó webshopnál viszont az is számít, mennyi rendelési vagy készletadat veszhet el, és az is, meddig maradhat működésképtelen az oldal. A mentési stratégia tervezésénél ezért érdemes feltenni a kérdést, hogy milyen régi állapotba tudok még elfogadható veszteséggel visszatérni, és hogy mennyi idő alatt kell újra működnie az oldalnak. Ehhez nem kell bonyolult vállalati katasztrófa-helyreállítási rendszer, már az is sokat segít, ha ezt a két üzleti elvárást előre végiggondolod.

A fájlokat és az adatbázist nem feltétlenül kell ugyanolyan gyakran menteni

Egy oldal adatbázisa naponta akár több százszor is változhat úgy, hogy a bővítmények, a sablon és a feltöltött fájlok alig változnak, más oldalakra viszont rendszeresen kerülnek fel új képek vagy dokumentumok. Ezért indokolt lehet eltérő gyakorisággal menteni az adatbázist és a fájlokat, feltéve, hogy a visszaállításnál továbbra is egyértelmű, mely állapotok tartoznak össze. A lényeg, hogy a mentési rendszer kövesse az oldal változásának ütemét és az elfogadható adatvesztést, az óránkénti, napi vagy heti címke ehhez képest mellékes.

Dinamikus oldalnál a visszaállítás módja is fontos

Egy folyamatosan működő webshopnál nemcsak a mentési gyakoriságot kell végiggondolni. Tegyük fel, hogy egy több órával korábbi teljes adatbázis-mentést állítasz vissza, miközben az éles rendszerben már keletkezhettek:

• új rendelések;
• rendelési állapotváltozások;
• ügyféladatok;
• készletváltozások;
• más üzleti adatok.

Egy régebbi teljes adatbázis egyszerű visszaállítása ezeket az azóta keletkezett változásokat felülírhatja vagy elveszítheti. Nem minden webshopnál kell ezért részleges adatbázis-visszaállítás, és nem is mindig egyszerű megoldani, de egy dinamikus rendszer visszaállítása nem feltétlenül merül ki abban, hogy „állítsuk vissza az egész adatbázist az utolsó mentésből”. A konkrét helyzetben azt is mérlegelni kell, milyen állapotot szeretnél visszaállítani, és milyen újabb adatokat nem veszíthetsz el.

Fontos változtatás előtt készíts külön mentést

Az automatikus mentés mellett hasznos egy külön mentés minden olyan művelet előtt, amely érdemben megváltoztathatja az oldalt, például:

• nagyobb WordPress-, bővítmény- vagy sablonfrissítés;
• jelentősebb beállításmódosítás;
• adatbázist érintő változtatás;
• nagyobb élesítés;
• költöztetés;
• más kockázatosabb karbantartási művelet.

A WordPress frissítési dokumentációja is azt javasolja, hogy frissítés előtt készüljön mentés az oldalról. (developer.wordpress.org) Ez akkor ad valódi védelmet, ha vissza is tudsz állni belőle: a frissítés előtti mentés egy konkrét visszaállítási pont arra az esetre, ha a változtatás nem a tervek szerint sikerül.

Hány korábbi mentést érdemes megtartani?

Ha minden új mentés azonnal felülírja az előzőt, hiába működik hibátlanul az automatikus mentés, könnyen előfordulhat, hogy mire észreveszed a bajt, már csak a hibás állapot mentése maradt meg. Ez különösen fontos olyan hibánál vagy biztonsági incidensnél, amelyet nem azonnal veszel észre: ha egy feltörés több nappal az észlelés előtt történt, a tegnapi mentés ugyanúgy tartalmazhatja a nem kívánt módosítást. Ezért érdemes több helyreállítási pontot megtartani.

A WordPress aktuális mentési dokumentációja 3–5 friss mentés megőrzését javasolja, különböző helyeken tárolt példányokkal. (developer.wordpress.org) Ezt nem kezelném minden oldalra kötelező szabályként, mert a megőrzés (retention), vagyis hogy mennyi ideig és hány korábbi állapotot tartasz meg, az oldal kockázatától és helyreállítási igényeitől függ, például:

• az oldal változásának gyakoriságától;
• a rendelkezésre álló tárhelytől;
• a tárolt adatok érzékenységétől;
• az üzleti követelményektől;
• attól, mennyi idő alatt szoktak kiderülni a problémák.

Nem feltétlenül az a jó rendszer, amelyik minden mentést örökké megőriz, az a fontos, hogy legyen érdemi lehetőséged korábbi állapothoz visszanyúlni.

A megváltoztathatatlan mentés további védelmi réteg lehet

Bizonyos mentési rendszerekben beállítható, hogy egy elkészült mentést meghatározott ideig ne lehessen módosítani vagy törölni. Ezt gyakran megváltoztathatatlan (immutable) mentésnek nevezik.

Ennek akkor van jelentősége, ha például egy feltört adminisztrátori hozzáféréssel valaki a mentéseket is megpróbálná törölni vagy módosítani, vagy egy zsarolóvírus-jellegű támadás az elérhető mentéseket is érinthetné. Minden WordPress-oldalhoz ettől még nem kell ilyen infrastruktúra: ez egy további védelmi réteg, amelynek értékét az oldal fontossága, a kockázat és a használt mentési rendszer alapján érdemes mérlegelni.

Hova érdemes menteni a WordPress-oldalt?

Az egyik legfontosabb alapelv: ne az éles webszerver legyen az egyetlen hely, ahol a mentés létezik. Ha maga a szerver meghibásodik, elveszik a hozzáférés a tárhelyfiókhoz, vagy egy biztonsági incidens az ott lévő mentéseket is érinti, az éles oldal és az egyetlen helyreállítási lehetőség egyszerre válhat használhatatlanná. A WordPress hivatalos dokumentációja is azt javasolja, hogy ne csak a tárhelyszolgáltató szerverén tárolt mentésre támaszkodj. (developer.wordpress.org)

Ezért érdemes legalább egy elkülönített mentési példányban gondolkodni, ezt gyakran off-site mentésnek hívják. Ehhez nem kell egy másik kontinensen lennie, az a lényeg, hogy ugyanaz az egyetlen hiba vagy feltört hozzáférés ne veszélyeztesse egyszerre az éles rendszert és az összes mentést.

Az elkülönítés ráadásul nemcsak földrajzi vagy szolgáltatói kérdés. Hiába tárolod a mentést egy másik szolgáltatónál, ha ugyanazzal a feltört fiókkal vagy jelszóval az éles rendszer és az összes mentés is törölhető vagy módosítható. Ezért azt is érdemes végiggondolni:

• milyen fiókkal érhető el az éles rendszer;
• milyen fiókkal érhetők el a mentések;
• mekkora kárt tud okozni egyetlen feltört hozzáférés;
• milyen jogosultság kell a mentések törléséhez vagy módosításához.

Ehhez sem kell bonyolult hozzáférés-kezelés, csak arra figyelj, hogy közben ne ugyanaz a hozzáférés kezeljen mindent.

A 3-2-1 szabály hasznos gondolkodási keret

A mentésről szóló anyagokban gyakran találkozhatsz a 3-2-1 szabállyal. A klasszikus megfogalmazás szerint legyen:

• 3 példány az adatokról;
• 2 különböző tárolási mód;
• 1 elkülönített vagy off-site példány.

A CISA ma is hasznos irányelvként mutatja be. (CISA: Back Up Business Data) Kötelező WordPress-szabályként ezt sem érdemes kezelni, mert egy kisebb bemutatkozó oldal és egy üzletileg kritikus webshop mentési igénye eltér. A 3-2-1 inkább egy jó ellenőrző kérdés: nem függ-e az összes helyreállítási lehetőség ugyanattól az egyetlen hibaponttól? A konkrét megvalósítás a kockázattól és a környezettől függ.

Elég a tárhelyszolgáltató mentése?

Lehet, de ezt ellenőrizni érdemes, nem feltételezni. Sok tárhelyszolgáltató készít valamilyen automatikus mentést, ami kifejezetten hasznos, a szolgáltatások között viszont nagy különbség lehet abban, hogy:

• milyen gyakran készül mentés;
• pontosan mit tartalmaz;
• mennyi ideig őrzik meg;
• hogyan lehet visszaállítani;
• mennyi ideig tart a visszaállítás;
• milyen körülmények között érhető el a mentés.

A WordPress dokumentációja is megjegyzi, hogy sok tárhely készít szerveroldali mentést, de ettől még érdemes saját mentési lehetőséggel is rendelkezni. (developer.wordpress.org) A tárhelyes mentés ettől nem rossz, csak nem jó stratégia olyan mentésre hagyatkozni, amelynek a működését, a tartalmát és a visszaállítási feltételeit nem ismered.

A mentés ne legyen nyilvánosan elérhető

Egy WordPress-mentés kifejezetten érzékeny adatokat tartalmazhat. Az adatbázis-exportban lehetnek felhasználói adatok és beállítási értékek, a fájlmentésben pedig ott lehet a wp-config.php, egyedi kód, feltöltött dokumentum vagy más nem nyilvános tartalom. Az oldaltól és a beállításoktól függően a mentésben olyan hozzáférési adatok is lehetnek, mint például:

• az adatbázis belépési adatai;
• API-kulcsok;
• az SMTP belépési adatai;
• más titkos beállítási értékek.

Nem minden mentés tartalmazza mindezeket, ez attól függ, mit ment a rendszer, és hol tárolja az oldal a hozzáférési adatokat. A következmény viszont fontos: egy illetéktelenül megszerzett mentés adatszivárgáson túl olyan hozzáférési adatokat is kiadhat, amelyekkel más rendszerekbe is be lehet jutni.

Ezért a mentést nem érdemes egy nyilvános webkönyvtárban hagyni csak azért, mert onnan könnyű letölteni. Ugyanez igaz a mentési rendszer hozzáféréseire: ha külső tárhelyre vagy más mentési szolgáltatásba kerülnek a mentések, annak a hozzáférését is rendesen védeni kell. A mentés biztonsága a teljes rendszer része, rá ugyanazok a szabályok vonatkoznak, mint az eredeti adatokra.

Érdemes titkosítani a mentéseket?

Ez attól függ, milyen adatokat tartalmaznak, és hol tárolod őket. Egy mentésben lehetnek személyes adatok, beállítási értékek, belépési adatok és más érzékeny információk, ezért bizonyos környezetekben indokolt lehet a titkosítás, különösen ha a mentés olyan helyre kerül, ahol ez érdemi plusz védelmet ad. A WordPress biztonsági (hardening) dokumentációja is a biztonság fontos részeként kezeli a mentéseket. (developer.wordpress.org)

A titkosítás viszont új feladatot is ad: a titkosítási kulcsot vagy a visszafejtéshez szükséges hozzáférést is biztonságosan kell kezelni. Egy tökéletesen titkosított mentés, amelyet szükség esetén senki nem tud visszafejteni, helyreállítási szempontból nem sokat ér.

Az automatikus mentés jó, de ellenőrizni is kell

A legtöbb WordPress-oldalnál teljesen ésszerű automatizálni a rendszeres mentést, például:

• a tárhelyszolgáltató rendszerével;
• WordPress-mentőbővítménnyel;
• külső mentési szolgáltatással;
• szerveroldali automatizmussal;
• más, az infrastruktúrához illő megoldással.

Nincs egyetlen technológia, amely minden WordPress-oldalhoz a legjobb lenne. Az automatizálás előnye, hogy a mentés nem azon múlik, eszébe jut-e valakinek minden este elindítani.

Egy mentőbővítmény ettől még nem jelent off-site mentést. Ha a bővítmény elkészíti a mentést, de ugyanazon a webszerveren vagy ugyanabban a WordPress-környezetben hagyja, a közös hibapont problémája megmarad, mert a mentés elkészítése és a tárolási helye két külön kérdés. A mentőbővítmény sok esetben teljesen jó része lehet egy mentési rendszernek, csak érdemes külön ellenőrizni, mi történik az elkészült mentéssel.

Az automatikus folyamat ráadásul meg is hibásodhat: betelhet a tárhely, megszűnhet egy külső hozzáférés, megváltozhat egy API-kulcs, hibára futhat a mentés, vagy elkészülhet egy használhatatlan fájl. Ezért a „beállítottam az automatikus mentést” és a „biztosan vannak használható mentéseim” két különböző állítás.

A mentés sikeréről is érdemes tudni

Egy automatikus mentési rendszernek futnia kell, és ellenőrizhetőnek is kell lennie. Érdemes tudni például:

• mikor készült az utolsó sikeres mentés;
• mekkora lett;
• azt tartalmazza-e, amit vársz tőle;
• volt-e hiba;
• elérhető-e a szükséges korábbi változat.

Nem kell minden sikeres mentésről külön értesítés, a hibák viszont ne maradjanak hónapokig észrevétlenek. Egy mentési rendszer akkor igazán hasznos, ha nem a helyreállítás pillanatában derül ki először, hogy fél éve nem működik.

A mentés csak akkor ér valamit, ha visszaállítható

Ez talán az egész téma legfontosabb pontja: a mentés elkészítése és a sikeres visszaállítás két külön feladat. Lehet egy szabályosnak tűnő fájlod, amely:

• sérült;
• hiányos;
• nem a megfelelő adatbázist tartalmazza;
• nem tartalmazza az összes szükséges fájlt;
• vagy csak olyan folyamattal állítható vissza, amelyet senki nem ismer.

Ezért érdemes időnként ténylegesen kipróbálni a visszaállítást egy elkülönített tesztkörnyezetben (staging), ahol az éles oldal érintetlen marad, és kiderül, valóban felépíthető-e a mentésből egy működő oldal. A WordPress saját dokumentációja is hangsúlyozza, hogy a rendszeres mentés mellett ismerni kell a visszaállítás módját, mielőtt olyan változtatásba kezdesz, amelynél szükség lehet rá. (developer.wordpress.org) A próba-visszaállítás így azt ellenőrzi, hogy a teljes helyreállítási folyamat működik-e, nem csak azt, hogy egy fájl kicsomagolható.

A mentés még nem teljes helyreállítási terv

A mentések megléte a helyreállítás egyik legfontosabb alapja, de egy valódi visszaállításnál azt is tudni kell például:

• ki végzi a helyreállítást;
• milyen hozzáférések kellenek hozzá;
• hova történik a visszaállítás;
• milyen sorrendben kell visszaállítani az egyes elemeket;
• hogyan ellenőrizzük utána, hogy az oldal tényleg rendesen működik.

Ennek főleg az RTO szempontjából van jelentősége. Lehet kiváló mentésed, de ha egy incidens közben először azt kell kideríteni, hol a tárhely belépése, ki fér hozzá a mentéshez és hogyan indul a visszaállítás, a helyreállítás sokkal tovább tart. Ehhez nem kell hosszú dokumentáció, csak a mentés mellett a helyreállítás útja is legyen ismert.

Mit érdemes ellenőrizni egy próba-visszaállítás után?

Nem elég annyit látni, hogy megjelent a főoldal. Az oldal jellegétől függően érdemes ellenőrizni például:

• megvannak-e a tartalmak;
• megjelennek-e a képek és a többi feltöltött fájl;
• működik-e a sablon;
• elérhetők-e a szükséges bővítmények;
• rendben vannak-e a fontos beállítások;
• működik-e a belépés;
• rendben vannak-e az oldal kritikus funkciói.

Egy webáruháznál nyilván más funkciók kritikusak, mint egy egyszerű bemutatkozó oldalnál. A helyreállítási próba célja éppen az, hogy még egy valódi baj előtt kiderüljön, mi hiányzik a mentésből vagy a leírt folyamatból.

A verziókövetés nem helyettesíti a mentést

Fejlesztett WordPress-oldalaknál gyakori, hogy a sablon, az egyedi bővítmény vagy más kód Gitben vagy más verziókövető rendszerben van, és ez nagyon hasznos. A WordPress dokumentációja is külön foglalkozik a verziókövetéssel mint a fájlok változásainak követésére és a korábbi kódállapotok visszaállítására alkalmas eszközzel. (developer.wordpress.org)

A Git-tároló viszont általában nem tartalmazza a teljes WordPress-adatbázist és a felhasználók által feltöltött összes fájlt, ezért a verziókövetés és a mentés két külön problémát old meg. A verziókövetéssel látod, mi változott a kódban, és vissza tudsz állni egy korábbi kódra, a teljes oldal helyreállításához viszont továbbra is mentés kell.

A mentés nem véd a feltörés ellen

A mentés a WordPress biztonságának fontos része, de van egy lényeges korlátja: nem akadályozza meg a feltörést. Segít a helyreállításban, de nem javít ki egy sérülékeny bővítményt, nem teszi erőssé a gyenge jelszót, nem kapcsolja be a kétlépcsős azonosítást (2FA), és nem akadályozza meg, hogy valaki illetéktelenül hozzáférjen az oldalhoz. Ezért a mentés nem helyettesíti a frissítéseket, a jó hozzáférés-kezelést és a felügyeletet. A megelőző biztonsági rétegekről a WordPress biztonság: a leggyakoribb támadások és amit érdemes beállítani cikkben írok részletesebben.

Biztonsági incidensnél ne feltételezd, hogy a legutóbbi mentés tiszta

Ha egy WordPress-oldalt feltörtek, vagy kártékony kód került rá, kézenfekvő ötlet egy korábbi mentést visszaállítani. Ez működhet, csak tudni kell, hogy a fertőzés észlelése nem feltétlenül esik egybe a feltörés időpontjával. Ha kedden veszed észre a bajt, az oldal már előző pénteken is érintett lehetett, és akkor a hétfői mentés ugyanúgy tartalmazhatja a nem kívánt módosítást. Ez az egyik oka annak, hogy több korábbi helyreállítási pont hasznosabb, mint egyetlen, folyamatosan felülírt mentés.

A zsarolóvírusos támadások utáni helyreállítással foglalkozó biztonsági ajánlások is abból indulnak ki, hogy a támadók megpróbálhatják elérni, törölni vagy titkosítani a hozzáférhető mentéseket, ezért az elkülönített és védett mentés különösen fontos.

Ha egy megtisztított oldalra rossz mentésből kerül vissza egy korábbi módosítás, az akár úgy is tűnhet, mintha az oldal újra megfertőződött volna. Erről a Miért fertőződik újra a WordPress oldal a tisztítás után? cikkben írok részletesebben.

Milyen egy ésszerű WordPress-mentési stratégia?

Nem minden oldalhoz ugyanaz a mentési rendszer kell, mert egy egyszerű bemutatkozó oldal és egy folyamatosan változó webshop kockázata, adatmennyisége és helyreállítási igénye teljesen eltérő lehet. A technológia kiválasztása előtt ezért ezekre a kérdésekre érdemes válaszolni:

1. Pontosan milyen fájlokra és adatbázis-adatokra van szükség a teljes helyreállításhoz?
2. Milyen gyakran változnak ezek az adatok?
3. Legfeljebb mennyi adat elvesztése fér bele?
4. Mennyi ideig maradhat kiesve az oldal, vagyis milyen gyorsan kell helyreállítani?
5. Hány korábbi helyreállítási pontra lehet szükség?
6. Van-e legalább egy elkülönített mentési példány?
7. Egy feltört hozzáférés elérheti-e egyszerre az éles rendszert és az összes mentést?
8. Ki és hogyan fér hozzá a mentésekhez?
9. Észreveszed-e, ha a mentés hibára fut?
10. Próbáltad-e már ténylegesen visszaállítani az oldalt?
11. Le van-e írva annyira a folyamat, hogy szükség esetén végre lehessen hajtani?

Ha ezekre tudsz válaszolni, sokkal többet tudsz a mentési rendszeredről annál, hogy „naponta készül mentés”.

Mikor érdemes felülvizsgálni a mentési rendszert?

A mentési stratégia sem egyszeri beállítás. Érdemes újra átgondolni például akkor, ha:

• jelentősen nő az oldal forgalma vagy fontossága;
• webshop vagy más dinamikus funkció kerül rá;
• megváltozik a tárhely;
• új integrációk jelennek meg;
• átalakul az élesítés folyamata;
• jelentősen nő az adatbázis vagy a feltöltött fájlok mennyisége;
• kiderül, hogy a mostani megőrzési idő már nem elég;
• egy próba-visszaállítás hibát talál.

Egy mentési rendszer, amely három éve megfelelt egy tízoldalas bemutatkozó oldalhoz, nem biztos, hogy akkor is megfelel, amikor az oldal már napi üzleti folyamatokat kezel.

Gyakori kérdések

Mit kell menteni egy WordPress-oldalból?

A teljes helyreállításhoz az adatbázissal és a WordPresshez tartozó fájlokkal is számolni kell. Az adatbázisban van a tartalmak és a beállítások jelentős része, a fájlok között pedig többek között a bővítmények, a sablonok, a feltöltött fájlok, a wp-config.php és más, az oldal működéséhez szükséges elemek.

Milyen gyakran kell WordPress-mentést készíteni?

Nincs minden oldalra érvényes gyakoriság. Azt érdemes meghatározni, mennyi adat elvesztése elfogadható, ezt nevezik RPO-nak. Egy ritkán változó bemutatkozó oldal és egy folyamatosan rendeléseket fogadó webshop ezért teljesen eltérő mentési gyakoriságot igényelhet.

Elég csak az adatbázist menteni?

A teljes WordPress-helyreállításhoz általában nem, mert az adatbázis mellett a sablonokra, a bővítményekre, a feltöltött fájlokra, a beállításokra és más, az oldalhoz tartozó fájlokra is szükség lehet.

Elég a tárhelyszolgáltató mentése?

Lehet, hogy a szolgáltató mentése megfelelő az adott oldalhoz, de ezt érdemes ellenőrizni: mit ment, milyen gyakran, mennyi ideig őrzi meg, hogyan lehet visszaállítani, és mi történik, ha maga a tárhely vagy a hozzáférés válik problémássá.

Hol tároljam a WordPress-mentést?

Úgy érdemes kialakítani a rendszert, hogy ne minden mentés ugyanazon a szerveren vagy ugyanabban a könnyen együtt érinthető környezetben legyen, mint az éles oldal. Legalább egy elkülönített mentési példány csökkenti annak kockázatát, hogy ugyanaz az esemény az oldalt és az összes mentést egyszerre tegye használhatatlanná, és az elkülönítésnél a tárolási hely mellett a hozzáféréseket is érdemes figyelembe venni.

Hány korábbi mentést tartsak meg?

Erre sincs általános szám. Több korábbi helyreállítási pont azért kell, mert egy hibát vagy feltörést nem feltétlenül veszel észre azonnal, és ha mindig csak az előző mentést tartod meg, könnyen előfordulhat, hogy az már ugyanazt a hibás állapotot tartalmazza. A megőrzési időt ezért az oldal működéséhez, a problémák várható észlelési idejéhez és a helyreállítási elvárásokhoz érdemes igazítani.

Honnan tudom, hogy jó a mentés?

Abból még nem, hogy a mentési rendszer azt írja: „sikeres”. A valódi ellenőrzés az, hogy megvannak-e a szükséges fájlok és adatok, és ténylegesen visszaállítható-e belőlük az oldal, ezért érdemes időnként elkülönített környezetben próba-visszaállítást is végezni.

A mentés megvéd attól, hogy feltörjék a WordPress-oldalt?

Nem. A mentés helyreállítási eszköz, egy feltörés után nagyon fontos lehet, de nem helyettesíti a frissítéseket, az erős hozzáférés-védelmet, a kétlépcsős azonosítást, a megfelelő jogosultságokat és a többi biztonsági réteget.

A jó WordPress-mentés végső soron attól jó, hogy a megfelelő adatokat, megfelelő gyakorisággal, megfelelő helyen őrzi, és amikor tényleg szükség van rá, vissza is tudsz belőle állni. Az, hogy minden éjjel elkészül egy fájl, ehhez még kevés.

---

Nem szeretnél ezzel foglalkozni? A WordPress-weboldal karbantartásával a mentések ütemezését és ellenőrzését is elvégzem, ha pedig már baj van, a WordPress-vírusirtással helyreállítom az oldalt.

---

Kapcsolódó: WordPress biztonság: mit érdemes beállítani? · Feltörték a WordPress oldalam: mit tegyek?