Sao lưu dữ liệu backup là gì? 3-2-1 và kiểm thử phục hồi

Sao lưu dữ liệu backup là bản sao dữ liệu được tạo và lưu ở nơi khác để phục hồi khi bản gốc mất hoặc hỏng. Quy tắc 3-2-1 và một lần kiểm thử phục hồi có bằng chứng quan trọng hơn số lượng bản sao, vì bản sao chưa từng được phục hồi là giả định.

Tóm tắt nhanh

• Sao lưu là quy trình tạo bản sao có thể phục hồi được, không phải việc chép tệp sang ổ khác.
• RPO quyết định mất bao nhiêu dữ liệu, RTO quyết định mất bao nhiêu thời gian. Hai con số này thiết kế hệ thống, không phải trang trí hợp đồng.
• Quy tắc 3-2-1 là mức tối thiểu: ba bản, hai loại phương tiện, một bản ngoài site.
• Kiểm thử phục hồi phải sinh ra bằng chứng đo được: thời gian phục hồi thực tế, số bản ghi đối chiếu, và người xác nhận.
• Phần lớn kế hoạch sao lưu thất bại vì không ai thử phục hồi, không phải vì thiếu bản sao.

Sao lưu khác gì với bản sao, nhân bản và lưu trữ

Bốn khái niệm này thường bị dùng lẫn, và việc dùng lẫn dẫn đến những kế hoạch trông đầy đủ nhưng thiếu đúng phần cần thiết.

Điểm phân biệt quan trọng nhất là khả năng phục hồi sau khi dữ liệu bị sửa sai. Nhân bản và bản sao làm việc đều sao chép cả lỗi logic, nên chúng không cứu được trước một lệnh xoá sai hoặc một đoạn mã ghi nhầm. Chỉ bản sao lưu được giữ ở trạng thái bất biến mới làm được việc đó.

Vì vậy một hệ thống có nhân bản ba vùng vẫn có thể mất toàn bộ dữ liệu trong vài giây nếu một lệnh xoá được nhân bản kịp thời. Đây là lý do các sự cố mất dữ liệu lớn thường xảy ra ở hệ thống có hạ tầng tốt: hạ tầng tốt khuếch đại cả thao tác đúng lẫn thao tác sai.

Quy tắc 3-2-1 và biến thể 3-2-1-1-0

Quy tắc 3-2-1 nói rằng nên có ba bản dữ liệu, trên hai loại phương tiện khác nhau, với một bản ở ngoài site chính. Mỗi con số xử lý một loại rủi ro riêng.

Ba bản xử lý rủi ro hỏng một bản. Hai loại phương tiện xử lý rủi ro hỏng cả một lớp phương tiện, ví dụ toàn bộ ổ đĩa cùng một lô sản xuất hoặc cùng một lỗi firmware. Một bản ngoài site xử lý rủi ro mất cả phòng máy: cháy, ngập, mất điện dài, hoặc một sự cố vật lý khác.

Biến thể 3-2-1-1-0 thêm hai điều kiện. Số 1 thứ tư là một bản ngoại tuyến hoặc bất biến, tức là bản không thể bị sửa hoặc xoá bởi tài khoản đang chạy hệ thống. Số 0 là không có lỗi khi kiểm thử phục hồi, nghĩa là mỗi lần kiểm thử phải đạt kết quả đối chiếu, không được phép "gần đúng".

Bản bất biến là phần hay bị bỏ nhất và cũng là phần chống được nhóm tấn công phổ biến nhất hiện nay: kẻ tấn công vào được hệ thống sẽ tìm cách xoá bản sao lưu trước khi mã hoá dữ liệu. Nếu bản sao nằm trên cùng hệ thống với cùng tài khoản quản trị, nó sẽ bị xoá cùng.

Với doanh nghiệp nhỏ, 3-2-1 có thể hiểu đơn giản hơn: một bản trên máy chủ, một bản trên thiết bị lưu trữ tại văn phòng, một bản ở dịch vụ lưu trữ ngoài. Ba nơi, hai loại phương tiện, và bản ngoài phải được kiểm tra độc lập với hệ thống chính.

RPO và RTO: hai con số quyết định thiết kế

RPO là lượng dữ liệu tối đa có thể mất, tính bằng thời gian. RTO là thời gian tối đa để đưa hệ thống trở lại hoạt động. Hai con số này không phải mục tiêu cảm tính; chúng quyết định tần suất sao lưu, loại phương tiện và mức độ tự động hoá của quy trình phục hồi.

Con số trong bảng là phép nhân đơn giản từ tần suất và lưu lượng giả định, dùng để so sánh lựa chọn chứ không phải dự báo cho một hệ thống cụ thể. Việc cần làm là thay lưu lượng giả định bằng lưu lượng thật của bạn rồi lặp lại phép tính.

RTO thì phụ thuộc vào ba yếu tố: thời gian phát hiện, thời gian quyết định phục hồi, và thời gian thực thi phục hồi. Trong đó thời gian thực thi thường bị đánh giá thấp nhất. Một bản sao 500 GB phục hồi qua đường truyền 100 Mbps mất ít nhất hơn mười một giờ chỉ để truyền xong, chưa tính thời gian giải nén và kiểm tra.

Cách kiểm tra RTO có thật hay không rất đơn giản: lấy một bản sao gần nhất, phục hồi vào môi trường tách biệt, và bấm giờ từ lúc bắt đầu đến lúc ứng dụng phục vụ được yêu cầu đầu tiên. Nếu chưa từng làm việc này, RTO trong hợp đồng là con số chưa được kiểm chứng.

Ba loại sao lưu và chu kỳ phù hợp

Ba loại sao lưu khác nhau ở lượng dữ liệu chép mỗi lần và thời gian phục hồi. Chọn sai loại là nguyên nhân phổ biến của việc "có sao lưu nhưng không phục hồi kịp".

Điểm cần hiểu là thời gian phục hồi của bản gia tăng phụ thuộc vào chuỗi. Muốn phục hồi về thứ Năm, phải có bản toàn phần Chủ Nhật và bốn bản gia tăng. Nếu một bản trong chuỗi hỏng, không thể phục hồi đến mốc đó, và đây là rủi ro thường không được tính vào RTO.

Cách bố trí thực tế cho phần lớn hệ thống vừa: một bản toàn phần mỗi tuần, bản khác biệt mỗi ngày, và nhật ký giao dịch được lưu riêng nếu cần RPO dưới một giờ. Cách này giữ thời gian phục hồi ở mức chấp nhận được mà không cần chép toàn bộ dữ liệu mỗi ngày.

Quy trình kiểm thử phục hồi sinh ra bằng chứng gì

Kiểm thử phục hồi không phải là mở tệp sao lưu ra xem có dữ liệu. Nó là một buổi diễn tập có kịch bản, có người chấm và có biên bản. Sáu bước dưới đây tạo ra bằng chứng mà người ngoài đọc được.

Bước một: chọn một mốc thời gian cụ thể, không phải "bản mới nhất". Chọn mốc có giao dịch đã biết trước, ví dụ một đơn hàng tạo lúc 14 giờ ngày hôm kia, để sau khi phục hồi có thể đối chiếu chính xác.

Bước hai: phục hồi vào môi trường tách biệt hoàn toàn với hệ thống đang chạy. Phục hồi đè lên môi trường chính là cách biến một buổi diễn tập thành một sự cố thật.

Bước ba: bấm giờ từ lúc bắt đầu. Ghi lại ba mốc: bắt đầu, dữ liệu đã sẵn sàng, và ứng dụng phục vụ được yêu cầu đầu tiên. Khoảng cách giữa mốc thứ nhất và mốc thứ ba là RTO thực tế.

Bước bốn: đối chiếu số liệu. Đếm bản ghi ở ba bảng chính, so với số đếm trên hệ thống nguồn tại đúng mốc thời gian đó. Chênh lệch phải giải thích được, không được bỏ qua.

Bước năm: kiểm tra tính toàn vẹn chức năng. Đăng nhập bằng một tài khoản thử, mở một giao dịch đã biết, và chạy một báo cáo có tổng số đã tính trước. Bước này phát hiện lỗi mà phép đếm bản ghi không thấy, ví dụ khoá ngoại bị mất hoặc chỉ mục hỏng.

Bước sáu: ghi biên bản. Biên bản cần có người thực hiện, thời điểm, mốc phục hồi, RTO đo được, kết quả đối chiếu và các vấn đề phát hiện. Đây là tài liệu duy nhất chứng minh kế hoạch sao lưu hoạt động.

Tần suất hợp lý là mỗi quý một lần cho hệ thống ổn định và mỗi tháng một lần cho hệ thống đang thay đổi nhiều. Sau mỗi lần thay đổi hạ tầng hoặc nâng cấp phiên bản lớn, nên chạy thêm một lần không theo lịch.

Bảy chế độ hỏng thường gặp của một kế hoạch sao lưu

Phần lớn kế hoạch sao lưu không hỏng vì thiếu công cụ mà vì một trong bảy chế độ dưới đây. Bảng liệt kê triệu chứng và cách xử lý.

Chế độ thứ bảy đáng nhấn mạnh vì nó thường bị bỏ qua trong các buổi diễn tập. Dữ liệu phục hồi được nhưng hệ thống không chạy được vì thiếu cấu hình, thiếu khoá mã hoá hoặc thiếu tài liệu về thứ tự khởi động. Cần sao lưu cả phần "cách dựng lại", không chỉ phần "nội dung".

Chi phí: cấu trúc chứ không phải con số

Chi phí sao lưu có bốn thành phần. Thành phần thứ nhất là dung lượng lưu trữ, phụ thuộc khối lượng dữ liệu, tần suất và thời gian giữ. Thành phần thứ hai là băng thông, phụ thuộc khối lượng chép mỗi lần và khoảng cách giữa các lần.

Thành phần thứ ba là thời gian vận hành: cấu hình, theo dõi, xử lý lỗi và chạy diễn tập. Đây là phần dễ bị bỏ khỏi dự toán nhất, dù nó là phần quyết định kế hoạch có sống được hay không.

Thành phần thứ tư là chi phí của việc mất dữ liệu, gồm doanh thu mất, chi phí khôi phục thủ công và chi phí uy tín. Thành phần này không xuất hiện trên hoá đơn, nhưng nó là lý do tồn tại của ba thành phần kia. Cách cân nhắc hợp lý là so chi phí ba thành phần đầu với chi phí thành phần thứ tư ở mức RPO và RTO đang chọn.

Với doanh nghiệp nhỏ, một cách tiếp cận thực tế là chọn RPO theo chu kỳ nghiệp vụ: nếu mỗi ngày chốt một lần và có thể nhập lại dữ liệu của một ngày, RPO 24 giờ là đủ. Nếu không thể nhập lại, RPO phải ngắn hơn nhiều, và chi phí tăng tương ứng.

Mẫu checklist một trang để tự kiểm tra

Sáu câu hỏi dưới đây đủ để phát hiện phần lớn lỗ hổng. Trả lời bằng tài liệu, không trả lời bằng trí nhớ.

1. Bản sao gần nhất được tạo lúc nào, và ai đã kiểm tra nó có dữ liệu?
2. Có bao nhiêu bản, trên bao nhiêu loại phương tiện, và bản nào ở ngoài site chính?
3. Bản nào không thể bị sửa hoặc xoá bởi tài khoản đang chạy hệ thống?
4. Lần kiểm thử phục hồi gần nhất là khi nào, mất bao lâu, và biên bản ở đâu?
5. Nếu phải phục hồi ngay bây giờ, ai là người làm và ai là người xác nhận?
6. Dữ liệu cấu hình và khoá mã hoá có nằm trong bản sao không?

Nếu câu bốn không có câu trả lời bằng văn bản, kế hoạch sao lưu đang ở trạng thái chưa được kiểm chứng. Đó là trạng thái phổ biến, và cũng là trạng thái dễ sửa nhất: chạy một buổi diễn tập, ghi biên bản, và đưa nó vào lịch.

Câu hỏi thường gặp

Sao lưu dữ liệu backup khác gì với lưu trữ trên cloud?

Lưu trữ trên cloud là nơi chứa dữ liệu; sao lưu là quy trình tạo bản sao có thể phục hồi. Có thể sao lưu lên cloud, nhưng cloud tự nó không phải sao lưu. Một thư mục đồng bộ cloud sẽ đồng bộ luôn thao tác xoá, nên nó không bảo vệ được trước lỗi logic.

Bao lâu phải kiểm thử phục hồi một lần?

Mỗi quý cho hệ thống ổn định, mỗi tháng cho hệ thống thay đổi nhiều, và bổ sung một lần sau mỗi thay đổi hạ tầng lớn. Tần suất quan trọng ít hơn việc có biên bản: một lần mỗi quý có biên bản tốt hơn mỗi tháng chạy mà không ghi lại gì.

Có cần sao lưu cả mã nguồn và cấu hình không?

Có. Dữ liệu phục hồi được nhưng hệ thống không dựng lại được là tình huống phổ biến trong các buổi diễn tập. Cần sao lưu mã nguồn, tệp cấu hình, khoá mã hoá và tài liệu về thứ tự triển khai.

RPO 24 giờ có đủ cho doanh nghiệp nhỏ không?

Đủ nếu bạn có thể nhập lại dữ liệu của một ngày mà không mất doanh thu hoặc sai lệch sổ sách. Không đủ nếu dữ liệu phát sinh liên tục và không thể tái tạo, ví dụ đơn hàng trực tuyến hoặc giao dịch thanh toán. Trong trường hợp đó, RPO phải ngắn hơn nhiều.

Bản sao lưu có cần mã hoá không?

Có, đặc biệt khi bản sao nằm ngoài site hoặc trên phương tiện di động. Mã hoá bảo vệ dữ liệu khi phương tiện bị mất hoặc bị truy cập trái phép, nhưng khoá phải được lưu riêng và cũng phải có trong kế hoạch phục hồi, nếu không bản sao trở thành vô dụng.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo thông lệ sao lưu và phục hồi sau sự cố. Các phép tính trong bài dùng lưu lượng giả định để minh hoạ cách tính RPO và RTO, không phải số liệu đo từ một hệ thống cụ thể.

Nếu bạn cần một hệ thống được thiết kế sẵn cho việc sao lưu và phục hồi có kiểm chứng, WinSell nhận vận hành sau bàn giao theo phạm vi đã chốt. Báo giá sau khi chốt phạm vi.

Bài viết liên quan: tại sao cần sao lưu dữ liệu định kỳ, vì sao cần giám sát liên tục hệ thống AI, bảo trì phần mềm là gì và kiến trúc phần mềm là gì.