RPO mô tả cửa sổ mất dữ liệu mà bạn sẵn sàng chấp nhận; RTO mô tả thời gian gián đoạn mà bạn muốn giữ trong giới hạn. Hãy xác định cả hai cho một chức năng kinh doanh hữu ích, rồi chứng minh trình tự khôi phục trong một buổi diễn tập. Chỉ một lịch sao lưu hay một thông số kỹ thuật máy chủ không thiết lập được mục tiêu nào.
Bắt đầu với một dịch vụ mọi người có thể sử dụng
Các mục tiêu khôi phục trở nên hữu ích khi chúng mô tả một chức năng kinh doanh thay vì một máy riêng lẻ. Một máy chủ có thể khởi động trong khi khách hàng vẫn không thể đăng nhập, truy xuất tệp hay hoàn tất một yêu cầu. Hãy viết điều kiện kết thúc bằng ngôn ngữ thông thường: người dùng được ủy quyền có thể truy cập ứng dụng và dữ liệu cần thiết nhất quán. Điều này khiến mục tiêu có thể kiểm thử bởi người ngoài nhóm hạ tầng.
Hỏi chủ sở hữu ứng dụng xem một gián đoạn sẽ ngăn cản điều gì và dữ liệu bị thiếu sẽ gây tốn kém ra sao. Một ấn phẩm hàng tuần và một ứng dụng xử lý giao dịch có thể có câu trả lời khác nhau. Coi các mục tiêu thu được là mục tiêu lập kế hoạch, không phải lời hứa bịa ra từ danh mục phần cứng. Ghi lại ai đã phê duyệt chúng và kế hoạch bao phủ những tình huống lỗi nào.
Tách biệt hai đồng hồ
RPO liên quan đến việc dữ liệu được khôi phục có thể lùi xa bao nhiêu so với thời điểm gián đoạn. RTO liên quan đến việc chức năng có thể không khả dụng trong bao lâu. Một bản sao lưu gần đây có thể cải thiện cửa sổ mất dữ liệu trong khi một quá trình khôi phục chậm vẫn trượt mục tiêu thời gian khôi phục. Ngược lại, một lần khởi động lại nhanh có thể khôi phục quyền truy cập vào một ứng dụng mà dữ liệu mới nhất của nó không tồn tại.
Xác định các điểm tham chiếu. Quyết định khi nào đồng hồ sự cố bắt đầu, điều gì được tính là hoạt động đã khôi phục và điểm dữ liệu khả dụng sẽ được xác định như thế nào. Giữ các mục tiêu tách biệt khỏi kết quả đo được: mục tiêu là điều bạn hướng tới; một buổi diễn tập cho thấy quy trình hiện tại đã đạt được gì. Hãy xem lại một trong hai khi ứng dụng hoặc tập dữ liệu thay đổi.
Lập ngân sách cho từng bước khôi phục
Một ngân sách RTO thực tế bao gồm phát hiện, đánh giá, ủy quyền, truy cập môi trường khôi phục, khôi phục, xác thực ứng dụng và mở lại. Thời gian sao chép tệp chỉ là một thành phần. Nếu người giữ khóa khôi phục không sẵn có, một bản sao lưu nhanh về lý thuyết vẫn có thể không dùng được. Liệt kê các phụ thuộc và đảm bảo nhóm khôi phục có thể tiếp cận chúng trong sự cố đang được xem xét.
Gán thời gian tạm thời cho từng bước, rồi thay thế ước tính bằng quan sát. Trong ngân sách hai giờ minh họa này, khôi phục nhận khoảng cho phép lớn nhất nhưng xác thực vẫn có thời gian được bảo vệ. Các con số mô tả một ví dụ lập kế hoạch, không phải việc cung cấp dịch vụ SwissOctet. Nếu tổng không có biên dự phòng, thiết kế cần được cải thiện trước khi mục tiêu trở nên đáng tin cậy.
| Bước khôi phục | Khoảng cho phép minh họa | Bằng chứng cần thu thập |
|---|---|---|
| Phát hiện và đánh giá | 15 phút | Cảnh báo đến và quyết định sự cố |
| Chuẩn bị môi trường khôi phục | 20 phút | Quyền truy cập và cấu hình sẵn có |
| Khôi phục dữ liệu và dịch vụ | 50 phút | Hoàn tất khôi phục với dữ liệu nhất quán |
| Xác thực và mở lại | 25 phút | Hành trình người dùng thành công |
| Biên dự phòng | 10 phút | Công việc bất ngờ được ghi lại |
Kiểm tra cửa sổ mất dữ liệu thực tế
Một tác vụ được lên lịch mỗi giờ không tự động mang lại RPO một giờ. Một tác vụ thất bại, tải lên bị trễ hoặc bản sao không dùng được có thể khiến điểm khôi phục mới nhất cũ hơn nhiều. Hãy quan sát việc hoàn thành thành công và trạng thái thực sự có thể khôi phục. Đối với một ứng dụng có nhiều kho dữ liệu, hãy xác nhận rằng các điểm khôi phục của chúng tương thích thay vì đọc từng dấu thời gian một cách riêng lẻ.
Chọn một sự kiện tham chiếu trong một buổi diễn tập, chẳng hạn một bản ghi kiểm thử được ủy quyền tạo tại một thời điểm đã biết. Sau khi khôi phục, xác định bản ghi hợp lệ mới nhất và đo khoảng cách. Sử dụng dữ liệu kiểm thử vô hại. Điều này cho một kết quả thực tế và phơi bày những giả định mà một bảng điều khiển chỉ hiển thị thành công của tác vụ có thể để ẩn.
Chọn một chiến lược trong ngân sách
Sao lưu và khôi phục, môi trường dự phòng đã chuẩn bị sẵn và thiết kế ứng dụng được sao chép đánh đổi chi phí và độ phức tạp lấy tốc độ khôi phục. Sao chép có thể giảm một số độ trễ nhưng cũng có thể tái tạo một lần xóa nhầm hoặc sai sót ứng dụng. Một môi trường dự phòng đã lệch khỏi cấu hình đang hoạt động tạo ra rủi ro riêng. Chọn một chiến lược dựa trên các tình huống lỗi và mục tiêu bạn đã ghi lại.
Hãy xem xét một dịch vụ nhỏ với mục tiêu bốn giờ và một tập dữ liệu lớn hơn mà chỉ riêng việc khôi phục đã mất sáu giờ trong một buổi diễn tập. Mua một cổng mạng nhanh hơn chỉ là một giả thuyết: đọc lưu trữ, ghi nhận và khôi phục ứng dụng có thể chiếm ưu thế. Cải thiện bước giới hạn đã đo, giảm tập khôi phục hoặc thay đổi chiến lược, rồi diễn tập lại.
Diễn tập mà không gây nguy hiểm cho môi trường sản xuất
Sử dụng một môi trường khôi phục biệt lập và một khung thời gian diễn tập đã xác định. Đảm bảo các tác vụ đã khôi phục không thể gửi thông báo thật, nhận thanh toán công khai hoặc ghi vào các tích hợp sản xuất. Kiểm thử quyền truy cập, tính toàn vẹn dữ liệu và hành trình người dùng đại diện trước khi coi buổi diễn tập đã hoàn tất. Bao gồm một người không viết quy trình gốc để phơi bày các hướng dẫn còn thiếu.
Giữ một dòng thời gian của buổi diễn tập, điểm khôi phục đạt được và mọi gián đoạn do thông tin không sẵn có. Một báo cáo hữu ích nêu rõ kết quả đo được, khoảng cách so với mục tiêu và một hành động khắc phục cụ thể. Lặp lại sau những thay đổi có ý nghĩa và theo khoảng thời gian phù hợp với tầm quan trọng của dự án.
Giữ kế hoạch khả dụng trong khi xảy ra sự cố
Lưu trữ quy trình khôi phục ở nơi nhóm có thể truy cập mà không chỉ dựa vào ứng dụng đã hỏng. Giữ thông tin xác thực và khóa mã hóa ở một vị trí được bảo vệ với quy trình truy cập đã được kiểm thử. Cập nhật danh bạ, kích thước tập dữ liệu và các phụ thuộc khi dự án phát triển. Một kế hoạch lỗi thời có thể tiêu tốn biên thời gian trước cả khi quá trình khôi phục bắt đầu.
Khi so sánh các cấu hình SwissOctet, hãy tách kiến trúc khôi phục của bạn khỏi các tùy chọn sao lưu của danh mục. Xác nhận một tùy chọn bao phủ những gì, dữ liệu khôi phục được giữ ở đâu và ai thực hiện khôi phục. Danh mục không thiết lập RPO hay RTO của ứng dụng. Quy trình đã đo của bạn và các điều khoản dịch vụ thực tế tạo cơ sở cho quyết định đó.
Danh sách kiểm tra thực tế của bạn.
- Xác định chức năng kinh doanh đã khôi phục.
- Phê duyệt các mục tiêu RPO và RTO riêng biệt.
- Lập ngân sách cho phát hiện, truy cập, khôi phục và xác thực.
- Đo điểm dữ liệu khả dụng mới nhất.
- Diễn tập trong một môi trường biệt lập.
- Ghi lại khoảng cách và lặp lại sau những thay đổi liên quan.
Những chi tiết quan trọng.
RTO có giống với thời gian hoạt động không?+
Không. RTO là mục tiêu khôi phục cho một tình huống gián đoạn. Thời gian hoạt động đo tính khả dụng trong một khoảng thời gian; một cái không thiết lập cái kia.
Sao lưu hàng giờ có đảm bảo RPO một giờ không?+
Không. Hãy kiểm tra các bản sao đã hoàn tất, dùng được và các yêu cầu nhất quán của ứng dụng. Tác vụ thất bại và truyền tải bị trễ có thể mở rộng khoảng cách dữ liệu có thể khôi phục.
Mọi dự án có phải sử dụng máy chủ dự phòng không?+
Hãy chọn một chiến lược dựa trên các mục tiêu khôi phục của dự án và quy trình khôi phục đã đo. Một máy chủ dự phòng làm tăng chi phí và độ phức tạp vận hành và không tự động cần thiết.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- NIST SP 800-34 Rev. 1: Hướng dẫn lập kế hoạch dự phòng nvlpubs.nist.gov
- AWS Well-Architected: Xác định mục tiêu khôi phục docs.aws.amazon.com
- Microsoft Learn: Liên tục kinh doanh, tính khả dụng cao và khôi phục sau thảm họa learn.microsoft.com
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.