Targetless SnapVX Gold Copies with SRDF SRA

Gold Copies

The SRDF SRA for VMware SRM has the capability to take copies of the R1 or R2 before running a failover of the environment. This adds a layer of protection in case something happens to either of the production copies of data. Unfortunately, these XML files (EmcSrdfSraProtectionSiteGoldcopyConfig.xml and EmcSrdfSraRecoverySiteGoldcopyConfig) cannot take advantage of the automated creation that you can use with test failover (AutoTargetDevice) so these Gold Copy XMLs require modification to match the R1 or R2 with a target device of the same size. In essence this is the old functionality of test failover before auto device creation. Here is a sample of one of the XML files:

<?xml version="1.0" encoding="ISO-8859-1"?>

Now while it would be beneficial to have the SRA create the target devices automatically, it would be far better to not create them at all. With SnapVX technology we could create targetless Gold Copies, saving us valuable cache and device IDs for that matter. Both of these capabilities I have requested in a future version of the SRA (won’t be the 2022 release), but is there a way we can do it now with a little modification? Sure.

SRM Windows Recovery Plan Script

Since the SRA does not inherently have the ability to take the targetless snap, we can write a script to do it and then execute that script as a pre-step to the Recovery Plan (test or actual failover). The execution of a script is part of SRM, not the SRDF SRA. SRM allows you to add a script pretty much anywhere along the plan. These scripts are executed on the SRM server so we need to take that into account. My example is made easier by the fact that my SRM server is also my Array Manager. This means I have Solutions Enabler local and can execute a symsnapvx command directly on the server, though calling out to a remote installation would not be that difficult. My script is simple enough:

symsnapvx -f gold_copy.txt -snapshot_name gold_copy terminate -sid xxx -nop
symsnapvx -f gold_copy.txt -name gold_copy establish -sid xxx -nop

The command uses a file with my single device (173) and calls the snapshot “gold_copy” to create a snapshot on the R2. Each time the command is run, the existing snapshot is removed and a new one created. This ensures only one snapshots exists at a time, otherwise the cache usage would grow.

To add the script, simply right-click the first step “Pre-synchronize storage” and “Add Step Before”.

In the dialog box, enter in the command to run the script. Note that I can’t just call the batch file, I need to call a command prompt first and then the script.

Now each time a test failover or actual failover is run, a targetless Gold Copy is created. Here is an example of a test run. Note that I have 2 snapshots, my Gold Copy and then the one the SRA created.

Taking a Gold Copy for failover testing isn’t really essential unless you are running directly against the R2s (TestFailoverWithoutLocalSnapshots). As I’ve noted before, though not recommended, some customers do require using this option. And if you do, taking a Gold Copy before doing the test is essential to protect yourself from an R1 failure.

10-13-2022 Update – SRM Appliance

I had forgotten about this post until someone queried me about using the script callout in the SRM Appliance. Since I only covered Windows above, I wanted to at least briefly mention using the script capability, and thus targetless snapshots, for Gold Copies.

Despite the change in OS (Photon), the SRM interface and how a script step is added has not changed. On the appliance, the script is executed as the srm user and must be in the /home/admin directory. VMware has guidance here. The big difference though, is that above my SRM server was also my Solutions Enabler server so it was easy to execute the script locally. Since SE can’t be put on Photon, it’s not possible on the appliance. You could potentially use REST, and a python script, but it would require installing and upgrading packages on the SRM appliance. I find that a risky proposition to modify the appliance, though it is possible (I’ve done a little testing in the past with it). I think the better course of action is to use a server specifically for any custom scripts. It could even be your management server where SE is installed so you could utilize the same commands as above. In SRM you would still add the local shell script on the appliance, but it would make a remote call to execute a different script on another host. In the end, however, do what makes the most sense for your environment and business.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by

Up ↑

%d bloggers like this: