I am using EMC Retrospect to backup and restore offline VMs. The backup server is using a HP LTO Autoloader running Windows 2003 Server. The Linux Retrospect client has been installed on the VC and the necessary ports opened both in and out. Backup speeds are in the 1.5GB/Min ballpark, while restore speeds are only 150MB/min.
The VMWare host is on a HP/Compaq DL380 and connected to the same Gbit switch as the backup server.
Thanks,
Wes
Just an update.. Attempted a restore of the same data to a Windows XP client instead. Restored 8GB in under 7 minutes...
OK.. It seems to have something to do with restoring files to the VMFS volume. Restores to VMFS are 150MB/min and restores to the EXT3 volumes are 2000MB/min. Does anybody else care? Hello... Should I be doing this a different way?
Retrospect is not a certified solution, perhaps it has issues with VMFS?
I'd have a look at Legato, or any other certified solution.
\- Anders
Haha!!! You made my morning Jason, thanks.
Your problem is definitely related to doing restores against a VMFS volume.
While I lack the URLs (okay, I am too lazy to search) there are many threads in here discussing how cp and similar unix utilities are problematic when \_writing_ data to a VMFS volume.
The issue here is that non-native utilities, ie ones that werent written by VMware, will cause lots of locking issues with the metadata used by VMFS - which is a clustered filesystem - to avoid data corruption by two processes updating the same file at once.
It's pretty likely that a backup utility will have this same problem, leading to poor performance during writes and the potential for interfering with VMs running on the VMFS volume being restored.
For more info, search for "vmfs AND metadata AND cp" in the ESX 3.0 forum
Thanks, oschistad.
You've been most helpful! I always welcome an explanation of why things are wonky.