দশ TB-র একটি database-এর জন্য backup ও disaster recovery

Question

IT Interview Practice · Accepted Answer

**point-in-time recovery-এর জন্য periodic snapshot-এর সঙ্গে continuous WAL archiving মিলিয়ে দিন, offsite/cross-region replicate করুন, এবং সুস্পষ্ট RPO/RTO target-এর বিপরীতে নিয়মিত restore drill দিয়ে এটি প্রমাণ করুন।** যে backup আপনি কখনও restore করেননি সেটি একটি আশা, একটি পরিকল্পনা নয়।

## আর্কিটেকচার

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## কীভাবে কাজ করে

- **Snapshot** হলো volume/cluster-এর একটি full copy (যেমন daily EBS snapshot বা `pg_basebackup`)। এগুলো হলো base যা থেকে আপনি restore করেন — কিন্তু কেবল গত রাত পর্যন্ত restore করলে এক দিনের write হারায়।
- **WAL / binlog archiving** শেষ snapshot থেকে প্রতিটি পরিবর্তন continuously object store-এ stream করে। Restore = snapshot + যেকোনো নির্বাচিত সেকেন্ড পর্যন্ত WAL replay। এটি **PITR (point-in-time recovery)** — একটি খারাপ `DELETE`-এর ঠিক আগের মুহূর্ত ১০:৩২:০৪-এ recover করুন।
- **Offsite / cross-region.** DB-এর একই region-এ একটি backup region-এর সঙ্গে মরে। একটি দ্বিতীয় region-এ replicate করুন (S3 cross-region replication) যাতে একটি regional outage বা ransomware উভয়কে না নেয়।
- **Restore drill.** পর্যায়ক্রমে একটি scratch environment-এ restore করুন, কত সময় লাগল (**RTO**) এবং কত data হারাতেন (**RPO**) পরিমাপ করুন, এবং prod-এর বিপরীতে checksum করুন।

## RPO বনাম RTO

- **RPO (Recovery Point Objective)** = আপনি কত data হারাতে পারেন। প্রতি ৫ মিনিটে WAL archiving → RPO ≈ ৫ মিনিট। Synchronous replica → RPO ≈ ০।
- **RTO (Recovery Time Objective)** = আপনাকে কত দ্রুত ফিরতে হবে। S3 থেকে ২০TB restore করতে ঘণ্টা লাগতে পারে; একটি warm standby replica RTO-কে মিনিটে কমায়।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার যাচাই করেন আপনি জানেন কিনা **কেবল snapshot যথেষ্ট নয়** (এগুলোর মধ্যে data loss), আপনি **RPO/RTO সংখ্যায় সংজ্ঞায়িত** করতে পারেন কিনা, এবং আপনি **restore test করেন** কিনা। দারুণ উত্তর জোর দেয় যে untested backup ঠিক তখনই ব্যর্থ হয় যখন প্রয়োজন, এবং সুবিধা থেকে নয়, *business* RPO/RTO থেকে একটি strategy বাছে। একটি ফাঁদ: একটি read replica-কে একটি backup ধরে নেওয়া — replication একটি `DROP TABLE`-ও বিশ্বস্তভাবে copy করে।

## ট্রেড-অফ ও ব্যর্থতা

- **খরচ বনাম RTO.** একটি warm cross-region standby মিনিটের RTO দেয় কিন্তু infra খরচ দ্বিগুণ করে; cold S3 restore সস্তা কিন্তু ধীর। business-এর প্রকৃত প্রয়োজন অনুযায়ী tier কিনুন।
- **Backup load.** একটি hot ২০TB DB snapshot করা I/O যোগ করে; একটি replica থেকে snapshot নিন।
- **Silent corruption.** WAL একটি corrupt page archive করতে পারে; periodic full-restore + checksum এটি ধরে।
- **Retention ও compliance.** আইনি প্রয়োজনের জন্য যথেষ্ট history রাখুন (যেমন ৩৫ দিন PITR + monthly archive); সস্তা দীর্ঘমেয়াদির জন্য Glacier।
- **কখন নয়:** একটি ছোট DB nightly `pg_dump` S3-তে দিয়ে ঠিক — full WAL + cross-region standby overkill যতক্ষণ না data loss বাস্তব অর্থে পরিমাপ হয়।

আর্কিটেকচার

কীভাবে কাজ করে

RPO বনাম RTO

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতা

সম্পর্কিত প্রশ্ন