उत्पादन डेटाबेस बैकअप रणनीतियाँ जो वास्तव में काम करती हैं: MySQL और PostgreSQL

उत्पादन डेटा खोना एक ऐसी घटना है जो करियर को समाप्त कर देती है, कंपनियों को बंद कर देती है और सभी गलत कारणों से हैकर समाचार का पहला पृष्ठ बन जाती है। फिर भी अधिकांश टीमें डेटाबेस बैकअप को एक बाद का विचार मानती हैं - एक क्रॉन जॉब जिसे किसी ने दो साल पहले स्थापित किया था, जिसे तब से किसी ने सत्यापित नहीं किया है। यह आलेख MySQL और PostgreSQL के लिए युद्ध-परीक्षणित बैकअप रणनीतियों को प्रस्तुत करता है जो एकल-नोड k3s क्लस्टर से लेकर बहु-क्षेत्रीय क्लाउड परिनियोजन तक के उत्पादन वातावरण में प्रतिदिन लाखों लेनदेन को संसाधित करने में सिद्ध हुए हैं।

हम पूर्ण स्पेक्ट्रम को कवर करेंगे: तार्किक और भौतिक बैकअप विधियां, पॉइंट-इन-टाइम पुनर्प्राप्ति, स्वचालित शेड्यूलिंग, क्लाउड स्टोरेज लक्ष्य, एन्क्रिप्शन, सत्यापन, Kubernetes-मूल दृष्टिकोण, और आपदा पुनर्प्राप्ति योजना जो इसे एक साथ जोड़ती है। प्रत्येक अनुशंसा ठोस कॉन्फ़िगरेशन और कोड के साथ आती है जिसे आप अपने परिवेश के अनुसार अनुकूलित कर सकते हैं।

बैकअप प्रकार को समझना

विशिष्ट उपकरणों में गोता लगाने से पहले, आपको चार मूलभूत बैकअप रणनीतियों के एक स्पष्ट मानसिक मॉडल की आवश्यकता है और वे पुनर्प्राप्ति उद्देश्यों के साथ कैसे बातचीत करते हैं। प्रत्येक रणनीति बैकअप गति, भंडारण खपत और पुनर्प्राप्ति समय के बीच एक अलग समझौता करती है।

एकपूर्ण बैकअपएक ही समय में संपूर्ण डेटाबेस को कैप्चर करता है। यह तर्क करने में सबसे सरल और पुनर्स्थापित करने में सबसे तेज़ है, लेकिन भंडारण में सबसे महंगा और बनाने में सबसे धीमा है। एकवृद्धिशील बैकअपकेवल उस डेटा को कैप्चर करता है जो किसी भी प्रकार के अंतिम बैकअप के बाद से बदल गया है। इसे बनाना और भंडारण में कॉम्पैक्ट करना तेज़ है, लेकिन पुनर्स्थापन के लिए पूरी श्रृंखला को दोबारा चलाने की आवश्यकता होती है: अंतिम पूर्ण बैकअप और प्रत्येक बाद की वृद्धिशील।डिफरेंशियल बैकअपवह सब कुछ कैप्चर करता है जो पिछले पूर्ण बैकअप के बाद से बदल गया है। यह एक मध्य मार्ग पर है - वृद्धिशील से बड़ा लेकिन पुनर्स्थापित करना आसान है क्योंकि आपको केवल अंतिम पूर्ण और नवीनतम अंतर की आवश्यकता है। अंत में,निरंतर संग्रह(PostgreSQL में WAL संग्रह, MySQL में बाइनरी लॉग स्ट्रीमिंग) प्रत्येक व्यक्तिगत लेनदेन को कैप्चर करता है, जैसा कि होता है, बैकअप के बीच किसी भी क्षण में पॉइंट-इन-टाइम पुनर्प्राप्ति सक्षम करता है।

अधिकांश उत्पादन प्रणालियों के लिए इष्टतम रणनीति एक संयोजन है: साप्ताहिक पूर्ण बैकअप, दैनिक वृद्धिशील या अंतर, और निरंतर वाल/बिनलॉग संग्रह। यह आपको हाल के पूर्ण बैकअप से तेजी से पुनर्प्राप्ति और आवश्यकता पड़ने पर किसी भी समय पुनर्प्राप्त करने की क्षमता प्रदान करता है।

MySQL बैकअप विधियाँ

MySQL कई बैकअप टूल प्रदान करता है, जिनमें से प्रत्येक विभिन्न डेटाबेस आकार और पुनर्प्राप्ति आवश्यकताओं के लिए उपयुक्त है। सही विकल्प आपके डेटा की मात्रा, स्वीकार्य बैकअप विंडो और आरटीओ/आरपीओ लक्ष्यों पर निर्भर करता है।

mysqldump - यूनिवर्सल लॉजिकल बैकअप

mysqldumpSQL स्टेटमेंट तैयार करता है जो स्कीमा और डेटा को दोबारा बनाता है। यह प्रत्येक MySQL संस्करण और स्टोरेज इंजन पर काम करता है, जो इसे सार्वभौमिक फ़ॉलबैक बनाता है। हालाँकि, यह डंप के दौरान तालिकाओं को लॉक कर देता है (जब तक कि InnoDB के साथ--single-transactionका उपयोग नहीं किया जाता है), और 50-100 जीबी से अधिक के डेटाबेस के लिए पुनर्स्थापना गति काफी कम हो जाती है क्योंकि यह व्यक्तिगत 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

पेरकोना एक्स्ट्राबैकअप - InnoDB

50 जीबी से बड़े डेटाबेस के लिए, तार्किक बैकअप अव्यावहारिक हो जाता है - बैकअप विंडो और पुनर्स्थापना समय दोनों डेटा आकार के साथ रैखिक रूप से बढ़ते हैं। 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 बैकअप विधियाँ

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 डेटा निर्देशिका की एक भौतिक प्रतिलिपि लेता है। यह स्टैंडअलोन पुनर्प्राप्ति और स्ट्रीमिंग प्रतिकृति सेटअप दोनों के लिए आधार है। वाल संग्रह के साथ संयुक्त, यह पॉइंट-इन-टाइम पुनर्प्राप्ति को सक्षम बनाता है।

# 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 बैकअप प्रबंधन के लिए स्वर्ण मानक है। यह पूर्ण, वृद्धिशील और विभेदक बैकअप, समानांतर बैकअप और पुनर्स्थापना, एन्क्रिप्शन, मल्टी-रिपॉजिटरी लक्ष्य (स्थानीय डिस्क, एस 3, जीसीएस, एक्सपीआर 7 एक्स ब्लॉब), और स्वचालित वाल संग्रह का समर्थन करता है - सभी एक एकल, सुसंगत कॉन्फ़िगरेशन के माध्यम से।

# /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 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

MySQL

PITR

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 ब्लॉब, या GCS पर शिपिंग करते समय, क्लाइंट SDK डिफ़ॉल्ट रूप से HTTPS का उपयोग करते हैं।

एन्क्रिप्शन बाकीमें दो परतें हैं। सर्वर-साइड एन्क्रिप्शन (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 वॉल्ट, AWS सीक्रेट मैनेजर, या Azure कुंजी वॉल्ट जैसे एक रहस्य प्रबंधक अनुशंसित दृष्टिकोण है। यदि आप कुंजी को बैकअप के साथ संग्रहीत करते हैं, तो आपके बैकअप संग्रहण तक पहुंच प्राप्त करने वाले हमलावर के पास वह सब कुछ होता है जिसकी उसे आवश्यकता होती है।

स्वचालित बैकअप शेड्यूलिंग

मैनुअल बैकअप बैकअप नहीं हैं - वे आकांक्षाएं हैं। बैकअप शेड्यूल को स्वचालित, मॉनिटर किया जाना चाहिए और विफलता पर सचेत किया जाना चाहिए।

सिस्टम क्रॉन

# /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 परिवेश में, CronJobs सिस्टम क्रॉन को प्रतिस्थापित करता है। वे क्लस्टर के 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 संसाधनों (तैनाती, सेवाएँ, कॉन्फिगमैप्स, रहस्य) और लगातार वॉल्यूम का बैकअप लेता है। यह एप्लिकेशन-स्तरीय डेटाबेस बैकअप के लिए प्रतिस्थापन नहीं है - यह पीवी के क्रैश-संगत स्नैपशॉट को कैप्चर करता है, जो डेटाबेस के लिए लेनदेन के अनुरूप नहीं हो सकता है। क्लस्टर पुनर्प्राप्ति के लिए वेलेरो और डेटाबेस पुनर्प्राप्ति के लिए एप्लिकेशन-स्तरीय टूल (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 परिनियोजन आमतौर पर लॉन्गहॉर्न को अपने CSI भंडारण प्रदाता के रूप में उपयोग करते हैं। लॉन्गहॉर्न वॉल्यूम-स्तरीय स्नैपशॉट और 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 के लिए) बैकअप प्रबंधन को सीधे डेटाबेस जीवनचक्र में एकीकृत करते हैं। ऑपरेटर कस्टम संसाधनों के माध्यम से शेड्यूलिंग, वाल संग्रह और प्रतिधारण को स्वचालित रूप से संभालता है।

# 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 और ऑरोरा

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 - लचीला सर्वर

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 - क्लाउड SQL

क्लाउड SQL बॉक्स से बाहर स्वचालित बैकअप और पॉइंट-इन-टाइम रिकवरी प्रदान करता है। जीसीई या जीकेई पर स्व-प्रबंधित डेटाबेस के लिए, नियरलाइन और कोल्डलाइन स्टोरेज कक्षाओं के साथ जीसीएस लागत प्रभावी दीर्घकालिक बैकअप स्टोरेज प्रदान करता है।

# 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)- आप कितना डेटा खोने का जोखिम उठा सकते हैं। ये संख्याएँ बैकअप आवृत्ति, विधि और वास्तुकला के बारे में हर निर्णय को संचालित करती हैं।

शून्य आरपीओ के लिए, आपको कम से कम एक स्टैंडबाय के लिए तुल्यकालिक प्रतिकृति की आवश्यकता है। यह प्रत्येक लिखित लेनदेन में विलंबता जोड़ता है लेकिन गारंटी देता है कि कोई भी प्रतिबद्ध लेनदेन खो नहीं गया है। अधिकांश उत्पादन प्रणालियाँ निरंतर वाल/बिनलॉग संग्रह के साथ अतुल्यकालिक स्ट्रीमिंग प्रतिकृति का उपयोग करके लगभग-शून्य आरपीओ (संभावित हानि के सेकंड) स्वीकार करती हैं, जो लेखन-विलंबता दंड से बचाती है।

डिजास्टर रिकवरी रनबुक टेम्पलेट

# 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 क्रेडेंशियल समाप्त हो रहे हैं. प्रत्येक बैकअप कार्य को निगरानी प्रणाली को सफलता या विफलता की रिपोर्ट करनी चाहिए, और यदि सबसे हालिया सफल बैकअप आपके आरपीओ से पुराना है तो सचेत करें।

5. बैकअप के साथ एन्क्रिप्शन कुंजी संग्रहीत करना।यदि कोई हमलावर आपके बैकअप स्टोरेज तक पहुंच प्राप्त करता है, तो उसके पास डिक्रिप्शन कुंजी भी नहीं होनी चाहिए। एक समर्पित रहस्य प्रबंधक में चाबियाँ संग्रहीत करें।

6. कोई प्रतिधारण नीति नहीं।जीवनचक्र नीतियों के बिना, बैकअप संग्रहण असीमित रूप से बढ़ता है। स्पष्ट अवधारण विंडो को परिभाषित करें: वाल सेगमेंट के लिए 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 का समर्थन करते हैं।

स्टोरेज टियरिंग लागू करें।बैकअप को पुराने होने के साथ उत्तरोत्तर सस्ते स्टोरेज स्तरों पर ले जाएं। पहले दिखाई गई जीवनचक्र नीतियां (एस3 मानक → आईए → ग्लेशियर, जीसीएस मानक → नियरलाइन → कोल्डलाइन) दीर्घकालिक भंडारण लागत को 70-90% तक कम कर सकती हैं।

जहां संभव हो वहां डुप्लिकेट करें।pgBackRest अपने रिपॉजिटरी में ब्लॉक-स्तरीय डिडुप्लीकेशन का उपयोग करता है, केवल बदले हुए ब्लॉक को बैकअप में संग्रहीत करता है। यह उन डेटाबेस के लिए भंडारण को नाटकीय रूप से कम कर देता है जहां अधिकांश डेटा स्थिर है।

सही आकार की रिटेंशन विंडो।कई टीमें बैकअप को हमेशा के लिए सावधानी से बाहर रखने में चूक करती हैं। अपने वास्तविक पुनर्प्राप्ति पैटर्न और अनुपालन आवश्यकताओं का विश्लेषण करें, फिर उससे मेल खाने वाला प्रतिधारण सेट करें। अधिकांश क्लाउड प्रदाताओं पर 7-वर्षीय प्रतिधारण आवश्यकता $1/टीबी/माह से कम पर गहरे संग्रह भंडारण का उपयोग कर सकती है।

# 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 ब्लॉब)
के साथ प्राथमिक बैकअप टूल के रूप में
• दोनों रिपॉजिटरी
में सतत वाल संग्रह
• साप्ताहिक पूर्ण बैकअप + दैनिक अंतर (K8s CronJob के माध्यम से)
• तेज रोलबैक के लिए हर 4 घंटे में लॉन्गहॉर्न वॉल्यूम स्नैपशॉट
• प्रत्येक बुधवार को स्वचालित पुनर्स्थापना सत्यापन
• Prometheus बैकअप आयु, विफलता और भंडारण पर अलर्ट के साथ निगरानी

MySQL के लिए:

भौतिक बैकअप के लिए
• पेरकोना एक्स्ट्राबैकअप S3
पर स्ट्रीम किया गया
• भंडारण को अलग करने के लिए निरंतर बाइनरी लॉग शिपिंग
• साप्ताहिक पूर्ण + दैनिक वृद्धिशील (K8s CronJob के माध्यम से)
• पोर्टेबल लॉजिकल बैकअप के लिए महत्वपूर्ण स्कीमाओं का दैनिकmysqldump
• लॉन्गहॉर्न वॉल्यूम स्नैपशॉट हर 4 घंटे
• प्रत्येक गुरुवार को स्वचालित पुनर्स्थापना सत्यापन

Kubernetes क्लस्टर के लिए:

• वेलेरो पीवी स्नैपशॉट
के साथ डेटाबेस नेमस्पेस का दैनिक बैकअप
• RKE2/k3s हर 6 घंटे में स्नैपशॉट को ऑफ-क्लस्टर स्टोरेज
पर सेट करता है सभी अभिव्यक्तियों के लिए सत्य के स्रोत के रूप में
• GitOps भंडार

आपदा पुनर्प्राप्ति के लिए:

• S3 क्रॉस-क्षेत्र प्रतिकृति DR क्षेत्र
पर भू-अनावश्यक बैकअप प्रतियों के लिए
• Azure GRS
• मासिक डीआर ड्रिल: डीआर क्षेत्र में बैकअप से पूर्ण क्लस्टर पुनर्निर्माण
• प्रत्येक विफलता परिदृश्य के लिए निर्णय वृक्ष के साथ प्रलेखित रनबुक

निष्कर्ष

डेटाबेस बैकअप आपके व्यवसाय और भयावह डेटा हानि के बीच रक्षा की अंतिम पंक्ति है। इस लेख में उल्लिखित रणनीतियाँ - भौतिक और तार्किक बैकअप, निरंतर वाल और बिनलॉग संग्रह, जीवनचक्र नीतियों के साथ मल्टी-क्लाउड स्टोरेज, हर परत पर एन्क्रिप्शन, Kubernetes CronJobs के माध्यम से स्वचालित शेड्यूलिंग, और व्यवस्थित पुनर्स्थापना सत्यापन - उत्पादन MySQL और PostgreSQL वातावरण के लिए कला की वर्तमान स्थिति का प्रतिनिधित्व करते हैं।

सबसे महत्वपूर्ण उपाय यह है:एक बैकअप रणनीति अपने पिछले सफल पुनर्स्थापना परीक्षणजितनी ही अच्छी है। इस आलेख में प्रत्येक टूल, स्क्रिप्ट और आर्किटेक्चर पैटर्न एक उद्देश्य की पूर्ति के लिए मौजूद है - यह सुनिश्चित करना कि जब सबसे खराब स्थिति हो, तो आप अपना डेटा पुनर्प्राप्त कर सकते हैं, अपनी आरटीओ और आरपीओ प्रतिबद्धताओं को पूरा कर सकते हैं, और अपना व्यवसाय चालू रख सकते हैं। अपना बैकअप सिस्टम बनाएं, उसे स्वचालित करें, उसकी निगरानी करें, उसका परीक्षण करें और फिर उसका पुन: परीक्षण करें। आपका भविष्य स्वयं आपको धन्यवाद देगा।