Zálohování a obnova po havárii pro PHP weby: Praktický průvodce

Každý PHP web stojí na zásobníku pohyblivých částí: webový server, PHP runtime, databáze MySQL nebo PostgreSQL, konfigurační soubory, nahraná aktiva a často stovka malých cron úloh. Kterákoli z nich může selhat – poškozená tabulka, zbloudilý rm -rf, ransomware – a pokud máte jen jednu zálohu databáze z minulého týdne, máte problém. V DigiForge jsme obnovili více PHP webů, než bychom chtěli počítat, a rozdíl mezi čtyřhodinovou obnovou a čtyřdenní noční můrou vždy spočívá v jediném: správně navržené strategii zálohování a zotavení po havárii.

Proč samotné zálohování nestačí

Mnoho týmů zaměňuje zálohování s obnovou po havárii. Záloha je periodická kopie dat. Obnova po havárii je celý proces zprovoznění aplikace – obnovení dat, překonfigurování služeb, přesměrování provozu a ověření, že vše funguje. Jak uvádí jedna zpráva o odolnosti IT, „chránit svá data pouze zálohami již nestačí k přežití“ (zdroj). Záloha bez otestovaného plánu obnovy je jen pojištění, které jste si ještě nepřečetli.

V kontextu PHP je rozdíl markantní. Vaše databázová záloha může být zcela neporušená, ale pokud nevíte, jak nasměrovat Apache nebo Nginx na obnovenou databázi, změnit přihlašovací údaje v .env nebo znovu sestavit PHP opcache, jste stále offline. A výpadek, jak všichni víme, stojí peníze a důvěru. Komplexní plán obnovy po havárii (DR) musí pokrývat každou vrstvu serverového zásobníku, nejen data.

Zásobník zálohování a obnovy pro PHP weby

Zálohování PHP aplikace rozdělujeme do pěti odlišných vrstev. Vynechání kterékoli z nich může učinit ostatní nepoužitelnými:

1. Kód a správa verzí (Git repozitáře včetně tagů a větví).
2. Databázové dumpy (MySQL, PostgreSQL nebo MariaDB).
3. Konfigurace webového serveru (virtuální hosty Nginx/Apache, SSL certifikáty, PHP-FPM fondy).
4. Konfigurace aplikace (.env, konfigurační soubory, pevně zadané přihlašovací údaje).
5. Uživatelský obsah (obrázky, PDF, soubory uložené mimo databázi).

Pojďme si každou vrstvu projít s praktickými doporučeními.

1. Kód a správa verzí

Váš aplikační kód by měl být v Git repozitáři – bez výjimek. Ale Git push není záloha. Viděli jsme týmy, které spoléhaly na jedinou vzdálenou větev a přišly o týdny práce, když došlo k force pushi nebo poškození repozitáře. Používejte hostingového poskytovatele Gitu (GitHub, GitLab, Bitbucket) a nastavte automatická zrcadlení na druhé místo. Pro produkční nasazení označujte každé vydání tagem. Pak pokud potřebujete vrátit zpět na známý dobrý stav, nebudete hádat, který commit byl v provozu.

2. Zálohy databáze

Zálohy databáze jsou nejkritičtější a zároveň nejvíce opomíjené. Denní mysqldump do lokálního adresáře je lepší než nic, ale viděli jsme, že takové zálohy zaplní disk a tiše přestanou běžet. Automatizujte dumpy pomocí skriptu, který rotuje staré zálohy, komprimuje je a odesílá mimo pracoviště – na S3, Backblaze nebo na samostatný server. Pro tabulky InnoDB používejte mysqldump --single-transaction, abyste zabránili zamykání čtení, a pravidelně testujte obnovu. Záloha, kterou nelze obnovit, je k ničemu.

3. Konfigurace serveru a webového serveru

Vaše PHP stránka běží na více než jen kódu a datech. Konfigurační soubory Nginx nebo Apache, nastavení fondu PHP-FPM, SSL certifikáty a definice cron úloh jsou pro váš server jedinečné. Ukládáme je do samostatného Git repozitáře (nebo jako součást aplikačního repozitáře do adresáře deploy/) a zálohujeme je společně se zbytkem. Služby jako Certbot automaticky obnovují certifikáty Let's Encrypt, ale pokud váš server zemře, tyto certifikáty jsou pryč. Zálohujte /etc/letsencrypt/ nebo přejděte na DNS validaci, která přežije přestavbu.

4. Konfigurace prostředí a aplikace

PHP aplikace často obsahují soubor .env s přihlašovacími údaji k databázi, API klíči a tajemstvími. Tyto údaje nikdy nesmí být ve verzovacím systému. Pro produkci používáme správce tajemství (např. HashiCorp Vault nebo envkey), ale minimálně zašifrujte a uložte kopii .env do vašeho zálohovacího systému. Pokud tento soubor ztratíte, neobnovujete svůj web – přestavujete ho.

5. Uživatelské nahrávky a média

Obrázky, PDF a další nahrávky jsou často ukládány do adresáře public/uploads. Rychle rostou a mohou nafouknout zálohy databáze, pokud jsou ukládány jako BLOBy. Osvědčený postup: ukládejte nahrávky na samostatný svazek nebo do objektového úložiště (S3, DigitalOcean Spaces). Pokud jsou na souborovém systému serveru, zahrňte tento adresář do vaší offsite zálohy. Použijte rsync nebo rclone k denní synchronizaci do cloudového úložiště.

Automatizace a testování plánu obnovy

Zálohovací strategie je jen tak dobrá, jako její obnova. Už jsme byli u mnoha po-mortem analýz, kde klient řekl: „Máme zálohy,“ ale nikdy je nezkusil použít. Disaster recovery je proces, ne produkt. Musíte sepsat – a hlavně nacvičit – jak svůj PHP web obnovíte.

• Napište runbook. Zdokumentujte každý krok: kde jsou zálohy uloženy, jak obnovit databázi, které příkazy znovu sestaví webový server, jak aktualizovat DNS, pokud se změní vaše IP.
• Automatizujte obnovy. Použijte skripty nebo nástroje pro orchestraci (Ansible, Puppet, nebo i jednoduchý Bash skript) k zprovoznění nového serveru a obnovení aplikace ze záloh. Pokud nedokážete rozjet klon do hodiny, je váš DR plán příliš pomalý.
• Testujte čtvrtletně. Obnovte celý PHP stack na čerstvém serveru (nový VPS nebo lokální VM) a ověřte, že web funguje. Otestujte propagaci DNS, SSL, databázová připojení, cron úlohy a všechny uživatelské toky. Opravte vše, co se pokazí.

Podle našich zkušeností jsou nejčastějšími selháními při cvičném obnovení neshody v přihlašovacích údajích (natvrdo zadaná databázová hesla, která neodpovídají obnovenému .env), chybějící PHP rozšíření a nekompletní nahrávky. Každé selhání je dar – odhaluje mezeru, kterou můžete opravit dříve, než dojde ke skutečné katastrofě.

„Záloha bez otestovaného plánu obnovy je jen naděje.“ — inženýrská zásada DigiForge

Volba umístění a formátů záloh

Staré pravidlo 3-2-1 stále platí: tři kopie dat, na dvou různých médiích, jedna kopie mimo pracoviště. U PHP webů je běžné nastavení: (1) lokální zálohovací skript na živém serveru, (2) cloudový bucket mimo pracoviště a (3) archiv v chladném úložišti (např. Glacier) pro měsíční snímky. Zálohy šifrujte pomocí GPG nebo klientského šifrování před nahráním k jakékoli třetí straně.

Inkrementální zálohy šetří šířku pásma a úložiště, ale zvyšují složitost obnovy. U středně vytíženého PHP webu je rozumným kompromisem denní plný dump databáze a v případě potřeby hodinové binární logy. Zálohy souborového systému lze provádět inkrementálně pomocí rsync – jen se ujistěte, že vaše nástroje dokážou z inkrementálů sestavit konzistentní stav.

Když udeří katastrofa: Runbook pro obnovu

Pojďme simulovat nejhorší scénář: ransomware zašifruje váš PHP web root a databázi. Zde je rámcový postup obnovy, který používáme v DigiForge:

1. Izolujte napadený server – zablokujte veškerý externí přístup, v případě potřeby pořiďte snímek pro forenzní analýzu.
2. Zřiďte čistý server – čerstvý VPS se stejným OS a verzí PHP.
3. Obnovte kód z Gitu – naklonujte tag vydání, který běžel před útokem.
4. Obnovte konfiguraci – zkopírujte .env, konfigurace web serveru, SSL certifikáty (nebo je vystavte znovu).
5. Obnovte databázi – importujte nejnovější čistý dump, poté přehrajte binlogy až do okamžiku infekce (jsou-li k dispozici).
6. Obnovte nahrané soubory – rsync ze zálohovacího úložiště do adresáře uploadů na novém serveru.
7. Otestujte vše – spusťte health checky, ověřte databázová připojení, zkontrolujte, zda se spouštějí cron úlohy.
8. Přepněte DNS – nasměrujte doménu na IP nového serveru (předem snižte TTL).
9. Monitorujte – sledujte logy a dostupnost po dobu 24 hodin. Obnovu prohlaste až po trvale zeleném stavu.

Celý proces může trvat 2–4 hodiny, pokud jsou vaše zálohy dobře organizované a máte je nacvičené. Bez praxe se může protáhnout na dny.

Budování kultury obnovy

Obnova po havárii není jednorázový projekt – je to průběžná praxe. Pokaždé, když aktualizujete verzi PHP, přidáte nový cron job nebo změníte direktivu webového serveru, aktualizujte svůj runbook a znovu otestujte. Viděli jsme příliš mnoho týmů, které berou zálohy jen jako položku v seznamu. Skutečná strategie DR je vetkaná do vašeho deployment pipeline, monitoringu a svalové paměti týmu.

Pokud máte na starosti PHP web, začněte ještě dnes. Zkontrolujte pokrytí záloh pro všech pět vrstev, automatizujte, co se dá, a naplánujte první cvičení obnovy. A pokud byste chtěli nechat svou strategii zkontrolovat odborníkem, ozvěte se DigiForge. Postavili jsme a obnovili dost PHP webů, abychom věděli, co funguje – a co ne.