Za DevOps inženjere i sistem administratore, snimke virtualnih strojeva (VM snapshots) predstavljaju temeljni alat. Oni pružaju brz i praktičan način za bilježenje stanja poslužitelja prije rizičnog ažuriranja, velike promjene konfiguracije ili implementacije aplikacije. Ako nešto pođe po zlu, povratak na prethodno stanje traje svega nekoliko sekundi.
Međutim, kada se ista metodologija primijeni na transakcijske baze podataka—kao što su PostgreSQL, MySQL, Oracle ili Microsoft SQL Server—VM snimke se iz sigurnosne mreže pretvaraju u tempiranu bombu.
Oslanjanje na standardne snimke hipervizora za sigurnosne kopije baza podataka jedan je od najčešćih uzroka oštećenja podataka, “rastrganih” stranica (torn pages) i nepopravljivih prekida u radu produkcijskih sustava. U ovom ćemo članku istražiti arhitektonski sukob između hipervizora i pogona baza podataka, mehaniku oštećenja podataka tijekom snimanja te inženjerske najbolje prakse potrebne za sigurno sigurnosno kopiranje virtualiziranih baza podataka.
Arhitektonski sukob: Hipervizori protiv pogona baza podataka
Da bismo razumjeli zašto VM snimke ugrožavaju baze podataka, prvo moramo ispitati kako oba sustava upravljaju stanjem i I/O operacijama.
Kako hipervizori izvršavaju snimke
Kada hipervizor (kao što je VMware ESXi, Microsoft Hyper-V ili KVM) napravi snimku, on ne kopira disk. Umjesto toga, zamrzava trenutnu datoteku virtualnog diska (npr. .vmdk ili .vhdx) u stanje samo za čitanje i stvara novi delta disk (disk za razlike). Svi naknadni zapisi usmjeravaju se na taj delta disk.
Kada se snimka izbriše, hipervizor mora potvrditi (konsolidirati) podatke s delta diska natrag u osnovni disk. Standardne snimke nisu svjesne aplikacija koje se izvode unutar gostujućeg operativnog sustava. One bilježe stanje diska točno onako kako postoji u toj mikrosekundi.
Kako transakcijske baze podataka upravljaju stanjem
Transakcijske baze podataka dizajnirane su oko ACID svojstava (Atomicity, Consistency, Isolation, Durability). Kako bi postigle visoke performanse uz održavanje ACID usklađenosti, baze podataka ne zapisuju svaku transakciju izravno u primarne datoteke podataka na disku odmah. Umjesto toga, koriste složenu, višeslojnu arhitekturu:
- Buffer Pool / Shared Buffers: Podaci se čitaju i modificiraju unutar sistemske memorije.
- Write-Ahead Log (WAL) / Redo Logs: Promjene se sekvencijalno zapisuju u visoko optimiziranu datoteku zapisnika na disku kako bi se osigurala trajnost.
- Checkpoints / Lazy Writers: Povremeno baza podataka ispire modificirane (prljave) stranice iz memorije u stvarne datoteke podataka na disku.
Zbog ove arhitekture, fizičke datoteke podataka na disku gotovo su uvijek izvan sinkronizacije sa stvarnim stanjem baze podataka. Pravo stanje baze podataka postoji samo kao kombinacija datoteka podataka na disku, WAL/Redo zapisnika i podataka koji se trenutno nalaze u memoriji.
Zona opasnosti: Što se događa tijekom VM snimke
Kada napravite standardnu VM snimku poslužitelja baze podataka, bilježite stanje konzistentno u slučaju pada (crash-consistent).
Konzistentnost u slučaju pada naspram konzistentnosti aplikacije
Snimka konzistentna u slučaju pada ekvivalentna je izvlačenju kabela za napajanje iz fizičkog poslužitelja. Stanje diska je zabilježeno, ali sve što je bilo u memoriji je izgubljeno, a sve što je bilo na putu prema kontroleru pohrane naglo je prekinuto.
Iako su moderne baze podataka dizajnirane da se oporave od neočekivanog gubitka napajanja ponovnim pokretanjem Write-Ahead zapisnika, oslanjanje na oporavak od pada kao primarnu strategiju sigurnosnog kopiranja vrlo je opasno. Ako vaša baza podataka obuhvaća više virtualnih diskova (npr. datoteke podataka na pogonu D: i WAL na pogonu E:), hipervizor možda neće snimiti oba diska u točno istoj mikrosekundi. Ako se snimka WAL diska zabilježi čak i djelić sekunde nakon snimke diska s podacima, baza podataka ne može uskladiti redne brojeve prilikom vraćanja, što rezultira fatalnim oštećenjem.
Učinak “VM Stun” na sustave s visokim brojem transakcija
Proces stvaranja snimke—i što je još važnije, proces konsolidacije snimke—uzrokuje fenomen poznat kao “VM Stun” (zamrzavanje virtualnog stroja).
Kako bi sigurno prebacio I/O s osnovnog diska na delta disk, hipervizor mora nakratko pauzirati (zamrznuti) virtualni stroj. Za slabo opterećen web poslužitelj, ovo zamrzavanje može trajati 10-50 milisekundi i proći nezapaženo. Međutim, za bazu podataka s velikim protokom i masivnim I/O-om, konsolidacija velikog delta diska može zamrznuti VM na nekoliko sekundi.
Tijekom VM zamrzavanja:
* Mrežne veze pucaju, uzrokujući vremenska ograničenja (timeouts) aplikacija.
* Klasteri visoke dostupnosti (poput SQL Server Always On, PostgreSQL Patroni ili MySQL Galera) propuštaju provjere otkucaja srca (heartbeat).
* Klaster može pretpostaviti da je zamrznuti čvor mrtav, pokrećući nepotreban i ometajući failover (scenarij podijeljenog mozga/split-brain).
Rastrgane stranice i I/O neusklađenost
Pogoni baza podataka obično zapisuju podatke u određenim veličinama stranica (npr. 8KB za PostgreSQL i SQL Server, 16KB za InnoDB). Međutim, temeljni operativni sustav i nizovi za pohranu obrađuju I/O u manjim blokovima (npr. 4KB ili 512 bajtova).
Ako hipervizor napravi snimku točno dok baza podataka zapisuje stranicu od 8KB, snimka može zabilježiti prvih 4KB novih podataka i zadnjih 4KB starih podataka. To stvara rastrganu stranicu (torn page). Kada pokušate vratiti snimku, baza podataka će pročitati stranicu, neće proći provjeru kontrolnog zbroja i označit će bazu podataka kao oštećenu.
Posljedice u stvarnom svijetu za specifične pogone baza podataka
Različiti pogoni baza podataka reagiraju na snimke konzistentne u slučaju pada na različite načine, ali niti jedan od njih se ne nosi s tim elegantno u produkcijskom okruženju.
- PostgreSQL: PostgreSQL se uvelike oslanja na direktorij
pg_wal. Ako snimka zabilježi direktorij podataka ($PGDATA) i WAL izvan sinkronizacije, PostgreSQL se neće pokrenuti, izbacujući pogreškuPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB koristi međuspremnik dvostrukog zapisivanja (doublewrite buffer) za sprječavanje rastrganih stranica, što nudi određenu zaštitu od stanja konzistentnih u slučaju pada. Međutim, ako su datoteka
ibdata1iib_logfilezabilježene izvan sinkronizacije, InnoDB pogon će se srušiti pri oporavku. - Microsoft SQL Server: SQL Server je vrlo osjetljiv na zamrzavanje I/O-a. Bez pravilne VSS (Volume Shadow Copy Service) integracije, vraćanje SQL Servera iz standardne VM snimke često će rezultirati sumnjivim bazama podataka i prekinutim lancima zapisnika, uništavajući vaše mogućnosti oporavka do određene točke u vremenu (PITR).
Najbolje prakse za sigurno sigurnosno kopiranje virtualiziranih baza podataka
Kako biste zaštitili transakcijske baze podataka, morate prijeći sa sigurnosnih kopija konzistentnih u slučaju pada na sigurnosne kopije konzistentne na razini aplikacije. To zahtijeva da mehanizam sigurnosnog kopiranja komunicira s pogonom baze podataka, prisiljavajući ga da ispere memoriju na disk i privremeno pauzira I/O operacije dok se snimka uzima.
1. Iskoristite aplikacijski svjesno zamrzavanje (VSS i fsfreeze)
Za Windows (SQL Server):
Uvijek osigurajte da vaše rješenje za sigurnosno kopiranje koristi Microsoft Volume Shadow Copy Service (VSS). Kada se pokrene sigurnosna kopija svjesna VSS-a, SQL Server VSS Writer zamrzava I/O baze podataka, ispire čekajuće transakcije na disk i osigurava da je snimka savršeno konzistentna na razini aplikacije.
Za Linux (PostgreSQL / MySQL):
Linux nema izvorni ekvivalent VSS-u. Da biste postigli konzistentnost aplikacije, morate koristiti skripte za zamrzavanje (pre-freeze) i odmrzavanje (post-thaw) u kombinaciji s alatima za goste hipervizora (npr. VMware Tools).
Ovo je primjer VMware pre-freeze-script za PostgreSQL 15+ koji sigurno priprema bazu podataka za snimku:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Osigurajte da je ova skripta izvršna (chmod +x)
# 1. Recite PostgreSQL-u da se pripremi za sigurnosnu kopiju
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Ispraznite međuspremnike datotečnog sustava na disk
sync
# 3. Zamrznite datotečni sustav (pod pretpostavkom da su podaci na /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
I odgovarajuća post-thaw-script za nastavak operacija:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Odmrznite datotečni sustav
fsfreeze -u /var/lib/pgsql
# 2. Recite PostgreSQL-u da je sigurnosna kopija dovršena
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Koristite izvorne uslužne programe za sigurnosno kopiranje baza podataka
Iako su snimke konzistentne na razini aplikacije bolje od standardnih snimki, one i dalje nose rizik od VM zamrzavanja. Najsigurniji pristup za sigurnosne kopije baza podataka je korištenje izvornih, streaming uslužnih programa za sigurnosno kopiranje koji rade neovisno o hipervizoru.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Ovi alati uzimaju “vruće”, neblokirajuće sigurnosne kopije kopiranjem datoteka podataka i istovremenim praćenjem promjena u redo zapisniku.
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. Implementirajte oporavak do određene točke u vremenu (PITR) putem arhiviranja zapisnika
Dnevna snimka ili potpuna sigurnosna kopija štiti vas samo do minute kada je snimljena. Ako se vaša baza podataka sruši u 16:00, a vaša posljednja snimka bila je u 02:00, gubite 14 sati transakcijskih podataka.
Da biste postigli istinsku otpornost na razini poduzeća, morate kombinirati potpune sigurnosne kopije konzistentne na razini aplikacije s kontinuiranim arhiviranjem zapisnika (sigurnosno kopiranje WAL-a, Redo zapisnika ili transakcijskih zapisnika svakih nekoliko minuta). To omogućuje administratorima baza podataka da vrate bazu podataka na određenu minutu ili čak određeni ID transakcije prije katastrofe.
Strategije sigurnosnog kopiranja za poduzeća uz CloudSave
Upravljanje prilagođenim skriptama za zamrzavanje, cron zadacima za izvorne dumpove i slanjem zapisnika preko desetaka poslužitelja baza podataka operativna je noćna mora za DevOps timove. Ovdje platforma poslovne klase kao što je CloudSave postaje ključna.
CloudSave premošćuje jaz između virtualizacije i arhitekture baza podataka. Umjesto oslanjanja na slijepe snimke hipervizora, CloudSave koristi agente svjesne aplikacija koji se izvorno integriraju sa SQL Serverom, PostgreSQL-om, MySQL-om i Oracleom.
Kada CloudSave pokrene sigurnosnu kopiju:
1. Komunicira izravno s pogonom baze podataka putem izvornih API-ja (poput VSS-a za Windows ili izvornog WAL streaminga za Linux).
2. Orkestrira ispiranje memorijskih međuspremnika na disk bez izazivanja ometajućih VM zamrzavanja.
3. Sigurno bilježi datoteke podataka i automatski upravlja skraćivanjem transakcijskih zapisnika.
4. Kontinuirano sigurnosno kopira transakcijske zapisnike, omogućujući granularni oporavak do određene točke u vremenu (PITR) s nekoliko klikova.
Prebacivanjem složenosti konzistentnosti aplikacije na CloudSave, administratori baza podataka i sistemski administratori mogu jamčiti integritet podataka bez žrtvovanja performansi ili dostupnosti svojih produkcijskih klastera.
Zaključak
Snimke virtualnih strojeva nevjerojatan su alat za upravljanje infrastrukturom, ali su temeljno nekompatibilne s ACID zahtjevima transakcijskih baza podataka. Oslanjanje na snimke hipervizora konzistentne u slučaju pada izlaže vašu organizaciju rastrganim stranicama, prekinutim lancima replikacije i katastrofalnom gubitku podataka.
Kako biste zaštitili svoje kritične podatke, morate implementirati zamrzavanje svjesno aplikacije, koristiti izvorne metodologije sigurnosnog kopiranja baza podataka i održavati kontinuirane arhive transakcijskih zapisnika. Usvajanjem namjenskih rješenja za sigurnosno kopiranje na razini poduzeća, možete osigurati da vaše baze podataka ostanu visoko dostupne, potpuno oporavljive i potpuno sigurne.
