[Bug]: Auto-update failures leave configuration backups behind and can fill the filesystem

[Fabrizioso]

Describe the bug

When a Pulse auto-update fails after the installer has created a configuration backup under /opt/pulse/config-backups/, the newly created backup is not removed.

The next automatic or manual update attempt creates another full configuration backup. Repeated failed updates therefore progressively consume disk space.

In my case, this eventually filled a 4 GB Proxmox LXC root filesystem to 96% and prevented further updates. More importantly, once an update starts failing because of insufficient disk space, every retry makes the disk-space problem worse.

Pulse itself correctly detects insufficient space and suggests removing old backups, but because the automatic updater retries periodically, additional backups can accumulate without user intervention.

To reproduce

1. Run Pulse using the systemd installation with automatic updates enabled.
2. Have enough free disk space for the installer to create a configuration backup, but not enough for the subsequent update staging requirement.
3. Trigger an update, e.g.:
   systemctl start pulse-update.service
4. The installer creates a backup under:
   /opt/pulse/config-backups/pulse.backup.<timestamp>
5. The update subsequently fails its disk-space/staging check.
6. Check /opt/pulse/config-backups/. The newly created backup remains.
7. Trigger the update again.
8. Another full configuration backup is created and also remains after failure.
9. Repeated retries progressively consume the remaining filesystem space.

This happened during an attempted update from Pulse v6.3.2 to v6.4.1.

Before cleanup, these backups had accumulated:
293M pulse.backup.20260826-190649 439M pulse.backup.20260829-032144 456M pulse.backup.20260830-031504 461M pulse.backup.20260831-041357

Total size was approximately 1.7 GB.

After manually deleting old backups, the filesystem had approximately 1.4 GB free. I triggered the updater manually.

The first failed attempt created another approximately 496 MB backup. The next attempt created another approximately 479 MB backup.

As a result, disk usage went from 64% to approximately 90% after only two failed update attempts.

Expected behavior

A configuration backup created as part of an update should not remain indefinitely after that update fails.

Possible expected behaviours would be:

• Remove the newly created configuration backup after a failed update has been rolled back successfully.
• Apply a bounded retention policy to /opt/pulse/config-backups/.
• Before creating a new backup, prune sufficiently old update backups.
• Ensure that automatic retries caused by insufficient disk space cannot consume additional persistent disk space on every retry.

In particular, an update failure caused by low disk space should not make the low-disk-space condition progressively worse.

Additional actionable topics

Seems this has been reported earlier in #1646 but either is a regression or not completely solved?

Pulse version

v6.3.2

Agent version

none

Image tag or digest

No response

Installation type

Docker

Relevant logs or diagnostics

Filesystem when the problem was discovered:
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/pve-vm--107--disk--0  3.9G  3.5G  161M  96% /

Backup usage:
293M  /opt/pulse/config-backups/pulse.backup.20260826-190649
439M  /opt/pulse/config-backups/pulse.backup.20260829-032144
456M  /opt/pulse/config-backups/pulse.backup.20260830-031504
461M  /opt/pulse/config-backups/pulse.backup.20260831-041357
1.7G  /opt/pulse/config-backups

First manual retry after freeing disk space:
[INFO] Backing up existing configuration...
[ERROR] Not enough free disk space to stage the Pulse update
[INFO] The same filesystem backs /tmp and /opt/pulse
[INFO] Available: 814MB, required: 1GB
[INFO] Free disk space and retry the update
Update installation failed
Restoring from backup
Update failed

After that failure, a new backup remained:
~496M  pulse.backup.20260920-155450

Second retry:
[INFO] Backing up existing configuration...
[ERROR] Not enough free disk space to stage the Pulse update
[INFO] The same filesystem backs /tmp and /opt/pulse
[INFO] Available: 337MB, required: 1GB
[INFO] Free disk space and retry the update
Update installation failed
Restoring from backup
Update failed

After the second failure:
461M  pulse.backup.20260831-041357
496M  pulse.backup.20260920-155450
479M  pulse.backup.20260920-155527
~1.5G total

Confirmations

• I verified the exact Pulse version and image reference from the running instance.
• I searched existing issues for duplicates.

[pulse-triage]

On v6.4.0 and v6.4.1 the installer bounds this: it checks free space before taking a configuration snapshot and keeps only the newest five, so a retry loop cannot grow config-backups without limit. Your install is v6.3.2, which predates both checks — free enough space for the update and retry, then confirm on v6.4.1. If it still grows there, reply with ls -la /opt/pulse/config-backups.

How Pulse handles triage

[Fabrizioso]

Maybe an idea for improvement:
Keeping 5 snapshots also is consuming a lot of disk space. Pulse would easily run on a 4GB disk but with around 2GB of snapshot data and a 1GB free memory requirement for upgrades it needs a bigger disk just because of the snapshots.
Maybe this should be either configurable or the pruning mechanism should consider the total available disk space and keep fewer snapshots on smaller disks.

[pulse-triage]

The retry accumulation is fixed for the next 6.4.x preview: when an update aborts at the staging disk-headroom check, the snapshot taken for that attempt is now removed, so a retry loop no longer consumes space.

Retention remains a fixed five snapshots. A configurable or free-space-aware limit is recorded as a request; no version for it yet.

How Pulse handles triage

[pulse-triage]

v6.4.5-rc.1 is published with the staging-cleanup fix. Update with sudo /bin/update --version v6.4.5-rc.1 and confirm a failed update no longer leaves its configuration backup behind. Post the result here.

How Pulse handles triage