Veeam Data Lab – Part One

I was at a VMware User Group in Perth recently and started discussing the Veeam Data Lab with two consultants, and how much of a hidden secret it is.  For those of you who don’t know the Data Lab (previously Virtual Lab) provides an isolated sandbox for testing of Virtual Machines in an isolated network environment.  The Virtual Machines in question could be a single VM, or an application group, and can have dependancies on other VMs as well.  The discussion that I had around how useful this could be highlighted a use case that I thought I should share.

Scenario – An un-patched system

One of the consultants highlighted that a couple of years ago he had a phone call from a prospective client highlighting that they had some problems with Microsoft Lync (now Skype for Business) servers being out of sync and causing all sorts of problems inside of the client site.  On attending the site it was discovered that no server on the entire site had been patched for years.  The reason?  An outage caused by the last patch that had been run during the middle of the day with no change control.  The client wanted to guarantee that patching the systems would fix the environment prior to signing off on any changes inside of their environment, so the consultant was left with the challenge of showing how this could be achieved.

Veeam had been running for years, but purely used for backup.  Having had prior experience with Veeam, a Data Lab was put in place and the last backup was restored in the isolated environment and patching begun on the Lync servers and everything they depended on.  A couple of days later the environment in the sandbox was shown to be in sync, and a full plan of how the servers needed to be patched was given to the client as part of the change control process.  Given a complete change control process, proven outcome, and critical timeline the upgrades were approved and completed out of hours.  As a bonus the internal IT team at the client ended up with the ability to run all software patches  in the test lab prior to deployment, and the IT team ended up with a positive reputation amongst the leaders of the organisation.

There are other scenarios that the Data Labs could assist in, such as:

A resource for training – imagine being able to help out someone at the start of their IT career by providing a DC, Exchange server, and a VDI instance, in order to learn how to break and fix an exchange issue.  The difference this could make to someone starting in IT, or preparing for an exam is priceless.

Software Product Lifecycle – by using some network trickery you could conceivably create and destroy a virtual environment throughout the software development lifecycle.  You could create data on a VM, back it up, and then present the same environment to another team the next day, and so on.

Test Lab – the number of times I have been told that an organisation has a Production environment, DR environment, and a scaled down Test environment, only to find out that Test was deployed and never kept in lock-step with Production is crazy.  Using Data Labs you can essentially create a Test environment based on the latest protected copy of your Production environment.  This could then realise cost savings by freeing the dedicated Test servers to be utilised in the Production environment the majority of the time.

Data Analysis – by using the gateway appliance built into the Data Lab you could provide a path for your big data analysis engine to access a copy of your Production environment and then run analysis.  This is a new idea and one I’m hoping to spend some time delving into over the next couple of months.

In part two of this mini-series I intend to cover off How To Implement a Data Lab.  Stay Tuned!