Khôi phục thảm họa với RPO và RTO có thể kiểm chứng

Ý chính: Một bản sao lưu chưa phải năng lực phục hồi cho tới khi đội ngũ đã khôi phục thử, kiểm tra dữ liệu và đo thời gian.

Thuật ngữ trong bài: RPO: lượng dữ liệu tối đa có thể mất; RTO: thời gian tối đa để khôi phục; failover: chuyển dịch vụ sang hệ thống dự phòng.

Bài toán thực tế

Bản sao dữ liệu cũng sao chép thao tác xóa nhầm. Bản sao lưu có thể không dùng được nếu thiếu khóa mã hóa hoặc bỏ sót hàng đợi và kho tệp. Vì vậy, phục hồi phải được kiểm thử như một quy trình hoàn chỉnh.

Điểm dễ bị bỏ qua

Replica sao chép cả dữ liệu đúng lẫn thao tác xóa nhầm, còn bản sao lưu chưa được khôi phục thử chỉ là một giả định. Năng lực phục hồi phải bao gồm dữ liệu, khóa mã hóa, hàng đợi, kho tệp và thứ tự khởi động các dịch vụ.

RPO và RTO chỉ có ý nghĩa khi được đo trong diễn tập gần với điều kiện thật và có người chịu trách nhiệm cho từng bước.

Luồng xử lý

Thiết kế và triển khai

Phân tầng dữ liệu theo tác động

Chọn cơ chế sao chép dữ liệu, nhật ký shipping, bản chụp và thời gian lưu giữ từ RPO thật, thay vì dùng mẫu đắt nhất cho mọi nơi.

Phục hồi dịch vụ phụ thuộc theo thứ tự

Identity, secret, cơ sở dữ liệu, broker, object kho lưu trữ và application tạo thành graph. Tự động hóa và kiểm thử đúng thứ tự đó.

Kiểm chứng nghiệp vụ điều kiện bất biến

Row count là chưa đủ. Phải kiểm tra balance, khả năng cô lập khách hàng, sự kiện continuity và object reference sau restore.

Đi sâu vào thiết kế

RPO gồm cả hệ bất đồng bộ

Chỉ restore cơ sở dữ liệu có thể làm broker offset, search chỉ mục và object metadata lệch nhau. Cần xác định phần nào dựng lại, phần nào authoritative.

Phục hồi cần năng lực tổ chức

Vai trò khi ứng phó sự cố, trao đổi thông tin template, vendor contact và quyết định authority là một phần của RTO. Công nghệ không bù được một phê duyệt không ai có quyền đưa ra.

Cách triển khai

1. Định nghĩa RPO và RTO cho từng năng lực nghiệp vụ thay vì dùng một con số cho cả nền tảng.
2. Lập danh sách mọi kho dữ liệu, khóa mã hóa và cấu hình cần thiết để phục hồi trọn vẹn.
3. Tự động khôi phục vào môi trường cô lập và tổ chức diễn tập định kỳ với thời gian được đo.

Mã minh họa: Cổng kiểm chứng trước khi hoàn tất phục hồi

restore(backupId, isolatedEnvironment)
assert pointInTime >= incidentTime - RPO
assert invariant('tenant_isolation')
assert invariant('ledger_balanced')
assert syntheticJourney('sign-in-to-publish')
approve traffic cutover

Giữ môi trường khôi phục ở trạng thái cô lập cho tới khi kiểm tra tính toàn vẹn và bảo mật đạt; không đưa một bản sao chưa xác minh tới người dùng.

Rủi ro cần tính trước

• Sao lưu báo thành công nhưng không thể khôi phục vì định dạng hoặc khóa mã hóa đã thay đổi.
• DNS đã chuyển vùng nhưng ứng dụng khách vẫn giữ kết nối dài tới vùng cũ.
• Quá trình chuyển ngược về vùng chính ghi đè dữ liệu đã nhận trong thời gian chạy dự phòng.

Nên theo dõi gì?

Cách kiểm chứng

• Restore ngẫu nhiên một bản sao lưu mà không dùng môi trường gốc.
• Làm mất một region trong khi synthetic write tiếp tục và đo dữ liệu được chấp nhận.
• Thực hiện failback và đối soát mọi write trong disaster mode.

Đưa vào production từng bước

Tự động khôi phục một kho dữ liệu quan trọng trước, rồi thêm từng dịch vụ phụ thuộc cho tới khi hoàn tất được một hành trình nghiệp vụ. Diễn tập định kỳ, luân phiên người chỉ huy, ghi lại RPO/RTO thực tế và tự động hóa mọi bước thủ công dễ sai.

Checklist trước khi vận hành

• Bản sao lưu không thể thay đổi, được mã hóa và nằm ngoài sự cố ranh giới chính.
• Thông tin xác thực restore và mã hóa khóa sống sót qua cùng thảm họa.
• Failover có cơ chế fenced single writer và failback được tài liệu hóa.

Điều cần nhớ

Khả năng phục hồi được chứng minh bằng thời gian khôi phục đã đo và dữ liệu đã đối soát, không phải bằng việc hệ thống có replica.