MFT/Index Errors Forcing Sector-By-Sector
We are currently evaluating Acronis vmProtect 8 (using the 15-day trial version), and I'm running into the following issues:
Several of our VMs are forced into sector-by-sector mode, with an information-level entry in the logs nothing the MFT or index being corrupt.
I first tried running chkdsk c: /r on one of the VMs exhibiting the issue. It didn't help.
I then created a brand new 2008 R2 VM from scratch (using the 2008 R2 ISO, not an existing VM or template), and it still exhibited the issue. I then followed the workaround in this guide, creating vmware.conf in %ALLUSERSPROFILE%\VMware\VMware Tools\ (the documentation specifies %ALLUSERSPROFILE%\Application Data\VMware\VMware Tools\ , but it looks like that's incorrect) and adding the line Shadow Copy Optimization Writer .
I then restarted the VMWare Tools Service and tried the backup again, but it still forced sector-by-sector mode. A log of this is attached.
I restarted the VM and tried again just now, and it looks like it completed without resorting to sector-by-sector mode. This is a VM with absolutely nothing running on it but the Windows OS, so there should be no issue with load.
What are the downsides of disabling the Shadow Copy Optimization Writer?
Is there an ETA on a fix? Will this fix be available for vmProtect 8, or will it only be available in vmProtect 9?
We also have a warning about inconsistent snapshots due to VSS issues on another VM.
I believe the fix is to enable application-consistent quiescing, but I have not tried it yet. (I'll report back when I have.)
What is application-consistent quiescing? Is there any reason to not enable it? Again, this is a 2008 R2 VM. We're running ESXi 5.0.1 with the latest updates (build 1117897). The VM itself was probably created on ESXi 4.x .
If I can't get this warning to go away, what are the consequences of having inconsistent snapshots? We don't use snapshots (I know vmProtect uses them when performing backup operations). The VM exhibiting this error is an MS-SQL server, if that matters.
And finally, I see that the beta of vmProtect 9 has been announced. We're looking to buy approximately 20 licenses (through a partner that offers our organization an EDU discount), but if vmProtect 9 is around the corner, I'm not sure what we should do. The MS SQL, Active Directory, and vmProtect configuration backup and restore sound great. Are upgrade licenses typically available? If we were to buy vmProtect 8 now only for vmProtect 9 to come out in a month or two, what would our options be? Would it be best to wait? (Is there an anticipated release for vmProtect 9? I see vmProtect 8 was released in October of last year.)
Attachment | Size |
---|---|
log.zip | 5.31 KB |

- Log in to post comments

I was able to get around the VSS warning by adding disk.EnableUUID TRUE.
I was able to get around the corrupted MFT/index issue by adding Shadow Copy Optimization Writer to vmbackup.conf (I mistakenly did vmware.conf earlier).
All backups succeeded for 3 or 4 rounds with no errors or warnings and without being run in sector-by-sector mode.
I'd still like to know if there is any downside to disabling the Shadow Copy Optimization Writer via vmbackup.conf, or if there is a fix coming (and if it will be available for vmProtect 8).
I then had an issue backing up to a network share.
I have a file server I'm backing up to, and I've created a local user account (Acronis) on that server, and gave it full access to and ownership of a folder (C:\test). I then shared the folder, and gave the Acronis user access to it. When browsing for the backup location, I can authenticate using the Acronis username and password, navigate to the share, see files and folders already in the share, and even create a new folder within that share.
When I run the backup task I get an error saying "Failed to mount SMB share".
It turns out the issue was the password I was using. It had spaces in it. I generated a new password for the account without spaces and it looks like everything is working so far (I'll find out tomorrow morning).
- Log in to post comments

Now that the backups are running on the SMB share with a specific username and password, I can't get them to validate.
vCenter reports the following:
Commit of operations result is failed.
Failed to perform the operation with archive 'avfs:/smb?//backup-exof/Acronis%20vmProtect/Test%20Validation%20Corrupted%20No%20PW.TIB'. Error: 'The archive is corrupted.'.
The vmProtect log shows
I'm using AES encryption. I iurst used a 32-character random password, then a 24-character random password with no spaces (because of the issue I had with the SMB share), and then I tried with no password and no encryption. Validation fails every time. I'm backing up every single VM under the vCenter host (except for replicas).
Help?
- Log in to post comments

Hello Brian,
Sorry for the delay with the response.
Let's start with the first issue "MFT/Index Errors Forcing Sector-By-Sector". Unfortunately it is a known issue, which is described in our Knowledge Base article, you can find here the description and the temporary workaround till it will be fixed: http://kb.acronis.com/content/36993 . So you were absolutely right, when you disabled "Shadow Copy Optimization Writer".
Regarding you question about upgrade to Acronis vmProtect 9 Beta:
We are going to release the 9th Version in the end of Summer approximately.
We provide our customers which have valid maintenance (1 year after purchase), free upgrades to new versions. So you have two options: you can buy Acronis vmProtect 8 now and then get the free upgrade to Acronis vmProtect 9 just like in this KB article described: http://kb.acronis.com/content/36140 . Or you can wait for the new version Acronis vmProtect 9.
Regarding your second issue: backup to the network share. Please attach the full log of the operation so that we could analyze it.
Thank you.
- Log in to post comments

Thanks for the response. It looks like everything is working normally right now (I restarted both the Acronis vmProtect appliance and the system hosting the network share).
I'm currently testing the copying to a secondary location feature and the replication feature to replicate our 3 critical VMs to another ESXi host.
After that I'll create a new VM and run my main backup task to ensure that the new VM is automatically included (the task has the entire ESXi infrastructure included, excluding replicas).
For the copying to a secondary location feature, I noticed that the file sizes are different between the original and the copy.
For example, our first (full) ESXi Configuration Backup file is 443,573,760 bytes in the original storage location, but 443,440,128 bytes in the secondary location. The first incremental file in the chain is 909,312 in the original location and 900,096 in the secondary location.
Both copies validate successfully, and I'm looking at the actual file size (not the size on disk).
Is this normal?
If I copy the files to a third, offsite location via a batch file every month, will I encounter any problems if I have to restore from the third location?
Should I copy from the original location to the third location, or from the secondary location to the third location?
I have not yet tested copying the VM backups to a secondary location, but we're using the single-file format for those. Our backup to the SMB share will run daily, the backup to the secondary location will run weekly (copying all missed restore points), and we'll manually overwrite the file on the third location monthly.
Same question for this scenario: Should I copy from the original location to the third location, or from the secondary location to the third location? Or will all the files be identical (after the weekly copy) in this case?
For licensing, if we buy 20 licenses, do we get 20 different keys? Or do we get a single key with 20 licenses allocated to it?
We have 3 separate locations we plan to support, and there will be 3 different installations of Acronis vmProtect 8 on 3 separate vCenter infrastructures. If we get 20 different serials, then it's obviously not a problem, but if we only get a single serial, are we able to use that same serial in multiple locations? (I believe we'd be purchasing through CDW, if that matters.)
- Log in to post comments

Hello Brian,
Great hearing that the problem with the backup on the network share does not persists.
Concerning your question about second location. I consulted our developers and there is an explanation for this behavior: a backup to second location is literally a backup of the backup to original storage, thus the backup on the second location has the less size- because of more compression.
This backup is absolutely proper. You can copy the backup from the original location as well as from the second location. The same is for the backup of VMs.
The question about licensing: if you will buy 20 licenses, you will get 20 different keys. Please be aware: the licensing policy is based on a number of CPUs in the physical infrastructure holding the virtual machines. Each CPU on the managed ESX host/cluster consumes a license. E.g. if a host has 2 CPUs, you need to have 2 licenses in order to backup this host. More information you can find in the Acronis KB article (Acronis vmProtect 9 has the same policy): http://kb.acronis.com/content/24250
Look forward to your reply.
Thank you.
- Log in to post comments

Thanks for the reply.
I noticed that the backup to the second location isn't encrypted, but the backup to the original location is. I added the backup to a second location after creating and running the task. But if I create a new task and specify the backup to a second location, the second location's copy is encrypted.
So I've recreated our main backup task and deleted all existing recovery points so that both locations will have encrypted copies.
Is there a way to specify that the Disaster Recover Plan document gets copied to a second location?
I am also now testing the GFS backup scheme using 180 days, 26 weeks, and 6 months.
Does the validation task validate the entire archive (all 180 days worth) or does it only validate what it needs to recover to the most recent point? That would be the latest monthly backup, the latest weekly backup, and all daily backups after the latest weekly backup.
Validation will take a very long time if it has to validate every recovery point every time.
- Log in to post comments

Hello Brian,
Sorry for the delay with response. Please see my answers below.
>>Is there a way to specify that the Disaster Recover Plan document gets copied to a second location?
Unfortunately it is impossible to copy the Disaster Recover Plan document to a second location. DRP can be sent only to single specific location/folder.
>>Does the validation task validate the entire archive (all 180 days worth) or does it only validate what it needs to recover to the most recent point?
It validates the data required to perform recovery from selected recovery point. In other words if source VM was 40Gb in size and resulted archive was 20Gb then 20Gb will be validated each time (no matter how many recovery points are inside the archive and what size the archive is).
Thank you.
- Log in to post comments

Hi!
Concerning the sector-by-sector backup issue, I've left a detailed explanation of its impact here: http://forum.acronis.com/forum/42770#comment-134286 . Hope it will also be useful.
Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager
- Log in to post comments

Thanks, that's very helpful.
Wednesday night's backup job had an error:
An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.
The guest OS has reported an error during quiescing. The error code was: 5 The error message was "VssSyncStart" operation failed: Server execution failed (0x80080005)
I just re-ran the job the next morning and it completed successfully. The archive also validated successfully. And last night's backup completed successfully as well. If it continues to happen, I'll investigate further, but I presume it's just a fluke due to VSS and whatever's going on in the VM at the time.
- Log in to post comments

Hi Brian,
The quiescing failure seems to be unique one and I've yet to find a VMware KB article referring to this particular error (Server execution failed (0x80080005)). Here's a KB article which refers to similar problem, though not exactly the one you have: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…
Taking into account the fact that next morning the quiescing succeeded I would suspect some problems with the underlying ESXi host.
Also in the 9th version of vmProtect (which is currently in Beta: http://forum.acronis.com/forum/42833 ) there is an option added (Backup Options->Error Handling) to re-try the failed VM processing which allows to automatically re-try the snapshotting process from scratch. With this option enabled such quiescing issues can be worked around.
Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager
- Log in to post comments