Skip to main content

Backup appears to have caused VMDK file corruption

Thread needs solution

Hi, We have been using Backup & Recovery for a few months now and have been pleased with its performance so far. Unfortunately, last nights backups have not only failed, but they seemed to have corrupted a few of our vmdk files on our virtual machines. We can no longer start these servers!

The corruption coincides with the backup schedule and we are therefore concerned that a similar issue may happen again over the weekend. Our virutual infrastructure is hosted on VMWare ESX3.5

Any help would be greatly appreciated

0 Users found this helpful

Hello Duncan,

Thank you for posting. I will do my best to help you.

We need to understand where .vmdk corruption occurs and if it is related to Acronis software. The reason for this is because our software creates a snapshot of a virtual machine and attaches it to the appliance as a virtual disk which is then backed up. Afterwards the virtual disks are detached. Our software does not apply any changes on the .vmdk file.

Could you check your datastore please, it is possible old virtual disk did not detach properly. Also, did you have a power failure or anything of this sort?

I can see that you have valid maintenance, have you tried upgrading to ABR 11 by any chance?

Looking forward to your reply and if you have additional questions please let me know.

Thank you.

Hello,

Please could you advise me how to check whether the old virtual disk detached properly? We were experiencing intermittent backups form the virtual appliance, so decide to make some chhanges to our backup configurartion. It would appear that the problem occured after we enbaled Virtual Centre Integration yesterday evening.

We have found a previous article with the same issues:
http://forum.acronis.com/forum/7342

We were advised by our reseller to wait a short while before we apply Acronis ABR11, just in case there were any unforseen issues.

Regards

Duncan

We have managed to locate the source of the problem and we have managed to reinstate most of the virtual machines to their original state.

It would seem that a hardware switch had an outage during the backup cycle and that the effected machines failed to detach. It was not immediately obvious that we had a problem, as the backups started, but produced various duplication errors.

We have since rebuilt the virtual machines by reconstructing the CID chains, as metioned in the attached article:
http://redshift10.blogspot.com/2008/04/vmdk-snapshots-and-importance-of…