Plán záloh pro Váš server

Modul 8: Zálohy a monitoring · Doba čtení: 11 min.

Cíl lekce: Po této lekci dokážete pro svůj server sestavit plán záloh: co uchováváte, kde, jak často a jak dlouho, a jak si ověříte, že obnova opravdu funguje.

Klíčové pojmy: pravidlo 3-2-1, snapshot, záloha od poskytovatele, vlastní záloha mimo poskytovatele, RPO, RTO, dump databáze (mariadb-dump, pg_dump), konfigurace v /etc, Docker volumes, šifrování, ransomware, append-only, test obnovy

Proč plán, a ne jen "záloha přece existuje"?

Skoro každý, kdo přišel o server, si myslel, že má zálohu. Pak se ukáže, že obsahuje jen operační systém, a ne databázi, nebo leží na stejném serveru, který je teď pryč, nebo ji zašifroval tentýž ransomware, nebo nikdo nezná heslo. Záloha má hodnotu teprve tehdy, když ji dokážete obnovit. Proto začínáte plánem a končíte testem.

Plán odpovídá na pět otázek:

1. Co musí jít obnovit?
2. Kolik dat smíte ztratit? (RPO)
3. Jak rychle musí vše znovu fungovat? (RTO)
4. Kde jsou kopie uloženy a kolik jich je?
5. Jak víte, že to funguje?

Co musí jít obnovit?

Server se skládá z vrstev. Ne každá vrstva musí být v záloze:

Zvláštní pozornost věnujte databázím. Běžící databáze neustále zapisuje. Pokud zkopírujete soubory běžící MariaDB nebo PostgreSQL, můžete získat poškozenou kopii. Proto nejprve vytvořte dump: konzistentní snímek v podobě souboru, který pak zahrnete do zálohy.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump se dříve jmenoval mysqldump; tento příkaz většinou funguje i nadále.) Pokud databáze běží v kontejneru, postupujete stejně pomocí docker compose exec (lekce 9.4).

RPO a RTO: kolik smíte ztratit?

Při rozhodování pomohou dva pojmy z praxe:

• RPO (recovery point objective): data za jak dlouhou dobu smíte nanejvýš ztratit? Denní záloha ve 03:00 znamená: pokud server spadne ve 22:00, přijdete téměř o celý den. Pro e-shop s objednávkami je to příliš; pro blog, který se mění jednou týdně, je to v pořádku.
• RTO (recovery time objective): jak dlouho smí trvat, než vše znovu funguje? Obnova kompletní zálohy od poskytovatele může zabrat minuty; sestavení nového serveru a ruční obnova všeho může trvat hodiny.

Zapište si obě hodnoty pro svůj server. Určují, jak často zálohujete a jak zálohy uchováváte.

Snapshot, záloha od poskytovatele, vlastní záloha

Na VPS máte obvykle tři druhy záchranné sítě. Vypadají podobně, ale chrání před různými věcmi.

1. Snapshot. Snímek celého virtuálního disku, vytvořený v panelu Vašeho poskytovatele. Rychle se vytvoří a rychle obnoví. Ideální těsně před upgradem (lekce 4.3). Ale: snapshot je u většiny poskytovatelů uložen na stejném úložišti jako Váš server. Pokud se toto úložiště poškodí nebo přijdete o účet, je pryč i snapshot. A snapshot si neuchováváte dlouho: roste se všemi pozdějšími změnami. Snapshot není záloha.

2. Záloha od poskytovatele. Mnoho poskytovatelů (případně jako volitelnou službu) automaticky každý den vytváří kopii celého Vašeho serveru na jiném úložišti. U WebOké je to například denní záloha celého VPS, která se uchovává sedm dní; u jiných poskytovatelů to funguje podobně, s vlastními lhůtami. To je dobrá druhá vrstva proti vadnému hardwaru a proti Vašim vlastním včerejším chybám. Stále je to ale jediná strana: Váš účet, Vaše platba, jejich výpadek. A obnova obvykle probíhá pro celý server najednou.

3. Vaše vlastní záloha mimo poskytovatele. Kopie Vašich dat u jiné strany nebo na jiném místě, kterou vytváříte a spravujete sami (lekce 8.2). To je vrstva, která zůstane, když selže všechno ostatní.

Pravidlo 3-2-1

Běžné pravidlo:

• 3 kopie Vašich dat (originál a dvě zálohy);
• na 2 různých typech úložiště nebo systémech;
• z toho 1 na jiném místě.

U VPS to může vypadat takto: data na serveru, denní záloha od poskytovatele a šifrovaná vlastní záloha pomocí restic na úložiště u jiné strany. Moderním doplněním je, že alespoň jednu kopii nemůže smazat ten, kdo server ovládne (offline nebo append-only, lekce 8.2). Ransomware na serveru aktivně hledá zálohy, aby je také zašifroval nebo smazal. Záloha, kterou smí smazat samotný server, proti tomu neposkytuje žádnou ochranu.

Šifrování a heslo k záloze

Záloha u jiné strany musí být šifrovaná: obsahuje údaje zákazníků, hesla a klíče. restic (lekce 8.2) šifruje automaticky. Tím ale vzniká nové riziko: heslo k Vaší záloze. Pokud ho ztratíte, je záloha nepoužitelná. A totéž platí, pokud je uložené jen na serveru, o který jste přišli.

Heslo proto uchovávejte i mimo server: ve správci hesel a případně na papíře v trezoru. Totéž platí pro přístupové údaje k úložišti, kde je Vaše záloha.

Testování obnovy

Nejdůležitější část plánu. Test obnovy znamená: zálohu skutečně obnovíte na místo, kde nic nepoškodí, a zkontrolujete, zda výsledek funguje.

• Malý a častý: obnovit jeden soubor nebo jednu složku do /tmp/terug a porovnat (diff). Například jednou měsíčně.
• Velký a občasný: sestavit ze zálohy kompletně nový testovací server, importovat databázi, spustit web. Například jednou ročně nebo při každé velké změně. Je to zároveň nácvik pro případ, kdy se opravdu něco pokazí (lekce 10.3).

Zapište si, jak dlouho to trvalo: to je Vaše skutečné RTO.

Doby uchovávání

Neuchovávejte jen poslední zálohu. Pokud zjistíte až po dvou týdnech, že je soubor poškozený nebo smazaný, potřebujete zálohu starou tři týdny. Běžné schéma: sedm denních, čtyři týdenní a šest měsíčních verzí. restic to zajistí pomocí forget (lekce 8.2). Myslete také na GDPR: osobní údaje neuchovávejte déle, než je nutné, ani v zálohách. Doby uchovávání si písemně stanovte.

V praxi

Snapshot od poskytovatele použijte těsně před riskantními změnami a poté ho smažte; denní zálohu od poskytovatele nechte zapnutou, pokud je k dispozici; a k tomu vytvářejte vlastní šifrovanou zálohu dat a konfigurace u jiné strany. U WebOké se to na obrazovce VPS jmenuje Snapshots a Backups; u jiných poskytovatelů se názvy a lhůty liší, ale princip je stejný. Webhosting nebo spravovaná služba mají často jiná pravidla: zjistěte, co je zajištěno ve Vašem případě.

Shrnutí

• Záloha má hodnotu teprve tehdy, když obnova funguje; začněte plánem a skončete testem.
• Zálohujte hlavně data a konfiguraci: databáze jako dump, /etc, weby, Docker volumes, soubory compose.
• Určete RPO (kolik smíte ztratit) a RTO (jak rychle to musí fungovat).
• Snapshot (stejné úložiště, krátkodobě), záloha od poskytovatele (jiné úložiště, stejná strana) a vlastní záloha mimo poskytovatele jsou tři různé vrstvy; dodržujte pravidlo 3-2-1 s alespoň jednou kopií, kterou samotný server nemůže smazat.
• Šifrujte, uchovávejte heslo k záloze mimo server a testujte obnovu: v malém často, ve velkém občas.

Kvíz

Úkol

Úkol O8.1: Váš plán záloh. Sestavte pro svůj server plán záloh na jedné stránce: co musí jít obnovit (podle vrstev), Vaše RPO a RTO, jaké kopie máte (snapshot, poskytovatel, vlastní) a kde, Vaše doby uchovávání, kde je uložené heslo k záloze a kdy provádíte test obnovy. Vyplňte formulář; po odeslání uvidíte vzorový plán, se kterým můžete svůj plán porovnat.

Doporučujeme k přečtení

• Snapshoty a zálohy VPS
• Záložní strategie: pravidlo 3-2-1 pro Vaši vlastní firmu
• Jak vytvořím zálohu své databáze MySQL?
• V kurzu Bezpečně online: lekce o pravidle 3-2-1 a o zálohách, které přežijí ransomware.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html