BACKUP_LXC_MP fallback skipped when snapshot is unsupported (v5.1.2)

[X1pheR]

Summary

On Ultimate Updater v5.1.2, an LXC with a mount point can continue to the guest update without the configured BACKUP_LXC_MP backup fallback when pct snapshot returns snapshot feature is not available.

This looks like a regression of the behavior introduced for #204. In that issue the intended behavior was described as: try the snapshot first, and if it fails and BACKUP_LXC_MP=true, make a backup instead.

Environment

• Proxmox VE: pve-manager/9.2.20
• Kernel: 7.0.14-17-pve
• Ultimate Updater: 5.1.2
• Installed branch/tag: master / v5.1.2
• Installed commit: c50abb58468f3751db03e767f629bcee2c5fc306
• Affected guest: unprivileged Debian 13 LXC with rootfs on local-lvm and a bind mount (mp0)

Configuration

SNAPSHOT="true"
BACKUP="false"
BACKUP_LXC_MP="true"
BACKUP_MODE="stop"

Relevant LXC configuration:

rootfs: local-lvm:vm-104-disk-0,size=20G
mp0: /mnt/hermes-docker-hypershell,mp=/srv/hypershell
unprivileged: 1

Observed behavior

During update:

Updating LXC 104 : hermesagent

Start Snapshot and/or Backup
Snapshot not supported for LXC 104; continuing without snapshot

Proxmox task history records the snapshot failure as:

snapshot feature is not available

No vzdump fallback is started, and the package update continues without the requested pre-update protection.

Cause observed in v5.1.2

In CONTAINER_BACKUP, the unsupported-snapshot branch is evaluated before the mount-point backup fallback:

if grep -Eqi 'snapshot feature is not available|...' <<< "$snapshot_output"; then
  echo "Snapshot not supported ... continuing without snapshot"
  snapshot_requested=false
elif [[ "$backup_requested" == true ]]; then
  ...
elif [[ "$BACKUP_LXC_MP" == true ]] && pct config "$CONTAINER" | grep -q '^mp'; then
  backup_requested=true
  snapshot_requested=false
  echo "Changed to backup, because of mount points"
fi

Because pct snapshot for an LXC with this bind mount returns the recognized snapshot feature is not available text, the first branch consumes the failure and the BACKUP_LXC_MP=true branch is never reached.

Expected behavior

For an LXC with mount points and:

SNAPSHOT=true
BACKUP=false
BACKUP_LXC_MP=true

if the attempted snapshot is unsupported, Ultimate Updater should use the configured backup fallback and only continue the guest update after that backup succeeds.

This also seems relevant to #317: that fix states that configured snapshot protection should not be bypassed when no successful fallback exists.

Suggested direction

Handle the mount-point backup fallback before treating a recognized unsupported-snapshot result as a benign continue without snapshot, or otherwise preserve the documented/intended BACKUP_LXC_MP semantics for this case.

[BassT23]

Thanks for the detailed report — the issue is confirmed and fixed on develop.

Root cause: in CONTAINER_BACKUP(), an unsupported snapshot set snapshot_requested=false before the BACKUP_LXC_MP fallback branch was evaluated. With SNAPSHOT=true, BACKUP=false, BACKUP_LXC_MP=true and an LXC mount point, that meant the configured fallback could be skipped and the guest update could continue without the intended protection.

The fix is in commit 552c771.

Behavior now:

• unsupported snapshot + BACKUP_LXC_MP=true + mount point -> run the configured backup fallback;
• unsupported snapshot + BACKUP=true -> run the normal configured backup fallback;
• no configured fallback -> abort the guest update;
• failed fallback backup -> abort the guest update;
• successful snapshot -> no unnecessary backup;
• VM backup behavior remains unchanged.

This preserves the original #204 semantics and the #317 safety guarantee that a guest must not be updated when configured protection could not be created.

Regression coverage includes the exact #334 case, fallback-backup failure, no-fallback safety failure, no-mountpoint behavior, existing BACKUP=true fallback, LXC lifecycle handling, and VM regressions. The full shell test suite passes.

No real guest update or backup was required for the fix validation.

[BassT23]

The fix is now included in v5.1.3 Beta 5.

Beta currently points to 4bd6563affe3542110ddf9c775da407f134103bf, which includes the #334 fix from 552c771.

The Beta 5 validation passed, including the LXC backup-fallback regression coverage and the full CI gate.

The issue will remain open until the corresponding master release; the label has been moved from development to beta for the current release stage.