Proxmox Backup Server không phải nút “backup một lần là xong”. Nó là một hệ thống có datastore, retention, prune, garbage collection, verification, quyền truy cập và có thể đồng bộ sang remote. Chiến lược đúng phải trả lời được backup nằm ở đâu, giữ bao lâu, ai được xóa, dữ liệu có kiểm tra toàn vẹn không và khi mất cả node Proxmox thì restore từ đâu.
PBS giải quyết bài toán nào?
PBS tích hợp với Proxmox VE để nhận backup VM và container theo cơ chế phù hợp, hỗ trợ incremental, deduplication và các thao tác quản trị backup. Điều này giảm lượng dữ liệu lặp nhưng không loại bỏ nhu cầu về dung lượng, network và restore test.
Một datastore nên được xem là thành phần hạ tầng riêng. Nếu datastore nằm cùng một disk hoặc cùng một máy với node nguồn, lỗi phần cứng hoặc ransomware có thể xóa cả production và backup.
| Lớp | Mục tiêu | Câu hỏi kiểm tra |
|---|---|---|
| Datastore | Nơi lưu backup | Disk và quyền có đủ không? |
| Retention | Giữ phiên bản cần thiết | RPO/RTO là bao nhiêu? |
| Verify | Kiểm tra toàn vẹn | Đã chạy định kỳ chưa? |
| Remote/Sync | Có bản sao khác site | Mất node vẫn còn dữ liệu? |
Thiết kế datastore và dung lượng
Tính dung lượng theo full backup ban đầu, tốc độ thay đổi, retention và overhead. Deduplication giúp tiết kiệm nhưng không nên dùng để che giấu việc cấp disk quá nhỏ. Tách OS của PBS và datastore theo khả năng phần cứng để khi nâng cấp hoặc thay disk dễ hơn.
Backup VM chứa disk image và config; backup container thường nhỏ hơn nhưng vẫn có data, config và database bên trong. Dữ liệu ứng dụng có thể cần dump logic trước backup image nếu yêu cầu nhất quán cao. Hãy ghi rõ loại backup nào là crash-consistent và loại nào có application hook.
Retention, prune và garbage collection
Retention nên phản ánh lịch phục hồi: vài bản gần nhất để rollback nhanh, bản theo tuần/tháng để xử lý lỗi phát hiện muộn. Prune loại bản quá hạn, còn garbage collection thu hồi chunk không còn được tham chiếu. Chạy quá aggressive có thể làm mất điểm phục hồi cần thiết; chạy quá rộng sẽ làm datastore đầy.
Không giao quyền xóa datastore cho mọi user. Tạo API token/ACL theo nguyên tắc ít quyền, bật thông báo và theo dõi dung lượng. Nếu có sync offsite, hiểu thứ tự prune ở nguồn và đích để không vô tình xóa bản sao cuối cùng.
Verification, encryption và offsite
Verification định kỳ giúp phát hiện backup/chunk hỏng trước khi cần restore. Encryption phía client bảo vệ dữ liệu khi storage không hoàn toàn tin cậy, nhưng key phải được lưu an toàn; mất key có thể đồng nghĩa mất khả năng phục hồi.
Bản sao offsite có thể qua remote, sync hoặc object storage tùy kiến trúc. 3-2-1 là nguyên tắc, không phải nút bấm: hãy kiểm tra rằng bản sao thực sự khác failure domain và có credentials độc lập.
Restore test cho VM và container
Một job “OK” không chứng minh restore được. Hãy chọn backup đại diện, restore vào ID hoặc node test, kiểm tra boot, network, filesystem, service, database và dữ liệu người dùng. Ghi thời gian restore để biết RTO thực tế thay vì ước lượng.
Test cả trường hợp mất node nguồn và mất access network. Nếu dùng encryption, thử lấy key từ kho an toàn. Nếu application chạy trong container, kiểm tra volume, secret, DNS và webhook sau restore.
Lịch vận hành tối thiểu
Đặt lịch backup theo mức thay đổi dữ liệu, chạy verification, review log, theo dõi datastore và diễn tập restore. Đừng bật retention rồi quên kiểm tra garbage collection. Với homelab, một báo cáo hàng tuần có thể đủ nếu đi kèm alert disk và job failure.
Hãy coi backup là một sản phẩm có người sở hữu. Ghi lại RPO, RTO, danh sách VM quan trọng, thứ tự restore và thông tin liên hệ khi có sự cố.
- Backup khác failure domain.
- Verify trước khi prune sâu.
- Giữ encryption key ngoài PBS.
- Restore test tối thiểu theo tháng.
Backup chỉ có giá trị khi có thể restore trong thời gian chấp nhận được; datastore, retention, verification và bản sao offsite phải được thiết kế cùng nhau.Proxmox Backup Server Documentation — datastore, verification and recovery
Checklist áp dụng nhanh
- Xác định mục tiêu vận hành, ngân sách tài nguyên và người chịu trách nhiệm trước khi cài thêm dịch vụ.
- Tách dữ liệu, secret, cấu hình và quyền truy cập khỏi lifecycle của container hoặc máy ảo; ghi rõ đường khôi phục.
- Đo bằng log, metric, thời gian phản hồi, dung lượng và restore test thay vì chỉ nhìn lệnh cài đặt chạy thành công.
- Thử trên staging hoặc một node nhỏ, lưu output thực tế rồi mới mở rộng sang toàn bộ homelab hoặc production.
Lệnh và cấu hình tham khảo
proxmox-backup-client list
proxmox-backup-client snapshot list remote:store
proxmox-backup-manager datastore list
proxmox-backup-manager garbage-collection start store
qmrestore <backup> <new-vmid> --storage local-lvmLiên kết nội bộ nên đọc tiếp
Nguồn chính thống
Các tài liệu dưới đây là nguồn tham khảo chính thống cho khái niệm và cú pháp trong bài. Phiên bản phần mềm và cách đóng gói có thể thay đổi, vì vậy hãy kiểm tra tài liệu gốc trước khi áp dụng vào hệ thống thật.
Kết luận
PBS giúp backup VM và container có hệ thống hơn, nhưng không thay thế thiết kế 3-2-1, quyền hạn chặt, verification và restore drill. Hãy đo được khả năng phục hồi trước khi coi homelab đã an toàn.
Thiết kế retention theo mục tiêu khôi phục
Retention không nên chỉ là vài con số mặc định. Hãy xác định cần khôi phục về thời điểm nào, giữ bao nhiêu phiên bản hằng ngày, hằng tuần và hằng tháng, sau đó tính dung lượng theo tốc độ thay đổi dữ liệu. Prune giải phóng tham chiếu theo chính sách, còn garbage collection xử lý các chunk không còn được tham chiếu; hai việc này không thay thế verification.
Datastore nên có quyền truy cập hạn chế và không dùng chung tùy tiện với workload ứng dụng. Nếu có remote hoặc sync offsite, hãy kiểm tra thời gian truyền, mã hóa, quota và khả năng khôi phục khi mạng chính không còn.
Restore drill cho VM và container
Mỗi chu kỳ nên chọn một guest đại diện để restore vào mạng cô lập. Xác nhận boot, network, dịch vụ, dữ liệu ứng dụng và secret. Ghi thời gian từ lúc bắt đầu đến lúc người dùng có thể truy cập; đó là số liệu RTO thực tế chứ không phải thời gian job backup hoàn tất.
Phân biệt backup job thành công và bản backup dùng được
Job hoàn tất chỉ chứng minh dữ liệu đã được xử lý theo một quy trình; nó chưa chứng minh restore sẽ thành công. Hãy theo dõi dung lượng datastore, lỗi chunk, thời gian chạy, tốc độ truyền và trạng thái verify. Khi có cảnh báo, cần ghi rõ guest nào bị ảnh hưởng và bản gần nhất còn đáng tin cậy là bản nào.
Với database hoặc ứng dụng có trạng thái, nên phối hợp snapshot hoặc hook nhất quán với lịch backup. Không đóng gói secret vào log, nhưng phải lưu hướng dẫn lấy credential khi khôi phục. Nếu backup nằm cùng điện, cùng rack hoặc cùng host, hãy coi đó là bản sao tiện dụng chứ chưa phải disaster recovery.
Runbook sự cố cho PBS
- Kiểm tra node nguồn, network và thời gian hệ thống.
- Xác định datastore, snapshot và phiên bản gần nhất còn verify.
- Restore vào guest cô lập trước khi thay thế production.
- Ghi lại nguyên nhân, thời gian khôi phục và việc cần cải thiện.
