Backup WordPress hằng ngày hay hằng tuần? Cách chọn theo site

Site ít đổi thì sao lưu hằng tuần là đủ. Site đăng bài hoặc nhận form đều thì nên hằng ngày. Site có đơn hàng hoặc thành viên cần database theo giờ. Lịch sao lưu quyết định bạn mất tối đa bao nhiêu dữ liệu. Số bản giữ quyết định còn bản sạch hay không khi lỗi bị phát hiện muộn. Trong một ca Net Solutions xử lý, giữ 7 bản hằng ngày vẫn không còn bản nào trước ngày site bị chiếm.

Hằng ngày hay hằng tuần: tính theo dữ liệu mất tối đa

Mỗi lần sao lưu chụp lại site ở một thời điểm. Nếu site hỏng ngay trước lần sao lưu kế tiếp, mọi thứ ghi từ lần trước đó sẽ mất. Vì vậy lịch sao lưu chính là mức mất tối đa: hằng tuần là tới 7 ngày, hằng ngày là tới 24 giờ, theo giờ là tới 1 giờ.

Lấy một shop giả định nhận 12 đơn mỗi ngày. Đây là con số minh hoạ để tính, không phải số liệu của một khách cụ thể. Với lịch hằng tuần, tối đa 84 đơn nằm ngoài bản sao lưu. Hằng ngày còn 12 đơn. Theo giờ chưa tới 1 đơn.

Minh hoạ: 12 đơn/ngày là giả định để tính. Mức mất = tần suất đơn × khoảng cách giữa hai lần sao lưu.

Câu hỏi đúng là: một ngày dữ liệu của site này đáng giá bao nhiêu? Nếu bạn sửa site mỗi tháng một lần, mất 7 ngày gần như không mất gì. Nếu mỗi ngày có khách để lại thông tin, mất 24 giờ là mất khách thật.

Chọn lịch theo loại site, và tách database với tệp

Một site WordPress có hai phần đổi theo tốc độ khác nhau. Database chứa bài viết, bình luận, đơn hàng, thông tin form. Tệp gồm giao diện, plugin và ảnh tải lên. Database đổi từng giờ, tệp chỉ đổi khi bạn tải ảnh hoặc cập nhật plugin.

You need both to be able to fully restore a typical WordPress site.

— WordPress.org, Backups (mục Backing Up Your WordPress Site), 18/10/2026

Hai thứ cần cùng có thì mới khôi phục trọn vẹn, nhưng không cần cùng lịch. Nhiều nhà cung cấp sao lưu cũng chia lịch theo mức thay đổi như vậy. Database thường lệch nhịp nhanh hơn, nên cho nó lịch dày hơn.

Cách chia của Net Solutions theo mức thay đổi của dữ liệu, tổng hợp 21/10/2026. Không phải số trung bình thị trường.

Giữ bao nhiêu bản: lỗi phát hiện muộn cần giữ lâu, không cần sao lưu dày

Tần suất và số bản giữ là hai quyết định khác nhau. Tần suất cho biết bạn mất bao nhiêu khi site hỏng. Số bản giữ cho biết bạn còn quay lại được bao xa. Nhiều người chỉ chọn cái đầu rồi để nhà cung cấp tự đặt cái sau.

Ca thật Net Solutions từng xử lý: một site bị chiếm quyền ghi liên tục 20 ngày, từ 21/08 đến 09/09/2026. Không công cụ giám sát nào báo, và lỗi chỉ được phát hiện ngày 10/09. Thử áp bốn kiểu sao lưu lên ca này, giả định bản mới nhất tạo ngày 09/09.

Minh hoạ trên ca có thật, số bản giữ và ngày tạo bản là giả định. Dữ liệu phải làm lại = từ bản sạch mới nhất tới ngày phát hiện 10/09.

Bảng cho thấy một điều ngược trực giác. Hằng tuần giữ 8 bản có 5 bản sạch, trong khi hằng ngày giữ 7 bản không có bản nào. Với lỗi phát hiện muộn, chiều dài lịch sử quan trọng hơn độ dày của lịch. Hằng ngày giữ 30 bản cho kết quả tốt nhất, nhưng tốn dung lượng hơn nhiều.

Ca này cũng cho thấy vì sao nên giữ cả hai tầng: một vài bản hằng ngày gần đây cho lỗi mới, cộng vài bản hằng tuần cũ cho lỗi nằm im. Nếu bạn nghi site đã bị chiếm, bài dấu hiệu website bị hack liệt kê cách nhận biết.

Sao lưu ngoài lịch và nơi lưu bản sao

Lịch cố định không bắt được những lúc rủi ro cao nhất. Có ba thời điểm nên sao lưu thêm, bất kể lịch.

Back up your database regularly, and always before an upgrade.

— WordPress.org, Backups (mục Backup Questions), 18/10/2026

Thứ nhất là trước mỗi lần cập nhật plugin, giao diện hay WordPress. Thứ hai là trước khi sửa hàng loạt nội dung. Thứ ba là trước bản nâng core gấp. Ngày 22/09/2026 WordPress phát hành bản vá khẩn 7.1.2 cho lỗ hổng CVE-2026-87902. Nâng gấp là lúc dễ xảy ra sự cố nhất, nên cũng là lúc cần một bản mới.

Quy trình của Net Solutions đi theo nguyên tắc này: mọi lệnh ghi lên trang của khách đều lưu bản cũ kèm mã trước khi ghi. Sai thì quay lại đúng một thay đổi, không phải kéo cả site về tuần trước.

Về nơi lưu, bản sao nằm cùng máy chủ với site thì mất cả hai khi máy chủ hỏng hoặc bị chiếm. Hãy giữ ít nhất một bản ở nơi khác, và bảo đảm bạn tự tải về được. Đoạn mã dưới tính nhanh bạn còn bản sạch hay không, dựa trên lịch và số bản giữ của bạn. Đổi ngày bắt đầu lỗi và ngày phát hiện cho khớp tình huống của bạn.

from datetime import date, timedelta

def con_ban_sach(buoc_ngay, so_ban_giu, ban_moi_nhat, loi_bat_dau):
    # Ban sach = ban tao truoc ngay loi bat dau
    cac_ban = [ban_moi_nhat - timedelta(days=buoc_ngay * i) for i in range(so_ban_giu)]
    return [d for d in cac_ban if d < loi_bat_dau]

# Hang ngay (buoc 1), giu 7 ban, loi bat dau 21/08
sach = con_ban_sach(1, 7, date(2026, 9, 9), date(2026, 8, 21))
print(len(sach), 'ban sach')   # -> 0 ban sach

Thử khôi phục trước khi cần

Một bản sao lưu chưa từng khôi phục thử chỉ là một giả định. Hãy khôi phục thử sang môi trường riêng ít nhất mỗi quý. Cách làm nằm trong bài bảo trì website gồm những gì. Nếu site đã nhiễm mã độc và bạn không còn bản sạch, xem cách xử lý WordPress bị chèn mã độc.

Năm câu hỏi cho nhà cung cấp hosting hoặc sao lưu

Trang bảng giá hosting WebCloud của Net Solutions ghi “sao lưu định kỳ” và không nêu tần suất cụ thể. Gói chăm sóc website ghi tần suất sao lưu và điều kiện khôi phục trong thỏa thuận dịch vụ. Dù bạn dùng nhà cung cấp nào, hãy hỏi cho ra con số trước khi ký.

Khi nào cách chọn này không đủ

Hằng ngày vẫn mất tới 24 giờ. Shop có nhiều đơn mỗi giờ cần giải pháp ghi gần thời gian thực, chẳng hạn bản sao database liên tục hoặc dịch vụ thanh toán tự lưu đơn riêng. Đó là việc của người dựng hệ thống, không phải một lịch cron.

Sao lưu cũng không thay bảo mật. Nó chỉ giúp bạn quay lại sau khi sự cố đã xảy ra. Site vẫn cần cập nhật đúng hạn, giới hạn tài khoản quản trị và có người xem log. Lịch sao lưu tốt không ngăn được kẻ tấn công quay lại lần hai.

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

Backup hằng tuần có đủ không? Đủ với site giới thiệu ít đổi, nơi mất 7 ngày dữ liệu gần như không đáng kể. Không đủ nếu site nhận form, đơn hàng hay bài viết mỗi ngày. Hãy tính theo cách ở trên: một tuần dữ liệu của bạn đáng giá bao nhiêu.

Database và tệp có cần cùng lịch không? Không. Database đổi nhanh hơn nên cần lịch dày hơn. Tệp chỉ đổi khi tải ảnh hoặc cập nhật plugin, nên hằng tuần cộng với sao lưu sau mỗi lần cập nhật thường đủ. Khi khôi phục, bạn cần cả hai.

Nên giữ bao nhiêu bản? Tính theo thời gian lỗi có thể nằm im, không theo thói quen. Ca 20 ngày ở trên cần ít nhất bản cũ hơn 20 ngày. Một cách thực tế là giữ vài bản hằng ngày gần đây và vài bản hằng tuần cũ hơn.

Có cần sao lưu trước khi cập nhật plugin không? Có. Cập nhật là lúc xung đột plugin dễ làm site trắng trang nhất. WordPress.org cũng khuyên sao lưu database trước mỗi lần nâng cấp. Một bản ngay trước khi cập nhật cho bạn đường lùi chỉ cách vài phút.

Hosting đã sao lưu thì có cần plugin nữa không? Tuỳ nhà cung cấp trả lời được năm câu hỏi ở trên đến đâu. Nếu bản sao của hosting nằm cùng máy chủ, không tự tải về được hoặc chỉ giữ vài ngày, hãy thêm một lớp sao lưu độc lập ở nơi khác.

Bao lâu nên thử khôi phục? Ít nhất mỗi quý, và sau mỗi lần đổi hosting hay nhà cung cấp sao lưu. Hãy khôi phục sang môi trường riêng rồi mở thử trang chủ, form và trang đăng nhập.

Cập nhật 24/10/2026 bởi Công ty TNHH Net Solutions.