દસ 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 સામે નિયમિત restore drills વડે તેને સાબિત કરો.** જે backup તમે ક્યારેય restore ન કર્યું તે આશા છે, plan નહીં.

## આર્કિટેક્ચર

```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 ની full copy છે (દા.ત. daily EBS snapshot અથવા `pg_basebackup`). તે base છે જ્યાંથી તમે restore કરો છો — પણ માત્ર ગઈ રાત સુધી restore કરવાથી એક દિવસની writes ગુમાવે છે.
- **WAL / binlog archiving** છેલ્લા snapshot પછીના દરેક change ને object store પર continuously stream કરે છે. Restore = snapshot + કોઈપણ પસંદ કરેલી સેકન્ડ સુધી WAL replay. આ **PITR (point-in-time recovery)** છે — 10:32:04 પર recover કરો, ખરાબ `DELETE` પહેલાંની ક્ષણ.
- **Offsite / cross-region.** DB ના જ region માં backup region સાથે મરી જાય છે. બીજા region પર replicate કરો (S3 cross-region replication) જેથી regional outage કે ransomware બંને ને ન લઈ જાય.
- **Restore drills.** સમયાંતરે scratch environment માં restore કરો, કેટલો સમય લાગ્યો (**RTO**) અને કેટલો data ગુમાવ્યો હોત (**RPO**) માપો, અને prod સામે checksum કરો.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = તમે કેટલો data ગુમાવવો પરવડે. દર 5 min WAL archiving → RPO ≈ 5 min. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = તમારે કેટલી ઝડપથી પાછા આવવું જોઈએ. S3 માંથી 20TB restore કરવામાં કલાકો લાગી શકે; એક warm standby replica RTO ને મિનિટો સુધી ઘટાડે છે.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર probe કરે છે કે તમે જાણો છો કે **માત્ર snapshots પૂરતા નથી** (તેમની વચ્ચે data loss), શું તમે **RPO/RTO ને numbers માં define કરી શકો**, અને શું તમે **restores test કરો છો**. Great answers ભાર મૂકે છે કે untested backups બરાબર જ્યારે જરૂર હોય ત્યારે fail થાય છે, અને convenience થી નહીં પણ *business* RPO/RTO થી strategy પસંદ કરે છે. Trap: read replica ને backup ગણવો — replication `DROP TABLE` ને પણ વફાદારીથી copy કરે છે.

## Trade-offs અને failure

- **Cost vs RTO.** warm cross-region standby મિનિટોનું RTO આપે છે પણ infra cost double કરે છે; 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.** legal needs માટે પૂરતી history રાખો (દા.ત. 35 days PITR + monthly archives); સસ્તા long-term માટે Glacier.
- **ક્યારે ન કરવું:** એક નાનું DB S3 પર nightly `pg_dump` સાથે ઠીક છે — full WAL + cross-region standby ત્યાં સુધી overkill છે જ્યાં સુધી data loss real money માં માપાય.

આર્કિટેક્ચર

તે કેવી રીતે કામ કરે છે

RPO vs RTO

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો