Sean Wallbridge
I had promised more articles on Veeam but have been slow with the posts. We’ve been waiting on the arrival of gear in our office to support our own Veeam installation (hard drive shortage sure playing havoc with server supply) so my articles have also been “on hold”. Well, the real world jumped in and we had to use Veeam to help a customer recover lost SharePoint data.
To set the scene: our customer has a small but very crucial SharePoint installation that supports their internal field operations. To say they have embraced SharePoint as a means to drive their business forward would be an understatement – SharePoint is now THE driver for their business operations. Their VMware environment consists of three physical hosts running on top of VMware vSphere Essentials licensing; two run the production VM’s and the third is the standby host to support Veeam recovery operations. The customer implemented Veeam Backup & Replication v6 back in December using the Essentials licensing bundle to match their VMware licensing. Veeam is currently configured to backup production VM’s once every 24 hours (it can be configured to run much more frequently) using Veeam’s unique reverse incremental backup (see my previous post for details of the installation).
OK, now to the meat of this post.
This past Friday the customer contacted me as they had lost some critical data out of their SharePoint after SP1 was applied to the SharePoint 2010 server. The data was in a number of customised lists that SP1 messed up for some undetermined reason. We decided to use the Veeam “Instant Recovery” feature to bring up a copy of SharePoint prior to the SP1 installation. Instant Recovery manages the process of mounting up a Veeam backup of a given VM to a recovery ESXi server. This is NOT a copy or a replica of the VM, it is the actual backup. The additional wrinkle for us was that the copy we needed to mount was actually one of the reverse incremental backups as the last “full” was one day newer (after the SP1 application). I had played with Instant Recovery using a full but never a reverse incremental. We also realised that we would have to bring up a backup of both the SharePoint server as well as it’s backing SQL server in order to access the needed data.
On the Veeam server I set up an Instant Recovery of both VM’s and set the “recovered” VM’s to NOT connect to the network on start up as we did not want to have the VM’s running on the same network as the production machines (they could not be shutdown). The process took about 5 – 7 minutes for Veeam to mount up the VM’s on the ESXi server and make them available within the vSphere client. Once the recovery VM’s became available within the vSphere client I connected them to a vSwitch that had NO external NIC connections, this was to ensure the VM’s would run in their own “sandbox” without any connection to the production LAN. At that point we started up both VM’s.
It took time for the VM’s to start up even though the ESXi server itself has a decent amount of horsepower. Instant Recovery VM’s run across a special NFS link between the ESXi recovery server and the Veeam Windows server that holds the backups. Therefore, there is a certain performance penalty that is imposed by running across the NFS link as well as a performance penalty imposed by the Veeam Windows server if it does not have a high-performance disk subsystem. In other words, don’t expect performance from the Instant Recovery VM’s to match production VM’s. But start up they did and we logged into the SharePoint machine via the console feature of the vSphere client.
SharePoint was a bit pokey to authenticate but once we were in it operated reasonably quickly. My customer navigated to the lists in question and, of course, all the data was there as expected. He saved out the lists as list templates with their data to the server desktop and we then connected a USB stick to the SharePoint VM via the vSphere client and copied the data to the stick. On another machine we connected to the production SharePoint instance and imported the list templates and data back into SharePoint from the USB stick. My customer then recreated the lists in their appropriate sites and ensured the data displayed as expected. Crisis resolved!
Back on the Veeam server I “unpublished” the two Instant Recovery VM’s and we watched the VM’s “disappear” from the ESXi recovery server.
The whole process took us about 45 minutes start to finish. There was no drama and no impact on the production servers other than the fact that we were able to recover the needed data without any real hassle. We will be installing our own Veeam infrastructure in the next few days and I’ll be doing a lot more digging and testing of Veeam’s features which will lead to more posts.