Xuất nhập Database MariaDB cho WordPress: Từ mariadb-dump đến đối chiếu dữ liệu sau Restore

Phạm vi đã thử: Máy chủ LAB-CF-02 đã trải qua đợt xuất/nhập thông qua công cụ WP-CLI vào ngày 30/09/2026 và hai đợt thực nghiệm trực tiếp bằng bộ công cụ gốc mariadb-dump / mariadb (nhập mật khẩu qua lời nhắc prompt an toàn) vào lúc 12:05 và 13:21 ngày 01/10. Hai bức ảnh chụp màn hình console trong bài thuộc cùng đợt chạy lúc 13:21. Các đợt chạy native này tiến hành nạp Database của bản clone vào một cơ sở dữ liệu tạm thời tách biệt trên cùng VPS, đối chiếu toàn bộ cấu trúc bảng lẫn dữ liệu nội dung rồi dọn dẹp sạch sẽ; lưu ý rằng bước này chưa khởi chạy ứng dụng WordPress trên Database vừa nạp và chưa mô phỏng tải ghi đồng thời (concurrent writes). Các khối lệnh bên dưới được biên soạn chuẩn hóa cho mục đích học tập, không phải bản sao chép nguyên văn script tự động của hệ thống kiểm thử.

Trước khi gõ lệnh xuất hoặc nhập cơ sở dữ liệu MariaDB cho một trang WordPress, một người làm kỹ thuật cẩn trọng luôn phải trả lời được bốn câu hỏi: Database nguồn tên chính xác là gì, phiên bản công cụ tạo bản dump là bao nhiêu, làm sao đảm bảo tính nhất quán (consistency) khi đang có dữ liệu ghi vào, và Database đích nào sẽ đứng ra hứng dữ liệu. Một tệp tin chỉ đơn thuần có cái đuôi .sql nằm trên ổ đĩa hoàn toàn không tự trả lời được những câu hỏi sống còn đó. Trong bài hướng dẫn này, chúng ta sẽ sử dụng tài khoản người dùng độc lập và một Database phục hồi riêng biệt để triệt tiêu nguy cơ ghi đè nhầm lên dữ liệu gốc.

Hãy luôn tâm niệm rằng tệp SQL dump chính là “trái tim trần trụi” của website: bên trong nó chứa danh sách email khách hàng, chuỗi mật khẩu băm (password hashes) và hàng loạt khóa cấu hình nhạy cảm của các plugin. Vì vậy, bạn bắt buộc phải lưu trữ tệp này ở thư mục nằm hẳn bên ngoài vùng phục vụ của Nginx, khóa chặt quyền đọc hệ thống tệp và tuyệt đối không bao giờ đính kèm nguyên tệp SQL gốc lên các diễn đàn hỏi đáp hay hệ thống ticket hỗ trợ công khai.

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

Để theo sát bài thực hành này, bạn cần hoàn thành trước lộ trình cài WordPress trên VPS từ A đến Z và nắm quyền quản trị trên một máy chủ lab riêng. Hạ tầng mẫu trong bài chạy hệ điều hành Ubuntu 24.04 LTS, Nginx, PHP 8.3 và hệ quản trị cơ sở dữ liệu MariaDB 10.11. Bạn nhớ xác minh phiên bản phần mềm, tên tiến trình service và cấu trúc đường dẫn thực tế trên máy thử nghiệm của mình trước khi bắt đầu, bởi mỗi môi trường có thể mang đặc thù cấu hình riêng.

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ụ khách truy cập. Thay thế các biến môi trường viết hoa bằng giá trị thực tế đã xác minh trên lab; tuyệt đối giữ kín mật khẩu bên ngoài nội dung bài viết, lịch sử dòng lệnh (shell history) cũng như kho quản lý mã nguồn. Nếu gõ lệnh mà hệ thống báo “command not found”, đừng vội lo lắng tưởng dịch vụ web gặp sự cố — bạn chỉ cần đọc tài liệu chính thức để cài đặt đúng gói phần mềm còn thiếu và kiểm tra phiên bản là xong. Các sơ đồ minh họa trong bài đóng vai trò giải thích luồng thao tác, không dùng để thay thế ảnh chụp màn hình thực nghiệm.

Minh họa kiến trúc 1: bốn bước chuẩn bị trước khi xuất Database. 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.

Kiểm phiên bản, engine và tên đích trước

Môi trường lab Ubuntu 24.04 của chúng ta sử dụng MariaDB nhánh 10.11; trước tiên bạn hãy gõ lệnh mariadb --version để ghi nhận chính xác số hiệu phiên bản của trình khách trên máy. Tiếp theo, trong phiên làm việc SQL có đủ quyền truy vấn, hãy chạy câu lệnh SHOW TABLE STATUS để điểm danh loại Storage Engine của từng bảng dữ liệu. Điểm kỹ thuật cực kỳ quan trọng nằm ở đây: tham số --single-transaction sẽ tạo ra một điểm chụp dữ liệu nhất quán (consistent snapshot) hoàn hảo cho các bảng hỗ trợ giao dịch như InnoDB mà không làm khóa bảng, nhưng nó lại hoàn toàn bất lực trong việc đảm bảo tính nhất quán nếu hệ thống của bạn vẫn còn sót lại những bảng cổ lỗ sĩ chạy trên nền MyISAM.

Trong suốt khoảng thời gian chạy lệnh xuất dữ liệu (dump), tuyệt đối không thực hiện các tác vụ nâng cấp plugin hay chạy migration làm thay đổi cấu trúc bảng (ALTER TABLE). Nếu bạn đang thực hiện gom một bộ Backup hoàn chỉnh gồm cả file lẫn Database, hãy nhớ khóa cửa sổ ghi dữ liệu vào thư mục uploads theo đúng nguyên tắc đã bàn ở bài 50. Hãy mở tệp cấu hình riêng để tra cứu chính xác tên Database thay vì ngồi đoán mò theo tên miền website. Về mặt phân quyền: tài khoản thực hiện lệnh xuất trên nguồn chỉ cần quyền đọc đầy đủ các đối tượng được chọn, trong khi tài khoản thực hiện lệnh nạp ở phía đích chỉ nên được cấp quyền tạo bảng và ghi dữ liệu gói gọn bên trong đúng Database phục hồi.

Xuất một file mới, giữ lỗi tách khỏi dữ liệu

Hãy trích xuất giá trị DB_NAME và DB_USER từ hồ sơ cấu hình của trang nguồn trên lab, đồng thời đảm bảo biến DB_SOCKET trỏ đúng vào đường dẫn tệp socket của dịch vụ MariaDB đang chạy. Một thói quen bảo mật bắt buộc là chỉ truyền cờ --password đứng một mình (không viết kèm mật khẩu ngay sau dấu bằng) để buộc trình khách hiển thị lời nhắc nhập mật khẩu ẩn trên terminal. Hãy chuẩn bị sẵn thư mục cha BACKUP_DIR nằm tách biệt hoàn toàn bên ngoài mọi webroot và chỉ cho phép tài khoản vận hành truy cập. Ở mỗi lần chạy lệnh xuất, đoạn script mẫu dưới đây sẽ tự động tạo ra một thư mục con mới tinh nhằm loại bỏ hoàn toàn rủi ro ghi đè lên các bản sao lưu cũ.

(
  set -euC
  : "${DB_NAME:?Chọn database nguồn lab}"
  : "${DB_USER:?Chọn user DB nguồn}"
  : "${DB_SOCKET:?Chọn socket MariaDB đã xác minh}"
  : "${BACKUP_DIR:?Chọn thư mục cha backup riêng ngoài webroot}"
  test -S "$DB_SOCKET"
  test -d "$BACKUP_DIR"
  test -w "$BACKUP_DIR"
  BACKUP_DIR=$(realpath -e -- "$BACKUP_DIR")
  umask 077
  RUN_DIR=$(mktemp -d -- "$BACKUP_DIR/mariadb-dump.XXXXXX")
  printf 'Thư mục lần xuất: %s\n' "$RUN_DIR"
  mariadb-dump --no-defaults --protocol=socket --socket="$DB_SOCKET" \
    --user="$DB_USER" --password --single-transaction --quick \
    --hex-blob "$DB_NAME" > "$RUN_DIR/database.sql.part"
  test -s "$RUN_DIR/database.sql.part"
  test ! -e "$RUN_DIR/database.sql"
  test ! -L "$RUN_DIR/database.sql"
  mv -- "$RUN_DIR/database.sql.part" "$RUN_DIR/database.sql"
  printf 'Dump hoàn tất: %s/database.sql\n' "$RUN_DIR"
)

Mẹo viết script tinh tế của các kỹ sư lâu năm: toàn bộ cụm lệnh được bọc trong cặp ngoặc đơn ( ... ) để chạy trong một tiến trình con (subshell), nhờ đó nếu có lệnh nào vấp lỗi dừng lại thì cửa sổ phiên làm việc SSH chính của bạn không bị văng ra ngoài. Cờ set -e buộc khối lệnh phanh gấp ngay khi tiến trình dump hoặc bước kiểm tra gặp sự cố; trong khi cờ set -C (noclobber) ngăn chặn hành vi vô tình ghi đè lên tệp đã tồn tại. Đặc biệt, dữ liệu đang xuất ra sẽ được ghi vào tệp tạm mang đuôi .part trước; chỉ khi câu lệnh mariadb-dump kết thúc hoàn hảo với mã thoát exit code 0 và tệp được xác nhận có dung lượng lớn hơn không, hệ thống mới chính thức đổi tên nó thành đuôi .sql chuẩn chỉnh. Nhờ cơ chế này, bạn sẽ không bao giờ rơi vào cảnh ôm một tệp .sql bị đứt gánh giữa đường đi cấp cứu mà cứ ngỡ là bản sao lưu lành lặn. Nếu quá trình xuất gặp lỗi, hãy giữ nguyên tệp .part đó để mổ xẻ nguyên nhân và khởi tạo một thư mục mới cho lần chạy tiếp theo. Sau khi thành công, hãy gán đường dẫn tệp vừa in ra màn hình vào biến DUMP_FILE để phục vụ bước nạp phía dưới (do biến RUN_DIR chỉ sống bên trong phạm vi subshell). Lưu ý thêm: bài thực hành này chủ đích không truyền cờ --databases để trong tệp SQL xuất ra không bị chèn sẵn hai câu lệnh CREATE DATABASE và USE trỏ cứng về tên Database nguồn — giúp việc nạp sang một Database đích mang tên khác trở nên an toàn tuyệt đối.

Ảnh chụp thực tế (phần 1) từ cùng phiên ghi nhận trên console lúc 13:21:16 ngày 01/10/2026 (UTC+7). Công cụ giám sát điều khiển trình khách MariaDB chạy thật qua giao diện PTY trong khung 13:21:03–08; bức ảnh ghi lại kết quả kiểm tra đầu vào và hoàn tất bản dump 120.242 byte mà không hiển thị thao tác gõ mật khẩu. Toàn bộ vùng hiển thị giữ nguyên pixel gốc kèm logo ở chân ảnh; bấm vào ảnh để phóng to.

Minh họa kiến trúc 2: bốn chốt chặn an toàn khi nạp dữ liệu (Import). 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.

Nhập vào database trống đã tạo riêng

Ở phía nhận dữ liệu, bạn hãy tạo sẵn một cơ sở dữ liệu trống hoàn toàn mới với thiết lập bảng mã (charset) và quy tắc so sánh chuỗi (collation) khớp hoàn toàn với Database nguồn (thông thường là bộ đôi utf8mb4 và utf8mb4_unicode_ci). Trước khi nạp tệp vào, hãy quét kiểm tra một lượt để chắc chắn bên trong tệp dump không ẩn chứa câu lệnh CREATE DATABASE hay USE nào đang trỏ ngược về Database gốc. Nguyên tắc an toàn là chỉ nạp những bản dump vừa được trích xuất theo đúng quy trình kiểm soát của chính bạn; những tệp SQL trôi nổi lấy từ nguồn không rõ ràng có thể cài cắm sẵn các thủ tục (routines), sự kiện hẹn giờ (events) hoặc những câu lệnh can thiệp vượt quá phạm vi một website.

(
  set -eu
  : "${DB_NAME:?Đặt tên database nguồn để đối chiếu}"
  : "${DB_USER:?Đặt user nguồn để đối chiếu}"
  : "${DB_SOCKET:?Chọn socket MariaDB đã xác minh}"
  : "${RESTORE_DB:?Chọn database phục hồi trống}"
  : "${RESTORE_DB_USER:?Chọn user chỉ có quyền đích}"
  : "${DUMP_FILE:?Chọn đúng file database.sql đã hoàn tất}"
  test "$DB_NAME" != "$RESTORE_DB"
  test "$DB_USER" != "$RESTORE_DB_USER"
  test -S "$DB_SOCKET"
  test -f "$DUMP_FILE"
  test -r "$DUMP_FILE"
  test -s "$DUMP_FILE"
  test ! -L "$DUMP_FILE"
  case "$DUMP_FILE" in
    *.part) printf 'Không nhập file đang dở\n' >&2; exit 1 ;;
  esac
  target_tables=$(mariadb --no-defaults --protocol=socket \
    --socket="$DB_SOCKET" --user="$RESTORE_DB_USER" --password \
    --batch --skip-column-names "$RESTORE_DB" --execute='SHOW TABLES;')
  test -z "$target_tables"
  mariadb --no-defaults --protocol=socket --socket="$DB_SOCKET" \
    --user="$RESTORE_DB_USER" --password "$RESTORE_DB" < "$DUMP_FILE"
  printf 'Import trả mã 0; tiếp tục kiểm cấu trúc và dữ liệu.\n'
)

Bước đối chiếu tên nguồn và tên đích ở ngay đầu đoạn mã chính là chốt chặn giúp bạn phát hiện kịp thời nếu lỡ tay copy-paste nhầm tên biến. Để đóng khung phạm vi mà các câu lệnh SQL có thể tác động, tài khoản thực hiện lệnh nạp bắt buộc chỉ được cấp quyền bên trong đúng Database đích. Trước khi đổ dữ liệu vào, hãy dùng chính tài khoản đích đó để kiểm tra kết quả trả về của các hàm CURRENT_USER(), DATABASE() và câu lệnh SHOW GRANTS; tuyệt đối không dùng tài khoản root hay tài khoản đang nắm quyền trên Database nguồn để chạy lệnh import. Khối lệnh mẫu sẽ yêu cầu bạn nhập mật khẩu ở cả bước kiểm tra Database đích trống lẫn bước nạp dữ liệu thực tế. Nếu trình khách phát hiện lỗi kết nối hoặc thấy trong Database đích đã có sẵn bảng dữ liệu, toàn bộ tiến trình sẽ tự động dừng lại ngay trước vạch xuất phát. Đừng bao giờ dùng cờ --force để ép MariaDB nhắm mắt bỏ qua lỗi cú pháp rồi tự huyễn hoặc rằng mình đã khôi phục thành công! Nếu vướng lỗi liên quan đến bảng mã collation hoặc cú pháp SQL, hãy bình tĩnh đối chiếu lại phiên bản giữa trình khách và máy chủ cũng như nguồn gốc tệp dump. Trong trường hợp một lượt import bị gãy giữa chừng, một vài bảng dữ liệu có thể đã kịp sinh ra trong Database đích — lúc này hãy nhờ tài khoản quản trị xóa bỏ hoặc khởi tạo một Database trống mới tinh trước khi làm lại từ đầu, đảm bảo Database nguồn luôn bất khả xâm phạm.

Kiểm từ cấu trúc tới nội dung

Sau khi lệnh nạp báo hoàn tất với mã thoát bằng không, công việc của chúng ta mới đi được một nửa. Hãy sử dụng các câu truy vấn ở chế độ chỉ đọc (read-only queries) để đặt danh sách bảng của Database nguồn và Database đích lên bàn cân, đồng thời đếm số lượng bản ghi của những bảng cốt lõi. Với hệ thống WordPress, bạn cần đối chiếu số lượng bài viết phân loại theo từng cặp post_type và post_status, kiểm tra bài viết mới nhất vừa đăng và xác nhận tệp vật lý tương ứng của các bản ghi đính kèm (attachments). Một lưu ý nhỏ nhưng rất hay bắt bài những người cẩu thả: hãy đọc biến $table_prefix trong tệp cấu hình để biết tiền tố bảng thực tế của website là gì, đừng bao giờ nhắm mắt mặc định lúc nào nó cũng là wp_.

Khi một bản mã nguồn WordPress phục hồi độc lập đã được kết nối vào Database đích, bạn có thể tận dụng ngay công cụ WP-CLI để nghiệm thu nhanh số lượng bài viết và sức khỏe bảng mà không cần in thông tin nhạy cảm của người dùng ra màn hình:

: "${RESTORE_ROOT:?Chọn thư mục WordPress phục hồi riêng}"
wp --path="$RESTORE_ROOT" post list --post_type=post   --post_status=publish --format=count
wp --path="$RESTORE_ROOT" db check

Câu lệnh wp db check sẽ gọi công cụ kiểm tra tầng lưu trữ bên dưới để rà soát lỗi hỏng cấu trúc bảng; tuy nhiên kết quả OK của nó chưa tự động đảm bảo mọi plugin trên tầng ứng dụng sẽ chạy mượt mà. Bạn vẫn cần mở trình duyệt kiểm tra thực tế bài viết, thư viện ảnh, trang quản trị và thiết lập của các plugin trong lab. Đặc biệt, hãy nhìn kỹ các dòng tiêu đề và nội dung tiếng Việt có dấu: nếu thấy chữ nghĩa biến thành các ký tự dấu hỏi chấm (?) hay chuỗi mã lạ (mojibake), đó là dấu hiệu rõ ràng của việc lệch bảng mã encoding trong lúc xuất hoặc nhập. Hai cơ sở dữ liệu có tổng số dòng bằng nhau chằn chặn nhưng nội dung bên trong bị lỗi font chữ thì vẫn là một ca khôi phục thất bại.

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

Một bộ hồ sơ nghiệm thu Database đạt chuẩn cần lưu trữ đủ: mã thoát (exit code) của cả hai bước xuất và nhập, danh sách đối chiếu các bảng, kết quả kiểm tra mẫu nội dung, trạng thái hoạt động của ứng dụng và mốc thời gian thực hiện chính xác. Nếu website của bạn có sử dụng các plugin thương mại điện tử, đặt lịch hay học trực tuyến vốn sinh ra hàng chục bảng dữ liệu riêng, hãy bổ sung thêm các câu truy vấn kiểm tra nghiệp vụ đặc thù cho những bảng đó. Khi lập báo cáo chia sẻ nội bộ hoặc công khai, bạn chỉ cần chụp ảnh các con số thống kê tổng hợp và bài viết thử nghiệm là đủ sức thuyết phục; tuyệt đối không in dữ liệu từ bảng wp_users hay các dòng chứa khóa bí mật trong bảng wp_options ra làm bằng chứng.

Minh họa kiến trúc 3: quy trình hậu kiểm ba lớp sau khi nạp Database. 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ả thực trên LAB-CF-02 ngày 30/09/2026

Đợt thực nghiệm sao lưu và khôi phục thông qua WP-CLI cùng bước hậu kiểm phân quyền lúc 23:20 (UTC+7) ngày 30/09 đã ghi nhận các kết quả thực tế sau:

Tại thời điểm hoàn tất, tài khoản kết nối Database của bản phục hồi đã được tách biệt hoàn toàn khỏi tài khoản của trang nguồn. Sau khi cập nhật tài khoản mới và thu hồi các quyền dư thừa cũ, cả hai trang web đều vượt qua bài kiểm tra đếm số lượng bài viết và truy cập permalink. Tệp cấu hình của trang nguồn giữ nguyên vẹn, trong khi tệp cấu hình của bản phục hồi được khóa chặt ở chế độ phân quyền 640. Đúng theo nguyên tắc bảo mật, toàn bộ mật khẩu, nội dung tệp SQL dump và định danh tài khoản mới đều được giữ kín ngoài biên bản công khai.

Lưu ý về phạm vi: đợt chạy ngày 30/09 thực hiện qua lớp bọc WP-CLI nên chưa trực tiếp kiểm nghiệm thao tác nhập mật khẩu qua lời nhắc prompt của bộ công cụ gốc mariadb-dump và mariadb; mảnh ghép này đã được bổ sung hoàn chỉnh vào ngày 01/10 ngay bên dưới. Ngoài ra, nhật ký của WP-CLI ngày 30/09 chưa đi sâu xác nhận từng cờ tùy chọn dump chi tiết, loại Storage Engine của từng bảng hay khả năng chịu tải khi có nhiều luồng ghi đồng thời. Việc 12 bảng báo OK và khớp số bài viết cũng mới chỉ chứng minh phần dữ liệu cốt lõi, chưa thay thế cho việc nghiệm thu thư viện ảnh, khung đăng nhập, biểu mẫu, email hay các plugin mở rộng. Do môi trường đích nằm trên cùng máy chủ VPS, đợt chạy này cũng chưa bao hàm bài toán sao lưu ngoài máy (offsite), đo chỉ số RTO hay khôi phục từ Snapshot.

Dump/import trực tiếp đã kiểm ngày 01/10

Vào lúc 12:05:15–12:05:20 ngày 01/10/2026 (UTC+7), kịch bản kiểm thử đã khởi chạy trực tiếp hai trình khách gốc của MariaDB phiên bản 10.11.14 thông qua giao diện thiết bị đầu cuối ảo (PTY) trên máy chủ LAB-CF-02. Hệ thống xác nhận lời nhắc nhập mật khẩu (password prompt) xuất hiện đúng chuẩn, chế độ hiển thị ký tự phản hồi (terminal echo) được tắt hoàn toàn trước khi truyền mật khẩu và tuyệt đối không có chuỗi mật khẩu nào xuất hiện trong danh sách tham số tiến trình (process arguments). Cơ sở dữ liệu nguồn là Database của bản clone, còn phía đích là một cặp Database và tài khoản tạm thời mới tinh được khởi tạo riêng với đúng một quyền GRANT trên schema đích (không kèm quyền GRANT OPTION).

Ngay sau khi hoàn tất đối chiếu, toàn bộ Database tạm, tài khoản người dùng thử nghiệm, tệp dump phát sinh và các tệp trạng thái trung gian đều đã được xóa sạch. Những tài nguyên này chỉ được dựng lên để phục vụ đúng một phiên kiểm định kỹ thuật; tất nhiên các bộ Backup chính thức dùng để phòng hộ lâu dài thì vẫn được cất giữ nguyên vẹn ở kho riêng. Kết quả trên xác nhận các trường dữ liệu trọng yếu đã khớp hoàn toàn, dù về mặt toán học nó không đồng nghĩa với việc khẳng định toàn bộ hai cơ sở dữ liệu giống hệt nhau từng byte vật lý trên đĩa.

Tiếp đó, vào lúc 13:21:03–13:21:08 cùng ngày 01/10, quy trình kiểm thử native này được tái lập một lần nữa với trình khách MariaDB 10.11.14 trên một Database tạm độc lập mới để ghi nhận bằng chứng hình ảnh. Bản xuất SQL vẫn giữ đúng kích thước 120.242 byte với quyền truy cập 600; lệnh import kết thúc êm đẹp với mã thoát 0, toàn bộ 12 bảng khớp tuyệt đối từ Storage Engine, bảng mã collation cho đến tổng số dòng, mã băm SHA-256 của các trường bài viết trùng khớp hoàn toàn và cả 12 bảng đều trả về kết quả CHECK TABLE OK. Công cụ giám sát ghi nhận tổng cộng 15 lần xuất hiện lời nhắc mật khẩu xuyên suốt chuỗi thao tác truy vấn và xuất/nhập của trình khách, tất cả đều tắt hiển thị echo và không lộ mật khẩu trên dòng lệnh (lưu ý đây là 15 bước xác thực của trình khách trong một phiên kiểm định, không phải chạy 15 đợt dump/import khác nhau). Kết thúc phiên chạy, toàn bộ tài nguyên tạm được dọn dẹp sạch sẽ, mã băm của hai tệp cấu hình không đổi và hai trang web hiện hữu trên lab vẫn phản hồi khỏe mạnh.

Ảnh chụp thực tế (phần 2) từ cùng lần ghi nhận lúc 13:21:16 ngày 01/10/2026 (UTC+7), nối tiếp ngay sau bức ảnh xuất dữ liệu ở phần trên. Màn hình hiển thị kết quả giám sát trình khách MariaDB thực thi bước nạp dữ liệu, đối chiếu 12 bảng đạt chuẩn và dọn dẹp tài nguyên tạm thời; hình ảnh giữ nguyên độ phân giải gốc kèm logo ở chân trang. Nhấp vào ảnh để xem kích thước đầy đủ.

Cần nhấn mạnh lại giới hạn phạm vi: hai đợt chạy native lúc 12:05 và 13:21 tập trung thuần túy vào tầng cơ sở dữ liệu SQL, chưa nối một bản mã nguồn WordPress vào Database vừa nạp để mở web, chưa thử nghiệm kịch bản vừa xuất dữ liệu vừa bắn tải ghi liên tục, chưa kiểm tra bảng riêng của các plugin phức tạp hay truyền tệp ra ngoài VPS. Để hoàn chỉnh bức tranh khôi phục toàn diện, bạn cần kết hợp quy trình nạp SQL chuẩn chỉnh này với việc bung gói nén mã nguồn ở các bài liền kề và tự tay nghiệm thu chức năng trên trình duyệt.

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

Nếu trong lúc thao tác bạn vấp phải thông báo lỗi Access denied, hãy bình tĩnh rà soát lại tên tài khoản, địa chỉ host kết nối (ví dụ localhost so với 127.0.0.1) và bảng phân quyền GRANT; tuyệt đối không vì lười biếng mà vung tay cấp quyền GRANT ALL PRIVILEGES ON *.* toàn máy chủ chỉ để cho lệnh chạy qua. Lỗi Unknown database báo hiệu rằng cơ sở dữ liệu đích chưa được khởi tạo hoặc bạn đã gõ lệch tên biến. Với những bản dump có đính kèm thủ tục lưu trữ (stored routines) hoặc sự kiện (events), hãy đánh giá kỹ mức độ an toàn của chúng trước khi quyết định bật thêm cờ cho phép nạp. Khi một lượt nạp dữ liệu gặp trục trặc cần hủy bỏ, cách xử lý gọn gàng nhất là ngưng sử dụng ngay Database phục hồi đang lỗi đó, xóa bỏ nó và khởi tạo một Database trống mới tinh — nhờ nguyên tắc tách biệt từ đầu, Database nguồn của bạn vẫn bình an vô sự suốt cả quá trình.

Một lưu ý quan trọng nữa: nếu bạn đã thực hiện tách riêng tài khoản người dùng Database cho bản phục hồi và thu hồi quyền của tài khoản cũ như trong bài lab, thì khi muốn hoàn trả trạng thái cũ, việc chỉ chép đè lại tệp wp-config.php ban đầu là chưa đủ — bởi tài khoản nằm trong tệp cấu hình đó đã bị cắt quyền truy cập vào Database đích rồi. Trước khi hoàn trả cấu hình, hãy đảm bảo cả thông tin trong wp-config.php lẫn bảng quyền hạn trong MariaDB đều được đưa về cùng một mốc đồng bộ, sau đó xác minh lại khả năng kết nối và nội dung hiển thị của cả hai trang nguồn và đích.

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

Có thể copy thư mục dữ liệu MariaDB đang chạy không?

Tuyệt đối không được dùng lệnh cp hay tar chép sống thư mục vật lý (như /var/lib/mysql) khi tiến trình MariaDB đang hoạt động! Trong bài viết này chúng ta sử dụng phương pháp xuất dữ liệu logic (logical dump). Việc sao chép tệp dữ liệu vật lý đòi hỏi công cụ chuyên dụng (như mariabackup) và quy trình chốt điểm giao dịch nghiêm ngặt để không làm hỏng toàn bộ cơ sở dữ liệu.

Tại sao file SQL lớn nhưng import thất bại?

Dung lượng tệp lớn hoàn toàn không bảo chứng rằng tệp đó lành lặn. Một tệp SQL nặng hàng trăm MB vẫn có thể bị đứt đoạn ở những dòng cuối cùng do hết ổ cứng lúc xuất, bị lệch phiên bản cú pháp giữa máy cũ và máy mới, hoặc tài khoản chạy lệnh nạp không đủ quyền tạo các đối tượng đặc thù. Hãy luôn đọc kỹ dòng thông báo lỗi đầu tiên mà trình khách in ra và kiểm tra mã thoát của câu lệnh.

Có cần xuất user MariaDB toàn máy?

Đối với nhu cầu sao lưu và khôi phục một trang WordPress độc lập trên lab, bạn hoàn toàn không cần (và không nên) xuất toàn bộ bảng người dùng hệ thống của MariaDB. Cách làm sạch sẽ và an toàn nhất là tạo một tài khoản Database mới tinh dành riêng cho môi trường đích, cấp quyền tối thiểu đúng phạm vi schema đó và tránh mang theo các tài khoản quản trị từ máy cũ sang.

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

Hãy tập thói quen ghi chép đầy đủ phiên bản trình khách MariaDB, tên Database nguồn/đích, mã thoát của từng câu lệnh và bảng kết quả đối chiếu vào sổ tay vận hành. Sau khi tầng cơ sở dữ liệu đã vượt qua toàn bộ các bài kiểm tra cấu trúc và mã băm, bước tiếp theo của bạn là kết nối một bản mã nguồn WordPress thử nghiệm độc lập vào chính Database phục hồi đó để nghiệm thu hiển thị tiếng Việt, hình ảnh media và các plugin nghiệp vụ. Quy trình ghép nối hoàn chỉnh giữa gói nén hệ thống tệp và bản xuất SQL nằm ngay trong series WordPress từ A đến Z — hãy nhớ rằng 12 bảng dữ liệu khớp nhau mới chỉ là một nửa chặng đường cứu hộ một website.

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

Tài liệu chính thức được đối chiếu ngày 01/10/2026: chúng tôi đã rà soát kỹ tài liệu hướng dẫn của mariadb-dump và trình khách dòng lệnh mariadb xoay quanh phạm vi xuất dữ liệu, cơ chế giao dịch nhất quán (--single-transaction) và phương thức xác thực mật khẩu qua prompt. Bài viết tách bạch rõ kết quả thực nghiệm của hai ngày 30/09 và 01/10; các số liệu trên phản ánh đúng cấu hình máy lab chứ không phải cam kết cứng cho mọi hệ thống khác nhau.

• MariaDB: mariadb-dump.
• MariaDB: client dòng lệnh.

Tài liệu nền tảng giữ mốc tham chiếu ngày 30/09/2026:

• WordPress: phạm vi dữ liệu backup.

• WP-CLI: db check.