Database Architecture 3: Backup, PITR & Các Chỉ Số Phục Hồi (RPO, RTO)
Product Decode
•
1. Ảo Tưởng Tử Thần: "Tôi Đã Có Replication, Cần Gì Backup?"
Một trong những sai lầm ngây thơ (và đắt giá) nhất của các Newbie khi thiết kế hệ thống là đánh đồng Độ sẵn sàng cao (HA) với Phục hồi sau thảm họa (Disaster Recovery - DR). Khi thấy hệ thống đã có 1 Primary và 3 Replicas chạy mượt mà, nhiều người cho rằng dữ liệu đã an toàn tuyệt đối.
Hãy tưởng tượng kịch bản này: 2 giờ sáng, một kỹ sư Data chạy script dọn dẹp database nhưng quên mất mệnh đề WHERE trong câu lệnh DELETE FROM users;.
Điều gì sẽ xảy ra với hệ thống HA của bạn?
Với sức mạnh của Replication siêu tốc, lệnh xóa này được "sao chép" hoàn hảo sang toàn bộ 3 Replicas chỉ trong vòng 15 mili-giây. Kết quả: Toàn bộ bảng người dùng trống rỗng ở tất cả các node. Lúc này, High Availability biến thành thảm họa vì nó giúp việc hủy diệt dữ liệu diễn ra nhanh hơn bao giờ hết.
Replication bảo vệ bạn khỏi rủi ro (Server cháy, đứt cáp). bảo vệ bạn khỏi rủi ro (Xóa nhầm, Ransomware). Hệ thống Enterprise bắt buộc phải có cả hai.
Khi trình bày phương án DR với Ban Giám Đốc, đừng nói về việc "chúng ta sẽ chạy cronjob backup mỗi đêm". C-Level chỉ quan tâm đến rủi ro tài chính. Bạn phải giao tiếp bằng hai chỉ số sống còn: RPO và RTO.
Khái niệm cốt lõi:
RPO (Recovery Point Objective - Lượng dữ liệu chấp nhận mất): Tính bằng thời gian trước khi thảm họa xảy ra. Nếu RPO = 15 phút, bạn đang cam kết với Business: "Nếu sập, chúng ta mất tối đa doanh thu/đơn hàng của 15 phút gần nhất".
RTO (Recovery Time Objective - Thời gian chết tối đa): Tính bằng thời gian sau khi thảm họa xảy ra. Nếu RTO = 2 giờ, bạn cam kết: "Từ lúc sập, hệ thống sẽ online trở lại sau tối đa 2 tiếng".
Anti-Pattern: Cam kết phi thực tế
Vague / Bad: "Chúng ta sẽ setup hệ thống không bao giờ mất dữ liệu (RPO = 0) và phục hồi ngay lập tức (RTO = 0)." -> Chỉ có Google/AWS với ngân sách tỷ đô mới dám tiệm cận mức này.
Good / Specific: "Hệ thống Core Payment cần RPO = 0 (bằng Synchronous Replication) và RTO = 15 phút. Trong khi đó, hệ thống User Behavior Log chỉ cần RPO = 24 giờ và RTO = 4 giờ để tiết kiệm 70% chi phí lưu trữ S3."
3. Kỹ Thuật PITR (Point-in-Time Recovery): Cỗ Máy Thời Gian
Nếu RPO của bạn là 5 phút, làm sao bạn có thể copy toàn bộ Database dung lượng 10TB cứ mỗi 5 phút một lần? Điều đó là bất khả thi về mặt vật lý (Disk IOPS sẽ tê liệt).
Giải pháp của các hệ thống cơ sở dữ liệu hiện đại là PITR (Phục hồi tại một thời điểm). Thay vì backup toàn bộ (Full Backup) liên tục, ta chỉ làm Full Backup 1 lần/ngày, và ghi lại MỌI sự thay đổi (INSERT/UPDATE/DELETE) vào một cuốn nhật ký siêu nhẹ gọi là Transaction Log (WAL trong PostgreSQL, Binlog trong MySQL).
Khi thảm họa xảy ra lúc 14:35:00, kỹ sư sẽ kích hoạt "Cỗ máy thời gian" theo luồng sau:
Bằng cách phát lại (replay) các log này, bạn tái tạo lại trạng thái hệ thống chính xác đến từng giây, ngay trước khoảnh khắc lệnh DELETE định mệnh được gõ.
Lý thuyết Backup thì dễ, nhưng lúc cần "Restore" (khôi phục) thì hệ thống mới lòi ra hàng tá rủi ro. Hãy rà soát chiến lược DR của bạn để không bị thụ động:
[P] Permission (Rò rỉ bản sao lưu):
Rủi ro: Hacker không thể tấn công trực tiếp vào Database do tường lửa rất chặt, nên chúng nhắm vào Amazon S3 - nơi chứa các file Full Backup. Các file này bị tải trộm, dẫn đến lộ hàng triệu thẻ tín dụng.
Giải pháp: Toàn bộ file Backup bắt buộc phải được mã hóa (Encrypted at rest) trước khi đẩy lên Storage. Quản lý key giải mã (KMS) độc lập với quyền truy cập hệ thống.
[E] Extreme / Edge Cases (Ảo tưởng RTO):
Rủi ro: Bạn cam kết RTO = 1 giờ. Nhưng khi sự cố xảy ra, việc download 10TB file Full Backup từ Cloud Storage về Server vật lý để chạy PITR mất tới... 8 giờ do nghẽn băng thông mạng.
Giải pháp: Luôn phải có Disaster Recovery Drill (Diễn tập sập hệ thống) định kỳ mỗi 6 tháng để đo lường RTO thực tế. Không bao giờ tin vào con số RTO trên giấy.
[U] Unavailability (Ransomware lây nhiễm chéo):
Rủi ro: Mã độc tống tiền (Ransomware) lây nhiễm vào Primary DB, sau đó lan sang chính network drive đang chứa các file Transaction Logs, mã hóa luôn cả công cụ cứu sinh của bạn.
Giải pháp: Thiết lập Immutable Backups (Bản sao lưu bất biến) theo nguyên tắc WORM (Write Once, Read Many). Một khi log đã ghi vào Storage, không một ai (kể cả quyền Root Admin) có thể sửa hay xóa nó trong vòng 30 ngày.
[F] Fraud / Abuse (Tấn công làm đầy ổ cứng log):
Rủi ro: Kẻ gian lợi dụng lỗ hổng API tạo ra hàng triệu request rác. Hệ thống ghi Transaction Log liên tục khiến ổ cứng chứa Log bị đầy (Disk Full), làm sập cả cơ chế PITR lẫn Primary DB.
Giải pháp: Tách biệt phân vùng ổ cứng (Volume) của Data chính và Transaction Log. Thiết lập cảnh báo chủ động khi dung lượng thư mục Log vượt quá 70%.
5. Lời Kết: Khi Việc "Scale-Up" Đi Đến Giới Hạn
Chúng ta đã đi qua một hành trình dài để bảo vệ dữ liệu: dùng HA/Replication để hệ thống luôn sống sót trước lỗi vật lý, và dùngBackup/PITR để hệ thống có khả năng "chuyển sinh" sau những thảm họa do con người. Kiến trúc Single-leader đến lúc này đã cực kỳ vững chãi.
Nhưng, thế giới công nghệ không dừng lại ở đó.
Dù bạn có Replication nhanh đến đâu, dù có Backup an toàn đến mức nào, kiến trúc của bạn vẫn đang bị trói buộc vào một giới hạn vật lý tàn khốc: Tất cả các lệnh GHI (Write) đều phải đổ về 1 con Primary duy nhất.
Điều gì sẽ xảy ra khi lượng transaction mỗi ngày chạm mốc hàng trăm triệu? Khi dung lượng của 1 database phình to lên hàng trăm Terabyte khiến việc Indexing chậm như rùa bò và thời gian khôi phục (RTO) kéo dài đến hàng tuần?
Đó là lúc chúng ta phải phá vỡ hoàn toàn khối kiến trúc nguyên khối này bằng kỹ thuật tối thượng của dân thiết kế hệ thống phân tán. Hẹn gặp bạn ở bài cuối cùng: Database Sharding.
System ConceptApr 20, 2026
Database Architecture 4: Sharding: Phá Vỡ Giới Hạn Vật Lý & Nỗi Đau Vận Hành
Khi hệ thống chạm ngưỡng giới hạn Ghi (Write limit), Replication trở nên vô dụng. Khám phá chiến lược chọn Shard Key, cách né thảm họa Hotspot và những mặt tối đắt đỏ của Sharding.
Product Decode
Backup, PITR, RPO & RTO: Chiến Lược Disaster Recovery Cho PM | Product Decode
