Pro DevOps inženýry a systémové administrátory jsou snímky (snapshoty) virtuálních strojů (VM) základním nástrojem. Poskytují rychlý a pohodlný způsob, jak zachytit stav serveru před rizikovou opravou, zásadní změnou konfigurace nebo nasazením aplikace. Pokud se něco pokazí, návrat do předchozího stavu trvá sekundy.
Pokud však tuto metodiku aplikujete na transakční databáze – jako jsou PostgreSQL, MySQL, Oracle nebo Microsoft SQL Server – snímky VM se změní z bezpečnostní pojistky na tikající časovanou bombu.
Spoléhání se na standardní snímky hypervizoru při zálohování databází je jednou z nejčastějších příčin poškození dat, nekonzistentních stránek (torn pages) a neobnovitelných výpadků produkce. V tomto článku prozkoumáme architektonický střet mezi hypervizory a databázovými stroji, mechanismy poškození dat během vytváření snímků a inženýrské osvědčené postupy potřebné k bezpečnému zálohování virtualizovaných databází.
Architektonický střet: Hypervizory vs. databázové stroje
Abychom pochopili, proč snímky VM ohrožují databáze, musíme nejprve prozkoumat, jak oba systémy spravují stav a operace I/O.
Jak hypervizory provádějí snímky
Když hypervizor (například VMware ESXi, Microsoft Hyper-V nebo KVM) vytvoří snímek, nekopíruje disk. Místo toho zmrazí aktuální soubor virtuálního disku (např. .vmdk nebo .vhdx) do stavu jen pro čtení a vytvoří nový delta disk (rozdílový disk). Veškeré následné zápisy jsou směrovány na tento delta disk.
Při odstranění snímku musí hypervizor potvrdit (konsolidovat) data z delta disku zpět do základního disku. Standardní snímky si vůbec neuvědomují aplikace běžící uvnitř hostovaného operačního systému. Zachycují stav disku přesně tak, jak existuje v dané mikrosekundě.
Jak transakční databáze spravují stav
Transakční databáze jsou navrženy s ohledem na vlastnosti ACID (Atomicity, Consistency, Isolation, Durability – atomičnost, konzistence, izolace, odolnost). Aby dosáhly vysokého výkonu při zachování souladu s ACID, databáze nezapisují každou transakci přímo do primárních datových souborů na disku okamžitě. Místo toho používají komplexní, víceúrovňovou architekturu:
- Buffer Pool / Shared Buffers: Data jsou čtena a upravována v systémové paměti.
- Write-Ahead Log (WAL) / Redo Logs: Změny jsou sekvenčně zapisovány do vysoce optimalizovaného souboru protokolu na disku, aby byla zajištěna odolnost.
- Checkpoints / Lazy Writers: Databáze pravidelně vyprazdňuje upravené (špinavé) stránky z paměti do skutečných datových souborů na disku.
Kvůli této architektuře jsou fyzické datové soubory na disku téměř vždy nesynchronizované se skutečným stavem databáze. Skutečný stav databáze existuje pouze jako kombinace datových souborů na disku, WAL/Redo logů a dat aktuálně uložených v paměti.
Zóna nebezpečí: Co se děje během snímku VM
Když pořídíte standardní snímek VM databázového serveru, zachycujete stav konzistentní při havárii (crash-consistent).
Konzistence při havárii vs. aplikační konzistence
Snímek konzistentní při havárii je ekvivalentem vytažení napájecího kabelu z fyzického serveru. Stav disku je zachycen, ale cokoli bylo v paměti, je ztraceno a cokoli bylo na cestě k řadiči úložiště, je náhle přerušeno.
Ačkoli jsou moderní databáze navrženy tak, aby se zotavily z neočekávané ztráty napájení přehráním Write-Ahead Logu, spoléhat se na obnovu po havárii jako na primární strategii zálohování je velmi nebezpečné. Pokud vaše databáze zahrnuje více virtuálních disků (např. datové soubory na disku D: a WAL na disku E:), hypervizor nemusí vytvořit snímek obou disků ve stejné mikrosekundě. Pokud je snímek disku WAL zachycen byť jen zlomek sekundy po snímku datového disku, databáze při obnově nedokáže sladit sekvenční čísla, což vede k fatálnímu poškození.
Efekt „VM Stun“ u systémů s vysokým počtem transakcí
Proces vytváření snímku – a co je důležitější, proces konsolidace snímku – způsobuje jev známý jako „VM Stun“ (zmrazení VM).
Aby bylo možné bezpečně přepnout I/O ze základního disku na delta disk, musí hypervizor virtuální stroj krátce pozastavit (zmrazit). U lehce vytíženého webového serveru může toto zmrazení trvat 10–50 milisekund a zůstat nepovšimnuto. U databáze s vysokou propustností a masivním I/O však konsolidace velkého delta disku může zmrazit VM na několik sekund.
Během zmrazení VM:
* Síťová spojení vypadávají, což způsobuje časové limity (timeouty) aplikací.
* Clustery s vysokou dostupností (jako SQL Server Always On, PostgreSQL Patroni nebo MySQL Galera) vynechávají kontroly dostupnosti (heartbeat).
* Cluster může předpokládat, že zmrazený uzel je mrtvý, což spustí zbytečné a rušivé převzetí služeb při selhání (scénář split-brain).
Nekonzistentní stránky (Torn Pages) a nesoulad I/O
Databázové stroje obvykle zapisují data ve specifických velikostech stránek (např. 8 KB pro PostgreSQL a SQL Server, 16 KB pro InnoDB). Základní operační systém a úložná pole však zpracovávají I/O v menších blocích (např. 4 KB nebo 512 bajtů).
Pokud hypervizor vytvoří snímek přesně ve chvíli, kdy databáze zapisuje 8KB stránku, snímek může zachytit prvních 4 KB nových dat a posledních 4 KB starých dat. To vytvoří nekonzistentní stránku (torn page). Když se pokusíte obnovit snímek, databáze stránku přečte, neprojde kontrolou integrity (checksum) a označí databázi jako poškozenou.
Důsledky v reálném světě pro konkrétní databázové stroje
Různé databázové stroje reagují na snímky konzistentní při havárii různými způsoby, ale žádný z nich to v produkčním prostředí nezvládá elegantně.
- PostgreSQL: PostgreSQL silně spoléhá na adresář
pg_wal. Pokud snímek zachytí datový adresář ($PGDATA) a WAL nesynchronizovaně, PostgreSQL se nespustí a vyhodí chybuPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB používá vyrovnávací paměť doublewrite, aby zabránil vzniku nekonzistentních stránek, což nabízí určitou ochranu proti stavům konzistentním při havárii. Pokud jsou však soubor
ibdata1aib_logfilezachyceny nesynchronizovaně, stroj InnoDB při obnově havaruje. - Microsoft SQL Server: SQL Server je vysoce citlivý na zmrazení I/O. Bez řádné integrace VSS (Volume Shadow Copy Service) povede obnova SQL Serveru ze standardního snímku VM často k podezřelým databázím a přerušeným řetězcům protokolů, což zničí vaše možnosti obnovy k určitému bodu v čase (PITR).
Osvědčené postupy pro bezpečné zálohování virtualizovaných databází
Abyste ochránili transakční databáze, musíte přejít od záloh konzistentních při havárii k aplikačně konzistentním zálohám. To vyžaduje, aby mechanismus zálohování komunikoval s databázovým strojem, přinutil jej vyprázdnit paměť na disk a dočasně pozastavit operace I/O, zatímco je snímek pořizován.
1. Využijte aplikačně uvědomělé zmrazení (VSS a fsfreeze)
Pro Windows (SQL Server):
Vždy zajistěte, aby vaše řešení zálohování využívalo službu Microsoft Volume Shadow Copy Service (VSS). Když je spuštěna záloha podporující VSS, zapisovač SQL Server VSS zmrazí I/O databáze, vyprázdní čekající transakce na disk a zajistí, že snímek je dokonale aplikačně konzistentní.
Pro Linux (PostgreSQL / MySQL):
Linux nemá nativní ekvivalent VSS. K dosažení aplikační konzistence musíte použít skripty „pre-freeze“ a „post-thaw“ ve spojení s nástroji pro hosta hypervizoru (např. VMware Tools).
Zde je příklad skriptu VMware pre-freeze-script pro PostgreSQL 15+, který bezpečně připraví databázi na snímek:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Ujistěte se, že je tento skript spustitelný (chmod +x)
# 1. Řekněte PostgreSQL, aby se připravil na zálohu
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Vyprázdněte vyrovnávací paměti souborového systému na disk
sync
# 3. Zmrazte souborový systém (za předpokladu, že data jsou v /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
A odpovídající post-thaw-script pro obnovení operací:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Rozmrazte souborový systém
fsfreeze -u /var/lib/pgsql
# 2. Řekněte PostgreSQL, že záloha je dokončena
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Používejte nativní nástroje pro zálohování databází
I když jsou aplikačně konzistentní snímky lepší než standardní snímky, stále nesou riziko zmrazení VM. Nejbezpečnějším přístupem pro zálohování databází je použití nativních streamovacích zálohovacích nástrojů, které fungují nezávisle na hypervizoru.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Tyto nástroje provádějí „horké“, neblokující zálohy kopírováním datových souborů a současným sledováním změn v redo logu.
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Implementujte obnovu k určitému bodu v čase (PITR) prostřednictvím archivace protokolů
Denní snímek nebo úplná záloha vás chrání pouze do minuty, kdy byla pořízena. Pokud vaše databáze havaruje v 16:00 a váš poslední snímek byl ve 2:00 ráno, ztratíte 14 hodin transakčních dat.
Abyste dosáhli skutečné odolnosti na podnikové úrovni, musíte kombinovat úplné aplikačně konzistentní zálohy s průběžnou archivací protokolů (zálohování WAL, Redo logů nebo transakčních protokolů každých pár minut). To umožňuje správcům databází obnovit databázi k určité minutě nebo dokonce k určitému ID transakce před havárií.
Podnikové strategie zálohování s CloudSave
Správa vlastních skriptů „pre-freeze“, úloh cron pro nativní výpisy a odesílání protokolů napříč desítkami databázových serverů je pro týmy DevOps provozní noční můrou. Zde se stává kriticky důležitou platforma podnikové třídy, jako je CloudSave.
CloudSave překlenuje propast mezi virtualizací a architekturou databází. Místo spoléhání se na slepé snímky hypervizoru využívá CloudSave agenty s aplikačním povědomím, kteří se nativně integrují se SQL Serverem, PostgreSQL, MySQL a Oracle.
Když CloudSave zahájí zálohování:
1. Komunikuje přímo s databázovým strojem prostřednictvím nativních API (jako VSS pro Windows nebo nativní streamování WAL pro Linux).
2. Orchestruje vyprázdnění paměťových vyrovnávacích pamětí na disk, aniž by způsoboval rušivé zmrazení VM.
3. Bezpečně zachycuje datové soubory a automaticky spravuje zkracování transakčních protokolů.
4. Průběžně zálohuje transakční protokoly, což umožňuje granulární obnovu k určitému bodu v čase (PITR) pomocí několika kliknutí.
Tím, že správci databází a systémoví administrátoři přenesou složitost aplikační konzistence na CloudSave, mohou zaručit integritu dat, aniž by obětovali výkon nebo dostupnost svých produkčních clusterů.
Závěr
Snímky virtuálních strojů jsou neuvěřitelným nástrojem pro správu infrastruktury, ale jsou zásadně nekompatibilní s požadavky ACID transakčních databází. Spoléhání se na snímky hypervizoru konzistentní při havárii vystavuje vaši organizaci riziku nekonzistentních stránek, přerušených řetězců replikace a katastrofální ztráty dat.
Abyste ochránili svá kritická data, musíte implementovat aplikačně uvědomělé zmrazení, využívat nativní metodiky zálohování databází a udržovat průběžné archivy transakčních protokolů. Přijetím účelových podnikových řešení zálohování můžete zajistit, že vaše databáze zůstanou vysoce dostupné, plně obnovitelné a zcela zabezpečené.
