Personal Ops Runbook

1. Tổng quan Bài này giải thích tại sao trong Proxmox, khi backup một VM đang ở trạng thái stop thì hệ thống lại phải “start” (thực chất là dựng một qemu process tạm) mới backup được. Đồng thời mô tả luôn hành vi khi VM đang chạy sẵn thì Proxmox xử lý thế nào. Mấu chốt nằm ở chỗ Proxmox muốn dùng chung một cơ chế đọc dữ liệu (qua qemu) cho mọi loại storage và muốn xuất ra một bản backup có đầy đủ cấu hình, disk và trạng thái nhất quán.

2. Mục tiêu của Proxmox khi backup 2.1. Các mục tiêu chính

• Đọc được toàn bộ disk của VM theo cách nhất quán.
• Không phụ thuộc vào loại storage (Ceph, ZFS, LVM, file…).
• Đóng gói backup theo một định dạng chuẩn để restore dễ dàng.
• Có thể kết hợp với Proxmox Backup Server (PBS) để chunk + dedup.

3. Vấn đề với VM đang stop 3.1. Trạng thái ban đầu

• Khi VM stop thì không có qemu process tương ứng.
• Nhưng cơ chế backup của Proxmox lại được thiết kế để “nói chuyện” với qemu/drive của qemu để lấy dữ liệu.
• Nếu không có qemu, Proxmox sẽ phải viết đường đọc riêng cho từng backend → mục tiêu “storage-agnostic” bị phá vỡ.

3.2. Giải pháp của Proxmox

• Proxmox tạm thời dựng một qemu process chỉ để:

• mở đúng disk của VM

• đọc lần lượt các block
• stream chúng sang nơi backup (PBS hoặc file vzdump)
• Qemu này không phải để boot OS, không phải để user truy cập.

3.3. Sơ đồ logic

VM (stop)
  |
  | 1. backup job bắt đầu
  v
qemu tạm (mở disk, có lock=backup)
  |
  | 2. đọc dữ liệu disk theo pipeline chuẩn
  v
nơi lưu backup (PBS / file .vma.zst)
  |
  | 3. xong thì tắt qemu tạm
  v
VM trở lại trạng thái stop

4. Tại sao phải làm như vậy 4.1. Dùng chung một pipeline

• Proxmox chỉ cần duy trì một cách đọc duy nhất: “có qemu → đọc qua qemu”.
• Nhờ đó, bất kể disk ở Ceph hay local-LVM, cách backup giống nhau.

4.2. Đảm bảo cấu hình và metadata

• Khi đi qua qemu, Proxmox biết chính xác disk, bus, EFI, thứ tự…
• Bản backup vì thế restore lại sẽ giống VM ban đầu.

4.3. Tương thích với incremental/dedup

• PBS kỳ vọng nhận luồng dữ liệu theo cách Proxmox phát ra.
• Nếu mỗi loại storage phát một kiểu thì việc so sánh chunk, băm hash sẽ khó hơn nhiều.

5. Hành vi cụ thể khi VM đang stop 5.1. Các bước

• Bước 1: Proxmox tạo lock cho VM: lock: backup.
• Bước 2: Proxmox khởi tạo một qemu process tạm. Lúc này API hoặc monitoring có thể thấy VM “giống như đang chạy”.
• Bước 3: qemu đọc toàn bộ hoặc phần cần thiết của disk và gửi đi.
• Bước 4: Backup xong, qemu tạm bị dỡ, lock được bỏ, VM lại về stop.

5.2. Điều quan trọng

• Đây không phải là “start VM để hệ điều hành chạy lên”.
• Đây là “start qemu để có chỗ mà đọc disk”.
• Thời gian qemu tồn tại bằng đúng thời gian backup, nên với backup nhỏ sẽ thấy “lóe lên” rồi tắt.

6. Hành vi khi VM đang chạy sẵn 6.1. Trường hợp VM đang running

• Đã có qemu process thật đang phục vụ VM.
• Proxmox chỉ cần yêu cầu qemu này tạo snapshot/drive-backup (tùy mode: snapshot/suspend/stop).
• Không cần dựng thêm qemu tạm.

6.2. Lợi thế

• Không làm VM đổi trạng thái nhìn thấy được.
• Backup được trạng thái gần như online.
• Nếu guest agent bật, có thể freeze filesystem trước khi chụp để dữ liệu nhất quán.

6.3. Sơ đồ

VM (running) --qemu thật--> backup job --> PBS

7. Ví dụ 7.1. Ví dụ 1: VM stop, backup toàn bộ

• VM: stop
• Storage: Ceph RBD
• Bạn bấm backup → qemu tạm xuất hiện 30 giây → backup xong → qemu biến mất → VM vẫn stop.

7.2. Ví dụ 2: VM đang chạy web server

• VM: running
• Bạn bấm backup → không xuất hiện thêm VM “ảo” khác, chỉ có task backup chạy → VM vẫn phục vụ web bình thường.

7.3. Ví dụ 3: Monitoring đọc API

• Trong thời điểm backup VM stop, API trả trạng thái giống running + có lock=backup.
• Sau đó lại trả về stop → nếu không lọc theo lock sẽ tưởng có người bật VM.

8. Lời khuyên 8.1. Cho người viết monitoring

• Khi gọi API PVE để lấy trạng thái VM, luôn kiểm tra thêm trường lock.
• Nếu lock=backup thì bỏ qua cảnh báo “VM tự bật rồi tự tắt”.

8.2. Cho người muốn nhẹ hơn trên Ceph

• Nếu bạn chỉ dùng Ceph và chấp nhận tự quản lý metadata, có thể tự script rbd snap + export.
• Nhưng khi đó bạn sẽ bỏ qua sự tiện lợi của cơ chế “backup VM” của Proxmox.

8.3. Cho người vận hành

• Ưu tiên backup vào khung giờ ít nhạy cảm để việc VM “lóe” trạng thái không gây hiểu lầm.
• Dùng PBS để tận dụng chunk/dedup, nhất là khi có nhiều VM giống nhau.

9. Kết luận

• Proxmox buộc phải “start” theo nghĩa dựng qemu process đối với các VM đang stop vì cơ chế backup của nó được thiết kế xoay quanh việc đọc disk qua qemu, không phải gọi từng loại storage riêng.
• Với VM đang chạy, qemu đã có sẵn nên backup diễn ra gọn hơn, không tạo thêm trạng thái lạ.
• Việc API/monitoring nhìn thấy VM “bật lên rồi tắt” trong lúc backup là hành vi bình thường và có thể lọc được bằng cách kiểm tra lock.