Backup và disaster recovery: RPO, RTO, restore drill cho PostgreSQL

Backup không có restore thì chưa phải backup#

Nhiều team chỉ kiểm tra rằng job backup chạy thành công, nhưng chưa từng khôi phục dữ liệu thật. Đến khi xóa nhầm bảng, migration lỗi hoặc cloud region gặp sự cố, họ mới phát hiện file backup thiếu quyền, thiếu WAL, mã hóa sai key hoặc thời gian restore quá lâu. Một chiến lược backup chuyên nghiệp phải bao gồm backup, verify, restore drill và phân quyền truy cập.

Với blog, CMS, CRM hoặc LMS, database thường là tài sản quan trọng nhất. Code có thể build lại, server có thể tạo lại, nhưng dữ liệu user, bài viết, comment, thanh toán hoặc lịch sử học tập mất đi thì rất khó phục hồi niềm tin.

Hiểu RPO và RTO trước khi chọn công cụ#

RPO là lượng dữ liệu tối đa có thể mất. Nếu RPO là 15 phút, hệ thống backup phải cho phép khôi phục về điểm cách sự cố tối đa 15 phút. RTO là thời gian tối đa để dịch vụ hoạt động trở lại. Hai con số này quyết định kiến trúc: backup hằng ngày có thể đủ cho blog cá nhân, nhưng không đủ cho hệ thống giao dịch.

• Blog nội dung: RPO vài giờ, RTO vài giờ có thể chấp nhận.
• CRM vận hành: RPO 15-60 phút, RTO dưới vài giờ.
• Thanh toán hoặc đơn hàng: cần PITR, replica, runbook và kiểm thử định kỳ.

PostgreSQL cần base backup và WAL#

PostgreSQL có thể backup bằng logical dump hoặc physical backup. Logical dump như pg_dump dễ dùng cho database nhỏ và migration giữa version, nhưng restore có thể chậm. Physical backup kết hợp WAL archiving hỗ trợ point-in-time recovery, phù hợp production nghiêm túc hơn.

pg_dump --format=custom --file=app.dump "$DATABASE_URL"
pg_restore --clean --if-exists --dbname="$RESTORE_DATABASE_URL" app.dump

Dù dùng managed database như Supabase, Neon, RDS hay Cloud SQL, bạn vẫn cần hiểu chính sách retention, PITR, khu vực lưu backup, giới hạn restore và cách kiểm thử restore vào môi trường riêng.

Restore drill nên chạy như một bài test vận hành#

Restore drill là buổi diễn tập khôi phục dữ liệu theo runbook. Mục tiêu không chỉ là restore thành công, mà là đo thời gian, phát hiện bước thiếu, kiểm tra quyền truy cập, xác nhận dữ liệu và cập nhật tài liệu. Hãy chạy drill định kỳ, đặc biệt trước các migration lớn.

1. Chọn backup hoặc thời điểm PITR cần restore.
2. Restore vào database tách biệt, không ghi đè production.
3. Chạy smoke test: số bảng, số record, checksum hoặc query nghiệp vụ.
4. Đo thời gian restore thực tế và so với RTO.
5. Cập nhật runbook và quyền truy cập nếu phát hiện điểm yếu.

Bảo mật backup quan trọng như production#

Backup thường chứa toàn bộ dữ liệu nhạy cảm. Vì vậy backup cần mã hóa, kiểm soát quyền, audit access, retention rõ ràng và quy trình xóa an toàn. Không lưu backup production vào laptop cá nhân hoặc bucket public. Không dùng cùng một credential cho app runtime và thao tác restore.

Checklist backup và DR#

• Xác định RPO/RTO cho từng loại hệ thống.
• Backup tự động, có retention và cảnh báo khi job thất bại.
• Hỗ trợ PITR nếu dữ liệu thay đổi thường xuyên và quan trọng.
• Restore drill định kỳ vào môi trường tách biệt.
• Backup được mã hóa và giới hạn quyền truy cập.
• Runbook nêu rõ ai làm gì, command nào chạy, kiểm tra nào cần qua.
• Migration rủi ro có backup gần thời điểm deploy và rollback plan.

Nguồn tham khảo chính#

• PostgreSQL Docs: Backup and Restore
• PostgreSQL Docs: Continuous Archiving and PITR
• Supabase Docs: Backups