Backup WordPress cần giữ những gì? Kiểm kê từ wp-content, MariaDB đến cấu hình VPS

Một bộ Backup WordPress đúng nghĩa phải là chiếc phao cứu sinh trọn gói: có đủ cơ sở dữ liệu MariaDB, cây thư mục mã nguồn ứng dụng và các tệp cấu hình hệ thống để dựng lại dịch vụ từ đống tro tàn. Nhiều anh em mới vào nghề cứ nghĩ kéo mỗi thư mục uploads về máy là xong — cách đó giữ được ảnh đẹp đấy, nhưng toàn bộ bài viết, tài khoản và đơn hàng trong Database thì bay sạch; ngược lại, nén cả thư mục web mà quên xuất SQL thì mở trang lên cũng chỉ thấy màn hình cài đặt mới tinh. Trước khi bàn đến chuyện chọn tool sao lưu tự động xịn cỡ nào, hãy cùng ngồi xuống kiểm kê chính xác những mảnh ghép bắt buộc phải giữ lại qua bài thực hành này.

Ở phần cuối bài viết, chúng tôi đính kèm biên bản kiểm kê thực tế trên bản clone của máy chủ LAB-CF-02 vào ngày 01/10/2026 với từng con số file và bảng dữ liệu cụ thể. Để tự lập danh mục tài sản cho chính mình, bạn hãy thử tưởng tượng một kịch bản hơi rùng mình: sáng mai thức dậy thấy thư mục website trống trơn, vậy bạn sẽ lôi bài viết, hình ảnh, bộ theme đã dày công tùy biến và chuỗi kết nối Database từ đâu ra? Từng món đồ đó đều phải có chỗ cất bản sao rõ ràng, có người nắm chìa khóa lấy về và có phương pháp đối chiếu độ toàn vẹn. Dòng chữ quảng cáo “Có Backup tự động hằng ngày” trên trang bán dịch vụ hosting hoàn toàn không trả lời giúp bạn những chi tiết sống còn ấy đâu.

Điều kiện để thực hành đúng phạm vi

Bài viết này được thiết kế nối tiếp cho những bạn đã đi qua lộ trình WordPress trên VPS từ A đến Z và đang nắm quyền quản trị một máy chủ lab độc lập. Cấu hình tiêu chuẩn trong bài sử dụng Ubuntu 24.04 LTS, Nginx, PHP 8.3 và MariaDB 10.11. Trước khi gõ bất kỳ câu lệnh nào, hãy dành một phút đối chiếu phiên bản phần mềm, tên tiến trình dịch vụ (service) và đường dẫn thư mục trên máy thử nghiệm của bạn, bởi mỗi môi trường thực tế có thể khác biệt đôi chút.

Nguyên tắc an toàn trên hết: luôn thao tác với bộ dữ liệu mẫu, sử dụng tài khoản người dùng tách biệt và đặt thư mục làm việc cách ly hoàn toàn khỏi vùng dữ liệu đang chạy thật. Hãy thay thế các biến viết hoa trong bài bằng đường dẫn đã xác minh trên lab của bạn; tuyệt đối không lưu mật khẩu hay thông tin nhạy cảm vào lịch sử dòng lệnh (shell history) hoặc đẩy lên kho chứa code (Git repository). Nếu gõ lệnh mà gặp thông báo “command not found”, đừng vội hoảng hốt tưởng website sập — đó chỉ là lời nhắc bạn cần cài đặt thêm công cụ từ kho gói chính thức mà thôi. Các sơ đồ minh họa dưới đây đóng vai trò dẫn đường về mặt tư duy, không dùng để thay thế ảnh chụp kết quả thực nghiệm.

Minh họa kiến trúc 1: bốn lớp dữ liệu cần bảo vệ. Sơ đồ do đội ngũ localhost.vn biên soạn để tóm tắt khái niệm; không phải ảnh chụp màn hình hay số liệu trích xuất từ máy lab.

Tách dữ liệu gốc khỏi thứ có thể tạo lại

Để không biến kho Backup thành bãi rác khổng lồ, bạn cần phân biệt rạch ròi giữa “dữ liệu gốc độc bản” và “dữ liệu phái sinh có thể tái tạo”. Toàn bộ nội dung bài viết, bình luận của độc giả, danh sách người dùng, bảng cấu hình wp_options và dữ liệu nghiệp vụ của plugin đều nằm gọn trong cơ sở dữ liệu MariaDB. Trong khi đó, bản thân các bức ảnh hay tệp tài liệu PDF lại nằm dưới dạng file vật lý trong thư mục wp-content/uploads; những dòng bản ghi attachment trong Database thực chất chỉ là tấm thẻ thư viện ghi đường dẫn và thông tin mô tả cho các file ấy. Ngoài ra, hãy giữ gìn cẩn thận đúng phiên bản của child theme, các plugin tự viết riêng và thư mục mu-plugins. Riêng bộ mã nguồn lõi (WordPress core) thì bạn có thể tải lại từ trang chủ bất cứ lúc nào, nhưng vẫn bắt buộc phải ghi chép rõ số phiên bản đang chạy để phòng khi cần dựng lại môi trường y hệt lúc điều tra sự cố.

Ngược lại, các thư mục bộ nhớ đệm (cache) sinh ra trong quá trình vận hành thường có thể xóa đi và tự tạo mới lại sau khi Restore xong. Tuy nhiên, hãy cẩn trọng: chỉ đưa một thư mục vào danh sách loại trừ (exclude list) khi bạn hiểu rõ cấu trúc của plugin đó, tuyệt đối không nhắm mắt bỏ qua mọi thư mục có chữ “cache” trong tên nếu chưa chắc chắn plugin có tận dụng nơi đó để cất dữ liệu cấu hình gốc hay không. Cuối cùng, đừng quên liệt kê vào danh sách bảo vệ cả những tệp cấu hình nằm bên ngoài webroot như server block của Nginx, cấu hình pool PHP-FPM và các lịch trình cronjob hệ thống.

Lập danh mục bằng lệnh chỉ đọc

Hãy gán biến môi trường WP_ROOT trỏ tới đúng đường dẫn cài đặt WordPress trên máy lab mà bạn đã xác minh. Một nguyên tắc bảo mật cơ bản là không bao giờ dùng lệnh cat để in toạc toàn bộ nội dung file wp-config.php lên màn hình terminal, bởi bên trong đó chứa cả mật khẩu Database lẫn bộ khóa muối (AUTH_KEY, SECURE_AUTH_KEY) cực kỳ nhạy cảm.

: "${WP_ROOT:?Đặt đường dẫn WordPress lab}"
test -f "$WP_ROOT/wp-load.php" || exit 1
find "$WP_ROOT/wp-content" -maxdepth 1 -type d
wp --path="$WP_ROOT" core version
wp --path="$WP_ROOT" plugin list --fields=name,status,version
wp --path="$WP_ROOT" theme list --fields=name,status,version
wp --path="$WP_ROOT" db tables

Hãy cài đặt công cụ WP-CLI và thực thi dưới quyền của tài khoản hệ thống đang sở hữu mã nguồn website. Nếu câu lệnh kiểm tra đầu tiên không tìm thấy tệp wp-load.php, khối lệnh sẽ tự động phanh gấp để bạn rà soát lại đường dẫn. Lưu ý rằng nhiều plugin phức tạp (như thương mại điện tử, SEO hay bảo mật) thường tự tạo thêm các bảng riêng nằm ngoài 12 bảng mặc định của WordPress; hãy ghi chép đầy đủ tên bảng và plugin chủ quản của chúng vào sổ tay, tuyệt đối không tự ý xóa bớt những bảng lạ mặt chỉ vì muốn danh sách trông gọn gàng hơn.

Minh họa kiến trúc 2: thế nào là một bộ Backup nhất quán. Sơ đồ do localhost.vn thiết kế; không phải ảnh chụp thực nghiệm trên máy chủ lab.

Ghép file và database thành một bộ có thời điểm

Một bộ sao lưu chuyên nghiệp luôn đi kèm tệp hồ sơ (manifest) ghi nhận rõ mốc thời gian chuẩn UTC, phiên bản phần mềm, vị trí lưu trữ gói nén archive cùng bản xuất SQL và chuỗi mã băm Checksum tương ứng. Khi tiến hành chụp Backup trên môi trường lab, bạn nên tạm ngưng mọi hoạt động biên tập bài viết, tải ảnh mới hay chạy các tiến trình nhập liệu. Hãy hình dung cảnh lệch pha thế này: nếu bạn đóng gói thư mục uploads lúc 02:00, nhưng đến 02:02 biên tập viên tải lên một bức ảnh mới rồi lúc 02:05 bạn mới xuất Database SQL, thì trong bản SQL sẽ có dòng bản ghi trỏ tới bức ảnh kia nhưng trong gói nén file lại chẳng thấy ảnh đâu — kết quả là khi Restore sẽ hiện ra một ô ảnh vỡ đầy ngượng ngùng.

Với những website thương mại có đơn hàng đổ về liên tục 24/7, bài toán đảm bảo tính nhất quán (consistency) cần được thiết kế kỹ lưỡng hơn nhiều. Việc bật một trang thông báo “Website đang bảo trì” ở tầng giao diện hoàn toàn không tự động khóa mõm các luồng webhook thanh toán từ ngân hàng gọi về, không dừng các tiến trình WP-Cron ngầm hay hàng đợi xử lý nền (queue workers). Chỉ gõ hai câu lệnh tar và mysqldump nối đuôi nhau chưa thể biến chúng thành một bản Snapshot giao dịch đồng bộ cho toàn bộ hệ thống; bạn bắt buộc phải điểm mặt chỉ tên và kiểm soát từng nguồn có khả năng ghi dữ liệu trong suốt khung giờ đóng gói.

Giữ cấu hình an toàn và ghi phụ thuộc bên ngoài

Hãy luôn nhớ rằng cả tệp wp-config.php lẫn bản xuất .sql đều là những kho chứa thông tin nhạy cảm bậc nhất của hệ thống. Bạn phải cất giữ chúng ở thư mục tách biệt hoàn toàn khỏi webroot, khóa chặt quyền truy cập hệ thống tệp (chỉ cho phép chủ sở hữu đọc) và thực hiện mã hóa (encryption) trước khi đẩy bản sao lưu ra khỏi biên giới VPS. Đặc biệt, chìa khóa giải mã (decryption key / passphrase) phải được cất giữ ở một kho quản lý bí mật độc lập; nếu lưu khóa giải mã nằm chung một chỗ với máy chủ thì khi mất máy là mất trắng, còn nếu làm thất lạc khóa thì file Backup đã mã hóa kia cũng chỉ là một cục gạch kỹ thuật số không hơn không kém.

Một điểm mù khác mà nhiều người hay quên: câu lệnh tar đóng gói thư mục WordPress hoàn toàn không có phép thuật để sao lưu hộ bạn các bản ghi DNS trên Cloudflare, cấu hình CDN, dịch vụ gửi email SMTP/API, chứng chỉ bảo mật SSL/TLS, kho lưu trữ ảnh trên Object Storage (S3/R2) hay cấu hình cổng thanh toán. Hãy lập một danh sách riêng ghi rõ tên nhà cung cấp dịch vụ, người đang đứng tên tài khoản quản lý và quy trình khôi phục quyền truy cập (nhưng tuyệt đối không viết thẳng chuỗi API token vào file manifest). Miễn là bạn còn giữ quyền kiểm soát tên miền thì việc cấp phát lại chứng chỉ SSL không khó, nhưng kế hoạch khôi phục thảm họa (Disaster Recovery) vẫn phải tính toán đủ thời gian chờ xác thực đó.

Kiểm kết quả và giới hạn kết luận

Sau khi lập xong danh mục kiểm kê, hãy làm một bài kiểm tra chéo đơn giản: thử đăng một bài viết mới, tải lên một tấm ảnh, thay đổi một thiết lập trong plugin và chỉnh sửa nhẹ giao diện theme, rồi tự hỏi xem từng thay đổi đó sẽ nằm ở tệp nào trong bộ Backup. Chỉ khi mọi mảnh ghép đều có nơi lưu trữ xác định, có lịch sao lưu rõ ràng và có hướng dẫn khôi phục tương ứng thì khâu kiểm kê tài sản mới coi như hoàn thành. Bước tiếp theo ở các bài sau sẽ là mang chính bộ file đó đi dựng lại thành một website sống động để nghiệm thu chức năng. Mẹo nhỏ: nếu thấy dung lượng gói Backup hôm nay tăng vọt hoặc tụt giảm bất thường so với hôm qua, hãy bình tĩnh kiểm tra xem trên web vừa có đợt đăng tải hay dọn dẹp nội dung nào không trước khi vội kết luận công cụ sao lưu bị lỗi.

Minh họa kiến trúc 3: bốn điều kiện tiên quyết để khôi phục thành công. Sơ đồ do localhost.vn biên soạn; không phải ảnh chụp màn hình hay dữ liệu thực nghiệm trên lab.

Ví dụ kiểm kê và ghép bộ backup trên lab

Trong khung thời gian từ 02:16:14 đến 02:16:51 ngày 01/10/2026 (giờ Việt Nam), chúng tôi đã thực hiện một đợt kiểm kê thực tế trên bản clone của máy chủ LAB-CF-02. Hệ thống WordPress phiên bản 7.1.2 lúc ấy ghi nhận bức tranh hiện trạng như sau trước khi chúng tôi chèn thêm các tệp gắn nhãn thử nghiệm:

Do bản clone ban đầu chưa chứa tệp hình ảnh nào, chúng tôi đã chủ động tạo thêm hai tệp gắn nhãn rõ ràng: một tệp ẩn (dotfile) đặt ngay thư mục gốc và một tệp văn bản thuần túy nằm trong nhánh uploads. Mục đích của hai tệp này là để kiểm chứng khả năng đóng gói đường dẫn tương đối và tệp ẩn của công cụ nén, chứ không phải là ảnh chụp hay bản ghi attachment thật của WordPress. Khi tiến hành giải nén thử, toàn bộ đường dẫn và mã băm SHA-256 của cả 4.012 tệp bên trong gói archive đều khớp tuyệt đối với nguồn. Ngay sau khi hoàn tất đối chiếu, hai tệp gắn nhãn thử nghiệm này đã được dọn dẹp sạch sẽ khỏi bản clone.

Bộ sao lưu được giữ lại sau đợt chạy gồm gói nén archive nặng 42.777.312 byte, bản xuất SQL nặng 120.242 byte, tệp chứa mã băm Checksum và tệp hồ sơ manifest. Toàn bộ được cất giữ ở một thư mục nằm ngoài webroot trên cùng máy chủ VPS, với quyền truy cập thư mục khóa ở mức 700 và quyền từng tệp khóa ở mức 600. Cần nói rõ: việc khóa quyền 700/600 chỉ giúp ngăn chặn truy cập trái phép giữa các người dùng trên cùng hệ điều hành, chứ chưa phải là giải pháp mã hóa dữ liệu hay sao lưu ngoài máy (offsite). Bản SQL được xuất ra bằng WP-CLI trong cùng một cửa sổ thời gian nhưng ở bước này vẫn chưa được nạp ngược vào MariaDB để kiểm tra.

Như vậy, đợt thực nghiệm lúc 02:16 đã hoàn thành nhiệm vụ định danh đầy đủ các thành phần cần thu thập và xác minh tính toàn vẹn của gói nén archive. Vì lý do bảo mật, chúng tôi không đăng tải nguyên văn nội dung tệp SQL, gói nén hay tệp cấu hình lên bài viết. Khi áp dụng vào thực tế, danh mục khôi phục của bạn vẫn bắt buộc phải ghi chép riêng phần cấu hình Nginx/PHP-FPM, quyền quản lý tên miền và các dịch vụ phụ thuộc bên ngoài, bởi lệnh tar gom cây thư mục WordPress hoàn toàn không tự động chạm tới những vùng đó.

Trước đó, vào ngày 30/09/2026, một đợt diễn tập Restore độc lập đã sử dụng cặp lệnh export/import của WP-CLI, đối chiếu khớp hai chuỗi SHA-256, xác nhận đủ 12 bảng dữ liệu, hai bài viết đã xuất bản và cấu trúc đường dẫn tĩnh (permalink). Biên bản hôm ấy xác nhận việc khôi phục và cô lập quyền Database trên cùng máy chủ VPS đã thành công. Tuy nhiên, kết quả của bộ sao lưu ngày 30/09 không thể dùng để bảo chứng tự động cho bộ sao lưu mới tạo ngày 01/10 khi chưa chạy thử import, và càng không chứng minh được khả năng khôi phục từ kho offsite, từ Snapshot nhà cung cấp hay tổng thời gian cứu hộ khi sập toàn bộ máy chủ.

Rà soát danh mục và bộ đã lưu lúc 11:31–11:33

Đợt rà soát định kỳ diễn ra lúc 11:31:55–11:32:02 ngày 01/10/2026 (UTC+7) một lần nữa xác nhận bản clone vẫn đang chạy WordPress 7.1.2 với đúng 4.010 tệp tin, 12 bảng dữ liệu và 2 bài viết đã xuất bản; số lượng tệp trong thư mục uploads cũng như bản ghi attachment trong Database đều giữ nguyên ở mức 0. Hai plugin đi kèm là Akismet 5.7.2 và Hello 1.7.2 đều đang ở trạng thái tắt (inactive), trong khi giao diện Twenty Twenty-Five 1.5 đang hoạt động. Hai công cụ đóng gói trên hệ thống là tar 1.35 và gzip 1.12. Mã băm của cả hai tệp cấu hình WordPress trên máy không hề thay đổi.

Ảnh chụp màn hình console thực tế lúc 11:32:19 ngày 01/10/2026 (UTC+7), giữ nguyên toàn bộ pixel gốc và chỉ chèn thêm logo nhận diện. Kịch bản hỗ trợ chạy trực tiếp từ 11:31:55 đến 11:32:02 để in ra bảng tổng hợp kiểm kê; lưu ý mốc thời gian hiển thị trong cửa sổ lệnh tính theo chuẩn UTC (chậm hơn giờ Việt Nam 7 tiếng). Đây là kết quả đầu ra của script tự động chứ không phải ảnh chụp gõ tay từng lệnh rời rạc. Bạn có thể bấm vào ảnh để xem rõ từng dòng.

Ngay sau đó, trong khung 11:33:10–11:33:16, chúng tôi tiến hành thẩm định lại chính bộ sao lưu đã cất giữ từ lúc 02:16 rạng sáng mà không tạo thêm gói Backup mới:

Ảnh chụp console thực tế lúc 11:33:45 ngày 01/10/2026 (UTC+7), giữ nguyên độ phân giải gốc kèm logo. Các dấu thời gian 04:33:10–16 UTC trên màn hình chính là đợt chạy thẩm định và giải nén thử trực tiếp lúc 11:33:10–16 giờ Việt Nam; hình ảnh hiển thị bảng tóm tắt kết quả thay vì in tràn lan hàng nghìn dòng đầu ra của lệnh tar. Bấm vào ảnh để xem kích thước đầy đủ.

Một chi tiết thú vị dành cho những ai tinh mắt: gói archive giải nén ra có 4.012 tệp bởi vì lúc đóng gói hồi 02:16 nó có chứa hai tệp gắn nhãn thử nghiệm (vốn đã được xóa khỏi bản clone ngay sau đó), nên con số này hoàn toàn khớp logic chứ không hề mâu thuẫn với trạng thái 4.010 tệp hiện tại của cây thư mục đang chạy. Đợt thẩm định lúc 11:33 làm nhiệm vụ đối chiếu kết quả giải nén với gói archive gốc, chứ không so sánh ngược với cây thư mục đang sống. Do bước này chưa nạp tệp SQL vào MariaDB và chưa cấu hình Nginx/PHP-FPM để chạy thử bản giải nén, chúng ta chỉ mới xác nhận tính toàn vẹn của tệp lưu trữ chứ chưa nghiệm thu chức năng ứng dụng, mã hóa hay quy trình offsite.

Khi gặp lỗi và cách xử lý an toàn

Nếu trong lúc kiểm kê bạn phát hiện bộ sao lưu bị thiếu mất tệp SQL dump, đừng chắp vá bằng cách lấy đại một bản SQL của ngày hôm sau ghép vào — hãy trích xuất bổ sung ngay trong cùng một cửa sổ dữ liệu hoặc thực hiện lại trọn bộ cả file lẫn Database để đảm bảo tính đồng bộ. Nếu phát hiện thiếu mã nguồn theme/plugin tùy biến, hãy truy tìm ngay trong kho quản lý mã nguồn (Git) và đối chiếu đúng nhãn phiên bản (tag/release) đang chạy. Bản thân thao tác kiểm kê trong bài hoàn toàn ở chế độ chỉ đọc (read-only) nên không làm xáo trộn dịch vụ đang hoạt động. Trong trường hợp phát hiện một gói Backup bị lỗi hoặc thiếu hụt thành phần, kinh nghiệm xương máu là hãy gắn nhãn cảnh báo “DO_NOT_RESTORE” cho thư mục đó rồi tạo một bộ mới tinh ở thư mục khác để giữ lại hiện trường phục vụ điều tra, thay vì hấp tấp xóa đè ngay lập tức.

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

Chỉ backup uploads có đủ không?

Hoàn toàn không đủ. Thư mục uploads chỉ giữ lại các tệp hình ảnh và tài liệu vật lý, nhưng toàn bộ bài viết, mối liên kết giữa bài viết với bức ảnh (bản ghi attachment), cấu hình hệ thống và tài khoản người dùng đều nằm trong cơ sở dữ liệu MariaDB.

Có cần backup cache không?

Thông thường dữ liệu bộ nhớ đệm (cache) có thể tự tái tạo lại sau khi khôi phục website. Tuy nhiên, trước khi đưa một thư mục vào danh sách loại trừ, hãy xác minh thật kỹ đường dẫn để chắc chắn rằng không có plugin nào đang tiện tay lưu cấu hình gốc hoặc dữ liệu quan trọng chung vào thư mục đó.

Có nên gửi SQL cho người hỗ trợ?

Tuyệt đối không nên tùy tiện gửi nguyên tệp SQL dump gốc cho bên thứ ba. Bên trong bản xuất cơ sở dữ liệu chứa đầy thông tin cá nhân của người dùng, địa chỉ email, chuỗi băm mật khẩu và cả API secret của các plugin thanh toán; hãy chỉ cung cấp bộ dữ liệu mẫu trên môi trường lab hoặc bản dump đã được ẩn danh hóa (anonymized/sanitized) đúng chuẩn.

Việc nên làm tiếp

Bây giờ, bạn hãy bắt tay vào lập danh mục kiểm kê thực tế cho trang lab của mình: từ cơ sở dữ liệu MariaDB, thư mục uploads, các đoạn mã tùy chỉnh, tệp cấu hình hệ thống cho đến quyền truy cập kho lưu trữ. Với từng hạng mục trong bảng, hãy ghi chú rõ đường dẫn tệp sao lưu hoặc phương án khôi phục tương ứng. Sau đó, hãy khóa cửa sổ ghi dữ liệu, xuất tệp SQL và đóng gói archive dưới cùng một nhãn thời gian rồi kiểm tra mã băm Checksum. Khi đã có bộ sao lưu chuẩn chỉnh trong tay, hãy tiến tới các bài tiếp theo trong series WordPress từ A đến Z để diễn tập dựng lại website và kiểm chứng chức năng thực tế.

Nguồn và trạng thái kiểm chứng

Đối chiếu tài liệu ngày 01/10/2026: tài liệu quản trị chính thức của WordPress luôn phân tách rõ hai trụ cột bắt buộc trong mọi bộ sao lưu là hệ thống tệp (files) và cơ sở dữ liệu (database). Toàn bộ số liệu thực nghiệm trình bày ở trên phản ánh đúng kết quả và giới hạn phạm vi của từng đợt chạy trên máy lab; riêng bước kiểm kê và giải nén tệp chưa thể thay thế cho bài nghiệm thu khôi phục toàn diện ứng dụng website.

• WordPress: các thành phần backup.