A szakmai beszélgetések egyik legkellemetlenebb pillanata az, amikor kiderül: van mentés, csak éppen nem lehet belőle visszaállni. A tárhelyen ott a napi archívum, a plugin felülete zöld pipát mutat, a fájlméret is hihető, aztán a kicsomagolásnál látszik, hogy az adatbázis-dump félmondatnál elvágódott, vagy a wp-content/uploads mappa egyszerűen hiányzik belőle.
Saját tapasztalat: a legtöbb WordPress-üzemeltetőnél nem a mentés hiányzik, hanem a bizonyíték arról, hogy a mentés működik. A kettő közötti különbség akkor derül ki, amikor már ég a ház: adatbázis-sérülés, elrontott frissítés, kártékony kód vagy egy törölt könyvtár után. Ez a cikk arról szól, hogyan lesz a mentésből valódi biztosíték, és hogyan tudod ezt negyedévente, kockázat nélkül ellenőrizni.
Mitől lesz egy mentés valóban használható?
Rövid válasz: attól, hogy legalább egyszer, ellenőrzött körülmények között visszaállítottad belőle a teljes oldalt, és tudod, mennyi ideig tartott. Minden más csak fájl a lemezen.
Egy használható mentésnek négy tulajdonsága van. Teljes: a fájlok, az adatbázis és a feltöltések ugyanabból az időpontból származnak. Konzisztens: az adatbázis nem írás közben készült pillanatfelvétel. Elérhető: akkor is hozzáférsz, ha a szerver megszűnt létezni. Bizonyított: van dátumod arról, mikor állítottad vissza utoljára sikeresen. Ha ebből a négyből bármelyik hiányzik, a mentés inkább reményt jelent, mint védelmet.
Mit kell pontosan menteni egy WordPress-oldalon?
Rövid válasz: a teljes fájlrendszert, a MySQL/MariaDB-adatbázist és a feltöltéseket, plusz a konfigurációt, ami nélkül a másik három nem indul el.
- Adatbázis: ez a tartalom, a beállítások, a felhasználók és a legtöbb bővítmény adata. Bejegyzésenként külön exportálva (WordPress WXR) nem elég: a WXR nem tartalmaz mindent, például a beállítások jelentős részét sem.
- wp-content mappa: a sablon, a bővítmények, a feltöltések, és sok esetben a cache- vagy nyelvi könyvtárak.
- Feltöltések (
wp-content/uploads): ez általában a legnagyobb és a legkevésbé pótolható rész. Egy 15 GB-os képtár újragyártása nem opció. - Konfiguráció:
wp-config.php,.htaccessvagy nginx-beállítások, cron-bejegyzések, e-mail- és DNS-adatok. Utóbbi kettő nem a mentésben van, de a helyreállítási leírásban ott kell lennie. - Mag (core) fájlok: ezek pótolhatók a wordpress.org-ról, de a verziószámot jegyezd fel, mert egy régebbi adatbázis és egy újabb core keveréke gondot okozhat.
Kézi ellenőrzésre a legegyszerűbb út a WP-CLI:
wp db export mentes-$(date +%F).sql --add-drop-table
tar -czf files-$(date +%F).tar.gz wp-content wp-config.php .htaccess
Hivatalosan igazolt: a WordPress dokumentációja is a fájlok és az adatbázis együttes mentését írja le teljes mentésként, és a WP-CLI hivatalos parancsreferenciája tartalmazza a wp db export és wp db import párost.
Milyen gyakran mentsd, és meddig őrizd meg?
Rövid válasz: a mentési gyakoriságot az szabja meg, mennyi adat elvesztését viselné el az üzlet, a megőrzési időt pedig az, mennyi idő alatt szoktak kiderülni a bajok.
Egy statikus bemutatkozó oldalnál a heti teljes mentés plusz a frissítések előtti kézi mentés általában elegendő. Napi több rendelést kezelő webshopnál a napi mentés is kevés lehet: ott az adatbázisra érdemes gyakoribb, akár óránkénti mentést állítani, a nagy fájlállományra pedig ritkábbat. Szakmai feltételezés: a legtöbb kis- és középvállalati oldalnál a napi adatbázis- és heti teljes fájlmentés kombinációja jó kompromisszum a tárhelyigény és a kockázat között, de ezt a saját forgalmi adataid alapján érdemes eldönteni.
A megőrzésnél a gyakori hiba a felülírásos rendszer: egyetlen mentés van, amit minden éjjel felülír a friss. Ha a hiba két hete keletkezett, ez a rendszer csak a hibát őrzi meg. Használj generációkat: napi mentésekből 7 darab, hetiből 4, haviból 3 vagy 6. Így egy lassan romló adatbázis vagy egy csendben terjedő kártékony kód esetén is találsz tiszta pontot.
Hová kerüljön a mentés, és ki férhet hozzá?
Rövid válasz: a szervertől külön helyre, ahol a weboldal kompromittálódása nem érinti a mentést, és ahová csak néhány, névre szóló hozzáférés vezet.
A tárhelyen belüli mappa nem külső mentés. Ha a szolgáltatói fiók vész el, a lemez hibásodik meg, vagy támadó jut hozzá a fiókhoz, a mentés is vele megy. A gyakorlatban jól működő elrendezés: elsődleges másolat egy objektumtárolóban vagy külön felhőmeghajtón, másodlagos másolat egy fizikailag más helyszínen (akár egy irodai NAS-on). A régi, de máig érvényes hüvelykujjszabály a 3-2-1: három példány, két különböző adathordozón, egy telephelyen kívül.
A hozzáférésnél három dolog számít. Legyen névre szóló (ne közös jelszó), legyen szűk (az oldal futtató felhasználója írhat a mentéstárba, de ne törölhessen belőle), és legyen naplózott. Az írás-csak jogosultság, vagy ahol elérhető, a törlésvédett (immutable) tárolás sokat számít, mert a zsarolóvírusok jellemzően a mentéseket is keresik. Saját tapasztalat: a legtöbb kisvállalati környezetben a mentések ugyanazzal az FTP-jelszóval érhetők el, amivel az oldal is. Ez a beállítás pontosan azt a forgatókönyvet nem védi ki, ami miatt a mentés készül.
Hogyan próbálod ki a visszaállítást élesben történő kockázat nélkül?
Rövid válasz: ne az éles oldalra állíts vissza, hanem egy staging alá vagy egy helyi környezetbe, ami az éles oldal külön példánya, és semmilyen ponton nem ír bele az élesbe.
Három út van, mind járható. Az első a tárhelyszolgáltató staging funkciója: gyors, de figyelj arra, hogy a staging tényleg izolált legyen (külön adatbázis, külön fájlrendszer, indexelés letiltva). A második a helyi környezet, például LocalWP, DDEV vagy Docker. A harmadik egy ideiglenes, olcsó tárhely vagy virtuális gép, amit a próba után törölsz. Szakmai feltételezés: a helyi környezet ad a legtisztább képet arról, hogy a mentés önmagában elég-e, mert ott semmilyen szerveroldali beállítás nem segít ki menet közben.
A próba során ezekre figyelj: a visszaállított oldal az siteurl és home értékeit a próbakörnyezetre mutassa, a keresőmotorok indexelése legyen letiltva, a kimenő e-mail-küldés legyen kikapcsolva vagy elfogva, és a fizetési, illetve szinkronizáló bővítmények éles kulcsai ne maradjanak bent. Az URL-cserét WP-CLI-vel a szerializált adatokat is helyesen kezelve teheted meg:
wp search-replace 'https://oldal.hu' 'http://oldal.test' --all-tables --precise
Mennyi idő alatt áll helyre az oldal?
Rövid válasz: ezt csak méréssel tudod meg, és pontosan ez az a szám, amit a mentési rendszeredről tudnod kell.
Hivatalosan igazolt: az üzletmenet-folytonossági szakirodalom, például a NIST vonatkozó ajánlása, két mutatót használ. Az RTO (Recovery Time Objective) azt mondja meg, mennyi kiesést tűr el a működés, az RPO (Recovery Point Objective) pedig azt, mennyi adat elvesztése fér bele. A mentési gyakoriság az RPO-t határozza meg, a helyreállítási folyamat minősége pedig az RTO-t.
Saját tapasztalat szerinti nagyságrendek (nem ígéret, hanem tapasztalati sáv): egy néhány száz megabájtos bemutatkozó oldal jól előkészített mentésből tipikusan negyed és másfél óra között áll vissza. Egy több gigabájtos, sok médiát tartalmazó webshopnál a fájlok másolása önmagában órákat vehet igénybe, és a DNS-átállás, a levelezés vagy a fizetési szolgáltató újrakötése ehhez még hozzáadódik. Ha nem méred, a becslésed jó eséllyel a valós idő töredéke lesz, és a válságkommunikációdat is erre a téves számra fogod építeni.
Mit tegyél, ha maga a mentés is fertőzött?
Rövid válasz: keresd meg a fertőzés első napját, és onnan visszafelé válaszd ki a mentést, majd a visszaállítás után ellenőrizd a fájlok integritását, mielőtt élesbe kapcsolod.
A kártékony kód gyakran hetekig észrevétlen marad, tehát a legfrissebb mentés is tartalmazhatja. Ilyenkor a menet: (1) a szerver- és WordPress-naplókból, illetve a fájlok módosítási dátumaiból határold be, mikor jelent meg az első idegen fájl; (2) válassz egy ennél korábbi generációt; (3) állítsd vissza izolált környezetbe; (4) futtass integritás-ellenőrzést.
wp core verify-checksums
wp plugin verify-checksums --all
Ez a két parancs a hivatalos csomagokhoz hasonlítja a fájlokat, és kilistázza az eltéréseket. Ha a régebbi mentés is fertőzött, a járható út a tiszta újraépítés: friss WordPress-mag, bővítmények újratelepítése hivatalos forrásból, és csak az adatbázis, illetve a feltöltések átemelése, előzetes átvizsgálás után. A visszaállítás után minden jelszót és API-kulcsot cserélni kell, mert a mentésben benne voltak. Hivatalosan igazolt: a Google Search Central feltört oldalakra vonatkozó útmutatója is a takarítás utáni jelszócserét és a felhasználói fiókok átnézését írja le kötelező lépésként.
Hogyan néz ki egy negyedéves helyreállítási próba 7 lépésben?
Rövid válasz: egy naptárba beírt, két órás blokk, aminek a végén van egy dátumod és egy mért időd.
- Kiválasztás. Vedd a legfrissebb teljes mentést, és jegyezd fel a méretét, a dátumát és a forrását. Indíts stoppert.
- Letöltés és épség-ellenőrzés. Töltsd le a külső tárolóból, ellenőrizd az ellenőrzőösszeget, és csomagold ki. Már itt kiderül a fél letöltésből származó sérülés.
- Környezet felállítása. Hozz létre üres staging vagy helyi példányt, benne az élessel azonos PHP- és adatbázis-verzióval. A verzióeltérés a próba egyik leggyakoribb buktatója.
- Visszaállítás. Importáld az adatbázist, másold a fájlokat, futtasd az URL-cserét, és tiltsd le az indexelést, valamint a kimenő leveleket.
- Működés-ellenőrzés lista alapján. Nyitóoldal, egy aloldal, egy termék- vagy szolgáltatásoldal, kereső, űrlapbeküldés, bejelentkezés, kosár vagy időpontfoglalás, médiafájlok megjelenése, admin felület hibaüzenetek nélkül.
- Az idő rögzítése. Állítsd meg a stoppert, és írd fel, hány percbe telt, hol akadt el a folyamat, és mi hiányzott a mentésből.
- Javítás és dokumentálás. Amit hiányoltál, azt tedd bele a mentési körbe, a leírást pedig frissítsd úgy, hogy nélküled is végrehajtható legyen. Ezután töröld a próbakörnyezetet.
A hetedik lépés a legfontosabb és a legtöbbször kihagyott. Egy helyreállítási leírás, amit csak te értesz, szabadság vagy betegség idején nem sokat ér.
Mi a három leggyakoribb ok, amiért egy mentés használhatatlan?
Rövid válasz: a hiányos tartalom, a csendben elhalt mentési folyamat és a hiányzó helyreállítási tudás.
- Hiányzik belőle valami. Leggyakrabban a feltöltések mappa, mert a bővítmény méretkorlátba ütközött, vagy a szerver megölte a folyamatot időtúllépés miatt. A mentés elkészül, csak éppen a képek nélkül.
- A mentés hetek óta nem fut. Lejárt a felhőtároló jogosultsága, betelt a kvóta, elromlott a WP-Cron, vagy a bővítmény frissítés után némán leállt. Hibajelzés nincs, mert soha nem állítottad be az értesítést a sikertelen futásra.
- Senki nem tudja, hogyan kell visszaállítani. A fájl megvan, a folyamat viszont nincs leírva: nincs adatbázis-hozzáférés, nincs dokumentálva a PHP-verzió, senki nem tudja, hol vannak a DNS-beállítások. A technikai mentés kész, a szervezeti tudás hiányzik.
Saját tapasztalat: ebből a háromból a második a legalattomosabb, mert a felület továbbra is a legutóbbi sikeres futást mutatja. Ezért érdemes olyan riasztást beállítani, ami a mentés elmaradását jelzi, nem csak a hibáját.
Miért egyetlen szám méri a mentési stratégia értékét?
Saját nézőpont: a mentési rendszer minden más jellemzője (hány generáció van, milyen tárolóban, milyen titkosítással) csak addig érdekes, amíg nem esik ki az oldal. Attól a perctől egyetlen kérdés marad: mennyi idő alatt vagy újra online. Ez a szám foglalja magába az összes többit, mert ha a mentés hiányos, ha a hozzáférés lassú, vagy ha nem tudod a lépéseket, az mind ebben az időben jelenik meg.
Ha ezt a számot ismered, üzleti döntést tudsz hozni: elfogadható-e négy óra kiesés, vagy érdemes olyan megoldásba beruházni, ami ezt húsz percre viszi le. Ha nem ismered, csak reményed van. A negyedéves próba lényege pontosan az, hogy ezt a számot ne az incidens napján ismerd meg először. A visszaállítás sikeres kipróbálása nem szünteti meg a kockázatot, de a bizonytalanság nagy részét kiveszi a rendszerből, és ez már mérhető különbség.
Források és további olvasnivalók
- WordPress.org Support: WordPress Backups
- WordPress Developer Resources: Backing Up Your Database
- WP-CLI Command Reference (wp db, wp search-replace, wp core verify-checksums)
- Google Search Central: Help for hacked sites
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
- OWASP Application Security Verification Standard (ASVS)
- MySQL Reference Manual: mysqldump
- Egy mentés akkor létezik, ha legalább egyszer sikeresen visszaállítottad belőle a teljes oldalt.
- Három elem kell hiánytalanul: a fájlrendszer, az adatbázis és a feltöltések mappája, ugyanabból az időpontból.
- A mentés tárolása a szervertől külön helyen történjen, korlátozott hozzáféréssel és több generációval.
- A fertőzött mentés valós eset: a helyreállításhoz mindig kell egy incidens előtti, ellenőrzött visszaállítási pont.
- A mentési stratégia egyetlen igazi mérőszáma az, hogy hány perc vagy óra alatt vagy újra online.
Gyakori kérdések
Elég, ha a tárhelyszolgáltatóm készít mentést?
Ez jó alap, de önmagában kockázatos. A szolgáltatói mentés jellemzően a szerveren vagy annak infrastruktúráján belül tárolódik, és a megőrzési ideje rövid lehet. Kérdezd meg, hány napra visszamenőleg érhető el, mennyi idő alatt adják ki, és van-e önkiszolgáló visszaállítás. Emellett tarts fenn egy tőlük független másolatot is.
Milyen gyakran érdemes helyreállítási próbát tartani?
Negyedévente elegendő a legtöbb kisebb oldalnál, illetve minden olyan alkalommal, amikor jelentősen változik a környezet: tárhelyköltözés, PHP-verzióváltás, új mentőmegoldás bevezetése vagy nagy szerkezeti átalakítás után.
Mennyi helyet foglal egy értelmes mentési rend?
Nagyjából az oldal méretének két-négyszeresét, mert több generációt tárolsz. A feltöltések mappa általában a teljes méret 80-90 százalékát adja, ezért érdemes a fájlokra ritkább, az adatbázisra gyakoribb mentést állítani.
Vissza tudok állni akkor is, ha a tárhelyszolgáltatóm megszűnik?
Csak akkor, ha van tőlük független másolatod, és ismered a kiegészítő adatokat: a domain regisztrátorát, a DNS-rekordokat, a levelezés beállításait és a PHP-verziót. A fájlok és az adatbázis önmagában nem elég egy új szolgáltatónál.
Titkosítsam a mentéseket?
Ha személyes adatot tartalmazó adatbázisról van szó, akkor igen, mert a mentés ugyanazokat az adatokat hordozza, mint az éles rendszer. Fontos viszont, hogy a visszafejtő kulcs ne csak azon a gépen legyen, amit egy incidens érinthet.
Mit ellenőrizzek először egy visszaállított oldalon?
A nyitóoldalt és egy aloldalt, a médiafájlok megjelenését, egy űrlapbeküldést, a bejelentkezést, és ha van, a kosarat vagy a foglalási folyamatot. Ha ezek működnek, a mentés magja rendben van; a részletek utána javíthatók.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.