Shepherd Note

Data ONTAP snapshot for LUN and NFS

Environment

Data ONTAP 7.2.4 (Simulator)

Solaris 10 Update 6 (X86)

Snapshot for LUN

On NetApp Data ONTAP, LUNs are created from volume. Snapshot is taken at the volume level, rather than LUN level. If a snapshot is taken for a volume, all the LUNs residing on the volume will have a snapshot. Therefore, the restoration of a volume snapshot will revert all the LUNs of that volume to the status before the snapshot was taken.

For example, if both lun1 and lun2 are created from vol1, the snapshot for vol1 will capture data on both lun1 and lun2. If vol1 is restored from snapshot using command “snap restore –s <snapshot name> <volume name>”, then data on both lun1 and lun2 will be reverted to its original state.

If you only want to restore data on a single LUN, you can create a clone LUN from the snapshot. This clone LUN can then be mapped to the server for restoration. LUN clone from snapshot for a single LUN will not change data on other LUNs, even if they are in the same volume.

For example, lun1 and lun2 are created form vol1. A snapshot vol1-snap for vol1 is taken. After that you want to restore data on lun1 from the vol1-snap. You can follow steps below to recover data on lun1 by creating a clone LUN

1. Create a clone LUN using “lun clone create /vol/vol1/lun1-orig -b /vol/vol1/lun1 vol1-snap”.

2. Bring clone LUN online if it is offline, then pap the clone LUN to initiator group using “lun map /vol/vol1/lun1-orig ig1”.

3. Discover the new LUN on the server.

4. Mount the file system and start restoration.

5. Un-mount file system and remove clone LUN on the array.

Note that after clone LUN is mounted on the server, you don’t need to create new file system on the LUN. In addition, the file system on the LUN is read-writable.

Snapshot for NFS

On NetApp Data ONTAP, NFS is created from Qtree which resides on a volume. Qtree can be regarded as a sub-directory in a volume, this directory can be exported as NFS to the server. You can’t specify the size of a Qtree since it is a directory. But you can specify the quota of a Qtree which will be shown as the size of NFS if checked on the server.

The procedure for creating a NFS resource is as below.

1. Create a Qtree qtree1 on the array using “qtree create /vol/vol1/qtree1”

2. On the array, check the contents of file /etc/exports using “rdfile /etc/exports”

3. Note the line for /vol/vol0, change the management IP address to the IP address of the server which you want to use for disk array management. In this example, the IP address of the management server is 192.168.56.12.

/vol/vol0    -sec=sys,ro,rw=192.168.56.12,root=192.168.56.12,nosuid

4. Mount /vol/vol0 on server with IP address 192.168.56.12

5. On the management server, open file <mount point>/etc/exports, add lines for Qtree qtree1. Server 192.168.56.12 is also used as NFS client in this example.

/vol/vol1/qtree1 -sec=sys,rw,root=192.168.56.12

6. On the disk array, export the Qtree as NFS using command “exportfs /vol/vol1/qtree1”

7. On the disk array, check quota status for vol1 using command “quota status vol1”. If quota for vol1 is off, then enable quota for vol1 using “quota on vol1”. (You may be told that /etc/quotas does not exist, then you need to manually touch file /etc/quotas).

8. On the management server, open file <mount point>/etc/quotas and add line below in the file to specify NFS size is 400M

/vol/vol1/qtree1        tree    400M

9. On the disk array, resize quota for vol1 using command “quota resize vol1”.

10. Mount NFS resource <IP address>:/vol/vol1/qtree1 and you can see that the NFS size is 400M. (Note: repeat step 8, 9, 10 if you want to resize NFS size)

You can then make some modification on the NFS and make a snapshot for vol1. After the snapshot is taken, a directory called .snapshot will be created in the Qtree. Users on NFS client can access this directory and use the data for restoration.

Note that if a volume snapshot is taken, both LUNs and Qtrees in the volume will have a snapshot.

Posted June 8, 2011 by shepherd

Install Perl modules with Solaris bundled Perl

I always found it troublesome to install Perl modules with Solaris bundled Perl (current version 5.8.4). The problem is Solaris bundled Perl is compiled using cc. But cc is not by default installed on Solaris. So when you want to compile the downloaded modules, you will see error message such as “cc compiler cannot be found”.

This problem has been harassing me for quite a long time and finally I found a way to installed Perl modules with Solaris bundled Perl. The steps are listed as below (I cannot explain why these steps are needed but it actually works for me).

1. Install following packages in the system. They can be downloaded from http:/www.sunfreeware.com

sol2$ pkginfo | grep SMC

application SMCgcc                           gcc

application SMClgcc346                       libgcc

application SMCliconv                        libiconv

application SMClintl                         libintl

2. Add following directories in environment parameters. Make sure make and cc can be found in the environment parameters

sol2$ export PATH=$PATH:/usr/local/bin:/usr/ucb:/usr/ccs/bin

sol2$ which make

/usr/ccs/bin/make

sol2$ which cc

/usr/ucb/cc

3. Backup /usr/ucb/cc and create a symlink for /usr/local/bin/gcc as /usr/ucb/cc

sol2$ mv /usr/ucb/cc /usr/ucb/cc.orig

sol2$ ln -s /usr/local/bin/gcc /usr/ucb/cc

sol2$ ls -l `which cc`

lrwxrwxrwx   1 root     root          18 Jan 30 15:33 /usr/ucb/cc -> /usr/local/bin/gcc

Now you should be able to compile the modules, but don’t forget the most important step, which is to use “/usr/perl5/5.8.4/bin/perlgcc” rather than “/usr/bin/perl” to compile the modules.

I used these steps to install three modules on my Solaris 10 X86 virtual boxes with bundled Perl 5.8.4. The installed modules are IO-Tty-1.10, Expect-1.21 and Net-SSH-Expect-1.09 , all of them can be installed correctly. I also tried to install DBI-1.613, which I always had problem with, and it seems that it can be installed correctly as well.

Posted June 4, 2011 by shepherd

VCS Agents – MultiNICA and IPMultiNIC

MultiNICA does not require NIC to be plumbed and setup manually. Each NICs managed by MultiNICA needs to have a base IP address for connectivity test. The base IP addresses are defined in main.cf. See example below.

There are two nodes sol1 and sol2 in the cluster. Each node has two interfaces, e1000g1 and e1000g2. IP address 192.168.22.11 (on sol1) and 192.168.22.12 (on sol2) are base IP addresses. 192.168.22.103 is the floating IP address. See embedded main.cf (click here)

After the cluster is online, the interface status on sol1 is as below,

sol1

e1000g1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 6

         inet 192.168.22.11 netmask ffffff00 broadcast 192.168.22.255

         ether 8:0:27:b3:70:8

e1000g1:1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 6

         inet 192.168.22.103 netmask ffffff00 broadcast 192.168.22.255

After e1000g1 is failed, both base IP address and floating IP address will fail over to e1000g2 on sol1.

sol1

e1000g2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 7

         inet 192.168.22.11 netmask ffffff00 broadcast 192.168.22.255

         ether 8:0:27:cc:59:a8

e1000g2:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 7

         inet 192.168.22.103 netmask ffffff00 broadcast 192.168.22.255

After e1000g2 is also failed, the base IP address will be kept on sol1 while the floating IP address will fail over to sol2.

sol1

e1000g1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 15

         inet 192.168.22.11 netmask ffffff00 broadcast 192.168.22.255

         ether 8:0:27:b3:70:8

sol2

e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5

         inet 192.168.22.12 netmask ffffff00 broadcast 192.168.22.255

         ether 8:0:27:e2:60:3e

e1000g1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5

         inet 192.168.22.103 netmask ffffff00 broadcast 192.168.22.255

Comparison MultiNICA and MultiNICB

I. MultiNCIB can work with Solaris IPMP. If UseMpathd is enabled, then the interface status is determined by IPMP, VCS relies on IPMP to failover IP address. The NICs should be plumbed and configured in IPMP before being managed by VCS, which means MultiNICB can only work on Solaris.

II. MultiNICA does not depend on IPMP, which means it can also work on other OS (Linux and etc). NIC status is determined by VCS using base IP address. NIC can be unplumbed and base IP addresses are defined in main.cf. But Symantec suggests that fail over of MultiNICA could be much slower than MultiNICB. Test result shows that, for MultiNICA, base IP address fail over is very slow, this may because VCS tries to determine NIC status multiple times.

Posted May 31, 2011 by shepherd

VCS Agents – MultiNICB and IPMultiNICB

MultiNICB and IPMultiNICB enable VCS to work with Solaris IPMP. For example, on node sol1 there are two interface e1000g1 and e1000g2 on the server. IP address 192.168.22.11 is managed by IPMP to failover across e1000g1 and e1000g2. In addition, an floating IP address 192.168.22.101 is managed by VCS to failover across cluster nodes sol1 and sol2.

e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3

        inet 192.168.22.11 netmask ffffff00 broadcast 192.168.22.255

        groupname grp1

        ether 8:0:27:b3:70:8

e1000g1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3

        inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255

e1000g1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3

        inet 192.168.22.101 netmask ffffff00 broadcast 192.168.22.255

e1000g2: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 4

        inet 0.0.0.0 netmask 0

        groupname grp1

        ether 8:0:27:cc:59:a8

If e1000g1 is failed, both 192.168.22.11 and 192.168.22.101 will failover to e1000g2. If e1000g2 is also failed, then 192.168.22.101 will failover to another node sol2.

The NIC must be plumbed before being managed by VCS. IP address 192.168.22.11 is defined in /etc/hostname.* and 192.168.22.101 is defined in main.cf. Before configuring MultiNICB and IPMultiNICB, you need to enable IPMP by modifying /etc/hostname.e1000g1 and /etc/hostname.e1000g2 on both sol1 and sol2.

sol1

$ cat /etc/hostname.e1000g1

192.168.22.11 netmask + broadcast + group grp1 up

$ cat /etc/hostname.e1000g2

group grp1 standby up

sol2

$ cat /etc/hostname.e1000g1

192.168.22.12  netmask + broadcast + group grp1 up

$ cat /etc/hostname.e1000g2

group grp1 standby up

Normally, if multiple floating IP addresses are needed, you can create a dedicated service group for MultiNICB resource. Then create a proxy resource pointing to the MultiNICB resource for each IPMultiNICB resource. See embedded example (click here)

In VCS bundle agent document, it only mentions that MultiNICB can work with Probe-based IPMP, which require many IP address to be configured ( for instance, if you have two nodes and two interfaces on each node, then each interface needs a test IP address and you need another floating IP address, makes it 5 IP address altogether). However, in Solaris 10, MultiNICB can also work with Link-based IPMP (see example above).

MultiNICB resource has two working mode Base and Multipathing, depending on the value of UseMpathd. In Base mode, MultiNICB determine the NIC status by itself (sending packages to other hosts). In Multipathing mode, MultiNICB dependes on in.mpathd to determined the status of NIC (check FAILED flag on the NIC).

Note: There is a MultiNICB bug in VCS 5.1 (Etrack ID 1961530). Any NIC managed by MultiNICB is tagged as DEPRECATED and NOFAILOVER. That means if the underlying NIC is failed, then the base IP address is not able to be failed over to the standby NIC. You need to setup the NIC as “ifconfig e1000g1 failover -deprecated” to enable the base IP address to fail over to e1000g2 ( test result shows that you only need to do this on e1000g1, not on e1000g2)

Posted May 30, 2011 by shepherd

VCS Agents – Proxy

VCS uses resource dependency to determine if a resource needs to be online of offline. Sometimes, it is required that a resource in one service group is depended by a resource in another service group. However resource dependency cannot span service group.

Proxy is a resource to mirror the resource state in another service group.

For example, there is a resource file-none in service group sg1

group test-sg (
SystemList = { sol1 = 0, sol2 = 1 }
Parallel = 1
AutoStartList = { sol1, sol2 }
)

FileNone file-none (
PathName = "/var/tmp/filenone"
)

The state of resource file-none is needed in another service group sg2, therefore you can create a proxy resource file-none-p in sg2 for file-none.

group sg2 (
SystemList = { sol1 = 0, sol2 = 1 }
AutoStartList = { sol1, sol2 }
)

Proxy file-none-p (
TargetResName = file-none
)

You can see that the state for file-none-p is the same as the state of file-none, even though they are in different service group

sol1$ hares -state file-none
#Resource    Attribute        System     Value
file-none    State            sol1       ONLINE
file-none    State            sol2       ONLINE
sol1$ hares -state file-none-p
#Resource    Attribute        System     Value
file-none-p  State            sol1       ONLINE
file-none-p  State            sol2       ONLINE

Note that Proxy resource can only be used for NONE (persistent) and OnOnly resource, such as NIC and FileNone.

Posted May 29, 2011 by shepherd

VCS Agents – Phantom

Phantom is a dummy resource for VCS to determine the status of a service group whose resources’ type is None or OnOnly

For example, if a service group is defined as below

group sg2 (
SystemList = { sol1 = 0, sol2 = 1 }
AutoStartList = { sol1, sol2 }
)

NIC nic (
Device = e1000g0
)

This service group is online on both nodes in the cluster, VCS is not able to offline this group as the type for resource NIC is None.

In this case, if you want to offline service group on a node, you need to define a Phantom resource in the service group.

group sg2 (
SystemList = { sol1 = 0, sol2 = 1 }
AutoStartList = { sol1, sol2 }
)

NIC nic (
Device = e1000g0
)

Phantom nic_p (
)

If you check the cluster status, you can see that resource nic is online on both sides but nic_p is online on only one side.

nic                  sol1                 ONLINE
nic                  sol2                 ONLINE
nic_p                sol1                 OFFLINE
nic_p                sol2                 ONLINE

Posted May 29, 2011 by shepherd

A NTP problem

Description

This morning, when i was trying to install Storage Foundation, I got the warning message telling me that the time on two machines are not the same. I tried to enable one of the servers as NTP server and the other one as NTP client. Then I got the problem.

The NTP setup are actually not difficult. I just created /etc/inet/ntp.conf on both servers. The date on NTP server sol8 is,

sol8$ date
Monday, January 10, 2011 10:33:45 AM PST

On NTP client sol9, I ran ntpdate -d sol8 trying to check the time difference,

sol9$ ntpdate -d 192.168.47.83
10 Jan 09:21:26 ntpdate[1402]: ntpdate 3-5.93e+sun 03/06/05 23:16:45 (1.4)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
server 192.168.47.83, port 123
stratum 4, precision -17, leap 00, trust 000
refid [127.127.1.0], delay 0.02585, dispersion 0.00000
transmitted 4, in filter 4
reference time:    d0d5ced6.cf8d0000  Tue, Jan 11 2011  5:30:46.810
originate timestamp: d0d5cefa.6f0eb000  Tue, Jan 11 2011  5:31:22.433
transmit timestamp:  d0d4b366.df308000  Mon, Jan 10 2011  9:21:26.871
filter delay:  0.02649  0.02585  0.02585  0.02585
                   0.00000  0.00000  0.00000  0.00000
filter offset: 72595.56 72595.56 72595.56 72595.56
                   0.000000 0.000000 0.000000 0.000000
delay 0.02585, dispersion 0.00000
offset 72595.561852

10 Jan 09:21:26 ntpdate[1402]: step time server 192.168.47.83 offset 72595.561852 sec

I then ran ntpdate -b sol8 to synchronized the time,

sol9$ date
Monday, January 10, 2011  9:21:30 AM ES

sol9$ ntpdate -b sol8
11 Jan 05:31:53 ntpdate[1404]: step time server 192.168.47.83 offset 72595.567804 sec

sol9$ date
Tuesday, January 11, 2011  5:31:54 AM EST

Surprising, the date after synchronization is not the same as that on sol8.

Resolution

Notice that the time on sol8 is AM PST, however, the time on sol9 is AM EST, which indicates that the timezone on two servers are different.

On sol9, the timezone is Australia/NSW, however, on sol8 it is US/Pacific.

I use tzselect to change timezone on sol8, I also changed /etc/TIMEZONE on sol8 to Australia/NSW, then reboot sol8.

The system is back to normal after sol8 is rebooted. The time on sol9 and sol8 can be synchronized successfully.

Note

If you see following error message while running ntpdate -b <ntp server>,

11 Jan 05:40:07 ntpdate[1411]: no server suitable for synchronization found

The reason could be the NTP server hasn’t synchronized with itself yet.

On sol8, the output of ntpq -p is
sol8$ ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
 LOCAL(0)        LOCAL(0)         3 l    7   64    7     0.00    0.000 3885.01
 224.0.1.1       0.0.0.0         16 u    -   64    0     0.00    0.000 16000.0

The large value for disp indicates that sol8 hasn’t synchronized with itself yet. You may need to wait for it to decrease to a smaller value, then try to sychronized the time on NTP client. It will be working then.

sol8$ ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*LOCAL(0)        LOCAL(0)         3 l   50   64  377     0.00    0.000   10.01
 224.0.1.1       0.0.0.0         16 u    -   64    0     0.00    0.000 16000.0

sol9$ ntpdate -d sol8
11 Jan 05:53:51 ntpdate[1472]: ntpdate 3-5.93e+sun 03/06/05 23:16:45 (1.4)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
receive(192.168.47.83)
transmit(192.168.47.83)
server 192.168.47.83, port 123
stratum 4, precision -17, leap 00, trust 000
refid [127.127.1.0], delay 0.02585, dispersion 0.00000
transmitted 4, in filter 4
reference time:    d0d4c8d0.da215000  Mon, Jan 10 2011 10:52:48.852
originate timestamp: d0d4c90d.17583000  Mon, Jan 10 2011 10:53:49.091
transmit timestamp:  d0d5d43f.3935f000  Tue, Jan 11 2011  5:53:51.223
filter delay:  0.02606  0.02589  0.02585  0.02588
                   0.00000  0.00000  0.00000  0.00000
filter offset: -68402.1 -68402.1 -68402.1 -68402.1
                   0.000000 0.000000 0.000000 0.000000
delay 0.02585, dispersion 0.00000
offset -68402.132455

11 Jan 05:53:51 ntpdate[1472]: step time server 192.168.47.83 offset -68402.132455 sec

sol9$ ntpdate -b sol8
10 Jan 10:54:03 ntpdate[1473]: step time server 192.168.47.83 offset -68402.133875 sec

Posted January 10, 2011 by shepherd

VxVM Snapshot (6)

Linked break-off snapshot

Linked break-off snapshot is similar to third-mirror break-off snapshot. The difference is that the linked break-off snapshot is created in a disk group different from the disk group of the original volume. In this circumstance, the disk group for linked break-off snapshot can be deported and imported for off host backup.

Operation: Create a linked break-off snapshot

1. Assume original volume origvol and snapshot volume snapvol are in different diskgroup: origdg and snapdg. Prepare both volumes.

sol10$ vxsnap -g origdg prepare origvol
sol10$ vxsnap -g snapdg prepare snapvol

2. Link the snapshot volume to the original volume.

sol10$ vxsnap -g origdg addmir origvol mirvol=snapvol mirdg=snapdg

Notice that after this step, the device file snapvol at /dev/vx/dsk/snapdg will disappear. It will reappear after step 3

3. Create the linked break-off snapshot volume.

sol10$ vxsnap -g origdg make source=origvol/snapvol=snapvol/snapdg=snapdg

4. Fsck the snapshot volume and mount the snapshot volume. The data on the snapshot volume should be available for access.

5. The linked break-off snapshot volume can be reattached to the original volume. Unlike full-sized instant snapshot and third-mirror break-off snapshot, the snapshot volume will not be removed after being attached to the original volume, nor its plex will become a plex of the original volume. After being attached to the original volume, the status of the original volume and snapshot volume will be the same as that of after step 2. The data on the snapshot volume is synchronized with the original volume. Then use the same command as in step 3, the snapshot volume can be created again.

sol10$ vxsnap -g snapdg reattach snapvol source=origvol sourcedg=origdg
sol10$ vxsnap -g origdg make source=origvol/snapvol=snapvol/snapdg=snapdg

The link relationship between the original volume and snapshot volume can be broken

 sol10$ vxsnap -g origdg rmmir origvol mirvol=snapvol mirdg=snapdg

6. The snapshot volume can *NOT* be refreshed.

7. The original volume can *NOT* be restored from the snapshot volume.

8. Dissociate snapshot volume.

sol10$ vxsnap -g snapdg dis snapvol

Note

the sp object remains on the original volume even after the snapshot volume is dissociated from the original volume. Use command below t o delete sp object on the original volume.

sol10$ vxsnap -g origdg dis origvol

Posted January 9, 2011 by shepherd

VxVM Snapshot (5)

Third-mirror break-off snapshot

This is not traditional third-mirror break-off snapshot which is created by vxassist. This is created by vxsnap, but has a similar mechanism with the traditional one. That is to say, a plex of the original volume can be turned into s snapshot volume.

Operations: Create a third-mirror break-off snapshot

1. Prepare a volume

2. Add a mirror plex in the original volume. This mirror plex can then be turned into a snapshot volume.

sol10$ vxsnap -g tsnapdg addmir origvol

3. Create snapshot from the added mirror

sol10$ vxsnap -g tsnapdg make source=origvol/newvol=snapvol/plex=plex1

In SF5.1, plex must be specified while creating third-mirror break-off snapshot using vxsnap. The status of the plex could be SNAPDONE or ACTIVE. If a snapshot is going to be created from an ACTIVE plex, then there is no need to run step 2

4. The snapshot volume can be reattached to the original volume, then be turned into snapshot volume again.

sol10$ vxsnap -g tsnapdg reattach snapvol source=origvol

5. The data on the snapshot volume can be refreshed

sol10$ vxsnap -g tsnapdg refresh snapvol

6. The snapshot volume can then be dissociated from the original volume.

sol10$ vxsnap -g tsnapdg dis snapvol

Note:

there are two steps to create a break-off snapshot; the first step is to add a mirror to the original snapshot. The second step is to create a snapshot volume from the additional mirror. If the data on the original volume is changed after step one, then the changed data will also be written to the snapshot volume at step two. The first step is to establish a snapshot relationship. After step 1 is implemented, any data written to the original volume will write a copy to the mirror.

Posted January 9, 2011 by shepherd

VxVM Snapshot (4)

Full-sized instance snapshot

VxVM uses copy-on-write mechanism to create Full-sized instant snapshot. That is to say, when the snapshot volume was first created, the data on the original volume has yet been copied to the snapshot volume. At this point, if a read request comes to the snapshot to read the data yet resides on the snapshot volume, VxVM will then automatically direct the read request to the original volume. When the data on the original volume is changed, the original data is moved to the snapshot volume. Full-sized instant snapshot are not suitable for write intensive volumes since copy-on-write mechanism is used.

Operations: Create a full-sized instant snapshot

1. Checking the length, DCO log, region size of the original volume.

sol10$ LEN=`vxprint -g tsnapdg -F%len origvol`
sol10$ DCONAME=`vxprint -g tsnapdg -F%dco_name origvol`
sol10$ vxprint -g tsnapdg -F%regionsz $DCONAME

The default value for region size is 128.

2. If DCO is not enabled on the original volume, prepare the original volume for instant snapshot.

sol10$ vxsnap -g tsnapdg prepare origvol

The purpose of preparing the original volume for instant snapshot is to enable DCO and FastResync on the original volume.

sol10$ vxprint -g tsnapdg -F%hasdcolog origvol
on
sol10$ vxprint -g tsnapdg -F%fastresync origvol
on

If the original volume is not prepared first, then following error message will appear while creating snapshot

sol10$ vxsnap -g tsnapdg make source=origvol/snapvol=snapvol
VxVM vxassist ERROR V-5-1-7061 Volume origvol is not instant ready

3. Create a snapshot volume. The length and region size of the snapshot volume should be exactly the same as the original volume.

sol10$ vxassist -g tsnapdg make snapvol $LEN init=active
sol10$ vxsnap -g tsnapdg prepare snapvol regionsz=$RSZ [ndcomirs=number]

Be default, the number of DCO plxes automatically created by vxsnap prepare is the same as that of the data plex in the snapshot volume. That is to say, if there are two data plex in the snapshot volume, then there will be two DCO plex created by vxsnap prepare.

4. Associating and synchronizing the snapshot volume with the original volume.

sol10$ vxsnap -g tsnapdg make source=origvol/snapvol=snapvol [sync=on/off]

After this step, the content on the original volume will be synchronized to the snapshot volume. The snapshot volume in /dev/vx/dsk/tsnapdg/snapvol can be mounted independently.

Following command can be used to control the synchronized process.

vxsnap [-g diskgroup] syncstart [snapshot]
vxsnap [-g diskgroup] syncstop [snapshot]
vxsnap [-g diskgroup]syncpause [snapshot]
vxsnap [-g diskgroup] syncresume [snapshot]
vxsnap [-g diskgroup]syncwait [snapshot]

5. Fsck the snapshot volume and mount the volume.

6. After step 5, there are five options to do in the following steps

a. Refresh the snapshot from the original volume, or from any other volume that have the same configuration (length, region size) of the original volume. The snapshot volume needs to be un-mounted first.

sol10$ vxsnap -g tsnapdg refresh snapvol

Above command will refresh the snapshot volume from the immediate parent volume, in this case it should be origvol

sol10$ vxsnap -g tsnapdg refresh snapvol source=testvol

Above command will refresh the snapshot volume from the volume testvol. testvol and origvol have the same length.

Then run fsck to check the snapshot volume and mount the snapshot volume again.

b. Reattach the snapshot volume to the original volume. After this is done, the snapshot volume will become a plex of the original volume.

sol10$ vxprint -g tsnapdg reattach snapvol

If there are more than one plex in the snapshot volume, it is also possible to reattach one plex of the snapshot volume to the original volume. In this case, the snapshot volume will still be existed while one of its plex becomes the plex of the original volume.

sol10$ vxsnap -g tsnapdg reattach snapvol source=origvol nmirror=1

c. Restoration. In case the data on the original volume is destroyed, the data on the snapshot volume can be used to restore the original volume.

sol10$ vxsnap -g tsnapdg restore origvol source=snapvol

In this case, any data on the snapshot volume will be copied back to the original volume (after the snapshot volume is taken, any data created on the snapshot volume will also be copied back to the original volume while restoration)
If [destroy=yes] is specified, then the snapshot volume will become a plex of the original volume after the restoration.

d. Dissociating snapshot volume from the original volume. The snapshot volume will turn into an independent volume after being dissociated from the original volume.

sol10$ vxsnap -g tsnapdg dis snapvol

Posted January 5, 2011 by shepherd

Shepherd Noteshepherd's technical note