Zálohy VPS: co si ověřit, než podepíšete

Otázky, které položit

Frekvence a uchovávání: o co můžete přijít

Zálohovací politiku shrnují dvě doby:

• Maximální přípustná ztráta dat (RPO, recovery point objective): množství práce, o které jste ochotni přijít. Záloha každou noc znamená nanejvýš 24 hodin; databáze, která celý den zaznamenává objednávky, získá, když k ní přidáte průběžnou archivaci transakčního logu.
• Maximální doba přerušení (RTO, recovery time objective): doba, po kterou může služba stát. Závisí na objemu k obnovení a hlavně na tom, kdo obnovu provádí a kdy.

Doba uchovávání odpovídá na jinou otázku: jak daleko zpět se můžete vrátit? Smazání, kterého si všimnete druhý den, napravíte zálohou z předchozí noci. Nenápadný průnik, tiché poškození dat nebo chyba v automatickém zpracování se někdy odhalí později: pak potřebujete bod obnovy z doby před problémem. Pro dlouhodobé archivy, účetní nebo regulatorní, doplňuje zálohu serveru měsíční export uložený zvlášť.

Kde zálohy jsou a kdo je může smazat

Záloha chrání před tím, co se stane serveru. Musí proto žít jinde než on:

• Zrcadlení disků (RAID) chrání před poruchou disku a na druhý disk věrně zkopíruje i smazání nebo škodlivé zašifrování provedené na prvním. Je to ochrana hardwaru, ne záloha.
• Snapshot na stejném úložišti rychle vrátí server zpět po nepovedené aktualizaci, ale zmizí spolu s úložištěm, na kterém leží.
• Záloha mimo stroj, na odděleném úložišti, přežije ztrátu serveru. Když je zašifrovaná ještě před odesláním, zůstává nečitelná pro každého, kdo nemá klíč.

Často opomíjený bod: zálohu, kterou lze smazat ze serveru, může smazat i útočník, který server ovládl. Zálohy pořizované a uchovávané poskytovatelem, mimo dosah zálohovaného serveru, tomuto riziku unikají.

Zvláštní případ databází

Databáze neustále zapisuje. Kopie jejích souborů pořízená za běhu ji zachytí ve stavu, v jakém by byla po výpadku proudu: PostgreSQL i MySQL se z takového stavu umějí zotavit přehráním svého logu. Pro jemnou obnovu, tabulku po tabulce, nebo do jiné verze se k tomu přidává logická záloha:

pg_dump -Fc -d moje_db -f /zalohy/moje_db-$(date +%F).dump
mysqldump --single-transaction --routines moje_db | gzip > /zalohy/moje_db-$(date +%F).sql.gz

Když tyto exporty každou noc spustí naplánovaná úloha ještě před zálohou serveru, jsou do ní zahrnuté a lze je také zkopírovat na vaše vlastní úložiště.

Pravidlo 3-2-1

Pravidlo, které doporučují agentury pro kybernetickou bezpečnost, se vejde do tří číslic: 3 kopie vašich dat, na 2 různých médiích, z toho 1 mimo pracoviště. Na VPS to vypadá takto: data v provozu na serveru, záloha pořízená poskytovatelem mimo stroj a pravidelný export toho nejdůležitějšího (databáze, soubory nahrané vašimi uživateli) na vaše vlastní úložiště.

restic -r sftp:uzivatel@uloziste.example.com:/zalohy init
restic -r sftp:uzivatel@uloziste.example.com:/zalohy backup /zalohy

Otestovat obnovu

Záloha se prokazuje obnovou. Jednou za čtvrtletí a po každé důležité změně serveru:

1. Vyžádejte si nebo spusťte obnovu na testovací server, vedle produkce.
2. Ověřte, že se aplikace spustí a odpovídá.
3. Porovnejte několik čísel s produkcí: počet řádků hlavních tabulek, datum posledního záznamu.
4. Zapište si, jak dlouho operace trvala: to je vaše skutečná doba přerušení.

U Managed VPS má tyto zálohy, jejich uchovávání mimo stroj i samotnou obnovu na starosti poskytovatel: vy požádáte, on obnoví.

Pokud server uchovává osobní údaje, obecné nařízení o ochraně osobních údajů (GDPR, článek 32) uvádí mezi vhodnými opatřeními schopnost obnovit dostupnost osobních údajů a přístup k nim včas v případě fyzických či technických incidentů a proces pravidelného testování, posuzování a hodnocení účinnosti zavedených opatření. Datovaný test obnovy je nejjednodušším důkazem.