Sao lưu và phục hồi thảm họa (Disaster Recovery) trên Cloud

Disaster Recovery (DR) trên cloud là tập hợp chiến lược và quy trình giúp khôi phục hệ thống và dữ liệu sau sự cố lớn như mất cả một vùng hạ tầng, xóa nhầm dữ liệu hay bị mã độc tống tiền mã hóa. Chọn giải pháp nào phụ thuộc vào hai câu hỏi: bạn chấp nhận mất bao nhiêu dữ liệu, và hệ thống được phép ngừng bao lâu. Bài viết này giúp bạn trả lời hai câu hỏi đó và chọn chiến lược phù hợp với ngân sách.

Sao lưu không phải là Disaster Recovery

Nhiều tổ chức nghĩ rằng có bản sao lưu là đủ. Sao lưu chỉ là một thành phần. DR trả lời câu hỏi rộng hơn: khi sự cố xảy ra, làm sao đưa cả dịch vụ hoạt động trở lại, bao gồm máy chủ, mạng, DNS, cấu hình, bí mật, quyền truy cập và con người biết phải làm gì. Có bản sao lưu cơ sở dữ liệu nhưng mất ba ngày dựng lại hạ tầng thì doanh nghiệp vẫn chịu thiệt hại lớn.

Hai chỉ số định hình mọi quyết định: RPO và RTO

• RPO (Recovery Point Objective): lượng dữ liệu tối đa có thể mất, tính theo thời gian. RPO 1 giờ nghĩa là sau sự cố, bạn chấp nhận mất tối đa dữ liệu của một giờ gần nhất.
• RTO (Recovery Time Objective): thời gian tối đa từ lúc sự cố đến khi dịch vụ hoạt động lại.

RPO và RTO càng nhỏ, chi phí càng cao. Không phải hệ thống nào cũng cần mức khắt khe nhất: trang thanh toán có thể cần RTO tính bằng phút, trong khi hệ thống báo cáo nội bộ có thể chờ một ngày. Hãy phân loại hệ thống theo mức quan trọng với doanh nghiệp trước khi bàn đến công nghệ.

Bốn chiến lược DR phổ biến trên cloud

Tài liệu kiến trúc của các nhà cung cấp lớn, chẳng hạn AWS Well-Architected, mô tả bốn mức chiến lược từ rẻ đến đắt:

Các con số mang tính định hướng; thực tế phụ thuộc vào thiết kế, mức tự động hóa và khối lượng dữ liệu của bạn.

Nguyên tắc sao lưu nền tảng

Quy tắc 3-2-1 và biến thể hiện đại

Quy tắc kinh điển: giữ ít nhất 3 bản dữ liệu, trên 2 loại phương tiện lưu trữ khác nhau, với 1 bản ở ngoài địa điểm chính. Trên cloud, "phương tiện khác nhau" có thể hiểu là dịch vụ hoặc lớp lưu trữ khác nhau, và "ngoài địa điểm" là vùng hoặc tài khoản khác. Nhiều tổ chức mở rộng thành 3-2-1-1-0: thêm một bản bất biến hoặc tách biệt hoàn toàn, và không có lỗi khi kiểm tra khôi phục.

Tách biệt tài khoản và quyền

Nếu kẻ tấn công chiếm được tài khoản quản trị chính, chúng có thể xóa cả dữ liệu lẫn bản sao lưu. Lưu bản sao lưu ở một tài khoản cloud riêng với quyền truy cập riêng, chỉ cho phép ghi từ tài khoản chính mà không cho xóa, là biện pháp đơn giản nhưng rất hiệu quả.

Lưu trữ bất biến

Tính năng như S3 Object Lock, Azure Immutable Blob Storage hay khóa lưu giữ của Google Cloud Storage cho phép đặt bản sao lưu ở chế độ không thể sửa, xóa trong một khoảng thời gian định trước, kể cả với tài khoản quản trị. Đây là tuyến phòng thủ quan trọng trước mã độc tống tiền.

Các bước cấu hình chi tiết như mã hóa, phân quyền và vòng đời bản sao lưu được trình bày trong hướng dẫn cấu hình sao lưu dữ liệu đám mây an toàn.

Đừng quên những thứ không phải dữ liệu

Khi khôi phục, bạn cần nhiều hơn dữ liệu:

• Hạ tầng dưới dạng mã: Terraform hoặc CloudFormation cho phép dựng lại mạng, máy chủ, cân bằng tải ở vùng khác trong thời gian ngắn. Kết hợp với pipeline deploy tự động, bạn có thể triển khai lại ứng dụng ở vùng dự phòng bằng cùng quy trình hằng ngày. Không có IaC, việc dựng lại bằng tay dưới áp lực sự cố rất dễ sai.
• Image và artifact: image container và gói ứng dụng phải có sẵn ở registry tại vùng dự phòng.
• Bí mật và chứng chỉ: khóa mã hóa, chứng chỉ TLS và bí mật ứng dụng cần được sao chép an toàn. Nếu khóa mã hóa bản sao lưu nằm cùng chỗ với dữ liệu bị mất, bản sao lưu trở nên vô dụng.
• DNS và điểm vào: chuẩn bị cơ chế chuyển hướng lưu lượng, như bản ghi DNS có kiểm tra sức khỏe, với TTL hợp lý.
• Tài liệu vận hành: runbook từng bước, danh sách liên hệ, ai có quyền ra quyết định chuyển sang vùng dự phòng.

Ransomware thay đổi cách nghĩ về DR

Thảm họa ngày nay không chỉ là cháy trung tâm dữ liệu hay mất điện vùng. Mã độc tống tiền nhắm thẳng vào bản sao lưu để buộc nạn nhân trả tiền. Một số điều cần lưu ý:

• Sao chép liên tục (replication) không bảo vệ trước ransomware, vì dữ liệu bị mã hóa cũng được sao chép sang bên kia. Cần bản sao lưu theo thời điểm với lịch sử đủ dài.
• Kẻ tấn công có thể ẩn mình nhiều ngày trước khi kích hoạt; giữ bản sao lưu đủ lâu để quay về thời điểm trước khi bị xâm nhập.
• Trước khi khôi phục, cần xác định và loại bỏ điểm xâm nhập, nếu không hệ thống mới sẽ bị lây lại.

Kiểm thử: phần bị bỏ qua nhiều nhất

Bản sao lưu chưa từng được khôi phục thử là bản sao lưu chưa được chứng minh. Lên lịch kiểm thử định kỳ:

1. Kiểm tra khôi phục tự động: định kỳ khôi phục bản sao lưu cơ sở dữ liệu vào môi trường tạm và chạy truy vấn kiểm tra.
2. Diễn tập trên bàn (tabletop): đội ngồi lại đi qua kịch bản sự cố, phát hiện chỗ thiếu trong quy trình.
3. Diễn tập chuyển vùng thật: chuyển một phần hoặc toàn bộ dịch vụ sang vùng dự phòng trong khung giờ có kiểm soát, đo RTO thực tế.

Sau mỗi lần diễn tập, cập nhật runbook và cấu hình. Nhiều tổ chức phát hiện RTO thực tế dài gấp nhiều lần mục tiêu vì những chi tiết nhỏ như hạn mức tài nguyên ở vùng dự phòng chưa được nâng.

Tối ưu chi phí cho DR

DR là chi phí bảo hiểm, nên cần cân đối. Một số cách giảm chi phí mà không hy sinh nhiều khả năng phục hồi: dùng lớp lưu trữ giá rẻ cho bản sao lưu cũ, đặt chính sách vòng đời tự động chuyển lớp và xóa bản hết hạn, chỉ chạy tối thiểu ở vùng dự phòng và tăng quy mô bằng tự động hóa khi cần. Bài tối ưu chi phí dịch vụ đám mây có thêm gợi ý về lựa chọn lớp lưu trữ và chính sách vòng đời.

Các bước xây dựng kế hoạch DR

1. Liệt kê hệ thống, xác định mức quan trọng và phụ thuộc giữa chúng.
2. Thống nhất RPO, RTO cho từng nhóm với bộ phận kinh doanh.
3. Chọn chiến lược DR phù hợp cho từng nhóm.
4. Hiện thực sao lưu, sao chép, IaC và cơ chế chuyển hướng lưu lượng.
5. Viết runbook, phân công vai trò.
6. Diễn tập, đo, cải tiến và lặp lại định kỳ.

Một kế hoạch DR tốt không cần hoàn hảo ngay từ đầu. Bắt đầu bằng sao lưu tách tài khoản, bất biến và đã kiểm thử khôi phục cho dữ liệu quan trọng nhất, rồi nâng dần mức độ theo nhu cầu.