Za DevOps in\u017eenjere i sistem administratore, snimke virtualnih strojeva (VM snapshots) predstavljaju temeljni alat. Oni pru\u017eaju brz i prakti\u010dan na\u010din za bilje\u017eenje stanja poslu\u017eitelja prije rizi\u010dnog a\u017euriranja, velike promjene konfiguracije ili implementacije aplikacije. Ako ne\u0161to po\u0111e po zlu, povratak na prethodno stanje traje svega nekoliko sekundi.<\/p>\n
Me\u0111utim, kada se ista metodologija primijeni na transakcijske baze podataka\u2014kao \u0161to su PostgreSQL, MySQL, Oracle ili Microsoft SQL Server\u2014VM snimke se iz sigurnosne mre\u017ee pretvaraju u tempiranu bombu.<\/p>\n
Oslanjanje na standardne snimke hipervizora za sigurnosne kopije baza podataka jedan je od naj\u010de\u0161\u0107ih uzroka o\u0161te\u0107enja podataka, “rastrganih” stranica (torn pages) i nepopravljivih prekida u radu produkcijskih sustava. U ovom \u0107emo \u010dlanku istra\u017eiti arhitektonski sukob izme\u0111u hipervizora i pogona baza podataka, mehaniku o\u0161te\u0107enja podataka tijekom snimanja te in\u017eenjerske najbolje prakse potrebne za sigurno sigurnosno kopiranje virtualiziranih baza podataka.<\/p>\n
Da bismo razumjeli za\u0161to VM snimke ugro\u017eavaju baze podataka, prvo moramo ispitati kako oba sustava upravljaju stanjem i I\/O operacijama.<\/p>\n
Kada hipervizor (kao \u0161to je VMware ESXi, Microsoft Hyper-V ili KVM) napravi snimku, on ne kopira disk. Umjesto toga, zamrzava trenutnu datoteku virtualnog diska (npr. Kada se snimka izbri\u0161e, hipervizor mora potvrditi (konsolidirati) podatke s delta diska natrag u osnovni disk. Standardne snimke nisu svjesne aplikacija koje se izvode unutar gostuju\u0107eg operativnog sustava. One bilje\u017ee stanje diska to\u010dno onako kako postoji u toj mikrosekundi.<\/p>\n Transakcijske baze podataka dizajnirane su oko ACID svojstava (Atomicity, Consistency, Isolation, Durability). Kako bi postigle visoke performanse uz odr\u017eavanje ACID uskla\u0111enosti, baze podataka ne zapisuju svaku transakciju izravno u primarne datoteke podataka na disku odmah. Umjesto toga, koriste slo\u017eenu, vi\u0161eslojnu arhitekturu:<\/p>\n Zbog ove arhitekture, fizi\u010dke 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.<\/p>\n Kada napravite standardnu VM snimku poslu\u017eitelja baze podataka, bilje\u017eite stanje konzistentno u slu\u010daju pada (crash-consistent)<\/strong>.<\/p>\n Snimka konzistentna u slu\u010daju pada ekvivalentna je izvla\u010denju kabela za napajanje iz fizi\u010dkog poslu\u017eitelja. Stanje diska je zabilje\u017eeno, ali sve \u0161to je bilo u memoriji je izgubljeno, a sve \u0161to je bilo na putu prema kontroleru pohrane naglo je prekinuto.<\/p>\n Iako su moderne baze podataka dizajnirane da se oporave od neo\u010dekivanog gubitka napajanja ponovnim pokretanjem Write-Ahead zapisnika, oslanjanje na oporavak od pada kao primarnu strategiju sigurnosnog kopiranja vrlo je opasno. Ako va\u0161a baza podataka obuhva\u0107a vi\u0161e virtualnih diskova (npr. datoteke podataka na Proces stvaranja snimke\u2014i \u0161to je jo\u0161 va\u017enije, proces konsolidacije snimke\u2014uzrokuje fenomen poznat kao “VM Stun” (zamrzavanje virtualnog stroja).<\/p>\n Kako bi sigurno prebacio I\/O s osnovnog diska na delta disk, hipervizor mora nakratko pauzirati (zamrznuti) virtualni stroj. Za slabo optere\u0107en web poslu\u017eitelj, ovo zamrzavanje mo\u017ee trajati 10-50 milisekundi i pro\u0107i nezapa\u017eeno. Me\u0111utim, za bazu podataka s velikim protokom i masivnim I\/O-om, konsolidacija velikog delta diska mo\u017ee zamrznuti VM na nekoliko sekundi.<\/p>\n Tijekom VM zamrzavanja: Pogoni baza podataka obi\u010dno zapisuju podatke u odre\u0111enim veli\u010dinama stranica (npr. 8KB za PostgreSQL i SQL Server, 16KB za InnoDB). Me\u0111utim, temeljni operativni sustav i nizovi za pohranu obra\u0111uju I\/O u manjim blokovima (npr. 4KB ili 512 bajtova).<\/p>\n Ako hipervizor napravi snimku to\u010dno dok baza podataka zapisuje stranicu od 8KB, snimka mo\u017ee zabilje\u017eiti prvih 4KB novih podataka i zadnjih 4KB starih podataka. To stvara rastrganu stranicu (torn page)<\/strong>. Kada poku\u0161ate vratiti snimku, baza podataka \u0107e pro\u010ditati stranicu, ne\u0107e pro\u0107i provjeru kontrolnog zbroja i ozna\u010dit \u0107e bazu podataka kao o\u0161te\u0107enu.<\/p>\n Razli\u010diti pogoni baza podataka reagiraju na snimke konzistentne u slu\u010daju pada na razli\u010dite na\u010dine, ali niti jedan od njih se ne nosi s tim elegantno u produkcijskom okru\u017eenju.<\/p>\n Kako biste za\u0161titili transakcijske baze podataka, morate prije\u0107i sa sigurnosnih kopija konzistentnih u slu\u010daju pada na sigurnosne kopije konzistentne na razini aplikacije<\/strong>. To zahtijeva da mehanizam sigurnosnog kopiranja komunicira s pogonom baze podataka, prisiljavaju\u0107i ga da ispere memoriju na disk i privremeno pauzira I\/O operacije dok se snimka uzima.<\/p>\n Za Windows (SQL Server):<\/strong> Za Linux (PostgreSQL \/ MySQL):<\/strong> Ovo je primjer VMware I odgovaraju\u0107a 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\u0161tenje izvornih, streaming uslu\u017enih programa za sigurnosno kopiranje koji rade neovisno o hipervizoru.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Dnevna snimka ili potpuna sigurnosna kopija \u0161titi vas samo do minute kada je snimljena. Ako se va\u0161a baza podataka sru\u0161i u 16:00, a va\u0161a posljednja snimka bila je u 02:00, gubite 14 sati transakcijskih podataka.<\/p>\n Da biste postigli istinsku otpornost na razini poduze\u0107a, 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\u0107uje administratorima baza podataka da vrate bazu podataka na odre\u0111enu minutu ili \u010dak odre\u0111eni ID transakcije prije katastrofe.<\/p>\n Upravljanje prilago\u0111enim skriptama za zamrzavanje, cron zadacima za izvorne dumpove i slanjem zapisnika preko desetaka poslu\u017eitelja baza podataka operativna je no\u0107na mora za DevOps timove. Ovdje platforma poslovne klase kao \u0161to je CloudSave postaje klju\u010dna.<\/p>\n CloudSave premo\u0161\u0107uje jaz izme\u0111u 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.<\/p>\n Kada CloudSave pokrene sigurnosnu kopiju: Prebacivanjem slo\u017eenosti konzistentnosti aplikacije na CloudSave, administratori baza podataka i sistemski administratori mogu jam\u010diti integritet podataka bez \u017ertvovanja performansi ili dostupnosti svojih produkcijskih klastera.<\/p>\n 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\u010daju pada izla\u017ee va\u0161u organizaciju rastrganim stranicama, prekinutim lancima replikacije i katastrofalnom gubitku podataka.<\/p>\n Kako biste za\u0161titili svoje kriti\u010dne podatke, morate implementirati zamrzavanje svjesno aplikacije, koristiti izvorne metodologije sigurnosnog kopiranja baza podataka i odr\u017eavati kontinuirane arhive transakcijskih zapisnika. Usvajanjem namjenskih rje\u0161enja za sigurnosno kopiranje na razini poduze\u0107a, mo\u017eete osigurati da va\u0161e baze podataka ostanu visoko dostupne, potpuno oporavljive i potpuno sigurne.<\/p>\n","protected":false},"excerpt":{"rendered":" > Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Why VM Snapshots Are Unsafe for Transactional Databases","rank_math_description":"> Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.","rank_math_focus_keyword":"VM snapshots transactional databases","footnotes":""},"categories":[375],"tags":[3320,3602,3603,3604,3605,3606,3607],"class_list":["post-5473","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-data-integrity","tag-database-corruption","tag-database-recovery","tag-dba-guide","tag-hypervisor-snapshots","tag-transactional-databases","tag-vm-snapshots"],"yoast_head":"\n.vmdk<\/code> ili .vhdx<\/code>) u stanje samo za \u010ditanje i stvara novi delta disk (disk za razlike). Svi naknadni zapisi usmjeravaju se na taj delta disk.<\/p>\nKako transakcijske baze podataka upravljaju stanjem<\/h3>\n
\n
Zona opasnosti: \u0160to se doga\u0111a tijekom VM snimke<\/h2>\n
Konzistentnost u slu\u010daju pada naspram konzistentnosti aplikacije<\/h3>\n
pogonu D:<\/code> i WAL na pogonu E:<\/code>), hipervizor mo\u017eda ne\u0107e snimiti oba diska u to\u010dno istoj mikrosekundi. Ako se snimka WAL diska zabilje\u017ei \u010dak i djeli\u0107 sekunde nakon snimke diska s podacima, baza podataka ne mo\u017ee uskladiti redne brojeve prilikom vra\u0107anja, \u0161to rezultira fatalnim o\u0161te\u0107enjem.<\/p>\nU\u010dinak “VM Stun” na sustave s visokim brojem transakcija<\/h3>\n
\n* Mre\u017ene veze pucaju, uzrokuju\u0107i vremenska ograni\u010denja (timeouts) aplikacija.
\n* Klasteri visoke dostupnosti (poput SQL Server Always On, PostgreSQL Patroni ili MySQL Galera) propu\u0161taju provjere otkucaja srca (heartbeat).
\n* Klaster mo\u017ee pretpostaviti da je zamrznuti \u010dvor mrtav, pokre\u0107u\u0107i nepotreban i ometaju\u0107i failover (scenarij podijeljenog mozga\/split-brain).<\/p>\nRastrgane stranice i I\/O neuskla\u0111enost<\/h3>\n
Posljedice u stvarnom svijetu za specifi\u010dne pogone baza podataka<\/h2>\n
\n
pg_wal<\/code>. Ako snimka zabilje\u017ei direktorij podataka ($PGDATA<\/code>) i WAL izvan sinkronizacije, PostgreSQL se ne\u0107e pokrenuti, izbacuju\u0107i pogre\u0161ku PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> i ib_logfile<\/code> zabilje\u017eene izvan sinkronizacije, InnoDB pogon \u0107e se sru\u0161iti pri oporavku.<\/li>\nNajbolje prakse za sigurno sigurnosno kopiranje virtualiziranih baza podataka<\/h2>\n
1. Iskoristite aplikacijski svjesno zamrzavanje (VSS i fsfreeze)<\/h3>\n
\nUvijek osigurajte da va\u0161e rje\u0161enje 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 \u010dekaju\u0107e transakcije na disk i osigurava da je snimka savr\u0161eno konzistentna na razini aplikacije.<\/p>\n
\nLinux 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).<\/p>\npre-freeze-script<\/code> za PostgreSQL 15+ koji sigurno priprema bazu podataka za snimku:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Osigurajte da je ova skripta izvr\u0161na (chmod +x)\n\n# 1. Recite PostgreSQL-u da se pripremi za sigurnosnu kopiju\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Ispraznite me\u0111uspremnike datote\u010dnog sustava na disk\nsync\n\n# 3. Zamrznite datote\u010dni sustav (pod pretpostavkom da su podaci na \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> za nastavak operacija:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Odmrznite datote\u010dni sustav\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Recite PostgreSQL-u da je sigurnosna kopija dovr\u0161ena\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Koristite izvorne uslu\u017ene programe za sigurnosno kopiranje baza podataka<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nOvi alati uzimaju “vru\u0107e”, neblokiraju\u0107e sigurnosne kopije kopiranjem datoteka podataka i istovremenim pra\u0107enjem promjena u redo zapisniku.<\/p>\nmariabackup --backup --target-dir=\/mnt\/backups\/mysql_backup --user=root --password=SecurePass\n<\/code><\/pre>\nBACKUP DATABASE [ProductionDB] \nTO DISK = N'Z:BackupsProductionDB.bak' \nWITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', \nSKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\n3. Implementirajte oporavak do odre\u0111ene to\u010dke u vremenu (PITR) putem arhiviranja zapisnika<\/h3>\n
Strategije sigurnosnog kopiranja za poduze\u0107a uz CloudSave<\/h2>\n
\n1. Komunicira izravno s pogonom baze podataka putem izvornih API-ja (poput VSS-a za Windows ili izvornog WAL streaminga za Linux).
\n2. Orkestrira ispiranje memorijskih me\u0111uspremnika na disk bez izazivanja ometaju\u0107ih VM zamrzavanja.
\n3. Sigurno bilje\u017ei datoteke podataka i automatski upravlja skra\u0107ivanjem transakcijskih zapisnika.
\n4. Kontinuirano sigurnosno kopira transakcijske zapisnike, omogu\u0107uju\u0107i granularni oporavak do odre\u0111ene to\u010dke u vremenu (PITR) s nekoliko klikova.<\/p>\nZaklju\u010dak<\/h2>\n