0938.03.73.03 
0901.53.66.79 
3 giờ sáng, website của bạn trắng trang. Một bản cập nhật plugin chạy tự động lúc nửa đêm đã xung đột với theme. Trang chủ chỉ còn dòng lỗi PHP. Bạn gọi hosting, họ trả lời: bản sao lưu gần nhất là 14 ngày trước — và nó không bao gồm database.
Đây không phải kịch bản hiếm. Trong thực tế vận hành, phần lớn sự cố mất dữ liệu WordPress không đến từ hacker mà đến từ những việc rất đời thường: update sai thứ tự, cài nhầm plugin, sửa file functions.php trực tiếp trên host, hoặc đơn giản là hết hạn hosting mà không ai nhớ gia hạn.
Bài viết này hướng dẫn backup website WordPress theo hai luồng song song — thủ công và tự động — kèm khung tiêu chuẩn 3-2-1 và phần quan trọng nhất mà 90% người làm web bỏ qua: diễn tập phục hồi. Một bản sao lưu chưa được restore thử thì vẫn chỉ là một file nén, không phải một bản backup.
ĐỌC NHANH TRONG 30 GIÂY
- Một bản backup hợp lệ phải có đủ 2 nửa: source code (file) và database (MySQL). Thiếu một nửa là không khôi phục được.
- Áp dụng quy tắc 3-2-1: 3 bản sao, 2 nơi lưu trữ khác nhau, 1 bản nằm ngoài hosting.
- Backup thủ công dùng để chốt mốc trước khi thay đổi lớn. Backup tự động dùng để chạy nền hàng ngày. Cần cả hai, không thay thế nhau.
- Restore thử ít nhất 1 lần/quý trên môi trường staging. Không test = không có backup.
Một bản sao lưu website “đủ” gồm những gì?
Sai lầm phổ biến nhất khi sao lưu website là tải về mỗi thư mục wp-content rồi yên tâm. WordPress vận hành trên hai phần tách rời, và bạn cần cả hai để dựng lại trang.
Cách hiểu đơn giản: Source code là ngôi nhà, database là toàn bộ đồ đạc và con người bên trong. Có nhà mà không có đồ đạc, bạn được một website trắng trơn cài sẵn theme. Có đồ đạc mà không có nhà, bạn được một file .sql không mở nổi.
Quy tắc 3-2-1: khung chuẩn cho mọi chiến lược backup
Trước khi bàn tới công cụ, hãy chốt nguyên tắc. Quy tắc 3-2-1 là chuẩn được giới IT hạ tầng dùng suốt hàng chục năm, và nó áp dụng nguyên vẹn cho website nhỏ:
bản sao dữ liệu
Bản đang chạy trên host + 2 bản sao lưu độc lập. Một bản duy nhất là điểm chết đơn lẻ.
loại lưu trữ khác nhau
Ví dụ: cloud storage + ổ cứng máy tính. Không để cả hai bản trong cùng một tài khoản hosting.
bản nằm ngoài hosting
Nếu server cháy, bị khoá tài khoản hoặc nhà cung cấp ngừng dịch vụ, đây là bản cứu bạn.
Điểm dễ vi phạm nhất là số “1”. Rất nhiều website Việt Nam đang lưu backup ngay trong public_html/backup/ — tức là bản sao lưu nằm cùng chỗ với dữ liệu gốc. Khi server gặp sự cố hoặc bị mã hoá tống tiền, cả hai mất cùng lúc. Tệ hơn, thư mục backup lộ ra ngoài internet có thể bị tải về, và trong file .sql có toàn bộ hash mật khẩu quản trị.
Nên chọn luồng nào: thủ công hay tự động?
Câu trả lời chuyên nghiệp là cả hai, nhưng chúng phục vụ hai mục đích khác nhau. Dùng bảng dưới để hiểu vai trò của từng luồng thay vì chọn một bên:
| Tiêu chí | LUỒNG A – Thủ công | LUỒNG B – Tự động |
|---|---|---|
| Vai trò chính | Chốt mốc an toàn trước thay đổi lớn | Lưới an toàn chạy nền hàng ngày |
| Khi nào dùng | Trước khi update core/theme/plugin, đổi host, sửa code, chuyển domain | Mọi ngày, không cần ai nhớ tới nó |
| Độ tin cậy | Cao — bạn kiểm soát và nhìn thấy từng file | Phụ thuộc cấu hình; có thể âm thầm lỗi nếu không giám sát |
| Rủi ro lớn nhất | Con người quên làm | Backup lỗi nhưng không ai biết vì không có cảnh báo |
| Yêu cầu kỹ thuật | Biết cPanel/FTP, phpMyAdmin | Cài và cấu hình plugin một lần |
| Phù hợp với | Người quản trị có kỹ thuật, agency, dev | Chủ doanh nghiệp, marketer, site thương mại điện tử |
Mô hình vận hành lành mạnh: Luồng B chạy nền hàng ngày để bạn không bao giờ mất quá 24 giờ dữ liệu, và Luồng A được kích hoạt thủ công mỗi khi sắp làm điều gì có thể phá vỡ website.
Luồng A — Cách backup web thủ công (toàn quyền kiểm soát)
Backup thủ công gồm hai vế tách rời: tải file về, rồi export database. Làm đúng thứ tự và bạn có một bản sao lưu sạch, không phụ thuộc plugin nào.
A1. Tải toàn bộ source code về máy
Cách 1 — Qua File Manager của cPanel/DirectAdmin (khuyến nghị cho người mới):
- Đăng nhập cPanel → mở File Manager → vào thư mục
public_html. - Bật hiển thị file ẩn: Settings (góc phải trên) → tick Show Hidden Files (dotfiles). Bước này quyết định việc bạn có lấy được
.htaccesshay không. - Chọn Select All → nhấn Compress → chọn định dạng Zip Archive → đặt tên theo mẫu
tenweb-files-2026-07-15.zip. - Nén xong, chọn file zip → Download về máy.
- Xoá file zip trên server ngay sau khi tải xong. Để lại vừa tốn dung lượng, vừa là lỗ hổng bảo mật nếu ai đó đoán đúng đường dẫn.
Cách 2 — Qua FTP/SFTP (khi File Manager bị giới hạn):
- Dùng phần mềm FTP client, kết nối bằng host/user/password do nhà cung cấp hosting cấp. Ưu tiên SFTP (port 22) thay vì FTP thường (port 21) vì FTP truyền mật khẩu dạng plain text.
- Bật tuỳ chọn hiển thị file ẩn trong phần mềm (với FileZilla: Server → Force showing hidden files).
- Kéo toàn bộ
public_htmlvề thư mục local. Lưu ý: cách này chậm hơn nhiều so với nén-rồi-tải, đặc biệt với site có hàng chục nghìn file trong uploads.
Lưu ý thực chiến: Nếu website nặng trên 2GB, cPanel có thể timeout khi nén. Khi đó hãy nén theo từng phần: nén riêng wp-content/uploads, rồi nén phần còn lại.
A2. Export database qua phpMyAdmin
- Xác định đúng database. Mở
wp-config.php, tìm dòngdefine('DB_NAME', '...'). Đây là bước bắt buộc nếu host của bạn chứa nhiều website — export nhầm database là lỗi rất phổ biến. - Vào cPanel → phpMyAdmin → chọn đúng tên database ở cột trái.
- Chọn tab Export → chế độ Custom (không dùng Quick).
- Tick chọn tất cả bảng. Nếu site dùng nhiều plugin cache, bạn có thể bỏ qua các bảng transient tạm, nhưng với người mới thì cứ lấy hết cho an toàn.
- Ở mục Output, chọn nén zipped hoặc gzipped để giảm dung lượng file .sql.
- Ở mục Format-specific options, đảm bảo bật Add DROP TABLE / CREATE TABLE — nếu không, khi restore vào database đã có bảng cũ sẽ báo lỗi trùng.
- Nhấn Export và đặt tên đồng bộ với file source:
tenweb-db-2026-07-15.sql.gz.
A3. Cách nhanh nhất cho người có SSH: WP-CLI
Nếu hosting cho phép truy cập SSH, toàn bộ quy trình trên rút gọn còn hai dòng lệnh — cực kỳ hữu ích khi bạn quản trị nhiều website:
Sau đó tải file .tar.gz về máy và xoá bản trên server. Tài liệu lệnh đầy đủ có tại trang tài liệu chính thức của WP-CLI.
Luồng B — Backup tự động (lưới an toàn chạy nền)
Backup thủ công có một điểm yếu chết người: nó phụ thuộc vào trí nhớ con người. Luồng B loại bỏ yếu tố đó. Có ba tầng tự động hoá, và bạn nên hiểu rõ giới hạn của từng tầng.
B1. Tầng plugin — linh hoạt nhất, phổ biến nhất
Đây là lựa chọn thực tế cho hầu hết website doanh nghiệp. Nguyên tắc cấu hình một plugin backup đúng cách, bất kể bạn dùng công cụ nào:
- Tách lịch file và lịch database. Database thay đổi mỗi ngày (bài viết, đơn hàng, bình luận) nên cần backup dày hơn. File thay đổi ít hơn nhiều — thường chỉ khi update plugin/theme hoặc upload ảnh mới.
- Bắt buộc gửi ra remote storage. Trỏ đích lưu trữ về cloud storage hoặc một server riêng. Nếu để mặc định, plugin sẽ lưu ngay trong wp-content — vi phạm số “1” của quy tắc 3-2-1.
- Đặt số bản lưu trữ (retention). Giữ tối thiểu 7–14 bản. Lý do: ransomware và mã độc thường ủ bệnh nhiều ngày trước khi phát tác. Nếu chỉ giữ 2 bản gần nhất, cả hai đều đã nhiễm.
- Bật email báo cáo kết quả. Một backup lỗi mà không ai biết còn nguy hiểm hơn không có backup, vì nó tạo cảm giác an toàn giả.
- Tự động backup trước khi update. Một số plugin hỗ trợ tính năng này — bật lên và bạn gần như đã tự động hoá luôn Luồng A.
Các plugin được cộng đồng dùng nhiều nhất có thể tham khảo trong thư viện plugin backup trên WordPress.org — nên ưu tiên plugin còn cập nhật trong 3 tháng gần nhất và tương thích phiên bản WordPress bạn đang chạy.
B2. Tầng hosting — tiện nhưng đừng phụ thuộc hoàn toàn
Hầu hết nhà cung cấp hosting đều quảng cáo “backup tự động hàng ngày”. Trước khi tin, hãy hỏi họ bốn câu:
- Backup được lưu trên cùng server hay ở hệ thống lưu trữ tách biệt?
- Giữ được bao nhiêu bản và bao nhiêu ngày?
- Tôi có thể tự tải bản backup về hay phải gửi ticket nhờ khôi phục?
- Khôi phục có tính phí không, và mất bao lâu?
Nếu câu trả lời cho câu 1 là “cùng server” và câu 3 là “phải gửi ticket”, thì backup của hosting chỉ nên xem là lớp bổ sung, không phải lớp phòng thủ chính. Bạn vẫn cần một bản độc lập nằm trong tầm kiểm soát của mình.
B3. Tầng cron server — dành cho VPS và site lớn
Với VPS hoặc site có lượng dữ liệu lớn, chạy cron ở tầng hệ điều hành ổn định hơn plugin PHP (vốn hay bị timeout với site nặng). Ví dụ một cron job export database mỗi 3 giờ sáng:
Tần suất backup nên đặt bao nhiêu?
Không có con số chung. Tần suất đúng được quyết định bởi một câu hỏi duy nhất: bạn chấp nhận mất bao nhiêu dữ liệu? Nếu website tạo ra 20 đơn hàng mỗi ngày, backup hàng tuần nghĩa là bạn chấp nhận mất tới 140 đơn.
| Loại website | Database | File | Giữ lại |
|---|---|---|---|
| Landing page, site giới thiệu tĩnh | Hàng tuần | Hàng tháng | 4 bản |
| Website doanh nghiệp có blog | Hàng ngày | Hàng tuần | 14 bản |
| Tin tức, site đăng bài liên tục | 2 lần/ngày | Hàng tuần | 30 bản |
| WooCommerce, có giao dịch | Mỗi 2–6 giờ | Hàng ngày | 30 bản |
Ngoài lịch định kỳ, luôn thực hiện một bản backup thủ công ngay trước bốn thời điểm: cập nhật core WordPress, cài/gỡ plugin lớn, đổi theme, và chuyển hosting hoặc domain.
Diễn tập phục hồi: bước quyết định bản backup có thật hay không
Nguyên tắc nghề: Bạn không có backup cho tới khi bạn đã restore thành công một lần. Trước đó, cái bạn có chỉ là một file nén và một niềm tin.
Rất nhiều đơn vị chỉ phát hiện file .sql bị cắt cụt, hoặc thiếu thư mục uploads, đúng vào lúc website đã sập và không còn đường lui. Hãy chủ động kiểm chứng theo quy trình sau, tối thiểu một lần mỗi quý:
- Dựng môi trường staging. Dùng subdomain kiểu
test.tenweb.vnhoặc cài WordPress trên localhost. Tuyệt đối không test trên site đang chạy. - Giải nén source code vào thư mục gốc của staging.
- Tạo database rỗng, sau đó vào phpMyAdmin → tab Import → chọn file .sql đã export.
- Sửa
wp-config.phptrỏ về thông tin database mới (DB_NAME, DB_USER, DB_PASSWORD). - Đổi URL trong database. Đây là bước hay gây “vỡ” site nhất. Không dùng lệnh Find & Replace thô trong phpMyAdmin vì sẽ làm hỏng dữ liệu serialize của theme và plugin. Dùng lệnh WP-CLI an toàn:
wp search-replace 'https://tenweb.vn' 'https://test.tenweb.vn' --all-tables - Kiểm tra 5 điểm: trang chủ hiển thị đúng layout — đăng nhập wp-admin được — hình ảnh trong bài viết còn hiện — menu và permalink hoạt động — với site bán hàng: mở được danh sách đơn hàng cũ.
Đủ 5 điểm trên là bản backup của bạn đã được chứng thực. Ghi lại ngày test vào file log — đó là bằng chứng vận hành, và cũng là thứ đầu tiên một đơn vị dịch vụ chăm sóc website chuyên nghiệp sẽ hỏi khi tiếp nhận bàn giao.
7 sai lầm khiến bản backup trở nên vô dụng
Checklist vận hành backup hàng tháng
In ra hoặc lưu vào lịch làm việc. Toàn bộ quy trình chỉ mất khoảng 15 phút mỗi tháng:
- ☐ Mở email báo cáo của plugin backup — xác nhận 30 ngày qua không có lần nào lỗi.
- ☐ Đăng nhập cloud storage — kiểm tra dung lượng file có bất thường không (file nhỏ đột ngột = backup lỗi).
- ☐ Tải ngẫu nhiên 1 bản backup về máy, giải nén thử xem file có toàn vẹn.
- ☐ Xác nhận có ít nhất 1 bản nằm ngoài hosting (quy tắc 3-2-1).
- ☐ Dọn các bản backup cũ vượt quá số lượng retention đã đặt.
- ☐ Mỗi quý: chạy đủ quy trình diễn tập phục hồi trên staging và ghi ngày test vào log.
Câu hỏi thường gặp về backup website WordPress
Backup website WordPress có làm website chậm đi không?
Có, nhưng chỉ trong thời gian tiến trình chạy. Việc nén file và export database tiêu tốn CPU cùng bộ nhớ của server. Giải pháp là đặt lịch vào khung giờ thấp điểm (2–4 giờ sáng) và với site nặng thì tách backup file ra khỏi backup database để mỗi tiến trình nhẹ hơn.
Nên lưu bản sao lưu website ở đâu là an toàn nhất?
Nguyên tắc là tách khỏi hạ tầng đang chạy website. Kết hợp một dịch vụ lưu trữ đám mây (dung lượng lớn, truy cập mọi lúc) với một bản trên ổ cứng ngoài của bạn (không phụ thuộc internet, không thể bị tấn công qua mạng). Điều cần tránh tuyệt đối là để mọi bản sao trong cùng tài khoản hosting.
Website đã sập rồi, chưa từng backup thì làm sao?
Ưu tiên theo thứ tự: liên hệ hosting hỏi bản snapshot phía họ; kiểm tra Google Cache hoặc các dịch vụ lưu trữ web để lấy lại nội dung bài viết; kiểm tra thư mục cũ hoặc bản staging còn sót trên server. Đây là quy trình chữa cháy tốn kém và không đảm bảo lấy lại được đơn hàng hay bình luận — lý do vì sao backup luôn rẻ hơn khôi phục.
Backup thủ công và tự động, chọn cái nào nếu chỉ được chọn một?
Chọn tự động. Lý do đơn giản: quy trình phụ thuộc trí nhớ con người sẽ thất bại sau vài tuần bận rộn. Nhưng ngay cả khi đã có backup tự động, bạn vẫn nên bấm backup thủ công trước mỗi lần update lớn — vì đó chính xác là thời điểm rủi ro cao nhất.
Có cần backup cả thư mục uploads khi nó nặng vài GB không?
Có, nhưng không cần backup toàn bộ mỗi ngày. Thư mục uploads chỉ thay đổi khi bạn thêm ảnh mới, nên phù hợp với backup gia tăng (incremental) hoặc lịch hàng tuần. Nếu bỏ hẳn phần này, mọi hình ảnh trong bài viết sẽ vỡ sau khi khôi phục — và đó là dữ liệu không thể tái tạo từ bất kỳ nguồn nào.
Việc cần làm ngay hôm nay cho website của bạn
Backup không phải một dự án lớn cần lên kế hoạch hàng tháng. Nó là một quy trình nhỏ, làm đúng một lần rồi để nó tự chạy. Nếu bạn chỉ có 30 phút, hãy làm theo thứ tự này: (1) tải một bản thủ công đầy đủ ngay bây giờ để có mốc an toàn; (2) cài và cấu hình một plugin backup tự động, trỏ đích lưu trữ ra ngoài hosting; (3) đặt lịch nhắc trên calendar để restore thử vào cuối quý.
Ba việc đó đủ để bạn không bao giờ phải trải qua kịch bản 3 giờ sáng ở đầu bài viết. Nếu website của bạn đang chạy quảng cáo, có đơn hàng hoặc đang xếp hạng tốt trên Google, thì mỗi giờ downtime đều có giá — và cái giá đó luôn cao hơn chi phí phòng ngừa.
Không có thời gian tự vận hành backup?
IT GROUP triển khai lịch sao lưu tự động, lưu trữ tách biệt khỏi hosting, giám sát cảnh báo lỗi và diễn tập phục hồi định kỳ — trọn gói trong dịch vụ chăm sóc website. Bạn tập trung vào kinh doanh, phần hạ tầng để chúng tôi lo.
Đọc tiếp trong chuỗi bài về vận hành website
