How-to: NetApp ONTAP 9.1 simulator deployment

This post will show you how to deploy the new NetApp ONTAP 9.1 simulator on a VMware vSphere 6.5 host.

After releasing a post on how to run the setup with Data ONTAP 8.3 (please find here) I thought its worth to write another one as NetApp really changed the simulator in terms of capacity as well as the setup process.

Getting the required Software

  1. Login to with your credentials
  2. Go to “Download – Software” and click on “Data ONTAP Simulator”
    2017-04-01 19_54_19-Settings
  3. Accept the license agreements and terms and conditions.
    2017-04-01 19_54_06-New notification
  4. Download your required OVF template for VMware Workstation or VMware ESX
    as well as the license file.
    2017-04-01 19_53_25-Settings

Read More »

Veeam 9.5 and NetApp: Enterprise performance and scalability for NetApp storage with

Veeam just released version 9.5 of Veeam Backup & Replication. In this blog post, I would like to share some of the new capabilities that 9.5 delivers with our NetApp ONTAP storage integration.

As this is not a major version release, we didn’t add any specific new features, however, there are several improvements with respect towards backup resource scalability, which is of particular importance in enterprise data center environments.

1. Automatic NetApp LIF selection for data traffic

With 9.5, we implemented an advanced way for the Veeam backup server to identify the correct Data LIF for the backup process.
img01-1-700x427In the above example, the VM is stored on an aggregate located on Node 4. With 9.5, we made sure that data LIF4, of node 4, is used to access and backup the VM, instead of using data LIF1 on node 1 and transferring the data over the back-end cluster network. With this new implementation, we avoid the potential for node 1, or the back-end cluster network, to run out of resources during a Veeam backup.

The new cluster aware LIF selection also follows the data in case it is moved to another aggregate on another node, thereby ensuring the optimized path is utilized by the Veeam proxy server to perform data movement.

This functionality is enabled by default and does not require any action from your side to utilize this new capability.

2. Proxy affinity rules for storage access

The second enhancement is a new way to define proxy affinity between your NetApp ONTAP systems and the Veeam proxy server.
img02-1-700x204By using proxy affinity rules, you can easily define Veeam proxy server assignments for each NetApp ONTAP system. If there are multiple NetApp systems and Veeam proxy servers in the same environment, it is recommended to assign affinity relationships to avoid situations where a Veeam proxy server is misaligned with an ONTAP system. This capability saves time in the job initialization process and optimizes proxy resource utilization in larger environments, enabling you to ensure that specific proxy servers are available for specific backup jobs. img03-1-700x275This also ensures that local proxies are only accessing local NetApp ONTAP systems when using network based access protocols like NFS or iSCSI. img04To configure the proxy affinity, simply go to “Storage Infrastructure” within your Veeam Backup & Replication console and select the NetApp cluster you want to modify. Open the advanced settings and select the backup proxies Veeam should use.

3. Protocol selection to optimize proxy data access

One very common user request that we have addressed with 9.5 is the option to assign a different protocol to the Veeam proxy server than the one being used by the VMware server. Before 9.5, you could use different REG-Keys to force the Veeam proxy to use a different protocol. img05-1-700x466Now with 9.5, you can easily deploy a configuration where VMware is accessing the ONTAP cluster by FC, while the Veeam proxy uses iSCSI for backup and replication and all of the other Veeam features. Since the LUN is the same block device, it can be accessed via FC, iSCSI or both, enabling you to leverage your existing 10 GB network to back up the data via FC or iSCSI (or vice versa).

Besides the benefit of defining a different access protocol, you can also reduce the time that the Veeam proxy needs to scan and access your NetApp data and start a job, as the overhead required to check all available protocols is eliminated. In short, it’s a very simple way to optimize your existing Veeam and NetApp installation. img06To configure the protocol selection, simply go to “Storage Infrastructure” within your Veeam Backup & Replication console and select the NetApp cluster you want to modify. Open the advanced settings and select the protocol to be used by the Veeam proxy host. As shown in the above example, only the licensed ONTAP protocol is available to use.

In summary, the enterprise enhancements available in 9.5 make the Veeam integration with ONTAP more flexible and scalable. This is another great example of Veeam product development implementing feature enhancements based on the direct feedback from our customers and partners.

For additional Veeam and NetApp best practices, I highly recommend the following documents and articles:

Must see sessions at NetApp Insight Berlin


After attending NetApp Insight in Berlin I’d like to give you an overview on the sessions I would highly recommend to attend.

46322-2 – Flash to Disk to Cloud: VM Data Protection with Veeam, AltaVault and StorageGRID Webscale
Virtual machine data is often the largest and most critical data companies can have. It also tends to be the most laborious and difficult to properly protect. This breakout will explain and demonstrate how to simply configure a protection policy to migrate your virtual machine data from flash to a disk archive, and finally to a cloud repository. We will also discuss how to keep the right data on the right tier of storage.
Monday, Nov 14, 11:00 AM – 12:00 PM
Tuesday, Nov 15, 1:00 PM – 2:00 PM

60615-3 – NetApp SolidFire Technical Deep Dive
Understand the NetApp® SolidFire® architecture? Know how the product can be operated and managed? Ready for the firehose? Come listen to SolidFire developers and engineers dig deeply into the magic of the SolidFire storage software. Slice services, node elections, quality of service algorithms, data pathing, failure scenarios and more — nothing will be out of bounds. Time will be left to take questions from the audience, so no stone will be left unturned.
Tuesday, Nov 15, 10:30 AM – 12:30 PM
Thursday, Nov 17, 10:30 AM – 12:30 PM

94567-2 – Veeam: The best thing you didn’t know Veeam & NetApp can do for you
Attend this breakout session to see how Veeam and NetApp can: · Powerful recovery techniques with Veeam Explorer for NetApp Storage Snapshots: Recover individual items or entire VMs quickly and efficiently from NetApp Snapshot, SnapMirror and SnapVault. · Avoid data loss with Backup from NetApp SnapMirror and SnapVault: Protect your environment’s high performance by completely eliminating backup impact on your production storage. · Leverage NetApp data with On-Demand Sandbox for Storage Snapshots: See how Veeam’s On-Demand Sandbox can easily create isolated copies of your environment.
Tuesday, Nov 15, 2:15 PM – 3:15 PM

47573-1 – Hands-On Lab: VMware vSphere 6 on MetroCluster
This lab demonstrates the high availability of a stretched VMware® DRS cluster infrastructure built on the synchronous mirroring of NetApp® MetroCluster™. The lab also offers a few basic failure scenarios, and highlights survivability using MetroCluster to provide continuous access to storage across geographically separated datacenters. To create a lab reservation on your schedule, please search for the session ID starting with “Lab-10XX” and reserve your seat in the Hands-On Labs area.

52600-2 – NetApp MetroCluster: New Features in ONTAP 9 and Basics of Building a Zero-Downtime Infrastructure
In this session, you will learn about the new NetApp® MetroCluster® features in ONTAP® 9. We’ll also consider the implications of distance and bandwidth between MetroCluster sites and the maximum performance figures in a MetroCluster infrastructure. Finally, we’ll look at what benefits All Flash FAS provides and which minimum configurations are supported.

94568-2 – The Veeam 3-2-1 Data Protection Rule in NetApp’s Data Fabric
In today’s Enterprise Data Centers Availability is key for success. It’s very important to have a valid and proven Data Protection Design that delivers the required business RTO’s and RPO’s. Learn how to lower RTO’s and RPO’s and enhance application Availability by applying the 3-2-1 backup rule. You will learn how to deliver Availability for the Always-On Enterprise by combining NetApp ONTAP, FlexPod, AltaVault and the Veeam Availability Suite.
Wednesday, Nov 16, 2:00 PM – 2:30 PM

Of course there are much more sessions to attend.
Don’t miss to reserve your seat soon before they are getting full.
The session scheduler can be found here Session Builder.

I will be around at NetApp Insight in Berlin as well and deliver session 94568-2 as well as 94567-2.

Let me know when you’re coming an we can meet up. Just ping me on Twitter under @rennerstefan.

See u there.

Enterprise datacenter Availability with NetApp cascaded SnapMirror and Veeam

Data Availability has become more and more important for today’s businesses. The NetApp Data ONTAP and Veeam combination provides a high Availability level for the Always-On Enterprise. By leveraging NetApp data protection features like snapshots, SnapMirror and SnapVault, Veeam is able to enhance recovery time and recovery point objectives, otherwise known as RTPO, for VMs and applications residing on NFS-, FC-, FCoE- and iSCSI-based arrays.

Some enterprise data centers are leveraging NetApp’s ability to cascade ONTAP systems to maximize Availability. In this blogpost, I explain the benefits of leveraging an ONTAP cascaded design with Veeam.

The environment

Let’s assume the customer has the following data center design and requirements:

  1. In the primary data center, a NetApp ONTAP system named RLPEDGE01, with a source volume called NFSVAULT
  2. On the secondary side, a NetApp ONTAP system RLPEDGE02, with a SnapVault destination Volume RLPNFS01_NFSVAULT_vault
  3. At the third side, a NetApp ONTAP system RLPEDGE03, with a SnapMirror destination volume RLPNFS03_NFSVAULT_mirror

The requirements include using SnapVault between RLPEDGE01 and RLPEDGE02, combined with application-consistent snapshots. Furthermore, the customer wants to use SnapMirror to replicate the SnapVault data to RLPEDGE03, which is in a co-location facility.

Veeam orchestration combined with NetApp protection policies

To build this configuration, NetApp ONTAP protection policies are combined with Veeam’s advanced storage integration and orchestration capabilities.

  1. Veeam creates an application-consistent backup of VMs. This includes the optional log truncation and snapshot creation within the VMware environment.
  2. Next, Veeam instructs the primary NetApp system (RLPEDGE01) to perform an array-based snapshot and subsequent orchestration.
  3. Next, the primary NetApp system will manage the SnapVault update to the secondary (RLPEDGE02) and retention policies of these snapshots within both primary and secondary systems.
  4. The NetApp ONTAP built-in protection engine handles the SnapMirror update between the secondary and the tertiary (RLPEDGE03) NetApp systems. Through this process, all snapshots on RLPEDGE02 will be mirrored to RLPEDGE03 and made available for restores.

The customer benefits here by being able to leverage Veeam’s native restore capabilities on any NetApp ONTAP platform in the environment. This includes the third NetApp system, RLPEDGE03, which is not part of the Veeam snapshot orchestration process. The restore functionality permits granular restores using Veeam Explorers for Storage Snapshots to perform file, item or VM image-based recoveries for Microsoft Active Directory, Exchange, SharePoint, SQL and Oracle. Veeam OnDemand Sandbox capabilities can also leverage NetApp snapshots to create isolated test environments for testing application updates, patches and other changes, without impacting the production environment.

Let’s get it done

To set up this configuration, follow these steps:

  1. Add all NetApp ONTAP systems to your Veeam Backup & Replication console
  2. Create the SnapVault relationship between primary and secondary NetApp systems
  3. Create a Veeam job to protect your VMs:
    1. Within the Veeam job set the desired SnapVault retention policies
    2. If required, enable Application-Aware Processing
    3. Define a schedule for the job that meets the RPO of applications being protected

If you require any assistance creating a Veeam/NetApp backup job, you can find additional detail in the Best Practices Guide.

After Veeam Backup and NetApp SnapVault are configured and running, we can now set up the SnapMirror relationship to the third NetApp system. However, you should pair NetApp 2 and NetApp 3 and ensure that the proper SnapVault Mirrors (SVMs) are available and paired as well. In addition, create a DP Volume on the NetApp 3 SVM, which will be used as the destination target for the SnapMirror volume.

NOTE: Veeam assumes no warranty for any command. These commands should only be used as a reference. Exercise CAUTION when working in any production environment. All commands should be modified (cluster, volume, vservernames, etc.) to fit in your environment.

After the volume is created, you can create the SnapMirror policy and the SnapMirror relationship:

To create the SnapMirror policy run:

snapmirror policy create -vserver SVMNFS03 -policy VeeamSM -tries 8 -transfer-priority normal -ignore-atime false -restart always -type async-mirror

Add the rule to mirror all source snapshots: all_source_snapshots. This is mandatory, otherwise you will get an error that the SnapMirror label was not found:

snapmirror policy add-rule -vserver SVMNFS03 -policy VeeamSM -snapmirror-label all_source_snapshots -keep 1
snapmirror policy show

SnapMirror relation creation and initialization:

snapmirror create -source-path RLPNFS02:RLPNFS01_NFSVAULT_vault -destination-path SVMNFS03:RLPNFS03_NFSVAULT_mirror -type DP -throttle unlimited -identity-preserve false -vserver SVMNFS03 -policy VeeamMirror

snapmirror initialize -destination-path SVMNFS03:RLPNFS03_NFSVAULT_mirror

snapmirror modify -destination-path SVMNFS03:RLPNFS03_NFSVAULT_mirror -schedule 5min

snapmirror show

You can also check the SnapMirror relationship within the NetApp System Manager on the third NetApp to get the following screen view:
6Now that the SnapMirror relation has been initialized and running (in our case, every 5 minutes), check the Veeam interface to verify that snapshots on the third NetApp platform are available for restores.

Your Veeam interface should look similar to this:
7As you can see, all three NetApp systems are available, as well as the three volumes. When browsing the volumes on RLPEDGE02 and RLPEDGE03, we see the same number of available snapshots (one snapshot is the baseline image).
8With the configuration complete, we now have a cascaded SnapVault to SnapMirror relationship from which all Veeam restore capabilities can be used. One of the benefits of the direct integration Veeam provides is the ability to directly restore from array-based snapshots.

In the example below, we illustrate how an administrator can browse our NetApp system RLPEDGE03, view the VMs within that snapshot and perform all of the great recovery options that Veeam has available. In summary, this scenario illustrates how we’ve executed a single NetApp snapshot, which has been cascaded down to our tertiary device where we’re able to perform recovery. This process drastically reduces the load placed on the production environment during backup and recovery operations, which in turn, increases the RTPO for our applications and services.

What about Veeam Backup from Storage Snapshots?

Veeam Backup from Storage Snapshots is a unique technology that optimizes VM backup by leveraging Storage Snapshots as a source for the Veeam data stream. In the scenario that was just explained, you can fully leverage Veeam Backup from Storage Snapshots from the primary or secondary NetApp ONTAP storage device. Veeam orchestrates all the snapshots processes across these two storage systems.
10To complete the cascade process, and as mentioned earlier, the SnapMirror relation toward the third NetApp ONTAP system is handled by the data protection engine of ONTAP, and is not a part of Veeam orchestration.

Datacenter 4.0 – A reference architecture with Cisco, NetApp and Veeam

Today’s business relies on the IT department more than ever. The Internet of Everything (IoE) now requires a fully functioning datacenter to avoid business grinding to a halt, products not reaching the market and services disappearing. It is impossible to meet all user, customer or partner expectations without a fully functioning datacenter, which is the driving force for organizations to modernize and optimize their IT resources.

An important part of this modernization is standardizing predictable, repeatable and very stable data center reference architectures.

The reference architecture defines a technology design and deployment that addresses the specific requirements of a business need. This includes the blueprint and best practices for installation and configuration, which all work together in the most optimal state. The reference architecture defines which specific technologies and products are combined and how address them in a particular use case. The reference architecture is a template solution for enterprise IT.Read More »

Named as NetApp A-Team member

2016-04-05 09_37_56-Introducing the NetApp A-Team EMEA Chapter - NetApp Community

I’m very proud that today I was named as a NetApp A-Team member for the EMEA chapter of NetApps Advocates group.

What is the NetApp A-Team?
A group of Advocates of NetApp solutions.

Below you can find some additional, NetApp official, information’s about the NetApp A-Team EMEA chapter (Copyright by NetApp, for full post click here)

Community overview
Like-minded and outspoken in their passion for all things NetApp, the NetApp A-Team members leverage social media to tell their stories.

Join a community of  NetApp Experts that are passionate about our industry and share your knowledge and expertise as part of a select group. By joining the NetApp A-Team EMEA Group you will:

  • Be connected with NetApp Experts and Peers
  • Be recognized as the NetApp Ambassador in your region
  • Join the conversation and stay updated with major news
  • Raise your voice and get connected with NetApp Social Media Channels


  • Invitations to meet 1:1 with high-level NetApp executives and subject matter experts
  • Opportunities to participate in product launches and industry events
  • Exclusive NDA briefings on new products and roadmaps
  • Industry recognition as NetApp experts

How are the A-Team EMEA members selected?

  • NetApp identifies potential members  that meet the community criteria
  • Partner can proactively nominate themselves by contacting the NetApp team

Who is eligible to be a Member?
Partners are selected to participate in the program based on their level of passion for NetApp products and solutions, their technical expertise, and their influence in the “socialsphere”.

Don’t forget to tag your tweets with @NetAppATeam #ATeamEMEA 

NetApp SnapMirror policies and Veeam integration

Since years NetApp has the two different data protection mechanisms SnapMirror and SnapVault. SnapMirror is used to mirror the state of the volume to a secondary volume including all SnapShots and can be used to be a disaster recovery solution. SnapVault is used to build up a data protection (backup) solution based on SnapShots. With SnapVault you can define different numbers of SnapShots for primary and secondary volume. You can e.g. save 10 SnapShots on your production for instant recovery, primary volume and keep 200 SnapShots on you secondary volume for long-term retention.

With Data ONTAP 8.3 NetApp has extended the data protection relationships (type XDP) support by two more use cases, mirroring and mirror-vault. Mirror-Vault can be used to have one data protection relation for both, backup (SnapVault) and disaster recovery (SnapMirror). In previous versions you only had one data protection (type DP) relationship for async-mirror (SnapMirror) and one extended data protection relationship (type XDP) for SnapVault. The table below explains the current available types of data protection policies and their related results. The new flexible version SnapMirror is part of XDP as well.


As you can see, NetApp integrated the two new type into the XDP type. Veeam supports all four different types of data protection policies and relation types.

If you want to use any kind of secondary integration, you simply have to choose in our job settings.

Depending on your SnapMirror policy type you now have to select different options to get the update to a secondary ONTAP running.

Standard SnapMirror relation (async-mirror, DP)
To get a standard SnapMirror relation working you have to choose “Configure secondary destination for this job” in your Veeam Job in the section “Storage”.
2015-12-23 10_13_02- - Remote Desktop Connection

In the next section “Secondary Target” you can now add a SnapMirror update by clicking on “Add” and selecting “SnapMirror”.
2015-12-23 10_14_24- - Remote Desktop Connection

In the appearing window you simply click on “OK” to add SnapMirror secondary target job to your original Veeam Job.
2015-12-23 10_14_57- - Remote Desktop Connection

You will see the SnapMirror Job in the GUI.
2015-12-23 10_15_59- - Remote Desktop Connection

Standard SnapVault relation (vault, XDP)
To get a standard SnapVault relation working you have to choose “Configure secondary destination for this job” in your Veeam Job in the section “Storage”.
2015-12-23 10_13_02- - Remote Desktop Connection

In the next section “Secondary Target” you can now add a SnapVault update by clicking on “Add” and selecting “SnapVault”.
2015-12-23 10_17_01- - Remote Desktop Connection

In the appearing window you have to specify the amount of SnapShots that should be saved on the secondary window (SnapVault retention). In our case 30 SnapShots will be saved on the secondary volume.
2015-12-23 10_18_02- - Remote Desktop Connection

After a click on “OK” you will see the SnapVault integration immediately in the GUI.
2015-12-23 10_18_25- - Remote Desktop Connection

Version Flexible SnapMirror (async-mirror, XDP)
To get a version flexible SnapMirror relation working you have to choose “Configure secondary destination for this job” in your Veeam Job in the section “Storage”.
2015-12-23 10_13_02- - Remote Desktop Connection

As the version flexible SnapMirror is relation type is XDP Veeam recognizes them as a SnapVault relation. That means that you have to select “NetApp SnapVault” under “Add” in the “Secondary Target” window.
2015-12-23 10_17_01- - Remote Desktop Connection

In the appearing window you can leave everything on default. As it is a mirror the number of SnapShot copies for secondary does not have any effect. The number of SnapShots that will be saved on the secondary volume is depending on what you’ve entered in the Job setting “Storage” section under “Restore points to keep on disks”.
2015-12-23 10_18_02- - Remote Desktop Connection

After a click on “OK” you will see the version flexible SnapMirror integration immediately in the GUI (shown as NetApp SnapVault).
2015-12-23 10_18_25- - Remote Desktop Connection

Mirror and Vault combined (MirrorAndVault, XDP)
To get a version combined SnapMirror/SnapVault (mirror-vault) relation working you have to choose “Configure secondary destination for this job” in your Veeam Job in the section “Storage”.
2015-12-23 10_13_02- - Remote Desktop Connection

As the mirror-vault relation type is XDP Veeam recognizes them as a SnapVault relation. That means that you have to select “NetApp SnapVault” under “Add” in the “Secondary Target” window.
2015-12-23 10_17_01- - Remote Desktop Connection

In the appearing window you can specify the number of SnapShots that should be saved on the secondary volume. In our case we save 30 SnapShots on the secondary volume.
2015-12-23 10_18_02- - Remote Desktop Connection

After a click on “OK” you will see the mirror-vault integration immediately in the GUI (shown as NetApp SnapVault).
2015-12-23 10_18_25- - Remote Desktop Connection

How to setup a SVM DR in CDOT 8.3.1 including all configuration and data

With Data ONTAP 8.3.1 NetApp introduced the long expected SVM-DR. With the new feature you can easily build up a disaster recovery solution for your SVMs. In this post I’m going to show you how you can setup a SVM-DR relation between two different ONTAP clusters. It will be a SVM-DR where all information’s including CIFS, NFS and IP-Addresses are replicated to the destination cluster. There is also a possibility to perform some kind of advanced configuration for subnet and interface mapping if required.

We will look into the steps performed on source and destination cluster to setup the SVM-DR, perform a Failover test, rollback to source and resync after failback. Before you start please make sure that the two ONTAP cluster are peered already and your source SVM is up and running. Please note that in this sample we are working with CIFS and NFS only. SVM DR can also be configured for iSCSI and FC but therefore you need to perform more steps regarding interfaces and iGroups. Please have a look to the NetApp documentation for advanced setup. All steps are done by CLI only. Right now there is now integration into the system manager.

As every time, no warranty for the scripts. You need to change the SVM and cluster names to make it working for you. We are working on a SVM lever here.

Initial Setup:
First we will have a look into how an initial SVM-DR relation is configured.

On the destination cluster:
1. Create your new DR SVM on the destination cluster. The important thing here is to set the subtype to dp-destination:

vserver create -vserver SVMDR02 -subtype dp-destination

2. Create a peer relationship between your destination SVM the source SVM:

vserver peer create -vserver SVMDR02 -peer-vserver SVMDR -peer-cluster RLPEDGE01 -applications snapmirror

On the source cluster:
3. Accept the peer relationship on the source cluster for the source SVM:

vserver peer accept -vserver SVMDR -peer-vserver SVMDR02

On the destination cluster:
4. Create a new snapmirror relationship between your source and destination SVM. Setting the identity-preserve to true means that all configuration and data will be transferred. The schedule is set to hourly in our case. If you want to change the schedule you can create your own and set it afterwards.

snapmirror create -source-vserver SVMDR -destination-vserver SVMDR02 -type DP -throttle unlimited -policy DPDefault -schedule hourly -identity-preserve true

5. Initialize your relationship

snapmirror initialize -destination-path SVMDR02:

The initial setup is now done and the SVM-DR is mirroring according to your schedule. You can even see the destination SVM in the system manager as a powered off SVM.
2015-12-23 13_36_57-Settings

Failover to secondary SVM (DR Test):
Next step is to perform a failover to our secondary SVM. Attention: This means you will have some downtime of your data. Only perform this if you are sure that you want to test to failover. Again, no warranty for any outage or failures in your data center.

On the source cluster:
1. First you have to stop you running SVM on the source cluster:

vserver stop -vserver SVMDR

On the destination cluster:
2. Before we failover we update the snapmirror relationship to get the latest version of the source data and configuration:

snapmirror update -destination-path SVMDR02:

3. After the update is finished (please check with snapmirror show) we quiesce the relationship to make sure there is no task running:

snapmirror quiesce -destination-path SVMDR02:

4. After the quiesce is finished (please check with snapmirror show) we can break the snapmirror to make the destination writeable:

snapmirror break -destination-path SVMDR02:

5. After the break is finished (please check with snapmirror show) we can start the secondary SVM:

vserver start -vserver SVMDR02

The Failover is now completed and you should be able to ping and access all you data.

Failback to source (After DR Test):
After a successful failover and tests we are ready to failback to the source SVM. In case you had a disaster and the source SVM is no longer available you have to create a new one. Please refer to the NetApp guides on how to proceed here.

On the source cluster:
1. First we have to create a new snapmirror relationship from the DR SVM to the source SVM:

snapmirror create -source-path SVMDR02: -destination-path SVMDR: -type DP -throttle unlimited -identity-preserve true

As soon as the relationship is created we can perform a resync to sync the changed data back to the source SVM:

snapmirror resync -destination-path SVMDR:

On the destination cluster:
3. After the resync is done (please check with snapmirror show) we can shut down the DR SVM. Attention, this means downtime:

vserver stop -vserver SVMDR02 -foreground true

On the source cluster:
4. After the DR SVM is done (please check with SVM show) we can update the snapmirror relation:

snapmirror update -destination-path SVMDR:

5. After the update is done (please check with snapmirror show) we can quiesce the relation:

snapmirror quiesce -destination-path SVMDR:

6. After the quiesce is done (please check with snapmirror show) we can break to relation to make the source writable:

snapmirror break -destination-path SVMDR:

7. After the break is done (please check with snapmirror show) we can now boot up the original source SVM:

vserver start -vserver SVMDR

Your source SVM is now back online and can be used.

Resync after Failback:
After a successful failback we now want to have the original state back. Meaning the source SVM should proceed with replicating to the destination SVM. Therefore we have to resync the original SnapMirror relation.

On the destination Cluster:
1. To resync the original SnapMirror relation please execute the following:

snapmirror resync -destination-path SVMDR02:

On the source cluster:
2. After everything is done you can delete the SnapMirror relation which was used to resync back to source.

snapmirror delete -destination-path SVMDR: