Backup & Disaster Recovery ERP: RTO, RPO, restore và DR runbook

Backup và Disaster Recovery ERP là hai lớp khác nhau nhưng phải được thiết kế cùng nhau. Backup tạo bản sao dữ liệu/cấu hình để phục hồi; Disaster Recovery (DR) mô tả cách khôi phục dịch vụ ERP và các dependency cần thiết sau sự cố lớn. Có backup nhưng chưa từng test restore không chứng minh hệ thống có thể phục hồi trong thời gian doanh nghiệp chấp nhận.

ERP thường phụ thuộc database, identity, integration, scheduler, file storage, report, network và hệ thống ngoài. Vì vậy kế hoạch recovery phải dựa trên business impact, không chỉ dựa vào cấu hình hạ tầng. Nếu đang so kiến trúc cloud/on-premise, xem Cloud ERP vs On-premise.

RTO và RPO là gì?

Khái niệm	Câu hỏi	Tác động thiết kế
RTO	ERP có thể ngừng tối đa bao lâu?	Recovery architecture, runbook, staffing
RPO	Có thể chấp nhận mất tối đa bao nhiêu dữ liệu gần thời điểm sự cố?	Backup/replication frequency và data protection

Sơ đồ RTO/RPO trên cùng một timeline

RPO nhìn về phía dữ liệu trước sự cố; RTO nhìn về phía thời gian phục hồi sau sự cố. Cả hai phải bắt đầu từ business impact, sau đó mới thiết kế backup, replication, runbook và staffing.

RTO/RPO phải do business và IT thống nhất theo critical process. Không có một con số chuẩn cho mọi ERP. Order processing, payment, manufacturing hoặc payroll có thể có mức chịu gián đoạn khác nhau.

1. Lập business impact trước khi chọn công nghệ backup

• Process nào dừng khi ERP unavailable?
• Site/warehouse/plant nào bị ảnh hưởng?
• Workaround thủ công tồn tại được bao lâu?
• Transaction nào có thể nhập lại, transaction nào khó tái tạo?
• Integration nào phải phục hồi trước?
• Ai có quyền quyết định failover hoặc restore?

BIA giúp chuyển yêu cầu “ERP phải luôn online” thành recovery objective có thể thiết kế và test.

2. Backup scope phải vượt ra ngoài database

Tùy kiến trúc, phạm vi backup có thể gồm database, application/configuration, custom extension, integration configuration, scheduler/job, report/template, file attachment và security configuration. Không nên giả định backup database là đủ để tái tạo toàn bộ service.

3. Restore test quan trọng hơn báo cáo “backup success”

Job backup hoàn tất chỉ chứng minh dữ liệu đã được ghi ở đâu đó. Restore test phải chứng minh bản backup đọc được, application khởi động được, data có thể reconcile và integration/identity hoạt động đúng sau phục hồi.

• Restore vào môi trường tách biệt.
• Xác minh version/compatibility.
• Kiểm tra record hoặc balance trọng yếu.
• Kiểm tra encryption key/credential dependency.
• Ghi lại thời gian thực tế để so với RTO.
• Ghi lỗi và cập nhật runbook.

4. Backup khác Disaster Recovery ở đâu?

Backup trả lời “có bản dữ liệu nào để khôi phục?”. DR trả lời “làm sao đưa ERP và các dependency trở lại trạng thái phục vụ nghiệp vụ?”. DR có thể bao gồm alternate site/region, network route, identity, DNS, middleware, integration endpoint, monitoring và business communication.

5. SaaS/Cloud ERP vẫn cần shared-responsibility review

Nhà cung cấp SaaS có thể chịu trách nhiệm cho nhiều thành phần hạ tầng, nhưng doanh nghiệp vẫn phải hiểu backup/retention, restore granularity, RTO/RPO cam kết, export khả dụng, identity/integration dependency và quy trình support khi cần khôi phục. “Vendor có backup” không đồng nghĩa mọi nhu cầu recovery của doanh nghiệp đã được đáp ứng.

6. Recovery của integration và queue

Sau khi ERP phục hồi, integration có thể còn message cũ, duplicate hoặc transaction phát sinh trong thời gian downtime. Runbook phải nói rõ replay, idempotency, reconciliation và thứ tự bật interface. Xem tích hợp ERP.

7. Ransomware và immutable/offline copy

Backup chỉ hữu ích nếu sự cố ở production không đồng thời phá luôn toàn bộ backup. Tùy risk model, doanh nghiệp có thể dùng immutable, logically isolated hoặc offline copy, quyền truy cập tách biệt và monitoring cho hành vi xóa/đổi retention bất thường.

Recovery plan nên liên kết với bảo mật ERP vì privileged account, credential và audit log ảnh hưởng trực tiếp khả năng bảo vệ bản sao.

8. DR drill phải có business validation

DR drill không nên dừng ở việc “server đã lên”. Cần smoke test critical business flow, data reconciliation và integration. Với process nhạy cảm, business owner phải xác nhận service phục hồi đúng chức năng chứ không chỉ infrastructure team xác nhận endpoint reachable.

Recovery runbook nên có gì?

• Incident classification và authority kích hoạt.
• Contact/escalation theo vendor và owner.
• Thứ tự khôi phục component/dependency.
• Backup/restore source và credential procedure.
• Validation theo technical + business.
• Integration replay/reconciliation.
• Communication cho user và management.
• Return-to-primary/failback nếu có.
• Post-incident review và update runbook.

Checklist Backup & DR ERP

• BIA, RTO và RPO được business owner duyệt.
• Backup scope bao phủ component cần thiết.
• Retention và protection chống xóa/sửa ngoài ý muốn rõ ràng.
• Restore test đã chạy và đo thời gian thực.
• DR dependency gồm identity/network/integration đã inventory.
• Runbook có authority và escalation.
• Critical integration có replay/reconciliation plan.
• DR drill có business validation.
• Known gap có owner và remediation plan.

Trước go-live, các recovery dependency cũng nên xuất hiện trong Go-live ERP & Cutover Checklist và yêu cầu vendor nên được khóa từ RFP ERP.

Kết luận

Backup ERP là điều kiện cần nhưng chưa đủ cho khả năng phục hồi. Doanh nghiệp cần RTO/RPO dựa trên business impact, restore test, DR runbook và validation xuyên cả data, identity, integration và critical process. Recovery chỉ được coi là sẵn sàng khi đã được diễn tập bằng evidence.

Nguồn kiểm chứng cho RTO/RPO, backup và DR

• NIST SP 800-34 Rev. 1 — hướng dẫn contingency planning chính thức, bao gồm business impact analysis, recovery objectives, recovery strategy, testing và plan maintenance.
• Dynamics 365 Finance & Operations service description — nêu cơ chế backup/retention của SaaS và cho thấy backup capability cụ thể phụ thuộc service.
• Microsoft Business Continuity & Disaster Recovery — mô tả BCDR cho production environments trong Dynamics 365/Power Platform SaaS.

Nguồn được kiểm tra ngày 09/08/2026. RTO/RPO và recovery design của từng doanh nghiệp vẫn phải dựa trên business impact và điều khoản dịch vụ thực tế, không copy một con số chung.

Khi continuity cần gắn với vận hành Odoo

Bài này tiếp tục sở hữu intent Backup & Disaster Recovery ERP vendor-neutral. Khi hệ thống đang vận hành là Odoo và cần gắn backup/restore, integration recovery, release, incident và operational ownership trong cùng support model, xem dịch vụ hỗ trợ Odoo.