برای مهندسان DevOps و مدیران سیستم، اسنپشاتهای ماشین مجازی (VM) یک ابزار بنیادی هستند. آنها روشی سریع و راحت برای ثبت وضعیت سرور پیش از اعمال یک وصله پرخطر، تغییر پیکربندی عمده یا استقرار یک برنامه فراهم میکنند. اگر مشکلی پیش بیاید، بازگردانی (Rollback) تنها چند ثانیه طول میکشد.
با این حال، هنگامی که همین روششناسی برای پایگاههای داده تراکنشی—مانند PostgreSQL، MySQL، Oracle یا Microsoft SQL Server—بهکار میرود، اسنپشاتهای VM از یک لایه امنیتی به یک بمب ساعتی تبدیل میشوند.
تکیه بر اسنپشاتهای استاندارد هایپروایزر برای پشتیبانگیری از پایگاه داده، یکی از رایجترین دلایل خرابی دادهها، صفحات ناقص (Torn Pages) و قطعیهای غیرقابل بازیابی در محیط عملیاتی است. در این مقاله، ما به بررسی تضاد معماری بین هایپروایزرها و موتورهای پایگاه داده، مکانیسم خرابی دادهها در حین اسنپشاتگیری و بهترین شیوههای مهندسی مورد نیاز برای پشتیبانگیری ایمن از پایگاههای داده مجازیسازی شده میپردازیم.
تضاد معماری: هایپروایزرها در مقابل موتورهای پایگاه داده
برای درک اینکه چرا اسنپشاتهای VM پایگاههای داده را به خطر میاندازند، ابتدا باید بررسی کنیم که هر دو سیستم چگونه وضعیت و عملیات I/O را مدیریت میکنند.
هایپروایزرها چگونه اسنپشات میگیرند
هنگامی که یک هایپروایزر (مانند VMware ESXi، Microsoft Hyper-V یا KVM) یک اسنپشات میگیرد، دیسک را کپی نمیکند. در عوض، فایل دیسک مجازی فعلی (مثلاً .vmdk یا .vhdx) را در وضعیت «فقط خواندنی» منجمد کرده و یک دیسک دلتای جدید (دیسک تفاضلی) ایجاد میکند. تمام نوشتنهای بعدی به این دیسک دلتا هدایت میشوند.
هنگامی که اسنپشات حذف میشود، هایپروایزر باید دادهها را از دیسک دلتا به دیسک اصلی منتقل (ادغام) کند. اسنپشاتهای استاندارد کاملاً از برنامههای در حال اجرا در سیستمعامل مهمان بیاطلاع هستند. آنها وضعیت دیسک را دقیقاً همانطور که در آن میکروثانیه وجود دارد، ثبت میکنند.
پایگاههای داده تراکنشی چگونه وضعیت را مدیریت میکنند
پایگاههای داده تراکنشی بر اساس ویژگیهای ACID (اتمی بودن، سازگاری، جداسازی، پایداری) طراحی شدهاند. برای دستیابی به عملکرد بالا و در عین حال حفظ انطباق با ACID، پایگاههای داده هر تراکنش را بلافاصله مستقیماً در فایلهای داده اصلی روی دیسک نمینویسند. در عوض، آنها از یک معماری پیچیده و چندلایه استفاده میکنند:
- استخر بافر / بافرهای اشتراکی: دادهها در حافظه سیستم خوانده و اصلاح میشوند.
- لاگ پیشنویس (WAL) / لاگهای بازنویسی (Redo Logs): تغییرات بهصورت ترتیبی در یک فایل لاگ بسیار بهینه روی دیسک نوشته میشوند تا پایداری تضمین شود.
- نقاط بازرسی (Checkpoints) / نویسندههای تنبل (Lazy Writers): بهطور دورهای، پایگاه داده صفحات اصلاحشده (کثیف) را از حافظه به فایلهای داده واقعی روی دیسک منتقل میکند.
به دلیل این معماری، فایلهای داده فیزیکی روی دیسک تقریباً همیشه با وضعیت واقعی پایگاه داده همگام نیستند. وضعیت واقعی پایگاه داده تنها ترکیبی از فایلهای داده روی دیسک، لاگهای WAL/Redo و دادههای موجود در حافظه است.
منطقه خطر: در حین اسنپشات VM چه اتفاقی میافتد
هنگامی که از یک سرور پایگاه داده اسنپشات VM استاندارد میگیرید، در حال ثبت وضعیتی هستید که تنها در صورت کرش کردن سیستم سازگار است (Crash-consistent).
سازگاری در زمان کرش در مقابل سازگاری در سطح برنامه
اسنپشات Crash-consistent معادل کشیدن کابل برق از سرور فیزیکی است. وضعیت دیسک ثبت میشود، اما هر آنچه در حافظه بوده از دست میرود و هر آنچه در حال انتقال به کنترلر ذخیرهسازی بوده، بهطور ناگهانی قطع میشود.
اگرچه پایگاههای داده مدرن برای بازیابی از قطع ناگهانی برق با بازپخش لاگ پیشنویس (WAL) طراحی شدهاند، تکیه بر بازیابی پس از کرش بهعنوان استراتژی اصلی پشتیبانگیری بسیار خطرناک است. اگر پایگاه داده شما چندین دیسک مجازی را در بر بگیرد (مثلاً فایلهای داده در Drive D: و WAL در Drive E:)، ممکن است هایپروایزر هر دو دیسک را در یک میکروثانیه دقیق اسنپشات نکند. اگر اسنپشات دیسک WAL حتی کسری از ثانیه بعد از اسنپشات دیسک داده گرفته شود، پایگاه داده نمیتواند شمارههای توالی را هنگام بازیابی تطبیق دهد که منجر به خرابی مهلک میشود.
اثر «VM Stun» بر سیستمهای با تراکنش بالا
فرآیند ایجاد اسنپشات—و مهمتر از آن، فرآیند ادغام اسنپشات—پدیدهای به نام «VM Stun» (توقف ماشین مجازی) ایجاد میکند.
برای تغییر ایمن I/O از دیسک پایه به دیسک دلتا، هایپروایزر باید ماشین مجازی را بهطور مختصر متوقف (Stun) کند. برای یک وبسرور با بار کم، این توقف ممکن است ۱۰ تا ۵۰ میلیثانیه طول بکشد و محسوس نباشد. با این حال، برای یک پایگاه داده با توان عملیاتی بالا و I/O سنگین، ادغام یک دیسک دلتای بزرگ میتواند VM را برای چندین ثانیه متوقف کند.
در طول یک VM Stun:
* اتصالات شبکه قطع میشوند که باعث ایجاد وقفه (Timeout) در برنامهها میشود.
* خوشههای با دسترسپذیری بالا (مانند SQL Server Always On، PostgreSQL Patroni یا MySQL Galera) بررسیهای ضربان قلب (Heartbeat) را از دست میدهند.
* خوشه ممکن است فرض کند گره متوقفشده از کار افتاده است و یک Failover غیرضروری و مخرب (سناریوی مغزهای جداگانه یا Split-brain) را تحریک کند.
صفحات ناقص (Torn Pages) و عدم تراز I/O
موتورهای پایگاه داده معمولاً دادهها را در اندازههای صفحه خاصی مینویسند (مثلاً ۸ کیلوبایت برای PostgreSQL و SQL Server، ۱۶ کیلوبایت برای InnoDB). با این حال، سیستمعامل و آرایههای ذخیرهسازی زیرین، I/O را در بلوکهای کوچکتر (مثلاً ۴ کیلوبایت یا ۵۱۲ بایت) پردازش میکنند.
اگر یک هایپروایزر دقیقاً زمانی که پایگاه داده در حال نوشتن یک صفحه ۸ کیلوبایتی است اسنپشات بگیرد، ممکن است ۴ کیلوبایت اول دادههای جدید و ۴ کیلوبایت آخر دادههای قدیمی را ثبت کند. این یک صفحه ناقص (Torn Page) ایجاد میکند. هنگامی که سعی میکنید اسنپشات را بازیابی کنید، پایگاه داده صفحه را میخواند، اعتبارسنجی چکسام شکست میخورد و پایگاه داده بهعنوان خراب علامتگذاری میشود.
پیامدهای دنیای واقعی برای موتورهای پایگاه داده خاص
موتورهای مختلف پایگاه داده به روشهای گوناگونی به اسنپشاتهای Crash-consistent واکنش نشان میدهند، اما هیچکدام در محیط عملیاتی بهخوبی با آن برخورد نمیکنند.
- PostgreSQL: این پایگاه داده بهشدت به دایرکتوری
pg_walوابسته است. اگر اسنپشات دایرکتوری داده ($PGDATA) و WAL را بهصورت غیرهمگام ثبت کند، PostgreSQL در شروع کار شکست میخورد و خطایPANIC: could not locate a valid checkpoint recordرا نمایش میدهد. - MySQL/InnoDB: این موتور از یک بافر doublewrite برای جلوگیری از صفحات ناقص استفاده میکند که محافظتی در برابر وضعیتهای Crash-consistent ارائه میدهد. با این حال، اگر فایل
ibdata1وib_logfileبهصورت غیرهمگام ثبت شوند، موتور InnoDB هنگام بازیابی کرش میکند. - Microsoft SQL Server: این پایگاه داده به انجماد I/O بسیار حساس است. بدون ادغام مناسب با VSS (سرویس کپی سایه حجم)، بازیابی SQL Server از یک اسنپشات استاندارد VM اغلب منجر به مشکوک شدن پایگاههای داده و شکستن زنجیرههای لاگ میشود که قابلیتهای بازیابی در زمان (PITR) شما را از بین میبرد.
بهترین شیوهها برای پشتیبانگیری ایمن از پایگاههای داده مجازیسازی شده
برای محافظت از پایگاههای داده تراکنشی، باید از پشتیبانگیریهای Crash-consistent به سمت پشتیبانگیریهای سازگار با برنامه (Application-consistent) حرکت کنید. این امر مستلزم آن است که مکانیسم پشتیبانگیری با موتور پایگاه داده ارتباط برقرار کند و آن را مجبور کند حافظه را به دیسک تخلیه کرده و عملیات I/O را در حین گرفتن اسنپشات بهطور لحظهای متوقف کند.
۱. بهرهگیری از Quiescing آگاه از برنامه (VSS و fsfreeze)
برای ویندوز (SQL Server):
همیشه اطمینان حاصل کنید که راهکار پشتیبانگیری شما از سرویس کپی سایه حجم مایکروسافت (VSS) استفاده میکند. هنگامی که یک پشتیبانگیری آگاه از VSS فعال میشود، VSS Writer مربوط به SQL Server عملیات I/O پایگاه داده را منجمد کرده، تراکنشهای معلق را به دیسک تخلیه میکند و اطمینان حاصل میکند که اسنپشات کاملاً با برنامه سازگار است.
برای لینوکس (PostgreSQL / MySQL):
لینوکس معادل بومی برای VSS ندارد. برای دستیابی به سازگاری با برنامه، باید از اسکریپتهای pre-freeze و post-thaw در کنار ابزارهای مهمان هایپروایزر (مانند VMware Tools) استفاده کنید.
در اینجا نمونهای از یک pre-freeze-script در VMware برای PostgreSQL 15+ آورده شده است که پایگاه داده را بهطور ایمن برای اسنپشات آماده میکند:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Ensure this script is executable (chmod +x)
# 1. Tell PostgreSQL to prepare for a backup
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Flush file system buffers to disk
sync
# 3. Freeze the file system (assuming data is on /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
و post-thaw-script مربوطه برای از سرگیری عملیات:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Unfreeze the file system
fsfreeze -u /var/lib/pgsql
# 2. Tell PostgreSQL the backup is complete
su - postgres -c "psql -c "SELECT pg_backup_stop();""
۲. استفاده از ابزارهای پشتیبانگیری بومی پایگاه داده
اگرچه اسنپشاتهای سازگار با برنامه بهتر از اسنپشاتهای استاندارد هستند، اما همچنان خطر VM Stun را به همراه دارند. ایمنترین روش برای پشتیبانگیری از پایگاه داده، استفاده از ابزارهای پشتیبانگیری جریانی (Streaming) بومی است که مستقل از هایپروایزر عمل میکنند.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
این ابزارها با کپی کردن فایلهای داده و ردیابی همزمان تغییرات در لاگ بازنویسی (Redo Log)، پشتیبانگیریهای داغ و غیرمسدودکننده انجام میدهند.
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
۳. پیادهسازی بازیابی در زمان (PITR) از طریق آرشیو لاگ
یک اسنپشات روزانه یا پشتیبانگیری کامل فقط تا لحظهای که گرفته شده از شما محافظت میکند. اگر پایگاه داده شما ساعت ۴:۰۰ بعدازظهر کرش کند و آخرین اسنپشات شما ساعت ۲:۰۰ بامداد باشد، ۱۴ ساعت دادههای تراکنشی را از دست میدهید.
برای دستیابی به تابآوری واقعی در سطح سازمانی، باید پشتیبانگیریهای کامل سازگار با برنامه را با آرشیو مداوم لاگ (پشتیبانگیری از WAL، لاگهای بازنویسی یا لاگهای تراکنش هر چند دقیقه یکبار) ترکیب کنید. این به مدیران پایگاه داده اجازه میدهد تا پایگاه داده را به یک دقیقه خاص یا حتی یک شناسه تراکنش خاص پیش از فاجعه بازیابی کنند.
استراتژیهای پشتیبانگیری سازمانی با CloudSave
مدیریت اسکریپتهای سفارشی pre-freeze، کارهای زمانبندی شده (cron jobs) برای دامپهای بومی و ارسال لاگ در دهها سرور پایگاه داده، یک کابوس عملیاتی برای تیمهای DevOps است. اینجاست که یک پلتفرم در سطح سازمانی مانند CloudSave حیاتی میشود.
CloudSave شکاف بین مجازیسازی و معماری پایگاه داده را پر میکند. بهجای تکیه بر اسنپشاتهای کورکورانه هایپروایزر، CloudSave از عوامل (Agents) آگاه از برنامه استفاده میکند که بهصورت بومی با SQL Server، PostgreSQL، MySQL و Oracle یکپارچه میشوند.
هنگامی که CloudSave یک پشتیبانگیری را آغاز میکند:
۱. مستقیماً از طریق APIهای بومی (مانند VSS برای ویندوز یا استریمینگ بومی WAL برای لینوکس) با موتور پایگاه داده ارتباط برقرار میکند.
۲. تخلیه بافرهای حافظه به دیسک را بدون ایجاد توقفهای مخرب VM مدیریت میکند.
۳. فایلهای داده را بهطور ایمن ثبت کرده و بهطور خودکار کوتاه کردن (Truncation) لاگهای تراکنش را مدیریت میکند.
۴. بهطور مداوم از لاگهای تراکنش پشتیبانگیری میکند و امکان بازیابی دقیق در زمان (PITR) را با چند کلیک فراهم میسازد.
با برونسپاری پیچیدگی سازگاری با برنامه به CloudSave، مدیران پایگاه داده و مدیران سیستم میتوانند یکپارچگی دادهها را بدون قربانی کردن عملکرد یا دسترسپذیری خوشههای عملیاتی خود تضمین کنند.
نتیجهگیری
اسنپشاتهای ماشین مجازی ابزاری فوقالعاده برای مدیریت زیرساخت هستند، اما اساساً با الزامات ACID پایگاههای داده تراکنشی ناسازگارند. تکیه بر اسنپشاتهای Crash-consistent هایپروایزر، سازمان شما را در معرض صفحات ناقص، زنجیرههای همانندسازی شکسته و از دست دادن فاجعهبار دادهها قرار میدهد.
برای محافظت از دادههای حیاتی خود، باید Quiescing آگاه از برنامه را پیادهسازی کنید، از روشهای پشتیبانگیری بومی پایگاه داده استفاده کنید و آرشیوهای مداوم لاگ تراکنش را نگهداری کنید. با اتخاذ راهکارهای پشتیبانگیری سازمانی هدفمند، میتوانید اطمینان حاصل کنید که پایگاههای داده شما بسیار در دسترس، کاملاً قابل بازیابی و کاملاً امن باقی میمانند.
