• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Backups Downloaded via RPC API are not valid

C

christoph_peter

Guest
I can retrieve the list of backups and download the backupfiles from my server via the API. When I try to upload them again the server tells me they are invalid. One thing I noticed is they are not tar files unlike the files I get when I manually download a backup.

3571: 2012-04-17 22:53:09,245 DEBUG --> <pmmcli.ImportFileAsDumpAction object at 0x1477710>
3571: 2012-04-17 22:53:09,245 INFO stdin: <src-dst-files-specification guid="6fb5b258-4681-4c55-93f6-a1abf8eb4111" type="domain"><src><dumps-storage-credentials storag$
3571: 2012-04-17 22:53:09,248 INFO Packet succesfully validated.
3571: 2012-04-17 22:53:09,249 DEBUG <pmmcli.ActionRunner object at 0x14776d0>: doActivity
3571: 2012-04-17 22:53:09,251 INFO Executing <subprocess[3572] '/opt/psa/admin/bin/pmm-ras --import-file-as-dump --dump-file-specification=/tmp/phpfrogar --dump-storag$
3571: 2012-04-17 22:53:09,340 INFO Subprocess raised ExecuteException: Subprocess <subprocess[3572] '/opt/psa/admin/bin/pmm-ras --import-file-as-dump --dump-file-speci$
== STDOUT ====================
Repository error: Unknown archive type. Could not get converter for specified dump file 'phpfrogar'

== STDERR ====================

3571: 2012-04-17 22:53:09,340 DEBUG Import file operation ended with errcode=152. Filename is None
3571: 2012-04-17 22:53:09,341 DEBUG <pmmcli.ImportFileAsDumpAction object at 0x1477710>: response
3571: 2012-04-17 22:53:09,341 INFO Outgoing packet:
<?xml version="1.0" encoding="UTF-8"?>
<response>
<errcode>152</errcode>
<errmsg>The file you are trying to upload is not a valid backup file</errmsg>
</response>

the log files also suggest that its an issue with the compression of the backup files. the api documentation does not give any hint about this. I write the data directly to a file as I get it from the server. is there something I need to do with the data, compress it somehow, or should the server do this?
 
Ah I should have included this information:

OS Linux 2.6.32-5-amd64
Panel version 10.4.4 Update #26
The system is up-to-date; last checked at April 16, 2012 06:48 AM

So I think I am running the latest version available.
 
Also uploading and reimporting it via the API returns the same error
 
the files I get via the API are binary as far as I can tell, so I can't validate them. this is a sample of the file that I get after download. http://cl.ly/3L080E0J2c2R003g210T - I also tried to piping the request to the browser and letting the browser handle the download, but it every method creates the same file. it has the right size, so I think the data is all there, its a matter of encoding / compression since this is also where the importer throws the errer
 
This is a sample of the script I am using

<?php
/*
This is usefull when you are downloading big files, as it
will prevent time out of the script :
*/
$headers = array(
'HTTP_AUTH_LOGIN:USER',
'HTTP_AUTH_PASSWD:pW',
'Content-Type: text/xml'
);

$packet=<<<EOP
<packet version="1.6.3.0"><backup-manager><download-file><webspace-id>7</webspace-id><filename>resellers/c.peter/clients/chrillo/domains/drpeter.at/backup_drpeter.at_info_1204172251.xml</filename></download-file></backup-manager></packet>
EOP;

set_time_limit(0);
ini_set('display_errors',true);//Just in case we get some errors, let us know....


$ch = curl_init('https://HOST:' . 8443 . '/enterprise/control/agent.php');

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $packet);
$response=curl_exec($ch);
$fp = fopen (dirname(__FILE__) . '/backup', 'w+');//This is the file where we save the information
fwrite($fp, $response);
fclose($fp);

$info =curl_getinfo($ch);
print_r($info);

print_r($response);
print_r($info);
curl_close($ch);
fclose($fp);
?>
 
I think I found the cause for the issue - the downloaded file contains a string at the binging "file size = number of bytes" that should not be there. if I remove the string manually, the file is a actual tar file and also a valid backup file. it is possible to strip this post download, but it should get fixed on the server side as well.
 
Back
Top