Backing up large vmdks (~12 TB)

[Morgenstern72]

We are moving from our HyperV servers to VMWare 5.5 (and much stronger hardware).
We want to build a new fileserver with a large virtual disk to host the data we had before on several LUNs.
Idea is, that it is much easier to move to a new datastore (like in case of a new SAN) or extend the disk as it is with LUNs.

I know the limitation for VMWare 5.5 is 62 TB. Then you cannot add anything else like snapshots.
I also learned, that Dedup efficency drops at 16TB disks with veeam.

Would you have some ideas what we can expect from a 12TB vmdk regarding veeam?
Would you recommend to split the vmdk in two disks with 7TB and 5TB to host two seperate network shares?

Thank your for your ideas and time

[dellock6]

Joachim,
not sure where you found Dedup efficiency drop over 16TB, there is indeed a special configuration in Veeam ( from 6.5 if I remember correctly) to have a lighter dedup configuration in order to large backup files; but this means when the Veeam VBK files goes over 16TB in size, not the VMDK.

In your situation, since usually at least a 50% data reduction is expected, your 12TB vmdk is going to be reduced to 6 TB, and this means you can safely use any deduplication option available, even local or lan if needed.

Luca.

[Morgenstern72]

Thx Luca for your input! You are right, it is about the vbk, not dem vmdk.

About your question regarding the 16TB
"The Local target (16 TB + backup size) option is recommended for backup jobs that can produce very large full backup files — larger than 16 TB.
If you select to use data blocks of small size to dedupicate a large backup file, the backup file will be cut into a great number of data blocks. As a result, Veeam Backup & Replication will produce a very large deduplication metadata table which can potentially overgrow memory and CPU resources of your backup repository. For backup files over 16 TB, it is recommended to choose the Local target (16 TB + backup size) option. With this option selected, Veeam Backup & Replication will use data blocks of 8 MB. Large data blocks produce a smaller metadata table that requires less memory and CPU resources to process. Note, however, that this storage optimization option will provide the lowest deduplication ratio and the largest size of incremental backup files."

http://bit.ly/1lp7KZG Page 46

[veremin]

Yes, the said number (16 TB) is related solely to backup size.

As to reduction rates, it depends mostly on type of the data stored inside VM, how well it can be deduplicated. For instance, you wouldn't expect impressive deduplication/compression rates from the VM that stores mainly .jpeg images.

As a rule of thump can you use 50% as a data reduction ratio (compression + dedupe), because typically you won't see ratios less than that.

Thanks.

[Morgenstern72]

Any recomandations on splitting the vmdk into two vmdks resembling the network shares users see?

[Vitaliy S.]

Hi Joachim,

I don't think you need to split the vmdk into two separate disks. There should be no issues with backing up a 12 TB VM disk.

Thanks!