Applies to: I'm currently using a paid Dropbox account as an offsite backup, but this is relevant for all (offsite) backups.

What happens: When running full server backups, Plesk currently creates a file called server.domain.tld.tar.

The problem: When scheduling (daily/weekly/monthly) full server backups, the new backup file will have the exact same name as the previous backup file.

The result: When selecting e.g. the 12 latest backups to be saved, Plesk backup manager will display these backups as individual entries, but in reality when using a service like Dropbox to create automated off-site backups, the next backup overwrites the previous backup and relies on the version history feature (if available) of your off-site service. In case of Dropbox this is 30 days for a lot of plans.
In another uservoice entry, Plesk team calls this behavior a feature, as it doesn't count against the storage cap when version history is used. However, the availability of version history is way more restricted (and more expensive) than simple storage space.

Suggested solution: Allow users to add a dynamic prefix/suffix like the creation date of the backup to the file name. This simple change would allow users to choose between:
1. having the dynamic prefix (date) in the file name allowing for longer backup history than the off-site service 'version history' dependency allows for, while taking up more storage space.
2. not having a dynamic prefix (date) in the file name, allowing for the use of the off-site service 'version history' feature.

This way users can pick between less storage used or a longer backup history.

In my personal situation I have 2TB of storage, 20GB full server backups that I run once a month. I want to keep 12 backups for a total of ±240GB of storage. This is well within the boundaries of my storage allocation, but is currently impossible as Plesk is overwriting the file, causing a 30 day expiry of my monthly backups instead.