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.

 

[King555]

Thanks for the replies. I will now think about how I will do it in the future.

In my case the backups are only stored on an external SFTP space, not locally on the server. This applies to the backups of individual sites, the server-wide backup without the user data is backed up locally and externally.

 

[trialotto]

@King555

Did you mean FTPS? Or do you really implement SFTP?

If you do implement SFTP, then please note that this is quite unreliable in any environment, certainly in a Plesk environment.

In most cases (and in many tests that were performed by me), data transfer is interrupted quite fast and backups do not really resume automatically (but that depends on many factors, some of which can be mitigated to some extent).

In general, if you have

- individual site (or better, subscription) backups to remote storage,
- server-wide backup (without user data) locally and externally,

then that backup setup is - mostly - fine.

A problem can arise when your local server breaks down into oblivion.

I would recommend that you add the user data to your server-wide backup ....... and simply run the scheduled backup task less frequently and only keep 1 or 2 copies (retention rate 7 days, max 1 or 2 backups) in order to keep the disk usage to a minimum : this way, you will have fast restore from your local server AND a safeguard (of all data!) in the form of an external backup, which should allow you to restore all data from the remote to the local server or even - with some tweaks - move the backup file from the remote to the local server and restore all data (more fast) from the local server.

Personally, I use the above to be sure ........ but in daily practice, I prefer to run a sync between two or more servers : this works fastest, since failure of one server will not require a backup-restore process, but a simple DNS redirect (for a limited time) and a renewed sync (after server repair of the failed server).

Kind regards....

 

[King555]

You are absolutely right, I use FTPS, as Plesk does not support SFTP by default. I do several other backups via SFTP (with Bash scripts), which works fine.

And when I said "site" I actually meant subscription.

EDIT: Wrong again, I also use FTPS in the scripts. I only use SFTP when using a software on my PC.