RTO và RPO: 2 vấn đề trong backup/restore basic

RTO và RPO – Trong hệ thống sao lưu phục hồi cơ bản (backup/restore basic), 2 vấn đề quan trọng nhất là Recovery Time Objective (RTO) và Recovery Point Objective (RPO). Vậy RTO và RPO là gì? cả 2 vấn đề trên có ý nghĩa và lưu ý 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.

1. RTO và RPO là gì?

1.1. RPO là gì? RPO như thế nào là hợp lý ?

RTO và RPO – Khái niệm RPO là gì? RPO là một khái niệm viết tắt của cụm từ Recovery Point Object (RPO) hay còn được dịch nôm na là thời điểm phục hồi dữ liệu.

Thời điểm ở đây là thời điểm cụ thể, ví dụ như 1 phút trước, 1 ngày trước, 1 tuần trước hoặc 1 tháng trước, đạ khái là 1 thời điểm đã xảy ra và doanh nghiệp muốn dữ liệu được phục hồi vào đúng thời điểm mà họ mong muốn.

Ví dụ như: Công ty ABC muốn hệ thống backup của họ có khả năng phục hồi dữ liệu 1 ngày trở về trước từ thời điểm cần phục hồi dữ liệu thì RTO là 1 ngày. Hay một công ty khác muốn có thể khôi phục lại dữ liệu ở bất kỳ thời điểm nào thì RTO của họ là zero.

1.2. RTO là gì? Vai trò của RTO trong backup/restore

RTO và RPO – RTO là gì? RTO được định nghĩa là Recovery Time Object(RTO), còn có nghĩa là thời gian phục hồi mà thời gian này được tính từ thời điểm của chủ doanh nghiệp đưa ra yêu cầu để restore lại theo RPO đã chỉ định.

Ví dụ như một phòng nhân sự mất đi file tính lương và đưa ra yêu cầu phải hoàn thành việc phục hồi trong vòng 1 tiếng thì RTO lúc này sẽ là 1 giờ.

Tương tự như RPO thì thời gian này sẽ đóng vai trò tỉ lệ nghịch với chi phí, nghĩa là RTO càng nhỏ, chi phí càng lớn.

2. Các vấn đề về RTO và RPO:

2.1. RTO lớn/nhỏ liên quan gì trong giải pháp backup?

RTO càng ngắn thì ảnh hưởng đến doanh nghiệp càng nhỏ, RTO càng cao thì doanh nghiệp thất thu càng lớn (đối với những hệ thống đặc biệt quan trọng). Thông thường RTO và RPO là cặp đôi đồng hành, thường RPO ngắn thì đòi hỏi RTO cũng ngắn.

Trong RTO vai trò năng lực của đội ngũ thực hiện công tác phục hồi hệ thống là cực kỳ quan trọng, đối với RPO bạn có thể set lịch để task backup tự động chạy, và công việc chính chỉ là monitoring thì RTO đòi hỏi bạn phải bắt tay vào restore, và việc này hết sức cẩn trọng và tỉ mỉ.

Đối với những hệ thống lớn chỉ cần 1 sai lần nhỏ sẽ dẫn đến hậu quả vô cùng nghiêm trọng, đối với 1 hệ thống vừa và nhỏ việc bạn restore sai thời điểm sẽ làm cho mục đích của việc phục hồi dữ liệu không đúng như yêu cầu, thậm chí làm mất luôn những file đang có.

RTO càng nhỏ đòi hỏi hệ thống backup của bạn phải hoạt động real time, nghĩa là bên cạnh hệ thống production bạn đang xài thì phải có 1 hệ thống backup chạy song song. Đối với server có thể là cluster, đối với mặt dữ liệu có thể là backup file ra, hay backup hệ thống hệ điều hành ra 1 thiết bị lưu trữ khác. Chung quy là RTO = 0 tương ứng với việc chi phí và nhân lực đầu tư để vận hành và duy trì hệ thống backup sẽ rất đắt đỏ.

Đối với 1 số doanh nghiệp đòi hỏi RTO = 0, điển hình là các ngân hàng, các công ty cung cấp service IT cho khách hàng với cam kết on time 24/24 kể cả động đất sóng thần. Với các doanh nghiệp loại này, thay vì họ chỉ tốn 1 triệu $ đầu tư cho hệ thống production chạy thì giờ họ sẽ tốn thêm 2, 3 triệu $ thậm chí nhiều hơn để đầu tư những site tương tự ở vị trí khác nhau và hệ thống backup chạy real time cùng production vận hành liên tục.

Đối với nhiều công ty lớn ví dụ như google, microsoft, amazon, thì RTO của họ gần như là zero, và họ có những hệ thống backup của backup của backup, có nghĩa là nhiều lần backup, cùng 1 lúc ra lệnh thực thi ghi chép 1 file dữ liệu có thể được ghi và lưu trữ ở nhiều nơi khác nhau trên thế giới và việc backup cho các loại dữ liệu nầy hầu như real time. Nên bất kỳ thời điểm nào chúng ta cần phục hồi lại

=> Tóm lại RTO = 0 tương ứng với việc ta phải đầu tư chi phí cực cao.

2.2. RTO như thế nào là hợp lý trong backup/restore?

Việc này phụ thuộc hoàn toàn vào doanh nghiệp. Nếu công ty bạn việc tương tác với khách hàng 24/24 ,1 giờ off time cũng gây thiệt hại lớn cho doanh nghiệp, thì chắc chắn khỏi phải bàn, RTO phải là zero.

Nếu doanh nghiệp của bạn mất dữ liệu hay hệ thống có down 1 vài giờ hay 1 ngày, công ty đóng cửa cho nhân viên nghĩ sớm, mai làm lại bình thường, coi như nghỉ ngơi 1 ngày cho khỏe.

Dữ liệu không quá quan trọng đến mức là phải phục hồi lại ngay thời điểm từ lúc hệ thống dừng 1 – 2 h hay thậm chí 1 ngày, thì việc bạn chọn RT0 = 0, sẽ là gánh nặng cho doanh nghiệp bạn để nuôi hệ thống backup.

Việc tính toán RTO phải dựa trên tiêu chí là lượng dữ liệu mất quy ra bao nhiêu tiền, và đầu tư vào hệ thống backup có mang lại giá trị tương xứng hay không, ví dụ như bạn mất dữ liệu 1 ngày, thiệt hại tính ra là 1 triệu VNĐ.

Nhưng bạn tốn chi phí để duy trì hệ thống backup là 10 tr/ ngày thì chắc chắn là phải xem lại 2 yếu tố, 1 là RTO có phù hợp hay chưa, 2 hệ thống backup của bạn đầu tư có phù hợp với chi phí mà doanh nghiệp bạn tạo ra hay chưa.

3. Cách xác định RTO và RPO:

RTO (Recovery Time Objective) và RPO (Recovery Point Objective) là hai thuật ngữ quan trọng trong quá trình sao lưu dữ liệu và phục hồi hệ thống. Dưới đây là hướng dẫn về cách tính RTO và RPO:

3.1. Xác định Recovery Time Objective (RTO):

RTO là thời gian tối đa mà một hệ thống hoặc dịch vụ có thể bị gián đoạn trước khi được khôi phục lại mà không gây ra tác động lớn đến hoạt động kinh doanh. Để tính toán RTO, bạn cần thực hiện các bước sau:

• Xác định các quy trình, ứng dụng hoặc hệ thống quan trọng cần được khôi phục sau một sự cố.
• Đo lường thời gian mà hệ thống hoặc dịch vụ đó có thể được khôi phục lại từ thời điểm xảy ra sự cố.
• Cân nhắc các yếu tố khác nhau như thời gian cần để khắc phục sự cố, thời gian cần để khởi động lại hệ thống và thời gian cần để kiểm tra tính khả dụng của hệ thống.

Xác định RTO dựa trên các yếu tố trên và mục tiêu kinh doanh của tổ chức.

3.2. Xác định Recovery Point Objective (RPO):

RPO xác định thời điểm gần nhất mà dữ liệu được sao lưu sẽ được phục hồi sau một sự cố. RPO quyết định mức độ mà dữ liệu có thể bị mất trong quá trình phục hồi. Để tính toán RPO, bạn có thể thực hiện các bước sau:

• Xác định các dữ liệu quan trọng cần được sao lưu.
• Xác định tần suất sao lưu dữ liệu (ví dụ: hàng ngày, hàng tuần, hàng tháng).
• Đo lường thời gian giữa các bản sao lưu để xác định RPO.
• Cân nhắc các yếu tố như thời gian để sao lưu dữ liệu và khả năng mất dữ liệu trong trường hợp xảy ra sự cố.
• Xác định RPO dựa trên các yếu tố trên và yêu cầu của tổ chức về mức độ mất mát dữ liệu có thể chấp nhận được.

RTO và RPO đóng vai trò quan trọng trong quyết định kiến trúc sao lưu và phục hồi của một hệ thống. Tùy thuộc vào yêu cầu của

4. Giải pháp RTO và RPO từ góc nhìn khách quan

RTO và RPO luôn là các khái niệm đi cùng với nhau thành “bộ đôi hoàn hảo” với tính quyết định giá trị hệ thống hồi phục dữ liệu cùng những giải pháp khác đi kèm.

Với những hệ thống đòi hỏi RPO tính bằng 1 vài  phút đến 1 vài giây  thông thường người ta hay sử dụng những hệ thống Synchronous Replication (Nhân rộng đồng bộ) dữ liệu được đặt ở nhiều site khác nhau và đồng bộ liên tục.

Với RPO được tính bằng 1 vài giờ đến 1 ngày thông thường người ta sử dụng Asynchronous Replication (Nhân rộng không đồng bộ). Dữ liệu được đặt ở nhiều site khác nhau và thời gian đồng bộ được tính bằng giờ, ngày.

Đối với những hệ thống yêu cầu RPO không quá rush ( được tính bằng vài ngày cho đến 1 tuần) thì việc lưu trữ backup trên tape thường được sử dụng nhiều, thông thường sau khi hoàn thành task backup dữ liệu được lưu vào tape và đặt ở 1 nơi khác cách xa công ty ( thường là đặt trong các safe box tại  ngân hàng).

Việc đòi hỏi thời gian up-time 24/24 kể cả lúc sự cố xảy ra (RTO=0) đòi hỏi bạn phải trang bị hệ thống HA ở nhiều site khác nhau, đối với việc HA thời gian down time hầu như là zero.

Khi sự cố xảy ra, việc phục hồi nguyên hệ thống được tính bằng nhiều giờ đến nhiều ngày thông thường hay dùng hot site.

Hot site là 1 nơi đặt cách xa công ty và có trang bị đầy đủ các hạ tầng tối thiểu để vận hành 1 hệ thống mà site chính đang có, bao gồm từ hạ tầng về công nghệ thông tin và nơi làm việc cho nhân viên và dĩ nhiên dữ liệu định kỳ vẫn được đồng bộ lên hot site.

Trong thời gian chuyện hoạt động tạm thời lên hot site, bạn tiến hành xây dựng lại site chính. Khi site chính đã phục hồi, công việc cần làm là đồng bộ dữ liệu từ hot site về site chính. Đối với các công ty lớn thông thường hot site luôn nằm trong kế hoạch BCP(Business Continueus Plainning)  của họ.

Hi vọng bài viết có ích với các bạn!

P.A Việt Nam tiên phong trong thị trường Internet & Web.
Là nhà đăng ký tên miền lớn nhất Việt Nam. Chuyên nghiệp trong lĩnh vực Tên miền, Website, Email, Server, Thiết kế Web.

Thông tin kiến thức vps-dedicated-colocation tại: https://kb.pavietnam.vn/category/vps-dedicated-colocation
Đăng ký dịch vụ P.A Việt Nam: https://www.pavietnam.vn/
P.A Việt Nam cung cấp đa dạng cấu hình VPS và Dedicated tại: Cloud Server –  Cloud Server Pro  –  Máy Chủ Riêng
Tham khảo các Ưu đãi hiện có tại: https://www.pavietnam.vn/vn/tin-khuyen-mai/
Facebook: https://www.facebook.com/pavietnam.com.vn