Old SFTP Backups Are Not Deleted Because Destination Directory Is Duplicated

Help! (Home for newbies)
1
SYSTEM INFORMATION
OS type and version AlmaLinux 9.8
Virtualmin version Virtualmin 8.1

There appears to be a bug in Virtualmin 8.1 scheduled backups when using an SFTP destination. Old backups are not being deleted because the configured path is being duplicated.

In Destination and Format, the File on Server field is configured as:

01/backup-%Y-%m-%d.tar.gz

However, when the scheduled backup runs and attempts to delete old backups, it looks for them at:

01/01/backup-%Y-%m-%d.tar.gz

The 01 directory is being prepended a second time, causing Virtualmin to search in a non-existent path. As a result, it old backups are not deleted.

The backup itself is created successfully; the issue only affects the deletion of older backups because of the duplicated directory in the path.

2

Hi,

I ran into exactly the same issue on my server and spent some time debugging it with chatgpt. I think I managed to narrow down the cause.

My environment:

  • Virtualmin GPL 8.1.0
  • Ubuntu 24.04
  • Hetzner Storage Box (SFTP, port 23)

My destination is configured as:

daily/%Y-%m-%d

The backups themselves are created correctly under:

daily/2026-07-18
daily/2026-07-17
...

However, during the purge step the log shows:

Deleting backups from dailydaily...
Deleting file daily/daily/2026-07-18 via SSH...

I also noticed something interesting. When connecting directly with the standard OpenSSH SFTP client and running:

ls -l daily

Hetzner returns:

daily/2026-07-12
daily/2026-07-13
...

instead of only the directory names:

2026-07-12
2026-07-13

It looks like Virtualmin prepends the base directory again during the purge, which results in paths like:

daily/daily/2026-07-18

instead of:

daily/2026-07-18

As a temporary workaround, I wrote a small cleanup script using lftp to enforce my retention policy until this is fixed.

Hopefully this helps identify the issue. If you need any additional logs or testing, I’d be happy to help.

3

My thought on this on another similar post was a new server pulling from old stored different server backups, not a big issue for me so I ignored it. The error return intrigued me at the time though.
Paths seemed correct.
Hetzner here then and still.

David

4

I can confirm the bug with SFTP

Deleting backups from backupbackup/cloud12 on SFTP server xxxxxxx.your-storagebox.de matching .*-.*-.* older than 5 days ..
    Deleting file backup/cloud12/2026-07-29 via SSH, which is 6 days old ..
    .. deleted 44 bytes

notice the double “backupbackup”, which should be just “backup”.

Works fine with FTP but I really dont want to use that anymore.

5

I have reported this bug to the issues tracker on github