• The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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