Search results

In general I recommend to use another FTP storage or one of cloud storages (Amazon S3, Google Drive, OneDrive, Dropbox) to avoid such errors.

The backups with such errors may be not valid and not usable because of issues with network/remote storage.

Can you open such backups in Backup Manager and restore some data?

Customer's backups are deleted in GUI on the page Also make sure a customer has permissions to manage his own backups: Backup and restoration of account data using the server storage Backup and restoration of account data using remote storage

It looks like the file backup_xyz.de_2002120547.tar is empty and cannot be rotated automatically.

Try to enable verbose logging in /usr/local/psa/admin/conf/panel.ini and in /usr/local/psa/admin/share/pmmcli/pmmcli-rc and try to find errors in - /var/log/plesk/panel.log - /var/log/plesk/PMM/migration.log

These are known issues in Backup Manager that shall be fixed soon.

I cannot reproduce the issue in our environment. Could you provide the archive backup_info_2001280731_2002020231.xml.tar?

It may occur once after upgrade to 18.0.23.

Could you provide here or in a private message listing of files from backup index files that you mean should not be included to incremental backups? The backup index files looks like /var/lib/psa/dumps/domains/example.tld/.discovered/backup_info_2001241746/cid_user-data and can be viewed via command

From which version of Plesk did you upgrade?

Currently Plesk checks free disk space in DUMP_D directory and really uses it. I am not sure you need huge DUMP_TMP_D directory in Plesk 18.

You can create multi-volume backups, in this case Plesk needs 2 x volume size free disk space. But you always need at least 1 x subscription size to restore data from backups.

Plesk needs about 2 x subscription size free disk space in your case.

You should change DUMP_D in /etc/psa/psa.conf too. It is main place where local backups are stored.

Strato said they fixed the issue. You can try to use HiDrive S3 again.

I am sorry Strato does not agree they have the bug and they do not provide any proof. The ticket number is 2019072401000031. You can try to contact them yourself.

It looks like there is a bug in HiDrive S3 API. When Plesk Backup Manager trying to get specified range of a backup file, e.g. 121151589-131637348 bytes, HiDrive S3 API returns different range ‭52428800‬-53477375 bytes that causes Plesk Backup Manager cannot find a base backup and creates a full...

There are no neither migration.log nor pmmcli.log there.

man pigz I do not see way how restoration of big numbers of files can be speeded up significantly via using filesystem-based backups. The only possibility is creating raw dumps of block devices but it requires at least mount each webspace to its own partition.