Zálohy webu a VPS: co zálohovat a jak ověřit obnovu
Záloha má cenu teprve tehdy, když z ní obnovíte funkční službu. Vysvětlujeme snapshoty, oddělené kopie, četnost záloh, RPO, RTO a praktický test obnovy.
Záloha není hotová ve chvíli, kdy administrační rozhraní ukáže zelené „úspěšně dokončeno“. Smysl má až tehdy, když z ní dokážete v potřebném čase obnovit web, databázi a důležité nastavení. U WordPressu i VPS se proto vyplatí plánovat zálohování od výsledku: co musí po havárii znovu fungovat a kolik dat smíte ztratit?
Začněte dvěma otázkami: jak stará data a jak dlouhý výpadek?
První otázka určuje, jak často potřebujete zálohovat. Jestliže web přijímá objednávky během celého dne, kopie databáze z předchozí noci může znamenat ztrátu mnoha nových záznamů. Druhá otázka určuje, jak rychle musíte být schopni web obnovit. Jinou strategii snese osobní blog a jinou objednávkový systém, na kterém závisí každodenní provoz firmy.
V oblasti obnovy se používají zkratky RPO a RTO. RPO vyjadřuje maximálně přijatelný věk obnovených dat; RTO přijatelnou dobu obnovy služby. Pro malý web si nemusíte pořizovat složitý nástroj, ale měli byste si alespoň napsat odpověď vlastními slovy: „Přijmeme ztrátu nejvýše jednoho dne práce a web chceme obnovit do čtyř hodin.“ Podle toho pak zvolíte četnost kopírování i způsob obnovy.
Co musí obsahovat záloha WordPressu
Oficiální dokumentace WordPressu rozlišuje soubory a databázi. Soubory zahrnují motivy, pluginy, nahraná média a konfiguraci; databáze obsahuje obsah a většinu nastavení. Záloha jen jedné části obvykle nevrátí celý web do provozu. Při tvorbě kopie si proto zaznamenejte, které soubory a jaký export databáze tvoří jeden obnovitelný celek.
Pokud používáte e-shop, rezervační systém nebo plugin ukládající data do vlastních tabulek, proveďte test včetně těchto funkcí. U větších webů může export trvat déle a kopie souborů s databází nemusí zachycovat stejný okamžik. Zvolte postup, který počítá s konzistencí dat, případně po dobu závěrečné zálohy dočasně zastavte nové zápisy.
Co zálohovat na VPS
VPS je širší prostředí než samotný web. Vedle aplikace a databáze potřebujete umět obnovit konfiguraci webového serveru, plánované úlohy, přístupové údaje, případně certifikáty a nastavení firewallu. Citlivé údaje ukládejte bezpečně a odděleně; běžně přístupný archiv se všemi hesly by mohl vytvořit další problém. Sestavte stručný seznam služeb a pořadí, v jakém je při obnově spustíte.
Snapshot celého virtuálního stroje může výrazně zrychlit návrat po nepovedené aktualizaci. Sám o sobě však nemusí pokrýt všechny scénáře: záleží na místě uložení, době uchování, oddělení od primární infrastruktury a na tom, zda ho umíte obnovit i při větším výpadku poskytovatele. Ptejte se také, zda snapshot zahrnuje konzistentní stav databáze. Rozumná strategie často kombinuje rychlou obnovu serveru s oddělenou kopií důležitých dat.
Například Coolhousing u VPS uvádí jeden manuální snapshot zdarma a placené varianty automatických snapshotů. Provozovatel webu si musí ověřit, co přesně vybraný režim uchovává a zda jeho frekvence odpovídá požadovanému RPO. Nabídka záloh je součástí rozhodování o tarifu, ne jen doplněk, který se řeší po výpadku.
Více kopií a oddělené místo
Pravidlo 3-2-1 je užitečná pomůcka: tři kopie důležitých dat, dvě různá média nebo prostředí a jedna kopie mimo hlavní lokalitu. Není to samoúčelná matematika. Jeho smyslem je snížit riziko, že jedna chyba, účet nebo fyzické místo vyřadí originál i všechny zálohy současně. U webu to může znamenat běžnou pracovní kopii, zálohu u hostingu a další kopii pod samostatným účtem u jiné služby.
Oddělení přístupů je stejně důležité jako oddělení místa. Pokud má napadený server možnost zálohy volně smazat nebo přepsat, může útočník poškodit i cestu k obnově. Zvažte omezení oprávnění, verzování nebo ochranu proti smazání podle možností zvoleného úložiště. U citlivých dat řešte také šifrování a bezpečné uložení klíčů.
Jak zvolit četnost a délku uchování
Neexistuje jedna frekvence správná pro všechny weby. Obsahový web s jedním článkem týdně snese jiný rozvrh než obchod s desítkami objednávek denně. Důležitá je i retence: pokud chybu objevíte až po několika dnech, jediná poslední záloha může obsahovat stejný problém. Udržujte více obnovovacích bodů a čas od času starší kopii vyzkoušejte.
Rozvrh si napište jako provozní pravidlo. Například: databáze několikrát denně podle objemu změn, soubory denně a před větším nasazením, dlouhodobější kopie týdně. To je pouze ilustrace, nikoli univerzální doporučení. Správné hodnoty vyplývají z vašeho RPO, velikosti dat, ceny úložiště a času potřebného na obnovu.
Test obnovy: jediný spolehlivý důkaz
Vyberte jednu ze záloh a obnovte ji do odděleného testovacího prostředí. Změřte, jak dlouho trvalo získat soubory, importovat databázi, upravit konfiguraci a otevřít funkční web. Nestačí kontrola, že se soubor archivu otevře: ověřte přihlášení, formuláře, nahrané obrázky a nejdůležitější obchodní operaci. U VPS navíc prověřte start služeb a naplánované úlohy.
AWS ve své dokumentaci popisuje automatizované testování obnovy právě proto, že samotná existence záložního bodu neříká, zda z něj službu skutečně uvedete do provozu. Menší projekt zvládne podobný princip ručně. Po testu si zapište datum, použitou kopii, dobu obnovy a chyby. Při příští havárii z toho bude konkrétní postup místo odhadů.
Praktický plán na jednu stránku
- Seznamte soubory, databáze a konfiguraci potřebnou k obnově.
- Stanovte přijatelnou ztrátu dat a dobu výpadku.
- Vyberte frekvenci a dobu uchování kopí podle těchto cílů.
- Držte alespoň jednu použitelnou kopii mimo hlavní hosting a oddělte přístupy.
- Nastavte upozornění na neúspěšné zálohy.
- Pravidelně obnovte kopii v testu a zaznamenejte výsledek.
- Uchovejte jednoduchý návod, kdo a jak obnovu spustí.
Pokud právě plánujete přesun webu, využijte zálohu i jako bezpečnostní bod před migrací. Při výběru nové služby ověřujte konkrétní podmínky zálohování v porovnání hostingů a přímo u poskytovatele.
Tři různé nehody vyžadují různou obnovu
Chybná aktualizace pluginu. Web přestane fungovat, ale infrastruktura a databáze jsou jinak dostupné. Může stačit rychlý návrat k předchozí verzi nebo obnova vybraných souborů. Plošné vrácení celé databáze by však mohlo smazat objednávky či zprávy, které vznikly po poslední záloze. Než spustíte obnovu, určete, jaká data se mezitím změnila.
Smazaná či poškozená databáze. Potřebujete export databáze odpovídající stavu aplikace a spolehlivý import. Samotný archiv souborů WordPressu nepomůže. U větší databáze si předem změřte, jak dlouho import trvá a zda ho vaše administrační rozhraní zvládne; při výpadku by se omezení velikosti souboru nemělo stát překvapením.
Nedostupný celý VPS nebo účet poskytovatele. Obnova na stejném serveru není možná. Zde se ukáže význam kopie mimo primární hosting, uložených přístupových údajů a zapsaného postupu sestavení služby. Dokonce i úplná kopie dat je málo platná, pokud nevíte, jak znovu nastavit DNS, certifikát a konfiguraci aplikace. Tento scénář si alespoň jednou nanečisto projděte.
Jak poznat, že zálohovací systém selhává
Všímejte si nejen explicitní chyby, ale také neobvyklé změny velikosti kopie, zastaveného plánovače, zaplněného úložiště a příliš starého posledního bodu obnovy. Zálohování, které běží bez dozoru, může selhávat dlouho předtím, než ho někdo potřebuje. Nastavte upozornění na chybějící nebo neúspěšnou úlohu a pravidelně kontrolujte skutečně dostupné soubory.
Při testu obnovy vždy použijte oddělené prostředí. Neobnovujte zkušební data přes běžící produkční web. Pro ověření stačí kopie s omezeným přístupem, na níž otevřete hlavní stránky a provedete test důležité funkce. Po skončení testu bezpečně smažte dočasné kopie citlivých dat a zaznamenejte, zda výsledná obnova splnila vaše RPO a RTO.
