Personal Ops Runbook

1. Tổng quan Bài này giải thích cơ chế backup của Proxmox khi kết hợp với Proxmox Backup Server (PBS): cách nó đóng gói metadata VM, cách cắt dữ liệu thành chunk, cách dedup giữa các backup/giữa các VM, và vì sao cách này thực tế lại có lợi hơn so với việc chỉ dùng lệnh kiểu rbd snap/export của Ceph. Cuối bài sẽ có ví dụ để nhìn rõ chuyện “nhiều VM giống nhau nhưng dung lượng tăng rất ít”.

2. Các lớp dữ liệu Proxmox cần backup 2.1. Những thứ Proxmox muốn giữ lại

• Metadata của VM: cấu hình CPU, RAM, disk, bus, EFI/BIOS, NIC, MAC, cloud-init.
• Disk của VM: toàn bộ block dữ liệu của từng volume mà VM dùng (vm-100-disk-0, vm-100-disk-1…).
• Thông tin phiên bản backup: thời gian, khách hàng (client), job, notes.

3. Lưu metadata như thế nào 3.1. Cách làm

• Proxmox sẽ xuất cấu hình VM ra dạng text (kiểu như file /etc/pve/qemu-server/100.conf).
• Thông tin này được gói kèm trong snapshot/backup như một “manifest”.
• Bên PBS sẽ lưu một bản “định nghĩa” (manifest) này cạnh dữ liệu disk.

3.2. Lợi ích

• Khi restore chỉ cần chọn backup → Proxmox biết phải tạo lại VM với đúng số vCPU, đúng dung lượng disk, đúng model NIC.
• Không phải tạo VM mới rồi tự gắn disk như khi chỉ export RBD.

4. Cơ chế chunk dữ liệu 4.1. Ý tưởng

• Thay vì lưu nguyên file disk lớn (ví dụ 100G), PBS chia dữ liệu đến từ Proxmox thành các khối nhỏ (chunk), kích thước cố định (ví dụ 4 MiB).
• Mỗi chunk được tính hash (thường là một dạng nội dung băm).

4.2. Luồng

[Proxmox VM disk stream]
          |
          v
   cắt thành chunk
   (4 MiB, 4 MiB, ...)
          |
          v
   hash từng chunk
          |
          v
  nếu hash đã có -> chỉ tham chiếu
  nếu hash chưa có -> lưu mới

4.3. Ý nghĩa

• Chỉ những chunk chưa từng thấy mới chiếm dung lượng thật.
• Các chunk giống nhau giữa nhiều VM/lần backup sẽ dùng chung.

5. Dedup được thực hiện như thế nào 5.1. Mức độ dedup

• Dedup ở mức datastore của PBS, không phải ở mức từng VM.
• Nghĩa là hai VM khác nhau vẫn có thể dùng chung chunk nếu dữ liệu trùng.

5.2. Cơ chế

• Khi nhận một chunk, PBS tính hash.
• Nếu hash tồn tại trong datastore → PBS chỉ ghi “trong backup này có chunk đó” chứ không ghi lại nội dung.
• Kết quả: các bản backup sau, hoặc các VM giống nhau, tăng rất ít dung lượng.

5.3. Hệ quả

• Template chuẩn cho nhiều VM càng giống nhau → hiệu quả dedup càng cao.
• Backup định kỳ (hằng ngày) càng lâu → phần trùng càng nhiều, chỉ phần thay đổi mới tăng.

6. So sánh với backup RBD thuần của Ceph 6.1. Backup RBD thuần

• Bạn tự rbd snap create rồi rbd export image.
• Bạn sẽ có một bản dump đúng nội dung block của image đó tại thời điểm snapshot.

• Nhưng:

• Không có metadata VM của Proxmox (CPU, RAM, NIC…).

• Không có dedup giữa nhiều VM một cách tự động.
• Không có cấu trúc “backup chain” theo thời gian.
• Bạn phải tự nhớ tên image/pool.

6.2. Lợi thế của Proxmox/PBS

• Có manifest → restore 1 lần ra đúng VM.
• Có chunk + dedup → nhiều VM giống nhau không tốn gấp nhiều lần dung lượng.
• Có incremental dựa trên dirty-bitmap → lần sau chỉ gửi phần đổi.
• Có giao diện quản lý, expiry, verify.
• Không phụ thuộc vào 1 storage: hôm nay disk Ceph, mai chuyển ZFS vẫn backup theo cùng format.

6.3. Nói gọn

• Ceph RBD backup thuần: tốt để bảo vệ image cụ thể, ít tầng trừu tượng.
• Proxmox/PBS: tốt để bảo vệ “VM” như một thực thể hoàn chỉnh và để tiết kiệm dung lượng lâu dài.

7. Ví dụ để thấy lợi thế 7.1. Ví dụ 1: Một VM duy nhất

• VM disk: 100G
• Dùng thực: 20G
• Lần backup đầu lên PBS: quét đủ 100G nhưng chunk zero/dễ nén không chiếm nhiều → datastore tăng ~20G.
• Metadata ghi rõ: VM này disk 100G.

7.2. Ví dụ 2: Nhiều VM cùng template

• VM1: từ template Ubuntu, cài thêm 2G package → backup đầu ~8G.
• VM2: cũng template đó, chỉ đổi hostname → phần OS trùng với VM1 → PBS chỉ phải lưu thêm phần khác (hostname/config nhỏ) → datastore tăng rất ít.
• VM3: cài thêm app 3G → PBS chỉ lưu chunk mới 3G, còn phần OS gốc dùng chung chunk với VM1/VM2.

7.3. Ví dụ 3: Backup định kỳ

• Ngày 1: full đầu tiên → 10G.
• Ngày 2: VM ghi thêm 500 MB log → backup chỉ gửi chunk của 500 MB đó.
• Ngày 3: không đổi gì đáng kể → backup gần như chỉ sinh metadata phiên bản mới.
• Với RBD export thuần, nếu bạn export lại mỗi ngày thì ngày nào bạn cũng có 1 file ảnh lớn, không chia sẻ được dữ liệu giữa các ngày.

8. Lời khuyên 8.1. Nên dùng PBS nếu:

• Có nhiều VM được build từ cùng một template.
• Backup hằng ngày/giờ và cần tiết kiệm dung lượng dài hạn.
• Muốn restore nhanh bằng GUI mà không phải tạo lại VM bằng tay.

8.2. Tối ưu để dedup tốt hơn

• Chuẩn hóa template (cùng OS, cùng version).
• Bật TRIM/discard trong VM để block trống thật sự là zero → chunk dễ trùng.
• Hạn chế sinh dữ liệu ngẫu nhiên lớn (file log dạng binary không nén được).

8.3. Khi vẫn muốn giữ kịch bản Ceph thuần

• Có thể kết hợp: Ceph snapshot để rollback rất nhanh nội bộ storage, PBS để giữ bản backup “ở ngoài” và quản lý phiên bản.
• Nhưng đừng kỳ vọng Ceph snapshot sẽ tự dedup giữa 10 VM khác nhau như PBS.

9. Kết luận

• Cơ chế backup của Proxmox/PBS xoay quanh việc: lấy metadata VM → cắt dữ liệu disk thành chunk → băm → dedup trong datastore.
• Cách này giúp nhiều VM giống nhau hoặc nhiều lần backup của cùng một VM gần như không nhân đôi dung lượng.
• So với việc chỉ backup RBD của Ceph, Proxmox/PBS mang lại thêm tính đầy đủ (metadata VM), tính tiết kiệm (dedup), và tính vận hành (GUI, verify, retention).
• Vì vậy trong môi trường có nhiều VM và backup thường xuyên, dùng PBS sẽ hiệu quả và “kinh tế” hơn đáng kể so với backup RBD thuần.