Veeam has been advertising some of their Veeam Backup and Replication V7 features for a while now, but I finally got access to the beta and was allowed to bring you a preview of some of the new technology. This post is about how you can use Veeam V7 to protect a vCloud Director environment, and I figured what better test lab environment to protect than the Hands on Lab cloud!
From my initial testing it looks like Veeam will need to be installed locally to the vCloud Director install. By that I mean that if you are using a public vCloud you will not be able to use V7 to backup those VM’s in your public vCloud…. Instead your provider could use Veeam to do it for you though. The reason for this is because Veeam still needs to talk to vCenter server for backing up vCloud VM’s, therefore if you do not have access to the vCenter server you wont be able to do backups.
Disclaimer: Remember the information and screenshots are from a BETA release of V7 and some features may change, so this is strictly for a high level overview so that you can get a first look at how it will work. I make no guarantee that they wont change all of these before the GA release.
Setting up V7 for vCloud Protection
Just as in previous releases of Backup and Replication the first thing we must do is tell Veeam about our vCloud Director install and our vCenter server.
Step 1. Start by navigating to the “Backup Infrastructure” section on the left and then click on “Managed Servers”. From there right click on manage servers and select “vCloud Director” from the list of servers to add.
Step 2. Now fill out the Name form so that Veeam knows the URL of your vCloud Director server.
Step 3. Next we need to give Veeam the credentials to login to vCloud Director. Veeam has a new credential manager that helps to organize all of your passwords and usernames which makes it much quicker to setup things.
Step 4. Next up Veeam will detect the vCenter server that is connected to vCloud Director and ask for vCenter Credentials
Step 5. Veeam will automatically connect to the vCenter server that is needed to do backups of your vCloud Director infrastructure. After it has completed view the summary page and then click finish. Next we will create a backup job.
Creating a backup job for vCloud Director objects
Step 1. Navigate back to the “Backup and Replication” section of Veeam. Then right click in the right pane (or select backup from the top ribbon), this will start the backup job wizard. On the first page give the job a name.
Step 2. Select the objects you want to protect. This part is pretty cool, you can select an entire vCloud Director environment, or drill down as granular as you want… all the way down to an individual VM in a vApp. (or anything in between)
Step 3. Here we will need to specify which backup repository to put this data in as well as any of the advanced settings that you might want to change if using a Data Domain or other deduplication box.
Step 4. If you need to have application consistency then you will want to fill in the credentials to do that on this typical Veeam slide.
Step 5. Finally setup the proper job schedule for the protection you need. (Again a typical Veeam Backup step you are already used to). Then click Create and finish…
Restoring vCloud Director Objects
Step 1. Select the “Restore” button from the top ribbon and then select “vCloud” to start the wizard.
Step 2. Pick whether to restore an entire vApp or a single VM
Step 3. Select the vApps you want to restore
Step 3. Next you can select which restore point you want to restore.
Step 4. Restore to a new location or to the original location?
Step 5. Enter a reason for restoring if needed
Step 6. Review the restore settings.
Step 7. Monitor the restore process.
Stay tuned for an article on the new Tape device support… i just need to find a decent tape drive first 🙂
Hi Justin, thanks for sharing. We have a vCloud Director deployment and I am wondering how this is any different from using Veeam to backup vCenter? Since vCenter sees everything that cloud director puts a nice end user interface on, I don’t see this as a big deal. Am I wrong or misunderstanding it’s use?
My hope was that the vCloud director product from Veeam would add a backup and restore feature to each separate vcloud user’s login…now THAT would be phenomenal.
Thanks again for sharing.
Well you are correct in thinking that vcenter does see all of the vcloud director objects, however vcloud director will get really pissed off if you do things like snapshots or edit any of the virtual machines settings from within vcenter. (it could cause issues with linked clones and stuff).
Also there is a bunch of metadata type information that is in the vCloud Director database that contains information about networking inside of vCloud as well as how the VM’s are laid out in terms of vApps, etc…. just doing a backup through vCenter does not capture this information, therefore if you were to fubar a vCloud Director VM there is really no way to get all the vapps and stuff to go back into vCloud Director without that metadata.
Enter Veeam V7….. it grabs that metadata, it also collects everything it needs to restore the vApps and their VM’s back into the vCloud Director interface/database.
Personally i think this is HUGE! why ? well think of it this way…. if you put all your VM’s in “the cloud” but the provider doesn’t have a good way to back it up and restore it with all the stuff you need to see it in vCloud Director’s interface…. that is a big problem. The only other backup software that I’ve heard doing this is HP Data Protector (but that was last year at VMworld and I dont have any other details on it)
OH and to your point of backing up an individual users stuff. I will try this out, but my guess is that you would just need to authenticate with that user in vcloud director…. and you would only get to see your stuff. The only real downside is that you will still need vcenter admin access at which point if you have that then you might as well just sign in with the vcloud admin too 😉 LOL, so i get what you are saying. However the only real way that you could backups the VM’s without vCenter access would be to shut down the vApp and do an export…. at which time veeam would have to read in all that data every time a backup was done and then do post processing on it to see what blocks had actually changed…. so its just better to do it at the vcenter level ….. just get your provider to buy it and resell it as a service add on to their cloud offering. Veeam has a service provider program that only adds a few bucks a month per VM
It is a good thing to have a vCloud director – ready backup solution. We’re testing it in our vCloud solution for internal cloud backup.
However, setting it up to give cloud users direct control on their backups and restores is a bit tricky. Veeam needs to see not just a vCloud director interface, but needs to communicate to vCenter servers that are under vCloud director control for managing virtual organizations and vApps. And it’s Enterprise manager interface needs a lot of polishing to be able to work with multiple users as multi-tenant setup. It’s three roles just aren’t enough for that setup. You could experiment with dedicated Veeam BR servers for each user… Maybe include a good developer or two understanding vCloud director API, vSphere API and Veeam restful API to provide you with a neat user portal for backup/restore? 😉
Thanks for the post. I was thinking about a scenario, and wanted to get your thoughts if you think it might just work. Basically would veeam v7 be able to backup my internal vsphere or vcloud installation, to Amazon S3, where it lives forever. In case of a disaster, I would restore to hopefully any public vCloud provider. Is this practical? and would you know of any public vCloud provider that actually enables utility computing (a la AWS) where you spin up/down resources as needed.
Yes Veeam will do what your thinking. It backs up to local disk, then a cloud connector uploads your backups to the cloud storage provider you want it to.
As for vCloud installs its hard to say now that VMware Hybrid services are around.