Backup Problems Return with 9.3 Upgrade

[mikelegg]

I've started getting the "Version string portion was too short or too long" error in the migration.result file again since upgrading to Plesk 9.3.

I had already applied the workaround here http://kb.odin.com/en/7090 some time back, but it appears to only apply to Plesk 9.2.

Is there a workaround for 9.3?

 

[IgorG]

We have already submitted request regarding this problem. I have forwarded your message to developers too. It is under their investigation now. I will update thread with results as soon as I receive it.

 

[mikelegg]

Thanks Igor

 

[IgorG]

Try to use file patched for 9.3.0 from attach. I hope it will help.
Please update thread with results.

 

[mikelegg]

Thanks Igor

I've applied the patch, I'll let you know if it fixed the problem after tonight's backup runs.

 

[mikelegg]

Unfortunately, the patch didn't resolve the problem. Still getting the following warning in the migration.result file -

<?xml version="1.0" encoding="utf-8"?>
<execution-result status="warnings">
<object name="domain.tld" type="domain">
<message code="InformationalException" severity="error">Cannot dump database content dbname of type mssql'</message>
</object>
<object name="backup" type="backupowner">
<message code="ArgumentException" severity="error">Version string portion was too short or too long.</message>
</object>
</execution-result>

 

[IgorG]

I have forwarded this information to developers. I will update thread with their answer as soon a s I receive it.

 

[mikelegg]

Although the warnings still appeared in the migration.result file the first time the backup ran after I applied the new patch, they haven't appeared since.

So maybe the patch does work.

 

[IgorG]

Could you please completely confirm that all works fine with applied patch?

 

[mikelegg]

Could you please completely confirm that all works fine with applied patch?

It's been three days now and the backups are being created successfully and there have been no further warnings.

 

[mikelegg]

It's been three days now and the backups are being created successfully and there have been no further warnings.

I spoke too soon, today the migration.result file contained a different error -

<?xml version="1.0" encoding="utf-8"?>
<execution-result status="warnings">
<object name="domain.com" type="domain">
<message code="InformationalException" severity="error">Cannot dump database content db_name of type mssql'</message>
</object>
</execution-result>

The other odd thing is that the PMMCli-Daemon sends me the same email 9 times for some reason.

 

[IgorG]

We have already submitted bugreport regarding "Cannot dump database content db_name of type mssql" error. Bug under developer's investigation now.

 

[mikelegg]

I just started getting another (different) error in the migration.result file -

Cannot export dump file 'filename_1002060146.xml' to 'ftp://[email protected]/foldername/'
[Transport error: unable to delete directory: Curl error: failed writing received data to disk/application]

The backup files look like they are being written to the backup server and my other servers aren't having any problem writing to it, so I don't think the backup server is the problem.

Does this error simply mean that the local directory can't be deleted after the backup files have been FTP'd to the remote server?

 

[IgorG]

I just started getting another (different) error in the migration.result file -

Cannot export dump file 'filename_1002060146.xml' to 'ftp://[email protected]/foldername/'
[Transport error: unable to delete directory: Curl error: failed writing received data to disk/application]

The backup files look like they are being written to the backup server and my other servers aren't having any problem writing to it, so I don't think the backup server is the problem.

Does this error simply mean that the local directory can't be deleted after the backup files have been FTP'd to the remote server?

As I remember usually this issue caused by insufficient disk allocation at /tmp partition.

 

[mikelegg]

As I remember usually this issue caused by insufficient disk allocation at /tmp partition.

There's over 150Gb free space on the drive. The final backup file is 24Gb, I'm not sure how much space is needed to create the backups but I thought 150Gb would be ample.

(PS. it's a Windows server so there is no /tmp partition)

 

[mikelegg]

As well as the error above which I now get every day, today I received a bonus error -
Failed to parse response. Reason: Failed to read data from stream Process output:

I am turning off the Plesk Backup and using R1Soft http://www.r1soft.com/ instead.

 

[IgorG]

http://kb.odin.com/en/111574