Disaster Recovery (RPO/RTO)
- ●RPO বলে কতটুকু data হারানো সহনীয় (সময়ে), RTO বলে কত দ্রুত service ফেরানো লাগবে।
- ●Backup, multi-region failover আর replication মিলিয়ে disaster recovery পরিকল্পনা তৈরি হয়।
- ●Active-active সবসময় চালু থাকে (দ্রুত, ব্যয়বহুল); active-passive standby রাখে (সস্তা, ধীর failover)।
সমস্যাটা কী?
কল্পনা করো — তোমার পুরো data center (বা cloud region) আগুন, বন্যা, বা একটা বড় outage-এ সম্পূর্ণ অচল। শুধু একটা server নয়, পুরো অঞ্চল। এখন কী হবে? গ্রাহকের data কি চিরতরে হারিয়ে গেল? service কি ফিরবে, এবং কত ঘণ্টা পর?
এগুলো কাল্পনিক নয় — ২০২১-এ একটা বড় cloud provider-এর fire-এ অনেক কোম্পানির data পুড়ে গিয়েছিল, যাদের backup ছিল না তারা চিরতরে data হারিয়েছিল। Disaster Recovery (DR) হলো এমন বড় বিপর্যয়ের জন্য আগে থেকে পরিকল্পনা — যাতে data রক্ষা পায় এবং service গ্রহণযোগ্য সময়ের মধ্যে ফিরে আসে।
মূল ধারণা
Disaster Recovery হলো একটা বড় বিপর্যয়ের পর সিস্টেম ও data পুনরুদ্ধারের পরিকল্পনা ও প্রক্রিয়া। এর দুটো মূল লক্ষ্যমাত্রা — RPO (কতটুকু data হারানো সহনীয়) এবং RTO (কত দ্রুত ফেরানো লাগবে)।
দুটো metric গুলিয়ে ফেলা সহজ, তাই মনে রাখার উপায়:
- RPO (Recovery Point Objective) — অতীতের দিকে তাকায়। বিপর্যয়ের আগের কতটুকু data হারাতে পারি? এটা data loss নিয়ে।
- RTO (Recovery Time Objective) — ভবিষ্যতের দিকে তাকায়। কত দ্রুত service ফিরবে? এটা downtime নিয়ে।
একটা timeline ভাবো: ←── RPO ──[💥 বিপর্যয়]── RTO ──→। বাঁ দিকে data loss, ডান দিকে downtime।
কীভাবে কাজ করে
RPO ও RTO নির্ধারণ
ব্যবসার গুরুত্ব অনুযায়ী এই দুটো ঠিক হয়। যত কম, তত ব্যয়বহুল:
| System | RPO (data loss সহনীয়) | RTO (downtime সহনীয়) |
|---|---|---|
| ব্যাংকের transaction | প্রায় ০ (এক টাকাও হারানো যাবে না) | কয়েক মিনিট |
| E-commerce order | ১-৫ মিনিট | ১৫-৩০ মিনিট |
| Internal analytics | কয়েক ঘণ্টা | ১ দিন |
| Marketing blog | ১ দিন | কয়েক ঘণ্টা |
RPO ঠিক করে backup/replication কত ঘন ঘন করতে হবে; RTO ঠিক করে failover কত দ্রুত হতে হবে।
Backup কৌশল
| কৌশল | বর্ণনা | RPO প্রভাব |
|---|---|---|
| Full backup | পুরো data কপি (যেমন রাতে একবার) | RPO = ২৪ ঘণ্টা পর্যন্ত |
| Incremental | শুধু পরিবর্তন কপি, ঘন ঘন | RPO ছোট |
| Continuous replication | প্রায় real-time data কপি অন্য region-এ | RPO প্রায় ০ |
গুরুত্বপূর্ণ নিয়ম — 3-2-1 rule: ৩ কপি data, ২ ভিন্ন media-তে, ১ কপি off-site (ভিন্ন ভৌগোলিক স্থানে)। আর backup নিয়মিত restore test করো — না হলে জানবেই না backup আসলে কাজ করে কিনা।
Multi-region Failover
একটা region পুরো down হলে অন্য region-এ traffic সরিয়ে নেওয়া হয় — এটাই Failover। সাধারণত DNS বা load balancer routing বদলে এটা করা হয়। এখানেই আসে দুটো architecture pattern।
DR হলো বাড়ির জেনারেটরের মতো। RPO হলো — current চলে গেলে freezer-এর খাবার কত সময় ভালো থাকবে (অর্থাৎ কতটুকু "হারানো" সহনীয়)। RTO হলো — generator চালু হতে কত সময় লাগবে। Active-passive মানে generator আছে কিন্তু বন্ধ, current গেলে কেউ গিয়ে চালু করে (সস্তা, কিন্তু কিছুক্ষণ অন্ধকার)। Active-active মানে দুটো current line সবসময় চালু — একটা গেলে টেরই পাও না (ব্যয়বহুল, কিন্তু নিরবচ্ছিন্ন)। আর DR drill হলো মাঝে মাঝে generator চালিয়ে দেখা যে সত্যিই কাজ করে কিনা — না হলে ঝড়ের রাতে আবিষ্কার করবে generator-এ তেল নেই।
প্রকারভেদ — Active-Active vs Active-Passive
| বৈশিষ্ট্য | Active-Active | Active-Passive |
|---|---|---|
| Traffic | সব region একসাথে serve করে | একটা region serve করে, অন্যটা standby |
| Failover গতি | প্রায় তাৎক্ষণিক | ধীর (standby চালু করতে সময় লাগে) |
| খরচ | বেশি (সব সম্পদ সবসময় চালু) | কম (standby ছোট রাখা যায়) |
| জটিলতা | বেশি (data sync, conflict সামলানো কঠিন) | কম |
| RTO | সেকেন্ড | মিনিট-ঘণ্টা |
এছাড়া Active-Active-এর কম-ব্যয়ের সংস্করণও আছে: Pilot Light (core শুধু চালু, বাকি বন্ধ) ও Warm Standby (ছোট scale-এ চালু, দরকারে বড় করা হয়)।
কখন ব্যবহার করবে / করবে না
- অতি-জরুরি, revenue-critical system (ব্যাংক, payment) → active-active, RPO≈০।
- সাধারণ ব্যবসায়িক app → active-passive বা warm standby যথেষ্ট ও সাশ্রয়ী।
- কম-গুরুত্বপূর্ণ internal tool → শুধু নিয়মিত backup-ই যথেষ্ট হতে পারে।
সবচেয়ে বিপজ্জনক ভুল — DR plan লিখে রেখে কখনো পরীক্ষা না করা। বহু কোম্পানি বিপর্যয়ের রাতে আবিষ্কার করে যে তাদের failover script কাজ করে না, backup corrupt, বা restore-এ RTO-র চেয়ে ১০ গুণ বেশি সময় লাগছে। অপরীক্ষিত backup আসলে কোনো backup-ই নয়। নিয়মিত DR drill ছাড়া তোমার RPO/RTO শুধু কাগুজে আশা। আরেকটা ভুল — সব region একই cloud provider-এর একই account-এ রাখা; account-level সমস্যা হলে সব একসাথে যাবে।
বাস্তব উদাহরণ
একটা mobile banking platform (RPO≈০, RTO ৫ মিনিট target) DR setup করল — ঢাকা ও সিঙ্গাপুর দুই region-এ active-active, database-এ synchronous replication।
একদিন তাদের primary region-এর network provider-এ বড় outage হলো। কিন্তু load balancer ৩০ সেকেন্ডের মধ্যে সব traffic সিঙ্গাপুর region-এ সরিয়ে দিল। গ্রাহকরা প্রায় টেরই পেল না — কোনো data হারায়নি (RPO পূরণ), service কয়েক সেকেন্ডে ফিরল (RTO-র অনেক ভিতরে)।
কেন এটা কাজ করল? কারণ তারা প্রতি ত্রৈমাসিকে DR drill চালাত — ইচ্ছাকৃতভাবে এক region বন্ধ করে failover পরীক্ষা করত। এক drill-এ তারা ধরেছিল যে session data replicate হচ্ছে না, এবং তা ঠিক করেছিল — আসল outage-এর আগেই।
Interview-এ RPO ও RTO গুলিয়ে ফেলো না — RPO = data loss (অতীত), RTO = downtime (ভবিষ্যৎ)। এই দুটো সংখ্যা ব্যবসা ঠিক করে, engineer নয়। Active-active vs active-passive-এর trade-off (খরচ vs failover গতি) স্পষ্ট বলো। সবশেষে জোর দিয়ে বলো — DR plan যতই সুন্দর হোক, নিয়মিত drill ছাড়া তা অর্থহীন। "Untested backup is not a backup" — এই লাইনটা মনে রেখো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. একটা ব্যাংক বলল 'আমরা সর্বোচ্চ ৫ মিনিটের transaction data হারাতে পারি' — এটা কোন metric?
2. Active-active আর active-passive-এর মূল পার্থক্য কী?
3. DR পরিকল্পনা সত্যিই কাজ করে কিনা তা নিশ্চিত হওয়ার সেরা উপায় কী?