Error restoring one database from plesk 12.5 backup

[JuanjoSC]

Hi,

I tried to restore one database from a backup.
And has given me this error.

"Error: Unable to import file as dump: The file you are trying to upload is not a valid backup file"

The backup is a full server incremental backup, they are 13 Gb in external ftp.

I'm using CentOS 7 + Plesk 12.5 from fresh installation (OVH)

 

[UFHH01]

Hi JuanjoSC,

Could you please check, if the following KB - article and its suggestions already solves your issue?

[How to] Backup is shown as invalid in Parallels Plesk interface. How can I verify it? ( KB - article 6080 )
​

Please consider as well, to have a look at the log - files, because often enough you will find usefull informations about an error/issue there.

 

[JuanjoSC]

Hi UFHH01,

Thanks but this is not my problem.
The message appears when I try to restore after many minutes waiting.

The backups list appears all in green.

 

[JuanjoSC]

I do not understand anything.
Now I tried again and it worked well.

This morning gave these errors:

[2015-10-31 08:58:01] ERR [panel] No se ha encontrado ningún archivo de backup.
[2015-10-31 09:00:36] ERR [panel] Get dump 'backup_1510250825_1510310233.tar': Repository error: File 'backup_1510250825_1510310233.tar' not found

[2015-10-31 09:00:36] ERR [panel] No se ha encontrado ningún archivo de backup.
[2015-10-31 09:09:20] ERR [panel] Unable to import file as dump: The file you are trying to upload is not a valid backup file

Can it be that being in ftp, has tried to restore before copying locally?

 

[UFHH01]

Hi JuanjoSC,

unfortunately you didn't really read the KB - article. You would have noticed, that a restore process as well validates backups and its dumps. I didn't choose the suggested KB - article because of the title, but because of the suggestions, how to validate backups and its dumps.

Can it be that being in ftp, has tried to restore before copying locally?

This depends on your backup settings. If you choosed "compression", then the backup will be stored as "*.tgz" on your FTP, which is not a valid backup - file. I always recommend "no compression", because you avoid issue/errors, caused by the compression process, which is harder to investigate.
Another reason can be FTP - connection issues. The upload from the FTP - server hasn't been completely finished, but the verfify - process and a signature check has already been started. The options "Upload backup files without a valid signature" and "I want to restore this backup despite the fact that it does not have a valid signature" can avoid again some errors/issues.

To investigate issues/errors, you shouldn't guess things ( that's only time-investing and may not be related to facts ), but rather investigate them with the help of logs. It helps as well to use another log - level ( debug mode ), so your log will contain a more verbose output of the processes. It's as well a very good idea to try things more than once, before investigating issues/errors - often enough its just a temporary issue, or a non-reproducable failure.