PITR (Point In Time Recovery) là gì? Khôi phục Database về đúng thời điểm cần thiết

Trong vận hành Database, không phải lúc nào doanh nghiệp cũng muốn khôi phục dữ liệu về bản backup gần nhất. Có những tình huống cần khôi phục Database về đúng một thời điểm cụ thể, ví dụ trước khi nhân viên xóa nhầm dữ liệu, trước khi chạy nhầm câu lệnh UPDATE hoặc trước khi hệ thống bị lỗi logic.

Đó là lúc PITR, viết tắt của Point In Time Recovery, trở nên cực kỳ quan trọng.

PITR giúp doanh nghiệp khôi phục Database về một mốc thời gian cụ thể, giảm tối đa mất mát dữ liệu và tăng khả năng phục hồi sau sự cố.

1. PITR (Point In Time Recovery) là gì?

PITR, hay Point In Time Recovery, là kỹ thuật khôi phục Database về một thời điểm cụ thể trong quá khứ.

Thay vì chỉ restore về bản backup lúc 02:00 sáng, PITR cho phép bạn khôi phục về mốc như:

• 09:59:55 trước khi người dùng xóa nhầm dữ liệu lúc 10:00.
• 13:29:58 trước khi câu lệnh UPDATE sai chạy lúc 13:30.
• 22:14:30 trước khi hệ thống bị lỗi logic ghi dữ liệu sai.

Mô hình đơn giản:

Full Backup lúc 02:00
      |
      +-- Log 02:00 -> 09:00
      +-- Log 09:00 -> 10:00
      +-- Log 10:00 -> 11:00

Khôi phục về 09:59:55

2. Vì sao doanh nghiệp cần PITR?

Backup thông thường giúp bạn có bản sao dữ liệu tại một thời điểm. Nhưng trong nhiều trường hợp, bản backup gần nhất chưa đủ tốt.

Ví dụ:

• Backup chạy lúc 02:00 sáng.
• Nhân viên xóa nhầm dữ liệu lúc 15:00.
• Nếu chỉ restore bản 02:00, doanh nghiệp mất toàn bộ dữ liệu từ 02:00 đến 15:00.
• Nếu có PITR, có thể khôi phục về 14:59:59.

PITR đặc biệt quan trọng với:

• Website thương mại điện tử.
• CRM.
• ERP.
• LMS.
• Hệ thống tài chính.
• AI Chatbot lưu lịch sử hội thoại.
• SaaS nhiều khách hàng.

3. PITR hoạt động như thế nào?

PITR hoạt động bằng cách kết hợp:

• Một bản Full Backup hoặc Base Backup.
• Chuỗi transaction log sau thời điểm backup.
• Mốc thời gian muốn khôi phục.

Quy trình cơ bản:

1. Khôi phục bản Full Backup gần nhất.
2. Đọc lại transaction log sau bản backup.
3. Replay các thay đổi theo thứ tự thời gian.
4. Dừng replay tại thời điểm mong muốn.
5. Đưa Database về trạng thái tại đúng thời điểm đó.

Base Backup
   |
   v
Replay Transaction Log
   |
   v
Stop at target time
   |
   v
Recovered Database

Nhờ vậy, PITR có thể khôi phục dữ liệu rất sát thời điểm trước khi lỗi xảy ra.

4. Backup thông thường khác PITR như thế nào?

5. WAL Archive và Binary Log là gì?

WAL trong PostgreSQL

Trong PostgreSQL, WAL là viết tắt của Write-Ahead Logging. Đây là cơ chế ghi log mọi thay đổi trước khi dữ liệu chính thức được ghi xuống data files.

WAL giúp PostgreSQL:

• Đảm bảo tính bền vững dữ liệu.
• Phục hồi sau crash.
• Hỗ trợ replication.
• Hỗ trợ PITR.

Data Change
    |
    v
Write to WAL
    |
    v
Apply to Data Files

Binary Log trong MySQL/MariaDB

Trong MySQL/MariaDB, Binary Log ghi lại các thay đổi dữ liệu như INSERT, UPDATE, DELETE, DDL.

Binary Log thường dùng cho:

• Replication.
• Point-in-time recovery.
• Audit một số thay đổi dữ liệu.

MySQL Change
    |
    v
Binary Log
    |
    v
Replica / Recovery

6. PITR trong PostgreSQL

PostgreSQL hỗ trợ PITR rất mạnh thông qua Base Backup và WAL Archive.

Các thành phần cần có:

• Base Backup.
• WAL Archive.
• recovery target time.
• Storage lưu trữ backup và WAL.

Ví dụ ý tưởng cấu hình archive WAL:

archive_mode = on
archive_command = 'cp %p /backup/wal_archive/%f'

Ví dụ target time:

recovery_target_time = '2026-06-09 14:59:59'

Luồng khôi phục:

Restore Base Backup
      |
      v
Restore WAL files
      |
      v
Replay WAL until target time
      |
      v
Start PostgreSQL

7. PITR trong MySQL/MariaDB

MySQL/MariaDB có thể thực hiện PITR bằng cách kết hợp Full Backup và Binary Log.

Các thành phần cần có:

• Full Backup.
• Binary Log được bật.
• Thời điểm hoặc vị trí log muốn khôi phục.
• Công cụ mysqlbinlog.

Ví dụ bật Binary Log trong MySQL:

[mysqld]
log_bin = mysql-bin
server_id = 1
binlog_format = ROW

Ví dụ dùng mysqlbinlog để replay đến thời điểm cụ thể:

mysqlbinlog --stop-datetime="2026-06-09 14:59:59" mysql-bin.000001 | mysql -u root -p

8. Ví dụ thực tế về PITR

Ví dụ 1: Xóa nhầm đơn hàng

Một nhân viên chạy nhầm câu lệnh:

DELETE FROM orders WHERE created_at < '2026-06-09';

Nhưng điều kiện sai làm xóa nhiều đơn hàng quan trọng. Nếu có PITR, doanh nghiệp có thể khôi phục Database về thời điểm ngay trước khi câu lệnh DELETE chạy.

Ví dụ 2: Update sai giá sản phẩm

UPDATE products SET price = 0;

Nếu hệ thống có hàng nghìn sản phẩm, lỗi này có thể gây thiệt hại lớn. PITR giúp khôi phục trạng thái trước thời điểm update sai.

Ví dụ 3: Migration lỗi

Khi nâng cấp phần mềm, migration Database có thể lỗi logic hoặc làm thay đổi dữ liệu không đúng. PITR giúp quay lại trạng thái trước khi migration bắt đầu.

Ví dụ 4: Ransomware hoặc lỗi ứng dụng

Nếu ứng dụng bị lỗi và ghi dữ liệu sai trong một khoảng thời gian, PITR giúp khôi phục về mốc thời gian trước khi dữ liệu bắt đầu bị sai.

9. Ưu điểm của PITR

10. Nhược điểm của PITR

11. PITR, RPO và RTO

PITR liên quan trực tiếp đến hai khái niệm quan trọng trong Disaster Recovery:

• RPO: lượng dữ liệu tối đa có thể mất.
• RTO: thời gian tối đa để khôi phục hệ thống.

Nếu doanh nghiệp chỉ backup mỗi ngày một lần, RPO có thể lên đến 24 giờ. Nếu có PITR với log archive liên tục, RPO có thể giảm xuống vài phút hoặc thấp hơn tùy cấu hình.

12. Yêu cầu CPU/RAM/NVMe

PITR yêu cầu hạ tầng lưu trữ ổn định vì phải lưu Base Backup và transaction log liên tục. Với Database lớn, tốc độ NVMe ảnh hưởng rõ rệt đến backup, log archive và restore.

13. Sai lầm thường gặp khi triển khai PITR

• Chỉ có Full Backup nhưng tưởng đã có PITR.
• Không bật WAL Archive hoặc Binary Log.
• Log bị xóa quá sớm.
• Không lưu backup offsite.
• Không test restore theo mốc thời gian.
• Không xác định RPO/RTO.
• Không giám sát dung lượng log.
• Không ghi nhận thời điểm bắt đầu sự cố.
• Không có quy trình restore rõ ràng.
• Backup và log để chung một ổ dễ mất cùng lúc.

14. FAQ 

PITR là gì?

PITR là Point In Time Recovery, kỹ thuật khôi phục Database về một thời điểm cụ thể trong quá khứ.

PITR khác Backup thông thường thế nào?

Backup thông thường khôi phục về thời điểm bản backup được tạo. PITR có thể khôi phục về một mốc thời gian cụ thể nhờ kết hợp backup và transaction log.

PostgreSQL có hỗ trợ PITR không?

Có. PostgreSQL hỗ trợ PITR thông qua Base Backup và WAL Archive.

MySQL có hỗ trợ PITR không?

Có. MySQL/MariaDB có thể thực hiện PITR bằng cách kết hợp Full Backup và Binary Log.

PITR có thay thế Backup không?

Không. PITR cần backup nền và transaction log. Doanh nghiệp vẫn cần Full Backup, offsite backup và kiểm tra restore định kỳ.

PITR có giúp chống ransomware không?

PITR có thể giúp khôi phục về thời điểm trước khi dữ liệu bị mã hóa hoặc ghi sai, nhưng vẫn cần backup offsite, bảo mật truy cập và chiến lược disaster recovery đầy đủ.

Doanh nghiệp nhỏ có cần PITR không?

Nếu dữ liệu thay đổi ít, doanh nghiệp nhỏ có thể bắt đầu với Full Backup định kỳ. Nếu dữ liệu quan trọng và thay đổi liên tục, PITR rất đáng cân nhắc.

15. CloudX hỗ trợ Backup và PITR Database

16. Kết luận

PITR (Point In Time Recovery) là kỹ thuật khôi phục Database về một thời điểm cụ thể, giúp doanh nghiệp giảm thiểu mất mát dữ liệu khi xảy ra lỗi người dùng, lỗi ứng dụng, migration sai hoặc sự cố bảo mật.

Khác với backup thông thường, PITR cần kết hợp giữa Base Backup/Full Backup và transaction log như WAL trong PostgreSQL hoặc Binary Log trong MySQL/MariaDB.

Với các hệ thống quan trọng như CRM, ERP, LMS, thương mại điện tử, SaaS và AI Chatbot, PITR là một phần quan trọng của chiến lược Backup và Disaster Recovery chuyên nghiệp.