Cách tự động backup website WordPress lên S3 mỗi đêm

Sáng thứ Hai mở website ra thấy trắng trang — hosting gặp sự cố, mà bản backup gần nhất đã từ hai tháng trước. Kịch bản này xảy ra với rất nhiều chủ website WordPress tại Việt Nam, nguyên nhân thường giống nhau: backup thủ công, nhớ lúc nào làm lúc đó. Giải pháp bền vững là tự động hóa: mỗi đêm hệ thống tự backup website lên S3 mà bạn không cần động tay. Bài viết hướng dẫn chi tiết cách backup wordpress lên s3 tự động — từ plugin đơn giản đến script chuyên nghiệp.

Vì sao nên backup WordPress lên S3?

WordPress gồm hai thành phần cần backup: source code (theme, plugin, file upload trong wp-content) và database (bài viết, đơn hàng, cấu hình). Thiếu một trong hai, bạn không thể khôi phục website hoàn chỉnh.

S3 là dịch vụ lưu trữ object được nhiều nhà cung cấp cloud Việt Nam triển khai. Ưu điểm cho backup: độ bền dữ liệu rất cao; chi phí tính theo dung lượng thực dùng; tách bạch hoàn toàn khỏi server chính.

Nguyên tắc vàng là 3-2-1: 3 bản sao dữ liệu, trên 2 phương tiện khác nhau, trong đó 1 bản offsite. Backup lên S3 chính là bản offsite của bạn. Kết hợp backup tự động mỗi đêm, RPO (lượng dữ liệu chấp nhận mất) tối đa chỉ 1 ngày.

Backup wordpress lên s3: chuẩn bị: S3 bucket và thông tin truy cập

Bước 1 — Tạo bucket: đăng nhập portal của nhà cung cấp S3, tạo bucket mới với tên dễ nhận biết, ví dụ backup-website-tencongty. Chọn region gần nhất để upload nhanh. Bật versioning nếu muốn giữ nhiều phiên bản của cùng một file.

Bước 2 — Tạo access key: tạo IAM user chỉ có quyền truy cập đúng bucket backup đó — nguyên tắc "quyền tối thiểu". Lưu lại Access Key ID và Secret Access Key.

Bước 3 — Cấu trúc thư mục: trong bucket, tổ chức theo dạng ten-website/nam/thang/ để dễ tìm bản cần restore và dễ áp dụng chính sách xóa bản cũ tự động.

Bước 4 — Kiểm tra kết nối: upload thử một file nhỏ để chắc chắn access key hoạt động — tránh tình trạng "backup chạy 3 tháng mà không có file nào được upload".

Lưu ý: Secret Access Key phải giữ kín tuyệt đối — không commit vào git, không dán vào tài liệu chia sẻ công khai.

Backup wordpress lên s3: cách 1: dùng plugin UpdraftPlus lên lịch backup mỗi đêm

Đây là cách đơn giản nhất, phù hợp với đa số chủ website không chuyên về server. UpdraftPlus là plugin backup WordPress phổ biến nhất, bản miễn phí đã hỗ trợ backup lên S3.

Cài đặt và kết nối S3: trong wp-admin, cài plugin UpdraftPlus, vào Settings → chọn S3 làm remote storage. Điền Access Key, Secret Key, tên bucket và region, rồi nhấn "Test S3 Settings".

Cấu hình nội dung: chọn backup đầy đủ gồm database + plugins + themes + uploads. Loại trừ thư mục cache (wp-content/cache) để giảm dung lượng và thời gian backup.

Lên lịch tự động: backup files mỗi đêm (2h sáng), backup database mỗi 12 giờ. Giữ 7 bản gần nhất cho files, 14 bản cho database — plugin tự xóa bản cũ nhất khi vượt số lượng.

Thông báo lỗi: cấu hình email thông báo khi backup thất bại — đừng để hệ thống backup "chết lặng" mà bạn không hay biết.

Ưu điểm: cài trong 15 phút, restore vài cú click ngay trong wp-admin. Nhược điểm: chạy trên chính server web nên tốn tài nguyên lúc backup (đặt lịch giờ thấp điểm); bản miễn phí chưa có backup incremental.

Backup wordpress lên s3: cách 2: script bash + cron backup lên S3 không cần plugin

Với website lớn hoặc quản trị viên thích kiểm soát tuyệt đối, script bash + cron linh hoạt hơn và không phụ thuộc WordPress (backup được cả khi website đã sập).

Backup database: dùng mysqldump xuất ra file SQL, nén gzip, đặt tên theo ngày:

mysqldump -u DB_USER -p'DB_PASS' DB_NAME | gzip > /backup/db-$(date +%F).sql.gz

Lưu password trong file cấu hình riêng với quyền 600.

Backup source: dùng tar nén toàn bộ thư mục WordPress, loại trừ cache:

tar -czf /backup/files-$(date +%F).tar.gz --exclude='wp-content/cache' /var/www/html

Upload lên S3:

s3cmd put /backup/db-$(date +%F).sql.gz s3://backup-website-tencongty/
s3cmd put /backup/files-$(date +%F).tar.gz s3://backup-website-tencongty/

Lên lịch cron chạy lúc 2h sáng mỗi ngày:

0 2 * * * /opt/backup/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Script nên ghi log và gửi cảnh báo (email/Telegram) khi lỗi — backup thất bại mà không ai biết thì cũng như không backup.

Dọn bản cũ: xóa file local quá 7 ngày, cấu hình lifecycle trên S3 tự xóa object quá 30 ngày.

Ưu điểm: nhẹ, nhanh, không tốn tài nguyên PHP/MySQL, backup được cả khi WordPress đã lỗi. Nhược điểm: cần biết cơ bản về Linux; restore phải làm thủ công.

Cấu trúc backup chuẩn: full, incremental và retention

Backup mỗi đêm không có nghĩa là mỗi đêm copy toàn bộ website. Chiến lược chuẩn kết hợp hai loại backup.

Full backup: sao lưu toàn bộ source + database, thực hiện 1 lần mỗi tuần (đêm Chủ nhật). Đây là "mốc neo" để restore.

Incremental backup: chỉ sao lưu những gì thay đổi từ lần trước. Với database WordPress, dump toàn bộ mỗi đêm vẫn nhẹ nhàng (thường chỉ vài trăm MB). Với source, dùng rsync hoặc tính năng incremental của công cụ backup để chỉ upload file mới/thay đổi.

Retention: giữ bản full 4 tuần gần nhất + bản incremental hàng ngày trong 7–14 ngày. Cấu hình lifecycle trên S3 tự chuyển bản quá 30 ngày sang lớp lưu trữ rẻ hơn và xóa bản quá 90 ngày.

Lưu ý: tách backup database và source thành hai lịch riêng. Database thay đổi liên tục nên backup mỗi 6–12 giờ; source thay đổi ít hơn — mỗi đêm là đủ.

Bảo mật file backup trên S3

File backup chứa toàn bộ "ruột gan" của website: database với thông tin khách hàng, khóa API, cấu hình thanh toán. Nếu lọt vào tay kẻ xấu, hậu quả không kém gì bị hack trực tiếp.

Mã hóa khi lưu trữ: bật mã hóa phía server để file backup trên S3 luôn ở dạng mã hóa. Với dữ liệu nhạy cảm, mã hóa bằng GPG ngay trên server trước khi upload.

Phân quyền: bucket backup phải ở chế độ private tuyệt đối. IAM user dùng cho backup chỉ có quyền ghi và liệt kê/xóa theo lifecycle.

Bảo vệ access key: lưu key trong file cấu hình quyền 600, xoay vòng định kỳ 3–6 tháng. Nếu nghi key bị lộ, thu hồi ngay.

Tuân thủ pháp lý: nếu website lưu dữ liệu cá nhân người dùng Việt Nam, file backup cũng chịu điều chỉnh của Luật Bảo vệ dữ liệu cá nhân. Dùng S3 của nhà cung cấp Việt Nam để dữ liệu lưu trữ trong nước.

Kiểm tra khôi phục: backup không test = không backup

Sự thật phũ phàng: nhiều bản backup "trông có vẻ ổn" nhưng đến lúc restore mới phát hiện bị lỗi — file nén hỏng, database dump thiếu bảng. Quy tắc bất di bất dịch: bản backup chưa từng restore thử thành công thì coi như chưa có backup.

Test restore định kỳ: mỗi tháng một lần, dựng môi trường staging tách biệt, tải bản backup mới nhất từ S3 về, giải nén source, import database, chỉnh lại wp-config.php (tắt tích hợp thanh toán/email thật), rồi kiểm tra: trang chủ hiển thị đúng không, đăng nhập admin được không, dữ liệu có đầy đủ không.

Kiểm tra tính toàn vẹn tự động: sau mỗi lần backup, kiểm tra file nén giải nén thử được không (gzip -t), dung lượng có bất thường không. Ghi log và cảnh báo khi bất thường.

Đo thời gian restore (RTO): bấm giờ toàn bộ quy trình restore trong lúc test — con số này chính là RTO thực tế của bạn. Nếu RTO là 4 giờ trong khi cam kết với khách hàng là 1 giờ, cần tối ưu quy trình.

Tài liệu hóa: viết các bước restore thành checklist ngắn, lưu ở nơi không phụ thuộc vào chính server đang backup. Lúc sự cố 2h sáng, người trực cần checklist rõ ràng chứ không phải mò mẫm.

Tối ưu chi phí lưu trữ backup trên S3

Backup tự động mỗi đêm nếu không quản lý sẽ khiến hóa đơn S3 tăng dần. Vài nguyên tắc giúp chi phí trong tầm kiểm soát.

Loại trừ những gì không cần: thư mục cache, file log, bản sao lưu cũ của plugin — có thể chiếm 30–50% dung lượng mà hoàn toàn tái tạo được. Cấu hình exclude ngay từ đầu.

Nén hiệu quả: database dạng text nén bằng gzip thường giảm 70–90% dung lượng. Nén tar.gz trước khi upload thay vì upload từng file riêng lẻ.

Lifecycle thông minh: bản dưới 30 ngày giữ ở lớp standard để restore nhanh; bản 30–90 ngày chuyển sang lớp lưu trữ rẻ hơn; bản quá 90–180 ngày tự động xóa. Khả năng cần restore bản quá 3 tháng là rất thấp.

Giám sát dung lượng: đặt cảnh báo khi bucket tăng đột biến 50% trong một tuần — có thể do website bị upload file lạ hoặc retention cấu hình sai.

Ước tính trước: dung lượng website (GB) × số bản full giữ lại + dung lượng tăng mỗi ngày × số ngày giữ incremental. Ví dụ website 5GB, giữ 4 bản full + incremental 2 tuần (~0.2GB/ngày): khoảng 23GB. Từ đó ước tính chi phí theo bảng giá S3 của nhà cung cấp (giá tham khảo tại thời điểm viết, xem giá mới nhất tại website nhà cung cấp).

Lịch backup gợi ý theo quy mô website

Nguyên tắc chung: dữ liệu thay đổi càng nhanh, backup càng thường xuyên; dữ liệu càng quan trọng, retention càng dài. Với WooCommerce, ngoài backup định kỳ, hãy cân nhắc MySQL replication về server dự phòng để RPO gần như bằng 0 cho đơn hàng.

Đồng bộ giờ backup với múi giờ khách hàng: website phục vụ khách Việt Nam thì 2–3h sáng là lý tưởng. Backup làm tăng tải I/O, có thể khiến website chậm đi đôi chút trong lúc chạy — tránh giờ cao điểm.

Kết luận

Tự động backup wordpress lên s3 mỗi đêm không khó: với người không chuyên, plugin UpdraftPlus cấu hình trong 15 phút là có ngay lịch backup tự động; với quản trị viên, script bash + cron cho độ linh hoạt cao hơn. Điểm mấu chốt không nằm ở công cụ mà ở kỷ luật: backup phải tự động, phải có bản offsite trên S3 đúng nguyên tắc 3-2-1, phải được mã hóa và phân quyền chặt chẽ, và quan trọng nhất — phải được restore thử định kỳ.

Nếu bạn đang tìm dịch vụ lưu trữ S3 tại Việt Nam để làm nơi chứa backup — tốc độ upload nhanh, dữ liệu lưu trong nước, chi phí tính theo dung lượng thực dùng — hãy liên hệ SunCloud qua hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn giải pháp S3 và Cloud Server phù hợp (giá tham khảo tại thời điểm viết, xem giá mới nhất tại suncloud.vn).

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

Backup lên S3 có an toàn hơn để trên cùng VPS không?

An toàn hơn rất nhiều. Backup trên cùng VPS sẽ mất theo khi ổ cứng hỏng, server bị hack xóa dữ liệu, hoặc datacenter gặp sự cố. S3 là hệ thống lưu trữ độc lập với nhiều bản sao, tách bạch hoàn toàn khỏi server chính — đúng nguyên tắc "1 bản offsite" trong quy tắc 3-2-1.

Nên backup mỗi đêm vào khung giờ nào?

Khung giờ thấp điểm của website bạn — với đa số website Việt Nam là 2–4h sáng. Backup (đặc biệt dump database lớn và nén file) làm tăng tải CPU và I/O, có thể khiến website chậm đi trong lúc chạy. Tránh giờ cao điểm buổi tối hoặc lúc đang chạy chiến dịch quảng cáo.

Plugin UpdraftPlus bản miễn phí có đủ dùng không?

Đủ cho đa số website vừa và nhỏ: backup đầy đủ database + files, lên lịch tự động, lưu lên S3, tự xóa bản cũ, restore vài cú click. Bản trả phí bổ sung backup incremental (tiết kiệm dung lượng), mã hóa database và hỗ trợ multisite. Khi website lớn dần, nâng cấp bản trả phí để dùng incremental thường "đáng tiền".

Backup database và backup files có thể gộp làm một không?

Về mặt kỹ thuật thì có, nhưng không nên. Database thay đổi liên tục nên cần backup mỗi 6–12 giờ; source thay đổi ít hơn — mỗi đêm là đủ. Tách riêng giúp tiết kiệm dung lượng, rút ngắn thời gian backup, và khi restore bạn có thể chỉ restore database (trường hợp phổ biến nhất) mà không động đến files.

File backup trên S3 bị xóa nhầm thì sao?

Bật versioning cho bucket — file bị xóa hoặc ghi đè vẫn giữ phiên bản cũ và khôi phục được. Ngoài ra, giới hạn quyền xóa của IAM user dùng cho backup hàng ngày (chỉ cho lifecycle tự động xóa theo chính sách, không cho xóa thủ công).

Có cần backup cả khi đã dùng dịch vụ backup của nhà cung cấp hosting không?

Có. Backup của nhà cung cấp hosting là một lớp bảo vệ tốt, nhưng bạn không kiểm soát được tần suất, retention và vị trí lưu trữ của nó. Nguyên tắc 3-2-1 yêu cầu bản sao độc lập do chính bạn kiểm soát — backup lên S3 đảm bảo dù hosting gặp sự cố nghiêm trọng nhất, bạn vẫn có dữ liệu để dựng lại website ở bất kỳ đâu.