[RFC] vzdump: opt-in skipping of stopped guests for PBS jobs

[RFC] vzdump: opt-in skipping of stopped guests for PBS jobs

[Bogdan Ionescu]

Hi,

I'd like to get feedback on adding a small, opt-in policy option to scheduled vzdump jobs targeting native Proxmox Backup Server storage:

skip-stopped: <boolean>

Problem

When a QEMU VM is stopped, there is no reusable in-memory dirty bitmap. PVE therefore starts a temporary QEMU process and reads the complete virtual disk so PBS can identify and reuse existing chunks.

The resulting PBS snapshot is still a complete restore point and unchanged chunks are not stored again, but the full source read consumes storage I/O, CPU time, and backup-window time. This is particularly noticeable for large, intentionally powered-off VMs included through an "all guests" or pool-based job.

Some operators also deliberately do not want a new recovery point for a guest while it remains powered off.

Proposed semantics

- Add a boolean skip-stopped option, disabled by default.
- Accept it only for backup jobs targeting native PBS storage.
- Check the guest state immediately before its turn in the job.
- If the guest is stopped, log it as skipped and do not create a PBS snapshot.
- If the guest is running, back it up normally.
- If the state check fails, continue through the normal backup path so the option cannot hide an actual error.
- Apply the same behavior when using "Run now".
- A skipped guest should not make the job fail, but should be clearly shown as skipped in its log and notification.

This is intentionally a policy option, not change detection. A stopped guest is not necessarily unchanged: its disks or configuration may be modified while offline, and it may have run and stopped again between two backup jobs. The UI and documentation should make clear that enabling the option accepts this backup gap.

Relation to bug #3092

This is related to:

https://bugzilla.proxmox.com/show_bug.cgi?id=3092

However, skip-stopped would be a narrower solution. It would not track whether a VM ran since its previous backup and would not replace persistent dirty bitmaps or other change-detection work. It would simply let an administrator explicitly choose not to back up guests that are stopped at execution time.

Implementation

I have a prototype against PVE 9 which adds the option to the shared vzdump schema, checks the state in the PVE::VZDump job loop, exposes it in the backup-job advanced options, and includes documentation and tests.

The prototype currently handles both QEMU VMs and LXC containers, although the strongest performance motivation is the full disk scan for stopped QEMU VMs. It can be restricted to QEMU if that is considered the better initial scope.

Questions

- Would a PBS-only skip-stopped job option be acceptable?
- Should it initially apply only to QEMU VMs or to all stopped guests?
- Is skip-stopped an appropriate name?
- Should skipped guests remain in the job notification table with an explicit skipped state?
- Should direct vzdump invocations support the option as well, or only scheduled jobs?

If the general direction is acceptable, I can send the corresponding patch series for review.

Regards,

Bogdan