A mentendő tartalom

A sablon, feltöltések és adatbázis különböző adatokat őriznek. Listázd a fájlokat, adatbázist, konfigurációt és az újraépítéshez szükséges hozzáféréseket.

A WordPress adatbázisa őrzi többek között a tartalmat, beállításokat és sok bővítmény adatait, a fájlok pedig a feltöltéseket, sablont és kódot tartalmazzák. A kettő összetartozik. A puszta képmappa nem hozza vissza a bejegyzéseket, az adatbázis önmagában pedig nem biztosítja a feltöltött dokumentumot. A külső szolgáltatásban tárolt adat külön kérdés: egy CRM vagy levelező rendszer tartalmát nem feltétlenül foglalja magában a webhelymentés. Készíts adat- és függőségleltárt arról, mi szükséges a működés helyreállításához. A konfiguráció tartalmazhat titkot, ezért a mentés hozzáférését és továbbítását ennek megfelelően védd. A mentési kör pontos ismerete segít elkerülni, hogy baj esetén derüljön ki egy kritikus rész hiánya. A mentésből a teljes szükséges működés helyreállítható.

Gyakoriság

A ritka mentés nagyobb időszak új adatait hagyhatja védelem nélkül. A mentés ütemét a rendelések, szerkesztések és egyéb változások gyakoriságához igazítsd.

A mentési gyakoriságot az elfogadható adatvesztésből érdemes levezetni. Egy ritkán változó bemutatkozó oldal és egy folyamatosan rendelést fogadó webshop eltérő helyzet. A napi másolat azt jelentheti, hogy a két mentés között létrejött adat külön helyreállítást igényel vagy elveszhet. Az üzleti felelősnek ezt értenie kell, nem elég egy technikai ütemezés neve. A mentés elkészülési ideje és az érintett adatok közötti következetesség is számít. Nagyobb adatbázisnál a módszer hatását meg kell vizsgálni a működésre. A különböző időpontú változatok megőrzése segíthet később felfedezett hibánál, de a megőrzési rendet tárhellyel, biztonsággal és adatkezelési szempontokkal együtt kell tervezni. A vállalkozás érti és elfogadja a lehetséges adatvesztési időablakot.

Elkülönített tárolás

A kizárólag ugyanazon tárhelyen őrzött mentés közös hibának lehet kitéve. Tarts megfelelően védett, elkülönített másolatot és korlátozd a hozzáférést.

Az elkülönített tárolás célja, hogy egyetlen hiba ne érje egyszerre az éles rendszert és minden helyreállítási másolatot. A másik mappa ugyanazon fiókban nem feltétlenül jelent valódi elkülönítést. Vizsgáld a hozzáférési és törlési lehetőségeket is: ha ugyanaz a kompromittált fiók minden másolatot törölhet, a védelem korlátozott. A mentés titkosítása, jogosultsága és elérhetősége összehangolt döntést kíván. A titkosított fájl használhatatlan, ha a szükséges kulcs nem hozzáférhető helyreállításkor. A letöltött másolatot ne hagyd nyilvánosan elérhető webes könyvtárban. A tárolási tervben a rendszeres elkészítés, integritásellenőrzés és hozzáférési felelős is kapjon helyet, hogy a másolat ne csak létezzen, hanem használható maradjon. A tárhely kiesésekor is hozzáférhető a helyreállításhoz szükséges anyag.

Visszaállítási próba

A sikeres mentési üzenet nem bizonyítja az archívum használhatóságát. Időnként állíts vissza egy példányt nem nyilvános környezetben.

A visszaállítási próba során az archívumot külön, védett környezetben bontsd ki, majd indítsd el a szükséges alkalmazást. Ellenőrizd a bejelentkezést, fontos tartalmat, képeket és egy reprezentatív üzleti folyamatot. A próbarendszer ne küldjön valódi ügyféllevelet és ne indítson éles fizetést. A sikeres kibontás még nem ugyanaz, mint a működő rendszer: hiányozhat konfiguráció, szervermodul vagy külső kulcs. Jegyezd fel a helyreállítás tényleges lépéseit és az elakadásokat. A próba arra is választ adhat, mennyi szervezési és technikai idő kell egy leállás kezeléséhez. Az eredményt az üzleti igénnyel együtt értékeld, mert egy működő, de túl lassú helyreállítás nem minden helyzetben elégséges. Megnyílik az adminfelület, a tartalom és a fő felhasználói folyamat.

Rendelés és levél

Régi adatállapot visszahozása megismételt üzleti műveletet okozhat. Tervezd meg a külső rendszerek egyeztetését és a küldések letiltását a helyreállítás alatt.

Egy régi állapot visszaállítása nem tekeri vissza a külső világot. Közben megtörténhetett fizetés, csomagfeladás vagy számlakiállítás, amelyről a régi adatbázis még nem tud. A visszaállítás után ezeket egyeztetni kell, különben téves státusz vagy ismételt feldolgozás keletkezhet. A kimenő levelek és ütemezett feladatok ezért a helyreállítás alatt tudatos felügyeletet igényelnek. A friss rendelési adatot lehetőség szerint külön meg kell őrizni és megfelelő módon összevezetni. Ez nem feltétlenül egyszerű adatbázis-összemásolás, mert kapcsolódó rekordok és azonosítók is érintettek. Az eljárást a használt webshop- és integrációs szerkezethez kell készíteni. A mentésből visszatérés így kontrollált üzleti egyeztetés, nem pusztán fájlvisszamásolás. Nem indul indokolatlanul új fizetési vagy e-mail-művelet.

Felelős és hozzáférés

Incidensben a hiányzó jelszó vagy bizonytalan feladatkör késedelmet okoz. Legyen kijelölt felelős és biztonságosan elérhető helyreállítási leírás.

A helyreállítási leírás legyen elérhető akkor is, ha maga a weboldal nem működik. Tartalmazza a szolgáltató elérhetőségét, a hozzáférések biztonságos helyét, a mentések azonosítását és a fő ellenőrzési lépéseket. A titkos adatot ne másold fölöslegesen sok helyre; az eljárás és a hozzáférés kezelése különíthető el. Legyen helyettesítő felelős is, mert az incidens nem feltétlenül munkaidőben vagy az eredeti fejlesztő jelenlétében történik. A visszaállítás után a hiba okát is ki kell vizsgálni, különben ugyanaz újra bekövetkezhet. A régi állapot helyrehozása nem automatikusan oldja meg a sérülékenységet vagy hibás konfigurációt. A lezárás része ezért a tanulság és a mentési terv szükséges módosítása. A folyamat az eredeti fejlesztő távollétében is megindítható.

Szemléltető helyzet és gyakorlati munkalap

Szemléltető példa: egy webhely fájljairól naponta készül másolat, de az adatbázisról csak hetente. Egy hiba után a képek megvannak, a friss bejegyzések azonban hiányoznak. A mentési tervet ezért a tartalom változásának üteméhez igazítják, és a két részt összetartozó állapotként tesztelik.

Gyakori kérdések

A tárhely automatikus mentése önmagában elég a WordPress védelméhez?

A szolgáltatás pontos tartalmát, gyakoriságát, megőrzését és visszaállítási módját meg kell ismerni. Az automatikus másolat hasznos lehet, de tudni kell, milyen adatot tartalmaz és milyen kiesésnél hozzáférhető. Az elkülönített tárolás és kipróbált helyreállítás külön érték. A mentési tervet a vállalkozás elfogadható adatvesztési és helyreállítási igényéhez igazítsd. Ne feltételezd, hogy egy csomagnév minden fájlt, adatbázist és külső rendszerben kezelt adatot automatikusan lefed.

Miért kell a mentést időnként külön környezetben visszaállítani?

A próba mutatja meg, hogy az archívum használható, a szükséges konfiguráció elérhető és a rendszer valóban elindítható. A sikeres mentési értesítés nem bizonyítja a teljes helyreállítást. A tesztben nézd meg az adminfelületet, tartalmat és fő felhasználói folyamatot, éles küldések nélkül. A hiányzó lépéseket és hozzáférést rögzítsd. Így egy valódi incidensben nem először találkoztok a szerver, adatbázis vagy kulcskezelés gyakorlati követelményeivel.

Források és további olvasnivaló

A cikk tájékoztató jellegű szakmai útmutató. Az említett példák szemléltető helyzetek; a saját vállalkozásodnál a konkrét adatok és a működési feltételek alapján érdemes dönteni.

Van egy hasonló feladatod?

Beszéljük át, hogyan ültethető át a gyakorlatba.

Projektet indítok

Kapcsolódó szolgáltatás: Üzemeltetés és karbantartás ↗