Netapp snapmirror unified_replication_v1.2-lab_guide

SnapMirror Unified Replication
September 2016 | SL10232 Version 1.1

2 © 2016 NetApp, Inc. All rights reserved. NetApp Proprietary
1 Introduction
SnapMirror and SnapVault deliver powerful data management capabilities, including the ability to protect critical
data, while providing the flexibility to move data between locations and storage tiers.
• SnapMirror provides asynchronous mirroring of volumes from one Storage Virtual Machine (SVM) to
another, even across different clusters.
• SnapVault provides storage-efficient and long-term retention of backups through asyncronous
replication.
With SnapMirror and SnapVault, you can reduce your overall TCO, and make it easier to justify DR investment by
putting your DR site to active business use.
SnapMirror and SnapVault also offer the following benefits:
• Provides a standardized multipurpose replication solution. SnapMirror® can protect mission critical
business with simple, efficient replication for disaster recovery, and extends the value of replicated data
to accelerate business needs.
• Reduces bandwidth utilization using native network compression, and accelerates data transfers
resulting in a lower recovery point objective (RPO).
• Reduces management overhead through a unified architecture.
• Allows you to easily manage replication across different storage array tiers and protocols with the same
tool.
• Thinly replicated SnapMirror configurations extend the primary storage efficiencies of virtualized
environments.
• Proven, tested, and integrated with leading industry partners, NetApp is recognized as one of the
largest storage replication vendors and works with major partner applications to simplify and automate
data management.
1 Lab Objectives
The overall objective of this lab is to familiarize you with Data Protection and Replication technologies like
SnapMirror and SnapVault in ONTAP. You will learn how to modify policies as part of SnapVault and SnapMirror
relationships. Additionally, the lab will take you through the steps required to configure and monitor SnapVault
and SnapMirror relationships using NetApp Manageability tools and the Command Line Interface.
1 Prerequisites
This lab assumes you have a basic working knowledge of ONTAP, but does not require any previous experience
with SnapMirror or SnapVault.

2 Lab Environment
All of the servers and storage controllers presented in this lab are virtual devices, and the networks that
interconnect them are exclusive to just your lab session. The virtual storage controllers (vsims) offer nearly all the
same functionality as do physical storage controllers, but at a reduced performance profile. Currently, the main
exception is that vsims do not offer HA support.
Figure 2-1: Virtual Servers and Storage Controllers
2 Table of Systems
Host Name Operating System Role/Function IP Address
jumphost Windows Server 2012 R2 Primary desktop in lab 192.168.0.5
cluster1 ONTAP 9 Storage controller 192.168.0.101
dc1 Windows Server 2012 R2 Active Directory / DNS 192.168.0.253

2 User IDs and Passwords
Host Name User ID Password Comments
jumphost DEMOAdministrator Netapp1! Domain Administrator
cluster1 admin Netapp1! FAS administrator
dc1 DEMOAdministrator Netapp1! Domain Administrator

3 Lab Limitations
This lab has the following limitations:
• All of the servers and storage controllers presented in this lab are virtual devices. Consequently, any
operations that involve moving large quantities of data will not exhibit performance representative of
real systems.

4 Lab Activities
In this lab you will explore the following topics:
• Basic SnapMirror and SnapVault concepts.
• SnapMirror relationship failover and failback (e.g., breaking and reversing mirror/vault relationships).
• Cascaded SnapMirror and SnapVault.
• Disaster Recovery for Storage Virtual Machines (SVM DR)

5 SnapMirror Concepts
SnapMirror in ONTAP provides asynchronous volume-level replication based on a configured replication update
schedule. SnapMirror uses NetApp Snapshot technology as part of the replication process.
SnapMirror periodically updates the replica to create new backups and/or to keep it up-to-date with changes
that have been written to the primary. The SnapMirror subsystems are designed to keep many pairs of source
(primary) and destination (secondary) copies up-to-date in an efficient and scalable manner.
Integration with vendors such as Citrix, Microsoft, and VMware® ensures that the benefits of SnapMirror in a
physical server environment are equally applicable in a virtual environment.
Beginning with clustered Data ONTAP 8.1, the following functionality is available:
• Data protection mirrors that give users the ability to create backup copies within the same cluster
(intracluster), or to create a DR copy in a different cluster (intercluster).
• Load-sharing mirrors that allow replication from one volume to multiple volumes in the same cluster to
distribute a read-only workload across the cluster.
• Scheduled snapmirror processes are restarted in the event a disruptive event occurs.
• The ability to restore single files and luns.
5.1 Basics of SnapMirror Replication
Once two volumes have an established SnapMirror relationship, the scheduler assumes the responsibility for
triggering replication updates. The following operations are performed during each update:
• A new snapshot copy is created on the source volume.
• The difference between the new snapshot copy and the last replicatioon snapshot copy is determined,
and then transferred to the destination volume. This transfer includes any other snapshot copies that
were created between the last replication snapshot and the new one.
• When the transfer is complete, the new snapshot copy exists on the destination volume.
A SnapMirror destination volume is available for read-only access if it is shared using Common Internet File
System (CIFS) protocol, or exported using Network File System (NFS) protocol. A logical unit number (LUN) in
the replicated volume can be made available to a client that supports connection to read-only LUNs.
Replication occurs at the volume level. Qtrees can be created in ONTAP, and replicated along with the volume;
however, an individual qtree cannot be replicated separately from it’s containing volume.
DP relationships can be resynchronized in either direction after a failover without recopying the entire volume.
If a relationship is resynchronized in the reverse direction, only new data written since the last successful
synchronization snapshot is sent back to the destination.
Starting with clustered Data ONTAP 8.2, a cluster administrator can delegate the management of SnapMirror
relationships to a Storage Virtual Machine administrator.
5.2 Exercise
In this exercise you will look at an existing SnapMirror relationship between a source and destination volume.
1. On the Jumphost, launch the Chrome web browser from the task bar.

1
Figure 5-1:
2. Click on the browser toolbar button for cluster2 System Manager.
3. Fill in the System Manager login credentials:
• User Name: admin
• Password: Netapp1!
4. Click the Sign In button to log in to System Manager.
2
3
4
Figure 5-2:
System Manager displays the Dashboard view for cluster2.
5. In the dashboard view for “cluster2”, click Protection > Relationships on the command bar. The
command bar is the row of tabs that resides just below the blue bar that says “NetApp OnCommand
System Manager”. If you do not see a Protection entry on the command bar, try expanding your
Chrome browser window.

5
Figure 5-3:
System Manager now displays the Relationships pane.
6. In the “Relationships” pane, select the relationship with the source volume snapmirror_src1. You may
need to expand the column headings by dragging the separators to see the full name of the source
volume.
7. In the lower pane, select the Policy Details tab.
8. Note that this particular SnapMirror relationship is using the DPDefault policy. This is a default policy
supplied with ONTAP that contains reasonable defaults suitable for most typical relationships.
9. Back in the “Relationships” pane, click the Edit button on the toolbar above the selected SnapMirror
relationship.

6
7
8
9
Figure 5-4:
The “Edit Relationship” dialog window opens, and displays the source and destination volumes for the
selected relationship. Here you can alter the relationships' assigned Mirror Policy and Schedule. You can
again see that this relationship is using the “DPDefault” Mirror Policy, but now you can also see that it is
using the predefined schedule 5min, which the accompanying summary information indicates runs every
day, every 5 minutes of each hour. This is a custom schedule that was created specifically for this lab.
If you want to create a new policy or a new schedule, you could use the hyperlinks on the right of this
window to start that process, but to view the details of existing policies or schedules you have to look
elsewhere, as you will see later in this lab.
10. Click the Cancel button to close this window without applying any changes.

10
Figure 5-5:
The “Edit Relationship” window closes, and focus returns to the Relationships view in System Manager.
11. Click on the SVMs tab on the System Manager command bar.
12. Click the link for svm_dst1.
11
12
Figure 5-6:
System Manager displays the “Overview” page for svm_dst1.

13. Select the SVM Settings tab at the far right of the new tab bar that now appears under the command
bar.
14. In the pane that now displays on the left hand side of the window, click Protection Policies, which you
will find under the “Policies” section of that pane.
15. Note that there are no policies listed in the “Protection Policies” pane, not even the standard DPDefault
policy. ONTAP comes with several pre-defined standard policies, none of which are editable, and this
view only displays custom policies.
Note: To see the details of the predefined standard policies you must use the snapmirror
policy show command from the ONTAP command line. You are welcome to try this on your own
if you like, but doing so is not covered in this lab exercise.
16. Click Create in the right pane.
13
14
15
16
Figure 5-7:
The “Create Policy” window opens.
17. Examine the fields in this window. A “Policy Type” value of “Asynchronous Mirror” indicates a
SnapMirror relationship, and when that value is selected then the other fields in this window allow you
to control various aspects of the resulting SnapMirror relationship. The other possible “Policy Type”
values are used for Unified Replication and SnapVault relationships. Notice how the contents of the
“Create Policy” window change as you select different “Policy Type” values.
18. When you are finished reviewing the contents of the “Create Policy” window, click Cancel.

18
17
Figure 5-8:
The “Create Policy” window closes, and focus returns to the “SVM Settings” view in System Manager.
Now you will take a closer look at the schedules that exist on cluster2.
19. On the command bar, navigate to Protection > Schedules.
20. In the “Schedules” pane, select the 5min schedule.
21. Click the Edit button.
19
20
21
Figure 5-9:

The “Edit Schedule - 5min” window opens. As you saw earlier, this particular schedule will run every 5
minutes, but now you can see the many options you have for defining a schedule. Feel free to explore
through the different scheduling options that become available when you switch between the Basic,
Interval, and Advanced radio button selections.
22. When you are finished exploring, click Cancel to discard any changes you may have made to the 5min
schedule during your exploration.
22
Figure 5-10:
The “Edit Schedule - 5min” window closes, and focus returns to the “Schedules” view in System
Manager.
Since SnapMirror leverages NetApp Snapshot technology, several aspects of SnapMirror behavior
are governed by the underlying volume’s snapshot configuration. For volumes that are in a SnapMirror
relationship, the source volume’s snapshot configuration applies to both the source and destination
volumes, so you will now look at cluster1 to view the source volume’s snapshot configuration.
23. Open a new Chrome browser tab.
24. Click on the browser toolbar button for cluster1 System Manager.
25. Enter the User Name admin, and the password Netapp1!.
26. Click Sign In.

23
24
25
26
Figure 5-11:
System Manager displays the “Dashboard” view for cluster1.
27. Select the SVMs tab on the command bar.
28. Select the hyperlink for the SVM named snap_src1.
27
28
Figure 5-12:
System Manager now displays the Overview page for the snap_src1 SVM.
29. Select the Volumes tab from the tab bar that now appears below the command bar.
30. Select the entry for the snapmirror_src1 volume in the “Volumes” pane.
31. On the menu bar inside the “Volumes” pane, select Snapshot Copies > Configure.

29
30
31
Figure 5-13:
The “Configure Volume Snapshot Copies” window opens.
32. The Snapshot Reserve (%) field specifies what percentage of the volume’s disk space is set aside
for Snapshot copies. For FlexVol volumes, the default Snapshot copy reserve is set to 5 percent of the
disk space. The active file system cannot consume the Snapshot copy reserve space, but the Snapshot
copy reserve, if exhausted, can use space in the active file system. Verify that the Snapshot reserve
percentage field is set to 5%.
33. Click Cancel.

32
33
Figure 5-14:
The “Configure Volume Snapshot Copies” window closes, and focus returns to the Volumes view in
System Manager.
Finally, create a SnapMirror relationship for an existing source volume using System Manager.
34. Select the Chrome browser tab for cluster2.
35. Navigate to Protection > Relationships.
36. In the “Relationships” pane, click Create.

34
35
36
Figure 5-15:
The “Browse SVM” window opens.
37. Select the entry for the SVM named svm_dst1
38. Click Select.

37
38
Figure 5-16:
The “Browse SVM” window closes, and the “Create Protection Relationship” window opens.
39. In the “Relationship Type” section, leave the “Relationship Type:” field set to to the default value of
Mirror to indicate that this is a SnapMirror relationship.
40. Check the Create version-flexible mirror relationship checkbox.
41. In the “Source Volume” section, use the Browse... button next to the “Storage Virtual Machine:” field to
set that field to snap_src1.
42. Use the Browse... button next to the “Volume:” field to set that field to mirror_me.
43. In the “Destination Volume” section, use the Browse... button next to the “Aggregate” field to set the
value of that field to aggr_dp. Leave all other fields in this section at their default values.
44. In the “Configuration Details” section, use the Browse... button next to the “Schedule:” field to set the
value of that field to 5min.
45. Scroll down to the bottom of this window and make sure the Initialize Relationship checkbox is
checked. (This checkbox is not shown in the accompanying screenshot, but is checked by default.)
46. Click Create.

39
40
41
42 43
44
45
46
Figure 5-17:
47. The window changes while the wizard executes to display a summary of your selections, along with
status messages for the operations in progress. When execution completes. you will see four entries in
the Status section, all with green checkmarks beside them indicating success.
48. Click the OK button.

47
48
Figure 5-18:
The “Create Protection Relationship” window closes, and focus returns to the “Relationships” view of
System Manager for cluster2.
You can now view information regarding the SnapMirror relationship you just created.
49. While still in the “Relationships” window, click on the mirror_me relationship. The Relationship State
displays as “Uninitialized”, and the Transfer Status displays as “Transferring”.
50. Select the Details tab at the bottom of the screen.
51. Observe that the “Transfer Status” of the SnapMirror relationship you just created is “Transferring”,
indicating that a SnapMirror operation is in progress.

49
50
51
Figure 5-19:
52. In the main pane, click the Refresh button periodically until the “Transfer Status” value changes to
“Idle”.
53. Observe that the "Relationship State" field value has changed from the previous value of "Uninitialized"
to “SnapMirrored”.

52
53
Figure 5-20:
At this point, the baseline transfer of the volume’s contents from the source volume to the destination
volume has completed.
54. Initiate a manual update of the destination volume from the source volume by clicking on the
Operations > Update button at the top of the Relationships pane.

54
Figure 5-21:
The “Update” window opens.
55. The default values are all fine in this window, so click the Update button.

55
Figure 5-22:
The “Update” window closes.
56. The “Transfer Status” field for the relationship changes to “Transferring”.
57. Click the Refresh button again periodically while you watch the update process execute. Once
it finishes the “Transfer State” field will display “Idle” again, at which point the SnapMirror update
operation is complete.

56
57
Figure 5-23:

6 SnapVault Concepts
SnapVault is ONTAP’s integrated disk-to-disk backup solution. Like SnapMirror, it allows you to mirror the
contents of one volume to another, but unlike SnapMirror, SnapVault allows you to keep multiple versions of
your data on the destination volume, and to retain that data on the destination volume for a longer period of time
than you might on your primary volume. Prior to ONTAP 8.3 you could not mix both SnapVault and SnapMirror
characteristics in the same volume but, beginning with ONTAP 8.3, SnapVault now works seamlessly with
SnapMirror, because both now use the same replication engine. This means it is now possible to set retention
periods on snapshots that satisfy both disaster recovery/mirroring, and archiving/vaulting requirements within the
same volume.
Enabling SnapVault on your NetApp system has always been as simple as installing a license key. However,
starting with ONTAP 9 you only need to install a SnapMirror license to create both DP (mirror) and XDP (vault)
type relationships. No additional hardware or software needs to be installed; no additional training for staff is
needed either.
SnapVault for clustered Data ONTAP was introduced in Data ONTAP 8.2. SnapVault was rebuilt from the ground
up for its debut in clustered Data ONTAP, and although former 7-Mode users will find similarities, SnapVault in
clustered Data ONTAP contains many major enhancements. One major advance is the ability to preserve storage
efficiencies on primary data during SnapVault transfers.
Another important architectural change is that SnapVault in clustered ONTAP replicates at the volume level as
opposed to the Qtree level, as in 7-Mode SnapVault. This means that the source of a SnapVault relationship must
be a volume, and that volume must replicate to its own volume on the SnapVault secondary.
6.1 Basics of SnapVault Replication
Backing up volumes to a SnapVault backup involves starting the baseline transfer (the initial transfer when you
first establish the SnapVault relationship), performing scheduled incremental transfers, updating the SnapVault
common snapshot, and restoring data upon request.
• Baseline transfers
A baseline transfer occurs when you initialize the SnapVault relationship. When you do this, Data
ONTAP creates a new Snapshot copy. Data ONTAP transfers the Snapshot copy from the primary
volume to the secondary volume. This Snapshot copy is the baseline of the volume at the time of the
transfer, and is a complete transfer, not an incremental transfer. As a result, none of the other Snapshot
copies on the primary volume are transferred as part of the initial SnapVault transfer, regardless of
whether they match rules specified in the SnapVault policy.
• Incremental transfers
The source system creates incremental Snapshot copies of the source volume as specified by the
Snapshot policy that is assigned to the primary volume. Each Snapshot copy for a specific volume
contains a label that is used to identify it. The SnapVault secondary system selects and retrieves
specifically labeled incremental Snapshot copies, according to the rules that are configured for the
SnapVault policy that is assigned to the SnapVault relationship. The Snapshot label is retained to
identify the backup Snapshot copies. Snapshot copies are retained in the SnapVault backup for as long
as is needed to meet your data protection requirements. The SnapVault relationship does not configure
a retention schedule, but the SnapVault policy does specify the number of Snapshot copies to retain.
• Update SnapVault common snapshot
At the end of each Snapshot copy transfer session, which can include transferring multiple Snapshot
copies, the most recent incremental Snapshot copy in the SnapVault backup is used to establish a new
common base between the primary and secondary volumes, and is exported as the active file system.
• Data restore
If data needs to be restored to the primary volume, or to a new volume, the SnapVault secondary
transfers the specified data from the SnapVault backup.

6.2 Exercise
In this exercise you will look at an existing SnapVault relationship between a source and destination volume.
1. In Chrome, change to the browser tab you previously used to open a System Manager session to
cluster2. If you have already closed that tab, open a new one, and use the cluster2 System Manager
button on the browser's bookmark bar to launch and log in to System Manager for cluster2 (username is
admin, password is Netapp1!).
2. On the command bar, navigate to Protection > Relationships.
3. In the “Relationships” pane, select the entry for the source volume snapvault_src1. You may need to
expand the column headers if the source volume name is partially obscured.
4. Select the Details tab at the bottom of the lower pane to view the details of the SnapVault relationship
from the perspective of the destination cluster. You may need to use the scrollbar at the bottom of the
pane to view all the available fields.
1
2
3
4
Figure 6-1:
5. Click the Policy Details tab at the bottom of the lower pane.
6. The “Policy Name” field indicates that this relationship is utilizing the XDPDefault policy, which is another
indicator that this is a SnapVault relationship.
7. In the main “Protection” pane, make sure that the snapvault_scr1 volume is still selected.
8. Click the Edit button on the menu bar above the list of protection relationships.

5
6
7
8
Figure 6-2:
The “Edit Relationship” window opens. At the top of this window you can see the source and destination
volumes for this relationship, and in the “Configuration Details” section you can see the control fields
used to alter the policy and schedule assignments for this relationship.
9. If you want to create a new policy, or a new schedule, use the hyperlinks on the right of this window to
start that procedure, but to view the details of existing policies or schedules you have to look elsewhere,
as you will see momentarily.
10. Click the Cancel button to discard any changes you might have made.

9
10
Figure 6-3:
The “Edit Relationship” window closes, and focus returns to the “Relationship” view in System Manager.
11. On the System Manager command bar, click SVMs.
12. In the SVM list, click svm_dst1.
11
12
Figure 6-4:
System Manager displays the “Overview” page for the svm_dst1 SVM.
13. On the tab bar that now appears beneath the command bar, click SVM Settings.
14. In the left pane, under the “Policies” section, click Protection Policies.
15. In the “Protection Policies” pane, notice that there are no policies listed, not even the standard
XDPDefault policy. Clustered Data ONTAP comes with several pre-defined standard policies, none of
which are editable, and this view will only show custom policies. To see the details of the predefined
standard policies you need to issue the snapmirror policy show command from the Data ONTAP
command line, an activity not covered in this lab guide.
16. In the right pane, click the Create button.

13
14
15
16
Figure 6-5:
The “Create Policy” window opens. In this window you can see the various properties that you can
assign to a custom protection policy through System Manager.
17. Change the “Policy Type:” field to Vault, which indicates this will be a SnapVault policy.
18. Here you can see many of the same configuration options you saw when you examined how to create
a SnapMirror policy in a previous exercise, including the ability to set transfer priorities, and to enable
network compression. The other options under the “Policy Rules” section enable you to assign labels
and retention values for your SnapVault snapshots.
19. Since the procedure for creating a SnapVault relationship is otherwise the same as creating a
SnapMirror relationship (as you did in the preceding exercise), in the interest of saving time you will not
continue creating a SnapVault relationship here. After you review the contents of the “Create Policy”
window, click the Cancel button to exit the window without applying any changes.

17
18
19
Figure 6-6:
The “Create Policy” window closes, and focus returns to the “SVM Settings” view in System Manager.
SnapVault and SnapMirror share the same scheduling engine, and can also share the same schedules,
although in practice it is common to use different schedules for these two types of relationships as they
often require different update frequencies.
.

7 Failover/Failback
Failover / Failback is the capability to reverse the direction of the SnapMirror relationship between source and
destination volumes. This results in the destination being made writeable and, when you are ready, replicating it’s
updated contents back to the original source volume.
In the event of a DR scenario you can convert SnapMirror destination volumes to active primaries hosting your
business critical applications. Then once the DR event passes, you can easily revert your operations back to their
original sources with minimal data transfer, and no loss of data. You can initiate such a failover at will, so disaster
scenarios can be planned and tested anytime.
7.1 Basics of a Failover Scenario
The following sequence illustrates how to implement a failover scenario, and assumes that you already have an
initialized SnapMirror relationship in place for the volumes in question.
1. Perform a SnapMirror break operation to failover each volume. In the ONTAP operating system,
wildcards can be used to perform a SnapMirror operation on multiple volumes with one command. The
following example command performs failover for all volumes in the destination SVM named “vs5”;
the command can be further restricted to just certain volumes by using part of the volume name in the
command.
Attention: Please do not enter the following command in the lab; this is only an example, and
not part of the lab exercise.
snapmirror break -destination-path cluster02://svm_dst1/*
2. If the volumes have been mounted in the namespace, and CIFS shares and NFS export policies created
and applied, clients then have read-write access to the NAS data.
3. Redirect clients/applications to the destination volume.
It is common practice to have a DR system with a different name than the source system. In DR failover
scenarios, it is typical to change DNS name resolution, or use DNS aliases, to redirect clients to the name of the
recovered storage systems. This enables CIFS shares to be accessible using the same UNC path name, and
NFS clients can also access the expected path. Alternatively, the failed source storage system might be removed
from Active Directory, and the recovery storage system removed and re-added to Active Directory using the
same name as the source system. However, it can take time for this change to propagate through a large Active
Directory environment.
7.2 Exercise
In this exercise you will use System Manager to make an existing SnapMirror destination volume writeable,
and then reverse the relationship so that the original source volume now mirrors the contents of the original
destination volume.
1. In Chrome, select the browser tab for System Manager on cluster2.
3. Click on the relationship for the “snapmirror_src1” volume
4. In the lower pane, select the Details tab so you can see the status details for the selected SnapMirror
relationship.
5. Back in the “Relationships” pane, verify that the snapmirror_src1 relationship is still selected, and then
click Operations > Break from the menu.

1
2
3
4
5
Figure 7-1:
The “Break” window opens.
6. Check the OK to break the selected relationship checkbox.
7. Click the Break button.
6
7
Figure 7-2:

The “Break” window remains open while System Manager processes the break operation, then
automatically closes when finished, and focus returns to the “Relationships” view in System Manager.
8. Notice in the “Details” section that the relationship state has changed to “Broken Off”, which indicates
that the destination volume no longer accepts updates from the source volume, and also that the
destination volume is now writeable.
9. The “Is Healthy” field may also have gone from green to red indicating that the relationship is not healthy.
You may need to hit the Refresh button a few times (wait 5-10 seconds between presses) before this
change becomes visible.
Attention: It can sometimes take several minutes for the “Is Healthy” indicator to go red, even
with refreshes, so feel free to continue with the exercise if your indicator is still green, so long as
the relationship state displays “Broken Off”.
8
9
Figure 7-3:
Now you will create a new file on both the source and destination volumes. The files will have different
names so you can see what happens when you reverse and re-sync the SnapMirror relationship later in
this procedure.
10. On the desktop of jumphost, open Windows Explorer from the taskbar.

10
Figure 7-4:
11. In Windows Explorer, navigate to the J:snapmirror_src1 folder.
12. Right-click in the folder.
13. Select New > Text Document in the context menu.
11
12
13
Figure 7-5:
14. Name the file source.txt.

14
Figure 7-6:
15. Now navigate to the K:snapmirror_dst1 folder.
16. Right-click in the folder.
17. Select New > Text Document in the context menu.
15
16
17
Figure 7-7:
18. Name the file destination.txt.

18
Figure 7-8:
Next create a snapshot on the source volume.
19. Go to System Manager browser tab for cluster1. If necessary, log in with the user name admin, and the
password Netapp1!.
20. On the command bar, click on SVMs.
21. Click snap_src1.
21
19 20
Figure 7-9:
System Manager now displays the “Overview” page for the snap_src1 SVM.
22. On the tab bar that now appears below the command bar, click Volumes.
23. In the volume list, select the entry for the snapmirror_src1 volume.
24. On the row of buttons inside the Volumes pane, navigate to Snapshot Copies > Create.

22
23
24
Figure 7-10:
The “Create Snapshot Copy” window opens.
25. Change the “Snapshot Copy Name” to my_snapshot.
26. Click the Create button.
25
26
Figure 7-11:
The “Create Snapshot Copy” window closes, and focus returns to the “Volumes” view in System
Manager.
27. With the snapmirror_src1 volume still selected in the volume list, click the Snapshot Copies tab in the
lower pane of System Manager.
28. Locate my_snapshot in the snapshot list to verify it's existence.

27
28
Figure 7-12:
At this point the contents of the source and destination volumes both differ from their states when
SnapMirror last synchronized them together. Now you will re-sync the SnapMirror relationship, but
in the reverse direction, where the contents of the source volume are synchronized from the original
destination volume.
29. In Chrome, click on the browser tab for cluster2 System Manager.
30. In the “Relationships” pane, select the relationship for the source volume snapmirror_src1.
31. Select Operations > Reverse Resync from the menu bar.

29
30
31
Figure 7-13:
The “Reverse Resync” window opens.
32. Check the OK to reverse resync the relationship checkbox.
33. Click the Reverse Resync button.

32 33
Figure 7-14:
The “Reverse Resync” window remains open while System Manager completes the reverse operation,
and then automatically closes when finished, returning you to the “Relationships” pane in System
Manager.
34. Notice that the “snapmirror_src1” source volume is no longer present in the protection relationship list.

34
Figure 7-15:
35. In Chrome, select the System Manager browser tab for cluster1.
37. There is now an entry in the “Relationships” pane on cluster1 for the newly reversed relationship. Select
this entry (i.e., the one where the source volume is “snapmirror_dst1”).
38. Click the Details tab in the lower pane, and observe that the source location is now
“svm_dst1:snapmirror_dst1”, and the destination location is “snap_src:snapmirror_src1”.

35
36
37
38
Figure 7-16:
39. On the command bar, select SVMs.
40. In the list of SVMs, select snap_src1.
39
40
Figure 7-17:
System Manager nows displays the “Overview” page for the snap_src1 SVM.
41. On the tab bar that now appears below the command bar, click Volumes.
42. In the “Volumes” pane, select the volume snapmirror_src1.
43. In the lower pane, click the Snapshot Copies tab.
44. Try to locate the “my_snapshot” snapshot you created earlier in this exercise after breaking off the
original SnapMirror relationship. That snapshot is not present now because when you reversed the

relationship, the source volume reverted to the most recent snapmirror snapshot that both the source
and destination volumes had in common, which is an earlier snapshot than “my_snapshot”. The resync
then replicated any changes on the destination volume that had occured after that common snapshot
back to the source volume.
41
42
43
44
Figure 7-18:
45. Go back to Windows Explorer, select the K: drive (the original destination volume), and navigate to the
snapmirror_dst1 folder.
46. Observe that the destination.txt file you previously created here is still present.

45 46
Figure 7-19:
47. Still in Windows Explorer, select the J: share (the original source volume), and then navigate to the
snapmirror_src1 folder.
48. Observe that the source.txt file you previously created here is now gone, and that the destination.txt file
you created on the original destination volume is now present here too.
47
48
Figure 7-20:
The contents of the original source volume now mirror the contents of the original destination volume.
If you attempted to write any new files to the original source volume, you would find that this volume is
now read-only.
To make this volume writable again, and once again the “true” source volume in the SnapMirror
relationship, repeat the failover procedure, this time swapping the source and destination clusters,

SVMs, and volumes during the break and reverse re-sync steps. In order to save time, this lab guide
does not walk you through those steps, but you are welcome to do it on your own if you are interested.

8 SnapMirror/SnapVault Cascade
You have already seen how to establish SnapMirror and SnapVault relationships between a single source and
destination volume pair. But there are other relationships that you can create. For example, you can create
multiple-mirror fanouts, where a single source volume can SnapMirror to multiple destination volumes, or have
a single source volume with both SnapMirror and SnapVault relationships to different destination volumes. In
this section, you explore setting up a cascade relationship, where a chain of volumes are SnapMirrored and/or
SnapVaulted together, replicating from one to the other.
There are a number of situations where such a cascaded replication chain is desireable, including:
• Added redundancy—more than just one copy of your production instance.
• Having a fully working copy of production without having to disrupt currently scheduled replication
activities.
• Shifting long term snapshot retention to lower cost storage.
8.1 Basics of a Cascade Configuration
Cascading SnapMirror and SnapVault relationships are supported starting with ONTAP 8.2. A SnapMirror
secondary can be the source of a SnapVault relationship (backing up a DR mirror); or a SnapVault secondary can
be the source of a SnapMirror relationship (protecting a backup).
A cascade deployment is supported on FlexVol volumes, and consists of a chain of mirror relationships in which a
volume is replicated to a secondary volume, and the secondary is replicated to a tertiary volume. This deployment
adds one or more additional backup destinations without degrading performance on the source volume.
Before you perform a resynchronization operation in a cascade, you should be aware that a resynchronization
operation deletes Snapshot copies, and might cause a relationship in the cascade to lose its common Snapshot
copy. If this happens, the relationship will require a new baseline.
8.2 Exercise
In this exercise you configure a SnapMirror->SnapVault cascade configuration across three of the lab’s clusters,
as follows.
Figure 8-1: Cascade Exercise Architecture
Up until this point you have seen how to manage SnapMirror through System Manager. Seeing SnapMirror work
from the CLI can offer additional perspective, and so this exercise uses the CLI to configure these SnapMirror and
SnapVault relationships.

An easy way to navigate the CLI in ONTAP is to use command completion. As you type the commands in this
exercise, you can use the tab key in some instances to prepopulate CLI command options and default values. For
this lab, the default values are fine in most but not all cases, so use caution.
In this exercise you open console sessions to 3 different clusters. To help you keep track of the cluster on which
you should run a given command, the command prompts in this exercise include the cluster name.
1. On the desktop of Jumphost, right-click the PuTTY icon on the task bar and select PuTTY from the
context menu.
1
Figure 8-2:
The “PuTTY Confuration” window opens.
2. Initiate a connection to cluster1 by double-clicking the cluster1 entry in the saved sessions list. Log in
with username admin, and password Netapp1!.
3. Repeat the preceding two steps as needed to also establish console sessions to cluster2, and cluster3.
You will need to right-click on the PuTTY icon on the taskbar to open these additional sessions, or
alternately left-click on the PuTTY icon in your PuTTY session to cluster1 and select New Session...
from the menu.

2
Figure 8-3:
Important: You should now have 3 open PuTTY sessions, one to each of cluster1, cluster2, and
cluster3. Pay attention to the command prompts in the CLI windows in this exercise so you can
make sure that you are running a given command on the correct cluster!
4. Verify that the SVM peering relationships exist between the SVMs.
cluster1::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
snap_src1 svm_dst1 peered cluster2 snapmirror svm_dst1
cluster1::>
----------- ----------- ------------ ----------------- -------------- ---------
svm_dst1 snap_src1 peered cluster1 snapmirror snap_src1
svm_dst1 svm_dst2 peered cluster3 snapmirror svm_dst2
2 entries were displayed.
cluster2::>
----------- ----------- ------------ ----------------- -------------- ---------
cluster3::>

Cluster2 is peered with both cluster1 and cluster3, but cluster1 and cluster3 are not peered with each
other.
5. Create the primary (or source) volume “cascade_src1” on cluster1.
cluster1::> volume create -vserver snap_src1 -volume cascade_src1
-aggregate aggr_dp -size 20GB -state online -policy default
-unix-permissions ---rwxr-xr-x -type RW -snapshot-policy default
-foreground true -space-guarantee volume
Warning: The export-policy "default" has no rules in it. The volume will
therefore be inaccessible.
Do you want to continue? {y|n}: y
[Job 612] Job is queued: Create cascade_src1.
[Job 612] Job succeeded: Successful
cluster1::> volume show -vserver snap_src1
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
snap_src1 SRC1_root aggr_dp online RW 20MB 18.20MB 8%
snap_src1 cascade_src1 aggr_dp online RW 20GB 19.00GB 5%
snap_src1 mirror_me aggr_dp online RW 10GB 9.49GB 5%
snap_src1 snapmirror_src1
aggr_dp online DP 50MB 44.75MB 10%
snap_src1 snapvault_src1
aggr_dp online RW 50MB 46.78MB 6%
snap_src1 unified_rep_src1
cluster1::>
6. Create the secondary (or first destination) volume “svm_dst1” on cluster2.
cluster2::> volume create -vserver svm_dst1 -volume cascade_dst1
-aggregate aggr_dp -size 20GB -state online -policy default -type DP
-autosize-mode grow_shrink -snapshot-policy none -foreground true
-space-guarantee volume
[Job 231] Job is queued: Create cascade_dst1.
cluster2::>volume show -vserver svm_dst1
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_dst1 DST1_root aggr_dp online RW 20MB 17.88MB 10%
svm_dst1 cascade_dst1 aggr_dp online DP 20GB 20.00GB 0%
svm_dst1 snap_src1_mirror_me_mirror
aggr_dp online DP 128.0MB 121.0MB 5%
svm_dst1 snapmirror_dst1
svm_dst1 snapvault_dst1
svm_dst1 unified_rep_dst1
cluster2::>
7. Create the SnapMirror relationship between the primary and secondary volumes. You must run these
commands on cluster2, because that cluster hosts the destination SVM.
cluster2::> snapmirror create -source-path snap_src1:cascade_src1
-destination-path svm_dst1:cascade_dst1 -type DP -throttle unlimited
-policy DPDefault -schedule 5min
Operation succeeded: snapmirror create for the relationship with destination
"svm_dst1:cascade_dst1".
cluster2::>
8. The preceding command defined the relationship, but did not replicate any data. Initialize the SnapMirror
relationship to start that initial data transfer.
cluster2::> snapmirror initialize -destination-path svm_dst1:cascade_dst1
Operation is queued: snapmirror initialize of destination "svm_dst1:cascade_dst1".

cluster2::>
9. Check the status of the initializing relationship. Repeat this command every few seconds until the Mirror
State of the cascade_src1->cascade_dst1 relationship changes from “Uninitialized” to “Snapmirrored”.
(This happens quickly, so you may not actually catch it in an “Uninitialized” state unless you are very
fast.) Note that you can use the up arrow key to recall the most recent command, and then hit Enter to
re-execute it.
cluster2::> snapmirror show
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
snap_src:cascade_src1
DP svm_dst1:cascade_dst1
Uninitialized
Transferring 0B true 08/28 23:52:17
snap_src1:mirror_me
XDP svm_dst1:snap_src1_mirror_me_mirror
Snapmirrored
Idle - true -
snap_src:snapvault_src1
XDP svm_dst1:snapvault_dst1
Snapmirrored
Idle - true -
----------- ---- ------------ ------- -------------- --------- ------- --------
snap_src1:cascade_src1
Snapmirrored
Idle - true -
snap_src1:mirror_me
Snapmirrored
Idle - true -
snap_src1:snapvault_src1
Snapmirrored
Idle - true -
cluster2::>
10. Create the tertiary (or final destination) volume “cascade_dst2” on cluster3.
cluster3::> volume create -vserver svm_dst2 -volume cascade_dst2 -aggregate aggr_dp
-size 20GB -state online -policy default -type DP -autosize-mode grow_shrink
-space-guarantee volume -snapshot-policy none -foreground true
[Job 270] Job is queued: Create cascade_dst2.
cluster3::> volume show -vserver svm_dst2
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_dst2 cascade_dst2 aggr_dp online DP 20GB 20.00GB 0%
svm_dst2 rootvol aggr_dp online RW 20MB 17.96MB 10%
cluster3::>
11. Create the SnapVault relationship between the secondary and tertiary volumes. The updates are still
based on the initial source volume (cascade_src1). Run these commands on cluster3.
Note: Notice that both SnapMirror and SnapVault CLI commands utilize the snapmirror CLI
command.
cluster3::> snapmirror create -source-path svm_dst1:cascade_dst1
-destination-path svm_dst2:cascade_dst2 -type XDP -throttle unlimited

-policy XDPDefault -schedule 5min
"svm_dst2:cascade_dst2".
cluster3::>
12. Initialize the SnapVault relationship to start the initial data transfer.
cluster3::> snapmirror initialize -destination-path svm_dst2:cascade_dst2
Operation is queued: snapmirror initialize of destination "svm_dst2:cascade_dst2".
cluster3::>
13. Check the status of the SnapVault relationship. Repeat this command periodically until the value of the
relationship Mirror State changes from “Uninitialzied” to “SnapMirrored”.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm_dst1:cascade_dst1
XDP svm_dst2:cascade_dst2
Uninitialized
Transferring 0B true 08/28 23:58:26
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Snapmirrored
Idle - true -
cluster3::>
14. Minimize the PuTTY sessions for cluster1, cluster2, and cluster3 as you will need them again in later
exercises.
This concludes the lab exercises.

9 Disaster Recovery for Storage Virtual Machines
9
Traditional volume SnapMirror requires you to set up a separate mirroring relationship for each volume you want
to mirror. In cases where you want to mirror many volumes for an SVM, you have to set up many SnapMirror
relationships, and even then you have to manually maintain all the configuration for the destination SVM,
including setting up LIFs, namespaces, protocols, and so on.
Disaster Recovery for Storage Virtual Machines, also referred to as SVM DR, is a solution that uses SnapMirror
to mirror a storage virtual machine's (SVM’s) entire set of volumes and it's configuration. It simplifies failover by
minimizing or completely avoiding manual configuration at the destination SVM through automated setup and
change management.
To set up an SVM DR relationship you create one SnapMirror relationship that replicates the entire SVM's
contents, and as you add, remove, or re-junction volumes, SVM DR will automatically apply those changes to the
destination SVM according to your replication schedule, potentially along with other SVM configuration settings.
When you create an SVM DR relationship you can choose to replicate all or a subset of the source SVM's
configuration to the Destination SVM. This choice is controlled through the -identity-preserve command line
option.
When -identity-preserve is set to true, SVM DR replicates the source SVM configuration settings listed the
following figure to the destination SVM. Since this mode replicates network identity information, the destination
SVM does require access to the same network resources (physical/virtual networks, Active Directory servers,
etc.) as the source SVM has. This is the identity preserve mode that most customers will likely want to deploy for
disaster recovery needs.

Figure 9-1:
When -identity-preserve is set to false, only a subset of the source SVM’s configuration data is replicated to the
destination SVM, as described in the following figure. This mode is intended for replication to different sites that
have different network resources, or to support the creation of additional read-only copies of the SVM within the
same environment as the source SVM.

Figure 9-2:
As with traditional volume Snapmirror, SVM DR relationships can be broken off, reversed, and re-synchronized,
allowing you to cut-over the SVM’s services from one cluster to another. If -identity-preserve is set to true,
then when you stop the source SVM and start the destination SVM, the destination SVM has the same LIFs,
IP addresses, namespace structure, and so on. However, such a switchover is disruptive for both CIFS (which
requires an SMB reconnect), and NFS (which requires a re-mount).
SVM DR does not replicate iSCSI or FCP configuration in either -identity-preserve mode. The underlying
volumes, LUNs, and namespace are still replicated, as are the LIFs if -identity-preserve is set to true, but LUN
igroup/portsets will not be replicated nor will the SVM’s iSCSI/FCP protocol configuration. If you want to support
iSCSI/FCP through an SVM DR relationship, then you will have to manually configure the iSCSI/FCP protocols,
igroups, and portsets on the destination SVM.
9.1 Exercise
In this exercise you will create an identity-preserve “true” SVM-DR relationship between the source SVM svm3
on cluster3 to a new SVM named “smv3-dr” that you will create on cluster4. You will then perform a cut-over
operation, making svm3-dr the new operational primary, and then revert the primary back to svm3 again.
Note: This lab utilizes CLI sessions to the storage clusters “cluster3”, and “cluster4”, and to the Linux
client “rhel1”. You will frequently switch between these sessions, so pay attention to the command prompts
in this exercise to help you issue the commands on the correct hosts.
1. Open a PuTTY sessions to each of cluster3 and cluster4, and log in with the username admin, and the
password Netapp1!.
2. Open a PuTTY session to rhel1, and log in as root, with the password Netapp1!.

3. In the PuTTY session for cluster4, display a list of the SVMs on the cluster.
cluster4::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
cluster4 admin - - - - -
cluster4-01 node - - - - -
cluster4::>
4. Create the destination SVM svm3-dr.
cluster4::> vserver create -vserver svm3-dr -subtype dp-destination
[Job 227] Job is queued: Create svm3-dr.
[Job 227]
[Job 227] Job succeeded:
Vserver creation completed
cluster4::>
5. List the SVMs on cluster4.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data dp-destination stopped - -
running
cluster4::>
Notice that the svm3-dr SVM is administratively running, but is operationally stopped.
6. On cluster4, initiate an SVM peering relationship between the svm3-dr and svm3.
cluster4::> vserver peer create -vserver svm3-dr -peer-vserver svm3
-applications snapmirror -peer-cluster cluster3
Info: [Job 228] 'vserver peer create' job queued
cluster4::>
7. View the SVM peering status.
----------- ----------- ------------ ----------------- -------------- ---------
svm3-dr svm3 initiated cluster3 snapmirror svm3
cluster4::>
8. On cluster3, view the SVM peering status.
----------- ----------- ------------ ----------------- -------------- ---------
svm3 svm3-dr pending cluster4 snapmirror svm3-dr
cluster3::>
9. Accept the pending peering request.
cluster3::> vserver peer accept -vserver svm3 -peer-vserver svm3-dr
Info: [Job 271] 'vserver peer accept' job queued
cluster3::>

10. View the SVM peering status again.
----------- ----------- ------------ ----------------- -------------- ---------
svm3 svm3-dr peered cluster4 snapmirror svm3-dr
cluster3::>
11. On cluster4, create the SnapMirror relationship between the source SVM svm3 and the destination
SVM svm3-dr.
cluster4::> snapmirror create -source-path svm3: -destination-path svm3-dr:
-type DP -throttle unlimited -identity-preserve true -schedule hourly
cluster4::>
If you are familiar with creating volume SnapMirror relationships from the CLI then this command
should look familiar, as it is essentially the same command used for volume SnapMirror, but with a few
key differences. Most significant is the format of the values for the -source-path and -destination-
path arguments. Path values for volume SnapMirror take the form <svm>:<volume>, whereas for SVM
DR paths take the form <svm>:. One other difference is the inclusion of the -identity-preserve
true option, which indicates that this is an identity preserve relationship, meaning that all of the SVM’s
configuration information should be replicated to the destination SVM. If you were to instead specify -
identity-preserve false, then this would instead be an identity discard relationship.
12. Display the state of the cluster’s SnapMirror relationships.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3: DP svm3-dr: Uninitialized
Idle - true -
cluster4::>
Data ONTAP has created the relationship, but not yet initialized it (i.e., it has not initiated the first data
transfer).
13. Initialize the SnapMirror relationship.
cluster4::> snapmirror initialize -destination-path svm3-dr:
cluster4::>
14. View the status of the SnapMirror relationships again.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Transferring - true -
cluster4::>
Data has started transferring for the relationship.
Notice that there is only a single entry displayed for the SVM DR relationship, even though behind the
scene there are multiple SnapMirror relationships in operation for this relationship.
15. Display the status of all the constituents for the SVM disaster recovery relationships.
cluster4::> snapmirror show -expand
Progress

----------- ---- ------------ ------- -------------- --------- ------- --------
cluster4::>
When you initializes an SVM DR relationship, clustered Data ONTAP starts replicating the configuration
data first, which includes details of the source SVM’s volumes, and then afterward starts replicating
the source SVM’s constituent volumes. If you issue a snapmirror show -expand command early in the
initialization process, then the constituent relationships may not yet exist.
16. Periodically (every 10-15 seconds) repeat the snapmirror show expand command until you start seeing
output for the constituent relationships. It may take several minutes.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3:chn DP svm3-dr:chn Uninitialized
Idle - true -
svm3:eng DP svm3-dr:eng Uninitialized
Idle - true -
svm3:fin DP svm3-dr:fin Uninitialized
Idle - true -
svm3:mfg DP svm3-dr:mfg Uninitialized
Idle - true -
svm3:prodA DP svm3-dr:prodA
Uninitialized
Idle - true -
svm3:proj1 DP svm3-dr:proj1
Uninitialized
Idle - true -
cluster4::>
17. Periodically issue the snapmirror show command until the relationship status changes to “Idle”.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3: DP svm3-dr: Snapmirrored
Idle - true -
cluster4::>
The relationship has completed initialization, meaning that the destination SVM is now a mirrored copy
of the source SVM.
18. Examine the status of the constituent relationships.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Idle - true -
svm3:chn DP svm3-dr:chn Snapmirrored
Idle - true -
svm3:eng DP svm3-dr:eng Snapmirrored
Idle - true -
svm3:fin DP svm3-dr:fin Snapmirrored
Idle - true -
svm3:mfg DP svm3-dr:mfg Snapmirrored
Idle - true -
Snapmirrored
Idle - true -
Snapmirrored

Idle - true -
svm3:us DP svm3-dr:us Snapmirrored
Idle - true -
cluster4::>
These are 8 entries in total, and all are now likewise “Idle”.
19. Display a list of the volumes on cluster4.
cluster4::> vol show
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
cluster4 MDV_CRS_b7976a3b4df411e6b3c9005056010d01_A
cluster4 MDV_CRS_b7976a3b4df411e6b3c9005056010d01_B
cluster4-01
vol0 aggr0 online RW 7.17GB 2.91GB 59%
svm3-dr chn aggr_dp online DP 1GB 971.0MB 5%
svm3-dr eng aggr_dp online DP 1GB 971.0MB 5%
svm3-dr fin aggr_dp online DP 1GB 970.9MB 5%
svm3-dr mfg aggr_dp online DP 1GB 971.0MB 5%
svm3-dr prodA aggr_dp online DP 1GB 971.0MB 5%
svm3-dr proj1 aggr_dp online DP 1GB 971.0MB 5%
svm3-dr svm3_root aggr_dp online RW 20MB 18.79MB 6%
svm3-dr us aggr_dp online DP 1GB 971.0MB 5%
cluster4::>
You see here that svm3-dr has 8 volumes, which correspond to the 8 volumes on svm3. Also notice
the two MDV* volumes at the beginning of the output; these are special volumes that clustered Data
ONTAP uses to replicate the SVM DR configuration data from the source SVM to the destination SVM.
20. Display a list of the volume snapshots for svm3-dr.
Note: Since this command output is lengthy, the following CLI examples will focus on just the
eng volume, but in your lab feel free to exclude the -volume eng portion of the command so you
can see the snaphots for all of svm3-dr's volumes.
cluster4::> snapshot show -vserver svm3-dr -volume eng
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
svm3-dr eng
daily.2016-08-27_0010 512KB 0% 21%
daily.2016-08-28_0010 80KB 0% 4%
weekly.2016-08-28_0015 132KB 0% 7%
hourly.2016-08-28_1805 92KB 0% 5%
hourly.2016-08-28_1905 88KB 0% 4%
hourly.2016-08-28_2005 88KB 0% 4%
hourly.2016-08-28_2105 88KB 0% 4%
hourly.2016-08-28_2205 88KB 0% 4%
hourly.2016-08-28_2305 88KB 0% 4%
vserverdr.0.415d105a-6d76-11e6-925a-005056010d01.2016-08-28_232647
0B 0% 0%
cluster4::>
Notice the “vserverdr” snapshot created by SnapMirror.
21. On cluster3, display the list of snapshots for svm3’s volumes.
cluster3::> snapshot show -vserver svm3 -volume eng
---Blocks---
-------- -------- ------------------------------------- -------- ------ -----
svm3 eng
daily.2016-08-27_0010 512KB 0% 21%
daily.2016-08-28_0010 80KB 0% 4%
weekly.2016-08-28_0015 132KB 0% 6%
hourly.2016-08-28_1805 92KB 0% 5%
hourly.2016-08-28_1905 88KB 0% 4%

hourly.2016-08-28_2005 88KB 0% 4%
hourly.2016-08-28_2105 88KB 0% 4%
hourly.2016-08-28_2205 88KB 0% 4%
hourly.2016-08-28_2305 88KB 0% 4%
76KB 0% 4%
cluster3::>
The list of snapshots is the same on both the source and destination volumes.
22. On cluster4, initiate a SnapMirror update to transfer any changes on the source SVM since the last
transfer took place to the destination SVM.
cluster4::> snapmirror update -destination-path svm3-dr:
cluster4::>
23. Periodically view the status of the SnapMirror relationships until it goes idle.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Idle - true -
cluster4::>
24. View the status of the constituent relationships.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Idle - true -
svm3:chn DP svm3-dr:chn Snapmirrored
Idle - true -
svm3:eng DP svm3-dr:eng Snapmirrored
Idle - true -
svm3:fin DP svm3-dr:fin Snapmirrored
Idle - true -
svm3:mfg DP svm3-dr:mfg Snapmirrored
Idle - true -
Snapmirrored
Idle - true -
Snapmirrored
Idle - true -
svm3:us DP svm3-dr:us Snapmirrored
Idle - true -
cluster4::>
25. Display again the list of svm3-dr’s volume snapshots.
cluster4::> snapshot show -vserver svm3-dr -volume eng
---Blocks---
-------- -------- ------------------------------------- -------- ------ -----
svm3-dr eng
daily.2016-08-27_0010 512KB 0% 21%
daily.2016-08-28_0010 80KB 0% 4%
weekly.2016-08-28_0015 132KB 0% 6%
hourly.2016-08-28_1805 92KB 0% 5%
hourly.2016-08-28_1905 88KB 0% 4%
hourly.2016-08-28_2005 88KB 0% 4%
hourly.2016-08-28_2105 88KB 0% 4%
hourly.2016-08-28_2205 88KB 0% 4%
hourly.2016-08-28_2305 88KB 0% 4%

80KB 0% 4%
0B 0% 0%
cluster4::>
Now there are two vserverdr* snapshots listed. After your first update, SnapMirror maintains 2 rolling
snapshots on the destination volume going forward.
26. On cluster3, look at the snapshots on the source volumes.
cluster3::> snapshot show -vserver svm3 -volume eng
---Blocks---
-------- -------- ------------------------------------- -------- ------ -----
svm3 eng
daily.2016-08-27_0010 512KB 0% 21%
daily.2016-08-28_0010 80KB 0% 4%
weekly.2016-08-28_0015 132KB 0% 6%
hourly.2016-08-28_1805 92KB 0% 4%
hourly.2016-08-28_1905 88KB 0% 4%
hourly.2016-08-28_2005 88KB 0% 4%
hourly.2016-08-28_2105 88KB 0% 4%
hourly.2016-08-28_2205 88KB 0% 4%
hourly.2016-08-28_2305 88KB 0% 4%
84KB 0% 4%
cluster3::>
Even after the first update, the source volumes continue to host a single rolling snapshot for
SnapMirror.
27. The Linux host rhe1l has svm3’s root namespace volume NFS mounted at the start of the lab. Display
the /etc/fstab /entry that for this mount. The /etc/fstab file lists the local disks and NFS filesystems that
should be automatically mounted at system boot time.
[root@rhel1 ~]# grep svm3 /etc/fstab
svm3:/ /corp nfs defaults 0 0
[root@rhel1 ~]#
28. Display the details of that existing mount.
[root@rhel1 ~]# df /corp
Filesystem 1K-blocks Used Available Use% Mounted on
svm3:/ 19456 768 18688 4% /corp
[root@rhel1 ~]#
Svm3’s namespace root is mounted as /corp on rhel1.
29. List the contents of the /corp directory.
[root@rhel1 ~]# ls /corp
eng fin mfg
[root@rhel1 ~]#
You have no problem displaying the contents.
Next you initiate a cut-over. As mentioned in the introduction to this exercise. A cut-over is disruptive to
NFS clients in this initial release of SVM disaster recovery, and so you should unmount the NFS volume
from the rhel1 client before the cut-over.
30. Unmount the /corp mount.
[root@rhel1 ~]# umount /corp
[root@rhel1 ~]#
31. On cluster4, quiesce any running snapmirror operations.
cluster4::> snapmirror quiesce -destination-path svm3-dr:
cluster4::>

32. Verify that the snapmirror relationship is quiesced.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Quiesced - true -
cluster4::>
33. Break off the SnapMirror relationship.
cluster4::> snapmirror break -destination-path svm3-dr:
cluster4::>
34. Display the status of the SnapMirror relationships.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3: DP svm3-dr: Broken-off
Idle - true -
cluster4::>
The relationship for svm3-dr is broken-off.
35. Examine the status of the svm3-dr SVM.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data default running stopped svm3_root aggr_dp
cluster4::>
It is administratively running, but operationally stopped, as it should be since you have not cut over yet.
36. Examine the status of svm3-dr’s LIFs.
cluster4::> net int show -vserver svm3-dr
(network interface show)
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3-dr
svm3_cifs_nfs_lif1
up/down 192.168.0.143/24 cluster4-01 e0g true
svm3_cifs_nfs_lif2
up/down 192.168.0.144/24 cluster4-01 e0e true
cluster4::>
The LIFS are configured but down.
37. On cluster3, display the status of the SVMs.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3 data default running running svm3_root aggr_dp
svm_dst2 data default running running rootvol aggr_dp

cluster3::>
Svm3 is both administratively and operationally running.
38. Check the status of svm3’s LIFs.
cluster3::> net int show -vserver svm3
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3
svm3_cifs_nfs_lif1
up/up 192.168.0.143/24 cluster3-01 e0d true
svm3_cifs_nfs_lif2
up/up 192.168.0.144/24 cluster3-01 e0e true
cluster3::>
The LIFs are both up. If you compare the IP addresses on these LIFs with the ones you saw a couple
of steps back for svm3-dr you will see that they are the same. This is because you specified the -
identity-preserve true option when you established the SVM disaster recovery relationship at the
beginning of this exercise.
39. Stop svm3.
cluster3::> vserver stop -vserver svm3
[Job 274] Job is queued: Vserver Stop svm3.
[Job 274] Job succeeded: DONE
cluster3::>
40. View svm3’s status.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3 data default stopped stopped svm3_root aggr_dp
cluster3::>
The SVM is both administratively and operationally stopped.
41. Examine svm3’s LIFs.
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3
svm3_cifs_nfs_lif1
up/down 192.168.0.143/24 cluster3-01 e0d true
svm3_cifs_nfs_lif2
cluster3::>
The LIFs are also down.
42. On cluster4, view the status of svm3-dr.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data default running stopped svm3_root aggr_dp

cluster4::>
It is still administratively running, but is operationally down.
43. Start svm3-dr.
cluster4::> vserver start -vserver svm3-dr
[Job 239] Job is queued: Vserver Start svm3-dr.
[Job 239] Job is queued: Vserver Start svm3-dr.
cluster4::>
44. View svm3-dr’s status again.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data default running running svm3_root aggr_dp
cluster4::>
It is now administratively and operationally running.
45. Examine the status of svm3-dr’s LIFs.
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3-dr
svm3_cifs_nfs_lif1
up/up 192.168.0.143/24 cluster4-01 e0g true
svm3_cifs_nfs_lif2
cluster4::>
Both LIFs are up and operational.
46. Examine svm3-dr’s volumes.
cluster4::> vol show -vserver svm3-dr
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm3-dr chn aggr_dp online RW 1GB 970.9MB 5%
svm3-dr eng aggr_dp online RW 1GB 970.9MB 5%
svm3-dr fin aggr_dp online RW 1GB 970.9MB 5%
svm3-dr mfg aggr_dp online RW 1GB 970.9MB 5%
svm3-dr prodA aggr_dp online RW 1GB 970.9MB 5%
svm3-dr proj1 aggr_dp online RW 1GB 970.9MB 5%
svm3-dr svm3_root aggr_dp online RW 20MB 18.79MB 6%
svm3-dr us aggr_dp online RW 1GB 970.9MB 5%
cluster4::>
The volumes are all present and writable.
47. On rhel1, mount up all /etc/fstab entries that are not currently mounted. Alternately, you can use the
mount svm3:/ /corp command to manually mount /corp.
[root@rhel1 ~]# mount -a
[root@rhel1 ~]#
48. View the details of the mount.
[root@rhel1 ~]# df /corp

Filesystem 1K-blocks Used Available Use% Mounted on
svm3:/ 19456 192 19264 1% /corp
[root@rhel1 ~]#
49. List the contents of the /corp directory.
eng fin mfg
[root@rhel1 ~]#
50. Change directory to /corp/mfg/chn.
[root@rhel1 ~]# cd /corp/mfg/chn
[root@rhel1 ~]#
51. List the directory contents.
[root@rhel1 ~]# ls
[root@rhel1 ~]#
The directory is empty.
52. Create a new volume named prodB and junction it into the namespace at /mfg/chn/prodB.
cluster4::> volume create -vserver svm3-dr -volume prodB -aggregate aggr_dp
-space-guarantee volume -policy default -junction-path /mfg/chn/prodB
[Job 240] Job is queued: Create prodB.
cluster4::>
53. On rhel1, list the directory’s contents again.
[root@rhel1 ~]# ls
prodB
[root@rhel1 ~]#
54. cd to the prodB folder.
[root@rhel1 ~]# cd prodB
[root@rhel1 ~]#
55. Create a new file named “file.txt”.
[root@rhel1 ~]# touch file1.txt
[root@rhel1 ~]#
56. List the directory contents.
[root@rhel1 ~]# ls
file1.txt
[root@rhel1 ~]#
57. On cluster3, display the status of the SnapMirror relationships.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Snapmirrored
Idle - true -
cluster3::>
There is currently no relationship from svm3-dr to svm3.
58. Create a SnapMirror SVM disaster recovery relationship from the source SVM svm3-dr to the
destination SVM svm3.
cluster3::> snapmirror create -source-path svm3-dr: -destination-path svm3:
-type DP -throttle unlimited -identity-preserve true -schedule hourly

cluster3::>
59. Display the status of the SnapMirror relationships again.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3-dr: DP svm3: Broken-off
Idle - true -
Snapmirrored
Idle - true -
cluster3::>
SnapMirror creates the relationship. Since there is an existing relationship for the two SVMs from when
it was going the other direction before it was broken off, the Mirror State shows as Broken-off here.
60. Re-sync the relationship.
cluster3::> snapmirror resync -destination-path svm3:
cluster3::>
61. Display the status of the SnapMirror relationships again.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3-dr: DP svm3: Broken-off
Snapmirrored
Idle - true -
cluster3::>
62. Periodically display the status of the constituent relationships until they all show Idle.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3-dr: DP svm3: Snapmirrored Idle - true -
svm3-dr:chn DP svm3:chn Snapmirrored Idle - true -
svm3-dr:eng DP svm3:eng Snapmirrored Idle - true -
svm3-dr:fin DP svm3:fin Snapmirrored Idle - true -
svm3-dr:mfg DP svm3:mfg Snapmirrored Idle - true -
svm3-dr:prodA DP svm3:prodA Snapmirrored Idle - true -
svm3-dr:prodB DP svm3:prodB Snapmirrored Idle - true -
svm3-dr:proj1 DP svm3:proj1 Snapmirrored Idle - true -
svm3-dr:us DP svm3:us Snapmirrored Idle - true -
svm_dst1:cascade_dst1 XDP svm_dst2:cascade_dst2 Snapmirrored Idle - true -
cluster3::>
If you pay attention to the status of the relationship for the prodB volume while running these
commands (and if you are fast enough), you will see it go from “Uninitialized” to “Transferring” to “Idle”,
while the other relationships go from “Broken-off” to “Re-synching” to “Idle”.
63. View the status of the parent relationship.
Progress

----------- ---- ------------ ------- -------------- --------- ------- --------
svm3-dr: DP svm3: Snapmirrored Idle - true -
cluster3::>
Now start the procedure to cut-over from svm3-dr to svm3.
64. Quiesce the SnapMirror relationship.
cluster3::> snapmirror quiesce -destination-path svm3:
cluster3::>
65. Verify the relationship is quiesced.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
svm3-dr: DP svm3: Snapmirrored Quiesced - true -
cluster3::>
66. Break the SnapMirror relationship.
cluster3::> snapmirror break -destination-path svm3:
cluster3::>
67. On cluster4, display the status of the svm3-dr SVM.
cluster4:> vserver show
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data default running running svm3_root aggr_dp
cluster4::>
68. Stop the svm3-dr SVM.
cluster4::> vserver stop -vserver svm3-dr
[Job 241] Job is queued: Vserver Stop svm3-dr.
cluster4::>
69. Display the SVM’s status again.
cluster4:> vserver show
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3-dr data default stopped stopped svm3_root aggr_dp
cluster4::>
70. Display the status of svm3-dr’s LIFs.
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3-dr
svm3_cifs_nfs_lif1
up/down 192.168.0.143/24 cluster4-01 e0g true

svm3_cifs_nfs_lif2
cluster4::>
The LIFs are down, as you would expect.
71. On cluster3, start the svm3 SVM.
cluster3::> vserver start -vserver svm3
[Job 276] Job is queued: Vserver Start svm3.
cluster3::>
72. Display the svm3 SVM’s status.
----------- ------- ---------- ---------- ----------- ---------- ----------
svm3 data default running running svm3_root aggr_dp
cluster3::>
Svm3 is up and running.
73. Display the status of svm3’s LIFs.
----------- ---------- ---------- ------------------ ------------- ------- ----
svm3
svm3_cifs_nfs_lif1
up/up 192.168.0.143/24 cluster3-01 e0d true
svm3_cifs_nfs_lif2
cluster3::>
Svm3’s LIFs are both running and operational.
74. Examine svm3’s volumes.
cluster3::> vol show -vserver svm3
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm3 chn aggr_dp online RW 1GB 970.8MB 5%
svm3 eng aggr_dp online RW 1GB 970.8MB 5%
svm3 fin aggr_dp online RW 1GB 970.8MB 5%
svm3 mfg aggr_dp online RW 1GB 970.8MB 5%
svm3 prodA aggr_dp online RW 1GB 970.8MB 5%
svm3 prodB aggr_dp online RW 20MB 18.79MB 6%
svm3 proj1 aggr_dp online RW 1GB 970.8MB 5%
svm3 svm3_root aggr_dp online RW 20MB 18.20MB 8%
svm3 us aggr_dp online RW 1GB 970.8MB 5%
cluster3::>
All volumes are online.
75. On rhel, list the status of the /corp mount.
[root@rhel1 prodB]# df /corp
df: `/corp': Stale file handle
[root@rhel1 prodB]#

The file handle is stale because you did not unmount the NFS filesystem prior to the latest SVM DR cut-
over.
76. Change out of the /corp directory tree so you can unmount the NFS volume.
[root@rhel1 prodB] cd
[root@rhel1 ~]
77. Unmount /corp.
[root@rhel1 ~]# umount /corp
[root@rhel1 ~]#
78. Mount /corp again.
[root@rhel1 ~]# mount -a
[root@rhel1 ~]#
79. List the contents of /corp again.
eng fin mfg
[root@rhel1 ~]#
80. List the contents of the /corp/mfg/chn/prodB directory to see if the file you created on svm3-dr before
the last re-sync and cut-over is present.
[root@rhel1 ~]# ls /corp/mfg/chn/prodB
file1.txt
[root@rhel1 ~]#
Yes, the file you created earlier is there. It is noteworthy that there was no extra work involved in
replicating back configuration changes that were made on svm3-dr (from creating and mounting a new
volume) when it was running.
81. On cluster4, re-sync the SnapMirror relationship.
cluster4::> snapmirror resync -destination-path svm3-dr:
cluster4::>
82. Periodically check the status of the SnapMirror relationship until it goes Idle.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
Idle - true -
cluster4::>
At this point the SVM disaster recovery relationship is back to the state it was in before you initiated any
cutover operations.
83. You can close your PuTTY sessions to cluster3, cluster4, and rhel1 as they will not be needed for the
remainder of this lab.
This concludes this lab exercise.

10 SnapMirror Unified Replication
SnapMirror Unified Replication refers to the use of SnapMirror with the same (unified) logical replication engine as
in NetApp SnapVault® technology. This unified relationship type is designated Extended Data Protection (XDP)
and provides single baseline functionality at the volume level, drastically reducing storage and network bandwidth,
which translates immediately into cost savings. SnapMirror provides support for applications to fail over to a
secondary volume and continue operating as well as the capability to fail back to the primary location at a later
date. This capability is sometimes referred to as disaster recovery (DR) or mirroring. SnapVault provides support
for long-term retention of data for compliance, backup, archival, and other reasons. This support is sometimes
referred to as vaulting or backup. SnapMirror Unified Replication brings together the powerful capabilities of both
at the volume level.
There are four major benefits to using SnapMirror Unified Replication:
• Only one baseline copy of a volume is needed on the secondary storage (without Unified Replication,
SnapMirror and SnapVault each need their own baseline copy).
• Less network traffic is required between the primary and secondary (a single baseline plus fewer
snapshots over time).
• There is simplified upgrading of replication relationships to newer ONTAP releases. (Without Unified
Replication you can replicate only from higher to lower releases. Doing so can cause serious
operational issues with complex replication topologies. With Unified Replication you can replicate from
lower to higher AND from higher to lower as long as both sides are ONTAP 8.3 or higher.)
• If a primary volume that is the source of a SnapMirror relationship becomes corrupted for any reason,
the secondary inevitably becomes corrupted as well. With Unified Replication, it is now possible to
recover the primary volume from any arbitrary SnapVault or SnapMirror snapshot.
10.1 Exercise
This exercise will demonstrate the powerful capabilities of SnapMirror and SnapVault existing within the same
volume, the same baseline. It will demonstrate how you can set labels and retention times on the individual
snapshots in a volume to behave like a vault snapshot or a DR snapshot.
1. Open PuTTY sessions to both cluster1 and cluster2 (if you don't already have open PuTTY sessions to
them), logging in to each as the user admin with the password Netapp1!.
1
Figure 10-1:
2. On the source cluster (cluster1), create a policy that will be used to contain two snapmirror labels which
will dictate whether a snapshot will be retained like a vault or like a DR snapshot.
cluster1::> snapmirror policy create -vserver snap_src1 -policy oracle -tries 8
-transfer-priority normal -ignore-atime false -restart always -type mirror-vault
cluster1::>

3. Do the same on the destination cluster (cluster2).
cluster2::> snapmirror policy create -vserver svm_dst1 -policy oracle -tries 8
-transfer-priority normal -ignore-atime false -restart always -type mirror-vault
cluster2::>
4. On cluster1, add two rules to the policy that different retention times based on the snapshot's label, 60
days for “oraclevault” and 14 days for “oracleDR”.
cluster1::> snapmirror policy add-rule -vserver snap_src1 -policy oracle
-snapmirror-label oraclevault -keep 60
cluster1::> snapmirror policy add-rule -vserver snap_src1 -policy oracle
-snapmirror-label oracleDR -keep 14
cluster1::> snapmirror policy show -policy oracle
Vserver Policy Policy Number Transfer
Name Name Type Of Rules Tries Priority Comment
------- ------------------ ------ -------- ----- -------- ----------
snap_src1
oracle mirror-vault 3 8 normal -
SnapMirror Label: sm_created Keep: 1
oraclevault 60
oracleDR 14
Total Keep: 75
cluster1::>
Do the same for the destination cluster, cluster2.
5. Now we are adding the rule oracleDR to the policy named oracle.
cluster2::> snapmirror policy add-rule -vserver svm_dst1 -policy oracle
-snapmirror-label oraclevault -keep 60
cluster2::> snapmirror policy add-rule -vserver svm_dst1 -policy oracle
-snapmirror-label oracleDR -keep 14
cluster2::>
6. In the PuTTY session for cluster2, create a new SnapMirror relationship between the snap_src SVM's
snapmirror_src1 volume on cluster1 to the svm_dst1 SVM's snapmirror_dst1 volume on cluster2. You
are specifying the combination of XDP and MirrorAndVault for this relationship.
cluster2::> snapmirror create -vserver svm_dst1
-source-path snap_src1:unified_rep_src1
-destination-path svm_dst1:unified_rep_dst1 -type XDP -policy oracle
"svm_dst1:unified_rep_dst1".
cluster2::> snapmirror policy show -policy oracle
Vserver Policy Policy Number Transfer
Name Name Type Of Rules Tries Priority Comment
------- ------------------ ------ -------- ----- -------- ----------
svm_dst1
oracle mirror-vault 3 8 normal -
SnapMirror Label: sm_created Keep: 1
oraclevault 60
oracleDR 14
Total Keep: 75
cluster2::>
7. Now that you have created the relationship, you next need to initialize it in order to perform the initial
data transfer from the source to the destination.
cluster2::> snapmirror initialize -destination-path svm_dst1:unified_rep_dst1
-source-path snap_src1:unified_rep_src1
Operation is queued: snapmirror initialize of destination "svm_dst1:unified_rep_dst1".
cluster2::>

8. Query the status of the operation until the svm_dst1:unified_rep_dst1 destination volume displays a
“Relationship Status” of “Idle”.
Progress
----------- ---- ------------ ------- -------------- --------- ------- --------
snap_src1:cascade_src1
Snapmirrored
Idle - true -
snap_src1:mirror_me
Snapmirrored
Idle - true -
snap_src1:snapvault_src1
Snapmirrored
Idle - true -
snap_src1:unified_rep_src1
XDP svm_dst1:unified_rep_dst1
Snapmirrored
Idle - true -
cluster2::>
9. On cluster1 create some snaphots to transfer during the next SnapMirror update.
Note: The -snapmirror-label option specifies a label that is used by the Vaulting subsystem
when you back up Snapshot copies to the Vault Destination. The -expiry-time option indicates
the time at which the Snapshot copy becomes eligible for deletion.
cluster1::> snapshot create -vserver snap_src1 -volume unified_rep_src1
-snapshot oraclevault -snapmirror-label oraclevault
cluster1::> snapshot create -vserver snap_src1 -volume unified_rep_src1
-snapshot oracleDR -snapmirror-label oracleDR
cluster1::> snapshot show -vserver snap_src1 -volume unified_rep_src1
---Blocks---
-------- -------- ------------------------------------- -------- ------ -----
snap_src1
unified_rep_src1
snapshot_12082016_142038_98 128KB 0% 26%
weekly.2016-08-14_0015 520KB 1% 59%
weekly.2016-08-21_0015 176KB 0% 32%
snapmirror.f37fb61f-5433-11e6-9502-005056010cf1_2152686027.2016-08-25_191500
76KB 0% 17%
daily.2016-08-26_0010 500KB 1% 58%
daily.2016-09-21_0010 624KB 1% 63%
hourly.2016-09-21_1305 72KB 0% 16%
hourly.2016-09-21_1405 72KB 0% 16%
hourly.2016-09-21_1505 72KB 0% 16%
hourly.2016-09-21_1605 680KB 1% 65%
hourly.2016-09-21_1705 72KB 0% 16%
hourly.2016-09-21_1805 68KB 0% 16%
snapmirror.f37fb61f-5433-11e6-9502-005056010cf1_2152686024.2016-09-21_182733
68KB 0% 16%
oraclevault 68KB 0% 16%
oracleDR 64KB 0% 15%
cluster1::>
10. On cluster2, update the destination volume with the new snapshots you just created on the source
volume.
cluster2::> snapmirror update -destination-path svm_dst1:unified_rep_dst1
Operation is queued: snapmirror update of destination "svm_dst1:unified_rep_dst1".

Netapp snapmirror unified_replication_v1.2-lab_guide

Netapp snapmirror unified_replication_v1.2-lab_guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Netapp snapmirror unified_replication_v1.2-lab_guide

Similar to Netapp snapmirror unified_replication_v1.2-lab_guide (20)

Recently uploaded

Recently uploaded (20)

Netapp snapmirror unified_replication_v1.2-lab_guide