VMCopy thin-->thin/thick

[Frosty]

I went through all our virtuals this weekend and cloned them all, changing the disk provisioning from Thick to Thin. I had hoped that this would end up saving time on our VMCopy jobs each night, but now realise that this was in vain; when copying they are automatically converted from Thin to Thick. I understand now that this is a VMFS-specific feature, so I am looking for another way to reduce the amount of data being copied. Hoping that someone can steer me in the right direction.

Current Situation:
We have 5 virtuals running on a single VMware vSphere 4 server. There is about 350GB of data if considered as 'thick' but only 220GB if considered as 'thin' disks. We are using VMCopy to backup to a SAN (where the latest copy of the backups can always be found). Part #2 of the backup process is a script using Robocopy to mirror that data to portable USB HDDs.

We set it up that way initially because I had little knowledge of the Veeam Backup model and VMCopy was easier to understand (and easier to document in our disaster recovery documentation). I am now prepared to consider VMBackup, but would like to understand what I will need to change apart from what changes in the Veeam jobs themselves. e.g.
1. will I end up with more, or less, data stored on the SAN?
2. will I need to do something different at restore time in a DR scenario?
2.1 e.g. thin/thick provisioning changes?
2.2 e.g. what changes in the restore process? (someone previously suggested that we have a 2-stage restore process: first to rebuild from backup files to VMware disk images, then copy those files to the VMware server where they are to run ... is that how to do it?)
2.3 e.g. I understand there is a standalone recovery application ... is that what I should be using, or should I have a 2nd installation of Veeam on my DR servers ready to be used?

Hoping someone can give me some tips on how best to proceed, including pointers to some "best practice" documentation.

[Frosty]

In relation to the "2-stage restore process" I mention above, I am referring to this comment Gostev made in a previous thread of mine:

Gostev wrote:
>> When the time comes to restore, instead of restoring directly to ESXi free
>> (which is not supported because write operations via APIs are restricted for free ESXi),
>> you could restore all VM files from backup (second option in Restore wizard);
>> then upload those files to ESXi free by "some other means" and register VM manually.

Can you be more explicit for me?
* "second option in Restore wizard" ... is this part of the standalone restore tool that I have seen mentioned?
* what does "some other means" mean??? are you referring to FastSCP, or something else?

[Gostev]

Stephen, the thread you have referenced looks to be related to ESXi free workarounds, nothing to deal with the product's usage on licensed ESXi. So just ignore everything you heard in this thread to avoid further confusion.

As for your quesions, yes of course you should definitely use Backup instead of VM Copy...
VM Copy was never designed to be used for regular backups.

1. Backup will take a few times less.
2. No, your process will remain the same, you will just deal with highly compressed and deduped backup files, instead of full VM copies.
2.1 VM will be restored in the same state it was backed up, so thin VM will be restored as thin.
2.2 Nothing, you just perform restore using Restore wizard (single operation).
2.3 You can do either approach.

By Restore wizard I meant actual Restore wizard (page 65 of the User Guide), not standalone tool.

By "other means" I meant whatever tool you use today to upload ISO files or VM files to ESX host (for example, during your documented process of restore from USB HDD). FastSCP is just one of many ways.

[Frosty]

Thanks Gostev, that clears it up a fair bit for me. Currently I am still running ESXi Free down at our DR site, but I hope to have a fully licensed installation shortly.

Looks like its time for me to switch from VMCopy to VMBackup then ... '

Cheers! Steve.

[Frosty]

Have set up a test job for one of the servers. First thing I noticed was the amount of data. Using a VM Copy the server in question was 70GB. With VM Backup the file (compressed, de-duped I suppose) was just over 20GB. This will obviously massively reduce the amount of time it takes to complete our backup processes. I can also see that if I tell it to run a full backup every Sunday (for example) and then it incrementals away for the remainder of the week, the process will be a lot better. Cheers, S.

[Gostev]

Stephen, glad it works better for you. Actually Veeam uses synthetic (forever-incremental) backup. So you don't really need to perform full backups. Unless of course you have certain requirements which force you to do this, then you can enable it. Thanks.