I think these are questions which many of us might like to know about.
Perhaps some of the current beta testers et al. can now comment??
1. How well does it work compared to current 3rd-party tools -- ease of use, performance, speed, reliability, compression, etc.??
2. How effective is the file-level restore utility??
3. How does it work -- FTP, SMB, what?? -- I didn't see anything about this in my initial review of DR materials.
I could not help but notice many similarities between what VMware provides and what PHD/Virtual touts for their new esXpress 3.5 software, which has been in testing for months now. I really like esXpress, but I don't see a lot of difference between their new product (what I've read about it so far) and VMware's DR tool. That said, I am also not an esXpress 3.5 beta tester, so I of course am not privy to the details that beta testers know about, etc.
Thank you, Tom
You're right, VDR is based on the same backup principals as esXpress by using a VM to backup a VM (great to get validation from VMware on that front ) but it's really aimed more at SMB users.
They've done some things really well, namely the backup scheduling and selection wizard and the VC integration (guess that last one was to be expected really!) but at the moment it doesn't scale. You can only have one VDR per VC server, and that means VDR is a single point of failure, it does all of your scheduling and management as well as the actual backups themselves. This has a few disadvantages. 1/ The VDR appliance must see all storage of all hosts to backup VMs on them. 2/ Max 8 concurrent backup threads (VMDKs) 3/ Max 500GB de-dupe store for backups. 4/ The VDR appliance is going to be a very CPU intensive VM. 5/ Host with the VDR goes down, backups fail for all hosts not just that host.
I may be wrong on this, but I believe that file level backup/restore is also not in the initial GA release.
Thanks Alex...We fit right into that SMB scenario.
It will be a tossup for us on how we proceed for 2010 with data backups -- money-wise, feature-wise, etc.
It's unfortunate your company decided to do away with the free un-featured full backups.
But overall, thank you for an interesting feature comparison/comments.
Hopefully someone(s) not affiliated with PhdV will also eventually comment.
Thank you, Tom
No worries, if the boot fits wear it huh. On the esXpress "free un-featured full backups" front, keep an eye on us I have a feeling the situation may change before you need to make your decision for your 2010 backup software.
I always keep an eye on your site. I have been one of your
customers since 2007, and I really like your support crew, one of the
best I have ever seen.
My thinking is since I probably won't go back to the Enterprise version
after this year (TOOOOOOOOO e$pen$ive) but more likely to Essentials
Plus (or if I really must, XenServer), I will end up mixing amd matching
different solutions for similar problems...depends how much I have to
pay for everything...we had a lot more money available to us last year
than we will have this coming December...
I can easily see PhdV having more versions than it does now...everyone's
into multiple SKUs nowadays
You can more than one Data Recovery appliance associated with a vCenter server, but only can talk to one appliance at a time.
All configuration information/metadata for the Data Recovery appliance is stored on the file share or datastore it backs up to. If the Data Recovery appliance would need to be reinstalled, you will not lose anything, so long as your file share or datastore is still there. This also means in a DR situation, you could load a Data Recovery appliance, point it to the datastore or file share with the backups and configuration information, and start restoring your data.
I know you posted similar questions on our support boards before. Thanks for the positive words concerning our support staff.
www.phdvirtual.com, makers of esXpress
I am not liking the 500GB data dedupe store limit. We currently use vRanger on a host with 850GB of local storage for VM images and even that doesn't meet our requirements for weekly retention.
I'm only going by what VMware said in the webcast they did on VDR last week. They said that while you technically could have multiple VDR appliances per VC, they strongly recommended against curently due to the possibilities of them clashing on VMs during backup.
I would think that you could just implement one per host and not have to worry about conflicts. However, then you would need to track down the VM in each of the VDR appliances when it comes time to restore, which is not good. Ugh.
I wouldn't plan on putting more than one VDR per datacenter, but in my environment where I have 7 datacenters and one vCenter server, I don't see an issue running more than one VDR appliance.
1/ The VDR appliancemust see all storage of all hosts to backup VMs on them. 5/ Host with the VDR goes down, backups fail for all hosts not just
The beauty of having a VM and having features like VMware HA is that Data Recovery can take advantage of these features to minimize impact of unplanned downtime
File level restore will be experimental feature at GA, and we are working to make this a fully supported features as soon as possible.
Thanks for all of the clarifications on Data Recovery Manager.
We definitely agree with your point about running backups in a Virtual Machine and the benefits of it. That was why we went with the solution of running backups in our VBAs ( Virtual Backup Appliances ) almost 3 years ago.
www.phdvirtual.com, makers of esXpress