Hi,
Recently we have switched our backup services from VMware Data Recovery to VMware Data Protection (without migrating backup jobs and data from VDR, we did fresh config and fres backups in VDP). So I thought I could write a bit of encouraging words regarding the usage of VDP, especially since so much negative (some of them quite justified) words has been said on VDP.
We are currently using three VDP appliance, each one of them for each of our three sites. These are small sites (one is actually a brach office), but still big enough to make some decent stress tests for VDP. We are using VDP for approximately 2 weeks up to now and are generally hapy whit them.
So here are the results after those 2 weeks of usage. The first appliance was configured to be on the edge regarding the number of VMs - it backups 101 VMs on daily basis (I know only 100 VMs are supported, but we thought it would be nice to take it to the edge). The second one backups 18 VMs and the third one backups only 6 VMs, but one of the VM's is quite big - 1.5 TB of source data (actual data in the guest VM).
And some screenshots from VDP email summary reports:
Appliance no.1:
Appliance no.2:
Appliance no.3:
It's nice to see how well VDP can shrink 4.6 TB of guest VM data into only 0.6 TB de-duplicated backup data (on appliance no.1).
---
Now, the important things to follow for all of you who is still considering on implementing VPD:
1. VDP is a very special and huge piece of software. It is NOT the kind of software which could be simply installed and used in a simple try&error manner. Oh, no, you should follow very carefully all of the guides, user manuals and read user experiences on vmware communities.
2. Be VERY generous on giving resources to VDP. We've configured our appliance on site one (the one that backups 101 VM) with 8 vCPU and 16 GB of memory (esxi host has dual 6-core westmare cpu). Besides this - do not put VDP on some old host - oh, no, give it the best and fastest host you can get. We've analysed cpu and memory usage during backups and it actually can occupy full 6 cores of the host and eats all the memory that you gave it.
3. Don't touch VDP (or it's host) during blackout and maintenance window! If you leave VDP to do it's jobs during blackout and maintenance windows you can rest assure that integrity and other checks will be successful.
---
Of course, there are still some issues with VDP. Besides the documented and well-known limitations and issues, there are some small little annoying issues that hopefully VMware will sort out in the near future (VPD 5.5 has already solved some of them, it should be released soon). Among the issues that hurts the most (from our point of view) are:
- lack of CLI file-level restore client for Linux and lack for ext4 support on file-level restore;
- VPD is unable to automatically remove VM from the list of VMs in a Backup Job if the particular VM is deleted or removed from inventory (one have to manually edit Backup Job always when a particular VM is deleted or removed from inventory - this really hurts, especially in an automated environment where VMs are created and deleted by various users);
- VPD is not able to make any automatic reporting on failed backups: no alarms in vCenter, no easy parsing of log files (one have to read the e-mail Summary Report each single day to make sure all backups are done successfully - very time consuming and prone to human overlooks).
---
Anyway - let that be enough - at this point I would like to thank VMware and EMC for a nice free backup solution (after all, its free) - just keep up the good work and make sure VDP will get all the features and fixes, necessarily for continuous day-to-day automatic backup.
Thanks!
