Velero से Kubernetes बैकअप: परखी गई गाइड

छोटा जवाब: Kubernetes क्लस्टर का बैकअप लेने का मतलब है तीन अलग-अलग चीज़ों का बैकअप लेना — API ऑब्जेक्ट (Deployments, Services, Secrets, CRD), परसिस्टेंट वॉल्यूम, और एप्लिकेशन डेटा उसके तार्किक स्वरूप में (एक pg_dump, केवल ब्लॉक स्नैपशॉट नहीं)। Velero पहले दो को संभालता है: OVHcloud या Scaleway के S3 बकेट के साथ इंस्टॉल करने पर एक SME क्लस्टर के लिए स्टोरेज की लागत महीने में लगभग 1 से 5 € आती है, और यह किसी namespace का बैकअप कुछ मिनटों में ले लेता है। तीसरी ज़िम्मेदारी आपकी रहती है, और असल में वही आपको बचाएगी।

बातचीत हमेशा एक ही तरह शुरू होती है। क्लस्टर चल रहा है, CI डिप्लॉय कर रही है, वॉल्यूम प्रोवाइडर के रेप्लिकेटेड ब्लॉक स्टोरेज पर हैं — तो "बैकअप तो हो गया"। फिर कोई शुक्रवार शाम kubectl delete ns से ग़लत namespace हटा देता है, या कोई helm uninstall ऐसे PVC को ले जाता है जिसकी reclaimPolicy Delete पर सेट थी, और तब पता चलता है कि रेप्लिकेटेड ब्लॉक स्टोरेज डिस्क ख़राब होने से बचाता है, इंसानी ग़लती से नहीं।

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

क्लस्टर में ठीक-ठीक किसका बैकअप ज़रूरी है

समस्या को टुकड़ों में बाँटें। किसी SME एप्लिकेशन को चलाने वाले Kubernetes क्लस्टर में डेटा की चार श्रेणियाँ होती हैं, और इनका बैकअप एक जैसा नहीं होता।

इस तालिका में दो चिरपरिचित जाल हैं।

पहला: वॉल्यूम स्नैपशॉट किसी डेटाबेस का सुसंगत बैकअप नहीं है। PostgreSQL के लिखते समय लिया गया CSI स्नैपशॉट अच्छे से अच्छे मामले में अचानक बंद होने के बराबर होता है: PostgreSQL शुरू होते समय अपना जर्नल फिर से चलाएगा और आमतौर पर संभल जाएगा, लेकिन आपको किसी निश्चित क्षण पर रिस्टोर करने की कोई गारंटी नहीं मिलती, और तार्किक भ्रष्टाचार से कोई सुरक्षा नहीं (जैसे प्रोडक्शन में चला गया WHERE के बिना UPDATE)। PostgreSQL का दस्तावेज़ीकरण फ़ाइल सिस्टम स्नैपशॉट को केवल तभी वैध मानता है जब वॉल्यूम एक ही हो और स्नैपशॉट परमाणु (atomic) हो — नेटवर्क स्टोरेज पर व्यवहार में यह शर्त कम ही पूरी होती है। डेटाबेस के लिए हम लगातार WAL आर्काइविंग रखते हैं, और ठीक यही काम CloudNativePG जैसा ऑपरेटर संभालता है; लागत के समझौतों का विश्लेषण हमने मैनेज्ड PostgreSQL बनाम क्लस्टर के भीतर PostgreSQL की तुलना में विस्तार से किया है।

दूसरा: क्लस्टर ख़ुद बैकअप में नहीं होना चाहिए। अगर आपके क्लस्टर को दोबारा बनाने का एकमात्र तरीका etcd का स्नैपशॉट रिस्टोर करना है, तो आपकी समस्या इन्फ़्रास्ट्रक्चर की है, बैकअप की नहीं। नोड, नेटवर्क, सिक्योरिटी ग्रुप और IAM रोल किसी Terraform या OpenTofu रिपॉज़िटरी से आने चाहिए। Velero वर्कलोड दोबारा खड़ा करता है, कंट्रोल प्लेन नहीं।

OVHcloud या Scaleway के S3 बकेट के साथ Velero इंस्टॉल करना

Velero CNCF का एक प्रोजेक्ट है, आज इनक्यूबेशन चरण में, जिसे शुरुआत में Heptio और फिर VMware ने विकसित किया। यह किसी भी S3-संगत ऑब्जेक्ट स्टोरेज के साथ काम करता है, जिसमें OVHcloud Object Storage (पुरानी और नई S3 पेशकश), Scaleway Object Storage और ज़ाहिर तौर पर Amazon S3 शामिल हैं।

पहले बकेट और एक समर्पित एक्सेस-की जोड़ा बनाएँ। Scaleway पर एंडपॉइंट https://s3.fr-par.scw.cloud जैसा होता है, रीजन fr-par के साथ; OVHcloud पर S3-संगत पेशकश के लिए https://s3.gra.io.cloud.ovh.net, रीजन gra के साथ। सटीक मान हमेशा प्रोवाइडर के कंसोल में जाँचें, एंडपॉइंट कई बार बदले हैं।

क्रेडेंशियल फ़ाइल, चिरपरिचित AWS फ़ॉर्मैट में:

# velero-credentials
[default]
aws_access_key_id=SCWXXXXXXXXXXXXXXXXX
aws_secret_access_key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

फिर Velero CLI के साथ इंस्टॉलेशन (प्रोजेक्ट के GitHub रिलीज़ पर उपलब्ध):

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.11.0 \
  --bucket studio-cluster-backup \
  --secret-file ./velero-credentials \
  --backup-location-config \
      region=fr-par,s3ForcePathStyle=true,s3Url=https://s3.fr-par.scw.cloud \
  --use-node-agent \
  --uploader-type kopia \
  --default-volumes-to-fs-backup=false \
  --namespace velero

तीन विकल्पों की व्याख्या ज़रूरी है।

• --use-node-agent एक DaemonSet तैनात करता है जो हर नोड पर माउंट किए गए वॉल्यूम की सामग्री पढ़ सकता है। जिन वॉल्यूम के CSI ड्राइवर स्नैपशॉट नहीं संभालते, उनके फ़ाइल-स्तरीय बैकअप (File System Backup) के लिए यह अनिवार्य है।
• --uploader-type kopia Restic की जगह Kopia चुनता है। Velero में Restic v1.15 से डेप्रिकेटेड है; नए क्लस्टर पर Kopia ही डिफ़ॉल्ट विकल्प है।
• --default-volumes-to-fs-backup=false डिफ़ॉल्ट रूप से सब कुछ फ़ाइल-स्तर पर बैकअप करने से बचाता है: हम बहुत तेज़ CSI स्नैपशॉट को प्राथमिकता देते हैं और ज़रूरत पड़ने पर एक एनोटेशन से केस-दर-केस फ़ाइल मोड पर जाते हैं।

आगे बढ़ने से पहले जाँच लें कि बैकअप लोकेशन पहुँच में है:

kubectl -n velero get backupstoragelocation
# NAME      PHASE       LAST VALIDATED   AGE
# default   Available   12s              2m

PHASE: Unavailable दस में नौ बार ग़लत एंडपॉइंट, भूला हुआ s3ForcePathStyle, या बकेट पर लिखने का अधिकार न रखने वाली कुंजियों का संकेत देता है।

CSI स्नैपशॉट सक्रिय करना

Velero फ़ाइलें कॉपी करने की जगह प्रोवाइडर के ड्राइवर से VolumeSnapshot माँगे, इसके लिए एक लेबल वाली VolumeSnapshotClass चाहिए:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-block-snapclass
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: csi.cinder.openstack.org   # प्रोवाइडर के ड्राइवर के अनुसार बदलें
deletionPolicy: Retain

एक बात का ध्यान रखें, जो अक्सर बहुत देर से पता चलती है: कई प्रोवाइडरों के यहाँ वॉल्यूम स्नैपशॉट मूल वॉल्यूम के उसी रीजन, और कई बार उसी ज़ोन में ही रहता है। अगर लक्ष्य किसी ज़ोन के नष्ट होने पर भी बचे रहना है, तो Velero का DataMover (snapshotMoveData: true) सक्रिय करना होगा, जो स्नैपशॉट पढ़कर उसे ऑब्जेक्ट बकेट में भेजता है। यह धीमा है, लेकिन यही एकमात्र कॉन्फ़िगरेशन है जो आपका डेटा वाक़ई क्लस्टर के बाहर रखती है।

हम जो शेड्यूल बनाते हैं

"पूरा क्लस्टर, रात में एक बार" जैसा एकमात्र शेड्यूल नाकाफ़ी है: हर namespace का मूल्य और बदलाव की रफ़्तार एक जैसी नहीं होती। हम तीन Schedule इस्तेमाल करते हैं।

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: prod-hourly
  namespace: velero
spec:
  schedule: "17 * * * *"
  template:
    includedNamespaces:
      - app-prod
    snapshotVolumes: true
    snapshotMoveData: true
    ttl: 72h
---
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: full-cluster-daily
  namespace: velero
spec:
  schedule: "25 2 * * *"
  template:
    excludedNamespaces:
      - kube-system
      - velero
    snapshotVolumes: true
    ttl: 720h

संचालन के अनुभव से निकली बातें:

• कभी 0 * * * * नहीं। दुनिया के सारे शेड्यूल किए गए काम ठीक घंटे पर चलते हैं; कुछ मिनटों का अंतर ऑब्जेक्ट स्टोरेज पर टकराव से बचाता है।
• ttl रिटेंशन तय करता है, और वही बिल तय करता है। 72 घंटे के घंटेवार बैकअप और 30 दिन के दैनिक बैकअप किसी SME एप्लिकेशन के लिए वाजिब संतुलन है।
• Secret डिफ़ॉल्ट रूप से शामिल होते हैं। यानी वे बकेट में सादे रूप में जाते हैं — सर्वर-साइड एन्क्रिप्टेड, लेकिन एक्सेस कुंजियाँ रखने वाले किसी के लिए भी पठनीय। संवेदनशील डेटा के लिए Velero, Kopia रिपॉज़िटरी के ज़रिए क्लाइंट-साइड एन्क्रिप्शन कर सकता है (repositoryMaintenance और रिपॉज़िटरी पासवर्ड): इसे स्पष्ट रूप से कॉन्फ़िगर करना पड़ता है, यह डिफ़ॉल्ट सेटिंग नहीं है।

असल में लागत कितनी आती है

हमारे ग्राहकों का एक आम क्लस्टर लें: तीन नोड, एक प्रोडक्शन namespace, 60 GB परसिस्टेंट वॉल्यूम, जिसमें 25 GB PostgreSQL डेटाबेस और 35 GB अपलोड हैं।

Scaleway और OVHcloud की सार्वजनिक मूल्य सूचियाँ स्टैंडर्ड क्लास में ऑब्जेक्ट स्टोरेज को प्रति GB प्रति माह लगभग 0.01 € पर रखती हैं, और दोनों प्रोवाइडर डेटा आउटबाउंड के लिए शुल्क नहीं लेते — AWS S3 से यह उल्लेखनीय अंतर है, जहाँ आउटबाउंड ट्रांसफ़र पर शुल्क लगता है और 60 GB का रिस्टोर कुछ यूरो में पड़ता है। मूल्य सूची उसी दिन ज़रूर जाँचें: ये दाम बदलते रहते हैं।

दूसरे शब्दों में: किसी SME क्लस्टर के बैकअप की इन्फ़्रास्ट्रक्चर लागत महीने में 10 € से कम है। असली मद वह इंजीनियर-घंटा है जो यह जाँचने में लगता है कि बैकअप काम कर रहा है। यही हम अपने इन्फ़्रास्ट्रक्चर सेवाएँ पेज पर वर्णित संचालन अनुबंधों में शामिल करते हैं।

रिस्टोर, कदम-दर-कदम

यह वह प्रक्रिया है जिसे हम वास्तविक परिस्थितियों में, एक स्टेजिंग namespace पर दोहराते हैं।

1. उपलब्ध बैकअप की सूची देखें और लक्ष्य की जाँच करें।

velero backup get
velero backup describe prod-hourly-20261109021700 --details

--details शामिल रिसोर्स और हर वॉल्यूम की स्थिति दिखाता है। PartiallyFailed स्थिति वाला बैकअप आम है और अक्सर हानिरहित (कोई webhook रिसोर्स जिसका बैकअप नहीं हो सकता), लेकिन उसे इस्तेमाल करने से पहले चेतावनियाँ पढ़ लेनी चाहिए।

2. प्रोडक्शन के ऊपर नहीं, किसी नए namespace में रिस्टोर करें।

velero restore create recette-20261109 \
  --from-backup prod-hourly-20261109021700 \
  --namespace-mappings app-prod:app-recette \
  --wait

Namespace रीमैपिंग ही ग़ैर-विनाशकारी परीक्षण की कुंजी है: हमें app-recette में प्रोडक्शन की पूरी प्रतिलिपि मिल जाती है, और app-prod को छुआ नहीं जाता।

3. जो जागना नहीं चाहिए, उसे निष्क्रिय करें।

रिस्टोर की गई प्रोडक्शन प्रतिलिपि अपने CronJob, आउटबाउंड हुक और SMTP क्रेडेंशियल साथ रखती है। उसे पहुँच योग्य बनाने से पहले CronJob को सस्पेंड करें और बाहरी इंटीग्रेशन बंद करें:

kubectl -n app-recette get cronjob -o name \
  | xargs -I{} kubectl -n app-recette patch {} \
      -p '{"spec":{"suspend":true}}'

यहीं नेटवर्क एक्सपोज़र ऑब्जेक्ट भी जाँचे जाते हैं: प्रोडक्शन के ही होस्टनेम के साथ रिस्टोर किया गया HTTPRoute राउटिंग टकराव पैदा करेगा। इन ऑब्जेक्ट का विस्तृत विवरण हमने ingress-nginx की जगह Gateway API वाले लेख में दिया है।

4. पॉड नहीं, डेटा जाँचें।

रिस्टोर परीक्षण का चिरपरिचित जाल: सारे पॉड Running हैं, हम जीत घोषित कर देते हैं, और किसी ने डेटाबेस खोला ही नहीं। हमारी तीन न्यूनतम जाँचें:

# सबसे बड़ी टेबल में पंक्तियों की गिनती
kubectl -n app-recette exec deploy/postgres -- \
  psql -U app -d app -c "select count(*) from orders;"

# अंतिम रिकॉर्ड की तारीख़
kubectl -n app-recette exec deploy/postgres -- \
  psql -U app -d app -c "select max(created_at) from orders;"

# अपलोड वॉल्यूम में एक ज्ञात फ़ाइल
kubectl -n app-recette exec deploy/web -- \
  ls -l /app/uploads/2026/

दूसरी कमांड असली RPO (अधिकतम डेटा हानि) बताती है: max(created_at) और बैकअप के समय के बीच का अंतर। अगर आपका लक्ष्य एक घंटे का RPO है और अंतिम रिकॉर्ड बैकअप से चार घंटे पहले का है, तो समस्या रिस्टोर में नहीं, पूरी श्रृंखला में है।

5. समय नापें और दर्ज करें।

असली अवधि दर्ज करें: यही आपका RTO है। हमारे संचालित क्लस्टरों पर DataMover के साथ 60 GB वाले namespace का पूर्ण रिस्टोर 20 से 45 मिनट लेता है, जिसका बड़ा हिस्सा ऑब्जेक्ट स्टोरेज से ट्रांसफ़र में जाता है। अगर आपका वादा "30 मिनट में बहाल" है, तो आपको अभी पता चला कि वह ग़लत है।

6. प्रतिलिपि हटा दें।

velero restore delete recette-20261109
kubectl delete ns app-recette

जो चार ग़लतियाँ हम सबसे ज़्यादा देखते हैं

1. प्रोडक्शन StorageClass पर reclaimPolicy: Delete। ऐसे में कोई helm uninstall या kubectl delete pvc नीचे पड़े वॉल्यूम को तुरंत नष्ट कर देता है। डेटा रखने वाली StorageClass को Retain पर करें, भले ही अनाथ वॉल्यूम मैन्युअली साफ़ करने पड़ें।
2. बैकअप क्लस्टर के ही अकाउंट या प्रोजेक्ट में रखना। अगर एक कुंजी-जोड़े के समझौते से क्लस्टर और बैकअप बकेट दोनों मिटाए जा सकते हैं, तो आपके पास बैकअप नहीं है। अलग प्रोजेक्ट, सिर्फ़-लेखन कुंजियाँ, और जहाँ प्रोवाइडर दे वहाँ ऑब्जेक्ट लॉक (Object Lock) इस्तेमाल करें।
3. Schedule की कोई निगरानी नहीं। तीन हफ़्तों तक चुपचाप फ़ेल होता बैकअप सबसे आम परिदृश्य है। Velero Prometheus मेट्रिक्स देता है: "अंतिम सफल बैकअप 26 घंटे से ज़्यादा पुराना" जैसे अलर्ट के लिए velero_backup_last_successful_timestamp और velero_backup_failure_total काफ़ी हैं।
4. वे सीक्रेट जो बैकअप में नहीं हैं क्योंकि वे कहीं और से आते हैं। External Secrets Operator या Sealed Secrets के साथ, रिस्टोर किए गए Secret खाली या अवैध हो सकते हैं। निर्भरता नापने के लिए वॉल्ट अनुपलब्ध रखकर रिस्टोर आज़माएँ — यह ठीक वैसा विवरण है जो ख़राबी के साथ ही पता चलता है, जैसे प्राइवेट रजिस्ट्री पर प्रमाणीकरण, जिसकी चर्चा हमने Kubernetes पर प्राइवेट GitLab इमेज वाली गाइड में की है।

अक्सर पूछे जाने वाले प्रश्न

क्या Velero मेरे PostgreSQL डेटाबेस के बैकअप की जगह ले लेता है?

नहीं। Velero डेटाबेस के वॉल्यूम का स्नैपशॉट ले सकता है, जो आपको PVC के ग़लती से मिट जाने से बचाता है, लेकिन यह न किसी निश्चित क्षण पर रिस्टोर देता है और न ट्रांज़ैक्शनल सुसंगतता की गारंटी। एक समर्पित श्रृंखला रखें: किसी ऑपरेटर के साथ लगातार WAL आर्काइविंग, या मैनेज्ड डेटाबेस के स्वतः बैकअप। व्यवहार में हम डेटाबेस वॉल्यूम को Velero बैकअप से बाहर रखते हैं (एनोटेशन backup.velero.io/backup-volumes-excludes) ताकि स्टोरेज का दोहरा ख़र्च न हो।

क्या etcd का बैकअप अलग से लेना चाहिए?

मैनेज्ड क्लस्टर (OVHcloud Managed Kubernetes, Scaleway Kapsule, EKS) पर नहीं: कंट्रोल प्लेन प्रोवाइडर की ज़िम्मेदारी है और आपकी उस तक पहुँच नहीं है। स्वयं-प्रबंधित क्लस्टर पर रोज़ाना etcdctl snapshot save पूरा क्लस्टर बहाल करने के लिए उपयोगी है, लेकिन वह सारी ग़लतियाँ भी बहाल कर देता है। लक्षित रूप से पीछे लौटने के लिए Velero ही बेहतर रहता है।

रिस्टोर का परीक्षण कितनी बार करना चाहिए?

कम से कम हर तिमाही, और Kubernetes या CSI ड्राइवर के हर बड़े वर्शन बदलाव के बाद। स्क्रिप्ट किया हुआ परीक्षण दो घंटे लेता है। हम इसे पाइपलाइन में शेड्यूल किए गए काम के रूप में रखते हैं, और रिपोर्ट संग्रहित करते हैं: तारीख़, इस्तेमाल किया गया बैकअप, नापा गया RTO, विसंगतियाँ।

क्या Velero से किसी क्लस्टर को दूसरे प्रोवाइडर पर माइग्रेट किया जा सकता है?

हाँ, और यह इसके सबसे उपयोगी उपयोगों में से एक है: स्रोत क्लस्टर से snapshotMoveData: true के साथ बैकअप, लक्ष्य क्लस्टर से उसी बकेट को पढ़ना, फिर velero restore create। रगड़ के बिंदु हैं StorageClass (नाम अलग होते हैं, change-storage-class-config प्रकार के ConfigMap से रीमैप करें), LoadBalancer और प्रोवाइडर-विशिष्ट एनोटेशन। एक कमांड नहीं, पूरे एक दिन की मशक्कत मानकर चलें।

रिस्टोर परीक्षण को CI में कहाँ रखें?

एप्लिकेशन पाइपलाइन से अलग, एक साप्ताहिक शेड्यूल किए गए काम में: किसी डिस्पोज़ेबल namespace में रिस्टोर, जाँच क्वेरी, हटाना, और RTO को मेट्रिक के रूप में प्रकाशित करना। हम जो पाइपलाइन मॉडल इस्तेमाल करते हैं, उसका वर्णन हमारे लेख Kubernetes पर Next.js के लिए GitLab CI/CD पाइपलाइन में है।

संक्षेप में

• क्लस्टर का बैकअप तीन स्तरों पर होता है: API ऑब्जेक्ट, परसिस्टेंट वॉल्यूम, तार्किक डेटा। Velero पहले दो संभालता है, तीसरा नहीं।
• Velero को Kopia के साथ इंस्टॉल करें (Restic डेप्रिकेटेड है), OVHcloud या Scaleway का S3 बकेट लें, और किसी ज़ोन के नष्ट होने पर भी बचे रहना है तो snapshotMoveData: true रखें।
• एक शेड्यूल से तीन बेहतर हैं: प्रोडक्शन पर छोटे ttl के साथ घंटेवार, और पूरे क्लस्टर पर लंबी रिटेंशन के साथ दैनिक।
• इन्फ़्रास्ट्रक्चर लागत कम है — किसी SME क्लस्टर पर 60 GB डेटा के लिए महीने में 10 € से कम; असली लागत परीक्षण का समय है।
• रिस्टोर हमेशा रीमैप किए गए namespace में करें, CronJob सस्पेंड करें, और फिर पॉड की स्थिति नहीं बल्कि डेटा जाँचें (पंक्तियों की गिनती, अंतिम रिकॉर्ड की तारीख़)।
• हर परीक्षण पर RPO और RTO नापें और लिखें। बिना समय नापे किया गया बहाली का वादा एक अनुमान है।
• डेटा रखने वाली StorageClass को reclaimPolicy: Retain पर करें, बैकअप बकेट को क्लस्टर के अकाउंट से अलग रखें, और velero_backup_last_successful_timestamp पर अलर्ट लगाएँ।

अगर आप अपनी बैकअप श्रृंखला का ऑडिट करवाना चाहते हैं, या बस अपने क्लस्टर पर एक वास्तविक रिस्टोर का समय नपवाना चाहते हैं, तो हमारी टीम से बात करें या संपर्क पेज के ज़रिए हमें लिखें।