Élő oldal visszaállítása mentésből: sorrend, hogy ne veszíts megrendelést

Scheo · 2026-09-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy élő oldal visszaállítása mentésből ritkán technikai kérdés, sokkal inkább a sorrenden múlik. Maga a visszatöltés pár perc, a baj abból lesz, ha a mentés óta beérkezett megrendeléseket, űrlapkitöltéseket és hozzászólásokat egyetlen mozdulattal felülírod. Az alábbi lépéssorrend WordPress- és WooCommerce-oldalakra épül, de a logikája bármilyen adatbázis-alapú oldalon működik.

Mi a helyes sorrend, ha élő oldalt kell visszaállítani mentésből?

A helyes sorrend: karbantartási mód, a jelenlegi (hibás) állapot teljes lementése, annak eldöntése, hogy az adatbázist, a fájlokat vagy mindkettőt kell-e visszaállítani, maga a visszaállítás, a különbség pótlása, a gyorsítótárak ürítése, végül egy ellenőrző kör. Ha bármelyik lépés felcserélődik, jó eséllyel adat vész el.

1. Karbantartási mód: lezárod a bejövő írásokat (rendelés, űrlap, regisztráció, hozzászólás).
2. Pillanatkép a mostani állapotról: adatbázis és fájlok, akkor is, ha hibásak.
3. Diagnózis: mi romlott el, és melyik rétegben.
4. Részleges vagy teljes visszaállítás.
5. Különbség-pótlás: a mentés óta keletkezett rendelések, űrlapadatok, feltöltött képek.
6. Gyorsítótárak és CDN ürítése.
7. Ellenőrző kör, a karbantartási mód kikapcsolása, majd még egy ellenőrzés élesben.

A leggyakoribb hiba, hogy valaki a tárhelypanelen rögtön a visszaállítás gombra kattint. Ezzel a mentés óta eltelt összes változás törlődik, és utána már nincs honnan visszanyerni őket.

Miért kell karbantartási módba tenni az oldalt a visszaállítás előtt?

Azért, hogy a visszaállítás közben ne keletkezzen új adat, amely elvész, vagy félkész állapotban kerül az adatbázisba. Egy webshopban a vásárló a visszatöltés közben is fizethet, és ilyenkor előfordul, hogy a pénz megvan a fizetési szolgáltatónál, a rendelés viszont nincs meg az oldalon.

Hivatalosan igazolt: a Google Search Central útmutatója szerint átmeneti leálláskor az oldal 503-as (Service Unavailable) HTTP-állapotkódot adjon, lehetőleg Retry-After fejléccel. A Google ezt ideiglenes állapotként kezeli, de ha a 503 napokig megmarad, az URL-ek kieshetnek az indexből. A WordPress beépített karbantartási módja, amelyet a gyökérkönyvtárban lévő .maintenance fájl kapcsol be, 503-as kódot küld.

WP-CLI-vel így kapcsolod be:

wp maintenance-mode activate

Kívülről is ellenőrizd, például így: curl -I https://pelda.hu. A válasz első sorában 503-nak kell állnia. Sok karbantartási bővítmény a bejelentkezett adminnak nem mutatja a karbantartási oldalt, ezért a saját böngésződ félrevezethet.

Saját tapasztalat: webshopnál a bekapcsolás előtt érdemes a fizetési szolgáltató felületén megnézni, van-e éppen folyamatban lévő tranzakció, és pár percet várni. Így kisebb az esélye, hogy egy fizetés félúton marad.

Miért mentsd le a hibás állapotot is, mielőtt visszaállítasz?

Mert a hibás állapotban van meg a mentés óta beérkezett összes megrendelés és űrlapadat, és ez az egyetlen forrásod a különbség pótlásához. Ha pedig a visszaállítás rosszul sül el, ebből tudsz visszalépni.

Adatbázis WP-CLI-vel:

wp db export elotte_2026-09-13_0915.sql

WP-CLI nélkül:

mysqldump --single-transaction --quick --routines -u felhasznalo -p adatbazis > elotte.sql

Fájlok, legalább a wp-content mappa és a wp-config.php:

tar -czf elotte_fajlok.tar.gz wp-content wp-config.php

A mentést töltsd le a szerverről, és nevezd el időponttal, hogy később ne keverd össze a régi mentésekkel.

Hivatalosan igazolt: a MySQL dokumentációja szerint a --single-transaction kapcsoló InnoDB-táblák esetén zárolás nélkül ad konzisztens pillanatképet. Szakmai feltételezés: ha a hibát kártevő okozta, a most lementett fájlokat ne tedd vissza az oldalra, csak elkülönítve, adatforrásként használd.

Az adatbázist, a fájlokat vagy mindkettőt kell visszaállítani?

Csak azt a réteget állítsd vissza, amelyikben a hiba van: a kód- és bővítményhibák jellemzően a fájlokban, a tartalmi és beállítási hibák az adatbázisban vannak. A teljes visszaállítás a legegyszerűbb, de ezzel veszíted a legtöbb adatot.

Tipikus helyzetek

• Bővítmény- vagy témafrissítés után kritikus hiba: többnyire elég az érintett bővítmény mappáját visszaállítani. Figyelj arra, hogy egyes bővítmények frissítéskor az adatbázis szerkezetét is módosítják, és a régi kód ütközhet az új szerkezettel.
• Tömeges törlés, elrontott keresés-csere, hibás importálás: az adatbázis érintett táblái, gyakran csak egy-kettő.
• Feltört oldal: fájlok tiszta mentésből vagy friss WordPress-magból, az adatbázist pedig át kell vizsgálni (ismeretlen adminfelhasználók, beszúrt szkriptek a beállítások és a bejegyzések között).
• Tárhelyhiba vagy költözés: mindkét réteg, a legfrissebb mentésből, utána különbség-pótlással.

Saját tapasztalat: WooCommerce-nél a táblaszintű visszaállítás csapda. Ha a bolt még a régi tárolást használja, a rendelések a wp_posts táblában vannak shop_order típusként, így a csak bejegyzéseket érintő visszaállítás a rendeléseket is felülírja. A nagy teljesítményű rendeléstárolás (HPOS) mellett a rendelések külön táblákban vannak (wp_wc_orders és társai). Hogy melyik aktív, a WooCommerce beállításainál, a Speciális (Advanced) fül Funkciók részében látod.

Hogyan pótold a visszaállítás után a mentés óta beérkezett megrendeléseket és űrlapadatokat?

Az előtte lementett adatbázisból kilistázod a mentés időpontja után létrejött rekordokat, ellenőrzött módon visszaviszed őket, majd összeveted a fizetési szolgáltató és a számlázó rendszer adataival. A nyers SQL-másolás gyorsnak tűnik, de könnyen azonosító-ütközést okoz.

1. Húzd meg az időhatárt

Nézd meg, pontosan mikor készült a visszaállított mentés (a mentőbővítmény naplójában vagy a fájl időbélyegén). Minden, ami ezután keletkezett, pótolandó.

2. Listázd ki a különbséget

Az előtte készült mentést egy külön, ideiglenes adatbázisba töltsd be, ne az élőbe, és ott kérdezd le. HPOS esetén:

SELECT id, status, total_amount, billing_email, date_created_gmt FROM wp_wc_orders WHERE type = 'shop_order' AND date_created_gmt > '2026-09-12 00:00:00' ORDER BY id;

Régi tárolásnál ugyanezt a wp_posts táblában, post_type = 'shop_order' szűréssel kapod meg. Hozzászólásoknál a wp_comments, új regisztrációknál a wp_users tábla user_registered mezője a kiindulás. Az űrlapoknál az számít, menti-e a bővítmény az adatbázisba: a Gravity Forms igen, a Contact Form 7 önmagában nem, ott a beérkezett értesítő e-mailek a forrás.

Figyelj az időzónára: a _gmt végű mezők UTC-ben vannak, nyáron a magyar idő ehhez képest két órával előrébb jár.

3. Előzd meg az azonosító-ütközést

A visszaállított adatbázis a mentéskori számlálóról folytatja a rendelésszámokat. Ha a mentés óta az 1520-1534. rendelés jött be, újranyitás után a következő vásárló megint 1520-as számot kaphat, miközben a számlázóban és a fizetési szolgáltatónál már létezik egy másik 1520-as. A WooCommerce a rendelésazonosítót HPOS mellett is a wp_posts tábla számlálójából adja ki (helyőrző bejegyzéssel), ezért nyitás előtt ott emeld meg:

ALTER TABLE wp_posts AUTO_INCREMENT = 1600;

Ha sorszámozó bővítményt használsz, annak saját számlálója van, azt is állítsd át. Utána egy tesztrendeléssel ellenőrizd, milyen számot kap.

4. Vidd vissza és egyeztesd

• Kevés rendelésnél rögzítsd őket kézzel az adminban, az eredeti rendelésszámot és időpontot megjegyzésbe írva. Sok rendelésnél export-import bővítmény, de előbb tesztkörnyezetben.
• Ellenőrizd a készletet: a visszaállított adatbázis a mentéskori készletet mutatja.
• Vesd össze a fizetési szolgáltató tranzakciólistáját és a számlázót ugyanarra az időablakra. Ami ott megvan, nálad nincs, azt pótolni kell, vagy egyeztetni a vásárlóval.
• Nézd meg a szolgáltató felületén a karbantartás alatt sikertelen visszajelzéseket (webhookokat). Hivatalosan igazolt: a Stripe dokumentációja szerint élő módban akár három napig újrapróbálja a sikertelen kézbesítést. Más szolgáltatóknál ez eltérhet.
• A mentés óta feltöltött képeket (a wp-content/uploads friss havi mappáit) másold vissza az előtte készült fájlmentésből.

Miért kell a visszaállítás után üríteni a gyorsítótárat és a CDN-t?

Mert a gyorsítótár-rétegek tovább szolgálhatják ki a visszaállítás előtti oldalakat, így te azt látod, hogy minden rendben van, a látogató pedig mást lát. Rétegenként menj végig, belülről kifelé.

1. Objektum-gyorsítótár (Redis, Memcached): wp cache flush. Itt régi beállításértékek maradhatnak, amelyek felülírják a frissen visszatöltött adatbázist.
2. PHP OPcache: fájl-visszaállítás után a tárhelypanelen vagy a PHP-FPM újraindításával.
3. Gyorsítótár-bővítmény (például WP Rocket, LiteSpeed Cache): teljes törlés.
4. Szerveroldali gyorsítótár (Varnish, Nginx FastCGI cache, a tárhelyszolgáltató saját rétege).
5. CDN: Cloudflare-nél a Purge Everything, más CDN-nél a teljes törlés.

Saját tapasztalat: a CDN ürítését a karbantartási mód kikapcsolása után érdemes megismételni. Ha egyedi szabály minden választ gyorsítótáraz, a karbantartási oldal is bent ragadhat.

Mit ellenőrizz a visszaállítás utáni első percekben?

Azt, ami pénzt, érdeklődőt vagy láthatóságot hoz: fizetés, e-mail-küldés, mérőkódok, indexelhetőség és SSL. Ezeket a hibákat a látogató nem jelzi, egyszerűen elmegy.

Fizetés

• Teljes próbavásárlás a szolgáltató teszt módjában, vagy kis összegű éles vásárlás, majd visszatérítés.
• A rendelés állapota a fizetés után átáll-e, vagyis megérkezik-e a visszajelzés.
• Nem régi API-kulcs került-e vissza: ha a mentés óta kulcsot cseréltél, a visszaállított adatbázis a régit tartalmazza.

E-mail-küldés

• Megérkezik-e a rendelés-visszaigazolás a vásárlói és az admin címre.
• A kapcsolati űrlap próbakitöltése beérkezik-e, és nem a spambe.
• Az SMTP-bővítmény beállításai és jelszava is a mentéskori állapotot tükrözik, ezt külön nézd meg.

Mérőkódok

• A Google Tag Manager előnézeti módjában elsülnek-e a címkék.
• A GA4 valós idejű jelentésében vagy a DebugView-ban látszik-e a saját látogatásod és a próbavásárlás.
• A Meta pixel eseményei megjelennek-e az Events Manager tesztfelületén.
• Működik-e a süti-hozzájárulási sáv, mert nélküle a mérés egy része el sem indul.

Indexelhetőség

• wp option get blog_public: az 1-es érték jelenti, hogy a keresők nincsenek letiltva. Tesztkörnyezetből származó mentésnél itt gyakran 0 áll.
• A robots.txt nem tilt-e mindent, és nincs-e váratlan noindex az oldalforrásban.
• wp option get home: az éles domaint mutatja-e, nem egy teszt-aldomaint.
• Néhány fontos oldal élő tesztje a Search Console URL-ellenőrzőjében.

SSL

• Érvényes-e a tanúsítvány, és nem egy azóta lejárt került-e vissza fájlból.
• A siteurl és a home https-sel kezdődik-e.
• Nincs-e vegyes tartalom (http-n betöltött kép vagy szkript), ezt a böngésző konzolja jelzi.
• Működik-e az átirányítás http-ről https-re.

Végül nézd meg a háttérfeladatokat is: a WooCommerce ütemezett műveleteinél a karbantartás alatt feltorlódott, függőben lévő tételeket.

Miért fontosabb a visszaállítás gyakorlása, mint a mentés gyakorisága?

A mentés csak akkor mentés, ha már legalább egyszer sikeresen visszaállítottad belőle az oldalt. Egy óránként készülő, de soha ki nem próbált mentés kevesebbet ér, mint egy napi mentés, amelyről tudod, hogy működik, és azt is, mennyi idő alatt áll vissza belőle az oldal.

Saját tapasztalat: vészhelyzetben ritkán a mentés hiánya a gond. Sokkal inkább apróságok: a mentésből hiányzik egy tábla, mert a bővítmény csak az alapértelmezett előtagú táblákat vitte; sérült a tömörített fájl; a mentés ugyanazon a tárhelyen van, amelyik épp elérhetetlen; senki nem tudja a mentési tárhely jelszavát; vagy a visszaállítás három óráig tart húsz perc helyett. Ezek csak próbánál derülnek ki.

Negyedévente érdemes lefuttatni egy gyakorlókört:

1. Válassz egy nem a legfrissebb mentést.
2. Állítsd vissza egy elkülönített tesztkörnyezetbe, amelyet a keresők nem indexelnek, és amely nem küld levelet a vásárlóknak.
3. Mérd az időt az első lépéstől a működő oldalig.
4. Futtasd le rajta a fenti ellenőrzőlistát.
5. Írd le, hol akadtál el, és javítsd a mentési beállításokat vagy a leírást.

Szakmai feltételezés: a mentés gyakoriságát ahhoz érdemes igazítani, mennyi adatot tudsz kézzel pótolni. Napi néhány rendelésnél egy napi mentés és egy begyakorolt különbség-pótlás jó eséllyel elég; óránként sok rendelésnél már a gyakoribb adatbázis-mentés is számít. A visszaállítás ideje viszont csak gyakorlással csökken.

Hivatalosan igazolt: a CISA (az amerikai kiberbiztonsági ügynökség) mentési útmutatója a 3-2-1 elvet ajánlja: három példány, két különböző adathordozón, ebből egy a helyszínen kívül.

Források és további olvasnivalók

• Google Search Central: Webhely ideiglenes szüneteltetése vagy letiltása (503-as állapotkód)
• WordPress.org dokumentáció: WordPress Backups
• WP-CLI Handbook: wp db export, wp maintenance-mode, wp cache flush
• WooCommerce dokumentáció: High-Performance Order Storage (HPOS)
• MySQL Reference Manual: mysqldump
• Cloudflare dokumentáció: Purge cache
• Stripe dokumentáció: Webhooks
• CISA: Data Backup Options