Một job backup báo thành công, file ZIP cũng đã nằm trong storage. Tới lúc cần cứu site, database lên được nhưng ảnh mất, cấu hình queue trỏ sai hoặc dữ liệu mã hóa không còn đọc được. Chỗ đau là backup không hẳn bị lỗi; nó chỉ chưa bao giờ được kiểm tra như một bộ hồ sơ khôi phục hoàn chỉnh.
Với Botble CMS, cách chắc tay hơn là tách hai việc: tạo backup và diễn tập restore. Bài này dựng một fixture cô lập để kiểm chuỗi bằng chứng gồm database marker, media marker, checksum, negative control và rollback. Fixture không phải bản cài Botble core, không dùng dữ liệu production và không thay thế một lần restore staging trên đúng phiên bản site của bạn.
Mục lục [Hiển thị]
- Backup Botble thực sự bao phủ phần nào?
- Chốt điều kiện pass trước khi bấm Backup
- Tạo artifact có thể truy vết
- Fixture tách biệt đã kiểm tra điều gì?
- Restore Botble trong môi trường tách biệt
- Negative control nói thật hơn một lần pass
- Những thứ backup plugin không tự giải quyết
- Lịch diễn tập nên ngắn và có owner
Backup Botble thực sự bao phủ phần nào?
Tài liệu Backup Plugin của Botble, kiểm tra ngày 18/10/2026, mô tả hai nhóm chính: database và uploaded files trong Media Library. Trang này cũng nói rõ plugin không backup toàn bộ source code và không xử lý dịch vụ ngoài hay tích hợp bên thứ ba. Vậy nên một artifact xuất hiện trong Backup Manager chưa thể đại diện cho mọi thứ giữ site hoạt động.
Inventory tối thiểu nên có database, media, source/customization, phiên bản CMS-theme-plugin, cấu hình môi trường và các dịch vụ như queue, mail, object storage hoặc CDN. Botble Media Management cho phép nhiều storage driver, gồm local, S3, Wasabi, BunnyCDN và Cloudflare R2. Nếu site dùng object storage, đừng mặc định tùy chọn “uploaded files” của một backup local đã chụp đủ bucket từ xa; hãy xác minh trên chính cấu hình đang dùng.
.env và APP_KEY cần một kênh escrow secret riêng, có kiểm soát quyền và lịch sử thay đổi. Không đưa chúng vào ảnh chụp, log build hay báo cáo diễn tập. trang Troubleshooting chính thức cảnh báo rằng đổi hoặc mất APP_KEY sẽ làm session hiện có mất hiệu lực và có thể khiến cột mã hóa không đọc được. Giữ key cũ an toàn quan trọng hơn việc nhét nó vào cùng file ZIP cho tiện.
Chốt điều kiện pass trước khi bấm Backup
Restore “không hiện lỗi” là tiêu chí quá mơ hồ. Trước khi tạo artifact, hãy chọn một vài marker có thể kiểm chứng: một bài viết vô hại, một file media, một setting không nhạy cảm và phiên bản code đang chạy. Sau restore, probe phải trả lời được dữ liệu có đúng, ảnh có tải được, cấu hình cần thiết có khớp và môi trường đích có thể quay lui hay không.
RPO và RTO cũng nên được viết bằng ngữ cảnh thật. RPO là mức dữ liệu chấp nhận mất; RTO là thời gian cần để dịch vụ quay lại. Không có một con số chung cho mọi site. Một blog cập nhật mỗi tuần có thể chấp nhận cửa sổ dài hơn cửa hàng đang nhận đơn, nhưng cả hai đều cần biết backup gần nhất nằm ở đâu và ai chịu trách nhiệm restore.
| Probe | Bằng chứng trước backup | Điều kiện pass sau restore |
|---|---|---|
| Database | Row count + marker content | Số bản ghi và marker khớp |
| Media | Danh sách file + SHA-256 | Hash khớp, ảnh/file tải được |
| Phiên bản | CMS, theme, plugin, commit/release | Code và schema tương thích |
| Vận hành | Queue, cron, mail, storage driver | Smoke test đúng môi trường đích |
| Rollback | Restore point của đích | Trả lại marker ban đầu |
Tạo artifact có thể truy vết
Trang Commands hiện hành của Botble ghi cú pháp tạo backup là:
php artisan cms:backup:create [name] --description=[description]Nhưng trước khi đưa lệnh vào cron hoặc runbook, hãy hỏi chính bản cài đang vận hành:
php artisan --version
php artisan help cms:backup:create
php artisan help cms:backup:restore
php artisan cms:backup:listLượt kiểm tra này không có package Botble được cấp phép để chạy Artisan core, nên không tự nhận đã xác minh signature trên một bản Botble cụ thể. Đây là điểm quan trọng vì trang Commands mới dùng cms:backup:restore --backup=<backup-date>, còn trang Backup Plugin theo theme vẫn ghi ngày backup như đối số vị trí. Output của artisan help trên site bạn mới là nguồn quyết định.
Sau khi tạo, ghi timestamp UTC+7, tên artifact, kích thước, danh sách entry và SHA-256. Chép ít nhất một bản ra ngoài app root và ngoài ổ đĩa nguồn. File nằm trong cùng VPS có thể cùng biến mất khi volume hỏng hoặc tài khoản bị khóa; “một file, hai thư mục” chưa phải hai bản độc lập.
Fixture tách biệt đã kiểm tra điều gì?
Fixture chạy trên Windows với PHP 8.4.24, SQLite 3.53.2 và ZIP extension 1.22.8. Nó tạo một database có đúng một post marker, một setting vô hại và một file media marker. Full backup chứa database cùng media; database-only chỉ chứa database. Mọi restore diễn ra trong thư mục và database tách biệt, không đụng website thật.
Artifact full của fixture chỉ 715 byte vì dữ liệu cực nhỏ, con số này không đại diện kích thước hay tốc độ của một site Botble. Điều đáng dùng là phép so sánh: SHA-256 database và media sau restore khớp nguồn; row count vẫn là 1; nội dung marker và setting giữ nguyên. Cả bốn probe đặt trước đều pass.
Fixture còn kiểm soát đường dẫn khi giải nén: entry tuyệt đối hoặc có đoạn .. sẽ bị từ chối. Đây là hàng rào nên có khi inspect archive bằng script. Không giải nén một file chưa tin cậy thẳng vào production chỉ để “xem bên trong có gì”.
Restore Botble trong môi trường tách biệt
Môi trường rehearsal nên dùng đúng phiên bản code, database rỗng riêng, storage riêng và hostname staging/local. Tạo restore point của chính môi trường đích trước khi ghi đè. Tài liệu Botble cảnh báo thao tác restore sẽ ghi đè database hoặc file hiện tại, vì vậy production không phải nơi hợp lý cho lần thử đầu tiên.
Quy trình ngắn gọn:
- Đối chiếu hash artifact với manifest trước khi mở.
- Kiểm tra danh sách entry, database dump và media payload trong thư mục tạm.
- Clone code đúng release; cấu hình database/storage tách biệt bằng credential riêng.
- Dùng cú pháp được
artisan help cms:backup:restorexác nhận cho phiên bản đó. - Chạy probe database, media, admin/login, theme/plugin version, queue/cron và link quan trọng.
- Nếu bất kỳ probe nào fail, dừng quảng bá staging thành production và thử rollback.
Media cần được kiểm bằng URL sau khi web server chạy, không chỉ bằng việc file tồn tại trên disk. Nếu thumbnail sai sau restore, quy trình tạo lại thumbnail Botble an toàn giúp tách lỗi preset, file gốc và regeneration. Nếu toàn giao diện cũ, xem checklist cache, asset và quyền file sau deploy thay vì kết luận restore thất bại ngay.
Negative control nói thật hơn một lần pass
Positive control chứng minh đường restore có thể hoạt động; negative control chứng minh probe có khả năng bắt lỗi. Trong fixture, artifact database-only restore được database nhưng không có media marker. Probe media phải fail. Nếu dashboard vẫn xanh trong tình huống này, checklist đang kiểm nhầm thứ.
Kiểm soát thứ hai sửa đúng một byte ở bản sao artifact. SHA-256 lệch được phát hiện trước khi restore, nên file hỏng không đi vào bước ghi đè. Đây không phải kiểm tra malware hay chữ ký số; nó chỉ chứng minh artifact nhận được khác artifact đã ghi vào manifest.
Cuối cùng, rollback chép lại restore point của môi trường đích và kiểm marker ban đầu. Fixture trả đúng DESTINATION-BEFORE-RESTORE. Trên site thật, rollback có thể là snapshot volume, database snapshot hoặc một backup riêng; điều quan trọng là đường quay lại cũng phải được probe, không chỉ được viết trong tài liệu.
Những thứ backup plugin không tự giải quyết
Source customization, secret, object storage, DNS/CDN, mailbox, queue backend và dịch vụ thanh toán có vòng đời riêng. Với code, giữ Git/release manifest và dependency lockfile. Với secret, dùng secret manager hoặc vault phù hợp. Với S3/R2, bật versioning/lifecycle nếu hạ tầng cho phép và test quyền đọc từ môi trường khôi phục.
Sau restore, một shortcode động cũng nên được smoke test vì database đúng chưa chắc cache và context đã đúng. Bài test cache và escape cho Botble shortcode có matrix nhỏ để kiểm output theo locale, role và revision dữ liệu. Đặt probe đúng lớp sẽ tránh cảnh “database pass” nhưng trang công khai vẫn trả HTML cũ.
Lịch diễn tập nên ngắn và có owner
Site thay đổi thường xuyên có thể chạy backup hằng ngày nhưng rehearsal theo tháng; site ít đổi có thể diễn tập trước mỗi lần update lớn. Sau khi đổi storage driver, database engine, theme hoặc plugin quan trọng, nên chạy lại sớm vì phạm vi đã thay đổi. Đừng biến lịch tham khảo thành SLA giả cho mọi dự án.
Mỗi lượt chỉ cần lưu manifest, kết quả probe, thời gian thực hiện, lỗi và người chịu trách nhiệm sửa. Không lưu secret hoặc dump production vào báo cáo. Khi một probe fail, artifact chưa đạt chuẩn cứu site dù job tạo backup có màu xanh.
Chốt lại: backup Botble có giá trị khi inventory đủ, artifact có hash, restore chạy trong môi trường tách biệt và probe bắt được cả lỗi có chủ đích. Một file tồn tại mới là điểm bắt đầu. Restore rehearsal mới biến nó thành phương án phục hồi có thể tin.
