Sao lưu 3-2-1 cho người làm một mình: giữ dữ liệu website, ghi chú và file khách an toàn

Sao lưu 3-2-1 cho người làm một mình: giữ dữ liệu website, ghi chú và file khách an toàn
13 Tháng 11, 2026

Cập nhật:

9 phút đọcHướng dẫn

Sao lưu 3-2-1 là gì? Quy tắc sao lưu 3-2-1 yêu cầu giữ ba bản dữ liệu, trên hai loại phương tiện lưu trữ khác nhau, trong đó một bản nằm ở nơi khác (offsite). Theo các nguồn thứ cấp tôi tìm thấy ngày 25/10/2026, quy tắc này bắt nguồn từ nhiếp ảnh gia Peter Krogh trong sách The DAM Book (2005); nhiều bài còn nói CISA khuyến nghị, nhưng tôi chưa đọc được trang CISA nên không khẳng định. Bài này giải thích sao lưu 3-2-1 cho người làm một mình, các loại dữ liệu cần giữ, cách áp dụng thực tế, kiểm thử khôi phục và kinh nghiệm của OPCAIOS.

Sơ đồ sao lưu 3-2-1: ba bản dữ liệu, hai loại phương tiện, một bản ngoài địa điểm, mã hoá bản rời máy và thử khôi phục định kỳ
Sao lưu chưa khôi phục thử được thì chưa phải là sao lưu. Sơ đồ: OPCAIOS.

Sao lưu 3-2-1 là gì?

Quy tắc 3-2-1 nghĩa là: 3 bản dữ liệu (bản đang dùng cộng 2 bản sao), 2 loại phương tiện khác nhau (ví dụ ổ đĩa máy và đám mây), 1 bản ở nơi khác để một sự cố tại chỗ không xoá sạch tất cả. Mục tiêu là không có một điểm hỏng duy nhất.

Các nguồn thứ cấp cũng lưu ý quy tắc ra đời trước thời ransomware và đám mây, nên có biến thể mở rộng như 3-2-1-1-0: thêm một bản bất biến hoặc ngoại tuyến và xác minh không lỗi khi khôi phục. Đây là mô tả từ các bài tổng hợp, không phải tiêu chuẩn tôi đã đọc ở nguồn gốc.

Người làm một mình cần sao lưu những gì?

Cần sao lưu thứ mà mất đi bạn không dựng lại được: cơ sở dữ liệu website, file khách hàng, mã nguồn, ghi chú tri thức, cấu hình máy chủ và khoá giải mã. Thứ tải lại được từ Internet thì ưu tiên thấp.

Nhóm dữ liệu Ví dụ Mức ưu tiên
Cơ sở dữ liệu Bài viết, đơn hàng, khách hàng Rất cao
File khách và dự án Hợp đồng, bản thiết kế, file bàn giao Rất cao
Mã nguồn Repo website (đã có bản trên Git) Cao
Ghi chú, tri thức Vault Obsidian (Second Brain) Cao
Cấu hình máy chủ nginx, crontab, biến môi trường Cao: thiếu là dựng lại lâu
Khoá giải mã, mật khẩu sao lưu Passphrase mã hoá bản sao lưu Rất cao: mất là bản sao lưu vô dụng
Thứ tải lại được Bộ cài, cache Thấp

Áp dụng 3-2-1 trong thực tế

Một thiết kế gọn cho người làm một mình: bản 1 là dữ liệu đang chạy; bản 2 là bản sao tự động hằng ngày trên cùng máy chủ (giữ vài tuần); bản 3 là bản mã hoá gửi sang kho đám mây khác nhà cung cấp. Hai phương tiện khác nhau là ổ máy chủ và kho đám mây.

  1. Tự động hằng ngày bằng cron hoặc lịch của hệ điều hành; sao lưu thủ công sẽ bị quên.
  2. Xuất cơ sở dữ liệu bằng công cụ chính thức (ví dụ pg_dump cho Postgres) và nén lại.
  3. Mã hoá trước khi rời máy: bản gửi ra ngoài nên mã hoá, và passphrase phải được giữ riêng ở nơi an toàn khác.
  4. Giữ nhiều phiên bản: giữ ngắn hạn ở máy, dài hạn hơn ở kho ngoài.
  5. Kiểm tra bản sao lưu có dùng được: ví dụ kiểm tra bản xuất có chứa bảng quan trọng; bản rỗng hay thiếu phải báo lỗi.
  6. Thêm cảnh báo khi tác vụ thất bại.

Với dữ liệu nằm trên VPS, đừng coi ảnh chụp (snapshot) của nhà cung cấp là bản sao lưu duy nhất vì nó thường cùng tài khoản và cùng địa điểm với máy gốc.

Thử khôi phục: bước hay bị bỏ qua

Sao lưu chỉ có giá trị khi khôi phục được. Hãy lên lịch thử khôi phục định kỳ vào một môi trường riêng, đo thời gian thực hiện và ghi lại các bước. Lần đầu bạn khôi phục không nên là lúc đang có sự cố.

  • Khôi phục vào máy hoặc cơ sở dữ liệu thử, không ghi đè bản đang chạy.
  • Kiểm tra dữ liệu thật sự mở được: đếm số bản ghi, mở một vài file mẫu.
  • Ghi lại các bước ra một tài liệu "khôi phục khẩn cấp" (SOP hoá công việc).
  • Kiểm tra bạn còn giữ passphrase để giải mã bản ngoài.

Rủi ro và lỗi thường gặp

Lỗi hay gặp nhất là sao lưu cùng chỗ với dữ liệu gốc, không mã hoá bản gửi ra ngoài và không bao giờ thử khôi phục. Lỗi nguy hiểm thứ hai là sao lưu chạy lặng lẽ thất bại nhiều tuần mà không ai biết.

  • Cùng một điểm hỏng: cả ba bản ở cùng một máy hoặc cùng một tài khoản.
  • Bản sao lưu chứa bí mật: cấu hình và biến môi trường chứa khoá, nên phải mã hoá và hạn chế quyền truy cập.
  • Mất passphrase: bản mã hoá không mở được.
  • Đồng bộ không phải sao lưu: thư mục đồng bộ đám mây sẽ đồng bộ cả file bị xoá hoặc bị mã hoá bởi mã độc.
  • Dung lượng và chi phí: giữ quá nhiều phiên bản tốn kém; đặt thời hạn giữ.

Xem thêm danh sách kiểm tra rà soát bảo mật website một người.

Kinh nghiệm của OPCAIOS

Theo kịch bản sao lưu trong mã nguồn website (đọc ngày 25/10/2026), mỗi ngày hệ thống xuất cơ sở dữ liệu của website, nén lại, giữ 14 ngày trên máy chủ; nếu cấu hình kho từ xa thì sao chép thêm bản mã hoá (AES-256 bằng gpg) và giữ 60 ngày. Kịch bản còn sao lưu file dự án và cấu hình máy chủ cần để dựng lại. Nó từ chối bản xuất thiếu bảng bài viết, coi đó là sao lưu hỏng.

Hạn chế thật: tài liệu này cho thấy thiết kế, không chứng minh rằng chúng tôi đã thử khôi phục đầy đủ trên máy sạch định kỳ; đó vẫn là việc nên làm. Chúng tôi cũng không công bố đường dẫn, địa chỉ hay vị trí giữ passphrase. Phần dữ liệu nằm ngoài kịch bản này (ví dụ ghi chú cá nhân, mã nguồn ở máy khác) cần được sao lưu theo cách riêng.

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

Quy tắc 3-2-1 có đủ để chống ransomware không?

Không đủ một mình. Cần thêm bản bất biến hoặc ngoại tuyến và kiểm tra khôi phục, như các biến thể 3-2-1-1-0 mô tả.

Đồng bộ iCloud hay Google Drive có phải sao lưu không?

Không hẳn. Đồng bộ lan truyền cả việc xoá và hỏng file. Nó có thể là một bản trong chiến lược, không thay cho sao lưu có phiên bản.

Bao lâu nên sao lưu một lần?

Tuỳ lượng dữ liệu bạn chấp nhận mất. Dữ liệu thay đổi hằng ngày nên sao lưu hằng ngày; ghi chú ít đổi có thể thưa hơn.

Nên giữ bản sao lưu bao lâu?

Cân giữa chi phí và nhu cầu quay lại sự cố cũ. Đặt hai tầng: ngắn hạn trên máy, dài hạn hơn ở kho ngoài; yêu cầu pháp lý về lưu trữ hồ sơ cần hỏi chuyên gia.

Tôi không rành kỹ thuật, bắt đầu thế nào?

Bắt đầu từ việc liệt kê dữ liệu không thể mất, bật sao lưu tự động của dịch vụ đang dùng và thử khôi phục một file. Cần người dựng giúp, xem dịch vụ đào tạo ứng dụng AI.

Nguồn: các bài tổng hợp về quy tắc 3-2-1 (NinjaOne, Nakivo, v.v.) qua tìm kiếm ngày 25/10/2026; trang CISA trả lỗi 403 nên chưa xác minh việc CISA khuyến nghị; kịch bản sao lưu của chính dự án OPCAIOS, đọc ngày 25/10/2026. Thông tin nguồn gốc quy tắc là từ nguồn thứ cấp, chưa đọc sách gốc. Kinh nghiệm là của OPCAIOS.

Lê Quốc Nghĩa
Người xây dựng OPCAIOS

Để lại bình luận

Email của bạn sẽ không hiển thị công khai. Bình luận sẽ hiển thị sau khi được duyệt.