आप एक बैकअप और आपातकालीन पुनः प्राप्ति रणनीति कैसे डिजाइन करते हैं?

Question

Accepted Answer

एक बैकअप और आपातकालीन पुनः प्राप्ति (DR) रणनीति का जवाब देता है: यदि हम डेटा या पूरे क्षेत्र को खो देते हैं, तो **हम कितना डेटा खो सकते हैं, हम कितनी जल्दी वापस आ सकते हैं, और क्या हम वास्तव में पुनः स्थापित कर सकते हैं?** यह **3-2-1 नियम**, स्पष्ट **RPO/RTO** लक्ष्यों, और — महत्वपूर्ण रूप से — **नियमित रूप से परीक्षण किए गए पुनः स्थापनों** पर निर्भर करता है।

## 3-2-1 नियम

```text
3 copies of the data
2 different media / storage types
1 copy offsite (different region or provider)
→ no single failure (disk, host, datacenter, ransomware) destroys every copy
```

बैकअप **स्वचालित** (कोई व्यक्ति उन्हें चलाना नहीं भूल जाता) और **अनुप्रयोग से अलग** होना चाहिए ताकि क्षेत्रीय आपातकाल बैकअप को प्राथमिक के साथ न ले जाए।

## RPO और RTO

ये दोनों लक्ष्य प्रत्येक डिजाइन विकल्प को संचालित करते हैं:

- **RPO (Recovery Point Objective)** — कितना डेटा नुकसान सहन योग्य है, समय में मापा जाता है। 1 घंटे का RPO का मतलब है कि अधिकतम पिछले घंटे के लेखन में से खो देना, जो बैकअप/प्रतिकृति आवृत्ति को निर्देशित करता है।
- **RTO (Recovery Time Objective)** — पुनः प्राप्ति में कितना समय लग सकता है। 30 मिनट का RTO का मतलब है कि सिस्टम को 30 मिनट में पुनः स्थापित और सेवा प्रदान करनी चाहिए, जो DR आर्किटेक्चर को निर्देशित करता है।

```text
frequent backups / replication → smaller RPO (less data lost)
hotter standby infrastructure  → smaller RTO (faster recovery)
both cost money → pick targets per business criticality
```

## DR स्तर (लागत बनाम RTO)

```text
Backup & restore  → cheapest; restore from backups on demand   (RTO: hours)
Pilot light       → minimal core running, scale up on disaster  (RTO: tens of min)
Warm standby      → scaled-down live copy, scale up to take over (RTO: minutes)
Multi-site active → full live copies serving traffic            (RTO: ~seconds)
```

## अपने पुनः स्थापनों का परीक्षण करें

**एक बैकअप जिसे आपने कभी पुनः स्थापित नहीं किया है वह बैकअप नहीं है — यह आशा है।** नियमित पुनः स्थापन अभ्यास शेड्यूल करें: बैकअप से एक स्वच्छ वातावरण में वास्तव में पुनः निर्माण करें और अखंडता सत्यापित करें। यह भ्रष्ट बैकअप, छूटे हुए टुकड़े, और टूटे हुए runbooks को पकड़ता है *वास्तविक आपातकाल से पहले*।

## यह क्यों महत्वपूर्ण है

डेटा हानि और क्षेत्रीय आपातकाल तब होते हैं जब कंपनी का अस्तित्व परीक्षण पर होता है। 3-2-1 किसी भी एकल विफलता से एक प्रति को बचाता है; RPO/RTO अस्पष्ट "हमारे पास बैकअप है" को औसत दर्जे की प्रतिबद्धता में बदल देते हैं; DR स्तर आपको महत्वपूर्णता के लिए लागत मिलाने देते हैं; और परीक्षण पुनः स्थापन एकमात्र प्रमाण है कि पूरी चीज वास्तव में काम करती है। परीक्षण को छोड़ना कैसे टीमें मध्य-आपातकाल में खोज करती हैं कि उनके बैकअप बेकार थे।