قاتل خاموش: چگونه پیش از وقوع فاجعه، نسخه‌های پشتیبان آسیب‌دیده پایگاه داده را شناسایی کنیم

در دنیای پرمخاطره مدیریت پایگاه داده و مهندسی قابلیت اطمینان سایت (SRE)، یک اصل شناخته‌شده وجود دارد: نسخه پشتیبان شرودینگر. وضعیت هر نسخه پشتیبان تا زمانی که برای بازیابی آن اقدام نکنید، نامشخص است. تا آن لحظه، این نسخه در یک حالت کوانتومی قرار دارد که هم کاملاً سالم و هم کاملاً آسیب‌دیده است.

برای مهندسان DevOps و مدیران پایگاه داده (DBA)، کشف اینکه یک نسخه پشتیبان حیاتی در حین یک حادثه فعال آسیب دیده است، کابوس نهایی است. این اتفاق یک عملیات بازیابی معمولی را به یک فاجعه از دست دادن داده تبدیل می‌کند. این «قاتل خاموش» یکپارچگی داده‌ها اغلب نادیده گرفته می‌شود، زیرا کارهای پشتیبان‌گیری معمولاً حتی زمانی که محتوای اصلی به خطر افتاده است، Exit Code 0 (موفقیت‌آمیز) را گزارش می‌کنند.

در این راهنمای جامع، ما کالبدشکافی خرابی نسخه پشتیبان را بررسی می‌کنیم، تکنیک‌های اعتبارسنجی خاص پایگاه داده را می‌شناسیم و نشان می‌دهیم که چگونه خط لوله‌های بازیابی خودکار و ضدگلوله برای محیط‌های تولید ایجاد کنید.

کالبدشکافی خرابی نسخه پشتیبان

برای تشخیص خرابی، ابتدا باید درک کنید که چگونه رخ می‌دهد. خرابی نسخه پشتیبان معمولاً در دو دسته قرار می‌گیرد: فیزیکی (سطح زیرساخت) و منطقی (سطح برنامه).

خرابی فیزیکی

خرابی فیزیکی زمانی رخ می‌دهد که بیت‌های واقعی روی رسانه ذخیره‌سازی تغییر کنند. این اتفاق می‌تواند در حین فرآیند خواندن از دیسک منبع، در حین انتقال شبکه یا در حالت استراحت روی ذخیره‌ساز مقصد رخ دهد.
* پوسیدگی بیت (Bit Rot): تخریب تدریجی رسانه‌های ذخیره‌سازی می‌تواند بیت‌ها را به‌طور خاموش تغییر دهد.
* خطاهای انتقال: اگرچه TCP دارای چک‌سام است، اما این چک‌سام‌ها به‌طور بدنامی ضعیف هستند (۱۶ بیتی). محیط‌های با توان عملیاتی بالا می‌توانند دچار خرابی خاموش داده‌ها در حین انتقال شوند که TCP قادر به تشخیص آن نیست.
* خطاهای کنترلر ذخیره‌سازی: باگ‌های سخت‌افزاری در کنترلرهای RAID یا شبکه‌های SAN می‌توانند داده‌های نامعتبر بنویسند در حالی که موفقیت را به سیستم‌عامل گزارش می‌دهند.

خرابی منطقی

خرابی منطقی احتمالاً خطرناک‌تر است زیرا خود فایل پشتیبان کاملاً سالم است، اما داده‌های داخل آن خراب هستند.
* ورودی نامعتبر، خروجی نامعتبر (GIGO): اگر پایگاه داده زنده شما دارای یک ایندکس خراب یا یک صفحه آسیب‌دیده باشد، ابزار پشتیبان‌گیری شما ممکن است صادقانه همان صفحه خراب را کپی کند. کار پشتیبان‌گیری موفقیت‌آمیز است، اما بازیابی شکست می‌خورد یا یک پایگاه داده خراب تحویل می‌دهد.
* تراکنش‌های ناقص: اسنپ‌شات‌های سطح فایل‌سیستم که بدون مسدود کردن صحیح ورودی/خروجی پایگاه داده گرفته می‌شوند (مثلاً عدم استفاده از FLUSH TABLES WITH READ LOCK در MySQL)، منجر به صفحات آسیب‌دیده و وضعیت‌های غیرقابل بازیابی می‌شوند.

تشخیص پیشگیرانه: چک‌سام‌ها و هشینگ رمزنگاری

اولین خط دفاعی در برابر خرابی فیزیکی، اعتبارسنجی رمزنگاری است. تکیه بر اندازه فایل یا تاریخ‌های اصلاح کافی نیست.

فعال‌سازی چک‌سام‌های سطح پایگاه داده

سیستم‌های مدیریت پایگاه داده رابطه‌ای (RDBMS) مدرن از چک‌سام‌های سطح صفحه پشتیبانی می‌کنند. هنگامی که فعال باشد، پایگاه داده قبل از نوشتن هر صفحه روی دیسک، یک چک‌سام برای آن محاسبه می‌کند. هنگامی که صفحه خوانده می‌شود (چه توسط یک پرس‌وجو یا یک فرآیند پشتیبان‌گیری)، چک‌سام تأیید می‌شود.

برای PostgreSQL، می‌توانید چک‌سام‌های داده را در حین مقداردهی اولیه کلاستر فعال کنید:

# مقداردهی اولیه یک کلاستر جدید PostgreSQL با چک‌سام‌های فعال
initdb --data-checksums -D /var/lib/postgresql/data

نکته: اگر یک کلاستر PostgreSQL موجود دارید، می‌توانید از ابزار pg_checksums برای فعال‌سازی آن‌ها به‌صورت آفلاین استفاده کنید.

برای Microsoft SQL Server، اطمینان حاصل کنید که PAGE_VERIFY روی CHECKSUM تنظیم شده باشد (در نسخه‌های مدرن پیش‌فرض است، اما ارزش بررسی در سیستم‌های قدیمی را دارد):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

اعتبارسنجی نسخه‌های پشتیبان در حالت استراحت

هنگامی که نسخه پشتیبان روی مقصد ذخیره‌سازی شما قرار می‌گیرد، یکپارچگی آن باید به‌صورت رمزنگاری تأیید شود. پلتفرم‌های پشتیبان‌گیری سازمانی مانند CloudSave به‌طور خودکار هش‌های SHA-256 بلوک‌های پشتیبان را در حین انتقال و در حالت استراحت محاسبه و تأیید می‌کنند. اگر اسکریپت‌های سفارشی را مدیریت می‌کنید، باید این کار را به‌صورت دستی پیاده‌سازی کنید:

# تولید هش SHA-256 پس از ایجاد نسخه پشتیبان
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# تأیید هش روی سرور ذخیره‌سازی
sha256sum -c prod_db_backup.tar.gz.sha256

تکنیک‌های اعتبارسنجی خاص پایگاه داده

موتورهای مختلف پایگاه داده ابزارهای بومی برای تأیید یکپارچگی مصنوعات پشتیبان خود ارائه می‌دهند.

PostgreSQL: pg_verifybackup

ابزار pg_verifybackup که در PostgreSQL 13 معرفی شد، یک تغییر بزرگ برای پشتیبان‌گیری‌های فیزیکی گرفته شده با pg_basebackup است. این ابزار فایل backup_manifest تولید شده در حین پشتیبان‌گیری را می‌خواند و تأیید می‌کند که همه فایل‌ها موجود هستند و چک‌سام‌های آن‌ها مطابقت دارند.

# اجرای تأیید روی یک دایرکتوری پشتیبان فیزیکی
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

اگر حتی یک بیت در هر یک از فایل‌های داده تغییر کرده باشد، pg_verifybackup یک خطای مهلک ایجاد می‌کند و به سیستم‌های مانیتورینگ شما اجازه می‌دهد بلافاصله به تیم DBA هشدار دهند.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server یک دستور بومی برای تأیید یکپارچگی فیزیکی یک فایل پشتیبان بدون بازیابی واقعی آن ارائه می‌دهد. این دستور هدرهای پشتیبان را بررسی کرده و چک‌سام‌های صفحه را (اگر در حین پشتیبان‌گیری فعال شده باشند) تأیید می‌کند.

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

هشدار: RESTORE VERIFYONLY فقط تأیید می‌کند که فایل پشتیبان قابل خواندن است و چک‌سام‌های فیزیکی مطابقت دارند. این دستور یکپارچگی منطقی را تضمین نمی‌کند. برای اطمینان از یکپارچگی منطقی، باید یک بازیابی کامل انجام دهید و DBCC CHECKDB را اجرا کنید.

MySQL / InnoDB: Percona XtraBackup

برای محیط‌های MySQL، پشتیبان‌گیری‌های فیزیکی اغلب توسط Percona XtraBackup انجام می‌شود. فرآیند پشتیبان‌گیری شامل کپی کردن فایل‌ها است، اما پشتیبان تا زمانی که لاگ‌های تراکنش (redo logs) اعمال نشوند، سازگار نیست. مرحله --prepare به‌عنوان یک بررسی یکپارچگی داخلی عمل می‌کند.

# آماده‌سازی نسخه پشتیبان، لاگ‌های redo را اعمال می‌کند. 
# اگر نسخه پشتیبان خراب باشد، این مرحله شکست می‌خورد.
xtrabackup --prepare --target-dir=/data/backups/mysql/

استاندارد طلایی: تست بازیابی خودکار

چک‌سام‌ها و دستورات تأیید ضروری هستند، اما کافی نیستند. تنها راه برای اثبات قطعی قابل استفاده بودن یک نسخه پشتیبان، بازیابی آن است. در محیط‌های مدرن DevOps، این فرآیند باید کاملاً خودکار باشد.

با برخورد با نسخه‌های پشتیبان به عنوان کد، می‌توانید یک خط لوله CI/CD برای بازیابی پایگاه داده خود بسازید. این خط لوله باید زیرساخت‌های موقت را فراهم کند، بازیابی را اجرا کند، پرس‌وجوهای اعتبارسنجی را انجام دهد و محیط را پاکسازی کند.

ساخت خط لوله بازیابی خودکار

در زیر نمونه‌ای از یک اسکریپت Bash آورده شده است که می‌تواند روزانه توسط یک cron job یا یک CI runner (مانند GitLab CI یا GitHub Actions) برای اعتبارسنجی یک دامپ منطقی PostgreSQL اجرا شود.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] شروع تست بازیابی خودکار..."

# 1. راه‌اندازی یک کانتینر موقت PostgreSQL
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# انتظار برای آماده شدن PostgreSQL
echo "[INFO] در حال انتظار برای مقداردهی اولیه پایگاه داده..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. ایجاد پایگاه داده مقصد
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. اجرای بازیابی
echo "[INFO] در حال بازیابی نسخه پشتیبان..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. اجرای پرس‌وجوهای اعتبارسنجی منطقی
echo "[INFO] در حال اجرای پرس‌وجوهای اعتبارسنجی..."
# بررسی اینکه آیا جدول کاربران بیش از 10,000 رکورد دارد
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] اعتبارسنجی منطقی شکست خورد. انتظار بیش از 10000 کاربر می‌رفت، اما $USER_COUNT یافت شد."
    # در اینجا هشدار PagerDuty / Slack را فعال کنید
    exit 1
else
    echo "[SUCCESS] اعتبارسنجی منطقی با موفقیت انجام شد. تعداد کاربران: $USER_COUNT"
fi

# 5. پاکسازی محیط موقت
echo "[INFO] در حال پاکسازی..."
docker rm -f $CONTAINER_NAME

echo "[INFO] تست بازیابی خودکار با موفقیت به پایان رسید."

چه چیزی را باید اعتبارسنجی کنید؟

هنگام انجام تست بازیابی خودکار، فقط بررسی نکنید که آیا پایگاه داده بالا می‌آید یا خیر. پرس‌وجوهای اعتبارسنجی خاص برنامه را اجرا کنید:
1. تعداد ردیف‌ها: اطمینان حاصل کنید که جداول اصلی دارای تعداد ردیف‌های مورد انتظار هستند (مثلاً جدول users نباید خالی باشد).
2. داده‌های اخیر: برای رکوردهایی که در 24 ساعت گذشته ایجاد شده‌اند پرس‌وجو کنید تا مطمئن شوید نسخه پشتیبان قدیمی نیست.
3. یکپارچگی ارجاعی: اسکریپت‌هایی را برای بررسی کلیدهای خارجی یتیم اجرا کنید که نشان‌دهنده خرابی منطقی هستند.

مانیتورینگ و هشدار برای ناهنجاری‌های پشتیبان‌گیری

تشخیص خرابی قبل از وقوع فاجعه نیازمند مشاهده‌پذیری قوی است. فراتر از وضعیت‌های باینری موفقیت/شکست، باید متادیتای کارهای پشتیبان‌گیری خود را برای تشخیص ناهنجاری‌ها مانیتور کنید.

مانیتورینگ اکتشافی (Heuristic)

متادیتای پشتیبان‌گیری خود را در Prometheus ادغام کرده و با Grafana تجسم کنید. برای موارد اکتشافی زیر هشدار تنظیم کنید:
* کاهش ناگهانی اندازه: اگر نسخه پشتیبان روزانه شما به‌طور مداوم 500 گیگابایت است و نسخه امروز 50 مگابایت است، ممکن است کار با موفقیت (Exit Code 0) به پایان رسیده باشد، اما احتمالاً یک شمای خالی را پشتیبان‌گیری کرده است.
* ناهنجاری‌های مدت زمان: اگر پشتیبان‌گیری که معمولاً 2 ساعت طول می‌کشد در 5 دقیقه تمام شود، چیزی نادیده گرفته شده است. برعکس، اگر 10 ساعت طول بکشد، ممکن است دچار افت عملکرد ورودی/خروجی دیسک باشید که می‌تواند منجر به خرابی شود.
* تجمع لاگ‌های WAL/Archive: اگر پایگاه داده شما در حال تولید لاگ‌های Write-Ahead (WAL) است اما سیستم پشتیبان‌گیری آن‌ها را به اندازه کافی سریع آرشیو نمی‌کند، خطر ایجاد شکاف در زنجیره بازیابی در لحظه (PITR) وجود دارد.

پیاده‌سازی قانون 3-2-1 با بررسی‌های یکپارچگی

قانون استاندارد صنعت 3-2-1 برای پشتیبان‌گیری (3 نسخه از داده، 2 رسانه مختلف، 1 نسخه خارج از سایت) تنها در صورتی مؤثر است که همه نسخه‌ها تأیید شوند.

اینجاست که استفاده از یک راهکار سازمانی مانند CloudSave هزینه‌های عملیاتی را به‌شدت کاهش می‌دهد. به‌جای نوشتن و نگهداری اسکریپت‌های پیچیده bash برای هر نود پایگاه داده، CloudSave مستقیماً با زیرساخت شما ادغام می‌شود تا چرخه حیات 3-2-1 را خودکار کند. این سرویس ذخیره‌سازی غیرقابل تغییر (Immutable) را فراهم می‌کند—که در برابر باج‌افزار محافظت می‌کند—و دارای برنامه‌های زمان‌بندی داخلی و خودکار برای تأیید بازیابی است. CloudSave می‌تواند به‌طور خودکار محیط‌های سندباکس ایزوله را راه‌اندازی کند، نسخه پشتیبان را مونت کند، اسکریپت‌های اعتبارسنجی SQL سفارشی شما را اجرا کند و وضعیت سلامت را به داشبورد مرکزی شما گزارش دهد.

نتیجه‌گیری

نسخه‌های پشتیبان خراب پایگاه داده یک قاتل خاموش هستند که می‌توانند کسب‌وکارها را نابود کنند. تکیه صرف بر Exit Code 0 یک اسکریپت پشتیبان‌گیری، یک قمار خطرناک است.

برای محافظت واقعی از محیط‌های تولید خود، باید یک استراتژی دفاع در عمق اتخاذ کنید:
1. چک‌سام‌های سطح صفحه را در موتور پایگاه داده خود فعال کنید.
2. از ابزارهای تأیید بومی (pg_verifybackup، RESTORE VERIFYONLY) بلافاصله پس از ایجاد نسخه پشتیبان استفاده کنید.
3. متادیتای پشتیبان‌گیری (اندازه، مدت زمان) را برای ناهنجاری‌های اکتشافی مانیتور کنید.
4. تست بازیابی خودکار و موقت را به‌عنوان بخشی از خط لوله عملیاتی روزانه خود پیاده‌سازی کنید.

با تغییر از ذهنیت منفعل «بگیر و فراموش کن» به مدل فعال «اعتبارسنجی مداوم بازیابی»، اطمینان حاصل می‌کنید که وقتی فاجعه اجتناب‌ناپذیر رخ می‌دهد، داده‌های شما آماده، قابل اعتماد و کاملاً قابل بازیابی هستند.