Hello, All
So, i have this concern and i am looking to get back to the customer as soon as possible.
They are backing up virtual machines that are as big as 32TB.
They want the backup for those VMs to complete within 1-2 hours.
What kind of infrastructure should be put in place to achieve this?
Best answer by Jos Meijer
An intellisnap backup would most likely manage it within this timeframe as it only needs to quiesce the VM, snapshot the storage array volume and consolidate the disks for the VM. For such VM sizes I assume the VM is running on fast storage, preferably NVMe. When running on slow storage the disk consolidation will take a while depending on the delta created during this activity.
But a snapshot is not a backup in my opinion. If you want to backup copy it to disk, to be honest, I don't think you will manage this in the required timeframe if you focus on VM backup via LAN.
So it all depends on the context of your requirements.
A quick thought on a valid solution, for backup to disk, could be:
If you keep a certain amount of snapshots for both the OS and Data sections you can revert both the VM and Data with snapshots, or restore from disk if this would be required.
The questions here would be:
Other solutions might be there, but 32 TB is simply a lot of data for that timeframe...
+23https://documentation.commvault.com/11.25/expert/36282_vmware_intellisnap.html
The doc above should help get you started,
+13This isn’t an easy question to answer as it would be dependent on your infrastructure.
What transport mode is being utilized here?
+23Check the options here:
https://documentation.commvault.com/11.24/expert/36340_transport_modes_for_vmware.html
+17An intellisnap backup would most likely manage it within this timeframe as it only needs to quiesce the VM, snapshot the storage array volume and consolidate the disks for the VM. For such VM sizes I assume the VM is running on fast storage, preferably NVMe. When running on slow storage the disk consolidation will take a while depending on the delta created during this activity.
But a snapshot is not a backup in my opinion. If you want to backup copy it to disk, to be honest, I don't think you will manage this in the required timeframe if you focus on VM backup via LAN.
So it all depends on the context of your requirements.
A quick thought on a valid solution, for backup to disk, could be:
If you keep a certain amount of snapshots for both the OS and Data sections you can revert both the VM and Data with snapshots, or restore from disk if this would be required.
The questions here would be:
Other solutions might be there, but 32 TB is simply a lot of data for that timeframe...
+23File restores seem to be the weak spot for IntelliSnap backups of large VM’s.
Yes this is true if restoring from the snapshot copy. This is because the snap has to be presented back to the ESXi host, the VM mounted and read using a transport mode to access the file content. If your array supported non-persistent storage then a live mount from snap and copy out of the files may work much faster. Hoping we will see improvement to file restore performance from snap backup in the future - I’ll see if there is anything to improve this in the pipeline.
“Yes this is true if restoring from the snapshot copy. This is because the snap has to be presented back to the ESXi host, the VM mounted and read using a transport mode to access the file content.”
The mounting of a snapshot back to an ESXi host or a cluster from NetApp for example can manually be done within a minute.
The mounting of a VMDK to another VM for example can also manually be done in under minute. Not sure how presenting the snap to a single host is the issue.
+23“Yes this is true if restoring from the snapshot copy. This is because the snap has to be presented back to the ESXi host, the VM mounted and read using a transport mode to access the file content.”
The mounting of a snapshot back to an ESXi host or a cluster from NetApp for example can manually be done within a minute.
The mounting of a VMDK to another VM for example can also manually be done in under minute. Not sure how presenting the snap to a single host is the issue.
The issue is not the delay or slowness with the mounting operation. The issue is that once the VM is back in vCenter the disk is accessed in ‘file’ mode though VMware APIs, which allows Commvault to access the contents of the disk. This is an intensive operation and is completely different to how the backup is done, which of course is at the block level. Parsing actual file contents from a VMDK disk through a vmware transport mode is the cause of the delay.
Yes, if the process was to use a proxy machine to mount the disk and use the OS to read the files, the operation would be faster, but that is not how it is implemented currently and I can’t commend as to why that is the case. There is a restore option that allows you to mount the VMDK to a machine - the last leg of the restore would be up to you to copy the files manually through the proxy machine it is mounted to, and that would likely be more performant.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
