Question Plesk Backup Manager uploads first and deletes afterwards – how to switch this?

[King555]

Server operating system version

Ubuntu 24.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.82 Update #2 Web Admin Edition

My websites are backed up daily with incremental backups automatically by Plesk. My storage has 100 GB, the backups are 75 GB in size. One of the backup files (when starting a new incremental cycle) is a little bit over 25 GB. It seems that Plesk uploads the new file first and then deletes the old file. This leads to an error, because the space is not enough (a little bit over 100 GB is needed). So the incremental cycle stops at this point (old file is never deleted, because the new file is never uploaded).

What can I do in this case?

 

[Kaspar]

This is expected behavior and cannot be changed. It's fail safe logic; if the new backup fails (for whatever reason), the previous backup is still available for recovery. Having the previous backup deleted first would leave administrators with no (recent) backup if the new backup fails.

As a workaround however, you can create a custom script to the delete the previous back and run that's script with a cron job just before the the daily backup is scheduled. Below is an example Shell script to get you started. I assumed you store the backup locally on the same server. The script simply deleted yesterday's locally stored backup. If haven't tested this thoroughly, so use with caution.

#!/bin/bash
# Delete yesterday's Plesk server-wide backup via pmm-ras

PMM=/usr/local/psa/admin/bin/pmm-ras
DUMPS=/var/lib/psa/dumps
YESTERDAY=$(date -d "yesterday" +%y%m%d)

for f in "$DUMPS"/backup_info_${YESTERDAY}*.xml; do
    [ -e "$f" ] || continue
    "$PMM" --delete-dump --dump-specification="$(basename "$f")"
done

 

[trialotto]

@Kaspar

I like the script, but it is rather "deterministic" in the sense that it is limited to one day back.

In essence, your script is quite the opposite of the backup logic in Plesk ........... since it removes those backups that Plesk wants or even needs and, moreover, that Plesk already deletes when the "number of backups to retain" is configured.

However, it is good to change that logic, since the local backups can really consume a lot of "unnecessary" space.

Could you be so kind as to add a variable that allows for a x-day retention rate?

That is, all local backups older than x days could or should be removed.

Kind regards...

 

[Kaspar]

@trialotto, it's just an simple example to demonstrate a workaround via command line options specific for the OP's issue. Not a full featured script for that accounts for a multitude of use cases. It's available for any one to use and adapt to their own needs, including yourself

 

[trialotto]

@trialotto, it's just an simple example to demonstrate a workaround via command line options specific for the OP's issue. Not a full featured script for that accounts for a multitude of use cases. It's available for any one to use and adapt to their own needs, including yourself

@Kaspar,

That would be a rather logical conclusion.

However, deleting the 1-day old backup files might not be the best idea ....... whereas the deletion of older backup files still is not a good idea (I admit !), but it is slightly better : the whole concept of Plesk backup logic should take care of the removal of old backup files (being either 1-day old or x-days old), but there is this odd behavior with failing Plesk backups that causes very old backup files to persist locally.

Hence the request ........ it is a simple suggestion to change your script to one that allows for deletion of all old backups that exceed a specific number of days (and that, by default Plesk backup logic, should not be present anymore).

Nevertheless, fair point : anybody should adopt and change the script as they seem fit.

Kind regards...

PS In some sense, your logic with respect to freedom of users to use and adopt your bash script is equivalent to "you sharing, others not sharing and having an incentive to not share". So, yes, fair point to not change / adopt the script yourself and/or to allow other people to adopt the script to fit their needs. The actual downside of this approach is that we will have some posts of failed backups and/or failures to restore backups in the near future, since some people will adopt and change the script perfectly and other people will not.

I am happy that you at least made an effort and that @Sebahat.hadzhi noticed the script ............ after all, these kinds of minor adjustments to Plesk backup logic are essentially the domain of Plesk. It is something that can add value and that should have been introduced years ago.