Issue Downloading a backup from Plesk server creates 2 files

[Daveo]

Server operating system version

Debian 12

Plesk version and microupdate number

18.0.80 #4

Downloading a backup from either of my Plesk servers, creates a home.html file and a <random>.crdownload file (the .crdownload file is the valid backup once I rename it to backup_YYMMDDHHMM.tar).

This started happening a few updates ago, can't remember when as I had a difficult year with family (lost Dad about 3 months ago).

Before it use to be just the backup_YYMMDDHHMM.tar file downloaded.

I have tried Brave, Chrome, Firefox & Microsoft Edge. All with the same result, so it's not a browser issue.

 

[Kaspar]

What's in the home.html file?

The .crdownload file extension is the default file extension used by Chromium browsers (hence the cr prefix in the extension name) for temporary partial files. Usually it indicated that a browser hasn't finished the download yet. Firefox used the .part file extension for the same purpose.

But it doesn't necessarily mean it's a browser issue. Could very well be that something prevents the browser to actually finalize the download. This could be server side, but just as well a network issue at your end. Are the downloads listed as completed in the download history of the browser?

Sorry to read about your dad. My condolences to you and your family.

 

[Daveo]

The download does complete and show as completed in browser's download history.

Contents of html file is the code for the home page of the Plesk control panel (attached to post inside a zip file, as can't attach html files).

The .cr file once I've rename it to backup_YYMMDDHHMM.tar is fully complete and opens without errors and extracts without errors.

 

[Daveo]

Any update on this please, as it's still occurring and not sure how to fix it myself.

 

[Sebahat.hadzhi]

@Daveo , our developers are looking into similar report. As of this moment, I cannot provide any insights on what the root cause for the wrong format during downloads is. I will follow up as soon as more details are available. Thank you for your patience in the meantime.

 

[Daveo]

OK. Many thanks for the update.

 

[Sebahat.hadzhi]

@Daveo , could you please confirm if you have tested the download from one browser? If yes, could you please try with another browser? According to our team's tests it appears that the issue is isolated to Chrome only. Thanks in advance for your cooperation.

 

[Daveo]

I've tested with the following browsers:

Brave (Chromium based): Has the issue
Chrome: Has the issue
Edge (Chromium based): Fine, no issue
Firefox: Fine, no issue

Brave is my main default browser that I use and the one that I first noticed the issue with.

Weirdly, Brave is based on Chromium not Chrome and has the same issue as Chrome, yet Edge which is also based on Chromium does not have the issue and completes the backup file download correctly. This is the bit that puzzles me, two Chromium based browsers but only one has the same issue as Chrome and the other doesn't.

 

[cmartinez127]

Hi! Is there any update on this issue? It's happening to me on Chrome for example, but downloads fine on Firefox.

 

[Sebahat.hadzhi]

@cmartinez127 , the issue is still under investigation. There are some hypotheses, but the root cause is still not 100% confirmed. I will provide an update as soon as I hear more from our developers.

 

[Sebahat.hadzhi]

The behavior is confirmed as a bug with ID PPPM-15524. The reason for the issue is that the backup download starts with a POST request, with dumpId in the URL and type and password in the request body. The password cannot be included in the URL, so POST is required. If Chrome automatically resumes an interrupted download, it retries with a GET request instead of the original POST, causing type and password to be lost.

As a workaround you can either rename the Unconfirmed *.crdownload file to .tar, or use Firefox for the download.

A fix is expected in one of the upcoming Plesk releases, but I cannot provide an ETA as of the moment. Everyone's patience is appreciated.

 

[alapshin]

A bit more details what actually happens

When we click Download in the Backup Manager, Plesk does not simply hand over a file from disk. It starts an export process, and the download request carries some parameters that the panel needs. These parameters were sent in the body of the request.

In this case, the download was interrupted because of a temporary local file error. This can happen when antivirus or Windows defender temporarily locks the file while the browser is downloading, or renaming it. The browser treats this type of error as temporary and automatically retries the download without any action from the user. But different browsers act differ:

- Chrome repeats the download as a plain request without the body. The parameters are lost, and that is when the panel returns its HTML page and we end up with two files.
- Firefox repeats the download with the body intact. The parameters arrive normally, the server sends a real backup stream, and the problem never occurs.

So the difference is only whether a browser preserves the request body when it retries. Chrome drops it; Firefox replays it.