Hiểu về thông số Recovery Point Objective (RPO)
Trong sao lưu và phục hồi, 2 khái niệm quan trọng nhất là Recovery Time Objective (RTO) và Recovery Point Objective (RPO). Nếu như khái niệm RTO khá đơn giản thì RPO lại gây nhiều khó hiểu cho người IT; đặc biệt nếu bạn mới tiếp cận vấn đề sao lưu phục hồi.
Vậy RPO là gì? có ý nghĩa thế nào trong sao lưu dữ liệu? Bài viết bên dưới sẽ giúp bạn làm rõ những thắc mắc này.
RPO là gì?
Xét về lý thuyết, có khá nhiều câu chữ khác nhau định nghĩa khái niệm RPO. Gần như mỗi tài liệu bạn tìm thấy trên Internet lại có một cách định nghĩa khác nhau về thông số này.
Về ý nghĩa, bạn có thể hiểu RPO là lượng dữ liệu tối đa mà công ty có thể chấp nhận mất mát khi sự cố mất dữ liệu xảy ra. “Lượng dữ liệu” này không đo bằng đơn vị MB, GB hay TB như thông thường; mà được đo bằng đơn vị thời gian, thường là giờ, ngày (hoặc thậm chí phút, giây với doanh nghiệp có yêu cầu RPO cao).
Vẫn còn chút khó hiểu? Tham khảo ví dụ bên dưới có thể giúp bạn nắm rõ hơn.
Xem xét một ví dụ
Doanh nghiệp bạn là công ty hoạt động trong lĩnh vực thương mại điện tử. Mọi hoạt động kinh doanh của công ty đều được xử lý bởi phần mềm quản lý kinh doanh. Dữ liệu được phát sinh liên tục với dung lượng lớn trong thời gian ngắn. Do đó, bất kỳ mất mát nào với dữ liệu này đều ảnh hưởng nghiêm trọng đến hoạt động của công ty, gây thiệt hại lớn về doanh thu, uy tín. Vì lý do đó, công ty chỉ chấp nhận mất mát lượng dữ liệu tối đa tương đương 30 phút làm việc. Có nghĩa RPO = 30 phút.
Ngoài dữ liệu trên, công ty bạn cũng có một số dữ liệu khác như dữ liệu nhân sự – tiền lương, file báo cáo của nhân viên,… Xét về tầm quan trọng, những dữ liệu này nếu bị mất mát một phần thì thiệt hại cũng không lớn như dữ liệu phần mềm quản lý kinh doanh. Đồng thời đây là dữ liệu được phát sinh từ nhân viên công ty. Nên nếu mất mát vẫn có thể nhập lại được. Do đó, công ty chấp nhận mất mát lượng dữ liệu tương đương 24 giờ với những dữ liệu này. Tức là RPO = 24 giờ.
Tóm lại, thông số RPO biểu đạt mức độ quan trọng của dữ liệu và khả năng chấp nhận mất mát khi sự cố xảy ra. Dữ liệu càng quan trọng, và có tính chất khó (thậm chí không thể) tạo dựng lại khi bị mất mát thì khi đó thông số RPO càng cao. Ngược lại, dữ liệu ít quan trọng, hoặc quan trọng nhưng vẫn có thể tạo lại được thì yêu cầu RPO thường thấp hơn.
RPO ảnh hưởng thế nào đến cách sao lưu dữ liệu?
Giá trị RPO quyết định tần suất sao lưu dữ liệu. Nếu RPO = 4 giờ, bạn cần phải sao lưu dữ liệu lâu nhất 4 giờ/lần. Nếu sao lưu với tần suất thưa hơn (chẳng hạn 24 giờ/lần), khi sự cố xảy ra nhiều khả năng bản sao lưu gần nhất bạn có thể phục hồi cách lâu hơn 4 giờ. Hẳn nhiên, khi đó bạn không thể đáp ứng được RPO đặt ra.
Tiếp đó, tần suất sao lưu lại ảnh hưởng đến giải pháp và chiến lược sao lưu. Chẳng hạn RPO = 30 phút. Nhưng lượng dữ liệu quá lớn khiến thao tác Full backup không thể hoàn thành trong 30 phút. Khi đó, bạn cần cân nhắc sao lưu Differential backup (và Transaction log nếu là dữ liệu Database). Nếu các phương án này vẫn không thể đáp ứng giá trị RPO = 30 phút, bạn cần tìm kiếm các giải pháp cao cấp hơn như Mirror, Synchronization,…
Quay lại với ví dụ RPO = 4 giờ, bạn hoàn toàn có thể sao lưu với tần suất 1 giờ/lần, 2 giờ/lần. Điều này là quá tốt khi cần phục hồi dữ liệu. Nhưng ngược lại, sao lưu với tần suất dày như vậy lại tốn nhiều chi phí (chi phí ở đây bao hàm cả dung lượng, đường truyền, hiệu năng,…).
Do đó, việc xác định đúng giá trị RPO là yếu tố cực kỳ quan trọng khi xây dựng bất kỳ chiến lược sao lưu dữ liệu nào. Để có được giá trị RPO chính xác, bạn cần làm việc kỹ càng với các bộ phận liên quan trong công ty. Đặc biệt phải có được sự đồng ý của cấp lãnh đạo.
# Giúp tăng 48 lần RPO khi phục hồi SQL Server
zBackup sao lưu SQL Server cứ mỗi 30 phút thay vì 24 giờ
Với khả năng sao lưu offsite tự động cùng công nghệ In-File Delta, zBackup giúp bạn dễ dàng sao lưu Transaction Log với tần suất 30 phút/lần. Nhờ đó, bất kỳ lúc nào sự cố xảy ra với SQL Server, bạn đều có thể phục hồi dữ liệu trở về thời điểm cách xa nhất 30 phút trước.
