خاموش قاتل: تباہی سے پہلے کرپٹ ڈیٹا بیس بیک اپس کا پتہ کیسے لگائیں

ڈیٹا بیس ایڈمنسٹریشن اور سائٹ ریلائبلٹی انجینئرنگ کی دنیا میں، ایک مشہور اصول ہے: شروڈنگر کا بیک اپ (Schrödinger’s Backup)۔ کسی بھی بیک اپ کی حالت اس وقت تک نامعلوم ہوتی ہے جب تک آپ اسے بحال (restore) کرنے کی کوشش نہ کریں۔ اس لمحے تک، یہ ایک کوانٹم حالت میں موجود ہوتا ہے جہاں یہ مکمل طور پر درست بھی ہو سکتا ہے اور مکمل طور پر خراب بھی۔

DevOps انجینئرز اور DBAs کے لیے، کسی فعال حادثے کے دوران یہ دریافت کرنا کہ ڈیٹا بیس کا اہم بیک اپ خراب (corrupted) ہو چکا ہے، ایک ڈراؤنا خواب ہے۔ یہ معمول کے بحالی کے عمل کو ڈیٹا کے تباہ کن نقصان میں بدل دیتا ہے۔ ڈیٹا کی سالمیت کا یہ "خاموش قاتل” اکثر نظر انداز ہو جاتا ہے کیونکہ بیک اپ جابز اکثر Exit Code 0 کی کامیابی کی اطلاع دیتی ہیں، حالانکہ اصل ڈیٹا خراب ہو چکا ہوتا ہے۔

اس جامع گائیڈ میں، ہم بیک اپ کی خرابی کی وجوہات کا تجزیہ کریں گے، ڈیٹا بیس کے لیے مخصوص توثیقی تکنیکوں کا جائزہ لیں گے، اور یہ دکھائیں گے کہ پروڈکشن ماحول کے لیے خودکار اور فول پروف ریسٹور پائپ لائنز کیسے بنائی جاتی ہیں۔

بیک اپ کی خرابی کی وجوہات

خرابی کا پتہ لگانے کے لیے، آپ کو پہلے یہ سمجھنا ہوگا کہ یہ کیسے ہوتی ہے۔ بیک اپ کی خرابی عام طور پر دو اقسام میں آتی ہے: جسمانی (انفراسٹرکچر کی سطح پر) اور منطقی (ایپلیکیشن کی سطح پر)۔

جسمانی خرابی (Physical Corruption)

جسمانی خرابی تب ہوتی ہے جب اسٹوریج میڈیم پر موجود اصل بٹس تبدیل ہو جاتے ہیں۔ یہ سورس ڈسک سے پڑھنے کے عمل کے دوران، نیٹ ورک ٹرانزٹ کے دوران، یا ٹارگٹ اسٹوریج پر آرام کی حالت میں ہو سکتا ہے۔
* بٹ روٹ (Bit Rot): اسٹوریج میڈیا کا بتدریج خراب ہونا بٹس کو خاموشی سے تبدیل کر سکتا ہے۔
* ٹرانزٹ ایررز: اگرچہ TCP میں چیک سمز ہوتے ہیں، لیکن وہ بہت کمزور (16-bit) ہوتے ہیں۔ ہائی تھرو پٹ والے ماحول میں ڈیٹا کی خاموش خرابی ہو سکتی ہے جسے TCP پکڑنے میں ناکام رہتا ہے۔
* اسٹوریج کنٹرولر کی خرابیاں: RAID کنٹرولرز یا SAN فیبرکس میں ہارڈویئر کے مسائل OS کو کامیابی کی اطلاع دیتے ہوئے غلط ڈیٹا لکھ سکتے ہیں۔

منطقی خرابی (Logical Corruption)

منطقی خرابی زیادہ خطرناک ہے کیونکہ بیک اپ فائل خود تو بالکل ٹھیک ہوتی ہے، لیکن اس کے اندر موجود ڈیٹا ٹوٹ پھوٹ کا شکار ہوتا ہے۔
* کچرا اندر، کچرا باہر (GIGO): اگر آپ کے لائیو ڈیٹا بیس میں کوئی خراب انڈیکس یا ٹوٹا ہوا صفحہ ہے، تو آپ کا بیک اپ ٹول اس خراب صفحے کو ایمانداری سے کاپی کر سکتا ہے۔ بیک اپ جاب کامیاب ہو جاتی ہے، لیکن ریسٹور ناکام ہو جائے گا یا ایک ٹوٹا ہوا ڈیٹا بیس ملے گا۔
* نامکمل ٹرانزیکشنز: ڈیٹا بیس I/O کو صحیح طریقے سے منجمد کیے بغیر (مثلاً MySQL میں FLUSH TABLES WITH READ LOCK استعمال نہ کرنا) فائل سسٹم کی سطح پر لیے گئے اسنیپ شاٹس ٹوٹے ہوئے صفحات اور ناقابل بحالی حالت کا باعث بنتے ہیں۔

فعال سراغ رسانی: چیک سمز اور کرپٹوگرافک ہیشنگ

جسمانی خرابی کے خلاف دفاع کی پہلی لائن کرپٹوگرافک توثیق ہے۔ فائل کے سائز یا ترمیم کی تاریخوں پر انحصار کرنا ناکافی ہے۔

ڈیٹا بیس کی سطح پر چیک سمز کو فعال کرنا

جدید ریلیشنل ڈیٹا بیس مینجمنٹ سسٹمز (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

PostgreSQL 13 میں متعارف کرایا گیا، pg_verifybackup ان جسمانی بیک اپس کے لیے ایک گیم چینجر ہے جو pg_basebackup کے ساتھ لیے جاتے ہیں۔ یہ بیک اپ کے دوران تیار کردہ backup_manifest فائل کو پڑھتا ہے اور تصدیق کرتا ہے کہ تمام فائلیں موجود ہیں اور ان کے چیک سمز مماثل ہیں۔

# جسمانی بیس بیک اپ ڈائریکٹری کے خلاف تصدیق چلائیں
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

اگر ڈیٹا فائلوں میں سے کسی ایک میں بھی ایک بٹ تبدیل ہوا ہے، تو pg_verifybackup ایک مہلک خرابی (fatal error) دے گا، جس سے آپ کے مانیٹرنگ سسٹمز فوری طور پر 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 مرحلہ ایک بلٹ ان انٹیگریٹی چیک کے طور پر کام کرتا ہے۔

# بیک اپ تیار کرنے سے ریڈو لاگز لاگو ہوتے ہیں۔ 
# اگر بیک اپ خراب ہے، تو یہ مرحلہ ناکام ہو جائے گا۔
xtrabackup --prepare --target-dir=/data/backups/mysql/

گولڈ اسٹینڈرڈ: خودکار ریسٹور ٹیسٹنگ

چیک سمز اور تصدیقی کمانڈز ضروری ہیں، لیکن وہ کافی نہیں ہیں۔ بیک اپ کے قابل عمل ہونے کا حتمی ثبوت اسے بحال کرنا ہے۔ جدید DevOps ماحول میں، اس عمل کو مکمل طور پر خودکار ہونا چاہیے۔

بیک اپ کو کوڈ کے طور پر برت کر، آپ اپنے ڈیٹا بیس ریسٹورز کے لیے ایک CI/CD پائپ لائن بنا سکتے ہیں۔ اس پائپ لائن کو عارضی انفراسٹرکچر فراہم کرنا چاہیے، ریسٹور کو انجام دینا چاہیے، توثیقی استفسارات (validation queries) چلانے چاہئیں، اور ماحول کو ختم کرنا چاہیے۔

خودکار ریسٹور پائپ لائن بنانا

ذیل میں ایک Bash اسکرپٹ کی مثال ہے جسے روزانہ cron جاب یا CI رنر (جیسے 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. رو کاؤنٹس (Row Counts): یقینی بنائیں کہ بنیادی ٹیبلز میں متوقع تعداد میں روز موجود ہیں (مثلاً users ٹیبل خالی نہیں ہونا چاہیے)۔
2. حالیہ ڈیٹا: پچھلے 24 گھنٹوں میں بنائے گئے ریکارڈز کے لیے استفسار کریں تاکہ یہ یقینی بنایا جا سکے کہ بیک اپ پرانا نہیں ہے۔
3. ریفرنشل انٹیگریٹی: یتیم فارن کیز (orphaned foreign keys) کو چیک کرنے کے لیے اسکرپٹس چلائیں، جو منطقی خرابی کی نشاندہی کرتی ہیں۔

بیک اپ کی بے قاعدگیوں کے لیے مانیٹرنگ اور الرٹنگ

تباہی سے پہلے خرابی کا پتہ لگانے کے لیے مضبوط مشاہدہ (observability) کی ضرورت ہے۔ بائنری کامیابی/ناکامی کی حالتوں سے آگے، آپ کو بے قاعدگیوں کا پتہ لگانے کے لیے اپنی بیک اپ جابز کے میٹا ڈیٹا کی نگرانی کرنی چاہیے۔

ہیورسٹک مانیٹرنگ

اپنے بیک اپ میٹا ڈیٹا کو Prometheus میں ضم کریں اور اسے Grafana کے ساتھ ویژولائز کریں۔ درج ذیل ہیورسٹکس کے لیے الرٹس ترتیب دیں:
* سائز میں اچانک کمی: اگر آپ کا روزانہ کا بیک اپ مستقل طور پر 500GB ہے، اور آج کا بیک اپ 50MB ہے، تو جاب کامیابی سے مکمل ہو سکتی ہے (Exit Code 0)، لیکن امکان ہے کہ اس نے ایک خالی اسکیما کا بیک اپ لیا ہے۔
* دورانیے میں بے قاعدگی: اگر کوئی بیک اپ جو عام طور پر 2 گھنٹے لیتا ہے، 5 منٹ میں مکمل ہو جائے تو کچھ چھوٹ گیا ہے۔ اس کے برعکس، اگر یہ 10 گھنٹے لیتا ہے، تو آپ کو ڈسک I/O کی خرابی ہو سکتی ہے جو خرابی کا باعث بن سکتی ہے۔
* WAL/آرکائیو لاگ کا جمع ہونا: اگر آپ کا ڈیٹا بیس Write-Ahead Logs (WAL) تیار کر رہا ہے لیکن بیک اپ سسٹم انہیں کافی تیزی سے آرکائیو نہیں کر رہا ہے، تو آپ اپنی Point-in-Time Recovery (PITR) چین میں خلا کا خطرہ مول لے رہے ہیں۔

انٹیگریٹی چیکس کے ساتھ 3-2-1 اصول کا نفاذ

انڈسٹری کا معیاری 3-2-1 بیک اپ اصول (ڈیٹا کی 3 کاپیاں، 2 مختلف میڈیا، 1 آف سائٹ) تب ہی موثر ہے جب تمام کاپیوں کی تصدیق کی گئی ہو۔

یہیں پر CloudSave جیسے انٹرپرائز حل کا فائدہ اٹھانا آپریشنل بوجھ کو نمایاں طور پر کم کرتا ہے۔ ہر ڈیٹا بیس نوڈ کے لیے پیچیدہ بیش اسکرپٹس لکھنے اور برقرار رکھنے کے بجائے، CloudSave 3-2-1 لائف سائیکل کو خودکار کرنے کے لیے براہ راست آپ کے انفراسٹرکچر کے ساتھ ضم ہو جاتا ہے۔ یہ ناقابل تغیر اسٹوریج (immutable storage) فراہم کرتا ہے—رینسم ویئر سے تحفظ کے لیے—اور اس میں بلٹ ان، خودکار ریسٹور تصدیقی شیڈولز شامل ہیں۔ CloudSave خود بخود الگ تھلگ سینڈ باکس ماحول تیار کر سکتا ہے، بیک اپ ماؤنٹ کر سکتا ہے، آپ کے کسٹم SQL توثیقی اسکرپٹس چلا سکتا ہے، اور ہیلتھ اسٹیٹس کو آپ کے مرکزی ڈیش بورڈ پر رپورٹ کر سکتا ہے۔

نتیجہ

خراب ڈیٹا بیس بیک اپ ایک خاموش قاتل ہیں جو کاروبار کو تباہ کر سکتے ہیں۔ صرف بیک اپ اسکرپٹ کے Exit Code 0 پر انحصار کرنا ایک خطرناک جوا ہے۔

اپنے پروڈکشن ماحول کو حقیقی معنوں میں محفوظ رکھنے کے لیے، آپ کو گہرائی میں دفاع (defense-in-depth) کی حکمت عملی اپنانی ہوگی:
1. اپنے ڈیٹا بیس انجن کے اندر صفحہ کی سطح پر چیک سمز کو فعال کریں۔
2. بیک اپ بنانے کے فوراً بعد مقامی توثیقی ٹولز (pg_verifybackup, RESTORE VERIFYONLY) کا استعمال کریں۔
3. ہیورسٹک بے قاعدگیوں کے لیے بیک اپ میٹا ڈیٹا (سائز، دورانیہ) کی نگرانی کریں۔
4. اپنی روزانہ کی آپریشنل پائپ لائن کے حصے کے طور پر خودکار، عارضی ریسٹور ٹیسٹنگ کو نافذ کریں۔

غیر فعال "بنائیں اور بھول جائیں” بیک اپ ذہنیت سے فعال "مسلسل ریسٹور توثیق” ماڈل کی طرف منتقل ہو کر، آپ اس بات کو یقینی بناتے ہیں کہ جب تباہی ناگزیر طور پر آئے، تو آپ کا ڈیٹا تیار، قابل اعتماد اور مکمل طور پر بحال ہونے کے قابل ہو۔