Cách xây dựng kế hoạch khôi phục dữ liệu nghiên cứu

Điểm này đặc biệt quan trọng với dữ liệu nghiên cứu. Một dự án có thể không chỉ phụ thuộc vào tập dữ liệu cuối cùng mà còn vào dữ liệu thô, metadata, mã phân tích, cấu hình phần mềm, notebook, tài liệu mô tả phương pháp và lịch sử phiên bản. Khôi phục được một tệp nhưng mất các thành phần tạo nên khả năng tái lập nghiên cứu vẫn có thể khiến quá trình phục hồi không đạt mục tiêu.

Xác định dữ liệu nào thực sự phải được khôi phục

Bước đầu tiên không phải chọn phần mềm sao lưu mà là lập phạm vi dữ liệu cần bảo vệ. Nếu mọi dữ liệu được coi là quan trọng như nhau, tổ chức khó xác định thứ tự phục hồi và thường phải dành nguồn lực cho cả những thành phần có thể tạo lại dễ dàng.

Nên lập danh mục ít nhất cho các nhóm dữ liệu trực tiếp ảnh hưởng đến khả năng tiếp tục nghiên cứu:

·         Dữ liệu gốc thu nhận từ thí nghiệm, khảo sát, thiết bị hoặc nguồn bên ngoài

·         Dữ liệu đã làm sạch hoặc biến đổi mà việc tái tạo tốn đáng kể thời gian hoặc tài nguyên tính toán

·         Metadata, data dictionary và tài liệu mô tả cấu trúc dữ liệu

·         Mã nguồn, script, notebook và workflow phân tích

·         Cấu hình, tham số và phiên bản môi trường cần để chạy lại quy trình

·         Tài liệu ghi nhận phương pháp, quyết định xử lý và lịch sử phiên bản

·         Khóa, thông tin cấu hình hoặc thành phần cần thiết để truy cập dữ liệu đã mã hóa

Với từng nhóm, cần đánh giá hai yếu tố: mức độ khó tái tạo và hậu quả nếu mất. Dữ liệu thí nghiệm độc nhất, chẳng hạn, thường phải được ưu tiên cao hơn một tệp trung gian có thể sinh lại từ dữ liệu nguồn và mã xử lý còn nguyên vẹn.

Cũng cần xác định các kịch bản gây mất dữ liệu. Xóa nhầm tệp, hỏng thiết bị lưu trữ, lỗi đồng bộ, ransomware, hỏng cơ sở dữ liệu và mất toàn bộ hạ tầng không tạo ra cùng một yêu cầu phục hồi. Một bản sao nằm trên cùng hệ thống có thể hữu ích khi người dùng xóa nhầm nhưng không bảo vệ được dữ liệu nếu toàn bộ hệ thống bị mã hóa hoặc phá hủy.

Đặt RPO và RTO thay vì chỉ yêu cầu “khôi phục nhanh”

Kế hoạch nên chuyển yêu cầu phục hồi thành các mục tiêu có thể kiểm tra. Hai thông số thường được sử dụng trong lập kế hoạch dự phòng hệ thống là Recovery Point Objective (RPO) và Recovery Time Objective (RTO).

RPO thể hiện lượng dữ liệu tối đa có thể mất tính theo thời gian. Nếu RPO của một hệ thống là 4 giờ, cơ chế bảo vệ dữ liệu phải đủ để khi xảy ra sự cố, điểm phục hồi hợp lệ không cách thời điểm sự cố quá 4 giờ.

RTO thể hiện khoảng thời gian mục tiêu để đưa dữ liệu hoặc dịch vụ cần thiết trở lại trạng thái sử dụng được. RTO 8 giờ không có nghĩa chỉ cần bắt đầu phục hồi trong 8 giờ; mục tiêu là đạt trạng thái phục vụ đã được định nghĩa trong khoảng thời gian đó.

Không tồn tại một giá trị RPO hoặc RTO phù hợp cho mọi nghiên cứu. Chúng phải được xác định dựa trên tốc độ phát sinh dữ liệu, khả năng tái tạo, chi phí gián đoạn và mức độ quan trọng của từng loại dữ liệu.

Ví dụ, một thiết bị tạo dữ liệu liên tục có thể yêu cầu RPO ngắn hơn kho tài liệu dự án chỉ thay đổi vài lần mỗi tuần. Ngược lại, một kho dữ liệu nhiều terabyte có thể khiến RTO rất ngắn trở nên không khả thi nếu băng thông phục hồi không đủ.

Đây cũng là lý do cần phân biệt RTO kỳ vọng với năng lực phục hồi thực tế. Nếu phải phục hồi 10 TB dữ liệu qua đường truyền thực tế 500 Mbps, riêng quá trình truyền dữ liệu trong điều kiện lý tưởng đã cần khoảng 44 giờ. Một RTO 4 giờ khi đó sẽ không khả thi nếu không thay đổi kiến trúc, vị trí bản sao hoặc thứ tự dữ liệu cần phục hồi.

Thiết kế sao lưu để một sự cố không phá hủy mọi bản sao

Sau khi biết phải bảo vệ gì và cần phục hồi đến mức nào, mới có thể thiết kế kiến trúc sao lưu phù hợp.

Nguyên tắc 3-2-1 thường được dùng như một điểm khởi đầu thực tế: duy trì ba bản dữ liệu, trên ít nhất hai loại hoặc vị trí lưu trữ khác nhau, trong đó có một bản tách khỏi hệ thống chính. Ý nghĩa quan trọng không nằm ở việc đạt đúng một con số máy móc mà ở việc loại bỏ điểm lỗi chung.

Nếu dữ liệu chính và mọi bản sao đều sử dụng cùng tài khoản quản trị, cùng storage hoặc cùng miền bảo mật, ransomware hay lỗi cấu hình có thể ảnh hưởng đồng thời đến tất cả chúng. Vì vậy, với dữ liệu khó tái tạo, nên cân nhắc bản sao ngoại tuyến, immutable storage hoặc cơ chế hạn chế sửa và xóa bản sao lưu.

Versioning cũng có vai trò khác với replication. Đồng bộ dữ liệu sang hệ thống thứ hai có thể tạo tính sẵn sàng, nhưng nếu tệp bị xóa hoặc sửa sai rồi thay đổi đó được đồng bộ ngay sang bản còn lại, replication không cung cấp điểm phục hồi lịch sử. Kế hoạch phải quy định rõ thời gian giữ phiên bản và khả năng quay về một trạng thái trước sự cố.

Với dữ liệu nhạy cảm, bản sao lưu cũng cần áp dụng các yêu cầu bảo mật tương ứng với dữ liệu gốc. Mã hóa bản sao nhưng làm mất khóa giải mã sẽ khiến bản sao về mặt kỹ thuật vẫn tồn tại nhưng không thể phục hồi. Do đó, quản lý khóa và thông tin xác thực phải nằm trong kế hoạch phục hồi chứ không được xem là một vấn đề hoàn toàn tách biệt.

Xây dựng quy trình phục hồi đủ chi tiết để người khác thực hiện được

Kế hoạch khôi phục không nên phụ thuộc vào trí nhớ của một cá nhân. Trong tình huống thực tế, người hiểu hệ thống nhất có thể không có mặt, tài khoản thông thường có thể bị vô hiệu hóa hoặc hạ tầng ban đầu có thể không còn hoạt động.

Runbook phục hồi cần chỉ rõ trình tự thực hiện. Tùy hệ thống, quy trình có thể bao gồm:

1.    Xác nhận phạm vi và nguyên nhân sự cố

2.    Cô lập thành phần bị ảnh hưởng để tránh làm hỏng bản sao phục hồi

3.    Chọn điểm phục hồi phù hợp với RPO

4.    Xác định bản sao lưu sạch và có thể truy cập

5.    Chuẩn bị môi trường hoặc storage đích

6.    Khôi phục dữ liệu theo thứ tự ưu tiên

7.    Kiểm tra tính toàn vẹn và khả năng đọc dữ liệu

8.    Kiểm tra ứng dụng, mã phân tích hoặc workflow phụ thuộc

9.    Cho phép người dùng quay lại hệ thống sau khi xác nhận trạng thái

10.  Ghi lại dữ liệu đã mất, thời gian phục hồi và các sai lệch so với kế hoạch

Mỗi bước quan trọng cần có người hoặc vai trò chịu trách nhiệm. Tối thiểu nên xác định người có quyền tuyên bố sự cố, người truy cập được hệ thống sao lưu, người thực hiện restore và người có thẩm quyền xác nhận dữ liệu nghiên cứu sau phục hồi là chấp nhận được.

Các thông tin cần thiết cho phục hồi cũng phải được lưu ở nơi có thể truy cập khi hệ thống chính ngừng hoạt động. Một runbook chỉ tồn tại trên máy chủ đang gặp sự cố có rất ít giá trị trong chính tình huống mà nó được thiết kế để giải quyết.

Kiểm tra tính toàn vẹn thay vì mặc định bản sao lưu là hợp lệ

Một quá trình backup báo “thành công” chưa chứng minh rằng dữ liệu có thể phục hồi hoàn chỉnh. Tệp có thể đã hỏng trước khi được sao lưu, bản sao có thể thiếu thành phần phụ thuộc hoặc quá trình restore có thể gặp lỗi mà công việc sao lưu thông thường không phát hiện.

Vì vậy, kế hoạch cần có ít nhất hai tầng xác minh.

Tầng thứ nhất là kiểm tra bản sao lưu. Có thể sử dụng checksum hoặc hash để phát hiện thay đổi ngoài dự kiến đối với tệp, đồng thời theo dõi log, dung lượng, số lượng đối tượng và trạng thái job để phát hiện backup thiếu hoặc thất bại.

Tầng thứ hai quan trọng hơn là thử phục hồi thực tế. Một mẫu dữ liệu hoặc toàn bộ hệ thống cần được restore sang môi trường kiểm thử, sau đó kiểm tra xem:

·         Tệp có mở và đọc được hay không

·         Cấu trúc thư mục và quyền truy cập có đúng hay không

·         Metadata có còn gắn với dữ liệu hay không

·         Mã hoặc workflow có tìm thấy đúng đầu vào hay không

·         Dữ liệu sau restore có vượt qua kiểm tra toàn vẹn hay không

·         Thời gian phục hồi thực tế có đáp ứng RTO đã đặt ra hay không

Tần suất kiểm thử không nên được chọn tùy ý. Dữ liệu càng thay đổi nhanh, càng khó tái tạo hoặc hệ thống càng thường xuyên thay đổi cấu hình thì nhu cầu thử phục hồi càng cao. Sau thay đổi lớn về storage, phần mềm backup, phương thức mã hóa hoặc kiến trúc hệ thống cũng cần xem xét kiểm thử lại.

Các hướng dẫn về contingency planning như NIST SP 800-34 nhấn mạnh việc lập kế hoạch, xác định chiến lược phục hồi, kiểm thử và duy trì kế hoạch. Ý nghĩa thực tế là kế hoạch khôi phục không hoàn thành khi tài liệu được viết xong; nó chỉ đáng tin khi năng lực phục hồi đã được kiểm chứng.

Chuẩn bị cho đặc thù của dữ liệu nghiên cứu

Dữ liệu nghiên cứu có một yêu cầu mà kế hoạch phục hồi CNTT thông thường dễ bỏ sót: khôi phục byte dữ liệu chưa chắc đã khôi phục được khả năng hiểu và tái sử dụng dữ liệu.

Giả sử một tập dữ liệu CSV được phục hồi nguyên vẹn nhưng mất data dictionary mô tả ý nghĩa các cột, mất mã nguồn thực hiện bước làm sạch và mất thông tin về phiên bản dữ liệu đầu vào. Tệp vẫn tồn tại, nhưng nhóm nghiên cứu có thể không tái tạo được kết quả trước sự cố.

Vì vậy, đơn vị phục hồi nên được nhìn như một “gói nghiên cứu” gồm dữ liệu và các thành phần phụ thuộc cần thiết. Với một quy trình phân tích, gói đó có thể gồm dữ liệu đầu vào, mã nguồn, tệp cấu hình, metadata, thông tin phiên bản và tài liệu mô tả môi trường.

Một hiểu nhầm phổ biến khác là tất cả dữ liệu đều cần được phục hồi đồng thời. Trong thực tế, phân tầng phục hồi thường hiệu quả hơn. Dữ liệu đang phục vụ thí nghiệm hoặc phân tích đang diễn ra có thể được ưu tiên trước kho lưu trữ lịch sử. Cách tiếp cận này giúp nguồn lực phục hồi tập trung vào những thành phần quyết định khả năng tiếp tục hoạt động.

Biến kế hoạch thành quy trình có thể duy trì

Kế hoạch khôi phục cần được xem là một thành phần sống của hạ tầng nghiên cứu. Mỗi thay đổi về nơi lưu dữ liệu, quyền truy cập, thiết bị thu nhận, định dạng tệp, phần mềm phân tích hoặc nhân sự chịu trách nhiệm đều có thể khiến một phần của kế hoạch cũ không còn đúng.

Một cơ chế vận hành tối thiểu nên theo dõi các chỉ số có thể kiểm tra thay vì chỉ ghi nhận rằng “đã có backup”:

·         Tỷ lệ công việc sao lưu hoàn thành đúng lịch

·         Tuổi của điểm phục hồi hợp lệ gần nhất

·         Số lần kiểm thử restore thành công

·         Thời gian restore thực tế so với RTO

·         Mức dữ liệu mất thực tế so với RPO trong các lần diễn tập hoặc sự cố

·         Số thành phần quan trọng chưa có bản sao độc lập

·         Các thay đổi hệ thống chưa được phản ánh vào runbook

Khi một lần diễn tập cho thấy thời gian khôi phục dài hơn mục tiêu, giải pháp không phải sửa số liệu báo cáo. Cần thay đổi kiến trúc, tăng tốc độ truy xuất bản sao, phân tầng dữ liệu hoặc điều chỉnh RTO về mức thực tế có thể đạt được.

Kế hoạch cũng nên được xem xét sau mỗi sự cố. Thời điểm đó cung cấp bằng chứng thực tế về điểm nào hoạt động, điểm nào phụ thuộc quá nhiều vào một cá nhân và bước nào trong runbook chưa đủ rõ.

Một kế hoạch khôi phục dữ liệu nghiên cứu đáng tin cậy phải nối được sáu yếu tố thành một chuỗi: xác định dữ liệu quan trọng, đặt RPO/RTO, tạo các bản sao độc lập, xây dựng runbook phục hồi, kiểm chứng tính toàn vẹn và thử restore định kỳ. Với dữ liệu nghiên cứu, cần bảo vệ cả metadata, mã phân tích và các thành phần tạo nên khả năng tái lập, không chỉ các tệp dữ liệu cuối cùng.

Tiêu chí cuối cùng không phải “đã có bản sao lưu”, mà là nhóm nghiên cứu có thể khôi phục đúng dữ liệu, đúng trạng thái, trong giới hạn mất mát và thời gian đã chấp nhận, rồi chứng minh dữ liệu sau phục hồi vẫn sử dụng được.