Một tác vụ sao lưu báo thành công chỉ xác nhận dữ liệu đã được ghi ở đâu đó. Nó không chứng minh tệp có thể đọc, ứng dụng có thể chạy, quyền truy cập còn đúng hoặc doanh nghiệp có thể phục hồi trong thời gian cho phép. Vì vậy, kiểm tra khôi phục phải là một phần của quy trình sao lưu, không phải một việc chỉ thực hiện sau khi sự cố đã xảy ra.

1. Vì sao trạng thái “sao lưu thành công” chưa đủ

Tác vụ có thể hoàn tất nhưng vẫn chứa tệp hỏng, thiếu cơ sở dữ liệu, không có khóa giải mã hoặc không lưu đúng phiên bản cần thiết. Bản sao cũng có thể nằm chung tài khoản, chung thiết bị hoặc chung vị trí với hệ thống chính, khiến một sự cố có thể ảnh hưởng đồng thời cả dữ liệu gốc và dữ liệu sao lưu.

Ngoài dữ liệu, doanh nghiệp còn phải phục hồi cấu hình, quyền truy cập, phụ thuộc ứng dụng và thứ tự khởi động. Khôi phục một thư mục khác hoàn toàn với việc đưa hệ thống kế toán, ERP hoặc máy chủ tệp trở lại trạng thái người dùng có thể làm việc.

  • Tệp có thể đọc nhưng ứng dụng không khởi động vì thiếu cấu hình hoặc cơ sở dữ liệu
  • Bản sao bị mã hóa, hết thời gian lưu hoặc không chứa đúng thời điểm cần phục hồi
  • Tài khoản khôi phục không còn hoạt động hoặc chỉ một người biết thông tin truy cập
  • Đường truyền và dung lượng phục hồi thực tế chậm hơn nhiều so với dự kiến

2. Đặt RPO và RTO theo tác động kinh doanh

RPO là lượng dữ liệu tối đa doanh nghiệp có thể chấp nhận mất, được tính theo thời gian. Nếu RPO là bốn giờ, hệ thống cần tạo bản sao đủ thường xuyên để khi phục hồi không mất quá bốn giờ dữ liệu. RTO là thời gian tối đa để dịch vụ hoạt động trở lại sau gián đoạn.

Hai mục tiêu này phải do nghiệp vụ và lãnh đạo cùng xác nhận. Email có thể chấp nhận khôi phục trong vài giờ, nhưng hệ thống bán hàng hoặc dữ liệu giao dịch có thể cần nhanh hơn. Mục tiêu càng ngắn thì chi phí hạ tầng, lưu trữ và vận hành càng cao, nên không nên áp cùng một mức cho mọi dữ liệu.

  • Dịch vụ nào gây thiệt hại lớn nhất nếu dừng trong một giờ?
  • Mất bao nhiêu phút hoặc giờ dữ liệu là mức tối đa có thể chấp nhận?
  • Sau khôi phục, ai xác nhận dữ liệu đầy đủ và hoạt động kinh doanh bình thường?
  • Mục tiêu nào cần dự phòng nóng và mục tiêu nào có thể phục hồi theo thứ tự?
Minh họa chibi đại diện nghiệp vụ và đội IT thống nhất mục tiêu mất dữ liệu và thời gian khôi phục
RPO và RTO chỉ có ý nghĩa khi được gắn với dịch vụ, tác động và người xác nhận kết quả phục hồi.

3. Thiết kế nhiều lớp bản sao tách biệt

Nguyên tắc 3‑2‑1 là một điểm khởi đầu dễ áp dụng: có ít nhất ba bản dữ liệu, trên hai loại phương tiện và một bản ở vị trí khác. Với rủi ro hiện nay, doanh nghiệp nên bổ sung một bản ngoại tuyến hoặc bất biến và mục tiêu không có lỗi sau khi kiểm tra, thường được gọi ngắn gọn là 3‑2‑1‑1‑0.

Không phải mọi bản sao đều cần cùng công nghệ. Có thể kết hợp snapshot để phục hồi nhanh, bản sao trên thiết bị riêng, lưu trữ cloud và bản bất biến. Điều quan trọng là một tài khoản quản trị hoặc một sự cố không thể xóa, sửa hoặc mã hóa tất cả các bản cùng lúc.

  • Ba bản dữ liệu gồm dữ liệu sản xuất và ít nhất hai bản sao
  • Hai loại phương tiện hoặc nền tảng lưu trữ khác nhau
  • Một bản ở vị trí tách biệt với hệ thống chính
  • Một bản ngoại tuyến hoặc bất biến và không có lỗi sau kiểm tra

4. Bảo vệ chính hệ thống sao lưu

Hệ thống sao lưu chứa gần như toàn bộ dữ liệu quan trọng nên phải được xem là tài sản nhạy cảm. Tài khoản quản trị sao lưu cần tách khỏi tài khoản quản trị thông thường, bật xác thực nhiều lớp nếu hỗ trợ và chỉ cho phép truy cập từ thiết bị hoặc vùng mạng quản trị.

Doanh nghiệp cũng cần theo dõi các hành động bất thường như xóa hàng loạt bản sao, thay đổi thời gian lưu, tắt tác vụ hoặc tạo tài khoản quản trị mới. Cấu hình, khóa mã hóa, thông tin bản quyền và hướng dẫn phục hồi của chính hệ thống sao lưu cũng phải có bản dự phòng.

  • Tách tài khoản, quyền và vùng mạng quản trị sao lưu
  • Không dùng cùng mật khẩu hoặc cùng tài khoản với hệ thống sản xuất
  • Cảnh báo khi tác vụ lỗi, chính sách thay đổi hoặc bản sao bị xóa
  • Lưu an toàn khóa mã hóa, cấu hình và hướng dẫn khôi phục

5. Kiểm thử khôi phục theo nhiều cấp độ

Bài kiểm tra không nhất thiết phải dừng toàn bộ hệ thống. Hằng tháng có thể chọn ngẫu nhiên một số tệp, thư mục hoặc máy ảo để phục hồi vào môi trường tách biệt. Hằng quý nên kiểm tra một ứng dụng hoàn chỉnh, bao gồm dữ liệu, cấu hình, quyền và kết nối. Định kỳ hằng năm hoặc sau thay đổi lớn, doanh nghiệp nên diễn tập kịch bản phục hồi theo thứ tự dịch vụ.

Mỗi lần thử cần đo thời gian từ lúc quyết định khôi phục đến khi người dùng xác nhận có thể làm việc. Nếu chỉ đo thời gian tải dữ liệu mà bỏ qua cài đặt, cấu hình, kiểm tra và bàn giao, RTO thực tế sẽ bị đánh giá quá lạc quan.

  • Hằng tháng: khôi phục mẫu tệp, thư mục, hộp thư hoặc máy ảo
  • Hằng quý: phục hồi một ứng dụng và để người dùng nghiệp vụ kiểm tra
  • Hằng năm: diễn tập thứ tự phục hồi nhiều dịch vụ và kênh phối hợp
  • Sau thay đổi lớn: thử lại khi nâng cấp ứng dụng, lưu trữ hoặc kiến trúc
Minh họa chibi đội IT phục hồi ứng dụng trong môi trường tách biệt và người dùng kiểm tra kết quả
Khôi phục thành công cần được xác nhận ở cả ba lớp: dữ liệu đọc được, ứng dụng hoạt động và người dùng làm việc bình thường.

6. Ghi biên bản và phân rõ vai trò

Một biên bản ngắn nên ghi phạm vi dữ liệu, phiên bản bản sao, người thực hiện, thời gian bắt đầu, thời gian hoàn tất, lỗi phát hiện và người xác nhận. Qua vài kỳ, doanh nghiệp sẽ thấy xu hướng: dịch vụ nào phục hồi chậm, bước nào phụ thuộc một cá nhân và tài liệu nào đã lỗi thời.

Kế hoạch cũng cần chỉ rõ ai có quyền tuyên bố tình huống phục hồi, ai liên hệ nhà cung cấp, ai thực hiện kỹ thuật và ai xác nhận nghiệp vụ. Nếu toàn bộ thông tin chỉ nằm trong trí nhớ của một quản trị viên, chính quy trình khôi phục đang có một điểm lỗi đơn lẻ.

  • Dữ liệu và thời điểm đã chọn để phục hồi
  • Thời gian chuẩn bị, truyền dữ liệu, cấu hình và xác nhận
  • Lỗi, phụ thuộc hoặc thiếu tài liệu được phát hiện
  • Hành động khắc phục, người phụ trách và ngày hoàn tất

7. Lộ trình 30 ngày để chứng minh khả năng phục hồi

Tuần đầu, chọn ba dịch vụ quan trọng và thống nhất RPO/RTO. Tuần hai, rà vị trí bản sao, tài khoản quản trị, thời gian lưu và mức tách biệt. Tuần ba, phục hồi thử một bộ dữ liệu hoặc ứng dụng vào môi trường an toàn. Tuần cuối, sửa lỗi phát hiện, hoàn thiện biên bản và lập lịch kiểm tra định kỳ.

Kết quả tốt nhất của tháng đầu không phải là một báo cáo toàn màu xanh, mà là danh sách khoảng trống đã được nhìn thấy trước khi xảy ra sự cố thật. Mỗi lần thử giúp kế hoạch gần với khả năng vận hành hơn, giảm phụ thuộc vào giả định và tạo căn cứ rõ ràng cho các khoản đầu tư tiếp theo.

  • Tuần 1: chọn dịch vụ, người sở hữu và mục tiêu phục hồi
  • Tuần 2: kiểm tra bản sao, quyền, tách biệt và thời gian lưu
  • Tuần 3: thực hiện một bài khôi phục có đo thời gian
  • Tuần 4: khắc phục khoảng trống và chốt lịch kiểm thử
✓

Gợi ý từ Arbolume: Hãy bắt đầu bằng khảo sát hiện trạng và mức độ ưu tiên. Một cấu hình vừa vặn thường hiệu quả hơn một giải pháp lớn nhưng khó vận hành.

Chia sẻ chủ đề

#Arbolume #Backup #KhoiPhucDuLieu #BusinessContinuity