आपदा वसूली और RTO/RPO गाइड

यह दस्तावेज़ EKB AWS/EKS अवसंरचना के लिए आपदा वसूली (DR) रणनीति, वसूली समय लक्ष्य (RTO), और वसूली बिंदु लक्ष्य (RPO) का वर्णन करता है। इसमें अंतर्निहित HA क्षमताएँ, सक्रिय बैकअप सिस्टम, वसूली प्रक्रियाएँ और ज्ञात अंतराल शामिल हैं।

तैनाती निर्देशों के लिए, Terragrunt तैनाती गाइड देखें।

वास्तुकला और उच्च उपलब्धता सारांश

अवसंरचना घटक

घटक	कार्यान्वयन	HA मॉडल
कम्प्यूटिंग	EKS (Kubernetes 1.33) + Karpenter	Multi-AZ नोड्स, Spot + On-Demand
Pod autoscaling	KEDA	CPU/Memory-आधारित, न्यूनतम 2 रेप्लिकास
Ingress / SSL	ALB + ACM	Multi-AZ, हेल्थ-चेक रूटिंग
कैश	ElastiCache Redis (शर्तबद्ध)	स्वचालित failover के साथ Multi-AZ
मैसेज क्यू	Amazon MQ / RabbitMQ (शर्तबद्ध)	सिंगल-इंस्टैंस या active/standby
डेटाबेस (सेल्फ़-होस्टेड)	CloudNativePG HA क्लस्टर + PgBouncer	Primary + replicas, स्वचालित failover
डेटाबेस (क्लाउड)	Supabase Cloud	प्रबंधित, प्रदाता द्वारा क्रॉस-क्षेत्र
अवलोकन	SigNoz + k8s-infra (शर्तबद्ध)	क्लस्टर के अंदर, कोई एकल विफलता बिंदु नहीं
IaC स्टेट	S3 (वर्शन्ड) + DynamoDB lock	एन्क्रिप्टेड, वर्शन्ड
स्थायी volumes	EBS (EBS CSI Driver के माध्यम से)	AWS Data Lifecycle Manager के माध्यम से snapshots

वर्तमान HA क्षमताएँ

क्षमता	वसूली समय	डेटा हानि	स्थिति
AZ विफलता (pods)	0–5 मिनट	कोई नहीं	सक्रिय
Pod विफलता / क्रैश	0–2 मिनट	कोई नहीं	सक्रिय
ALB हेल्थ चेक री-रूटिंग	0–1 मिनट	कोई नहीं	सक्रिय
Redis Multi-AZ failover	< 1 मिनट	कोई नहीं	सक्रिय (जब सक्षम)
Karpenter node प्रतिस्थापन	0–10 मिनट	कोई नहीं	सक्रिय
EBS snapshot रिस्टोर	15–30 मिनट	24 घंटे तक	सक्रिय
CloudNativePG PITR रिस्टोर	15–60 मिनट	WAL लैग तक	सक्रिय (जब सक्षम)
पूर्ण अवसंरचना पुनर्निर्माण	30–60 मिनट	कोई नहीं (IaC)	Terragrunt के माध्यम से

RTO / RPO लक्ष्य

परिदृश्य	RTO लक्ष्य	RPO लक्ष्य	वर्तमान क्षमता
एकल pod विफलता	< 2 मिनट	0	पूरा (KEDA न्यूनतम रेप्लिकास)
एकल node विफलता	< 10 मिनट	0	पूरा (Karpenter प्रतिस्थापन)
AZ विफलता	< 5 मिनट	0	पूरा (Multi-AZ स्प्रेड)
Redis विफलता	< 1 मिनट	0	पूरा (Multi-AZ failover)
Postgres primary विफलता	< 5 मिनट	0–सेकंड WAL लैग	पूरा (CNPG स्वचालित failover)
EBS volume हानि	15–30 मिनट	< 24 घंटे	आंशिक — DLM दैनिक snapshots
पूर्ण क्षेत्र विफलता	> 60 मिनट	बैकअप आवृत्ति पर निर्भर	वर्तमान में स्वचालित नहीं

बैकअप सिस्टम

1. Terraform / Terragrunt स्टेट — S3

क्या बैकअप लिया जाता है: सभी अवसंरचना स्टेट (EKS, नेटवर्किंग, IAM, Helm releases)। कार्यान्वयन:

प्रति वातावरण S3 bucket: ekb-terraform-state-<env-name> (terragrunt/environments/<env-name>/state/ के माध्यम से बूटस्ट्रैप)
वर्शनिंग सक्षम — कोई भी पिछला स्टेट संस्करण पुनर्स्थापित किया जा सकता है
सर्वर-साइड एन्क्रिप्शन (AES-256)
स्टेट लॉकिंग के लिए DynamoDB टेबल

वसूली: S3 में किसी भी पिछली स्थिति संस्करण पर वापस जाएँ, फिर terragrunt apply पुनः चलाएँ। RPO: प्रत्येक terragrunt apply कमिट — लगातार।

2. EBS स्थायी volumes — AWS Data Lifecycle Manager

क्या बैकअप लिया जाता है: pods से जुड़े EBS volumes (Automator PostgreSQL, Supabase MinIO, कोई भी स्टेटफुल वर्कलोड)। कार्यान्वयन: वातावरण टैग्स को लक्षित करने वाली AWS Data Lifecycle Manager (DLM) नीति।

# अपने वातावरण के नाम से EBS volumes को टैग करें, फिर DLM नीति बनाएँ:
# - संसाधन: EBS volumes
# - लक्ष्य टैग: Environment=<your-env-name>
# - शेड्यूल: 02:00 UTC पर दैनिक
# - प्रतिधारण: 7 snapshots

वसूली:

# 1. रिस्टोर करने के लिए snapshot पहचानें
aws ec2 describe-snapshots --filters "Name=tag:Environment,Values=<your-env-name>"
 
# 2. snapshot से volume बनाएँ
aws ec2 create-volume \
  --snapshot-id snap-xxxxxxxxxxxxxxxxx \
  --availability-zone <your-az> \
  --volume-type gp3
 
# 3. Kubernetes में PersistentVolume को नए volume ID को संदर्भित करने के लिए अपडेट करें
kubectl patch pv <pv-name> -p '{"spec":{"awsElasticBlockStore":{"volumeID":"<new-vol-id>"}}}'

RPO: 24 घंटे तक (दैनिक snapshots)। DLM शेड्यूल आवृत्ति बढ़ाकर कम करें।

3. CloudNativePG (HA Supabase DB) — Barman Cloud बैकअप

लागू: ENABLE_CNPG=true और ENABLE_HA_SUPABASE_DB=true वाले वातावरण। क्या बैकअप लिया जाता है: CloudNativePG Postgres क्लस्टर (ha-supabase-db), जिसमें S3 या MinIO तक लगातार WAL (Write-Ahead Log) streaming, और CNPG ScheduledBackup CRD के माध्यम से अनुसूचित पूर्ण base backups शामिल हैं। कार्यान्वयन (values/ha-supabase-db.yaml में कॉन्फ़िगर):

postgres:
  backup:
    enabled: true                    # barman-cloud backups टॉगल करें
    # barmanObjectStore S3 bucket या MinIO endpoint की ओर इशारा करता है
    # IRSA / service account के पास s3:PutObject, s3:GetObject, s3:ListBucket होना चाहिए
    retentionPolicy: "30d"           # बैकअप 30 दिन रखें
    compression: gzip

बैकअप स्थिति सत्यापित करें:

# क्लस्टर के लिए सभी बैकअप सूचीबद्ध करें
kubectl get backup -n ha-supabase-db
 
# विशिष्ट बैकअप जाँचें
kubectl describe backup <backup-name> -n ha-supabase-db
 
# माँग पर बैकअप ट्रिगर करें
kubectl cnpg backup ha-supabase-db -n ha-supabase-db

बिंदु-समय वसूली (PITR):

# एक नया CNPG Cluster बनाएँ जो backup से रिस्टोर कर रहा है
# (नए namespace में या मूल को हटाने के बाद)
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: ha-supabase-db-restored
  namespace: ha-supabase-db-restore
spec:
  instances: 3
  bootstrap:
    recovery:
      source: ha-supabase-db
      recoveryTarget:
        targetTime: "2026-03-19T03:00:00.000000+00:00"  # लक्ष्य बिंदु-समय
  externalClusters:
    - name: ha-supabase-db
      barmanObjectStore:
        # स्रोत क्लस्टर जैसा ही S3/MinIO कॉन्फ़िगरेशन
        serverName: ha-supabase-db

RPO: WAL-सक्षम क्लस्टर्स के लिए लगभग शून्य (सेकंड का लैग, WAL अपलोड अंतराल से सीमित)।

4. ElastiCache Redis — Multi-AZ रिप्लिकेशन

लागू: ENABLE_AWS_SERVICES=true वाले वातावरण। Redis प्राथमिक डेटा स्टोर नहीं है — यह अस्थायी कैश और सत्र डेटा रखता है। DR का ध्यान बैकअप/रिस्टोर की तुलना में तेज़ failover पर है। कार्यान्वयन:

स्वचालित failover के साथ Multi-AZ सक्षम
रेस्ट और ट्रांज़िट में एन्क्रिप्शन
प्राथमिक node विफलता स्वचालित रूप से replica को प्रमोट करती है (< 1 मिनट)

RPO: Redis डेटा डिज़ाइन के अनुसार अस्थायी है। failover के बाद कैश मिस होने की उम्मीद है; एप्लिकेशन डेटाबेस से पुनः भरता है।

5. Amazon MQ (RabbitMQ) — मैसेज क्यू

लागू: ENABLE_AWS_SERVICES=true वाले वातावरण। कार्यान्वयन:

सिंगल-इंस्टैंस (डिफ़ॉल्ट) या active/standby तैनाती
broker पुनरारंभ के दौरान in-flight संदेश खो सकते हैं; consumers को idempotent बनाएँ
Management UI पोर्ट 15671 (SSL) पर उपलब्ध

RPO: सिंगल-इंस्टैंस — विफलता के समय in-flight संदेश खो सकते हैं। इस जोखिम को कम करने के लिए active/standby तैनाती मोड का उपयोग करें।

स्वतः वसूली तंत्र

Karpenter — Node प्रोविज़निंग और वसूली

समेकन: WhenEmptyOrUnderutilized — निष्क्रिय नोड्स स्वचालित रूप से समाप्त हो जाते हैं
Spot interruption handling: SQS interruption events सुनता है; समाप्ति से पहले Spot नोड्स को drain और प्रतिस्थापित करता है
Node drift: पुराने AMIs या कॉन्फ़िगरेशन का उपयोग करने वाले नोड्स enable_drift = true होने पर स्वचालित रूप से प्रतिस्थापित हो जाते हैं
वसूली समय: नया node 0–10 मिनट में प्रोविज़न

KEDA — Pod Autoscaling

न्यूनतम रेप्लिकास: सभी सेवाओं (Web, API, Celery, Automator) के लिए 2 — एकल-विफलता बिंदु को रोकता है
CPU सीमा: 60–70% स्केल-आउट ट्रिगर करता है
मेमोरी सीमा: 80% स्केल-आउट ट्रिगर करता है
स्केल-डाउन स्थिरता: 30 सेकंड — flapping से बचाता है
वसूली समय: विफल pods 0–2 मिनट में पुनः शेड्यूल

Kubernetes Pod Anti-Affinity

सभी रहित सेवाएँ nodes और AZs में pods को फैलाने के लिए kubernetes.io/hostname पर preferredDuringSchedulingIgnoredDuringExecution anti-affinity का उपयोग करती हैं।

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["web", "fastapi-backend", "celery-worker", "automator"]
        topologyKey: kubernetes.io/hostname

वसूली प्रक्रियाएँ

परिदृश्य 1: AZ विफलता

अपेक्षित व्यवहार: Karpenter शेष AZs में प्रतिस्थापन नोड्स प्रोविज़न करता है; KEDA pods को पुनः शेड्यूल करता है; ALB अस्वस्थ लक्ष्यों पर रूटिंग बंद कर देता है। सत्यापन:

kubectl get nodes -o wide     # पुष्टि करें कि नोड्स स्वस्थ AZs में हैं
kubectl get pods -A -o wide   # पुष्टि करें कि pods चल रहे हैं
kubectl get ingress            # पुष्टि करें कि ALB सही ढंग से रूट कर रहा है

सामान्य परिस्थितियों में कोई मैनुअल हस्तक्षेप आवश्यक नहीं है।

परिदृश्य 2: Postgres Primary Node विफलता (CloudNativePG)

CloudNativePG एक replica को primary में स्वचालित रूप से प्रमोट करता है।

# failover की निगरानी करें
kubectl get cluster ha-supabase-db -n ha-supabase-db -w
 
# नए primary की पुष्टि करें
kubectl cnpg status ha-supabase-db -n ha-supabase-db
 
# जाँचें कि PgBouncer pooler नए primary की ओर इशारा कर रहा है
kubectl get svc -n ha-supabase-db | grep pooler

एप्लिकेशन PgBouncer के माध्यम से पुनः कनेक्ट करते हैं — कनेक्शन स्ट्रिंग बदलने की आवश्यकता नहीं।

परिदृश्य 3: Snapshot से EBS Volume रिस्टोर

# 1. वातावरण के लिए snapshots खोजें
aws ec2 describe-snapshots \
  --filters "Name=tag:Environment,Values=<your-env-name>" \
  --query 'Snapshots[*].[SnapshotId,StartTime,VolumeSize]' \
  --output table
 
# 2. चयनित snapshot से नया volume बनाएँ
aws ec2 create-volume \
  --snapshot-id snap-xxxxxxxxxxxxxxxxx \
  --availability-zone <target-az> \
  --volume-type gp3 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Environment,Value=<your-env-name>}]'
 
# 3. प्रभावित वर्कलोड को स्केल-डाउन करें
kubectl scale deployment <workload> --replicas=0
 
# 4. PV को नए EBS volume को संदर्भित करने के लिए अपडेट करें, फिर स्केल-अप करें
kubectl patch pv <pv-name> -p '{"spec":{"csi":{"volumeHandle":"<new-volume-id>"}}}'
kubectl scale deployment <workload> --replicas=2

परिदृश्य 4: पूर्ण अवसंरचना पुनर्निर्माण

विनाशकारी विफलता या क्षेत्र के पुनर्निर्माण के बाद उपयोग किया जाता है।

# 1. स्टेट bucket बूटस्ट्रैप करें (यदि मौजूद नहीं है)
cd terragrunt/environments/<your-env-name>/state
terragrunt apply
 
# 2. EKS क्लस्टर और मूल अवसंरचना पुनर्निर्मित करें
cd terragrunt/environments/<your-env-name>
terragrunt apply
 
# 3. क्रम में सेवाएँ तैनात करें (Terragrunt तैनाती गाइड § चरण 6 देखें)
ENABLE_CNPG=true terragrunt apply --target='helm_release.local["cloudnative-pg"]'
ENABLE_HA_SUPABASE_DB=true terragrunt apply --target='helm_release.local["ha-supabase-db"]'
ENABLE_SUPABASE=true terragrunt apply --target='helm_release.local["supabase"]'

अनुमानित RTO: पूर्ण क्लस्टर के लिए 30–60 मिनट; यदि EBS/CNPG डेटा रिस्टोर करना हो तो 60–120 मिनट।

परिदृश्य 5: Terragrunt स्टेट वापसी

# S3 में स्टेट संस्करण सूचीबद्ध करें
aws s3api list-object-versions \
  --bucket ekb-terraform-state-<your-env-name> \
  --prefix <state-key>
 
# विशिष्ट संस्करण पुनर्स्थापित करें
aws s3api get-object \
  --bucket ekb-terraform-state-<your-env-name> \
  --key <state-key> \
  --version-id <version-id> \
  terraform.tfstate
 
# पुनर्स्थापित स्टेट के साथ पुनः आयात या लागू करें

अवलोकन और अलर्टिंग (SigNoz)

ENABLE_SIGNOZ=true होने पर, SigNoz monitoring namespace में तैनात होता है और प्रदान करता है:

सभी EKB सेवाओं के लिए वितरित tracing
k8s-infra DaemonSet agent के माध्यम से क्लस्टर मेट्रिक्स (CPU, मेमोरी, pod स्थिति)
सभी pods से लॉग एकत्रीकरण
अलर्टिंग — pod crash loops, उच्च त्रुटि दरों, या node दबाव पर सूचित करने के लिए SigNoz में अलर्ट नियम कॉन्फ़िगर करें

DR उद्देश्यों के लिए, SigNoz डैशबोर्ड घटना के बाद निदान और वसूली की पुष्टि करने का प्राथमिक उपकरण हैं। SigNoz डेटा स्वयं EBS PVs पर संग्रहीत है और EBS snapshot नीति के अंतर्गत आता है।

अंतराल और सिफारिशें

अंतराल	जोखिम	सिफारिश
कोई क्रॉस-क्षेत्र रिप्लिकेशन नहीं	पूर्ण क्षेत्र विफलता = विस्तारित RTO	CNPG बैकअप के लिए RDS क्रॉस-क्षेट्र read replica या S3 क्रॉस-क्षेत्र रिप्लिकेशन पर विचार करें
EBS snapshots दैनिक हैं	EBS-समर्थित वर्कलोड के लिए 24 घंटे तक डेटा हानि	महत्वपूर्ण volumes के लिए DLM आवृत्ति प्रति घंटा बढ़ाएँ
RabbitMQ सिंगल-इंस्टैंस (डिफ़ॉल्ट)	broker विफलता पर in-flight संदेश खोए	उत्पादन के लिए `ACTIVE_STANDBY_MULTI_AZ` तैनाती मोड में स्विच करें
कोई स्वचालित DR ड्रिल नहीं	वसूली प्रक्रियाएँ आवश्यक होने तक परखी नहीं जातीं	त्रैमासिक वसूली ड्रिल शेड्यूल करें; staging वातावरण में CNPG PITR रिस्टोर का परीक्षण करें
एक ही क्लस्टर पर SigNoz	क्लस्टर विफलता के दौरान अवलोकन खो जाता है	अलग हल्का निगरानी endpoint या CloudWatch फ़ॉलबैक अलर्ट पर विचार करें

Get Started!

Offerings

Chat

Agents

Knowledge Base

Workflows

Public Chatbot

Project Settings

My Account

Platform Admin

SDK

General Information

आपदा वसूली और RTO/RPO गाइड

वास्तुकला और उच्च उपलब्धता सारांश

अवसंरचना घटक

वर्तमान HA क्षमताएँ

RTO / RPO लक्ष्य

बैकअप सिस्टम

1. Terraform / Terragrunt स्टेट — S3

2. EBS स्थायी volumes — AWS Data Lifecycle Manager

3. CloudNativePG (HA Supabase DB) — Barman Cloud बैकअप

4. ElastiCache Redis — Multi-AZ रिप्लिकेशन

5. Amazon MQ (RabbitMQ) — मैसेज क्यू

स्वतः वसूली तंत्र

Karpenter — Node प्रोविज़निंग और वसूली

KEDA — Pod Autoscaling

Kubernetes Pod Anti-Affinity

वसूली प्रक्रियाएँ

परिदृश्य 1: AZ विफलता

परिदृश्य 2: Postgres Primary Node विफलता (CloudNativePG)

परिदृश्य 3: Snapshot से EBS Volume रिस्टोर

परिदृश्य 4: पूर्ण अवसंरचना पुनर्निर्माण

परिदृश्य 5: Terragrunt स्टेट वापसी

अवलोकन और अलर्टिंग (SigNoz)

अंतराल और सिफारिशें

​वास्तुकला और उच्च उपलब्धता सारांश

​अवसंरचना घटक

​वर्तमान HA क्षमताएँ

​RTO / RPO लक्ष्य

​बैकअप सिस्टम

​1. Terraform / Terragrunt स्टेट — S3

​2. EBS स्थायी volumes — AWS Data Lifecycle Manager

​3. CloudNativePG (HA Supabase DB) — Barman Cloud बैकअप

​4. ElastiCache Redis — Multi-AZ रिप्लिकेशन

​5. Amazon MQ (RabbitMQ) — मैसेज क्यू

​स्वतः वसूली तंत्र

​Karpenter — Node प्रोविज़निंग और वसूली

​KEDA — Pod Autoscaling

​Kubernetes Pod Anti-Affinity

​वसूली प्रक्रियाएँ

​परिदृश्य 1: AZ विफलता

​परिदृश्य 2: Postgres Primary Node विफलता (CloudNativePG)

​परिदृश्य 3: Snapshot से EBS Volume रिस्टोर

​परिदृश्य 4: पूर्ण अवसंरचना पुनर्निर्माण

​परिदृश्य 5: Terragrunt स्टेट वापसी

​अवलोकन और अलर्टिंग (SigNoz)

​अंतराल और सिफारिशें

वास्तुकला और उच्च उपलब्धता सारांश

अवसंरचना घटक

वर्तमान HA क्षमताएँ

RTO / RPO लक्ष्य

बैकअप सिस्टम

1. Terraform / Terragrunt स्टेट — S3

2. EBS स्थायी volumes — AWS Data Lifecycle Manager

3. CloudNativePG (HA Supabase DB) — Barman Cloud बैकअप

4. ElastiCache Redis — Multi-AZ रिप्लिकेशन

5. Amazon MQ (RabbitMQ) — मैसेज क्यू

स्वतः वसूली तंत्र

Karpenter — Node प्रोविज़निंग और वसूली

KEDA — Pod Autoscaling

Kubernetes Pod Anti-Affinity

वसूली प्रक्रियाएँ

परिदृश्य 1: AZ विफलता

परिदृश्य 2: Postgres Primary Node विफलता (CloudNativePG)

परिदृश्य 3: Snapshot से EBS Volume रिस्टोर

परिदृश्य 4: पूर्ण अवसंरचना पुनर्निर्माण

परिदृश्य 5: Terragrunt स्टेट वापसी

अवलोकन और अलर्टिंग (SigNoz)

अंतराल और सिफारिशें