Backup & disaster recovery cho database hàng chục TB

Question

IT Interview Practice · Accepted Answer

**Kết hợp snapshot định kỳ với WAL archiving liên tục để phục hồi point-in-time, replicate offsite/cross-region, và chứng minh bằng các buổi diễn tập restore đều đặn theo mục tiêu RPO/RTO rõ ràng.** Một bản backup chưa bao giờ restore chỉ là hy vọng, không phải kế hoạch.

## Kiến trúc

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

## Cách hoạt động

- **Snapshot** là bản copy đầy đủ của volume/cluster (vd. EBS snapshot hằng ngày hoặc `pg_basebackup`). Đó là nền để restore *từ* đó — nhưng chỉ restore tới đêm qua là mất một ngày write.
- **WAL / binlog archiving** stream liên tục mọi thay đổi kể từ snapshot gần nhất lên object store. Restore = snapshot + replay WAL tới bất kỳ giây nào bạn chọn. Đây là **PITR (point-in-time recovery)** — phục hồi về 10:32:04, đúng khoảnh khắc trước một `DELETE` nhầm.
- **Offsite / cross-region.** Backup ở cùng region với DB sẽ chết cùng region. Replicate sang region thứ hai (S3 cross-region replication) để một sự cố vùng hay ransomware không cuốn cả hai.
- **Restore drill.** Định kỳ restore vào một môi trường nháp, đo mất bao lâu (**RTO**) và sẽ mất bao nhiêu dữ liệu (**RPO**), và checksum đối chiếu prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = bạn chấp nhận mất bao nhiêu dữ liệu. WAL archive mỗi 5 phút → RPO ≈ 5 phút. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = phải trở lại nhanh cỡ nào. Restore 20TB từ S3 có thể mất hàng giờ; một warm standby replica kéo RTO xuống vài phút.

## Góc nhìn phỏng vấn

Người phỏng vấn dò xem bạn có biết **snapshot không thôi là chưa đủ** (mất dữ liệu giữa các lần), có **định nghĩa RPO/RTO bằng con số** không, và có **test restore** không. Câu xuất sắc nhấn rằng backup không test sẽ hỏng đúng lúc cần, và chọn chiến lược từ RPO/RTO của *nghiệp vụ*, không phải từ tiện lợi. Bẫy: tưởng read replica là backup — replication sao chép trung thành cả một `DROP TABLE`.

## Đánh đổi & lỗi

- **Chi phí vs RTO.** Một warm standby cross-region cho RTO cỡ phút nhưng nhân đôi chi phí hạ tầng; cold restore từ S3 rẻ nhưng chậm. Mua đúng tier mà nghiệp vụ thật sự cần.
- **Tải backup.** Snapshot một DB 20TB đang nóng thêm I/O; hãy snapshot từ một replica.
- **Hỏng âm thầm.** WAL có thể archive một page hỏng; full-restore + checksum định kỳ bắt được nó.
- **Retention & tuân thủ.** Giữ đủ lịch sử (vd. 35 ngày PITR + archive hằng tháng) cho nhu cầu pháp lý; Glacier cho lưu dài hạn giá rẻ.
- **Khi nào không dùng:** một DB nhỏ thì `pg_dump` hằng đêm lên S3 là đủ — full WAL + cross-region standby là thừa cho tới khi mất dữ liệu tính bằng tiền thật.

Kiến trúc

Cách hoạt động

RPO vs RTO

Góc nhìn phỏng vấn

Đánh đổi & lỗi

Câu hỏi liên quan