Chiến lược sao lưu website 3-2-1: áp dụng thực tế cho VPS

Chiến lược sao lưu website 3-2-1 cho VPS: sao lưu gì, bao lâu một lần, lưu ở đâu, chống ransomware, thử khôi phục, kèm lệnh restic và cách làm trên ZoPanel.

Sơ đồ: ba bản sao dữ liệu website, trên server, trên kho lưu trữ thứ hai và ngoài server

Ý chính

  • Quy tắc 3-2-1 nghĩa là ba bản dữ liệu, trên hai hệ thống lưu trữ khác nhau, trong đó một bản ở ngoài nơi đặt server.
  • Bản sao lưu nằm trên cùng VPS chỉ chống được lỗi thao tác và mã độc, không chống được mất server.
  • Kẻ tấn công có quyền root đọc được khoá S3 trên server, nên cần versioning, object lock hoặc giới hạn quyền xoá ở kho ngoài.
  • Bản sao lưu chưa từng được khôi phục thử thì chưa được chứng minh là dùng được.

Chiến lược sao lưu website 3-2-1 nghĩa là luôn có ba bản dữ liệu, nằm trên hai hệ thống lưu trữ khác nhau, trong đó một bản ở ngoài nơi đặt server. Với một website chạy trên VPS, cách áp dụng thực tế là: bản đang chạy, một bản sao lưu trên chính server để khôi phục nhanh, và một bản được mã hoá, đẩy lên kho lưu trữ S3 ở nhà cung cấp khác. Thêm một điều kiện nữa mà quy tắc gốc không nói: bạn phải từng khôi phục thử thành công.

Bài này đi qua những thứ cần sao lưu (nhiều hơn bạn nghĩ), tần suất phù hợp cho từng loại website, cách chống trường hợp kẻ tấn công xoá luôn bản sao lưu, cách tự làm bằng restic và cách ZoPanel ánh xạ 3-2-1 vào các tính năng có sẵn.

Quy tắc sao lưu 3-2-1 là gì?

Quy tắc 3-2-1 thường được gán cho nhiếp ảnh gia Peter Krogh, người phổ biến nó trong sách về quản lý ảnh số, và từ đó trở thành nguyên tắc sao lưu được nhắc nhiều nhất:

Thành phần Ý nghĩa gốc Áp dụng cho VPS
3 bản Dữ liệu gốc cộng hai bản sao lưu Website đang chạy + bản trên server + bản ngoài server
2 loại lưu trữ Ví dụ ổ cứng và băng từ Hai hệ thống hỏng độc lập: ổ của VPS và kho object storage
1 bản ngoài Cất ở địa điểm khác Kho ở nhà cung cấp hoặc vùng khác với VPS

Ý tưởng cốt lõi không phải con số, mà là không có một sự cố nào xoá được mọi bản cùng lúc: ổ hỏng, nhà cung cấp VPS gặp sự cố, bạn lỡ tay xoá, plugin lỗi ghi đè database, hay mã độc mã hoá file.

Sao lưu website cần sao lưu những gì?

Nhiều người chỉ sao lưu thư mục public_html và database, rồi phát hiện ra thiếu khi khôi phục. Danh sách đầy đủ:

  • File website: code, theme, plugin, ảnh và file người dùng tải lên.
  • Database: MariaDB/MySQL, PostgreSQL. Phải dump đúng cách (ví dụ --single-transaction), chép file database đang chạy thường cho ra bản hỏng.
  • Email: hộp thư của khách, nếu server có chạy mail.
  • DNS zone: nếu DNS nằm trên server của bạn.
  • Cấu hình: virtual host nginx, cấu hình PHP, cron job, cấu hình panel.
  • Khoá và bí mật: file .env, khoá DKIM, mật khẩu giải mã bản sao lưu. Bản sao lưu được mã hoá mà mất khoá thì vô dụng.

Chứng chỉ SSL Let's Encrypt cấp lại được trong vài phút, không nhất thiết phải sao lưu.

Sao lưu bao lâu một lần? Bắt đầu từ RPO và RTO

Hai câu hỏi quyết định tần suất:

  • RPO (Recovery Point Objective): bạn chấp nhận mất tối đa bao nhiêu dữ liệu? Sao lưu hằng ngày nghĩa là có thể mất tới gần 24 giờ.
  • RTO (Recovery Time Objective): website được phép ngừng bao lâu trong lúc khôi phục?
Loại website Gợi ý tần suất Lý do
Website giới thiệu, blog ít cập nhật File và database hằng ngày Nội dung ít đổi
Tin tức, blog cập nhật liên tục Database vài giờ một lần, file hằng ngày Bài viết mới mỗi ngày
WooCommerce, website có đơn hàng Database mỗi giờ Mất một ngày đơn hàng là mất tiền thật
Hosting nhiều khách hàng Mỗi đêm cho mọi tài khoản, cộng database dày hơn cho khách cần Cân bằng dung lượng và rủi ro

Về thời gian giữ lại, mô hình phổ biến là giữ theo ngày, tuần và tháng: ví dụ 7 bản ngày, 4 bản tuần, 6 bản tháng. Lý do: mã độc hay lỗi dữ liệu thường bị phát hiện muộn, khi mọi bản sao lưu hằng ngày đều đã nhiễm.

Bản trên server, bản ngoài server: khác nhau thế nào?

Bản trên server khôi phục nhanh nhất, không tốn băng thông, và cứu bạn trong các tình huống thường gặp nhất: lỡ xoá file, cập nhật plugin hỏng, website bị chèn mã độc. Nhưng nó nằm trên cùng ổ đĩa với website. VPS mất, bản này mất theo.

Bản ngoài server là thứ cứu bạn khi mất cả server. Nên đặt ở nhà cung cấp khác với VPS, không chỉ vùng khác của cùng nhà cung cấp: tài khoản bị khoá, thanh toán lỗi hay sự cố toàn hệ thống của một nhà cung cấp sẽ ảnh hưởng mọi thứ bạn đặt ở đó. Bản snapshot do nhà cung cấp VPS tạo là bổ sung tốt, nhưng không thay được bản ngoài.

Chống trường hợp kẻ tấn công xoá luôn bản sao lưu

Đây là điểm yếu của hầu hết thiết lập sao lưu: server đẩy bản sao lưu lên S3 thì server phải giữ khoá S3. Kẻ tấn công chiếm được root sẽ đọc được khoá đó và có thể xoá sạch kho. Các lớp phòng vệ:

  1. Khoá chỉ dùng cho một bucket, không dùng khoá có quyền trên toàn tài khoản lưu trữ.
  2. Bật versioning trên bucket, kèm luật vòng đời xoá phiên bản cũ sau N ngày. Lệnh xoá khi đó chỉ tạo "delete marker", phiên bản cũ vẫn khôi phục được trong N ngày.
  3. Object lock (ví dụ S3 Object Lock của AWS): không ai xoá được object trước ngày hết hạn khoá, kể cả người có khoá truy cập. Kiểm tra nhà cung cấp của bạn có hỗ trợ không, và lưu ý nó có thể xung đột với công cụ sao lưu tự xoá bản cũ.
  4. Sao lưu kiểu kéo: một server khác kéo dữ liệu về, server web không có quyền gì trên kho đó.
  5. Mã hoá trước khi tải lên, để nhà cung cấp lưu trữ hay ai lấy được khoá bucket cũng chỉ thấy dữ liệu đã mã hoá.

Tự làm chiến lược 3-2-1 bằng restic

restic là công cụ sao lưu mã nguồn mở: tăng dần, khử trùng lặp, mã hoá, hỗ trợ S3. Trên Ubuntu 24.04 và Debian 12, cài bằng sudo apt install restic. Ví dụ cho một VPS có website và MariaDB:

# /root/restic.env (chmod 600)
export RESTIC_REPOSITORY="s3:https://s3.example-provider.com/my-backups/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
export AWS_ACCESS_KEY_ID="khoá-chỉ-cho-bucket-này"
export AWS_SECRET_ACCESS_KEY="..."
source /root/restic.env
restic init                                        # chỉ chạy lần đầu

# database: dump nhất quán, đưa thẳng vào restic
mariadb-dump --single-transaction --all-databases \
  | restic backup --stdin --stdin-filename all-databases.sql

# file website và cấu hình
restic backup /var/www /etc/nginx /etc/php

# giữ 7 bản ngày, 4 bản tuần, 6 bản tháng
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# kiểm tra kho, đọc lại ngẫu nhiên 2% dữ liệu
restic check --read-data-subset=2%

Đặt các lệnh vào một script, chạy bằng systemd timer hoặc cron, và gửi cảnh báo khi script lỗi. Sao lưu âm thầm thất bại suốt ba tháng là kịch bản phổ biến hơn bạn nghĩ. Cất mật khẩu restic ở ngoài server (trình quản lý mật khẩu): không có nó, không ai giải mã được kho. Chi tiết về cấu hình S3, xem bài backup VPS lên S3.

Chiến lược 3-2-1 với ZoPanel

ZoPanel có sẵn các loại sao lưu bổ trợ nhau, nên việc của bạn chủ yếu là bật và cất khoá đúng chỗ:

Bản Trong ZoPanel
Bản 1: dữ liệu đang chạy Website, database, mail trên server
Bản 2: trên server, khôi phục nhanh Sao lưu toàn phần hằng ngày hoặc hằng tuần lúc 02:00 (giữ 1 - 90 bản, mặc định 7); snapshot tăng dần restic mỗi đêm lúc 01:00 (giữ 7 ngày, 4 tuần, 6 tháng); sao lưu database mỗi giờ, mỗi 6 giờ hoặc mỗi ngày
Bản 3: ngoài server Cài đặt → Sao lưu từ xa đẩy mọi bản sao lưu lên S3 (AWS, Cloudflare R2, Backblaze B2, Wasabi, MinIO...), mã hoá XChaCha20-Poly1305 trước khi tải lên. Cần license Pro.

Vài cơ chế an toàn đáng chú ý:

  • Trước mỗi lần sao lưu, ZoPanel kiểm tra dung lượng trống và không chạy nếu còn dưới 1 GB hoặc dưới 5% ổ đĩa, để sao lưu không làm đầy ổ và kéo sập website. Mỗi file có checksum SHA-256, được kiểm tra lại trước khi khôi phục.
  • Mỗi thứ Bảy lúc 05:00, ZoPanel kiểm tra cấu trúc kho restic và đọc lại 2% dữ liệu; nếu lỗi, quản trị viên nhận cảnh báo Sao lưu thất bại.
  • Sao lưu cấu hình (.zpb) chứa cài đặt panel, gói dịch vụ, tài khoản quản trị, khoá DKIM và DNS, được đẩy lên S3 mỗi ngày khi bật sao lưu từ xa. Kết hợp với khoá khôi phục, bạn dựng lại được cả server trên VPS mới. Xem tài liệu cứu hộ thảm họa.
  • Trung tâm bảo mật cảnh báo khi chưa có sao lưu ra ngoài server, và khi 48 giờ qua không có bản sao lưu nào thành công.
  • Khách hàng tự đặt lịch sao lưu và chép lên kho S3 riêng của họ, tạo thêm một bản độc lập với kho của nhà cung cấp hosting.

Việc quan trọng nhất bạn phải tự làm: ghi lại khoá khôi phục (Sao lưu → Cứu hộ thảm họa → Xem khóa) và khoá của sao lưu tăng dần, cất ngoài server. Mất server mà không có khoá thì dữ liệu trên S3 không giải mã được, và không ai khôi phục giúp được. Chi tiết trong tài liệu sao lưu.

Kiểm tra khôi phục: phần hay bị bỏ qua nhất

Mỗi quý một lần, thuê một VPS tạm trong vài giờ và làm đúng quy trình "mất server":

  1. Cài hệ thống mới, chỉ dùng thông tin bạn cất ngoài server (khoá S3, khoá khôi phục).
  2. Khôi phục một website và database từ kho ngoài.
  3. Mở website, đăng nhập quản trị, kiểm tra ảnh, đơn hàng gần nhất, form liên hệ.
  4. Ghi lại mất bao lâu. Đó là RTO thật của bạn, không phải con số bạn đoán.

Nếu bước nào bị kẹt, bạn vừa tìm ra lỗ hổng mà không phải trả giá bằng website thật.

Kết luận

Chiến lược sao lưu website 3-2-1 không phức tạp: một bản trên server để khôi phục nhanh, một bản mã hoá ở nhà cung cấp khác để sống sót khi mất server, khoá giải mã cất ở nơi thứ ba, và một lần khôi phục thử mỗi quý. Phần khó là kỷ luật: cảnh báo khi sao lưu lỗi, và không để khoá chỉ nằm trên server.

ZoPanel có sẵn sao lưu toàn phần, tăng dần, database và sao lưu cấu hình; gói Free dùng được các bản sao lưu trên server, còn sao lưu mã hoá lên S3 nằm trong gói Pro. Xem bảng giá.

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

Quy tắc sao lưu 3-2-1 là gì?

Ba bản dữ liệu (bản gốc và hai bản sao lưu), trên hai hệ thống lưu trữ khác nhau, trong đó một bản ở ngoài nơi đặt server. Mục đích là không một sự cố đơn lẻ nào xoá được mọi bản cùng lúc.

Sao lưu trên cùng VPS có đủ không?

Không. Bản trên server giúp khôi phục nhanh khi lỡ xoá hay bị mã độc, nhưng mất VPS hoặc hỏng ổ thì mất luôn. Luôn cần ít nhất một bản ở ngoài server, tốt nhất ở nhà cung cấp khác.

Nên sao lưu website bao lâu một lần?

Tuỳ bạn chấp nhận mất bao nhiêu dữ liệu. Website ít cập nhật sao lưu hằng ngày là đủ; website bán hàng nên sao lưu database mỗi giờ. Giữ thêm bản theo tuần và tháng, vì sự cố thường được phát hiện muộn.

Làm sao để hacker không xoá được bản sao lưu?

Dùng khoá S3 chỉ có quyền trên một bucket, bật versioning hoặc object lock ở kho lưu trữ, và mã hoá trước khi tải lên. Cách chắc chắn nhất là để một server khác kéo bản sao lưu về, để server web không có quyền xoá.

Bao lâu nên kiểm tra khôi phục một lần?

Ít nhất mỗi quý một lần, trên một VPS tạm, chỉ dùng những gì cất ngoài server. Bản sao lưu chưa từng được khôi phục thử thì chưa được chứng minh là dùng được.