I had promised more articles on Veeam but have been slow with the posts. We\u2019ve 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 \u201con hold\u201d. Well, the real world jumped in and we had to use Veeam to help a customer recover lost SharePoint data.<\/p>\n
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 \u2013 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\u2019s 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\u2019s once every 24 hours (it can be configured to run much more frequently) using Veeam\u2019s unique reverse incremental backup (see my previous post for details of the installation).<\/p>\n
OK, now to the meat of this post.<\/p>\n
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 \u201cInstant Recovery\u201d 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 \u201cfull\u201d 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\u2019s backing SQL server in order to access the needed data.<\/p>\n
On the Veeam server I set up an Instant Recovery of both VM\u2019s and set the \u201crecovered\u201d VM\u2019s to NOT connect to the network on start up as we did not want to have the VM\u2019s running on the same network as the production machines (they could not be shutdown). The process took about 5 \u2013 7 minutes for Veeam to mount up the VM\u2019s on the ESXi server and make them available within the vSphere client. Once the recovery VM\u2019s became available within the vSphere client I connected them to a vSwitch that had NO external NIC connections, this was to ensure the VM\u2019s would run in their own \u201csandbox\u201d without any connection to the production LAN. At that point we started up both VM\u2019s.<\/p>\n
It took time for the VM\u2019s to start up even though the ESXi server itself has a decent amount of horsepower. Instant Recovery VM\u2019s 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\u2019t expect performance from the Instant Recovery VM\u2019s to match production VM\u2019s. But start up they did and we logged into the SharePoint machine via the console feature of the vSphere client.<\/p>\n
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!<\/p>\n
Back on the Veeam server I \u201cunpublished\u201d the two Instant Recovery VM\u2019s and we watched the VM\u2019s \u201cdisappear\u201d from the ESXi recovery server.<\/p>\n
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\u2019ll be doing a lot more digging and testing of Veeam\u2019s features which will lead to more posts. <\/p>\n","protected":false},"excerpt":{"rendered":"