• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Backup fails since update to Plesk Obsidian 18.0.26: "Unable to validate the remote backup"

@DenisG

Here the log information

ag --log -C resume
backup.log

3098-[2020-04-25 03:03:12.254|27856] INFO: Curl output: > SIZE backup_xxxx_2004250300.tar
3099-[2020-04-25 03:03:12.274|27856] INFO: Curl output: < 213 6684302336 3100:[2020-04-25 03:03:12.274|27856] INFO: Curl output: * Instructs server to resume from offset 6683253760 3101-[2020-04-25 03:03:12.274|27856] INFO: Curl output: > REST 66832537603102-[2020-04-25 03:03:12.293|27856] INFO: Curl output: < 350 Restarting at 6683253760. Send STORE or RETRIEVE to initiate transfer


I hope it help to get this new error resolved
 
There was issue PPPM-11825 in Plesk Obsidian < 18.0.26.

If workarounds above do not help I recommend 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/PMM/backup-<date_time>/backup.log especially in lines with text "Curl output:".

Hi, I tried your suggestions, this is the output of my /var/log/plesk/PMM/backup-2020-04-26-01-28-20-767 with #cat backup.log | grep Curl | grep error:

[2020-04-26 01:28:26.445|15915] INFO: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: RETR backup_2004170128_2004250129.tar: Last FTP response: 425 Unable to build data connection: Operation already in progress
[2020-04-26 01:28:40.671|15935] INFO: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: LIST Last FTP response: 425 Unable to build data connection: Operation already in progress: Please, try to use passive mode
[2020-04-26 01:28:49.720|15942] INFO: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: LIST Last FTP response: 425 Unable to build data connection: Operation already in progress: Please, try to use passive mode
[2020-04-26 01:33:55.639|15947] INFO: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: LIST Last FTP response: 425 Unable to build data connection: Operation already in progress: Please, try to use passive mode
[2020-04-26 01:34:01.933|22440] INFO: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: LIST Last FTP response: 425 Unable to build data connection: Operation already in progress: Please, try to use passive mode

I am going to try the passive mode in combination with the "ftpForbidReuseConnection = 1" option and get back here tomorrow.
 
@DenisG

Here the log information

ag --log -C resume
backup.log

3098-[2020-04-25 03:03:12.254|27856] INFO: Curl output: > SIZE backup_xxxx_2004250300.tar
3099-[2020-04-25 03:03:12.274|27856] INFO: Curl output: < 213 6684302336 3100:[2020-04-25 03:03:12.274|27856] INFO: Curl output: * Instructs server to resume from offset 6683253760 3101-[2020-04-25 03:03:12.274|27856] INFO: Curl output: > REST 66832537603102-[2020-04-25 03:03:12.293|27856] INFO: Curl output: < 350 Restarting at 6683253760. Send STORE or RETRIEVE to initiate transfer


I hope it help to get this new error resolved

It is not error. When Backup Manager opens a backup it gets its size and then read 1 MB of data from the end.

You need to looking for lines with 'Curl error' strings.
 
You need to looking for lines with 'Curl error' strings.

If i search for curl error i get NO results.
I believe i now have tied all without any success. It would be great if plesk reached out to get this fixed asap
 
I cannot reproduce the issue. In general I can recommend to use pure FTP servers (not proxy for cloud storages because they are often not fully compatible with pure FTP servers) or submit a request to Plesk support.
 
These are the possible ways for my FTP backupspace.


1587975335345.png

Why has all worked OK for years, and now since this update it gives this Worring ERROR :-(
Since your suggestion i just Added Tick for "Use Passive mode"
 
Can you open in Backup Manager backups created before Plesk update? And what was previous version of Plesk?
 
Ubunut Server was installed with 17.8x and we on a regular basis

apt-get update && apt-get upgrade && plesk installer update && plesk daily ExecuteSpamtrain

If i do MANUAL Backup to ftp I get NO LOG error.
Its only for scheduled Backups
 
Make sure your scheduled backups do not rewrite each other (may be from different servers). Also check you have not duplicate records in BackupsScheduled table.
 
All backups are done at different night times for each domain. The ftp box is per server.

If i do manually backup its mainly done in the daytime

So just check what has actually changed for backup handling from plesk side as it was good all years before.
 
It just suddenly stopped working at the first scheduled backup after that patch, had this running perfectly for years before.
 
I have reproduced the issue with Hetzner's storage box but it looks like the issue is on Hetzner's side because of it is reproduced via curl command too.

I tried to upload a test file about 2 MB size
curl -v -s -S --ftp-pasv --ssl -k -u uNNNNNN -T test.file 'ftp://uNNNNNN.your-storagebox.de/dumps/'

and got the following error
...
< 450 Transfer aborted. Link to file server lost
* server did not report OK, got 450
* Connection #0 to host u230962.your-storagebox.de left intact
curl: (18) server did not report OK, got 450

Also size of the file uploaded 1753088 bytes was not equal original size 2007844 bytes.

I have created ticket #2020043003003391 to Hetzner.
 
I am running my server with Ubuntu 18.04. Since the Update to Plesk Obsidian 18.0.26 the incremental backup to my FTPS server fails with a message like this:

Code:
Error:
Export error: Size of volume backup_2004190206.tar 2144821247 does not match expected one 2146435072. The remote backup may not be restored.
Error:
Unable to validate the remote backup. It may not be restored. Error: Unable to extract dump header

Files are stored successfully on the remote backup server. I am using the following settings:
- Create a multivolume backup, volume size (MB) of 2047 MB
- Stored in FTP(S) only.
- Exluding Log
I have to backup 400+GB to FTP every day, that is inefficient if some subscriptions did not change at all in size, why should Plesk have a need to backup everything?
 
Back
Top