Đóng gói file WordPress bằng tar.gz: Cách kiểm tra Archive, Checksum SHA-256 và giải nén thử

Sử dụng công cụ tar truyền thống để đóng gói hệ thống tệp WordPress mang lại cho người quản trị một cảm giác làm chủ rất rõ ràng: bạn biết chính xác mình đang gom thư mục nào, bỏ qua thư mục nào và cất gói nén ở đâu trên đĩa. Tuy nhiên, kinh nghiệm xương máu trên chiến trường VPS cho thấy việc câu lệnh tar chạy xong mà không văng lỗi đỏ lòm chưa hề đồng nghĩa với việc bạn đã có một bản sao lưu hoàn hảo: gói archive đó hoàn toàn có thể đang nén nhầm thư mục rỗng, bỏ sót mất nhánh uploads quý giá, hoặc tệ hơn là gom dữ liệu ngay lúc tệp tin đang bị chỉnh sửa dở dang. Chính vì thế, bài viết này sẽ hướng dẫn bạn đi trọn vẹn từ khâu đóng gói chuẩn chỉnh cho tới bước thẩm định gói nén và giải nén thử nghiệm.

Nếu như ở bài 52 trước đó chúng ta đã giải quyết gọn gàng phần cơ sở dữ liệu MariaDB, thì tại đây bạn sẽ đóng gói toàn bộ hệ thống tệp ứng dụng rồi ghép cặp gói .tar.gz với tệp .sql thành một bộ Backup đồng bộ cùng thời điểm. Và xin nhắc lại một nguyên tắc bất di bất dịch: tuyệt đối không bao giờ dùng lệnh tar để nén sống thư mục dữ liệu vật lý của MariaDB khi dịch vụ cơ sở dữ liệu đang chạy!

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

Để bắt đầu thực hành trơn tru, bạn cần đi qua lộ trình cài WordPress trên VPS từ A đến Z và nắm trong tay quyền quản trị một máy chủ lab độc lập. Môi trường mẫu xuyên suốt bài viết chạy trên Ubuntu 24.04 LTS, Nginx, PHP 8.3 và MariaDB 10.11. Đừng quên dành một phút rà soát phiên bản phần mềm, tên service và cấu trúc đường dẫn thực tế trên máy thử nghiệm của bạn trước khi gõ lệnh, bởi mỗi hệ thống thực tế có thể có thiết lập khác nhau.

Hãy chuẩn bị sẵn bộ dữ liệu mẫu, tài khoản người dùng tách biệt và một thư mục làm việc nằm ngoài vùng dữ liệu đang phục vụ người đọc. Các biến môi trường viết hoa trong bài cần được gán bằng đường dẫn đã xác minh trên lab của bạn. Tuyệt đối không để lộ thông tin đăng nhập trong bài viết, lịch sử dòng lệnh (shell history) hay kho chứa Git. Nếu gõ lệnh mà gặp thông báo “command not found”, hãy bình tĩnh đọc tài liệu chính thức để cài đặt công cụ còn thiếu — thông báo đó của shell hoàn toàn không phải lỗi của website. Các sơ đồ dưới đây dùng để minh họa tư duy thao tác, không thay thế cho ảnh chụp màn hình thực nghiệm.

Minh họa kiến trúc 1: nguyên tắc tách biệt giữa thư mục nguồn và kho lưu trữ Backup. Sơ đồ do đội ngũ localhost.vn biên soạn; không phải ảnh chụp màn hình hay số liệu từ máy lab.

Chọn nguồn và nơi chứa không lồng nhau

Trước tiên, hãy xác định biến WP_ROOT trỏ thẳng tới thư mục cài đặt WordPress trên lab (nơi chứa tệp wp-load.php và thư mục wp-content). Ngược lại, thư mục chứa bản sao lưu BACKUP_DIR bắt buộc phải nằm tách biệt hoàn toàn bên ngoài cây thư mục nguồn, nằm ngoài mọi webroot của Nginx và có đủ dung lượng trống cho cả gói nén lẫn bản giải nén thử. Việc tiện tay lưu tệp Backup ngay bên trong thư mục website mang lại hai thảm họa kép: một là lệnh tar sẽ tự cắn đuôi chính mình khi vừa tạo tệp nén vừa đọc lại chính tệp đang phình to đó để nhét vào gói nén; hai là bạn đang dâng không toàn bộ mã nguồn cùng mật khẩu Database trong wp-config.php cho bất kỳ ai đoán trúng đường dẫn tải về qua trình duyệt!

Hãy thiết lập BACKUP_DIR là một tên thư mục con hoàn toàn mới nằm bên trong thư mục cha chuyên chứa Backup đã tạo sẵn, tuyệt đối không dùng chung hay ghi đè lên thư mục của các đợt sao lưu cũ. Trước khi bấm nút chạy, hãy tập thói quen đo lường dung lượng thực tế bằng cặp lệnh du -sh "$WP_ROOT" và df -h "$(dirname "$BACKUP_DIR")". Một kinh nghiệm thực tế rất hay bị bỏ quên: các tệp hình ảnh định dạng JPEG hay WebP trong thư mục uploads vốn dĩ đã là định dạng nén sẵn ở mức cao, nên khi đưa qua bộ lọc gzip chúng hầu như không co nhỏ thêm được bao nhiêu — vì vậy đừng bao giờ tính toán dung lượng ổ đĩa trống dựa trên kỳ vọng rằng gói .tar.gz sẽ nhẹ bằng một phần mười thư mục gốc. Cuối cùng, hãy rà soát quyền đọc trên toàn bộ cây thư mục nguồn, đặc biệt là các tệp cấu hình hoặc những thư mục con do tiến trình khác tạo ra.

Tạo archive với gốc tương đối

Hãy chọn một khung thời gian yên tĩnh trên môi trường lab khi không có ai đang tải ảnh mới lên hay chạy nâng cấp plugin. Sau khi đã xác nhận thư mục cha nằm ngoài vùng phục vụ của web server, chúng ta sẽ dùng lệnh mkdir (chủ đích không truyền cờ -p) để khởi tạo thư mục đích — cách viết này giúp khối lệnh lập tức phanh gấp nếu tên thư mục đó đã vô tình tồn tại từ trước. Đặc biệt, cú pháp truyền dấu chấm . ngay sau cờ chuyển thư mục -C "$WP_ROOT" là tuyệt chiêu giúp tar gom trọn toàn bộ nội dung bên trong (bao gồm cả các tệp ẩn bắt đầu bằng dấu chấm như .htaccess) theo đường dẫn tương đối gọn gàng mà không tạo ra hàng loạt lớp thư mục cha rườm rà.

: "${WP_ROOT:?Chọn nguồn WordPress lab}"
: "${BACKUP_DIR:?Chọn tên thư mục backup mới ngoài webroot}"
WP_ROOT=$(realpath -e -- "$WP_ROOT") || exit 1
test -f "$WP_ROOT/wp-load.php" || exit 1
BACKUP_DIR=$(realpath -m -- "$BACKUP_DIR") || exit 1
case "$BACKUP_DIR/" in
  "$WP_ROOT/"*) echo 'Backup không được nằm trong nguồn' >&2; exit 1 ;;
esac
umask 077
mkdir -m 700 -- "$BACKUP_DIR" || exit 1
if tar -czf "$BACKUP_DIR/wordpress.tar.gz.part" -C "$WP_ROOT" .; then
  mv -- "$BACKUP_DIR/wordpress.tar.gz.part" "$BACKUP_DIR/wordpress.tar.gz" || exit 1
else
  echo 'Tạo archive thất bại; giữ file .part và chọn thư mục mới cho lần thử sau' >&2
  exit 1
fi

Cơ chế phòng vệ của đoạn script trên cực kỳ chặt chẽ: quá trình đóng gói sẽ ghi dữ liệu vào tệp tạm mang đuôi .part trước; chỉ khi câu lệnh tar chạy trơn tru từ đầu đến cuối và trả về mã thoát exit code 0 thì nhánh then mới chính thức đổi tên tệp đó thành wordpress.tar.gz. Việc mỗi lần chạy lại tạo một thư mục mới giúp bạn bảo toàn tuyệt đối các bản sao lưu thành công trước đó. Nếu có bất kỳ bước nào báo lỗi, hãy dừng lại để tìm nguyên nhân gốc rễ chứ đừng vội vàng xóa bản Backup cũ đi để chạy lại. Khi thấy tar phàn nàn bằng dòng chữ kinh điển file changed as we read it, đó là bằng chứng rõ ràng cho thấy hệ thống tệp nguồn vẫn đang bị ghi đè ngay trong lúc đóng gói — bạn cần khóa chặt cửa sổ ghi dữ liệu rồi mới tạo lại bộ mới. Ngoài ra, đừng bao giờ dùng cờ --exclude để loại trừ bừa bãi cả thư mục wp-content, bởi bên trong đó chứa toàn bộ gia tài hình ảnh và giao diện tùy biến không thể tự tái tạo của website.

Minh họa kiến trúc 2: ba tầng thẩm định một gói nén Archive. Sơ đồ do localhost.vn thiết kế; không phải ảnh chụp màn hình hay số liệu từ máy lab.

Ba kiểm tra giải đáp ba câu hỏi khác nhau

Nhiều người thắc mắc tại sao phải làm tới ba bước kiểm tra cho một tệp nén. Câu trả lời rất rõ ràng vì mỗi phép thử giải đáp một câu hỏi kỹ thuật hoàn toàn khác nhau: việc liệt kê danh sách tệp cho biết bên trong gói nén thực sự chứa những gì; lệnh gzip -t rà soát toàn bộ luồng dữ liệu nén từ đầu đến cuối xem có bị cắt cụt hay hỏng cấu trúc nén không; còn mã băm Checksum SHA-256 giúp phát hiện bất kỳ sự biến đổi bit nào xảy ra trong quá trình lưu trữ trên đĩa hoặc truyền tải qua mạng. Và tất nhiên, cả ba phép thử này cộng lại cũng mới chỉ bảo chứng cho phần tệp lưu trữ, chưa thay thế được bước dựng lại và chạy thử ứng dụng WordPress.

tar -tzf "$BACKUP_DIR/wordpress.tar.gz" > "$BACKUP_DIR/file-list.txt" || exit 1
tar -tvzf "$BACKUP_DIR/wordpress.tar.gz" > "$BACKUP_DIR/member-details.txt" || exit 1
gzip -t "$BACKUP_DIR/wordpress.tar.gz" || exit 1
(cd "$BACKUP_DIR" && sha256sum wordpress.tar.gz > wordpress.sha256) || exit 1
(cd "$BACKUP_DIR" && sha256sum -c wordpress.sha256) || exit 1

Sau khi chạy xong khối lệnh trên, bạn hãy mở tệp file-list.txt bằng công cụ less để tìm kiếm sự hiện diện của các thành phần cốt lõi như wp-content/uploads, thư mục theme tùy chỉnh và tệp wp-config.php. Để soi kỹ hơn về kiểu tệp tin, phân quyền và đích trỏ tới của các liên kết, hãy đọc tệp member-details.txt được sinh ra từ lệnh tar -tvzf (bởi danh sách tên đơn thuần từ tar -tzf không cho bạn biết một mục có phải là symlink nguy hiểm hay không). Hãy lập tức dừng tay trước khi giải nén nếu phát hiện bên trong gói archive có chứa đường dẫn tuyệt đối bắt đầu bằng dấu /, chuỗi nhảy thư mục cha .., các liên kết mềm/cứng trỏ ra ngoài hoặc các tệp thiết bị lạ. Việc gắn chốt chặn || exit 1 ở từng câu lệnh đảm bảo rằng lỗi ở bước trước sẽ không bao giờ bị che lấp bởi thành công của câu lệnh phía sau. Cuối cùng, hãy nhớ rằng tệp Checksum đặt nằm cạnh gói archive rất giỏi trong việc phát hiện lỗi hỏng bit ngẫu nhiên (bit rot) hoặc đứt mạng khi tải file, nhưng nó không thể chống lại kịch bản một kẻ tấn công chiếm quyền thư mục và sửa đổi cả gói nén lẫn tệp Checksum cùng lúc — vì vậy kho Backup chuẩn chỉnh luôn cần một hồ sơ manifest được bảo vệ độc lập.

Giải nén thử và rà soát phân quyền sau khôi phục

Bước tiếp theo là mang gói archive mà bạn vừa tạo và thẩm định kỹ lưỡng đi giải nén thử vào một thư mục hoàn toàn mới. Nguyên tắc bảo mật xương máu: luôn đọc trước danh sách đường dẫn và các liên kết symlink bên trong gói nén, và tuyệt đối không bao giờ dùng quyền tối cao root để nhắm mắt giải nén một tệp archive lấy từ nguồn không hoàn toàn tin cậy. Việc thực thi lệnh giải nén dưới quyền của một tài khoản người dùng lab thông thường sẽ đóng khung phạm vi tác động trên hệ thống tệp.

: "${RESTORE_ROOT:?Chọn thư mục mới}"
mkdir -m 700 -- "$RESTORE_ROOT" || exit 1
tar -xzf "$BACKUP_DIR/wordpress.tar.gz" -C "$RESTORE_ROOT" \
  --no-same-owner --no-same-permissions || exit 1
test -f "$RESTORE_ROOT/wp-load.php" || exit 1
test -d "$RESTORE_ROOT/wp-content/uploads" || exit 1

Trong khối lệnh trên, nếu thư mục đích RESTORE_ROOT đã tồn tại từ trước thì lệnh mkdir sẽ báo lỗi và dừng lại ngay để bảo vệ dữ liệu hiện có; bạn chỉ việc chọn một cái tên thư mục mới tinh khác. Lưu ý rằng việc kết hợp thiết lập umask 077 cùng hai cờ --no-same-owner và --no-same-permissions sẽ chủ động bỏ qua thông tin chủ sở hữu và phân quyền cũ trong gói nén, khiến các tệp cấu hình sau khi bung ra có mức phân quyền chặt chẽ hơn (chỉ cho phép người chạy lệnh đọc/ghi). Trong khung thời gian mà thư mục nguồn không có sự thay đổi nào, bạn hãy thử băm mã SHA-256 của một tệp ảnh gốc hoặc tệp tĩnh bất kỳ ở cả hai bên nguồn và đích để thấy chúng khớp nhau từng byte. Trước khi cấu hình cho Nginx và PHP-FPM phục vụ thư mục vừa giải nén này, bạn sẽ cần gán lại quyền sở hữu (owner/group) và quyền đọc theo đúng tài khoản dịch vụ trên máy đích — bởi con số định danh UID/GID lưu trong gói nén từ máy chủ cũ chưa chắc đã khớp với tài khoản dịch vụ trên máy chủ mới.

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

Khâu thẩm định hệ thống tệp sao lưu chỉ được đánh dấu hoàn tất khi bạn đã đọc được danh sách tệp bên trong archive, kiểm tra luồng nén gzip báo đạt, đối chiếu khớp mã băm SHA-256 và giải nén thử thành công các tệp mẫu ra thư mục riêng. Nếu ở thời điểm đó bạn chưa nạp tệp SQL vào MariaDB và chưa mở trang web lên chạy thử, hãy ghi chép thật rạch ròi vào biên bản bàn giao: “Thẩm định gói Archive: ĐẠT” và “Diễn tập Restore ứng dụng WordPress: CHƯA THỰC HIỆN”. Sự minh bạch này giúp người tiếp nhận hệ thống biết chính xác mảnh ghép nào đã được kiểm chứng, tránh ảo tưởng nguy hiểm rằng cứ thấy tải được cục file nén về máy là coi như đã có hệ thống cứu hộ hoàn chỉnh.

Minh họa kiến trúc 3: bốn nguyên tắc an toàn khi giải nén thử nghiệm. Sơ đồ do localhost.vn biên soạn; không phải ảnh chụp màn hình hay số liệu từ máy lab.

Kết quả kiểm archive ngày 01/10/2026

Bản clone trên máy chủ LAB-CF-02 đã được đưa vào thực nghiệm trong khung giờ từ 02:16:14 đến 02:16:51 ngày 01/10/2026 (giờ Việt Nam), sử dụng bộ đôi công cụ chuẩn trên hệ thống là GNU tar 1.35 và gzip 1.12. Trước thời điểm chạy thử, bản clone ghi nhận trạng thái gồm 4.010 tệp tin thông thường, 12 bảng dữ liệu trong MariaDB, hai bài viết đã xuất bản và chưa có bất kỳ tệp nào trong thư mục uploads cũng như bản ghi attachment. Để kiểm tra khả năng gom tệp ẩn và cấu trúc thư mục con, chúng tôi đã chủ động đặt thêm hai tệp gắn nhãn rõ ràng: một tệp ẩn ngay tại thư mục gốc và một tệp văn bản thuần túy bên dưới nhánh uploads (lưu ý hai tệp này phục vụ bài toán kiểm tra đường dẫn đóng gói, không phải là bằng chứng nghiệm thu thư viện ảnh Media Library thực tế của WordPress).

Sau khi bung gói nén, tài khoản thực hành tutorial (mang UID 1000) đứng tên sở hữu toàn bộ cây thư mục đích. Do tác động của thiết lập umask 077 kết hợp cùng cờ không khôi phục phân quyền cũ, tệp wp-config.php chuyển từ chế độ phân quyền 640 ở trang nguồn sang 600 ở thư mục đích. Mã băm nội dung bên trong tệp vẫn trùng khớp tuyệt đối 100%, cho thấy sự thay đổi con số phân quyền này là hành vi bảo mật có chủ đích chứ hoàn toàn không phải lỗi hỏng gói archive. Tất nhiên, bạn sẽ cần rà soát và cấp quyền đọc phù hợp cho tiến trình PHP-FPM trước khi đưa thư mục đó vào chạy web thực tế (trong đợt chạy lúc 02:16 này chúng tôi chưa trỏ Nginx vào thư mục giải nén).

Để kiểm chứng độ nhạy của công cụ phát hiện lỗi, chúng tôi đã tạo một bản sao riêng biệt từ gói nén rồi cố tình cắt cụt mất 64 byte cuối cùng (giữ nguyên vẹn gói archive gốc). Đúng như kỳ vọng, câu lệnh gzip -t lập tức báo lỗi với mã thoát exit code 1 và chuỗi băm SHA-256 thay đổi hoàn toàn. Ngay sau khi kết thúc bài test, cả hai tệp gắn nhãn thử nghiệm, thư mục giải nén tạm và bản sao bị cắt cụt đều đã được dọn dẹp sạch sẽ. Mã băm của toàn bộ cây thư mục bản clone sau khi dọn dẹp khớp hoàn toàn với trạng thái trước khi thử nghiệm; tệp cấu hình của trang nguồn cũng giữ nguyên mã băm. Lưu ý nhỏ về mặt kỹ thuật: các câu lệnh WP-CLI hoặc yêu cầu HTTP GET có thể làm thay đổi các bản ghi tạm (transients) trong cơ sở dữ liệu, do đó việc mã băm hệ thống tệp giữ nguyên không dùng để kết luận về trạng thái bên trong Database.

Bộ sao lưu lành lặn sau đợt chạy được cất giữ trên VPS trong một thư mục riêng nằm ngoài webroot: thư mục cha đặt quyền 700, còn bốn tệp bên trong (gồm gói archive, bản xuất SQL, tệp Checksum và manifest) đều khóa ở quyền 600. Biên bản thực nghiệm hoàn toàn không phơi bày nội dung tệp SQL hay mật khẩu đăng nhập. Đợt thực nghiệm lúc 02:16 này tập trung xác minh tầng đóng gói tệp, chưa thực hiện nạp SQL, chưa khởi chạy WordPress từ thư mục vừa giải nén và chưa mã hóa hay đẩy tệp ra kho lưu trữ ngoài máy.

Mặc dù các đợt diễn tập ngày 30/09 trước đó đã dựng lại website thành công, nhưng chúng sử dụng bộ Backup của ngày hôm trước. Nguyên tắc vận hành nghiêm túc là mỗi bộ sao lưu mới sinh ra đều phải tự vượt qua bài kiểm tra của chính nó; việc giải nén khớp từng byte ở bước này mới đóng dấu xác nhận cho nửa phần tệp tin.

Ảnh thẩm định bộ archive đã lưu

Vào lúc 11:31:55–11:32:02 ngày 01/10/2026 (UTC+7), một lượt kiểm kê độc lập trên bản clone tiếp tục xác nhận hệ thống đang chạy WordPress 7.1.2 với đúng 4.010 tệp tin, 12 bảng dữ liệu, 2 bài viết xuất bản và 0 tệp trong uploads / 0 bản ghi attachment. Hai plugin Akismet 5.7.2 và Hello 1.7.2 vẫn tắt, giao diện Twenty Twenty-Five 1.5 đang kích hoạt. Hai công cụ nhị phân trên máy là tar 1.35 và gzip 1.12; mã băm của hai tệp cấu hình trên các trang hiện hữu 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 kè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 kiểm kê; lưu ý mốc giờ 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). Bấm vào ảnh để xem kích thước đầy đủ.

Ngay tiếp theo, trong khung 11:33:10–11:33:16, chính bộ sao lưu chuẩn chỉnh đã cất giữ từ lúc 02:16 rạng sáng được mang ra thẩm định lại và giải nén vào một thư mục đích hoàn toàn 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 chính là đợt chạy thẩm định và giải nén 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 thay vì in toàn bộ hàng nghìn dòng tên tệp của lệnh tar. Bấm vào ảnh để xem rõ chi tiết.

Thư mục lưu trữ Backup thuộc quyền sở hữu của root vẫn giữ nguyên mức phân quyền 700; bốn tệp thành phần bên trong giữ nguyên mức 600. Hai tệp gắn nhãn thử nghiệm nằm sẵn bên trong gói archive từ thời điểm đóng gói lúc 02:16, không phải là tệp media mới phát sinh. Đợt chạy lúc 11:33 này tập trung đối chiếu kết quả giải nén với gói archive đang cất trong kho và dọn dẹp thư mục đích ngay sau khi hoàn tất. Để nghiệm thu trọn vẹn khả năng hoạt động của ứng dụng WordPress từ bộ tệp này, bạn hãy xem kết quả của các đợt diễn tập Restore hoàn chỉnh (lúc 12:21 và 21:41) được trình bày chi tiết ở bài 51.

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

Nếu trong lúc đóng gói bạn gặp lỗi Permission denied ở một vài tệp tin, hãy kiên nhẫn tìm đúng tệp bị lệch quyền đó để điều chỉnh thay vì vung tay gõ câu lệnh tự sát chmod -R 777 lên toàn bộ thư mục website. Nếu vấp phải thông báo No space left on device (hết dung lượng ổ đĩa), hãy lập tức xóa bỏ tệp .part đang ghi dở dang, kiểm tra lại dung lượng trống trên phân vùng và bảo vệ nguyên vẹn bản sao lưu thành công gần nhất trước đó. Trong trường hợp tải gói Backup về mà đối chiếu thấy mã băm Checksum bị lệch, hãy tải lại từ kho gốc và kiểm tra cả kích thước byte của tệp — tuyệt đối không bao giờ tự chạy lệnh tạo mã Checksum mới đè lên tệp đang hỏng chỉ để vượt qua bước kiểm tra! Khi muốn hủy bỏ một lượt giải nén thử nghiệm, bạn chỉ cần xóa đúng thư mục đích vừa tạo, giữ nguyên vẹn thư mục trang nguồn và gói archive gốc.

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

Tar có lưu file ẩn không?

Khi bạn sử dụng cú pháp chuyển thư mục kèm dấu chấm tar -C "$WP_ROOT" . như trong bài hướng dẫn này, công cụ tar sẽ gom đầy đủ toàn bộ các tệp ẩn (dotfiles) nằm ngay ở thư mục gốc. Ngược lại, nếu bạn gõ tar ... "$WP_ROOT"/* để shell tự bung dấu sao, các tệp ẩn ở tầng ngoài cùng như .htaccess hay .user.ini rất dễ bị bỏ rơi lại phía sau.

Có cần backup toàn bộ core không?

Về mặt lý thuyết, bạn hoàn toàn có thể tải lại bộ mã nguồn lõi (WordPress core) đúng phiên bản từ trang chủ khi khôi phục. Tuy nhiên, việc đóng gói nguyên cây thư mục WordPress như trong bài lab này giúp giảm thiểu số mảnh ghép phải lắp ráp thủ công lúc đang cấp cứu sự cố, miễn là dung lượng ổ đĩa lưu trữ của bạn vẫn thoải mái.

Giải nén xong quyền khác có phải archive hỏng?

Hoàn toàn không phải. Quyền truy cập tệp tin (permissions) và chủ sở hữu sau khi giải nén phụ thuộc trực tiếp vào tài khoản người dùng đang gõ lệnh, giá trị umask hiện hành và các cờ tùy chọn mà bạn truyền cho lệnh tar. Hãy đối chiếu mã băm SHA-256 để xác nhận nội dung tệp nguyên vẹn, sau đó rà soát kỹ và thiết lập lại phân quyền chuẩn xác theo tài khoản dịch vụ web của môi trường đích.

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

Hãy cất giữ gói archive đã qua thẩm định, tệp mã băm Checksum và bản xuất SQL mang cùng nhãn thời gian vào một thư mục lưu trữ an toàn ngoài webroot. Tiếp theo, hãy tự tay giải nén thử ra một thư mục độc lập để kiểm tra sự hiện diện của tệp ẩn, thư mục uploads cũng như phân quyền của tệp cấu hình, rồi kết hợp nạp tệp SQL để dựng lại trang web hoàn chỉnh trong buổi diễn tập Restore. Nếu bất kỳ công đoạn nào báo lỗi, hãy giữ lại thư mục lỗi có gắn nhãn cảnh báo để điều tra nguyên nhân và tạo một bộ mới tinh chứ đừng ghi đè lên bản sao lưu lành lặn cuối cùng. Hành trình khôi phục toàn diện ứng dụng đang chờ bạn khám phá tiếp trong series WordPress từ A đến Z.

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

Đối chiếu tài liệu ngày 01/10/2026: chúng tôi đã rà soát lại hướng dẫn sao lưu chính thức của WordPress và kiểm chứng trực tiếp các cờ tùy chọn của bộ ba công cụ tar, gzip, sha256sum bằng tệp thực thi thực tế trên máy chủ lab. Lưu ý rằng các kết quả thẩm định gói nén ở trên chỉ xác nhận tính toàn vẹn của tệp lưu trữ, chưa thay thế cho bài nghiệm thu khôi phục toàn diện ứng dụng.

• WordPress: sao lưu file và database.

Tài liệu chuẩn GNU giữ mốc tham chiếu ngày 30/09/2026:

• GNU: kiểm dung lượng bằng du.

• GNU tar: tùy chọn tạo và giải nén archive.

• GNU Coreutils: kiểm SHA-256.