TopDev AI Robot TopDev
#Cơ sở dữ liệu & Tối ưu#DevOps & Cloud

Chiến lược sao lưu (Backup) và phục hồi (Disaster Recovery) PostgreSQL chuẩn RPO và RTO

Thu Trang (Backend Engineer)
📖 2 phút đọc 💬 1 phản hồi
⚡ Tóm tắt 30 giây bởi TopDev AI
AI Overview

"Chưa từng thử phục hồi thì coi như chưa bao giờ có Backup" Rất nhiều doanh nghiệp tự tin vì mỗi đêm đều có một cronjob chạy lệnh pgdump đẩy file lên Google Drive hoặc S3. Đến một ngày ổ cứng máy chủ…

☰ Mục lục bài viết (4 phần) Mở / Đóng mục lục

"Chưa từng thử phục hồi thì coi như chưa bao giờ có Backup"#

Rất nhiều doanh nghiệp tự tin vì mỗi đêm đều có một cronjob chạy lệnh pg_dump đẩy file lên Google Drive hoặc S3. Đến một ngày ổ cứng máy chủ chính bị hỏng vật lý hoặc database bị mã hóa tống tiền (Ransomware), khi tải file backup về restore thì:

  • File bị lỗi corrupt giữa chừng không đọc được.
  • Quá trình import mất tới 14 tiếng đồng hồ (vượt xa mức chịu đựng gián đoạn của doanh nghiệp).
  • Mất toàn bộ giao dịch phát sinh từ 00h sáng đến 15h chiều cùng ngày (mất 15 tiếng dữ liệu!).

Hai chỉ số cốt lõi của bài toán Disaster Recovery là RPO (Recovery Point Objective) và RTO (Recovery Time Objective).

Giải pháp: Point-In-Time Recovery (PITR) với pgBackRest#

Thay vì chỉ dựa vào bản dump logic (pg_dump), giải pháp chuẩn công nghiệp là sử dụng công cụ pgBackRest kết hợp giữa:

  1. Full Backup định kỳ mỗi tuần một lần.
  2. Differential / Incremental Backup mỗi đêm.
  3. Continuous WAL Archiving: Đẩy liên tục các file Write-Ahead Log (WAL) lên Object Storage (S3 / GCS) ngay khi phát sinh.
INI
# Cấu hình pgBackRest lưu trữ lên AWS S3
[global]
repo1-type=s3
repo1-s3-bucket=topdev-db-backups
repo1-s3-endpoint=s3.ap-southeast-1.amazonaws.com
repo1-s3-region=ap-southeast-1
repo1-s3-key=AKIA...
repo1-s3-key-secret=...
repo1-retention-full=2
repo1-cipher-type=aes-256-cbc # Mã hóa bảo mật dữ liệu sao lưu

Khả năng khôi phục đến từng giây (PITR)#

Nếu một dev lỡ tay chạy nhầm lệnh DELETE FROM orders vào lúc 14:23:15, bạn có thể ra lệnh cho pgBackRest khôi phục chính xác trạng thái của database vào thời điểm 14:23:14:

BASH
pgbackrest --stanza=db-main --type=time "--target=2026-11-10 14:23:14" restore
  • RPO: Giảm xuống chỉ còn vài giây (không bị mất dữ liệu cả ngày).
  • RTO: Tốc độ phục hồi cực nhanh vì khôi phục ở cấp độ tệp vật lý (Physical block-level restore).

Góc thảo luận#

Team bạn đã từng diễn tập kịch bản phục hồi thảm họa (Disaster Recovery Drill) bao giờ chưa? Lần gần nhất bạn thử restore file backup là khi nào?


Xem thêm nội dung liên quan:

Chia sẻ thảo luận này:

Thảo luận

1 phản hồi

Ý kiến từ cộng đồng kỹ sư TopDev
💬

Tham gia thảo luận

Cộng đồng mở · Đăng nhập 1-chạm qua Google
  1. Hoàng Nam (Tech Lead)
    #1

    Câu nói "Chưa từng thử phục hồi thì coi như chưa có backup" quá chuẩn xác! Bên mình định kỳ mỗi quý đều có 1 buổi diễn tập: Giả lập database chính bị sập hoàn toàn và yêu cầu team DevOps khôi phục lên server mới, bấm giờ xem có đạt RTO dưới 30 phút không.

Bài liên quan trong #Cơ sở dữ liệu & Tối ưu

1
TopDev AI Companion
AI
✓ Đã sao chép link