White Paper
EMC VNX Snapshots
Abstract
This white paper describes EMC® VNX™
Snapshots. The paper reviews and explains
operations and best practices for the feature, as
well as limits and functions.
March 2015
EMC VNX Snapshots White Paper
1
Copyright © 2015 EMC Corporation. All Rights
Reserved.
EMC believes the information in this publication is
accurate as of its publication date. The information
is subject to change without notice.
The information in this publication is provided “as
is.” EMC Corporation makes no representations or
warranties of any kind with respect to the
information in this publication, and specifically
disclaims implied warranties of merchantability or
fitness for a particular purpose.
Use, copying, and distribution of any EMC software
described in this publication requires an
applicable software license.
For the most up-to-date listing of EMC product
names, see EMC Corporation Trademarks on
EMC.com.
Part Number H10858.3
EMC VNX Snapshots White Paper
2
Table of Contents
Executive summary .............................................................................. 5
Audience ............................................................................................. 5
Terminology ........................................................................................ 6
VNX Snapshots Technical Overview ...................................................... 7
How Snapshots work ................................................................................... 7
Snapshot granularity ............................................................................... 9
Snapshot Mount Point ............................................................................... 10
VNX operations.................................................................................. 11
Create a Snap ............................................................................................ 11
Create a Snap with AppSync ...................................................................... 13
Create a Snapshot Mount Point ................................................................. 13
Attach a Snapshot ..................................................................................... 15
Branching (snap of a snap)........................................................................ 15
Copy a Snapshot ................................................................................... 16
Snap of a Snapshot Mount Point ........................................................... 17
Detach a Snapshot Mount Point ............................................................ 19
Detach a Snapshot Mount Point with Snapshots ................................... 20
Destroy a Snapshot ................................................................................... 22
Consistency Groups................................................................................... 23
Attach a Consistent Snapshot ............................................................... 25
Branch a Consistent Snapshot .............................................................. 28
Rules for Consistency Groups ................................................................ 29
Restore...................................................................................................... 29
Restore with SnapView Snapshots and VNX Snapshots ......................... 30
Restore a LUN ........................................................................................ 31
Restore CGs........................................................................................... 33
Repurpose Snapshots ............................................................................... 33
Migrations ................................................................................................. 33
Migration considerations ...................................................................... 37
Limits ........................................................................................................ 37
Interoperability with other VNX features .................................................... 37
VNX Snapshot Auto-Delete ................................................................. 38
Auto-Delete Thresholds ............................................................................. 40
Pool Space Used Threshold ....................................................................... 40
Snapshot Space Used Threshold ........................................................... 41
EMC VNX Snapshots White Paper
3
Delete Eligibility ........................................................................................ 41
Auto-Delete paused................................................................................... 42
Snapshot Expiration .................................................................................. 42
CLI .................................................................................................... 43
Create a Snapshot ..................................................................................... 44
Copy a Snapshot ....................................................................................... 44
Create a Snapshot Mount Point ................................................................. 45
Attach a Snapshot ..................................................................................... 46
Create a Cascading Snapshot .................................................................... 46
Detach a Snapshot .................................................................................... 47
Destroy a Snapshot ................................................................................... 47
List all VNX Snapshots for a LUN ................................................................ 47
Create a Consistency Group ....................................................................... 48
List Consistency Groups ............................................................................ 48
Create a Consistent Snapshot ................................................................... 49
Attach a Consistent Snapshot ................................................................... 49
SnapCLI............................................................................................. 49
Flush buffers ............................................................................................. 50
Create a Snapshot ..................................................................................... 50
Attach a Snapshot ..................................................................................... 50
Copy a Snap .............................................................................................. 50
Consistency Groups................................................................................... 50
Sample SnapCLI batch script ..................................................................... 51
VNX Snapshots vs. SnapView terms ................................................... 52
Properties Detailed ............................................................................ 53
Snapshot properties.................................................................................. 53
Snapshot Mount Point properties .............................................................. 54
Additional pool properties ......................................................................... 56
EMC VNX Snapshots White Paper
4
Executive summary
VNX™ Snapshots is a VNX software feature that creates point-in-time
data copies. VNX Snapshots is used for data backups, software
development and testing, repurposing, data validation, and local rapid
restores. Unlike SnapView™ snapshots and clones, VNX Snapshots do
not consume large amounts of pool capacity. As a result, this feature is
preferred for modern data management.
This white paper describes all VNX Snapshots operations in detail.
Wherever possible, all aspects of the feature sets are presented visually.
The paper provides straightforward instructions for common functional
tasks. Most tasks are shown from the point of view of Unisphere™
graphical user interface (GUI) and naviseccli command line interface
(CLI). You can also manage your VNX snapshots using EMC AppSync,
software that provides application consistent snapshots for Microsoft
Exchange and SQL Server, and provides crash-consistency for VMware
VMFS datastores. The AppSync GUI allows you to manage, configure,
catalogue, and schedule your VNX snapshots.
VNX Snapshots and SnapView will coexist on the same LUN.
Furthermore, SnapView clones, which use a different technology from
SnapView snapshots, will work with VNX Snapshots.
Audience
This paper is intended for EMC customers and EMC field personnel who
are familiar with VNX technology. The paper is intended to be used as a
main reference for VNX Snapshots technology.
EMC VNX Snapshots White Paper
5
Terminology

Consistency Group—an object that contains a list of primary
LUNs or Snapshot Mount Points (but not both) that are treated as
a single entity for taking snapshots.

Consistent Snapshot—a point-in-time copy of a Consistency
Group.

Copy on First Write (COFW)—the technology behind SnapView
Snapshots. After a snapshot is taken, new writes to the primary
LUNs are delayed to enable copying old blocks to the special
reserve LUN within the Reserve LUN Pool.

Logical Unit Number (LUN)—is the identifying number of a SCSI or
an iSCSI object that processes SCSI commands. The LUN is the
last part of the SCSI address for a SCSI object. The LUN is an ID
for the logical unit, but the term is often used to refer to the
logical unit itself.

Mount Point, Snapshot Mount Point (SMP)—a virtual LUN-like
container. It is used to "emulate" a typical LUN, but provide the
ability for hosts to write to snapshots and to change snapshots
without changing LUN properties such as WWN, and often
without the need to rescan SCSI bus on the client.

Redirect on Write (ROW)—the technology behind VNX Snapshots.
After a snapshot is taken, new writes to the primary LUN are
redirected (written) to a new location within a storage pool.

Storage processor (SP)—a hardware component that provides the
processing resources to perform storage operations such as
creating, managing, and monitoring storage resources.

Unisphere—a web-based management environment to create
storage resources, configure and schedule protection for stored
data, and manage and monitor other storage operations on VNX
and VNXe systems.
EMC VNX Snapshots White Paper
6
VNX Snapshots Technical Overview
VNX Snapshots is a feature introduced in VNX© for Block OE Release 32.
It was created to improve on the existing SnapView Snapshot
functionality by better integrating with pools. In fact, VNX Snapshots can
only be used with pool LUNs.
LUNs that are created on physical RAID groups, also called Classic LUNs,
support only SnapView Snapshots. This restriction exists because VNX
Snapshots require pool space as part of the technology.
Note: SnapView Snapshots are compatible with pool LUNs. VNX
Snapshots and SnapView Snapshots can coexist on the same pool LUN.
VNX Snapshots support 256 writeable snaps per pool LUN. It supports
Branching, also called Snap of a Snap. A Snap of a Snap hierarchy
cannot exceed 10 levels. There are no restrictions to the number of
branches, as long as the total number of snapshots for a given primary
LUN is within 256, which is the hard limit.
Consistency Groups are also supported with this feature. Several pool
LUNs can be combined into a Consistency Group and snapped
concurrently.
How Snapshots work
VNX Snapshots use redirect on write (ROW) technology. ROW redirects
new writes destined for the primary LUN to a new location in the storage
pool. Such an implementation is different from copy on first write
(COFW) used in SnapView, where the writes to the primary LUN are held
until the original data is copied to the reserved LUN pool to preserve a
snapshot.
Figure 1 compares the two technologies.
EMC VNX Snapshots White Paper
7
Figure 1: SnapView write vs. VNX Snapshot write
Figure 1 illustrates the main difference between SnapView Snapshots
and VNX Snapshots. VNX Snapshot technology writes the new data to a
new area within a pool, without the need to read/write to the old data
block. This improves the overall performance compared to SnapView.
Similarly, during a read from a snapshot, the snapshot's data is not
constructed from two different places as shown in Figure 4.
Figure 2: SnapView read vs. VNX Snapshot read
EMC VNX Snapshots White Paper
8
Snapshot granularity
Every VNX Snapshot has 8 KB block granularity. This means that every
write occupies at least 8 KB on the pool. The distribution of the 8 KB
blocks within a 256 MB slice (1GB in VNX OE for Block R32) is congruent
with the normal thin write algorithm.
Consider the following example. A LUN is snapped with a few blocks of
data. The new snapshot points at those blocks, just like the primary
LUN.
Figure 3: VNX Snapshot pointing at the same blocks with the LUN at
creation time
After a few moments, the primary LUN may receive an I/O that overwrites
block A. The first snapshot continues pointing to the original set of
blocks A, B, C, and D. After Snap2 is taken, it points to A`, B, C and D.
The next primary LUN I/O overwrites block D, and it now points to A`, B,
C, and D`.
Figure 4: VNX Snapshots point at unchanged blocks, Primary LUN is
using new blocks
EMC VNX Snapshots White Paper
9
Snapshots and Thick LUNs
When a VNX Snapshot is created on a Thick LUN, portions of its address
space are changed to indirect mode. In other words, when writes come
in to the Snapped Thick LUN, the LUN starts converting address mapping
from direct to 8 KB blocks for each portion of the Thick LUN being
written.
Note: Thick LUN remains to be classified as Thick in the CLI and GUI.
The Thick LUN remains in an indirect mode while it has VNX Snapshots.
When the last snapshot of the Thick LUN is removed, the mode
automatically reverts to direct. The process of reverting to direct mode is
not instantaneous, and is performed in the background. The process can
be aborted by creating a new VNX Snapshot on the LUN.
VNX Snapshots are a part of the storage pool. A snapshot does not
consume space from the pool, until the new data is written to the
primary LUN or to the snapshot itself.
Snapshot Mount Point
Snapshot Mount Point (SMP) is a LUN-like container. It is used to
emulate a typical LUN, but provides the ability for the host to write to
snapshots and to change snapshots without the need to rescan the SCSI
bus on the client.
Figure 5: What is a Snapshot Mount Point?
EMC VNX Snapshots White Paper
10
A SMP is created for snapshots of a specific LUN. This means that each
SMP can be used only for snapshots of a single primary LUN.
To enable access to hosts, SMPs must be provisioned to storage groups
just like any typical LUN.
VNX operations
VNX Snapshots support the following operations.
Create a Snap
Creating a snapshot does not consume any pool space. The space starts
being used when new writes to the primary LUN or to the snapshot itself
arrive. Snapshots have a granularity of 8 KB, and their blocks are
tracked just like the blocks in thin LUNs. Every snapshot must have a
primary LUN, and that property never changes.
A primary LUN cannot be deleted while it has snapshots. In Unisphere,
you can delete a LUN that has snapshots by selecting an optional
setting that deletes the snapshots first.
Figure 6: A pair of VNX Snapshots
Before creating a snapshot, use the SnapCLI utility to flush the host
buffers.
:: Windows
SnapCLI flush -o G:
To create a snapshot:
1. In Unisphere, select Storage > LUNs.
EMC VNX Snapshots White Paper
11
Figure 7: Create VNX Snapshots in Unisphere
2. Click Create Snapshot or right-click the primary LUN.
# To create snapshot in the CLI
naviseccli snap -create -res 1 -name "cli_snap" -descr "snap created via CLI"
#
^^^
# LUN ID
When a snapshot is first created, it is write-protected:
Figure 8: Unisphere view of the VNX Snapshot write protection
When you try to attach a snapshot that has the Allow Read/Write option
disabled, Unisphere automatically enables it and displays a warning.
EMC VNX Snapshots White Paper
12
Figure 9: Unisphere VNX Snapshot Attach warning
If a Snapshot is attached from the CLI, then the -allowReadWrite property
must be set to “Yes”. Therefore, you must manually modify it prior to an
attach command.
# To modify a snap in the CLI
naviseccli snap -modify -id "cli_snap" -allowReadWrite yes
Create a Snap with AppSync
You can also create VNX Snapshots using EMC AppSync. The AppSync user
interface allows you to create a service plan that allows you to manage your
snapshots. For more information, refer to EMC AppSync Installation and
Administration Guide located at
https://support.emc.com/products/25364_AppSync
Create a Snapshot Mount Point
To create a SMP in Unisphere, use the Configure Snapshot Mount Point
wizard located in Data Protection > Common Data Protection Tasks. The
wizard is also available in the Wizards area on the right pane.
Figure 10: Unisphere Snapshot Mount Point creation wizard location
Alternatively, you can also create a SMP by right clicking on a LUN listed
in the LUN tab under Storage > LUNs.
EMC VNX Snapshots White Paper
13
Figure 11: Unisphere right mouse click Snapshot Mount Point creation
Creating a SMP does not require any space from the pool.
Note: Each SMP is dedicated to a specific primary LUN. It is not possible
to attach snapshots from two different primary LUNs to a single SMP.
Therefore, a backup server that is backing up four different LUNs must
have four different SMPs provisioned to back up the snapshots of those
LUNs.
In Unisphere, you can provision the SMP to a host through either the
wizard or the SMP create screen.
In the CLI, you can provision the SMP to a host by using the Storage
Group command:
# To create a Snapshot Mount Point in CLI
naviseccli lun -create -type Snap -primaryLunName PrimaryLUN -sp B -l 60 \
-name SMP_name -allowInbandSnapAttach yes
# ^^ SMP LUN ID!!!
# When LUN ID is not provided at creation, VNX assigns one automatically.
# in that case, it needs to be looked up in order
# to provision the SMP to a storage group
# To provision the SMP to a Storage Group
naviseccli storagegroup -addhlu -gname "Storage Group 1" -hlu 60 -alu 60
CLI guidelines

Create the SMP on the same storage processor as the primary
LUN
EMC VNX Snapshots White Paper
14

Set the -allowInbandSnapAttach parameter to "yes" to allow
SnapCLI host binary to attach the Snapshots (It is a security
feature)
o This parameter can easily be modified at a later time.

A SMP is added to a storage group just like a usual LUN.
Attach a Snapshot
Attaching is an asynchronous operation during which the SMP remains
available, but the I/O is queued. This means that that the host does not
have to rescan the SCSI bus to view the snapshot. The rescan is required
only to discover the SMP when it is first presented to the host.
Figure 12: Attaching a Snapshot to a Snapshot Mount Point
Note: A SCSI rescan is not required for switching attached snapshots,
that is, detaching one snapshot and attaching another to the same SMP.
However, you must stop all I/O to the SMP and most importantly, flush
the host buffers (using the SnapCLI utility).
Branching (snap of a snap)
There are two main ways to create a Snap of a Snap. One way is to
create a simple copy of a Snapshot and another is to take a Snapshot of
the attached Mount Point, for example, Cascading Snapshots.
EMC VNX Snapshots White Paper
15
Copy a Snapshot
A VNX Snapshot can be copied to another snapshot. The resulting
snapshot is a copy of the source except for the name. The allowReadWrite1 property is set to No on the copy.
The snapshot copy retains the source LUN properties and resides within
the same pool as the original snapshot. So, copying a snapshot
increases the snapshot count for a given production LUN by one.
Figure 13: VNX Snapshot copy
Note: Only unattached snapshots can be copied. Attached snapshots
are branched by snapping the SMP, a process that is also called
Cascading Snapshots.
1
This property is a security feature, preventing unauthorized mounting a snapshot for read/write operations.
EMC VNX Snapshots White Paper
16
Snap of a Snapshot Mount Point
A snapshot of a SMP still has the same Primary LUN property as the
Mount Point (and as the attached snapshot). The primary LUN properties
of snapshots and the mount points that they are attached to will never
be different.
It is technically possible to attach a snapshot to a SMP that is not a part
of a storage group. Therefore, it is possible to create a snapshot of such
a SMP. The resulting snapshot will be slightly different from a regular
snapshot copy. The source of this snapshot and the creation times will
not be the same as the snapshot attached to the SMP.
Figure 14: VNX Snap of a Snap, aka Cascading Snapshots
EMC VNX Snapshots White Paper
17
The Source LUN property of the Cascading Snapshot has the name of the
SMP. It is possible to create multiple snapshots at this level, and
individually mount them.
Figure 15: VNX Snapshots, multiple levels
Note: In Figure 14 and Figure 15, both SMPs may only be used for
Primary LUN1 Snaps. No other snapshots may be attached to them.
However, either SMP could be provisioned to any host.
EMC VNX Snapshots White Paper
18
Detach a Snapshot Mount Point
Detaching a snapshot from a SMP modifies these properties: Last
Modified Date and Last Modified By. Detaching a snapshot from a SMP
does not destroy the SMP by default, and the SMP remains provisioned
to the host. Detaching is an asynchronous operation during which the
SMP remains available, but the host I/O is queued at the array. After the
detach operation completes, all queued I/O requests return a fail status
to the host.
Figure 16: Detaching a VNX Snapshot
EMC VNX Snapshots White Paper
19
Detach a Snapshot Mount Point with Snapshots
Detaching a snapshot from a SMP is more complex when the SMP has
its own snapshots.
Figure 17: Detaching SMP with its own Snapshots
Figure 17 shows that as a result of Snap2 detaching from SMP1, the
second level snapshots (Snap2.1 and Snap2.2) need to change:

The Source LUN property to match a higher-level object, which is
Primary LUN1.

The Creation time to match Snap2 (original Snap attached to
SMP1)

The Last modify time to match the old Last modified time or
Creation time (if Last modified is empty) or remains the same, if
the snapshot had not been modified (as Snap2.2 has in Figure
17).
EMC VNX Snapshots White Paper
20
Similarly, a multilevel structure will change as shown in Figure 18.
Figure 18: Multi-level detaching SMP with its own Snapshots
Note: A detached SMP persists by default and is kept provisioned to the
host. There is no degradation in the array performance during the
detaching operation.
When users are about to detach a SMP, Unisphere displays a message
asking users to stop I/O and flush the host buffers.
Figure 19: Unisphere Snapshot detach confirmation
EMC recommends flushing the buffers by using the SnapCLI utility on
the host. For example:
:: Windows. flush the buffers for drive G:
SnapCLI.exe flush -o G:
EMC VNX Snapshots White Paper
21
Destroy a Snapshot
Destroying (deleting) a snapshot reclaims space for reuse in the storage
pool. Reclaim is not instant, and is done by an internal process. This
internal process is throttled for better performance of the array and is
not sequential. This means that more than one snapshot can be
destroyed at one time. Multiple snapshot destructions start on a firstcome-first-served basis. VNX is tuned to destroy up to 16 snapshots
simultaneously on each Storage Processor (SP). Additional destruction
requests are queued until a destruction thread becomes available.
When a snapshot is in the "Destroying" state, it is still counted towards
the maximum number of snapshots. The snapshot name is changed to
Destroying_<timestamp> before it is destroyed. This way, a user can recreate a snapshot called, for example, "Monday_Backup_Snapshot"
immediately after executing a command to destroy the old snapshot
with the same name. This is especially useful for SnapCLI-based scripts.
Destroying a VNX Snapshot may generate a large amount of background
I/O as old blocks of data (which are unique to that snap) are removed
and the free space is reclaimed for the Pool. The amount of workload
generated on the SP and Pools is proportional to the number of
simultaneous deletions. The amount of time these deletions take to
complete depends on the amount of unique data on the snap. EMC
recommends snapshot deletions during periods of light load. Other
factors that may impact the performance of VNX Snapshots are:




Pools which contain a large proportion of NL-SAS drives (in terms of
capacity). The old data will tend to be moved to the lowest tier
drives and when the Snaps are deleted, the I/O associated with snap
deletion can end up on the NL-SAS drives, which are relatively slow
for that type of I/O. Pools which make extensive use of VNX
Snapshots should ideally be using only Flash and SAS drives.
Monitor the drives in the Pool and the SP Utilization to ensure that
the Pool is not being overloaded.
Large numbers of VNX Snaps being deleted at the same time. Too much
concurrent load can be caused by deleting snaps using a script, having a
common expiration time set on many snaps, or by reliance on Auto-delete
functionality. When not using Consistency Groups, stagger the deletions over
the course of the day or weekend, by script delay or staggered snap expiration
times. Do not rely on Auto-Delete as the primary deletion strategy since it is
not a proactive way to manage pool space or to manage the timing and impact
of the snap deletion load.
Overlapping snapshot deletions with FAST-VP relocation windows. It
is better to start the deletions after the FAST-VP relocation window
has ended.
VNX Snaps being created and deleted frequently. The greater the frequency of
snaps, the higher the background I/O will be to delete them. Reducing the
EMC VNX Snapshots White Paper
22

frequency of VNX Snaps and their subsequent deletions will reduce the
background I/O load on the Pool.
VNX Snapshots with thick LUNs. A mode conversion (similar to converting
from thin to thick) will be triggered when the last snap is deleted. It is
preferable to make sure that there is always at least one snap remaining on
the Thick LUN if you plan on using snaps again. Alternatively, use Thin LUNs
instead.
Consistency Groups
A Consistency Group (CG) is an object that contains a list of primary
LUNs or SMPs (but not both) that are treated as a single entity for taking
snapshots.
A Consistent Snapshot is one snapshot of a collection of LUNs. When a
snapshot of a CG is initiated, all writes to member LUNs are held until
their snapshots have been created. A CG is primarily designed for LUNs
that belong to the same application.
Consistency Groups are not designed with the purpose of conducting an
action on multiple unrelated snaps for administrative purposes
(specifically detach/destroy). Using this process on unrelated LUNs in a
single consistency group can result in triggering a high level of
background I/O load on the pool.
For a CG, it is recommended that the number of IOPS provided by the
slowest drives in the pool should be equal to the number of IOPS
required by the host application. This ensures the host application is
not impacted if a part of the CG becomes inactive and the data is moved
down to the lowest tier.
Note: Application-aware consistency is achieved with AppSync product
that integrates with VNX Snapshots and VNX Snapshot CGs.
CGs take write-order–consistent snapshots of a group of LUNs or SMPs.
CGs have a name and description. CGs can contain any non-private
pool-based LUNs, or SMPs. Figure 20 demonstrates the concept of
Consistency Groups.
EMC VNX Snapshots White Paper
23
Figure 20: VNX Snapshot Consistency Group
Figure 21: Unisphere view of a Consistency Group
EMC VNX Snapshots White Paper
24
Attach a Consistent Snapshot
Mounting an entire Consistent Snapshot requires the same number of
SMPs as there are members in the CG.
Figure 22: Attaching a Consistent Snapshot
Note: A Consistent Snapshot may have a different number of snapshots
than a CG, if the CG’s members were modified after the snapshot was
taken.
It is technically possible to attach a single snapshot from the Consistent
Snapshot. The system checks the SMP's primary LUN to know which
portion of the Consistent Snapshot to attach.
EMC VNX Snapshots White Paper
25
Figure 23: Attaching individual SMPs to a Consistent Snapshot
However, when SMPs are also members of a CG, they can be attached to
only one consistent snapshot. Figure 24 displays a bad example that
does not work.
The main difference between Figure 24 and Figure 23 is that SMPs in
Figure 23 are not in a CG, and SMPs in Figure 24 are.
EMC VNX Snapshots White Paper
26
Figure 24: SMPs that are members in a CG cannot be attached to
different Consistent Snapshots
EMC VNX Snapshots White Paper
27
Branch a Consistent Snapshot
Consistent Snapshots can be branched just like regular snapshots.
Figure 25: Attaching a Copy of a Consistent Snapshot
EMC VNX Snapshots White Paper
28
Cascading Consistent Snapshots
To create a cascading Consistent Snapshot, a new CG must be created
out of SMPs attached to a snapshot.
Figure 26: Attaching a Cascading Consistent Snapshot
Rules for Consistency Groups
The rules for CGs are:





CGs cannot contain a combination of primary LUNs and SMPs
CGs cannot contain multiple SMPs from the same primary LUN
Any LUN/SMP can belong to only one CG
SMPs that are members in a CG cannot be attached to different
Consistent Snapshots
Consistent Snapshots for Classic LUNs or a mix of RAID LUNs and
Thick/Thin LUNs are only possible with SnapView snapshots
(sessions)
Restore
Snapshots can be used to restore a primary LUN or a SMP. In other
words, the data in the LUN will be changed to match the data in the
snapshot. The classic use case for this operation is when recovering
from data corruption.
Restoring automatically creates a 'Restore point snapshot' to recover
from unintentional data corruption. Although restoring is not instant, it
EMC VNX Snapshots White Paper
29
is an online operation. While the LUN is being restored, its state shows
as Initializing, and is changed back to Ready after the restore is
complete. Although restoring is not instant, it is an online operation, in
the sense that the earlier point-in-time data is immediately available,
even while the restore operation occurs in the background. The user
only needs to perform an initial flush of the host buffers before starting
the process (just as you do when creating a snapshot), and then the rest
of the process is completely host transparent. While the LUN is being
restored, its state shows as 'Initializing,' and is changed back to 'Ready'
after the restore is complete.
Note: Restoring is also referred to as Protected Restore, because
restoring does not change the Restore Point snapshot. All its data is
protected so that the user can return to the point-in-time of the source
data if needed.
When restoring a SMP, the data from the source snapshot (the one
being restored) is placed onto the snapshot attached to a Mount Point.
Note: Restoring can change the LUN size if the source snapshot was
taken before the primary LUN expansion or shrinking.
EMC AppSync restores consistency groups and LUNs using a copy that is
catalogued during the execution of the snapshot.
Restore with SnapView Snapshots and VNX Snapshots
Since pool LUNs can have a combination of SnapView snapshots and
VNX Snapshots, it is possible to restore from either a SnapView
snapshot or a VNX Snapshot. Restore is supported for both cases.

To restore a primary LUN from a VNX Snapshot, all SnapView
snapshots (sessions) must be manually deleted (stopped).

If the primary LUN is restored from a SnapView snapshot
(session), VNX Snapshots are unaffected.
Figure 27: Unisphere error on Snapshot restore due to the presence of a
SnapView session
EMC VNX Snapshots White Paper
30
Restore a LUN
Certain prerequisite steps must be performed from the host operating
system for a successful LUN restoration. Operating Systems often have
cached metadata pertaining to the LUN's file system. Restore operations
tend to confuse memory maps unless the cache is cleared.
This affects most operating systems. The following is a sample
procedure to restore a LUN from a VNX Snapshot. Microsoft Windows
operating system is used as an example.
Step 1
Stop application access to the LUN. Optionally, you may need to flush
application buffers.
Step 2
Flush the buffers for the drive by using SnapCLI.
Note: EMC recommends using SnapCLI for all other operating systems (if
an appropriate binary exists). Use native operating system methods
when SnapCLI binary is not available.
:: Windows
SnapCLI flush -o G:
:: Optionally, one could flush a physical drive, when it is not a "drive letter"
:: Note, this command makes sense only when the drive is mounted,
:: e.g. has a drive letter assigned
SnapCLI flush -o \\.\PhysicalDrive1
Step 3
Unmount the drive. For some versions of Windows, unmounting refers to
removing the drive letter. Windows 2012 has an option to turn the drive
offline. This can be done either from Disk Manager or from the CLI
(diskpart).
Note: Unmounting the drive guarantees that the host stops all I/O to the
LUN.
EMC VNX Snapshots White Paper
31
Figure 28: Windows Server 2012 Disk Manager -- switching a disk to
offline mode
C:\>diskpart
Microsoft DiskPart version 6.2.9200
Copyright (C) 1999-2012 Microsoft Corporation.
On computer: WIN2K12
DISKPART> list disk
Disk ###
-------Disk 0
Disk 1
Status
------------Online
Online
Size
------100 GB
10 GB
Free
------38 MB
1024 KB
Dyn
---
Gpt
---
DISKPART> select disk 1
Disk 1 is now the selected disk.
DISKPART> offline disk
DiskPart successfully offlined the selected disk.
DISKPART>
Step 4
Initiate the restore operation for the LUN from Unisphere or by using
naviseccli.
EMC VNX Snapshots White Paper
32
Note: SnapCLI does not allow restores for security reasons.
Step 5
Mount the drive (On Windows 7/8, assign a letter). The mount can
happen immediately after starting the restore operation. There is no
need to wait for the operation to finish.
Restore CGs
When restoring a Consistent Snapshot to a CG, it is possible that the
LUN member list of the current CG may be out of sync with the list of
LUNs in a Consistent Snapshot. This happens when a CG is extended
with additional LUN members.
In this case, the array does not let users restore CG from a snapshot with
different CG members than the current member list. The CG must be
modified to match the member list of the snapshot, followed by another
restore attempt.
Repurpose Snapshots
Some snapshots may need to be repurposed for other use. For example,
when a primary LUN must be deleted, but one of its VNX Snapshots
need to be retained.
There are two ways to do that:

Migrate the SMP to another LUN before deleting the primary LUN.

Detach a snapshot and then restore the primary LUN (from that
snapshot).
o The primary LUN may have a different HLU than SMP, or
may even be presented to another host. Make sure to
check where the data is provisioned.
o In addition, the primary LUN has a different WWN from the
SMP. So, if any of your tools or scripts are using the WWN
of the SMP/primary LUN, they must be updated.
Migrations
One of the VNX Snapshot use cases is to promote a snapshot to be a
standard LUN. To do that, the snapshot must be attached, and then the
SMP can be migrated to another LUN.
If a migrating SMP has any snapshots associated with it (for example
Cascading Snapshots), all of them will be destroyed.
EMC VNX Snapshots White Paper
33
Figure 29: Attached Snapshot before migration
Consider the example in Figure 29:

Host 1 is a production server running an application with
'PrimaryLUN1' provisioned.

Host 2 is a development server. This server must try a new
version of the application on a copy of the production data.

The Administrator performs the following actions:
o Takes a snapshot Snap2 from the production
PrimaryLUN1
o Creates a SMP SMP Name for snapshot from PrimaryLUN1
o Provisions SMP Name to Host 2 (for example adds SMP
Name to the storage group for Host 2)
o Attaches Snap2 snapshot to SMP Name
o Runs SCSI rescan on Host 2
o Creates a local drive on Host 2

At some point, SMP Name is snapped, and a Snap2.1 is created.
After some time of running development code on SMP Name, it is decided
to promote it to an independent LUN.
The Administrator performs the following actions:
EMC VNX Snapshots White Paper
34

Creates a new LUN, LUN Temp that is the same size as
PrimaryLUN1. The new LUN does not have to be a pool LUN, or be
in the same pool. It can be any LUN that is supported by the VNX
array.

Starts a LUN migration session from SMP Name to LUN Temp
o Unisphere displays a warning message that the existing
SMP Name snapshots will be destroyed.
Figure 30: Unisphere LUN migration warning
o Administrator acknowledges the warning.
EMC VNX Snapshots White Paper
35

The LUN migration runs for some time. The speed of migration
depends on several factors such as the LUN priority, size of
PrimaryLUN1, and array load.

Migration completes, and
o SMP Name Snapshot Mount Point is deleted
o LUN Temp is renamed to SMP Name and retains all the SCSI
attributes of the Mount Point, including WWN and even HLU
ID within the storage group.
o Snap2.1 is destroyed.

An internal process examines the blocks used for
Snap2.1 and returns them to the pool.
Figure 31: Migrating an attached Snapshot Mount Point to a new LUN
Note: If any of the SMP Name snapshots were attached, the LUN
migration would not have started. If SMP Name had many unattached
snapshots, they would be deleted as a result of LUN migration.
EMC VNX Snapshots White Paper
36
Migration considerations

When a primary LUN with SnapView snapshots is migrated to a
Classic or pool LUN, all SnapView snapshots migrate to the
destination LUN.

When a primary LUN or attached SMP with VNX Snapshots is
migrated to a RAID or pool LUN, all VNX Snapshots are deleted
(migration does not start if one of several of the underlying VNX
Snapshots are attached or in use).
Limits

The maximum number of snapshots per primary LUN is 256. The
system displays an error if a user tries to create more snapshots.
The same error is displayed in the CLI.

When a pool LUN has a VNX Snapshot and a SnapView Snapshot at
the same time, SnapView COFW takes priority over ROW. That
means that the old data is copied to the Reserve LUN Pool (RLP)
first, before the changed data is written. The data written is still
placed in the proper pool space, not within the pool LUN (as it
would have been if the LUN had not been a RAID group LUN).

A snapshot taken before primary LUN (thin LUN only) expansion
does not reflect the new size. Therefore, a restore from that
snapshot will restore the primary LUN back into the old size.

An attached SMP can be expanded, but only if it is attached to a
snapshot and is associated with a Thin primary LUN. SMPs
associated with Thick LUNs cannot be expanded.
Interoperability with other VNX features
VNX Snapshots are fully supported when used with other VNX features.
When using VNX Snapshots with block deduplication, please note the
following:

VNX Snapshots cannot be taken on a LUN while the LUN is in the
enabling or disabling state of deduplication. This is due to the
fact that the LUN is either migrating into or out of the
deduplication container. If the creation of a VNX Snapshot is
initiated while a LUN is in either state, an error message will
appear.

VNX Snapshots of a LUN that exist prior to enabling or disabling
deduplication will be destroyed when the operation completes.

All VNX Snapshot Mount Points associated with VNX Snapshots
of a LUN must be deleted before deduplication can be enabled or
EMC VNX Snapshots White Paper
37
disabled on the LUN. If deduplication is enabled or disabled on
a LUN with SMPs, an error message will appear.
For more information on Deduplication, see the white paper titled
EMC VNX Deduplication and Compression, located on EMC Online
Support.
VNX Snapshot Auto-Delete
As stated earlier, VNX Snapshots use pool space and decrease the
amount of user usable space in the pool. The mechanism to control
unlimited snapshot growth was created, and named, Auto-Delete
Management.
The main goal of VNX Snapshot Auto-Management is not to let the
snapshots take usable space away from pool LUNs. Auto-Delete is
controlled by the Auto-Delete policy that can be set on each pool, pool
LUN, CG, and VNX Snapshot. Every Auto-Delete policy has two sets of
thresholds:
a. Pool Space Thresholds (low and high)
b. Snapshot Space Thresholds (low and high)
The Auto-Delete Pool policy is enabled by default. However, in can be
easily disabled.
Note: Only Storage Pool Auto-Delete policy is enabled by default. The
policies for Pool LUNs, Consistency Groups, and VNX Snapshots are
disabled by default.
EMC VNX Snapshots White Paper
38
Figure 32: Unisphere Pool properties, showing Auto-Delete policy
The Auto-Delete policy can be enabled or disabled for the following
objects:

Pool

LUN

Snapshot (Regular or Consistent Snapshot)

Consistency Group

SMP
Whenever a high threshold is crossed, the VNX starts an Auto-Delete
process that scans the affected pools for Snapshots that are eligible for
destruction based on the Auto-Delete policy of the pools, primary LUNs,
SMPs, CGs, and snapshots.
Note: Attached snapshots are excluded from Auto-Delete regardless of
other settings.
Disabling Auto-Delete at the pool level disables all Auto-Delete
operations within the pool, regardless of the individual
LUN/CG/snapshot settings (except for scanning for expired LUNs).
Disabling Auto-Delete on a LUN, SMP, or CG, disables Auto-Delete on all
snapshots created from it regardless of the individual snapshot
settings.
EMC VNX Snapshots White Paper
39
Snapshots are Auto-Deleted one at a time, because the system does not
have an ability to predict how many snapshots need to be deleted to
reach the low threshold.
Auto-Delete Thresholds
Figure 33 shows Auto-Delete thresholds.
Figure 33: Storage Pool Auto-Delete Thresholds
Pool Space Used Threshold
Pool Space Used Threshold is a user configurable parameter that
determines whether the system should monitor the space used in the
Pool and Auto-Delete snapshots if required. When enabled, the
thresholds below are used for space monitoring. When disabled, the
threshold values are retained by the system but the pool space used is
not actively monitored.
Pool Space Used Threshold is enabled by default at the time of Pool
creation.
There are two Pool Space Used Thresholds:

Pool Space Used High Threshold: By default, it is set to 95% of the
pool capacity. When the pool crosses the threshold, the Auto-Delete
process is triggered. This process examines pool snapshots for
destruction eligibility in order of age, oldest first. When eligible
snapshots are found, the process starts deleting them one at a
time.

Pool Space Used Low Threshold: By default, it is set to 85% of the
pool capacity. This threshold must be smaller than Pool Space Used
High Threshold. When this threshold is crossed, it is an indication
EMC VNX Snapshots White Paper
40
for the Auto-Delete process to stop looking for new snapshots
eligible for deletion.
Snapshot Space Used Threshold
Snapshot Space Used Threshold is a user-configurable parameter that
determines whether the system should monitor the Snapshot space
used in the pool and Auto-Delete Snapshots if required. When enabled,
the thresholds listed below are used for space monitoring. When
disabled, the threshold values are retained by the system but the
snapshot space used is not actively monitored.
Snapshot Space Used Threshold is disabled by default at the time of
pool creation.
There are two Snapshot Space Used Thresholds:

Snapshot Space Used High Threshold: By default, it is set to 25% of
the pool capacity. When the pool crosses the threshold, the AutoDelete process is triggered. This process examines the pool
snapshots for destruction eligibility in order of age, oldest first, and
starts deleting them one at a time.

Snapshot Space Used Low Threshold: By default, it is set to 20% of
the pool capacity. This threshold must be smaller than Snapshot
Space Used High Threshold. When this threshold is crossed, it is an
indication for the Auto-Delete process to stop looking for new
snapshots eligible for deletion.
Delete Eligibility
A busy snapshot is excluded from Auto-Delete or expiration destruction.
A snapshot is busy when:

It is attached to a SMP

It is involved in a restore
The Auto-Delete settings can be set in multiple places. Use the following
table for system rules.
Pool
LUN
On
On
On
On
VNX
Snapshot
On
Off
On
Off
On or Off
Off
On or Off
On or Off
Auto-Delete behavior
Snapshots are subject to destruction
This snapshot is exempt from
destruction
Snapshots are exempt from
destruction
All pool Snapshots are exempt from
destruction
EMC VNX Snapshots White Paper
41
Similar rules apply to Consistent Snapshots.
Note: If a Consistent Snapshot has member LUNs in multiple pools,
Auto-Delete in any of those pools can delete that snapshot unless the
snapshot or its Source CG is exempt.
Auto-Delete paused
When Auto-Delete is unable to find enough eligible snapshots to delete
to be able to reach the Low Threshold, a warning is posted.
To resolve the warning, perform one or several of the following actions:

Increase pool's capacity by adding more disks to it

Manually delete snapshots

Change configuration to allow more snapshots to be
automatically deleted

Change thresholds
In some extreme cases, when deleting snapshots or failing to find
eligible Snaps to be deleted, the Auto-Delete process does not get
below the High Threshold. In that case, the Auto-Delete process stops
and posts an "Automatic Snapshot deletion paused" array error.
Figure 34: Unisphere Auto-Delete error
To correct the error, perform one or several of the same actions as with a
warning and make sure to manually restart the automatic deletion
feature in the Pool Properties dialog box. Optionally, an error condition
is lifted when Auto-Delete is completely disabled on a pool.
Snapshot Expiration
Every VNX Snapshot may have an optional expiration date. Expired
snapshots are destroyed at regular intervals. The VNX array scans for
expired snapshots once an hour (The Auto-Delete process does not
process destruction of expired snapshots. The destruction is handled by
another software layer.) When the expiration time is reached, the
snapshot may not be destroyed immediately. It is deleted by the
process started at the next running interval.
Setting an expiration date on a snapshot automatically disables AutoDelete. In CLI, the user must acknowledge a warning or overwrite it with o flag. In Unisphere, the user can set an expiration date only after AutoDelete is disabled (unchecked).
EMC VNX Snapshots White Paper
42
Similarly, enabling Auto-Delete for a snapshot automatically clears the
expiration timestamp for that snapshot and Unisphere displays a
warning.
CLI
Unisphere Secure Command Line Utility, naviseccli, includes the 'snap'
command, and also options in the 'lun' command for VNX Snapshots.
[nasadmin@~]$ naviseccli -h SPA snap
Usage:
snap -create -res resource [-resType type][-name snapName][-descr description]
[{-keepFor number{h|d|m|y}|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}]
[-ignoreMigrationCheck][-ignoreDeduplicationCheck]
snap -destroy -id snapName [-o]
snap -list [{-id snapName|[-resType type][-res resource]}][{-brief|-detail}]
snap -modify -id snapName [-name newName][-descr description]
[{-keepFor number{h|d|m|y}|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}]
snap -copy -id snapName [-name newName][-ignoreMigrationCheck]
[-ignoreDeduplicationCheck]
snap -restore -id snapName [-bakName bakName][-res lunNumber][-o]
snap -attach -id snapName -res lunNumber
snap -detach -id snapName [-res lunNumber][-o]
snap -group -create -name cgName [-res lunNumber(s)][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -destroy -id cgName [-destroySnapshots]
snap -group -list [-id cgName][{-brief|-detail}]
snap -group -modify -id cgName [-name newName][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -addmember -id cgName -res lunNumber(s)
snap -group -rmmember -id cgName -res lunNumber(s)
snap -group -replmember -id cgName -res lunNumber(s)
snap -feature -info
A quick list of array maximums and total VNX Snapshot numbers is
displayed with this command:
[nasadmin@~]$ naviseccli -h SPA snap -feature -info
Is VNX Snapshots Supported: True
Max. Snapshots: 32000
Max. Snapshots Per Primary LU: 256
Max. CGs: 256
Max. Members Per CG: 64
Max. Snapshot Mount Points: 4000
Total Number of Snapshots: 42
Total Number of CGs: 3
Total Number of Snapshot Mount Points:
16
Note: This command was run on a VNX8000. The maximum number of
Snapshots and maximum number of Snapshot Mount Points per VNX
vary by model. Please see the white paper titled Introduction to the EMC
VNX2 series located on EMC Online Support for more information.
Instead of listing CLI commands, view the collection of commands that
are helpful for everyday CLI use.
EMC VNX Snapshots White Paper
43
Create a Snapshot
To create a snapshot, naviseccli requires the LUN ID, and not the LUN
name. Be sure to flush host buffers before creating a snapshot. See 0
Flush buffers for an example.
# Look up the LUN ID, if needed.
[nasadmin@~]$ naviseccli -h SPA lun -list -name Primary_LUN1 -default
LOGICAL UNIT NUMBER 10
Name: Primary_LUN1
Default Owner: SP B
<== LOOK HERE
# Create a Snapshot, and allow it to be mounted read/write (default is no)
[nasadmin@~]$ naviseccli -h SPA snap -create -res 10 -resType LUN -name \
Primary_LUN1_Snapshot -descr "The CLI made snapshot" -allowReadWrite yes
# list a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot
Name: Primary_LUN1_Snapshot
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Source LUN(s): 10
Source CG: N/A
State: Ready
Allow Read/Write: Yes
Modified: No
Allow auto delete: Yes
Expiration date: Never
Copy a Snapshot
As explained earlier, a copy of a snapshot does not inherit two
properties:

Name

Allow Read/Write flag, which is set to 'No' by default
Creation time is inherited from the original snapshot.
[nasadmin@~]$ naviseccli -h SPA snap -copy -id Primary_LUN1_Snapshot \
-name Primary_LUN1_Snapshot_COPY
[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot_COPY
Name: Primary_LUN1_Snapshot_COPY
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Source LUN(s): 0
Source CG: N/A
State: Ready
Allow Read/Write: No
<===== LOOK HERE. Allow Read/Write property is not copied!
Modified: No
Allow auto delete: Yes
Expiration date: Never
EMC VNX Snapshots White Paper
44
Create a Snapshot Mount Point
A SMP is a 'LUN-like' object, and is created similar to a simple pool LUN.
The -allowInbandSnapAttach property is a security feature, that lets
SnapCLI from the host to attach/detach snapshots to this mount point.
[nasadmin@~]$ naviseccli -h SPA lun -create -type Snap -primaryLunName Primary_LUN1 \
-name PrimaryLUN1_SMP1 -allowInbandSnapAttach yes -sp B
# list the SMP
[nasadmin@~]$ naviseccli -h SPA lun -list -name PrimaryLUN1_SMP1
LOGICAL UNIT NUMBER 8155
<=== Note the LUN number
Name: PrimaryLUN1_SMP1
UID: 60:06:01:60:13:40:2A:00:70:5C:2C:51:1E:78:E1:11
Current Owner: SP B
Default Owner: SP B
Allocation Owner: SP B
User Capacity (Blocks): 20971520
User Capacity (GBs): 10.000
Consumed Capacity (Blocks): 8404992
Consumed Capacity (GBs): 4.008
Pool Name: Pool 0
Raid Type: r_5
Offset: 0
Auto-Assign Enabled: DISABLED
Auto-Trespass Enabled: DISABLED
Current State: Ready
Status: OK(0x0)
Is Faulted: false
Is Transitioning: false
Current Operation: None
Current Operation State: N/A
Current Operation Status: N/A
Current Operation Percent Completed: 0
Is Pool LUN: Yes
Is Thin LUN: Yes
Is Private: No
Is Compressed: No
Tiering Policy: Auto Tier
Initial Tier: Highest Available
Tier Distribution:
Performance: 100.00%
After the SMP is created, it can be added to a Storage Group, similar to a
typical LUN:
[nasadmin@~]$ naviseccli -h SPA storagegroup -addhlu -gname "Storage Group 1" \
-hlu 50 -alu 8155
EMC VNX Snapshots White Paper
45
Attach a Snapshot
There are two ways to attach a snapshot:
1. Attach a snapshot to a SMP by sending a command to the SMP
2. Attach a snapshot to a SMP by sending the command to the
snapshot
# attach via the lun command
[nasadmin@~]$ naviseccli -h SPA lun -attach -l 8155 -snapName Primary_LUN1_Snapshot
# attach via the snap command
[nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155
# Note: in both cases 8155 is the LUN ID of the Snapshot Mount Point
If a snapshot does not allow read/write access, you will receive the
following error:
[nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155
The properties of this snapshot do not allow it to be attached. Modify the snapshot
properties to allow it to be attached and retry the attach operation. (0x716d802e)
# To modify the Read/Write flag use this command:
[nasadmin@~]$ naviseccli -h SPA snap -modify -id Primary_LUN1_Snapshot \
-allowReadWrite yes
# And repeat attach
[nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155
Create a Cascading Snapshot
Cascading snapshot is a snapshot of an attached SMP.
[nasadmin@~]$ naviseccli -h SPA snap -create -res 8155 \
-name PrimaryLUN1_Cascading_Snapshot1
# list the result
[nasadmin@~]$ naviseccli -h SPA snap -list -id PrimaryLUN1_Cascading_Snapshot1 -detail
Name: PrimaryLUN1_Cascading_Snapshot1
Description:
Creation time: 03/27/12 12:54:21
Last modify time: Never
Last modified by: N/A
Source LUN(s): 8155
<===== LUN ID of the SMP (aka PrimaryLUN1_SMP1)
Source CG: N/A
Primary LUN(s): 10
<===== LUN ID of the Primary LUN (aka Primary_LUN1)
State: Ready
Status: OK(0x0)
Allow Read/Write: No
<===== We didn't specify -allowReadWrite flag at creation
Modified: No
Attached LUN(s):
Allow auto delete: Yes
Expiration date: Never
EMC VNX Snapshots White Paper
46
Detach a Snapshot
There are two ways to detach a snapshot:
1. Detach a snapshot by sending a command to the snapshot
2. Detach a snapshot by sending the command to the SMP
To detach using a lun command, use the name of the SMP. There are no
warnings.
[nasadmin@~]$ naviseccli -h SPA navi lun -detach -name PrimaryLUN1_SMP1
However, when sending the detach command to a snapshot itself, there
are warnings:
[nasadmin@~]$ naviseccli -h SPA snap -detach -id Primary_LUN1_Snapshot
WARNING : Attempting to detach a snapshot mount point that has snapshots. The snapshots
of the mount point will be inherited by the source of the snapshot being detached.
Snapshot mount point: 8154
Are you sure you want to perform this operation?(y/n): yes
[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot -detail
Name: Primary_LUN1_Snapshot
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Last modify time: 03/27/12 13:01:09
<===== Time when detached
Last modified by: PrimaryLUN1_SMP1_COPY
Source LUN(s): 0
Source CG: N/A
Primary LUN(s): 0
State: Ready
Status: OK(0x0)
Allow Read/Write: Yes
Modified: Yes
<===== Shows as modified, since it used to be attached
Attached LUN(s):
<===== Nothing listed
Allow auto delete: Yes
Expiration date: Never
Destroy a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -destroy -id Primary_LUN1_Snapshot
Are you sure you want to perform this operation?(y/n): yes
List all VNX Snapshots for a LUN
Check whether the LUN belongs to a CG.
[~]$ naviseccli -h SPA lun -list -l 4 -belongsToCG
LOGICAL UNIT NUMBER 4
Name: LB_LUN
Consistency Group: USG-CG
[~]$ naviseccli -h SPA lun -list -l 12 -belongsToCG
LOGICAL UNIT NUMBER 12
Name: LB_LUN
Consistency Group: N/A
Note: The getlun command does not show the VNX Snapshot
information.
EMC VNX Snapshots White Paper
47
[~]$ naviseccli -h SPA getlun 4 | egrep -i "group|snap"
RAIDGroup ID:
N/A
If the LUN is a part of a CG, use that CG name to find the list of all LUNs:
[~]$ naviseccli -h SPA snap -list -res CG_name
Name: 2012-02-10 14:45:18
Description:
Creation time: 02/10/12 14:45:24
Source LUN(s): 4,5
Source CG: CG_name
State: Ready
Allow Read/Write: Yes
Modified: No
Allow auto delete: Yes
Expiration date: Never
Name: Backup Snapshot:2012-02-14 04:28:21
Description:
Creation time: 02/14/12 16:28:23
Source LUN(s): 4,5
Source CG: CG_name
State: Ready
Allow Read/Write: No
Modified: No
Allow auto delete: Yes
Expiration date: Never
To list snapshots for a single LUN (that is not a member of a CG) specify
the LUN ID or name with -res option.
Create a Consistency Group
To create a CG with two member LUNs, use this command:
[~]$ naviseccli -h SPA snap -group -create -name "CG_name" -res 4,5 -descr "CG group1"
List Consistency Groups
To list all CGs on the array, use this command:
[~]$ naviseccli -h SPA snap -group -list
Name: CG_name
Description:
Allow auto delete: Yes
Member LUN ID(s): 4, 5
State: Ready
Name: USG-CG_mountpoints
Description:
Allow auto delete: Yes
Member LUN ID(s): 8081,8080
State: Ready
EMC VNX Snapshots White Paper
48
Create a Consistent Snapshot
To snap a Consistent Snapshot, use the command:
[~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap
Note: When creating a Consistent Snapshot on a CG that has only SMP
members, all the SMPs must be attached.
Otherwise, the following error is displayed:
[~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap
The snapshot of the consistency group cannot be created because some members of the
group are unattached snapshot mount points. Attach all members of the consistency group
and retry the operation. (0x716d8063)
Attach a Consistent Snapshot
CLI does not allow attaching a Consistent Snapshot to multiple SMPs in
one command. It is only possible to attach a Consistent Snapshot to
every SMP one by one.
[~]$ naviseccli -h SPA lun -attach -name SMP1 -snapName Consistent_Snap
[~]$ naviseccli -h SPA lun -attach -name SMP2 -snapName Consistent_Snap
[~]$ naviseccli -h SPA lun -list -showOnly Snap -attachedSnapshot
LOGICAL UNIT NUMBER 504
Name: SMP1
Attached Snapshot: Consistent_Snap
LOGICAL UNIT NUMBER 503
Name: SMP2
Attached Snapshot: Consistent_Snap
SnapCLI
SnapCLI is the utility used on the host to manage snapshots and their
attachments to the SMPs. It uses in-band (FC or iSCSI) communication
with the array and thus does not require an IP connection to the Storage
Processor (SP).
SnapCLI is similar to the ADMSNAP utility in SnapView (ADMSNAP is not
used with VNX Snapshots). Both provide the same level of security in
that they can only manage snapshots of LUNs that they have access to,
based on the primary LUNs or existing SMPs exposed to the host. In
other words, the array administrator sets up the primary LUNs and/or
SMPs and puts them in the host storage group and then the host
administrator may use SnapCLI to manage snapshot creation,
destruction, attach and detach for those LUNs only.
Note: To run SnapCLI, run the SnapCLI command from its installation
folder, or modify the PATH to include the SnapCLI path. The default path
in Windows is C:\Program Files\EMC\Unisphere SnapCLI
EMC VNX Snapshots White Paper
49
Flush buffers
Like ADMSNAP, SnapCLI must be used to flush disk buffers before
creating or detaching a VNX Snapshot. This is especially important in
Windows environments.
:: Windows
SnapCLI flush -o G:
Create a Snapshot
:: Windows
SnapCLI create -s SnapCLI_snap1 -o \\.\PhysicalDrive1
:: Or address by the drive letter
SnapCLI create -s SnapCLI_snap2 -o G:
Attach a Snapshot
The following command attaches a snapshot to the first SMP available.
When there are many SMPs (that belong to the primary LUN), the first
available SMP is used (usually the one identified as the lower drive, e.g.
\\.\PhysicalDriveX).
:: Windows
SnapCLI attach -s SnapCLI_snap1 -f
Note: When the -f option is supplied, VNX changes the
allowReadWrite property to "Yes" while the snapshot stays attached.
Copy a Snap
An attached snapshot cannot be copied. Therefore, the request to copy
an attached snapshot will fail.
When a snapshot is not attached, it can be copied. You must specify
both the name of the Snap to be created and the name of the Snap to be
snapped.
:: Windows
SnapCLI copy -s SnapCLI_snap1_copy -b SnapCLI_snap1 -o G:
Consistency Groups
One main difference between SnapCLI and ADMSNAP is Consistency
Groups support. When creating VNX Snapshots, you can specify the
name of Consistency Group (CG) along with a list of LUNs. If the
specified CG does not already exist, it is created containing the LUNs
specified as members.
Note: If the specified Consistency Group already exists, the existing
members of the CG are replaced with the LUNs specified as members.
The storage system maintains the CG and member LUNs persistently.
EMC VNX Snapshots White Paper
50
:: Windows
:: Create a Consistent Snapshot, and a Consistency group (if it doesn't exist)
SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name
Sample SnapCLI batch script
Note: SnapCLI does not support storagegroup commands. Therefore, all
necessary SMPs must be provisioned to the hosts before SnapCLI can
mount any snapshots. SMPs are not required for snapshot creation.
:: Windows
@echo off
:: Create one snap
echo "Creating a snapshot for drive M:"
SnapCLI create -s SnapCLI_snap_m -o M:
:: Create a Consistent Snap
:: and a Consistency group (if it doesn't exist)
SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name
:: Attach a single snap
:: (requires 1 mount point already provisioned to the host)
SnapCLI attach -s SnapCLI_snap_m -f
:: Attach a Consistent Snapshot
:: (requires as many mount points as number of LUNs in the CG)
SnapCLI attach -s Consistent_Snap -f
EMC VNX Snapshots White Paper
51
VNX Snapshots vs. SnapView terms
The following table shows the consolidated difference between VNX
Snapshots and SnapView terminology.
VNX Snapshot
Definition
SnapView
Snapshot
Point-in-time copy of a LUN2
Session
Create
Take a point-in-time copy of a LUN3
Start
Attach
Connect a snapshot to Snapshot Mount
Point
Activate
Detach
Disconnect from a Snapshot Mount Point
Deactivate
Primary LUN
LUN4 from which the snapshot is taken
Source LUN
Snapshot
Mount Point
An object that is exposed to the host
through a storage group
Snapshot
Restore
Change a LUN data to a specific point-intime copy
Rollback
Delete
Delete a snapshot
Stop
Copy
Create an identical copy of a Snapshot
-- N/A --
Consistency
Group
Persistent grouping of primary LUNs or
Mount Points
-- N/A --
In this context, besides LUNs, VNX Snapshots can be taken on a Consistency Group, or Attached Mount Point
Same as above
4
Same as above
2
3
EMC VNX Snapshots White Paper
52
Properties Detailed
Snapshot properties
Every snapshot has the following properties:
Snapshot
property
Name
Description
Description
Unique user friendly name.
This name can be used to
identify the snapshot in
management commands. The
array will generate a unique
name if it is not supplied
during the time of snapshot
creation.
User-created description
Creation Time The time when the snapshot
was created
Last Modify
The time when the snapshot
Time
was last detached from a
SMP
Last Modified The field is blank until the
By
first snapshot is detached.
After it is detached, the field
is updated with the name of
the SMP that the snapshot
was attached to.
Primary LUN
Name of the source that is
used to create the Snapshot
State
Object state from the array's
point of view
User
editable?
Yes
Yes
Value range
ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
255
ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
255
Timestamp
Timestamp or the
word "Never"
ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
64
ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
64
 Initializing
 Ready
 Faulted
EMC VNX Snapshots White Paper
53
Snapshot
property
Allow
Read/Write
Modified
Source LUNs
Allow auto
delete
Expiration
Date
Description
An indicator whether the
Snapshot may be attached to
a SMP or not. The default
setting is No
An indicator that the
snapshot is or had previously
been attached to a SMP
The SMP that the Snapshot is
currently attached to
An indicator whether or not
this Snapshot participates in
auto-delete
The date/time that the
snapshot will get
automatically deleted (Time
of day of destruction may be
approximate). The default is
Never expiring.
User
editable?
Value range
 Offline
 Destroying
Yes/No
Yes
Yes/No
List
Yes
Yes/No
Yes
Timestamp
Snapshot Mount Point properties
Every SMP has the following properties:
SMP property
Name
Description
Unique user friendly name
LOGICAL UNIT ID of the SMP. The array
NUMBER
assigns a unique LUN ID to
the SMP. This can be set in
the GUI or CLI only at the time
of creation.
User Capacity Size of the attached
snapshot. Will be set to one
of:
User
editable?
Yes
Yes
Value range
ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
64
Shared with all
LUN types (starts
high similar to
SnapView
Snapshot LUNs)
EMC VNX Snapshots White Paper
54
SMP property
Description
User
editable?
Value range

LUN Type
State Details
WWN
Current
Owner
Default
Owner
Auto Assign
Enabled
Allocation SP
Auto Delete
Active
Operation
Attached
Snapshot
Statistics
Allow Inband
Snap Attach
Primary LUN size if never
attached
 Current attached
snapshot size
 Last attached size if
unattached
Field indicating that the LUN
is VNX SMP
Details about the current
state, if any
World Wide Name
SP that currently owns the
LUN
SP that owns the LUN by
default
An indicator if the LUN
should participate in auto
assignment
Set by the array (derived from
the primary LUN)
Indicator whether or not
snapshots of this SMP
participate in auto-delete.
The default setting is Yes.
Set by the array
User-friendly name of the
snapshot attached to the
SMP
Same as Classic LUNs, Thick
LUNs, and Thin LUNs
Setting to enable or disable
attaching mountpoint from
host-based SnapCLI
Snapshot Attach
LUN
ASCII
SPA, SPB.
Yes
SPA, SPB
SPA, SPB
SPA, SPB
Yes
Yes/No
 Expanding
 Shrinking
 Attaching
 Detaching
Maximum length:
255
Yes


Enabled
Disabled
EMC VNX Snapshots White Paper
55
Additional pool properties
VNX Snapshots adds the following pool properties:
Pool property
Primary
Capacity
Used
Snapshot
Capacity
Used
Description
User
editable?
The total amount of storage
that is consumed from this
pool for data written to all the
primary LUNs in the pool.
The total amount of storage
that is consumed from this
pool for data written to all the
snapshots in the pool.
The total amount of storage
that is allocated from this
pool to store metadata for
the LUNs and Snapshots in
the pool.
Primary
The total amount of user data
Subscribed
that can be written to all of
Capacity
the LUNs in the pool.
Snapshot
The total amount of space
Subscribed
that all snapshots currently
Capacity
consume and what they
would consume if all the
primary LUNs’ data was
overwritten.
Metadata
The total amount of metadata
Subscribed
storage that is required to
Capacity
support writing to the entire
contents of all the LUNs in
the pool.
Auto-Delete
Indicator that the system
Pool Full
should check the pool full
Threshold
high water mark for autoEnabled
delete. (Default: TRUE)
Auto-Delete
Pool percentage full that will
Pool Full High trigger snapshot autoWater Mark
deletion in the pool. Shown
as a pool percentage full and
Total primary
capacity
Total snapshot
capacity
Metadata
Capacity
5
Value range
Total overhead
capacity
Total primary
subscription
Total snapshot
subscription
Total overhead
subscription
Yes
On/Off
Yes
0.01 - 99%5
GUI only allows whole numbers. CLI will accept decimal places.
EMC VNX Snapshots White Paper
56
Pool property
Auto-Delete
Pool Full Low
Water Mark
Auto-Delete
Pool Full
State
Auto-Delete
Snapshot
Space Used
Threshold
Enabled
Auto-Delete
Snapshot
Space Used
High Water
Mark
Auto-Delete
Snapshot
Space Used
Low Water
Mark
Description
also a size for convenience.
(Default: 95%)
Pool percentage full at which
auto-delete will stop
snapshot auto-deletion in the
pool. This value must be less
than the high water mark.
(Default: 85%)
The state of the pool full
auto-delete process for this
pool.
The “Auto-delete Pool Full
State” and “Auto-Delete
Snap Used State” states will
be aggregated into a single
state for reporting using the
GUI. Separate states for each
will be reported via the CLI.
Indicator that the system
should check the snapshot
space used high water mark
for auto-delete. (Default:
FALSE)
Total percentage snapshot
space used in the pool that
will trigger snapshot autodeletion in the pool. Shown
as a pool percentage full and
also a size for convenience.
(Default: 25%)
Total percentage snapshot
space used in the pool that
will stop snapshot autodeletion in the pool. This
value must be less than the
high water mark. Shown as a
pool percentage full and also
a size for convenience.
(Default: 20%)
User
editable?
Yes
Value range
0 - 98.00%6





Idle
Running
Could not
Reach LWM
System Paused
Failed
Yes
On/Off
Yes
0.01 - 99.00%7
Yes
0 - 98.00%8
GUI only allows whole numbers. CLI will accept decimal places.
GUI only allows whole numbers. CLI will accept decimal places.
8
GUI only allows whole numbers. CLI will accept decimal places.
6
7
EMC VNX Snapshots White Paper
57
Pool property
Auto-Delete
Snap Used
State
Description
User
editable?
Value range
The state of the Snapshot
Space Used auto-delete
process for this pool.



The “Auto-delete Pool Full
State” and “Auto-Delete
Snap Used State” states will
be aggregated into a single
state for reporting using the
GUI. Separate states for each
will be reported using the CLI.


Idle
Running
Could not
Reach LWM
System Paused
Failed
EMC VNX Snapshots White Paper
58