Za DevOps in\u017eenjere i sistemske administratore, snimci virtuelnih ma\u0161ina (VM snapshots) predstavljaju osnovni alat. Oni pru\u017eaju brz i prakti\u010dan na\u010din za bele\u017eenje stanja servera pre rizi\u010dnog a\u017euriranja, velike promene konfiguracije ili primene aplikacije. Ako ne\u0161to krene po zlu, vra\u0107anje na prethodno stanje traje svega nekoliko sekundi.<\/p>\n
Me\u0111utim, kada se ova ista metodologija primeni na transakcione baze podataka\u2014kao \u0161to su PostgreSQL, MySQL, Oracle ili Microsoft SQL Server\u2014snimci virtuelnih ma\u0161ina se pretvaraju iz sigurnosne mre\u017ee u tempiranu bombu.<\/p>\n
Oslanjanje na standardne snimke hipervizora za pravljenje rezervnih kopija baza podataka jedan je od naj\u010de\u0161\u0107ih uzroka o\u0161te\u0107enja podataka, \u201epocepanih\u201c stranica (torn pages) i nepopravljivih prekida u radu produkcionih sistema. U ovom \u010dlanku istra\u017ei\u0107emo arhitektonski sukob izme\u0111u hipervizora i mehanizama baza podataka, mehaniku o\u0161te\u0107enja podataka tokom snimanja i in\u017eenjerske najbolje prakse potrebne za bezbedno pravljenje rezervnih kopija virtuelizovanih baza podataka.<\/p>\n
Da bismo razumeli za\u0161to snimci virtuelnih ma\u0161ina ugro\u017eavaju baze podataka, prvo moramo ispitati kako oba sistema upravljaju stanjem i I\/O operacijama.<\/p>\n
Kada hipervizor (kao \u0161to je VMware ESXi, Microsoft Hyper-V ili KVM) napravi snimak, on ne kopira disk. Umesto toga, on zamrzava trenutnu datoteku virtuelnog diska (npr. Kada se snimak obri\u0161e, hipervizor mora da potvrdi (konsoliduje) podatke sa delta diska nazad u osnovni disk. Standardni snimci su potpuno nesvesni aplikacija koje rade unutar gostuju\u0107eg operativnog sistema. Oni bele\u017ee stanje diska ta\u010dno onako kako postoji u toj mikrosekundi.<\/p>\n Transakcione baze podataka su dizajnirane oko ACID svojstava (Atomicity, Consistency, Isolation, Durability \u2013 Atomi\u010dnost, Konzistentnost, Izolacija, Trajnost). Da bi postigle visoke performanse uz odr\u017eavanje ACID usagla\u0161enosti, baze podataka ne upisuju svaku transakciju direktno u primarne datoteke podataka na disku odmah. Umesto toga, koriste slo\u017eenu, vi\u0161eslojnu arhitekturu:<\/p>\n Zbog ove arhitekture, fizi\u010dke datoteke podataka na disku su skoro uvek van sinhronizacije sa stvarnim stanjem baze podataka. Pravo stanje baze podataka postoji samo kao kombinacija datoteka podataka na disku, WAL\/Redo dnevnika i podataka koji se trenutno nalaze u memoriji.<\/p>\n Kada napravite standardni snimak virtuelne ma\u0161ine na kojoj se nalazi baza podataka, vi bele\u017eite stanje konzistentno u slu\u010daju pada (crash-consistent)<\/strong>.<\/p>\n Snimak konzistentan u slu\u010daju pada je ekvivalentan izvla\u010denju kabla za napajanje iz fizi\u010dkog servera. Stanje diska je zabele\u017eeno, ali sve \u0161to je bilo u memoriji je izgubljeno, a sve \u0161to je bilo u procesu slanja ka kontroleru skladi\u0161tenja je naglo prekinuto.<\/p>\n Iako su moderne baze podataka dizajnirane da se oporave od neo\u010dekivanog gubitka napajanja ponovnim pokretanjem Write-Ahead dnevnika, oslanjanje na oporavak od pada kao primarnu strategiju rezervnih kopija je veoma opasno. Ako va\u0161a baza podataka obuhvata vi\u0161e virtuelnih diskova (npr. datoteke podataka na Proces kreiranja snimka\u2014i \u0161to je jo\u0161 va\u017enije, proces konsolidacije snimka\u2014izaziva fenomen poznat kao \u201eVM Stun\u201c (zamrzavanje virtuelne ma\u0161ine).<\/p>\n Da bi bezbedno prebacio I\/O sa osnovnog diska na delta disk, hipervizor mora nakratko da pauzira (zamrzne) virtuelnu ma\u0161inu. Za slabo optere\u0107en veb server, ovo zamrzavanje mo\u017ee trajati 10-50 milisekundi i pro\u0107i neprime\u0107eno. Me\u0111utim, za bazu podataka sa visokim protokom i masivnim I\/O operacijama, konsolidacija velikog delta diska mo\u017ee zamrznuti virtuelnu ma\u0161inu na nekoliko sekundi.<\/p>\n Tokom zamrzavanja virtuelne ma\u0161ine: Mehanizmi baza podataka obi\u010dno upisuju podatke u odre\u0111enim veli\u010dinama stranica (npr. 8KB za PostgreSQL i SQL Server, 16KB za InnoDB). Me\u0111utim, operativni sistem i skladi\u0161ni nizovi ispod njih obra\u0111uju I\/O u manjim blokovima (npr. 4KB ili 512 bajtova).<\/p>\n Ako hipervizor napravi snimak ta\u010dno dok baza podataka upisuje stranicu od 8KB, snimak mo\u017ee zabele\u017eiti prvih 4KB novih podataka i poslednjih 4KB starih podataka. Ovo stvara pocepanu stranicu (torn page)<\/strong>. Kada poku\u0161ate da vratite snimak, baza podataka \u0107e pro\u010ditati stranicu, ne\u0107e pro\u0107i validaciju kontrolne sume i ozna\u010di\u0107e bazu podataka kao o\u0161te\u0107enu.<\/p>\n Razli\u010diti mehanizmi baza podataka reaguju na snimke konzistentne u slu\u010daju pada na razli\u010dite na\u010dine, ali nijedan od njih se ne pona\u0161a korektno u produkcionom okru\u017eenju.<\/p>\n Da biste za\u0161titili transakcione baze podataka, morate pre\u0107i sa rezervnih kopija konzistentnih u slu\u010daju pada na aplikaciono-konzistentne<\/strong> rezervne kopije. Ovo zahteva da mehanizam za pravljenje rezervnih kopija komunicira sa mehanizmom baze podataka, primoravaju\u0107i ga da ispere memoriju na disk i nakratko pauzira I\/O operacije dok se snimak pravi.<\/p>\n Za Windows (SQL Server):<\/strong> Za Linux (PostgreSQL \/ MySQL):<\/strong> Evo primera VMware I odgovaraju\u0107a Iako su aplikaciono-konzistentni snimci bolji od standardnih snimaka, oni i dalje nose rizik od zamrzavanja virtuelne ma\u0161ine (VM stun). Najsigurniji pristup za rezervne kopije baza podataka je kori\u0161\u0107enje izvornih, striming uslu\u017enih programa za rezervne kopije koji rade nezavisno od hipervizora.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Dnevni snimak ili potpuna rezervna kopija vas \u0161titi samo do minuta kada je napravljena. Ako se va\u0161a baza podataka sru\u0161i u 16:00, a va\u0161 poslednji snimak je bio u 02:00, gubite 14 sati transakcionih podataka.<\/p>\n Da biste postigli pravu otpornost na nivou preduze\u0107a, morate kombinovati potpune aplikaciono-konzistentne rezervne kopije sa kontinuiranim arhiviranjem dnevnika (pravljenje rezervnih kopija WAL, Redo dnevnika ili transakcionih dnevnika svakih nekoliko minuta). Ovo omogu\u0107ava administratorima baza podataka da vrate bazu podataka na odre\u0111eni minut ili \u010dak odre\u0111eni ID transakcije pre katastrofe.<\/p>\n Upravljanje prilago\u0111enim pre-freeze skriptama, cron poslovima za izvorne dump-ove i slanjem dnevnika na desetine servera baza podataka je operativna no\u0107na mora za DevOps timove. Ovde platforma poslovnog nivoa kao \u0161to je CloudSave postaje kriti\u010dna.<\/p>\n CloudSave premo\u0161\u0107uje jaz izme\u0111u virtuelizacije i arhitekture baza podataka. Umesto oslanjanja na slepe snimke hipervizora, CloudSave koristi aplikaciono-svesne agente koji se izvorno integri\u0161u sa SQL Serverom, PostgreSQL-om, MySQL-om i Oracle-om.<\/p>\n Kada CloudSave pokrene rezervnu kopiju: Prebacivanjem slo\u017eenosti aplikacione konzistentnosti na CloudSave, administratori baza podataka i sistemski administratori mogu garantovati integritet podataka bez \u017ertvovanja performansi ili dostupnosti svojih produkcionih klastera.<\/p>\n Snimci virtuelnih ma\u0161ina su neverovatan alat za upravljanje infrastrukturom, ali su fundamentalno nekompatibilni sa ACID zahtevima transakcionih baza podataka. Oslanjanje na snimke hipervizora konzistentne u slu\u010daju pada izla\u017ee va\u0161u organizaciju pocepanim stranicama, prekinutim lancima replikacije i katastrofalnom gubitku podataka.<\/p>\n Da biste za\u0161titili svoje kriti\u010dne podatke, morate implementirati aplikaciono-svesno zamrzavanje, koristiti izvorne metodologije za pravljenje rezervnih kopija baza podataka i odr\u017eavati kontinuirane arhive transakcionih dnevnika. Usvajanjem namenskih re\u0161enja za rezervne kopije na nivou preduze\u0107a, mo\u017eete osigurati da va\u0161e baze podataka ostanu visoko dostupne, potpuno oporavljive i potpuno bezbedne.<\/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":[663],"tags":[3464,3818,3819,3820,3821,3822,3823],"class_list":["post-5541","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 kreira novi delta disk (diferencijalni disk). Sva naknadna upisivanja se usmeravaju na ovaj delta disk.<\/p>\nKako transakcione baze podataka upravljaju stanjem<\/h3>\n
\n
Zona opasnosti: \u0160ta se de\u0161ava tokom snimka virtuelne ma\u0161ine<\/h2>\n
Konzistentnost u slu\u010daju pada naspram aplikacione konzistentnosti<\/h3>\n
Drive D:<\/code> i WAL na Drive E:<\/code>), hipervizor mo\u017eda ne\u0107e snimiti oba diska u istoj mikrosekundi. Ako se snimak WAL diska napravi \u010dak i deli\u0107 sekunde nakon snimka diska sa podacima, baza podataka ne mo\u017ee da uskladi redne brojeve prilikom vra\u0107anja, \u0161to rezultira fatalnim o\u0161te\u0107enjem.<\/p>\nEfekat \u201eVM Stun\u201c na sisteme sa velikim brojem transakcija<\/h3>\n
\n* Mre\u017ene konekcije pucaju, uzrokuju\u0107i vremenska ograni\u010denja (timeouts) aplikacija.
\n* Klasteri visoke dostupnosti (kao \u0161to su SQL Server Always On, PostgreSQL Patroni ili MySQL Galera) propu\u0161taju provere statusa (heartbeat checks).
\n* Klaster mo\u017ee pretpostaviti da je zamrznuti \u010dvor mrtav, pokre\u0107u\u0107i nepotreban i ometaju\u0107i prelazak na rezervni sistem (scenario split-brain).<\/p>\nPocepane stranice i I\/O neuskla\u0111enost<\/h3>\n
Posledice u stvarnom svetu za specifi\u010dne mehanizme baza podataka<\/h2>\n
\n
pg_wal<\/code> direktorijum. Ako snimak zabele\u017ei direktorijum sa podacima ($PGDATA<\/code>) i WAL van sinhronizacije, PostgreSQL se ne\u0107e pokrenuti, izbacuju\u0107i gre\u0161ku PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> datoteka i ib_logfile<\/code> zabele\u017eeni van sinhronizacije, InnoDB mehanizam \u0107e se sru\u0161iti prilikom oporavka.<\/li>\nNajbolje prakse za bezbedno pravljenje rezervnih kopija virtuelizovanih baza podataka<\/h2>\n
1. Iskoristite aplikaciono-svesno zamrzavanje (VSS i fsfreeze)<\/h3>\n
\nUvek se uverite da va\u0161e re\u0161enje za rezervne kopije koristi Microsoft Volume Shadow Copy Service (VSS). Kada se pokrene rezervna kopija svesna VSS-a, SQL Server VSS Writer zamrzava I\/O baze podataka, ispira \u010dekaju\u0107e transakcije na disk i osigurava da je snimak savr\u0161eno aplikaciono-konzistentan.<\/p>\n
\nLinux nema izvorni ekvivalent VSS-u. Da biste postigli aplikacionu konzistentnost, morate koristiti skripte za pre-freeze i post-thaw u kombinaciji sa alatima za goste hipervizora (npr. VMware Tools).<\/p>\npre-freeze-script<\/code> za PostgreSQL 15+ koji bezbedno priprema bazu podataka za snimak:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Uverite se da je ova skripta izvr\u0161na (chmod +x)\n\n# 1. Recite PostgreSQL-u da se pripremi za rezervnu kopiju\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Ispirite bafer sistema datoteka na disk\nsync\n\n# 3. Zamrznite sistem datoteka (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 sistem datoteka\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Recite PostgreSQL-u da je rezervna kopija zavr\u0161ena\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Koristite izvorne uslu\u017ene programe za rezervne kopije 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 prave „vru\u0107e“, neblokiraju\u0107e rezervne kopije kopiranjem datoteka podataka i istovremenim pra\u0107enjem promena u redo dnevniku.<\/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 u odre\u0111enom trenutku (PITR) putem arhiviranja dnevnika<\/h3>\n
Strategije rezervnih kopija za preduze\u0107a sa CloudSave-om<\/h2>\n
\n1. Komunicira direktno sa mehanizmom baze podataka putem izvornih API-ja (kao \u0161to je VSS za Windows ili izvorno WAL strimovanje za Linux).
\n2. Orkestrira ispiranje memorijskih bafera na disk bez izazivanja ometaju\u0107ih zamrzavanja virtuelne ma\u0161ine.
\n3. Bezbedno bele\u017ei datoteke podataka i automatski upravlja skra\u0107ivanjem transakcionih dnevnika.
\n4. Kontinuirano pravi rezervne kopije transakcionih dnevnika, omogu\u0107avaju\u0107i granularni oporavak u odre\u0111enom trenutku (PITR) sa nekoliko klikova.<\/p>\nZaklju\u010dak<\/h2>\n