A WordPress biztonsági mentésről könnyű úgy gondolkodni, mint egy kipipálandó feladatról:
„Van backup? Van. Akkor rendben vagyunk.”
A fontos kérdések viszont csak ezután kezdődnek.
Pontosan mi van benne a mentésben? Milyen régi állapotokat tudsz visszaállítani? Hol található a backup? Mi történik, ha maga a tárhely válik elérhetetlenné? És próbáltál már ténylegesen visszaállni belőle?
Egy jó mentési stratégia célja nem egyszerűen az, hogy valahol legyen néhány ZIP vagy adatbázisfájl. Az a cél, 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énylegesen helyreállítható legyen.
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:
- az adatbázisból;
- a fájlokból.
Mindkettő fontos, csak más típusú adatokat tartalmaz.
Ha kizárólag az adatbázist mented, abból nem feltétlenül tudod visszaállítani a teljes oldalt. 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 kapcsolódó információkat.
A pluginok is létrehozhatnak saját táblákat vagy tárolhatnak adatokat a WordPress meglévő struktúrá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 akár 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ója külön útmutatót tart fenn az adatbázis mentéséhez.
A WordPress fájljait
A fájlmentésnek nem csak a feltöltött képekről kell szólnia.
A WordPress hivatalos backup dokumentációja a mentendő fájlok között kezeli többek között:
- a WordPress fájljait;
- a pluginokat;
- a sablonokat;
- a feltöltött képeket és más fájlokat;
- a
wp-config.phpfájlt; - valamint más, az oldalhoz tartozó fájlokat.
A gyakorlatban különösen fontos a wp-content tartalma, mert itt található többek között a legtöbb plugin, sablon és feltöltött média.
Egyedi fejlesztésnél más fájlok is lehetnek, amelyek nélkül az oldal nem állítható vissza megfelelően.
A WordPress core fájlokat is muszáj menteni?
A WordPress core eredeti fájljai újra beszerezhetők, ezért elméletileg nem minden helyreállításnál szükséges ugyanazokat a standard core fájlokat backupból visszamásolni. A WordPress fájlmentési dokumentációja is kiemeli, hogy a core jelentős része friss WordPress-csomagból pótolható, miközben a wp-config.php és a wp-content különösen fontos saját adatokat tartalmazhat. (developer.wordpress.org)
Ettől még egy teljes fájlmentésnek lehet gyakorlati előnye.
Egyszerűbb lehet belőle az adott rendszer állapotát visszaállítani, és nem kell a helyreállítás pillanatában eldönteni, mely fájl újratelepíthető és melyik tartalmazott egyedi módosítást.
A fontosabb kérdés az, hogy pontosan tudd, mit tartalmaz a backupod, és mi szükséges a teljes oldal visszaállításához.
A fájlok és az adatbázis együtt alkotnak egy helyreállítható állapotot
Nem elég, ha valahol van egy három hónapos fájlmentés és mellette egy tegnapi adatbázis-export.
Ezek külön-külön lehetnek használható mentések, de nem biztos, hogy együtt egy konzisztens állapotot képviselnek.
A WordPress hivatalos backup dokumentációja is külön kezeli a fájlokat és az adatbázist, és a teljes helyreállításhoz mindkettő meglétével számol. (developer.wordpress.org)
Ez különösen dinamikus weboldalnál fontos.
Ha például 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 backup rendszer és az oldal működésének függvénye. A fő elv az, hogy a mentés ne különálló fájlhalmazok gyűjteménye legyen, hanem legyen világos, mely elemek tartoznak ugyanahhoz a helyreállítási ponthoz.
Milyen gyakran érdemes menteni a WordPresst?
Erre nincs minden weboldalra érvényes válasz.
A jó mentési 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 öt órakor történik valami, és csak az előző éjszakai állapot állítható vissza, akkor az azóta keletkezett változások egy része elveszhet.
Egy ritkán módosuló bemutatkozó oldalnál ez lehet elfogadható.
Egy olyan webáruháznál, ahol folyamatosan érkeznek rendelések, már teljesen más lehet az elvárás.
Ezért nem mondanám univerzálisan azt, 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ást engedhetek meg magamnak elveszíteni?
Ennek van egy 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 még 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)
Van egy másik hasznos fogalom is, az RTO, vagyis Recovery Time Objective. Ez leegyszerűsítve arra válaszol, hogy mennyi kiesési idő fér bele, tehát milyen gyorsan kell a működést helyreállítani. (NIST Recovery Time Objective)
A kettő nem ugyanaz.
Egy ritkán változó bemutatkozó oldalnál elképzelhető, hogy több óra adatvesztés és egy hosszabb helyreállítási idő is elfogadható.
Egy folyamatosan rendeléseket fogadó webshopnál már egészen más lehet a helyzet. Ott nemcsak az számíthat, hogy mennyi rendelési vagy készletadat veszhet el, hanem az is, hogy az oldal mennyi ideig maradhat működésképtelen.
A mentési stratégia megtervezésénél ezért két külön kérdést érdemes feltenni:
Milyen régi állapotba tudok még elfogadható veszteséggel visszatérni?
és
Mennyi idő alatt kell újra működnie az oldalnak?
Nem szükséges ehhez bonyolult vállalati disaster recovery 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 módosulhat úgy, hogy a pluginok, a sablon és a feltöltött fájlok alig változnak.
Más weboldalnál viszont rendszeresen kerülnek fel új képek vagy dokumentumok is.
Ezért indokolt lehet eltérő mentési gyakoriságot használni az adatbázisra és a fájlokra, feltéve, hogy a visszaállítási folyamatban továbbra is egyértelmű, mely állapotok tartoznak össze.
Nem maga az óránkénti, napi vagy heti címke a lényeg, hanem hogy a mentési rendszer kövesse az oldal változásának ütemét és az elfogadható adatvesztést.
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. Kö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 létrejött változásokat felülírhatja vagy elveszítheti.
Ez nem jelenti azt, hogy minden webshopnál részleges adatbázis-visszaállítást kell végezni, vagy hogy ez minden helyzetben egyszerűen megoldható.
A fontos gondolat az, hogy egy dinamikus rendszer restore stratégiája nem feltétlenül merül ki abban, hogy „állítsuk vissza az egész adatbázist az utolsó backupból”.
A konkrét helyzetben azt is mérlegelni kellhet, milyen állapotot szeretnénk visszaállítani, és milyen újabb adatokat nem engedhetünk meg elveszíteni.
Fontos változtatás előtt készíts külön mentést
Az automatikus backup mellett hasznos lehet egy külön, igény szerinti mentés olyan művelet előtt, amely érdemben megváltoztathatja az oldalt.
Például:
- nagyobb WordPress-, plugin- vagy sablonfrissítés;
- jelentősebb konfigurációmódosítás;
- adatbázist érintő változtatás;
- nagyobb deployment;
- migráció;
- 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 azonban csak akkor jelent valódi védelmet, ha a mentésből vissza is tudsz állni.
Egy frissítés előtti backup tehát nem rituálé. 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?
Az sem ideális, ha minden új backup azonnal felülírja az előzőt.
Ebben az esetben hiába működik hibátlanul az automatikus mentés, könnyen előfordulhat, hogy mire észreveszed a problémát, már csak a problémá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 például egy kompromittálás több nappal az észlelés előtt történt, akkor a tegnapi backup 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 backup dokumentációja jelenleg 3–5 friss WordPress-mentés megőrzését javasolja, különböző helyeken tárolt példányokkal. Ezt azonban nem kezelném minden WordPress oldalra kötelező univerzális szabályként. A megfelelő retention továbbra is az oldal kockázatától és helyreállítási igényeitől függ. (developer.wordpress.org)
A gyakorlatban a retention, vagyis hogy mennyi ideig és hány korábbi állapotot őrzöl meg, függhet 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 ugyanazzal a gyakorisággal őriz meg minden mentést örökké.
A fontos az, hogy legyen érdemi lehetőséged korábbi állapothoz visszanyúlni.
Az immutable backup további védelmi réteg lehet
Bizonyos mentési rendszerek lehetővé teszik, hogy egy már elkészült backupot meghatározott ideig ne lehessen egyszerűen módosítani vagy törölni.
Ezt nevezik gyakran immutable, vagyis megváltoztathatatlan mentésnek.
Ennek akkor lehet külön jelentősége, ha például egy kompromittált adminisztrátori hozzáféréssel valaki a mentéseket is megpróbálná törölni vagy módosítani, illetve ransomware-jellegű esemény az elérhető backupokat is érinthetné. Az immutable tárolási megoldások célja éppen az, hogy bizonyos műveletekkel szemben védjék a meglévő helyreállítási pontokat.
Ettől még nem következik, hogy minden WordPress oldalhoz immutable backup infrastruktúrára van szükség.
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 backupot?
Az egyik legfontosabb alapelv:
ne az éles webszerver legyen az egyetlen hely, ahol a mentés létezik.
Ha maga a szerver meghibásodik, a tárhelyfiókhoz való hozzáférés elveszik, vagy egy biztonsági incidens az ott található backupokat is érinti, akkor az éles oldal és az egyetlen helyreállítási lehetőség egyszerre válhat használhatatlanná.
A WordPress hivatalos dokumentációja szintén azt javasolja, hogy ne kizárólag a tárhelyszolgáltató szerverén tárolt mentésre támaszkodj. (developer.wordpress.org)
Ezért érdemes legalább egy megfelelően elkülönített mentési példányban gondolkodni.
Ezt gyakran off-site backupnak nevezik.
Nem feltétlenül azt jelenti, hogy fizikailag egy másik kontinensen kell lennie. A lényeg az, hogy ne ugyanaz az egyetlen meghibásodás vagy kompromittált hozzáférés veszélyeztesse az éles rendszert és az összes mentést.
Az elkülönítés ráadásul nem kizárólag fizikai vagy szolgáltatói kérdés.
Hiába tárolod a backupot egy másik szolgáltatónál, ha ugyanazzal a kompromittált fiókkal vagy hitelesítési adattal 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;
- egyetlen kompromittált hozzáférés mekkora kárt tud okozni;
- a backupok törléséhez vagy módosításához milyen jogosultság szükséges.
Nem feltétlenül kell ehhez bonyolult hozzáférés-kezelési architektúra. A lényeg az, hogy az „off-site” ne csak földrajzi vagy szolgáltatói elkülönítést jelentsen, miközben ugyanaz a hozzáférés továbbra is mindent kontrollál.
A 3-2-1 szabály hasznos gondolkodási keret
Backup témában 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 ezt jelenleg is hasznos backup irányelvként mutatja be. (CISA: Back Up Business Data)
Ezt sem érdemes azonban kötelező WordPress architektúraként értelmezni.
Egy kisebb bemutatkozó oldal és egy üzletileg kritikus webshop mentési igénye nem azonos. A 3-2-1 inkább egy hasznos ellenőrző gondolat: 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 továbbra is kockázat- és környezetfüggő.
A tárhelyszolgáltató mentése elég?
Lehet, hogy igen, de ezt érdemes ellenőrizni, nem feltételezni.
Sok tárhelyszolgáltató biztosít valamilyen automatikus backupot, ami kifejezetten hasznos lehet. Az egyes szolgáltatások között viszont jelentős 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;
- a visszaállítás mennyi időt vesz igénybe;
- milyen körülmények között érhető el a backup.
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)
Ez nem azért van, mert a hosting backup szükségszerűen rossz.
Egyszerűen nem jó biztonsági stratégia olyan mentésre hagyatkozni, amelynek a működését, tartalmát és visszaállítási feltételeit nem ismered.
A backup ne legyen nyilvánosan elérhető
Egy WordPress backup kifejezetten érzékeny adatokat tartalmazhat.
Az adatbázis-exportban lehetnek felhasználói adatok és konfigurációs értékek. A fájlmentésben ott lehet a wp-config.php, egyedi kód, feltöltött dokumentum vagy más nem nyilvános tartalom.
Az adott oldal és konfiguráció függvényében a backup olyan hitelesítési vagy konfigurációs adatokat is tartalmazhat, mint például:
- adatbázis-hitelesítési adatok;
- API-kulcsok;
- SMTP hitelesítési adatok;
- más konfigurációs secretek.
Nem minden WordPress backup tartalmazza mindezeket. Attól függ, milyen adatokat ment a rendszer és hol tárolja az adott oldal a hitelesítési információkat.
A következmény viszont fontos: egy jogosulatlanul megszerzett backup bizonyos esetekben nem csak adatszivárgást jelenthet. Olyan hozzáférési információk is lehetnek benne, amelyek más rendszerekhez használhatók.
Ezért a backupot nem érdemes egyszerűen egy publikus webkönyvtárban hagyni csak azért, mert onnan könnyű letölteni.
Ugyanez igaz a mentési rendszerhez tartozó hozzáférésekre.
Ha külső tárhelyre vagy más backup szolgáltatásba kerülnek a mentések, annak a hozzáférését is megfelelően kell védeni.
A backup biztonságát érdemes a teljes rendszer részének tekinteni, nem pedig olyan másolatnak, amelyre már nem vonatkoznak az eredeti adatok védelmével kapcsolatos szempontok.
Érdemes titkosítani a mentéseket?
Ez attól függ, milyen adatokat tartalmaznak és hol vannak tárolva.
Egy mentésben lehetnek személyes adatok, konfigurációs értékek, hitelesítési adatok és más érzékeny információk, ezért bizonyos környezetekben indokolt lehet a backup titkosítása, különösen ha olyan tárolóhelyre kerül, ahol ez érdemi további védelmet ad.
A WordPress hardening dokumentációja a mentéseket a biztonság fontos részeként kezeli. (developer.wordpress.org)
A titkosítás viszont egy új feladatot is létrehoz: a titkosítási kulcsot vagy más visszafejtéshez szükséges hozzáférést szintén biztonságosan kell kezelni.
Egy olyan tökéletesen titkosított backup, amelyet szükség esetén senki nem tud visszafejteni, helyreállítási szempontból nem sokat ér.
Az automatikus backup jó, de ellenőrizni is kell
A legtöbb WordPress oldalnál teljesen ésszerű automatizálni a rendszeres mentéseket.
Ez történhet például:
- tárhelyszolgáltatói rendszerrel;
- WordPress backup pluginnal;
- külső mentési szolgáltatással;
- szerveroldali automatizmussal;
- más, az infrastruktúrához illeszkedő megoldással.
Nincs egyetlen olyan 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 kézzel elindítani.
Egy backup plugin használata ugyanakkor önmagában még nem jelent off-site backupot.
Ha a plugin sikeresen elkészíti a mentést, de azt ugyanazon a webszerveren vagy ugyanabban a WordPress környezetben hagyja, akkor továbbra is fennállhat a közös hibapont problémája.
A mentés elkészítésének módja és a mentés tárolási helye két külön kérdés.
Ez nem jelenti azt, hogy a WordPress backup plugin rossz megoldás lenne. Sok esetben teljesen megfelelő része lehet egy mentési rendszernek. Csak azt é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 olyan fájl, amely valójában használhatatlan.
Ezért a „beállítottam az automatikus backupot” és a „biztosan vannak használható mentéseim” nem ugyanaz az állítás.
A mentés sikeréről is érdemes tudni
Egy automatikus backup rendszernek nemcsak futnia kell, hanem valamilyen módon ellenőrizhetőnek is kell lennie.
Érdemes tudni például:
- mikor készült az utolsó sikeres mentés;
- mekkora lett;
- tartalmazza-e azt, amit vársz tőle;
- történt-e hiba;
- elérhető-e a szükséges korábbi verzió.
Nem feltétlenül kell minden sikeres mentésről külön értesítés.
A hibák viszont ne maradjanak hónapokon keresztül észrevétlenek.
Egy backup 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 backup csak akkor ér valamit, ha visszaállítható
Ez talán a teljes mentési témakör legfontosabb pontja.
A backup elkészítése és a sikeres visszaállítás két külön feladat.
Lehet egy teljesen 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 tesztelni a visszaállítást.
Nem feltétlenül az éles oldal felülírásával.
Egy megfelelően elkülönített teszt- vagy staging környezetben ellenőrizhető, hogy a backupból valóban felépíthető-e egy működő weboldal.
A WordPress saját dokumentációja is hangsúlyozza, hogy a rendszeres mentés mellett tudni kell a visszaállítás módját, mielőtt olyan változtatásokat végzünk, amelyeknél szükség lehet rá. (developer.wordpress.org)
A próba-visszaállítás jelentősége azonban nem csak abból áll, hogy technikailag ki lehet-e bontani egy fájlt. Azt ellenőrzi, hogy a teljes helyreállítási folyamat valóban működőképes-e.
A backup nem ugyanaz, mint a teljes helyreállítási terv
A mentések megléte a helyreállítás egyik legfontosabb alapja, de attól még nincs teljes helyreállítási tervünk, hogy léteznek backupok.
Egy valódi visszaállításnál azt is tudni kellhet például:
- ki végzi el a helyreállítást;
- milyen hozzáférések szükségesek hozzá;
- hova történik a restore;
- milyen sorrendben kell visszaállítani az egyes elemeket;
- hogyan ellenőrizzük utána, hogy az oldal valóban megfelelően működik.
Ennek különösen az RTO szempontjából lehet jelentősége.
Lehet kiváló mentésed, de ha egy incidens közben először kell kideríteni, hol van a tárhely belépése, ki fér hozzá a backuphoz és hogyan indul a restore, a tényleges helyreállítás sokkal tovább tarthat.
Nem feltétlenül kell ehhez hosszú disaster recovery dokumentáció. A lényeg az, hogy a backup mellett maga a helyreállítás útja is ismert legyen.
Mit érdemes ellenőrizni egy próba-visszaállítás után?
Nem feltétlenül 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 más feltöltött fájlok;
- működik-e a használt sablon;
- elérhetők-e a szükséges pluginok;
- megfelelőek-e a fontos konfigurációk;
- működik-e a belépés;
- rendben vannak-e az oldal szempontjából kritikus funkciók.
Egy webáruháznál nyilván más funkciók számítanak kritikusnak, mint egy egyszerű bemutatkozó weboldalnál.
A helyreállítási teszt célja éppen az, hogy még egy valódi probléma előtt kiderüljön, mi hiányzik a mentésből vagy a dokumentált folyamatból.
A verziókövetés nem helyettesíti a backupot
Fejlesztett WordPress oldalaknál gyakori, hogy a sablon, egyedi plugin vagy más kód Gitben vagy más verziókövető rendszerben van.
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 nyomon követésére és korábbi kódállapotok visszaállítására alkalmas eszközzel. (developer.wordpress.org)
De a Git repository általában nem tartalmazza a teljes WordPress adatbázist és a felhasználók által feltöltött összes fájlt.
Ezért:
verziókövetés és backup két külön problémát old meg.
A verziókövetés kiváló lehet arra, hogy lásd, mi változott a kódban, vagy visszaállíts egy korábbi verziót.
A teljes weboldal helyreállításához viszont továbbra is szükség lehet a mentésekre.
A backup nem security megoldás
A mentés a WordPress biztonság fontos része, de van egy lényeges korlátja:
nem akadályozza meg a kompromittálást.
Egy jó backup segíthet a helyreállításban.
Nem javít ki egy sérülékeny plugint, nem teszi erőssé a gyenge jelszót, nem kapcsol be 2FA-t, és nem akadályozza meg önmagában, hogy valaki jogosulatlanul hozzáférjen az oldalhoz.
Ezért a mentést nem érdemes a frissítések, a megfelelő hozzáférés-kezelés vagy a monitoring helyett használni.
A megelőző biztonsági rétegekről részletesebben a WordPress biztonság: mit érdemes beállítani, mielőtt megtörténik a baj? cikkben írok.
Biztonsági incidensnél ne feltételezd automatikusan, hogy a legutóbbi backup tiszta
Ha egy WordPress oldalt feltörtek vagy malware került rá, kézenfekvő ötlet egy korábbi mentés visszaállítása.
Ez működhet, de fontos tudni, hogy a fertőzés észlelésének időpontja nem feltétlenül azonos a kompromittálás időpontjával.
Ha kedden veszed észre a problémát, attól még elképzelhető, hogy az oldal már előző pénteken érintett volt.
Ebben az esetben a hétfői backup 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.
Az olyan biztonsági ajánlások, amelyek ransomware-helyreállítással foglalkoznak, szintén 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 backup különösen fontos.
Ha egy megtisztított oldalra nem megfelelő backupbó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 részletesebben a Miért fertőződik újra a WordPress oldal a tisztítás után? cikkben írok.
Milyen egy ésszerű WordPress backup stratégia?
Nem minden oldalhoz ugyanaz a mentési rendszer szükséges.
Egy egyszerű bemutatkozó weboldal és egy folyamatosan változó webshop kockázata, adatmennyisége és helyreállítási igénye teljesen eltérő lehet.
A technológia helyett ezért először ezeket a kérdéseket érdemes megválaszolni:
- Pontosan milyen fájlokra és adatbázis-adatokra van szükség a teljes helyreállításhoz?
- Milyen gyakran változnak ezek az adatok?
- Legfeljebb mennyi adat elvesztése fér bele?
- Mennyi ideig maradhat kiesve az oldal, vagyis milyen gyorsan kell tudni helyreállítani?
- Hány korábbi helyreállítási pontra lehet szükség?
- Van-e legalább egy megfelelően elkülönített mentési példány?
- Egy kompromittált hozzáférés elérheti-e egyszerre az éles rendszert és az összes backupot?
- Ki és hogyan fér hozzá a backupokhoz?
- Észrevehető-e, ha a mentési folyamat hibára fut?
- Próbáltad-e már ténylegesen visszaállítani az oldalt?
- Dokumentálva van-e 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, mint hogy „naponta készül backup”.
Mikor érdemes felülvizsgálni a mentési rendszert?
A backup 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 a deployment folyamat;
- jelentősen nő az adatbázis vagy a feltöltött fájlok mennyisége;
- kiderül, hogy a jelenlegi retention már nem megfelelő;
- egy visszaállítási teszt problémát talál.
Egy olyan mentési rendszer, amely három éve megfelelő volt egy tízoldalas bemutatkozó oldalhoz, nem biztos, hogy ugyanúgy megfelelő marad, 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 található a tartalmak és beállítások jelentős része, míg a fájlok között vannak többek között a pluginok, sablonok, feltöltött média, a wp-config.php és más, az oldal működéséhez szükséges elemek.
Milyen gyakran kell WordPress backupot készíteni?
Nincs minden oldalra érvényes gyakoriság.
Azt érdemes meghatározni, mennyi adat elvesztése elfogadható. Ezt a szakmai terminológia RPO-nak nevezi. 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?
Teljes WordPress helyreállításhoz általában nem.
Az adatbázis mellett szükség lehet a sablonokra, pluginokra, feltöltött fájlokra, konfigurációkra és más, az oldalhoz tartozó fájlokra is.
Elég csak a tárhelyszolgáltató backupja?
Lehet, hogy a szolgáltató mentése megfelelő az adott oldalhoz, de ezt érdemes ellenőrizni.
Fontos tudni, hogy mit ment, milyen gyakran, mennyi ideig őrzi meg, hogyan lehet visszaállítani, és mi történik akkor, ha maga a tárhely vagy a hozzáférés válik problémássá.
Hol tároljam a WordPress mentést?
Érdemes úgy kialakítani a rendszert, hogy ne minden backup kizárólag ugyanazon a szerveren vagy ugyanabban a könnyen együtt érinthető környezetben legyen, mint az éles oldal.
Legalább egy megfelelően elkülönített mentési példány csökkentheti annak kockázatát, hogy ugyanaz az esemény az oldalt és az összes backupot egyszerre tegye használhatatlanná.
Az elkülönítésnél nemcsak a tárolási helyet, hanem a hozzáféréseket is érdemes figyelembe venni.
Hány korábbi backupot tartsak meg?
Erre sincs univerzális szám.
Több korábbi helyreállítási pont azért fontos, mert egy hibát vagy kompromittálást nem feltétlenül azonnal veszel észre. Ha mindig csak az előző mentést tartod meg, könnyen előfordulhat, hogy az már ugyanazt a problémás állapotot tartalmazza.
A retentiont ezért az oldal működéséhez, a problémák lehetséges észlelési idejéhez és a helyreállítási elvárásokhoz érdemes igazítani.
Honnan tudom, hogy jó a backup?
Nem abból, hogy a mentési rendszer azt írja: „sikeres”.
A valódi ellenőrzés az, hogy a szükséges fájlok és adatok megvannak-e, valamint az oldal ténylegesen visszaállítható-e belőlük.
Ezért érdemes időnként próba-visszaállítást is végezni megfelelően elkülönített környezetben.
A backup megvéd attól, hogy feltörjék a WordPress oldalt?
Nem.
A backup helyreállítási eszköz. Egy kompromittálás után nagyon fontos lehet, de nem helyettesíti a frissítéseket, az erős hozzáférés-védelmet, a 2FA-t, a megfelelő jogosultságokat vagy a többi biztonsági réteget.
A jó WordPress mentés végső soron nem attól jó, hogy minden éjjel elkészül egy fájl. Attól jó, hogy a megfelelő adatokat, megfelelő gyakorisággal, megfelelő helyen őrzi, és amikor valóban szükség van rá, vissza is tudsz belőle állni.