Dla in\u017cynier\u00f3w DevOps i administrator\u00f3w system\u00f3w migawki (snapshoty) maszyn wirtualnych (VM) s\u0105 podstawowym narz\u0119dziem. Zapewniaj\u0105 szybki i wygodny spos\u00f3b na uchwycenie stanu serwera przed ryzykown\u0105 poprawk\u0105, powa\u017cn\u0105 zmian\u0105 konfiguracji lub wdro\u017ceniem aplikacji. Je\u015bli co\u015b p\u00f3jdzie nie tak, przywr\u00f3cenie stanu zajmuje sekundy.<\/p>\n
Jednak\u017ce, gdy ta sama metodologia jest stosowana do baz danych transakcyjnych \u2014 takich jak PostgreSQL, MySQL, Oracle czy Microsoft SQL Server \u2014 migawki VM zmieniaj\u0105 si\u0119 z zabezpieczenia w tykaj\u0105c\u0105 bomb\u0119 zegarow\u0105.<\/p>\n
Poleganie na standardowych migawkach hiperwizora w celu tworzenia kopii zapasowych baz danych jest jedn\u0105 z najcz\u0119stszych przyczyn uszkodze\u0144 danych, \u201eposzarpanych stron\u201d (torn pages) i nieodwracalnych awarii produkcyjnych. W tym artykule przyjrzymy si\u0119 konfliktowi architektonicznemu mi\u0119dzy hiperwizorami a silnikami baz danych, mechanice uszkodze\u0144 danych podczas tworzenia migawek oraz najlepszym praktykom in\u017cynieryjnym wymaganym do bezpiecznego tworzenia kopii zapasowych zwirtualizowanych baz danych.<\/p>\n
Aby zrozumie\u0107, dlaczego migawki VM zagra\u017caj\u0105 bazom danych, musimy najpierw zbada\u0107, w jaki spos\u00f3b oba systemy zarz\u0105dzaj\u0105 stanem i operacjami wej\u015bcia\/wyj\u015bcia (I\/O).<\/p>\n
Kiedy hiperwizor (taki jak VMware ESXi, Microsoft Hyper-V lub KVM) wykonuje migawk\u0119, nie kopiuje dysku. Zamiast tego zamra\u017ca bie\u017c\u0105cy plik dysku wirtualnego (np. Po usuni\u0119ciu migawki hiperwizor musi zatwierdzi\u0107 (skonsolidowa\u0107) dane z dysku delta z powrotem do dysku bazowego. Standardowe migawki nie maj\u0105 \u017cadnej wiedzy o aplikacjach dzia\u0142aj\u0105cych wewn\u0105trz systemu operacyjnego go\u015bcia. Rejestruj\u0105 stan dysku dok\u0142adnie w takiej postaci, w jakiej istnieje w danej mikrosekundzie.<\/p>\n Bazy danych transakcyjnych s\u0105 projektowane w oparciu o w\u0142a\u015bciwo\u015bci ACID (Atomowo\u015b\u0107, Sp\u00f3jno\u015b\u0107, Izolacja, Trwa\u0142o\u015b\u0107). Aby osi\u0105gn\u0105\u0107 wysok\u0105 wydajno\u015b\u0107 przy zachowaniu zgodno\u015bci z ACID, bazy danych nie zapisuj\u0105 ka\u017cdej transakcji bezpo\u015brednio do g\u0142\u00f3wnych plik\u00f3w danych na dysku w czasie rzeczywistym. Zamiast tego wykorzystuj\u0105 z\u0142o\u017con\u0105, wielopoziomow\u0105 architektur\u0119:<\/p>\n Z powodu tej architektury fizyczne pliki danych na dysku prawie zawsze nie s\u0105 zsynchronizowane z rzeczywistym stanem bazy danych. Prawdziwy stan bazy danych istnieje tylko jako kombinacja plik\u00f3w danych na dysku, dziennik\u00f3w WAL\/Redo oraz danych znajduj\u0105cych si\u0119 aktualnie w pami\u0119ci.<\/p>\n Kiedy wykonujesz standardow\u0105 migawk\u0119 VM serwera bazy danych, rejestrujesz stan sp\u00f3jny w przypadku awarii (crash-consistent)<\/strong>.<\/p>\n Migawka sp\u00f3jna w przypadku awarii jest odpowiednikiem wyci\u0105gni\u0119cia kabla zasilaj\u0105cego z fizycznego serwera. Stan dysku zostaje uchwycony, ale wszystko, co znajdowa\u0142o si\u0119 w pami\u0119ci, zostaje utracone, a operacje b\u0119d\u0105ce w trakcie przesy\u0142ania do kontrolera pami\u0119ci masowej zostaj\u0105 nagle przerwane.<\/p>\n Chocia\u017c nowoczesne bazy danych s\u0105 zaprojektowane tak, aby odzyskiwa\u0107 sprawno\u015b\u0107 po nieoczekiwanej utracie zasilania poprzez odtworzenie dziennika transakcji (WAL), poleganie na odzyskiwaniu po awarii jako g\u0142\u00f3wnej strategii tworzenia kopii zapasowych jest bardzo niebezpieczne. Je\u015bli baza danych rozci\u0105ga si\u0119 na wiele dysk\u00f3w wirtualnych (np. pliki danych na Proces tworzenia migawki \u2014 a co wa\u017cniejsze, proces konsolidacji migawki \u2014 powoduje zjawisko znane jako \u201eVM Stun\u201d (zamro\u017cenie maszyny wirtualnej).<\/p>\n Aby bezpiecznie prze\u0142\u0105czy\u0107 operacje I\/O z dysku bazowego na dysk delta, hiperwizor musi na chwil\u0119 wstrzyma\u0107 (zamrozi\u0107) maszyn\u0119 wirtualn\u0105. W przypadku lekko obci\u0105\u017conego serwera WWW to zamro\u017cenie mo\u017ce trwa\u0107 10-50 milisekund i pozosta\u0107 niezauwa\u017cone. Jednak w przypadku bazy danych o wysokiej przepustowo\u015bci z ogromnym ruchem I\/O, konsolidacja du\u017cego dysku delta mo\u017ce zamrozi\u0107 maszyn\u0119 wirtualn\u0105 na kilka sekund.<\/p>\n Podczas zamro\u017cenia VM: Silniki baz danych zazwyczaj zapisuj\u0105 dane w okre\u015blonych rozmiarach stron (np. 8 KB dla PostgreSQL i SQL Server, 16 KB dla InnoDB). Jednak podstawowy system operacyjny i macierze pami\u0119ci masowej przetwarzaj\u0105 operacje I\/O w mniejszych blokach (np. 4 KB lub 512 bajt\u00f3w).<\/p>\n Je\u015bli hiperwizor wykona migawk\u0119 dok\u0142adnie w momencie, gdy baza danych zapisuje stron\u0119 8 KB, migawka mo\u017ce uchwyci\u0107 pierwsze 4 KB nowych danych i ostatnie 4 KB starych danych. Tworzy to tzw. poszarpan\u0105 stron\u0119 (torn page)<\/strong>. Podczas pr\u00f3by przywr\u00f3cenia migawki baza danych odczyta stron\u0119, nie przejdzie walidacji sumy kontrolnej i oznaczy baz\u0119 danych jako uszkodzon\u0105.<\/p>\n R\u00f3\u017cne silniki baz danych reaguj\u0105 na migawki sp\u00f3jne w przypadku awarii na r\u00f3\u017cne sposoby, ale \u017caden z nich nie radzi sobie z tym dobrze w \u015brodowisku produkcyjnym.<\/p>\n Aby chroni\u0107 bazy danych transakcyjnych, nale\u017cy przej\u015b\u0107 od kopii zapasowych sp\u00f3jnych w przypadku awarii do kopii zapasowych sp\u00f3jnych z aplikacj\u0105<\/strong>. Wymaga to, aby mechanizm kopii zapasowej komunikowa\u0142 si\u0119 z silnikiem bazy danych, zmuszaj\u0105c go do opr\u00f3\u017cnienia pami\u0119ci na dysk i chwilowego wstrzymania operacji I\/O podczas wykonywania migawki.<\/p>\n Dla Windows (SQL Server):<\/strong> Dla Linux (PostgreSQL \/ MySQL):<\/strong> Oto przyk\u0142ad skryptu VMware Oraz odpowiadaj\u0105cy mu Chocia\u017c migawki sp\u00f3jne z aplikacj\u0105 s\u0105 lepsze ni\u017c standardowe migawki, nadal nios\u0105 ze sob\u0105 ryzyko zamro\u017cenia VM (VM stun). Najbezpieczniejszym podej\u015bciem do tworzenia kopii zapasowych baz danych jest u\u017cycie natywnych, strumieniowych narz\u0119dzi do tworzenia kopii zapasowych, kt\u00f3re dzia\u0142aj\u0105 niezale\u017cnie od hiperwizora.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Codzienna migawka lub pe\u0142na kopia zapasowa chroni Ci\u0119 tylko do momentu jej wykonania. Je\u015bli Twoja baza danych ulegnie awarii o 16:00, a ostatnia migawka by\u0142a o 2:00 w nocy, tracisz 14 godzin danych transakcyjnych.<\/p>\n Aby osi\u0105gn\u0105\u0107 prawdziw\u0105 odporno\u015b\u0107 klasy korporacyjnej, musisz po\u0142\u0105czy\u0107 pe\u0142ne kopie zapasowe sp\u00f3jne z aplikacj\u0105 z ci\u0105g\u0142\u0105 archiwizacj\u0105 dziennik\u00f3w (tworzenie kopii zapasowych WAL, Redo Logs lub Transaction Logs co kilka minut). Pozwala to administratorom baz danych przywr\u00f3ci\u0107 baz\u0119 do konkretnej minuty, a nawet konkretnego identyfikatora transakcji przed wyst\u0105pieniem awarii.<\/p>\n Zarz\u0105dzanie niestandardowymi skryptami pre-freeze, zadaniami cron dla natywnych zrzut\u00f3w i przesy\u0142aniem dziennik\u00f3w na dziesi\u0105tkach serwer\u00f3w baz danych to koszmar operacyjny dla zespo\u0142\u00f3w DevOps. W tym miejscu kluczowa staje si\u0119 platforma klasy korporacyjnej, taka jak CloudSave.<\/p>\n CloudSave wype\u0142nia luk\u0119 mi\u0119dzy wirtualizacj\u0105 a architektur\u0105 baz danych. Zamiast polega\u0107 na \u201e\u015blepych\u201d migawkach hiperwizora, CloudSave wykorzystuje agent\u00f3w \u015bwiadomych aplikacji, kt\u00f3rzy natywnie integruj\u0105 si\u0119 z SQL Server, PostgreSQL, MySQL i Oracle.<\/p>\n Kiedy CloudSave inicjuje kopi\u0119 zapasow\u0105: Przenosz\u0105c z\u0142o\u017cono\u015b\u0107 zapewniania sp\u00f3jno\u015bci aplikacji na CloudSave, administratorzy baz danych i system\u00f3w mog\u0105 zagwarantowa\u0107 integralno\u015b\u0107 danych bez po\u015bwi\u0119cania wydajno\u015bci lub dost\u0119pno\u015bci swoich klastr\u00f3w produkcyjnych.<\/p>\n Migawki maszyn wirtualnych s\u0105 niesamowitym narz\u0119dziem do zarz\u0105dzania infrastruktur\u0105, ale s\u0105 fundamentalnie niekompatybilne z wymaganiami ACID baz danych transakcyjnych. Poleganie na migawkach hiperwizora sp\u00f3jnych w przypadku awarii nara\u017ca organizacj\u0119 na poszarpane strony, zerwane \u0142a\u0144cuchy replikacji i katastrofaln\u0105 utrat\u0119 danych.<\/p>\n Aby chroni\u0107 swoje krytyczne dane, musisz wdro\u017cy\u0107 quiescing \u015bwiadomy aplikacji, stosowa\u0107 natywne metodologie tworzenia kopii zapasowych baz danych i utrzymywa\u0107 ci\u0105g\u0142e archiwa dziennik\u00f3w transakcji. Przyjmuj\u0105c dedykowane rozwi\u0105zania do tworzenia kopii zapasowych klasy korporacyjnej, mo\u017cesz zapewni\u0107, \u017ce Twoje bazy danych pozostan\u0105 wysoce dost\u0119pne, w pe\u0142ni odzyskiwalne i ca\u0142kowicie bezpieczne.<\/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":[607],"tags":[3436,3776,3777,3778,3779,3780,3781],"class_list":["post-5503","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> lub .vhdx<\/code>) do stanu tylko do odczytu i tworzy nowy dysk delta (dysk r\u00f3\u017cnicowy). Wszystkie kolejne operacje zapisu s\u0105 kierowane na ten dysk delta.<\/p>\nJak bazy danych transakcyjnych zarz\u0105dzaj\u0105 stanem<\/h3>\n
\n
Strefa zagro\u017cenia: Co dzieje si\u0119 podczas migawki VM<\/h2>\n
Sp\u00f3jno\u015b\u0107 w przypadku awarii a sp\u00f3jno\u015b\u0107 aplikacji<\/h3>\n
Dysku D:<\/code>, a WAL na Dysku E:<\/code>), hiperwizor mo\u017ce nie wykona\u0107 migawki obu dysk\u00f3w w tej samej mikrosekundzie. Je\u015bli migawka dysku z WAL zostanie wykonana nawet u\u0142amek sekundy po migawce dysku z danymi, baza danych nie b\u0119dzie w stanie uzgodni\u0107 numer\u00f3w sekwencyjnych podczas przywracania, co doprowadzi do fatalnego uszkodzenia.<\/p>\nEfekt \u201eVM Stun\u201d w systemach o du\u017cej liczbie transakcji<\/h3>\n
\n* Po\u0142\u0105czenia sieciowe s\u0105 zrywane, co powoduje przekroczenie czasu oczekiwania aplikacji.
\n* Klastry wysokiej dost\u0119pno\u015bci (takie jak SQL Server Always On, PostgreSQL Patroni czy MySQL Galera) trac\u0105 sygna\u0142y kontrolne (heartbeat).
\n* Klaster mo\u017ce uzna\u0107 zamro\u017cony w\u0119ze\u0142 za martwy, wyzwalaj\u0105c niepotrzebne i zak\u0142\u00f3caj\u0105ce prac\u0119 prze\u0142\u0105czenie awaryjne (scenariusz split-brain).<\/p>\nPoszarpane strony (Torn Pages) i niedopasowanie I\/O<\/h3>\n
Rzeczywiste konsekwencje dla konkretnych silnik\u00f3w baz danych<\/h2>\n
\n
pg_wal<\/code>. Je\u015bli migawka uchwyci katalog danych ($PGDATA<\/code>) i WAL w spos\u00f3b niesynchronizowany, PostgreSQL nie uruchomi si\u0119, zg\u0142aszaj\u0105c b\u0142\u0105d PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> i ib_logfile<\/code> zostan\u0105 uchwycone w spos\u00f3b niesynchronizowany, silnik InnoDB ulegnie awarii podczas odzyskiwania.<\/li>\nNajlepsze praktyki bezpiecznego tworzenia kopii zapasowych zwirtualizowanych baz danych<\/h2>\n
1. Wykorzystaj mechanizmy quiescingu \u015bwiadome aplikacji (VSS i fsfreeze)<\/h3>\n
\nZawsze upewnij si\u0119, \u017ce Twoje rozwi\u0105zanie do tworzenia kopii zapasowych wykorzystuje us\u0142ug\u0119 Microsoft Volume Shadow Copy Service (VSS). Gdy wyzwalana jest kopia zapasowa obs\u0142uguj\u0105ca VSS, SQL Server VSS Writer zamra\u017ca operacje I\/O bazy danych, opr\u00f3\u017cnia oczekuj\u0105ce transakcje na dysk i zapewnia, \u017ce migawka jest w pe\u0142ni sp\u00f3jna z aplikacj\u0105.<\/p>\n
\nLinux nie posiada natywnego odpowiednika VSS. Aby osi\u0105gn\u0105\u0107 sp\u00f3jno\u015b\u0107 aplikacji, nale\u017cy u\u017cy\u0107 skrypt\u00f3w pre-freeze i post-thaw w po\u0142\u0105czeniu z narz\u0119dziami go\u015bcia hiperwizora (np. VMware Tools).<\/p>\npre-freeze-script<\/code> dla PostgreSQL 15+, kt\u00f3ry bezpiecznie przygotowuje baz\u0119 danych do migawki:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Upewnij si\u0119, \u017ce ten skrypt jest wykonywalny (chmod +x)\n\n# 1. Poinformuj PostgreSQL o przygotowaniu do kopii zapasowej\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Opr\u00f3\u017cnij bufory systemu plik\u00f3w na dysk\nsync\n\n# 3. Zamro\u017a system plik\u00f3w (zak\u0142adaj\u0105c, \u017ce dane s\u0105 w \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code>, aby wznowi\u0107 operacje:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Odmro\u017a system plik\u00f3w\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Poinformuj PostgreSQL, \u017ce kopia zapasowa zosta\u0142a zako\u0144czona\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. U\u017cywaj natywnych narz\u0119dzi do tworzenia kopii zapasowych baz danych<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nNarz\u0119dzia te wykonuj\u0105 \u201egor\u0105ce\u201d, nieblokuj\u0105ce kopie zapasowe poprzez kopiowanie plik\u00f3w danych i jednoczesne \u015bledzenie zmian w dzienniku redo.<\/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. Wdr\u00f3\u017c odzyskiwanie do punktu w czasie (PITR) poprzez archiwizacj\u0119 dziennik\u00f3w<\/h3>\n
Strategie tworzenia kopii zapasowych klasy korporacyjnej z CloudSave<\/h2>\n
\n1. Komunikuje si\u0119 bezpo\u015brednio z silnikiem bazy danych za pomoc\u0105 natywnych interfejs\u00f3w API (takich jak VSS dla Windows lub natywne strumieniowanie WAL dla Linux).
\n2. Orkiestruje opr\u00f3\u017cnianie bufor\u00f3w pami\u0119ci na dysk bez powodowania zak\u0142\u00f3caj\u0105cych prac\u0119 zamro\u017ce\u0144 VM.
\n3. Bezpiecznie przechwytuje pliki danych i automatycznie zarz\u0105dza obcinaniem dziennik\u00f3w transakcji.
\n4. Ci\u0105gle tworzy kopie zapasowe dziennik\u00f3w transakcji, umo\u017cliwiaj\u0105c granularne odzyskiwanie do punktu w czasie (PITR) za pomoc\u0105 kilku klikni\u0119\u0107.<\/p>\nWniosek<\/h2>\n