Veeam Replication – Sandbox Environments
In this day and age, we want to be able to do more with less, seems to be everywhere, or we want to be able to do something additional with what we have already got. Get more ROI out of an asset. Leveraging data is no difference, for years as technical customers we have been backing up our data to some form of media, this could be classed as dumb storage. We send our backups there then we update again at the next iteration. We only come back to that backup or replicated data if we need something in the form of a recovery.
Why not leverage it, that’s your production assets in the form of a backup or replication state. In the last post, I discussed SureReplica which is the Veeam way in which those replicated virtual machines can be verified for recovery. To do that we power on those machines in an isolated network away from production and in this instance in our secondary site for disaster recovery. Fully automated to make sure that those files are good for if we need to failover our workloads.
Verification is one thing leverage is another, by leveraging that data we are getting more use from that target storage array that traditionally may have just been sat there holding those replicated VMs.
SandBox Labs via SureBackup Job
By clicking a simple step within the SureBackup job wizard you can keep that same application group up and running for as long as you need. A good use for this is patching, if you are responsible for patching your key application servers or all servers then this could help that process.
One thing to note here is that this is going to start that same application groups it’s going to adhere to the configuration of that application group about memory assigned and boot time delay etc. be sure to configure those tests and settings to ensure you have the optimal configuration when running a Sandbox environment.
You also have the ability to run your own scripts here this is part of the verification also, this could be a script that you may run that runs a windows update via script to test updates faster.
Scheduling & Stopping
When you have that in line you are able to start your job or schedule that job. What I mean by scheduling is that this will run a scheduled time and spin up these replica VMs in your secondary location the difference here is that they will keep running. Whilst they are running no further replication jobs can be completed. I want to show you how you can stop the session so that you don’t face this issue, when you are finished with your sandbox testing then be sure to stop that session.
By stopping the session, you are going to shut down them virtual machines and you are going to lose anything you placed on that we are not going to write anything to those replica files or backups.
Tips – Data Sources
A useful tip here is that you may have these VMs in your application group that are being replicated over to the secondary location however you may have a Domain Controller or something alike already running in that location, with that you may or I should say should be taking a local backup of that Domain Controller. Within your application group configuration, you can mix your workloads, we could use some of the replicated virtual machines and we can use some of the local backup files.
There is also one more option of sources and that’s the ability to leverage storage snapshots. I will touch on more later on in the series on this one.
I also did a vBrownBag session at VMworld in 2017 that allowed me to demonstrate the power of this cool unsung feature within Veeam.
<Link to VMworld YouTube Session>