பத்து TB கொண்ட ஒரு database-க்கான Backup & disaster recovery

Question

IT Interview Practice · Accepted Answer

**point-in-time recovery-க்கு periodic snapshots-ஐ continuous WAL archiving உடன் இணையுங்கள், offsite/cross-region replicate செய்யுங்கள், மேலும் வெளிப்படையான RPO/RTO targets-க்கு எதிராக regular restore drills மூலம் அதை நிரூபியுங்கள்.** நீங்கள் ஒருபோதும் restore செய்யாத ஒரு backup ஒரு நம்பிக்கை, ஒரு திட்டம் அல்ல.

## கட்டமைப்பு

```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
```

## எப்படி வேலை செய்கிறது

- **Snapshots** volume/cluster-இன் ஒரு முழு copy (எ.கா. daily EBS snapshot அல்லது `pg_basebackup`). அவை நீங்கள் *எதிலிருந்து* restore செய்யும் base — ஆனால் நேற்று இரவு வரை மட்டும் restore செய்வது ஒரு நாள் writes-ஐ இழக்கிறது.
- **WAL / binlog archiving** கடைசி snapshot-க்குப் பிறகு ஒவ்வொரு மாற்றத்தையும் object store-க்கு continuously stream செய்கிறது. Restore = snapshot + எந்த தேர்ந்தெடுக்கப்பட்ட வினாடி வரை WAL replay. இது **PITR (point-in-time recovery)** — ஒரு மோசமான `DELETE`-க்கு முந்தைய தருணமான 10:32:04 வரை recover.
- **Offsite / cross-region.** DB-இன் அதே region-இல் உள்ள ஒரு backup region-உடன் இறக்கிறது. ஒரு regional outage அல்லது ransomware இரண்டையும் எடுக்காதபடி இரண்டாவது region-க்கு (S3 cross-region replication) replicate செய்யுங்கள்.
- **Restore drills.** அவ்வப்போது ஒரு scratch environment-க்கு restore செய்து, அது எவ்வளவு நேரம் எடுத்தது (**RTO**) மற்றும் நீங்கள் எவ்வளவு data இழந்திருப்பீர்கள் (**RPO**) என்பதை அளந்து, prod-க்கு எதிராக checksum செய்யுங்கள்.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = நீங்கள் எவ்வளவு data இழக்க தாங்கமுடியும். ஒவ்வொரு 5 நிமிடமும் WAL archiving → RPO ≈ 5 நிமிடம். Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = நீங்கள் எவ்வளவு விரைவாக திரும்ப வர வேண்டும். S3-இலிருந்து 20TB restore செய்வது மணிநேரம் எடுக்கலாம்; ஒரு warm standby replica RTO-ஐ நிமிடங்களுக்குக் குறைக்கிறது.

## நேர்காணல் கண்ணோட்டம்

**snapshots மட்டும் போதாது** (அவற்றுக்கு இடையே data loss) என்று நீங்கள் அறிவீர்களா, **RPO/RTO-ஐ எண்களில் வரையறுக்க** முடியுமா, மேலும் **restores-ஐ test செய்கிறீர்களா** என்பதை நேர்காணல் செய்பவர் ஆராய்கிறார். சிறந்த பதில்கள் test செய்யப்படாத backups சரியாகத் தேவைப்படும்போது தோல்வியடைகின்றன என்பதை வலியுறுத்தி, வசதியிலிருந்து அல்ல *business* RPO/RTO-இலிருந்து ஒரு strategy தேர்ந்தெடுக்கின்றன. ஒரு பொறி: ஒரு read replica ஒரு backup என்று கருதுவது — replication ஒரு `DROP TABLE`-ஐயும் நம்பகமாக copy செய்கிறது.

## சமரசங்களும் பிழைகளும்

- **Cost vs RTO.** ஒரு warm cross-region standby நிமிடங்கள் RTO தருகிறது ஆனால் infra cost-ஐ இரட்டிப்பாக்குகிறது; cold S3 restore மலிவானது ஆனால் மெதுவானது. business உண்மையில் தேவைப்படும் tier-ஐ வாங்குங்கள்.
- **Backup load.** ஒரு hot 20TB DB-ஐ snapshot செய்வது I/O சேர்க்கிறது; snapshots-ஐ ஒரு replica-இலிருந்து எடுங்கள்.
- **Silent corruption.** WAL ஒரு corrupt page-ஐ archive செய்யலாம்; periodic full-restore + checksum அதைப் பிடிக்கிறது.
- **Retention & compliance.** சட்டத் தேவைகளுக்கு போதுமான history-ஐ வைத்திருங்கள் (எ.கா. 35 நாட்கள் PITR + monthly archives); மலிவான long-term-க்கு Glacier.
- **எப்போது இல்லை:** ஒரு சிறிய DB S3-க்கு nightly `pg_dump` உடன் நன்றாக இருக்கும் — data loss உண்மையான பணத்தில் அளவிடப்படும் வரை full WAL + cross-region standby அதிகப்படியானது.

கட்டமைப்பு

எப்படி வேலை செய்கிறது

RPO vs RTO

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் பிழைகளும்

தொடர்புடைய கேள்விகள்