Backup Database và File website: cần sao lưu gì?

Một trong những lỗi phổ biến nhất của backup website là nói “đã backup toàn bộ” nhưng thực tế chỉ có database hoặc chỉ có thư mục web. Với WordPress, hai lớp này phục vụ những phần khác nhau của hệ thống và thường phải được ghép thành cùng một backup set nếu mục tiêu là full-site recovery.

Bài này trả lời câu hỏi cụ thể: database chứa gì, files chứa gì, cấu hình nào phải giữ, và dữ liệu nào có thể tái tạo thay vì sao lưu vô điều kiện? Nếu cần khung quyết định bao trùm frequency, retention, offsite và recovery objective, xem chiến lược Website Backup.

Database và Files khác nhau ở đâu?

WordPress Developer Handbook nêu rõ website WordPress có hai phần backup chính: database và files. Database thường nằm trong MySQL/MariaDB, tách khỏi thư mục WordPress trên web server; vì vậy tải toàn bộ thư mục web về không tự động sao lưu database.

Lớp	Ví dụ	Nếu mất
Database	Posts, pages, comments, options, users, plugin data	Mất dữ liệu động và trạng thái ứng dụng
Files	Core, plugins, themes, uploads, config	Mất code, media và cấu hình file
External systems	CDN, payment, CRM, object storage	Có thể mất dữ liệu không nằm trong WordPress

Database WordPress cần backup những gì?

Một database export đầy đủ thường bao gồm toàn bộ bảng thuộc site trong scope. Với WordPress core, dữ liệu quan trọng có thể gồm posts/pages, metadata, users, comments, options, taxonomy và các bảng khác. Plugin có thể tạo bảng riêng nên không nên backup bằng một danh sách table hard-code nếu chưa inventory plugin schema.

Không chỉ nhìn prefix mặc định

Nhiều site dùng prefix khác wp_, và plugin có thể tạo bảng riêng. Khi thiết kế backup job, inventory database/schema thực tế thay vì giả định tất cả dữ liệu quan trọng đều nằm trong một số bảng core.

Database export phải đi cùng metadata vận hành

Ngoài file dump, nên biết timestamp, database name, engine/version nếu cần, charset/collation và công cụ export. Những thông tin này hữu ích khi restore sang môi trường khác hoặc khi gặp lỗi import.

Files WordPress nào cần sao lưu?

`wp-content`: khu vực thường có dữ liệu duy nhất

Uploads, plugin tùy chỉnh, theme tùy chỉnh, MU-plugin và một số dữ liệu plugin nằm trong wp-content. Đặc biệt uploads thường không thể “cài lại từ nguồn” như WordPress core.

`wp-config.php` và file cấu hình

wp-config.php, .htaccess, web server config liên quan hoặc các file cấu hình custom cần được inventory. Tuy nhiên backup có thể chứa secrets, nên lưu trữ và quyền truy cập phải được kiểm soát. Xem thêm bảo vệ wp-config.php, salts và secrets.

WordPress core có cần backup không?

Core có thể tải lại từ nguồn WordPress chính thức nếu version và integrity được xác định, nhưng việc có core trong full-site backup có thể giúp khôi phục nhanh và giữ đúng trạng thái tại restore point. Quyết định này phụ thuộc recovery strategy, không phải quy tắc bắt buộc.

Plugin/theme có thể tải lại nhưng vẫn cần inventory

Plugin/theme từ repository hoặc vendor có thể tái cài, nhưng version cũ, custom code, private package hoặc component đã bị gỡ khỏi nguồn có thể không còn lấy lại được. Tối thiểu phải giữ inventory version và source; với custom/private component, backup artefact thường cần thiết.

Những thứ thường không nên coi là dữ liệu backup cốt lõi

Cache có thể tái tạo.
Temporary files không có giá trị recovery.
Generated logs đã có retention ở hệ thống log riêng.
Artefact build có thể tái tạo từ source/release pipeline đã bảo vệ.

Nhưng đừng loại trừ theo tên thư mục một cách máy móc. Một plugin có thể lưu dữ liệu quan trọng trong vị trí không chuẩn; inventory thực tế quan trọng hơn.

Dữ liệu bên ngoài WordPress rất dễ bị bỏ quên

Website có thể phụ thuộc vào object storage, CDN, payment provider, CRM, email platform, search index, form service hoặc headless backend. Nếu dữ liệu nguồn nằm ngoài WordPress, backup WordPress không bảo vệ được dữ liệu đó.

Hãy vẽ data-flow trước khi chốt scope

Liệt kê nơi tạo dữ liệu, nơi lưu dữ liệu gốc và nơi chỉ chứa bản copy/cache. Khi đó bạn mới biết thành phần nào phải backup và thành phần nào có thể rebuild từ nguồn khác.

Consistency giữa database và files

Backup database và files ở hai thời điểm cách nhau quá xa có thể tạo restore point không nhất quán. Ví dụ database tham chiếu một media file vừa upload nhưng files backup được chụp trước upload. Với site có nhiều write activity, nên thiết kế backup set có timestamp gần nhau hoặc cơ chế snapshot/transaction phù hợp.

Backup trước thay đổi lớn

WordPress khuyến nghị backup database trước upgrade; với thay đổi có thể tác động code/files, full backup set trước maintenance giúp rollback an toàn hơn. Bài quy trình cập nhật WordPress an toàn đặt backup trong change workflow thay vì coi nó là job tách biệt.

Backup Scope Matrix

Thành phần	Có cần backup?	Lý do/nguồn tái tạo	Owner
Database	Thông thường: Có	Dữ liệu động khó tái tạo	DB/App owner
Uploads	Thông thường: Có	Media/user-generated content	Content owner
Custom theme/plugin	Có nếu không có nguồn khác đáng tin	Private/custom code	Dev owner
Core	Tùy recovery strategy	Có thể tải từ nguồn chính thức	Ops
Cache/temp	Thường không	Có thể rebuild	Ops
External object storage	Tùy data ownership	Không nằm trên server WordPress	Platform owner

Full backup, incremental và selective backup

Full backup đơn giản hơn khi restore nhưng tốn dung lượng và thời gian. Incremental/differential có thể giảm chi phí nhưng làm recovery phụ thuộc chain và tooling. Selective backup hữu ích khi chỉ một dataset thay đổi nhanh, nhưng yêu cầu inventory và procedure chặt chẽ hơn.

Không có loại nào tốt nhất cho mọi website. Hãy chọn dựa trên RPO/RTO, kích thước dữ liệu, thay đổi mỗi ngày, băng thông và độ phức tạp mà đội vận hành có thể kiểm soát.

Verification: làm sao biết backup set đủ?

Kiểm tra database dump có thể parse/import trong môi trường test.
Kiểm tra archives/files có thể đọc và giải nén.
Đối chiếu uploads/media count hoặc sample quan trọng.
Kiểm tra custom component và config đã nằm trong scope.
Xác minh external dependency nào cần recovery riêng.
Restore test business flow quan trọng.

Việc file backup tồn tại không chứng minh backup set đủ. Sau khi scope đã đúng, cần chạy restore test end-to-end để chứng minh database/files thực sự phục hồi được. Bài bảo mật backup WordPress: restore integrity và recovery đi sâu hơn vào integrity, retention và restore verification.

Operational artifact: Backup Inventory

asset: wordpress-production
database:
  source: <db-name/cluster>
  method: <dump/snapshot>
  frequency: <schedule>
files:
  wordpress_root: yes|no
  wp_content: yes|no
  uploads: yes|no
  custom_plugins_themes: yes|no
  config_files: <list>
external_dependencies:
  - <object storage / CRM / payment / other>
rebuildable_items:
  - <cache / generated artifacts>
consistency_method: <how DB + files become one restore point>
owner: <team/person>
last_restore_test: <date/result>

Nguồn kỹ thuật

Kết luận

Backup database và files là hai phần khác nhau của cùng bài toán recovery. Một backup set tốt phải biết chính xác dữ liệu nào nằm trong database, dữ liệu nào nằm trên filesystem, dependency nào nằm ngoài WordPress và cách giữ các thành phần đó nhất quán tại cùng restore point.