Loading blog...

پروڈکشن ڈیٹا بیس بیک اپ کی حکمت عملی جو اصل میں کام کرتی ہے: MySQL اور PostgreSQL

پیداوار میں MySQL اور PostgreSQL کے لیے ثابت شدہ بیک اپ اور ریکوری کی حکمت عملی

Balinder Walia12 اپریل، 202635 min read

پروڈکشن ڈیٹا کا کھو جانا ایک ایسا واقعہ ہے جس سے کیریئر ختم ہو جاتا ہے، کمپنیاں بند ہو جاتی ہیں، اور تمام غلط وجوہات کی بنا پر ہیکر نیوز کا صفحہ اول بنا دیتا ہے۔ اس کے باوجود زیادہ تر ٹیمیں ڈیٹا بیس کے بیک اپ کو ایک سوچ سمجھ کر پیش کرتی ہیں - ایک کرون جاب جو کسی نے دو سال پہلے ترتیب دی تھی جس کے بعد سے کسی نے تصدیق نہیں کی۔ یہ مضمون MySQL اور PostgreSQL کے لیے جنگ کی آزمائشی بیک اپ حکمت عملیوں کو پیش کرتا ہے جو کہ سنگل نوڈ k3s کلسٹرز سے لے کر ملٹی ریجن کلاؤڈ ڈیپلائمنٹس تک روزانہ لاکھوں لین دین پر کارروائی کرنے والے پیداواری ماحول میں ثابت ہوئی ہیں۔

ہم مکمل اسپیکٹرم کا احاطہ کریں گے: منطقی اور فزیکل بیک اپ کے طریقے، پوائنٹ ان ٹائم ریکوری، خودکار شیڈولنگ، کلاؤڈ اسٹوریج کے اہداف، انکرپشن، تصدیق، Kubernetes-مقامی نقطہ نظر، اور ڈیزاسٹر ریکوری پلاننگ جو ان سب کو ایک ساتھ جوڑتی ہے۔ ہر سفارش کنکریٹ کنفیگریشن اور کوڈ کے ساتھ آتی ہے جسے آپ اپنے ماحول کے مطابق ڈھال سکتے ہیں۔

بیک اپ کی اقسام کو سمجھنا

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

Aمکمل بیک اپایک ہی وقت میں پورے ڈیٹا بیس کو کیپچر کرتا ہے۔ اس کے بارے میں استدلال کرنا سب سے آسان اور بحال کرنا سب سے تیز ہے، لیکن اسٹوریج میں سب سے مہنگا اور تخلیق کرنے میں سب سے سست ہے۔ ایکانکریمنٹل بیک اپصرف وہی ڈیٹا حاصل کرتا ہے جو کسی بھی قسم کے آخری بیک اپ کے بعد تبدیل ہوا ہے۔ اسٹوریج میں بنانا اور کمپیکٹ کرنا تیز ہے، لیکن بحالی کے لیے مکمل چین کو دوبارہ چلانے کی ضرورت ہے: آخری مکمل بیک اپ کے علاوہ ہر بعد میں اضافہ۔ ایکڈیفرینشل بیک اپہر وہ چیز کیپچر کرتا ہے جو آخری مکمل بیک اپ کے بعد سے تبدیل ہوا ہے۔ یہ ایک درمیانی زمین پر قبضہ کرتا ہے — ایک اضافی سے بڑا لیکن بحال کرنا آسان ہے کیونکہ آپ کو صرف آخری مکمل اور تازہ ترین فرق کی ضرورت ہے۔ آخر میں،مسلسل آرکائیونگ(PostgreSQL میں WAL آرکائیونگ، MySQL میں بائنری لاگ سٹریمنگ) ہر انفرادی لین دین کو کیپچر کرتا ہے جیسا کہ یہ ہوتا ہے، بیک اپ کے درمیان کسی بھی لمحے پوائنٹ ان ٹائم ریکوری کو فعال کرتا ہے۔

زیادہ تر پروڈکشن سسٹمز کے لیے بہترین حکمت عملی ایک مجموعہ ہے: ہفتہ وار مکمل بیک اپ، روزانہ اضافہ یا فرق، اور مسلسل WAL/binlog آرکائیونگ۔ اس سے آپ کو حالیہ مکمل بیک اپس سے تیزی سے بحالی اور ضرورت پڑنے پر کسی بھی وقت بحال ہونے کی صلاحیت دونوں ملتی ہے۔

MySQL بیک اپ کے طریقے

MySQL کئی بیک اپ ٹولز پیش کرتا ہے، ہر ایک مختلف ڈیٹا بیس سائز اور ریکوری کی ضروریات کے لیے موزوں ہے۔ صحیح انتخاب آپ کے ڈیٹا کے حجم، قابل قبول بیک اپ ونڈو، اور RTO/RPO اہداف پر منحصر ہے۔

mysqldump - یونیورسل لاجیکل بیک اپ

mysqldumpSQL بیانات تیار کرتا ہے جو اسکیما اور ڈیٹا کو دوبارہ بناتا ہے۔ یہ ہر MySQL ورژن اور سٹوریج انجن پر کام کرتا ہے، جو اسے یونیورسل فال بیک بناتا ہے۔ تاہم، یہ ڈمپ کے دوران ٹیبلز کو لاک کر دیتا ہے (جب تک کہ InnoDB کے ساتھ--single-transactionکا استعمال نہ کیا جائے)، اور بحالی کی رفتار 50-100 GB سے زیادہ ڈیٹا بیس کے لیے نمایاں طور پر کم ہو جاتی ہے کیونکہ یہ انفرادی INSERT بیانات کو دوبارہ چلاتا ہے۔

# Full logical backup with consistent snapshot for InnoDB
mysqldump --single-transaction --routines --triggers --events \
  --set-gtid-purged=ON --all-databases \
  | gzip > /backups/mysql-full-$(date +%Y%m%d-%H%M%S).sql.gz

# Single database backup with compression
mysqldump --single-transaction --routines --triggers \
  --databases production_db \
  | pigz -p4 > /backups/production_db-$(date +%Y%m%d).sql.gz

# Schema-only backup for migration planning
mysqldump --no-data --routines --triggers --events \
  --all-databases > /backups/schema-only-$(date +%Y%m%d).sql

mysqlpump — متوازی منطقی بیک اپ

mysqlpumpمتوازی ٹیبل ڈمپنگ اور بلٹ ان کمپریشن کے ساتھmysqldumpپر بہتر ہوتا ہے۔ یہ بہت سے آزاد میزوں کے ساتھ ڈیٹا بیس کے بیک اپ کے وقت کو نمایاں طور پر کم کر سکتا ہے۔

# Parallel logical backup with 4 threads and zstd compression
mysqlpump --default-parallelism=4 --compress-output=ZSTD \
  --include-databases=production_db,analytics_db \
  --set-gtid-purged=ON \
  > /backups/mysql-pump-$(date +%Y%m%d).sql.zst

Percona XtraBackup — InnoDB

کے لیے فزیکل بیک اپ

50 GB سے بڑے ڈیٹا بیسز کے لیے، منطقی بیک اپ ناقابل عمل ہو جاتے ہیں — بیک اپ ونڈو اور بحالی کا وقت دونوں ڈیٹا کے سائز کے ساتھ لکیری طور پر بڑھتے ہیں۔ Percona XtraBackup ڈیٹابیس کو لاک کیے بغیر InnoDB ڈیٹا فائلوں کی فزیکل لیول کاپیاں لیتا ہے، جس سے یہ ملٹی ٹیرا بائٹ کی تعیناتیوں کے لیے موزوں ہے۔

# Full physical backup with streaming to compressed archive
xtrabackup --backup --target-dir=/backups/full-$(date +%Y%m%d) \
  --user=backup_user --password=secure_pass \
  --parallel=4 --compress --compress-threads=4

# Incremental backup based on last full
xtrabackup --backup --target-dir=/backups/incr-$(date +%Y%m%d) \
  --incremental-basedir=/backups/full-20260412 \
  --user=backup_user --password=secure_pass \
  --parallel=4

# Stream full backup directly to S3 via xbstream
xtrabackup --backup --stream=xbstream --compress \
  --user=backup_user --password=secure_pass | \
  aws s3 cp - s3://db-backups/mysql/full-$(date +%Y%m%d).xbstream

# Prepare for restore (apply redo log)
xtrabackup --prepare --target-dir=/backups/full-20260412

# Prepare incremental on top of full
xtrabackup --prepare --apply-log-only --target-dir=/backups/full-20260412
xtrabackup --prepare --target-dir=/backups/full-20260412 \
  --incremental-dir=/backups/incr-20260412

# Restore
systemctl stop mysqld
xtrabackup --copy-back --target-dir=/backups/full-20260412
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

MySQL بائنری لاگ — پوائنٹ ان ٹائم ریکوری

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

# Enable binary logging in my.cnf
[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800   # 7 days
sync_binlog = 1
gtid_mode = ON
enforce_gtid_consistency = ON

# Flush and archive binary logs
mysqladmin flush-logs
mysqlbinlog --read-from-remote-server --host=db-primary \
  --raw --stop-never --result-file=/backup/binlogs/ \
  mysql-bin.000042

# Point-in-time recovery: replay binlog up to specific timestamp
mysqlbinlog --stop-datetime="2026-04-12 14:30:00" \
  /backup/binlogs/mysql-bin.000042 \
  /backup/binlogs/mysql-bin.000043 | mysql -u root

PostgreSQL بیک اپ کے طریقے

PostgreSQL کا بیک اپ ایکو سسٹم MySQL کے مقابلے میں معقول طور پر زیادہ امیر ہے، جس میں فرسٹ پارٹی ٹولز اور بڑے پیمانے پر پیداواری ماحول کے لیے بنایا گیا کمیونٹی سلوشنز کا ایک پختہ سیٹ ہے۔

pg_dump اور pg_dumpall — منطقی بیک اپس

mysqldumpکی طرح،pg_dumpمنطقی بیک اپ تیار کرتا ہے۔ حسب ضرورت فارمیٹ (-Fc) تجویز کردہ ڈیفالٹ ہے کیونکہ یہ متوازی بحالی، سلیکٹیو ٹیبل کی بحالی، اور بلٹ ان کمپریشن کو سپورٹ کرتا ہے۔

# Custom format with parallel dump (4 worker jobs)
pg_dump -Fc -j4 -f /backups/production-$(date +%Y%m%d).dump production_db

# Directory format for maximum parallelism on large databases
pg_dump -Fd -j8 -f /backups/production-$(date +%Y%m%d)/ production_db

# All databases including globals (roles, tablespaces)
pg_dumpall > /backups/pg-all-$(date +%Y%m%d).sql

# Parallel restore from custom format
pg_restore -j4 -d production_db_restored /backups/production-20260412.dump

# Selective restore: single table
pg_restore -j4 -d production_db -t orders /backups/production-20260412.dump

pg_basebackup — فزیکل بیک اپ فاؤنڈیشن

pg_basebackupپوری PostgreSQL ڈیٹا ڈائرکٹری کی فزیکل کاپی لیتا ہے۔ یہ اسٹینڈ الیون ریکوری اور اسٹریمنگ ریپلیکشن سیٹ اپ دونوں کی بنیاد ہے۔ WAL آرکائیونگ کے ساتھ مل کر، یہ پوائنٹ ان ٹائم ریکوری کو قابل بناتا ہے۔

# Physical backup with WAL files included
pg_basebackup -D /backups/base-$(date +%Y%m%d) \
  -Ft -z -Xs -P -c fast \
  -U replication_user -h db-primary

# Stream backup directly to a tar archive with checksums
pg_basebackup -D - -Ft -Xs -c fast \
  -U replication_user -h db-primary | \
  gzip > /backups/pg-base-$(date +%Y%m%d).tar.gz

pgBackRest - انٹرپرائز گریڈ بیک اپ مینجمنٹ

pgBackRest PostgreSQL بیک اپ مینجمنٹ کے لیے گولڈ اسٹینڈرڈ ہے۔ یہ مکمل، انکریمنٹل، اور ڈیفرینشل بیک اپس، متوازی بیک اپ اور ریسٹور، انکرپشن، ملٹی ریپوزٹری اہداف (لوکل ڈسک، S3، GCS، Azure بلاب)، اور خودکار WAL آرکائیونگ کو سپورٹ کرتا ہے — یہ سب ایک سنگل، مربوط ترتیب کے ذریعے۔

# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=pg-backups-production
repo1-s3-endpoint=s3.eu-west-1.amazonaws.com
repo1-s3-region=eu-west-1
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=a_very_secure_encryption_passphrase

# Second repository for geographic redundancy
repo2-type=azure
repo2-azure-container=pg-backups-dr
repo2-azure-account=prodbackupstorage
repo2-azure-key=base64encodedkeyhere
repo2-path=/pgbackrest
repo2-retention-full=2

process-max=4
compress-type=zst
compress-level=6
log-level-console=info
log-level-file=detail
start-fast=y

[production]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

# PostgreSQL WAL archive configuration (postgresql.conf)
# archive_mode = on
# archive_command = 'pgbackrest --stanza=production archive-push %p'

# Create the stanza
pgbackrest --stanza=production stanza-create

# Verify the stanza configuration
pgbackrest --stanza=production check

# Full backup
pgbackrest --stanza=production --type=full backup

# Differential backup
pgbackrest --stanza=production --type=diff backup

# Incremental backup
pgbackrest --stanza=production --type=incr backup

# List backups
pgbackrest --stanza=production info

WAL-G — ہلکا پھلکا WAL کو کلاؤڈ اسٹوریج میں محفوظ کرنا

WAL-G pgBackRest کا ایک آسان متبادل ہے جو کلاؤڈ آبجیکٹ اسٹوریج میں WAL سیگمنٹس اور بیس بیک اپس کو سٹریم کرنے پر فوکس کرتا ہے۔ یہ کنٹینرائزڈ ماحول میں مقبول ہے جہاں آپ کم سے کم کنفیگریشن کے ساتھ سنگل بائنری چاہتے ہیں۔

# Environment variables for WAL-G with S3
export WALG_S3_PREFIX=s3://pg-wal-archive/production
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_REGION=eu-west-1
export WALG_COMPRESSION_METHOD=lz4
export PGHOST=/var/run/postgresql

# Configure WAL archiving in postgresql.conf
# archive_mode = on
# archive_command = 'wal-g wal-push %p'
# restore_command = 'wal-g wal-fetch %f %p'

# Take a base backup
wal-g backup-push /var/lib/postgresql/16/main

# List backups
wal-g backup-list

# Restore from latest backup
wal-g backup-fetch /var/lib/postgresql/16/main LATEST

# Delete old backups (retain last 4)
wal-g delete retain FULL 4 --confirm

برمن — سنٹرلائزڈ بیک اپ سرور

برمن (بیک اپ اور ریکوری مینیجر) کو ایسے ماحول کے لیے ڈیزائن کیا گیا ہے جہاں ایک وقف شدہ بیک اپ سرور متعدد PostgreSQL مثالوں کے لیے بیک اپ کا انتظام کرتا ہے۔ یہ بیک اپ ٹرانسپورٹ کے لیے rsync/SSH اور سٹریمنگ ریپلیکیشن پروٹوکول دونوں کو سپورٹ کرتا ہے۔

# /etc/barman.d/production.conf
[production]
description = "Production PostgreSQL 16"
ssh_command = ssh postgres@db-primary
conninfo = host=db-primary user=barman dbname=postgres
streaming_conninfo = host=db-primary user=streaming_barman
backup_method = postgres
streaming_archiver = on
slot_name = barman
retention_policy = RECOVERY WINDOW OF 14 DAYS

# Create replication slot and start streaming
barman receive-wal --create-slot production
barman switch-wal --force --archive production

# Take a backup
barman backup production

# List backups
barman list-backup production

# Restore to point in time
barman recover --target-time "2026-04-12 14:30:00" \
  production 20260412T120000 /var/lib/postgresql/16/main

پوائنٹ ان ٹائم ریکوری (PITR)

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

PITR برائے PostgreSQL

PostgreSQL PITR بیس بیک اپ کو بحال کرکے اور WAL سیگمنٹس کو ٹارگٹ ٹائم اسٹیمپ تک دوبارہ چلا کر کام کرتا ہے۔ pgBackRest کے ساتھ، پورا عمل ایک واحد کمانڈ ہے۔

# Restore to specific point in time with pgBackRest
pgbackrest --stanza=production \
  --type=time --target="2026-04-12 16:42:30" \
  --target-action=promote \
  restore

# Manual PITR using pg_basebackup + WAL archive
# 1. Stop PostgreSQL
systemctl stop postgresql

# 2. Clear the data directory and restore base backup
rm -rf /var/lib/postgresql/16/main/*
tar xzf /backups/pg-base-20260412.tar.gz -C /var/lib/postgresql/16/main/

# 3. Create recovery signal and configure restore
cat > /var/lib/postgresql/16/main/postgresql.auto.conf << 'CONF'
restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2026-04-12 16:42:30'
recovery_target_action = 'promote'
CONF
touch /var/lib/postgresql/16/main/recovery.signal

# 4. Start PostgreSQL — it will replay WAL and stop at target
systemctl start postgresql

PITR برائے MySQL

MySQL PITR ایک XtraBackup فزیکل ریسٹور کو بائنری لاگ ری پلے کے ساتھ جوڑتا ہے۔

# 1. Restore the XtraBackup
systemctl stop mysqld
rm -rf /var/lib/mysql/*
xtrabackup --prepare --target-dir=/backups/full-20260412
xtrabackup --copy-back --target-dir=/backups/full-20260412
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

# 2. Identify the binlog position from XtraBackup metadata
cat /backups/full-20260412/xtrabackup_binlog_info
# Output: mysql-bin.000042  154  3E11FA47-1111-1111-1111-AAAAAAAAAAAA:1-1234

# 3. Replay binlogs up to target time
mysqlbinlog --start-position=154 \
  --stop-datetime="2026-04-12 16:42:30" \
  /backup/binlogs/mysql-bin.000042 \
  /backup/binlogs/mysql-bin.000043 | mysql -u root

ملٹی کلاؤڈ بیک اپ آرکیٹیکچر

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

لائف سائیکل پالیسیوں کے ساتھ

کلاؤڈ اسٹوریج کنفیگریشن

# AWS S3 lifecycle policy (Terraform)
resource "aws_s3_bucket_lifecycle_configuration" "backup_lifecycle" {
  bucket = aws_s3_bucket.db_backups.id

  rule {
    id     = "backup-tiering"
    status = "Enabled"

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }
    expiration {
      days = 2555  # 7 years for compliance
    }
  }

  rule {
    id     = "wal-segments"
    status = "Enabled"
    filter {
      prefix = "wal-archive/"
    }
    expiration {
      days = 30
    }
  }
}

# Enable cross-region replication
resource "aws_s3_bucket_replication_configuration" "backup_replication" {
  bucket = aws_s3_bucket.db_backups.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "cross-region-dr"
    status = "Enabled"
    destination {
      bucket        = aws_s3_bucket.db_backups_dr.arn
      storage_class = "STANDARD_IA"
      encryption_configuration {
        replica_kms_key_id = aws_kms_key.dr_key.arn
      }
    }
    source_selection_criteria {
      sse_kms_encrypted_objects {
        status = "Enabled"
      }
    }
  }
}

# Azure Blob immutability policy (Azure CLI)
az storage container immutability-policy create \
  --account-name prodbackupstorage \
  --container-name pg-backups \
  --period 365 \
  --allow-protected-append-writes true

# GCS lifecycle with nearline transition
gsutil lifecycle set /dev/stdin gs://pg-backups-production << 'JSON'
{
  "rule": [
    {"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"}, "condition": {"age": 30}},
    {"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"}, "condition": {"age": 90}},
    {"action": {"type": "Delete"}, "condition": {"age": 2555}}
  ]
}
JSON

بیک اپ انکرپشن اور سیکیورٹی

بیک اپ حملہ آوروں کے لیے ایک اعلیٰ قیمت کا ہدف ہیں۔ چوری شدہ غیر انکرپٹڈ بیک اپ حملہ آور کو آپ کے پروڈکشن ڈیٹا کی مکمل کاپی فراہم کرتا ہے بغیر آپ کے چلنے والے سسٹمز کی خلاف ورزی کی ضرورت کے۔ ہر بیک اپ، ٹرانزٹ اور آرام میں، انکرپٹ ہونا ضروری ہے۔

ٹرانزٹ میں خفیہ کاریکا مطلب ہے ڈیٹا بیس سرور اور بیک اپ منزل کے درمیان تمام رابطوں کے لیے TLS استعمال کرنا۔ TLS کے ساتھ کنفیگر ہونے پر pgBackRest اور XtraBackup دونوں انکرپٹڈ چینلز پر سٹریم کرتے ہیں۔ S3، Azure Blob، یا GCS پر بھیجتے وقت، کلائنٹ SDKs بطور ڈیفالٹ HTTPS استعمال کرتے ہیں۔

Encryption باقیکی دو پرتیں ہیں۔ سرور سائیڈ انکرپشن (SSE) اسٹوریج کے ہدف پر پہنچنے کے بعد ڈیٹا کو خفیہ کرتا ہے — S3 SSE-KMS، Azure اسٹوریج سروس انکرپشن، یا GCS ڈیفالٹ انکرپشن۔ کلائنٹ سائڈ انکرپشن ڈیٹا بیس سرور سے نکلنے سے پہلے ہی ڈیٹا کو خفیہ کرتا ہے، اس بات کو یقینی بناتا ہے کہ کلاؤڈ فراہم کنندہ کبھی بھی سادہ متن کا ڈیٹا نہ دیکھے۔ pgBackRest اور WAL-G دونوں مقامی طور پر کلائنٹ سائڈ انکرپشن کی حمایت کرتے ہیں۔

# pgBackRest client-side encryption config
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=long_random_passphrase_stored_in_vault

# WAL-G client-side encryption
export WALG_LIBSODIUM_KEY=$(cat /etc/wal-g/encryption.key)
# Or GPG-based
export WALG_GPG_KEY_ID=backup@example.com

# MySQL XtraBackup with encryption
xtrabackup --backup --encrypt=AES256 \
  --encrypt-key-file=/etc/mysql/backup-encryption.key \
  --target-dir=/backups/full-encrypted-$(date +%Y%m%d)

انکرپشن کیز کو خود بیک اپ سے الگ اسٹور کریں۔ HashiCorp Vault، AWS Secrets Manager، یا Azure Key Vault جیسا سیکرٹ مینیجر تجویز کردہ طریقہ ہے۔ اگر آپ کلید کو بیک اپ کے ساتھ اسٹور کرتے ہیں، تو ایک حملہ آور جو آپ کے بیک اپ اسٹوریج تک رسائی حاصل کرتا ہے اس کے پاس وہ سب کچھ ہوتا ہے جس کی انہیں ضرورت ہوتی ہے۔

خودکار بیک اپ شیڈولنگ

دستی بیک اپ بیک اپ نہیں ہیں - یہ خواہشات ہیں۔ بیک اپ کے نظام الاوقات کو خودکار، نگرانی، اور ناکامی پر الرٹ کرنا چاہیے۔

سسٹم کرون برائے ننگی دھات اور VMs

# /etc/cron.d/database-backups

# PostgreSQL — pgBackRest
# Full backup every Sunday at 01:00
0 1 * * 0 postgres pgbackrest --stanza=production --type=full backup 2>&1 | logger -t pgbackrest-full

# Differential backup every day at 01:00 (except Sunday)
0 1 * * 1-6 postgres pgbackrest --stanza=production --type=diff backup 2>&1 | logger -t pgbackrest-diff

# MySQL — XtraBackup
# Full backup every Sunday at 02:00
0 2 * * 0 root /usr/local/bin/mysql-backup.sh full 2>&1 | logger -t xtrabackup-full

# Incremental backup every day at 02:00 (except Sunday)
0 2 * * 1-6 root /usr/local/bin/mysql-backup.sh incremental 2>&1 | logger -t xtrabackup-incr

# Backup verification — restore test every Wednesday at 04:00
0 4 * * 3 root /usr/local/bin/verify-backup.sh 2>&1 | logger -t backup-verify

Kubernetes کرون جابز

Kubernetes ماحول میں، کرون جابس سسٹم کرون کی جگہ لے لیتے ہیں۔ وہ بلٹ ان ریٹری منطق، کنکرنسی کنٹرول، اور کلسٹر کے RBAC اور خفیہ انتظام کے ساتھ انضمام پیش کرتے ہیں۔

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pg-backup-full
  namespace: database
spec:
  schedule: "0 1 * * 0"  # Sunday 01:00 UTC
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 4
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 7200  # 2 hour timeout
      template:
        spec:
          serviceAccountName: db-backup
          restartPolicy: OnFailure
          containers:
            - name: pgbackrest
              image: pgbackrest/pgbackrest:2.50
              command:
                - /bin/bash
                - -c
                - |
                  pgbackrest --stanza=production --type=full backup
                  RESULT=$?
                  if [ $RESULT -eq 0 ]; then
                    curl -s -X POST "$SLACK_WEBHOOK" \
                      -d '{"text":"PostgreSQL full backup completed successfully"}'
                  else
                    curl -s -X POST "$SLACK_WEBHOOK" \
                      -d '{"text":"ALERT: PostgreSQL full backup FAILED"}'
                  fi
                  exit $RESULT
              envFrom:
                - secretRef:
                    name: pgbackrest-credentials
                - secretRef:
                    name: slack-webhook
              resources:
                requests:
                  memory: 512Mi
                  cpu: 500m
                limits:
                  memory: 2Gi
                  cpu: "2"
              volumeMounts:
                - name: pgbackrest-config
                  mountPath: /etc/pgbackrest
          volumes:
            - name: pgbackrest-config
              configMap:
                name: pgbackrest-conf
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: pg-backup-diff
  namespace: database
spec:
  schedule: "0 1 * * 1-6"  # Mon-Sat 01:00 UTC
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 7
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 3600
      template:
        spec:
          serviceAccountName: db-backup
          restartPolicy: OnFailure
          containers:
            - name: pgbackrest
              image: pgbackrest/pgbackrest:2.50
              command:
                - /bin/bash
                - -c
                - |
                  pgbackrest --stanza=production --type=diff backup
              envFrom:
                - secretRef:
                    name: pgbackrest-credentials
              resources:
                requests:
                  memory: 256Mi
                  cpu: 250m
                limits:
                  memory: 1Gi
                  cpu: "1"
              volumeMounts:
                - name: pgbackrest-config
                  mountPath: /etc/pgbackrest
          volumes:
            - name: pgbackrest-config
              configMap:
                name: pgbackrest-conf
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: mysql-backup-full
  namespace: database
spec:
  schedule: "0 2 * * 0"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 7200
      template:
        spec:
          serviceAccountName: db-backup
          restartPolicy: OnFailure
          containers:
            - name: xtrabackup
              image: percona/percona-xtrabackup:8.0
              command:
                - /bin/bash
                - -c
                - |
                  xtrabackup --backup --stream=xbstream --compress \
                    --user=$MYSQL_BACKUP_USER \
                    --password=$MYSQL_BACKUP_PASS \
                    --host=mysql-primary.database.svc | \
                    aws s3 cp - s3://$S3_BUCKET/mysql/full-$(date +%Y%m%d).xbstream
              envFrom:
                - secretRef:
                    name: mysql-backup-credentials
                - secretRef:
                    name: aws-credentials
              resources:
                requests:
                  memory: 512Mi
                  cpu: 500m
                limits:
                  memory: 2Gi
                  cpu: "2"

Kubernetes-مقامی بیک اپ اپروچز

Kubernetes میں

چلانے والے ڈیٹا بیس نے بیک اپ حکمت عملی کے لیے ایک نئی جہت متعارف کرائی ہے۔ ایپلیکیشن لیول ڈیٹا بیس بیک اپ کے علاوہ، آپ کو کلسٹر لیول بیک اپ (وغیرہ)، مستقل والیوم اسنیپ شاٹس، اور آپریٹر کے زیر انتظام بیک اپس پر غور کرنے کی ضرورت ہے۔

ویلرو برائے کلسٹر لیول بیک اپ

ویلرو Kubernetes وسائل (تعینات، خدمات، کنفیگریشن میپس، راز) اور مستقل حجم کا بیک اپ لیتا ہے۔ یہ ایپلیکیشن کی سطح کے ڈیٹا بیس بیک اپ کا متبادل نہیں ہے - یہ PVs کے کریش-مسلسل اسنیپ شاٹ کو حاصل کرتا ہے، جو ڈیٹا بیس کے لیے لین دین کے لحاظ سے مطابقت نہیں رکھتا۔ ڈیٹا بیس کی بازیابی کے لیے کلسٹر ریکوری اور ایپلیکیشن لیول ٹولز (pgBackRest، XtraBackup) کے لیے ویلرو کا استعمال کریں۔

# Install Velero with S3 backend
velero install \
  --provider aws \
  --bucket velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config region=eu-west-1 \
  --snapshot-location-config region=eu-west-1 \
  --use-volume-snapshots=true \
  --plugins velero/velero-plugin-for-aws:v1.9.0

# Create a scheduled backup of the database namespace
velero schedule create db-namespace-backup \
  --schedule="0 3 * * *" \
  --include-namespaces database \
  --ttl 720h \
  --storage-location default \
  --volume-snapshot-locations default

# On-demand backup before maintenance
velero backup create pre-maintenance-$(date +%Y%m%d) \
  --include-namespaces database,monitoring \
  --wait

# Restore a namespace from backup
velero restore create --from-backup pre-maintenance-20260412 \
  --include-namespaces database

k3sپر

لانگ ہارن اسنیپ شاٹس

k3s تعیناتیاں عام طور پر Longhorn کو اپنے CSI اسٹوریج فراہم کنندہ کے طور پر استعمال کرتی ہیں۔ Longhorn حجم کی سطح کے سنیپ شاٹس اور S3 کے موافق آبجیکٹ اسٹوریج میں سنیپ شاٹس کو نقل کرنے کی صلاحیت فراہم کرتا ہے۔ ڈیٹا بیس کے لیے، گہرائی میں دفاع کے لیے لانگ ہارن اسنیپ شاٹس کو ایپلیکیشن لیول بیک اپ کے ساتھ جوڑیں۔

# Longhorn recurring snapshot job via CRD
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: pg-data-snapshot
  namespace: longhorn-system
spec:
  cron: "0 */4 * * *"  # every 4 hours
  task: snapshot
  retain: 6
  concurrency: 1
  groups:
    - pg-data
  labels:
    app: postgresql
---
# Longhorn recurring backup to S3
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: pg-data-s3-backup
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"  # daily at 02:00
  task: backup
  retain: 14
  concurrency: 1
  groups:
    - pg-data
  labels:
    app: postgresql
---
# VolumeSnapshot using Longhorn CSI
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pg-data-snap-$(date +%Y%m%d)
  namespace: database
spec:
  volumeSnapshotClassName: longhorn-snapshot-vsc
  source:
    persistentVolumeClaimName: pg-data-postgresql-0

آپریٹر کے زیر انتظام بیک اپس

ڈیٹا بیس آپریٹرز جیسے CloudNativePG (PostgreSQL کے لیے) اور Percona آپریٹر (MySQL کے لیے) بیک اپ مینجمنٹ کو براہ راست ڈیٹا بیس لائف سائیکل میں ضم کرتے ہیں۔ آپریٹر اپنی مرضی کے وسائل کے ذریعے شیڈولنگ، WAL آرکائیونگ، اور برقرار رکھنے کو خود بخود ہینڈل کرتا ہے۔

# CloudNativePG cluster with integrated backup
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-pg
  namespace: database
spec:
  instances: 3
  storage:
    size: 100Gi
    storageClass: longhorn
  backup:
    barmanObjectStore:
      destinationPath: s3://pg-backups/cnpg/
      endpointURL: https://s3.eu-west-1.amazonaws.com
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: SECRET_ACCESS_KEY
      wal:
        compression: gzip
        maxParallel: 4
      data:
        compression: gzip
    retentionPolicy: "30d"
---
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: production-pg-weekly
  namespace: database
spec:
  schedule: "0 1 * * 0"
  backupOwnerReference: self
  cluster:
    name: production-pg

کلاؤڈ فراہم کنندہ کے لیے مخصوص حکمت عملی

AWS — RDS اور Aurora

AWS RDS پوائنٹ ان ٹائم ریکوری کے لیے کنفیگر ایبل ریٹینشن (35 دن تک) اور ٹرانزیکشن لاگ آرکائیونگ کے ذریعے مسلسل بیک اپ کے ساتھ روزانہ خودکار اسنیپ شاٹس فراہم کرتا ہے۔ ارورہ نے بیک ٹریک کا اضافہ کیا، جو کہ کلسٹر کو بیک ٹریک ونڈو کے اندر کسی بھی مقام پر ری وائنڈ کر سکتا ہے بغیر کسی بحالی کی ضرورت کے - یہ ڈیٹا بیس کی اندرونی حالت کو صرف الٹ دیتا ہے۔

# Enable automated backups with maximum retention (Terraform)
resource "aws_db_instance" "production" {
  identifier             = "production-pg"
  engine                 = "postgres"
  engine_version         = "16.2"
  instance_class         = "db.r6g.xlarge"
  allocated_storage      = 500
  backup_retention_period = 35  # maximum
  backup_window          = "03:00-04:00"
  copy_tags_to_snapshot  = true
  deletion_protection    = true
  storage_encrypted      = true
  kms_key_id             = aws_kms_key.rds.arn

  # Enable PITR
  enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
}

# Cross-region automated backup replication
resource "aws_db_instance_automated_backups_replication" "dr" {
  source_db_instance_arn = aws_db_instance.production.arn
  kms_key_id             = aws_kms_key.dr_rds.arn
  retention_period       = 14
}

# Aurora Backtrack (MySQL-compatible Aurora only)
resource "aws_rds_cluster" "aurora_production" {
  cluster_identifier      = "aurora-production"
  engine                  = "aurora-mysql"
  engine_version          = "8.0.mysql_aurora.3.05.2"
  backtrack_window        = 86400  # 24 hours of backtrack
  backup_retention_period = 35
  preferred_backup_window = "03:00-04:00"
  storage_encrypted       = true
}

# Manual snapshot with cross-region copy
aws rds create-db-snapshot \
  --db-instance-identifier production-pg \
  --db-snapshot-identifier pre-migration-$(date +%Y%m%d)

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:eu-west-1:123456789:snapshot:pre-migration-20260412 \
  --target-db-snapshot-identifier pre-migration-20260412-dr \
  --source-region eu-west-1 \
  --region us-east-1 \
  --kms-key-id arn:aws:kms:us-east-1:123456789:key/dr-key-id

Azure — لچکدار سرور

PostgreSQL اور MySQL لچکدار سرور کے لیے

Azure ڈیٹا بیس میں مقامی طور پر بے کار یا جیو فالتو اسٹوریج کے ساتھ خودکار بیک اپ شامل ہیں۔ جیو فالتو بیک اپ تباہی کی بحالی کے لیے کراس ریجن کی بحالی کی اجازت دیتا ہے۔

# Azure Flexible Server with geo-redundant backup (Terraform)
resource "azurerm_postgresql_flexible_server" "production" {
  name                = "production-pg"
  location            = "westeurope"
  resource_group_name = azurerm_resource_group.db.name
  sku_name            = "GP_Standard_D4s_v3"
  version             = "16"
  storage_mb          = 524288  # 512 GB

  backup_retention_days        = 35
  geo_redundant_backup_enabled = true

  authentication {
    active_directory_auth_enabled = true
    password_auth_enabled         = false
  }
}

# Azure Blob immutability for self-managed backups
resource "azurerm_storage_management_policy" "backup_lifecycle" {
  storage_account_id = azurerm_storage_account.backups.id

  rule {
    name    = "backup-tiering"
    enabled = true
    filters {
      blob_types   = ["blockBlob"]
      prefix_match = ["pg-backups/"]
    }
    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 30
        tier_to_archive_after_days_since_modification_greater_than = 90
        delete_after_days_since_modification_greater_than          = 2555
      }
    }
  }
}

GCP — Cloud SQL

Cloud SQL باکس سے باہر خودکار بیک اپ اور پوائنٹ ان ٹائم ریکوری فراہم کرتا ہے۔ GCE یا GKE پر خود سے منظم ڈیٹا بیسز کے لیے، نزدیکی اور کولڈ لائن اسٹوریج کلاسز کے ساتھ GCS لاگت سے موثر طویل مدتی بیک اپ اسٹوریج فراہم کرتا ہے۔

# Cloud SQL with automated backups and PITR (Terraform)
resource "google_sql_database_instance" "production" {
  name             = "production-pg"
  database_version = "POSTGRES_16"
  region           = "europe-west1"

  settings {
    tier = "db-custom-4-16384"

    backup_configuration {
      enabled                        = true
      start_time                     = "03:00"
      point_in_time_recovery_enabled = true
      transaction_log_retention_days = 7
      backup_retention_settings {
        retained_backups = 30
        retention_unit   = "COUNT"
      }
    }

    ip_configuration {
      ssl_mode = "ENCRYPTED_ONLY"
    }
  }
}

# Export to GCS for long-term retention
gcloud sql export sql production-pg \
  gs://pg-backups-longterm/export-$(date +%Y%m%d).sql.gz \
  --database=production_db \
  --offload

بیک اپ کی تصدیق اور بحال ٹیسٹنگ

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

#!/bin/bash
# verify-backup.sh — Automated backup verification script
set -euo pipefail

RESTORE_DIR="/tmp/backup-verify-$(date +%Y%m%d-%H%M%S)"
LOG_FILE="/var/log/backup-verify.log"
SLACK_WEBHOOK="${SLACK_WEBHOOK_URL}"
DB_TYPE="${1:-postgresql}"  # postgresql or mysql

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"; }
alert() {
  log "ALERT: $*"
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H 'Content-Type: application/json' \
    -d "{\"text\":\"BACKUP VERIFY FAILED: $*\"}"
}

cleanup() {
  log "Cleaning up $RESTORE_DIR"
  rm -rf "$RESTORE_DIR"
  if [ "$DB_TYPE" = "postgresql" ]; then
    pg_ctlcluster 16 verify stop 2>/dev/null || true
  else
    mysqladmin -S /tmp/mysql-verify.sock shutdown 2>/dev/null || true
  fi
}
trap cleanup EXIT

mkdir -p "$RESTORE_DIR"

if [ "$DB_TYPE" = "postgresql" ]; then
  log "Starting PostgreSQL backup verification"

  # Restore latest pgBackRest backup to temporary directory
  pgbackrest --stanza=production \
    --pg1-path="$RESTORE_DIR/pgdata" \
    --type=immediate \
    --target-action=promote \
    restore 2>&1 | tee -a "$LOG_FILE"

  if [ ${PIPESTATUS[0]} -ne 0 ]; then
    alert "pgBackRest restore failed"
    exit 1
  fi

  # Start PostgreSQL on a different port
  pg_ctlcluster 16 verify start -- \
    -D "$RESTORE_DIR/pgdata" \
    -o "-p 5433" \
    -o "-c listen_addresses=127.0.0.1"

  sleep 5

  # Verify data integrity
  TABLES=$(psql -p 5433 -d production_db -t -c \
    "SELECT count(*) FROM information_schema.tables WHERE table_schema='public';")
  log "Verified $TABLES tables exist"

  ROW_CHECK=$(psql -p 5433 -d production_db -t -c \
    "SELECT count(*) FROM orders WHERE created_at > now() - interval '7 days';")
  log "Recent orders count: $ROW_CHECK"

  if [ "$ROW_CHECK" -lt 1 ]; then
    alert "PostgreSQL restore has no recent data — possible stale backup"
    exit 1
  fi

  # Run pg_amcheck for corruption detection (PostgreSQL 14+)
  pg_amcheck -p 5433 -d production_db --heapallindexed 2>&1 | tee -a "$LOG_FILE"

  log "PostgreSQL backup verification PASSED"

else
  log "Starting MySQL backup verification"

  # Prepare and restore latest XtraBackup
  LATEST_FULL=$(ls -td /backups/full-* | head -1)
  cp -r "$LATEST_FULL" "$RESTORE_DIR/mysql-data"
  xtrabackup --prepare --target-dir="$RESTORE_DIR/mysql-data"

  # Start MySQL on a different socket and port
  mysqld --datadir="$RESTORE_DIR/mysql-data" \
    --socket=/tmp/mysql-verify.sock \
    --port=3307 \
    --skip-networking=0 \
    --bind-address=127.0.0.1 &

  sleep 10

  # Verify data
  TABLES=$(mysql -S /tmp/mysql-verify.sock -e \
    "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='production_db';" -sN)
  log "Verified $TABLES tables exist"

  mysqlcheck -S /tmp/mysql-verify.sock --all-databases --check 2>&1 | tee -a "$LOG_FILE"

  log "MySQL backup verification PASSED"
fi

curl -s -X POST "$SLACK_WEBHOOK" \
  -H 'Content-Type: application/json' \
  -d "{\"text\":\"Backup verification PASSED for $DB_TYPE at $(date)\"}"

log "Verification complete"

ڈیزاسٹر ریکوری پلاننگ: RTO اور RPO

ہر بیک اپ حکمت عملی کو دو میٹرکس کے ارد گرد ڈیزائن کیا جانا چاہیے:ریکوری ٹائم آبجیکٹو (RTO)— آپ کتنی دیر تک نیچے رہنے کا متحمل ہو سکتے ہیں — اورریکوری پوائنٹ آبجیکٹیو (RPO)— آپ کتنا ڈیٹا کھو سکتے ہیں۔ یہ نمبر بیک اپ فریکوئنسی، طریقہ کار اور فن تعمیر کے بارے میں ہر فیصلے کو چلاتے ہیں۔

منظر نامہ	RTO	RPO	حکمت عملی
ای کامرس چیک آؤٹ	< 5 منٹ	0 (صفر ڈیٹا نقصان)	ہم وقت ساز نقل + مسلسل WAL آرکائیونگ + ہاٹ اسٹینڈ بائی فیل اوور
SaaS ایپلیکیشن	< 30 منٹ	< 1 منٹ	سلسلہ بندی کی نقل + WAL-G مسلسل آرکائیونگ + خودکار فیل اوور
اندرونی ٹولز	< 4 گھنٹے	< 1 گھنٹہ	روزانہ فرق + گھنٹہ اضافہ + WAL آرکائیونگ
تجزیات / ڈیٹا گودام	< 24 گھنٹے	< کلاؤڈ اسٹوریج پر 24 گھنٹے	روزانہ مکمل بیک اپ
دیو / سٹیجنگ	< 48 گھنٹے	< 1 ہفتہ	ہفتہ وار مکمل بیک اپ

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

ڈیزاسٹر ریکوری رن بک ٹیمپلیٹ

# DR Runbook: Database Recovery

## Severity Levels
- P1: Complete data loss / corruption — all hands, CEO notified
- P2: Partial data loss / single region down — on-call team + escalation
- P3: Replica failure / backup failure — on-call investigation

## Recovery Procedures

### Scenario A: Primary DB failure, replicas healthy
1. Promote replica to primary (automated via Patroni / orchestrator)
2. Verify application connectivity
3. Re-establish replication from new primary
4. Investigate root cause

### Scenario B: Complete cluster failure, backups intact
1. Provision new database infrastructure
2. Restore latest full backup
3. Apply WAL/binlog to reach latest consistent point
4. Verify data integrity with checksums
5. Update DNS / connection strings
6. Resume application traffic
7. Re-establish backup schedule immediately

### Scenario C: Data corruption (bad migration / SQL injection)
1. Identify exact timestamp of corruption
2. Restore to point-in-time just before corruption
3. Export affected tables from restored copy
4. Merge clean data into production
5. OR: full PITR restore if corruption is widespread

## Contacts
- DBA on-call: [PagerDuty rotation]
- Infrastructure: [PagerDuty rotation]
- VP Engineering: [phone number]

## Validation Checklist
- [ ] Application health checks pass
- [ ] Row counts match expected ranges
- [ ] Recent transactions are present
- [ ] Replication re-established
- [ ] Backup schedule resumed
- [ ] Post-incident review scheduled

بیک اپ مانیٹرنگ اور الرٹنگ

بیک اپ سسٹم خاموشی سے ناکام ہو جاتے ہیں۔ ڈیٹا بیس چلتا رہتا ہے، ایپلیکیشن ٹریفک کی خدمت کرتی رہتی ہے، اور کوئی بھی نہیں دیکھتا کہ بیک اپ نے تین ہفتے پہلے کام کرنا بند کر دیا تھا - جب تک کہ انہیں کسی کی ضرورت نہ ہو۔ فعال نگرانی ضروری ہے۔

# Prometheus alerting rules for backup monitoring
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: backup-alerts
  namespace: monitoring
spec:
  groups:
    - name: database-backups
      rules:
        - alert: BackupTooOld
          expr: |
            (time() - backup_last_successful_timestamp_seconds) > 90000
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Database backup is older than 25 hours"
            description: "Last successful backup for {{ $labels.database }} was {{ $value | humanizeDuration }} ago"

        - alert: BackupJobFailed
          expr: |
            kube_job_status_failed{job_name=~".*backup.*"} > 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Backup CronJob failed: {{ $labels.job_name }}"

        - alert: WALArchivingLagging
          expr: |
            pg_stat_archiver_failed_count > 0
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "PostgreSQL WAL archiving has failures"

        - alert: BackupStorageQuotaNearing
          expr: |
            (backup_storage_used_bytes / backup_storage_quota_bytes) > 0.85
          for: 30m
          labels:
            severity: warning
          annotations:
            summary: "Backup storage at {{ $value | humanizePercentage }} capacity"

        - alert: BinlogSpaceCritical
          expr: |
            mysql_binlog_size_bytes > 53687091200
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "MySQL binlog space exceeds 50GB — check archiving"

# Custom Prometheus exporter for pgBackRest metrics
#!/usr/bin/env python3
"""pgBackRest Prometheus exporter — exposes backup age and size metrics."""
import json
import subprocess
import time
from prometheus_client import start_http_server, Gauge

BACKUP_AGE = Gauge('pgbackrest_last_backup_age_seconds', 'Seconds since last backup', ['stanza', 'type'])
BACKUP_SIZE = Gauge('pgbackrest_last_backup_size_bytes', 'Size of last backup', ['stanza', 'type'])
BACKUP_REPO_SIZE = Gauge('pgbackrest_repo_size_bytes', 'Total repository size', ['stanza'])

def collect():
    result = subprocess.run(
        ['pgbackrest', '--output=json', 'info'],
        capture_output=True, text=True
    )
    info = json.loads(result.stdout)
    for stanza_info in info:
        stanza = stanza_info['name']
        for backup in stanza_info.get('backup', []):
            backup_type = backup['type']
            stop_time = backup['timestamp']['stop']
            age = time.time() - stop_time
            BACKUP_AGE.labels(stanza=stanza, type=backup_type).set(age)
            size = backup['info']['size']
            BACKUP_SIZE.labels(stanza=stanza, type=backup_type).set(size)

if __name__ == '__main__':
    start_http_server(9854)
    while True:
        collect()
        time.sleep(300)

عام غلطیاں اور اینٹی پیٹرنز

درجنوں پیداواری ماحول میں ڈیٹا بیس کے بیک اپ کا انتظام کرنے کے بعد، یہ وہ غلطیاں ہیں جو سب سے زیادہ نقصان پہنچاتی ہیں۔

1. ڈیٹا بیس کی طرح اسی ڈسک پر بیک اپ لینا۔اگر ڈسک ناکام ہو جاتی ہے، تو آپ ڈیٹا بیس اور بیک اپ دونوں کھو دیتے ہیں۔ بیک اپ کو ہمیشہ الگ اسٹوریج ٹارگٹ پر لکھیں — مثالی طور پر آف میزبان اور آف ریجن۔

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

3. بیک اپ کے طور پر مکمل طور پر نقل پر انحصار کرنا۔نقل بیک اپ نہیں ہے۔ پرائمری پر ایکDROP TABLEکو فوری طور پر تمام نقلوں پر نقل کیا جاتا ہے۔ نقل ہارڈ ویئر کی ناکامی سے بچاتی ہے، منطقی غلطیوں سے نہیں۔

4. بیک اپ جابز کی نگرانی نہیں کرنا۔کرون جابز خاموشی سے ناکام ہو جاتی ہیں۔ Kubernetes کرون جابس معطل ہو گئے۔ S3 اسناد کی میعاد ختم ہو رہی ہے۔ ہر بیک اپ جاب کو مانیٹرنگ سسٹم کو کامیابی یا ناکامی کی اطلاع دینی چاہیے، اور اگر حالیہ کامیاب بیک اپ آپ کے RPO سے پرانا ہے تو الرٹ کریں۔

5. بیک اپ کے ساتھ ساتھ انکرپشن کیز کو اسٹور کرنا۔اگر کوئی حملہ آور آپ کے بیک اپ اسٹوریج تک رسائی حاصل کرتا ہے، تو اس کے پاس ڈکرپشن کلید بھی نہیں ہونی چاہیے۔ ایک سرشار راز مینیجر میں چابیاں اسٹور کریں۔

6. کوئی برقرار رکھنے کی پالیسی نہیں۔لائف سائیکل پالیسیوں کے بغیر، بیک اپ اسٹوریج بے حد بڑھتا ہے۔ واضح برقرار رکھنے والے ونڈوز کی وضاحت کریں: WAL سیگمنٹس کے لیے 7 دن، روزانہ بیک اپ کے لیے 30 دن، ماہانہ بیک اپ کے لیے 12 مہینے، اور ان کے حذف کو خودکار بنائیں۔

7. بیک اپ کارکردگی کے اثرات کو نظر انداز کرنا۔پرائمری ڈیٹا بیس پر مکمل بیک اپ چلانے کے اوقات کے دوران ایپلیکیشن کی کارکردگی میں کمی آتی ہے۔ کم ٹریفک والی ونڈوز کے دوران بیک اپ کا شیڈول بنائیں، یا کسی وقف شدہ نقل سے بیک اپ لیں۔

8.--single-transactionکے بغیر بڑے ڈیٹا بیس کے لیےmysqldumpکا استعمال۔اس جھنڈے کے بغیر،mysqldumpٹیبلز کو لاک کر دیتا ہے، ڈمپ کی مدت کے لیے رائٹ کو مسدود کرنا۔ بڑے ڈیٹا بیس کے لیے اس کا مطلب منٹوں یا گھنٹوں کے ڈاؤن ٹائم ہو سکتا ہے۔

9. ڈیٹا بیس کنفیگریشن کا بیک اپ لینا بھول جانا۔ڈیٹا کو بحال کرنا صرف آدھی جنگ ہے۔ اگر آپpostgresql.conf,pg_hba.conf,my.cnf, نقل کی ترتیبات اور صارف گرانٹس کھو دیتے ہیں تو آپ ڈیٹا بیس کو قابل استعمال حالت میں واپس نہیں لا سکتے۔ اپنے بیک اپ کے عمل میں کنفیگریشن فائلوں کو شامل کریں۔

10. بحالی کے طریقہ کار کی دستاویز نہیں کرنا۔بندش کے دوران، ڈیٹا بیس کو بحال کرنے والا شخص بیک اپ سیٹ کرنے والا شخص نہیں ہوسکتا ہے۔ ایک تحریری، آزمائشی رن بک اہم ہے۔

بیک اپ اسٹوریج کے لیے

لاگت کی اصلاح

بیک اپ سٹوریج کے اخراجات تیزی سے بڑھ سکتے ہیں، خاص طور پر بڑے ڈیٹا بیس کے بار بار مکمل بیک اپ کے ساتھ۔ یہ حکمت عملی بازیابی پر سمجھوتہ کیے بغیر اخراجات کو کنٹرول میں رکھتی ہیں۔

اضافی/تفرقی بیک اپ استعمال کریں۔ہفتہ وار فل پلس ڈیلی ڈیفرنس روزانہ مکمل بیک اپ کے مقابلے میں اسٹوریج کا ایک حصہ استعمال کرتا ہے۔ pgBackRest کی ڈیلٹا بحالی کی صلاحیت کا مطلب ہے کہ اضافی بیک اپ مکمل بیک اپ کی طرح تیزی سے بحال ہوتے ہیں۔

کمپریشن کو فعال کریں۔جدید کمپریشن الگورتھم جیسے zstd کم سے کم CPU اوور ہیڈ کے ساتھ بہترین کمپریشن تناسب (عام ڈیٹا بیس ڈیٹا کے لیے 5:1 سے 10:1) پیش کرتے ہیں۔ pgBackRest اور XtraBackup دونوں مقامی طور پر zstd کو سپورٹ کرتے ہیں۔

اسٹوریج ٹائرنگ کو لاگو کریں۔بیک اپ کو ان کی عمر کے ساتھ آہستہ آہستہ سستے اسٹوریج ٹائرز میں منتقل کریں۔ پہلے دکھائی گئی لائف سائیکل پالیسیاں (S3 Standard → IA → Glacier, GCS Standard → Nearline → Coldline) طویل مدتی ذخیرہ کرنے کے اخراجات کو 70-90% تک کم کر سکتی ہیں۔

جہاں ممکن ہو

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

دائیں سائز کی برقرار رکھنے والی ونڈوز۔بہت سی ٹیمیں بیک اپ کو ہمیشہ کے لیے احتیاط سے دور رکھنے کے لیے پہلے سے طے شدہ ہیں۔ اپنے اصل بحالی کے نمونوں اور تعمیل کے تقاضوں کا تجزیہ کریں، پھر مماثل برقراری سیٹ کریں۔ 7 سالہ برقرار رکھنے کی ضرورت زیادہ تر کلاؤڈ فراہم کنندگان پر $1/TB/ماہ سے کم میں گہری آرکائیو اسٹوریج استعمال کر سکتی ہے۔

# Cost comparison: Full vs Incremental backup storage
# Assuming 500 GB database, 5% daily change rate, 30-day retention

# Strategy A: Daily full backups
# 500 GB × 30 days = 15,000 GB = 15 TB
# S3 Standard: 15 TB × $0.023/GB = $345/month

# Strategy B: Weekly full + daily incremental
# 4 full × 500 GB = 2,000 GB
# 26 incremental × 25 GB = 650 GB
# Total: 2,650 GB ≈ 2.6 TB
# S3 Standard: 2.6 TB × $0.023/GB = $59.80/month

# Strategy C: Strategy B + lifecycle tiering
# Current week: 525 GB Standard = $12.08
# Weeks 2-4: 2,125 GB Standard-IA = $26.56
# Total: $38.64/month

# Savings: Strategy C is 89% cheaper than Strategy A

یہ سب ایک ساتھ رکھنا: ایک مکمل بیک اپ آرکیٹیکچر

یہاں MySQL اور PostgreSQL دونوں پر چلنے والے پیداواری ماحول کے لیے تجویز کردہ بیک اپ فن تعمیر ہے، جو Kubernetes پر ملٹی کلاؤڈ ڈیزاسٹر ریکوری کے ساتھ تعینات ہے۔

PostgreSQL کے لیے:

pgBackRest بنیادی بیک اپ ٹول کے بطور دو ریپوزٹریز (S3 + Azure Blob)
دونوں ریپوزٹریز
ہفتہ وار مکمل بیک اپ + روزانہ فرق (K8s CronJob کے ذریعے)
لانگ ہارن والیوم اسنیپ شاٹس
خودکار بحالی کی توثیق ہر بدھ
Prometheus بیک اپ کی عمر، ناکامی، اور اسٹوریج

MySQL کے لیے:

Percona XtraBackup S3
الگ اسٹوریج کے لیے مسلسل بائنری لاگ شپنگ
ہفتہ وار مکمل + روزانہ اضافہ (K8s CronJob کے ذریعے)
روزانہmysqldump
لانگ ہارن والیوم اسنیپ شاٹس ہر 4 گھنٹے میں
ہر جمعرات کو خودکار بحالی کی توثیق

Kubernetes کلسٹر کے لیے:

ویلرو ڈیٹا بیس کے نام کی جگہوں کا روزانہ بیک اپ پی وی اسنیپ شاٹس کے ساتھ
RKE2/k3s etcd سنیپ شاٹس ہر 6 گھنٹے بعد آف کلسٹر اسٹوریج پر
GitOps ریپوزٹری تمام مینی فیسٹس کے لیے سچائی کے ماخذ کے طور پر

ڈیزاسٹر ریکوری کے لیے:

S3 کراس ریجن کی نقل DR ریجن
Azure GRS برائے جیو فالتو بیک اپ کاپیاں
ماہانہ DR ڈرل: DR خطے میں بیک اپ سے مکمل کلسٹر دوبارہ تعمیر
ہر ناکامی کے منظر نامے کے لیے فیصلے کے درخت کے ساتھ دستاویزی رن بک

نتیجہ

ڈیٹا بیس بیک اپ آپ کے کاروبار اور ڈیٹا کے تباہ کن نقصان کے درمیان دفاع کی آخری لائن ہیں۔ اس مضمون میں بیان کردہ حکمت عملی — جسمانی اور منطقی بیک اپ، مسلسل WAL اور binlog آرکائیونگ، لائف سائیکل پالیسیوں کے ساتھ ملٹی کلاؤڈ اسٹوریج، ہر پرت پر انکرپشن، Kubernetes CronJobs کے ذریعے خودکار شیڈولنگ، اور منظم بحالی کی توثیق — پیداوار MySQLX اور ماحولیات کے لیے آرٹ کی موجودہ حالت کی نمائندگی کرتی ہیں۔

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