Veritas Volume Manager (VxVM) Instant Snapshot silently fails for data volume - vxsnap -g <dg-name> make source=<vol-name>/newvol=<new-vol-name>/cache=<cacheobj-name> due to vxsnap prepare syntax

book

Article ID: 100052444

calendar_today

Updated On:

Description

Error Message

 

The below command returns to the prompt, no error is reported and the snapshot volume is not created.

Example:

# vxsnap -g freddg make source=fredvol/newvol=snapfredvol/cache=cacheobj


NOTE: The snapshot volume "snapfredvol" for data volume "fredvol" is not created
 

# vxprint -qthg freddg
dg freddg       default      default  23000    1644481703.250.fred

dm 3pardata0_101466 3pardata0_101466 auto 65536 41875568 -
dm 3pardata0_101467 3pardata0_101467 auto 65536 41875568 -
dm 3pardata0_101468 3pardata0_101468 auto 65536 41875568 -
dm 3pardata0_101469 3pardata0_101469 auto 65536 41875568 -
dm 3pardata0_101470 3pardata0_101470 auto 65536 41875568 -

v  fredvol      -            ENABLED  ACTIVE   10485760 SELECT    -        fsgen
pl fredvol-01   fredvol      ENABLED  ACTIVE   10485760 CONCAT    -        RW
sd 3pardata0_101466-01 fredvol-01 3pardata0_101466 0 10485760 0   3pardata0_101466 ENA
dc fredvol_dco  fredvol      fredvol_dcl
v  fredvol_dcl  -            ENABLED  ACTIVE   67840    SELECT    -        gen
pl fredvol_dcl-01 fredvol_dcl ENABLED ACTIVE   67840    CONCAT    -        RW
sd 3pardata0_101466-02 fredvol_dcl-01 3pardata0_101466 10485760 67840 0 3pardata0_101466 ENA

co cacheobj     cachevol     ENABLED  ACTIVE
v  cachevol     cacheobj     ENABLED  ACTIVE   41875568 SELECT    -        fsgen
pl cachevol-01  cachevol     ENABLED  ACTIVE   41875568 CONCAT    -        RW
sd 3pardata0_101468-01 cachevol-01 3pardata0_101468 0 41875568 0  3pardata0_101468 ENA

 

Cause

Cache volume was created as follows:
 

# vxassist -g freddg make cachevol 41875568 alloc=3pardata0_101468
# vxmake -g freddg cache cacheobj cachevolname=cachevol regionsize=512k autogrow=on
# vxcache -g freddg start cacheobj


During the data volume vxsnap prepare phase, the user needs to specify the regionsz matching that of the cache object.

# vxsnap -g   prepare   regionsz=

By not specifying the regionsz, the subsequent vxsnap make command will complete, but will not create the snapshot volume.

# vxsnap -g  make source=/newvol=/cache=
 

Figure 2.0

 

Resolution

 

If you attempt to prepare a data volume for snapshots & it is already prepared "instant ready", you may see the following error:
 

# vxsnap -g freddg prepare fredvol regionsz=512k
VxVM vxassist ERROR V-5-1-7039 volume fredvol is already instant ready


Entries defined in the /etc/default/vxassist file, i.e. mirror=enclr, may also result in errors.


Steps:
 

Unprepare the data volume, removing the DCO (Data Change Object) & DCL (Data Change Log)

# vxsnap -g freddg unprepare fredvol
 

Use the below vxprint syntax against  the DCO to discover its region size (in blocks):

# RSZ=`vxprint [-g diskgroup] -F%regionsz `

In this instance, the snapshot objects (DCO) are created with a region size of 512k, matching the region size specified when creating the cache object earlier.

NOTE: Region size is shown in blocks.

# RSZ=`vxprint -g freddg -F%regionsz cacheobj`
# echo $RSZ

1024
 

When preparing the data volume for snapshot operations, specify the regionsz argument with the cache object region size defined earlier:

# vxsnap -g freddg prepare fredvol regionsz=512k

Once created, the regionsz can be verified:

# RSZ=`vxprint -g freddg -F%regionsz fredvol_dco`
# echo $RSZ

1024
 

Figure 3.0
 

 

if you attempt to create a snapshot volume against a data volume which has not be prepared, you may see the following error:

# vxsnap -g freddg make source=fredvol/newvol=snapfredvol/cache=cacheobj
VxVM vxassist ERROR V-5-1-7061 Volume fredvol is not instant ready
 

For instant snapshots, the vxsnap make command makes an instant snapshot volume immediately available for use:

# vxsnap -g freddg make source=fredvol/newvol=snapfredvol/cache=cacheobj
 

By specifying the regionsz with the vxsnap prepare command, the subsequent vxsnap make command now works successfully for data volume "fredvol" by creating new snapshot volume named "snapfredvol".

Sample output:
 

# vxprint -qthg freddg
dg freddg       default      default  23000    1644481703.250.fred

dm 3pardata0_101466 3pardata0_101466 auto 65536 41875568 -
dm 3pardata0_101467 3pardata0_101467 auto 65536 41875568 -
dm 3pardata0_101468 3pardata0_101468 auto 65536 41875568 -
dm 3pardata0_101469 3pardata0_101469 auto 65536 41875568 -
dm 3pardata0_101470 3pardata0_101470 auto 65536 41875568 -

v  fredvol      -            ENABLED  ACTIVE   10485760 SELECT    -        fsgen
pl fredvol-01   fredvol      ENABLED  ACTIVE   10485760 CONCAT    -        RW
sd 3pardata0_101466-01 fredvol-01 3pardata0_101466 0 10485760 0   3pardata0_101466 ENA
dc fredvol_dco  fredvol      fredvol_dcl
v  fredvol_dcl  -            ENABLED  ACTIVE   67840    SELECT    -        gen
pl fredvol_dcl-01 fredvol_dcl ENABLED ACTIVE   67840    CONCAT    -        RW
sd 3pardata0_101466-02 fredvol_dcl-01 3pardata0_101466 10485760 67840 0 3pardata0_101466 ENA
sp snapfredvol_snp fredvol   fredvol_dco

v  snapfredvol  -            ENABLED  ACTIVE   10485760 SELECT    -        fsgen
pl snapfredvol-P01 snapfredvol ENABLED ACTIVE  10485760 CONCAT    -        RW
sc snapfredvol-S01 snapfredvol-P01 cacheobj 0  10485760 0         -        ENA
dc snapfredvol_dco snapfredvol snapfredvol_dcl
v  snapfredvol_dcl -         ENABLED  ACTIVE   67840    SELECT    -        gen
pl snapfredvol_dcl-01 snapfredvol_dcl ENABLED ACTIVE 67840 CONCAT -        RW
sd 3pardata0_101467-01 snapfredvol_dcl-01 3pardata0_101467 0 67840 0 3pardata0_101467 ENA
sp fredvol_snp  snapfredvol  snapfredvol_dco

co cacheobj     cachevol     ENABLED  ACTIVE
v  cachevol     cacheobj     ENABLED  ACTIVE   41875568 SELECT    -        fsgen
pl cachevol-01  cachevol     ENABLED  ACTIVE   41875568 CONCAT    -        RW
sd 3pardata0_101468-01 cachevol-01 3pardata0_101468 0 41875568 0  3pardata0_101468 ENA

NOTES:

For space-optimized instant snapshots, the DCO object & DCO volume are associated with a snapshot volume that is created on a cache object and not on a VxVM disk.

The DCO volume contains the single DCO plex that was associated with the snapshot plex.

Associated with both the original data volume & the snapshot volume are snap objects.

The snap object for the original volume points to the snapshot volume, and the snap object for the snapshot volume points to the original data volume.

This allows VxVM to track the relationship between volumes and their snapshots, even if they are moved into different disk groups.


How to refresh the snapshot volume contents


Whilst the VxFS File System mount-point for the snapshot volume is unmounted, create some files on the VxFS File System mount-point for the original data volume (/fredvol)

# touch /fredvol/barney
# touch /fredvol/charlie
# cp /etc/hosts /fredvol

 

As the File System for the snapshot volume is unmounted (closed), it can refreshed by running:

# vxsnap -g freddg refresh snapfredvol
 

The vxsnap print command may be used to display information about the snapshots that are associated with a volume.
 

#  vxsnap -g freddg print
NAME    SNAPOBJECT    TYPE    PARENT    SNAPSHOT    %DIRTY    %VALID

fredvol  --           volume   --       --           --       100.00
        snapfredvol_snp  volume   --       snapfredvol  0.00     --

snapfredvol fredvol_snp  volume   fredvol  --           0.00     0.01

 

By mounting the VxFS File System for the snapshot volume "snapfredvol", the user can confirm the files now exist:
 

# mount -t vxfs /dev/vx/dsk/freddg/snapfredvol /snapfredvol

# ls -al /snapfredvol
total 5
drwxr-xr-x.  3 root root   96 Feb 10 20:19 .
dr-xr-xr-x. 34 root root 4096 Feb 10 20:21 ..
-rw-r--r--.  1 root root    0 Feb 10 20:19 barney
-rw-r--r--.  1 root root    0 Feb 10 20:19 charlie
-rw-r--r--.  1 root root  158 Feb 10 20:19 hosts
drwxr-xr-x.  2 root root   96 Feb 10 20:16 lost+found


Remove the files on the original data volume File System:

# rm /fredvol/barney
rm: remove regular empty file `/fredvol/barney'? y

# rm /fredvol/charlie
rm: remove regular empty file `/fredvol/charlie'? y
 

# vxsnap -g freddg print
NAME    SNAPOBJECT    TYPE    PARENT    SNAPSHOT    %DIRTY    %VALID

fredvol  --           volume   --       --           --       100.00
        snapfredvol_snp  volume   --       snapfredvol  0.02     --

snapfredvol fredvol_snp  volume   fredvol  --           0.02     0.03

The snapshot volume cannot be updated (refreshed) until the File System is unmounted:

# ls -al /snapfredvol
total 5
drwxr-xr-x.  3 root root   96 Feb 10 20:19 .
dr-xr-xr-x. 34 root root 4096 Feb 10 20:21 ..
-rw-r--r--.  1 root root    0 Feb 10 20:19 barney
-rw-r--r--.  1 root root    0 Feb 10 20:19 charlie
-rw-r--r--.  1 root root  158 Feb 10 20:19 hosts
drwxr-xr-x.  2 root root   96 Feb 10 20:16 lost+found

# vxsnap -g freddg refresh snapfredvol
VxVM vxsnap ERROR V-5-1-7066 Volume snapfredvol is open, cannot refresh


Once the File System is unmounted, the snapshot volume can be refreshed with the original data volume:
 

# umount /snapfredvol

# vxsnap -g freddg refresh snapfredvol

# vxsnap -g freddg print
NAME    SNAPOBJECT    TYPE    PARENT    SNAPSHOT    %DIRTY    %VALID

fredvol  --           volume   --       --           --       100.00
         snapfredvol_snp1  volume   --       snapfredvol  0.00     --

snapfredvol fredvol_snp  volume   fredvol  --           0.00     0.01

 

# mount -t vxfs /dev/vx/dsk/freddg/snapfredvol /snapfredvol


The updates have been refreshed against the snapshot volume following the vxsnap refresh:

# ls -al /snapfredvol
total 5
drwxr-xr-x.  3 root root   96 Feb 10 20:22 .
dr-xr-xr-x. 34 root root 4096 Feb 10 20:21 ..
-rw-r--r--.  1 root root  158 Feb 10 20:19 hosts
drwxr-xr-x.  2 root root   96 Feb 10 20:16 lost+found


NOTE: Changes are now reflected by mounting File System for snapshot volume.


# vxsnap -g freddg print
NAME    SNAPOBJECT    TYPE    PARENT    SNAPSHOT    %DIRTY    %VALID

fredvol  --           volume   --       --           --       100.00

        snapfredvol_snp1  volume   --       snapfredvol  0.02     --

snapfredvol fredvol_snp  volume   fredvol  --           0.02     0.03

 

Issue/Introduction

Veritas Volume Manager (VxVM) provides the capability for taking an image of a volume at a given point in time. Such an image is referred to as a volume snapshot.

Even though the contents of the original volume can change, the snapshot volume preserves the contents of the original volume as they existed at an earlier time.

VxVM 4.0 introduced full-sized instant snapshots & space-optimized instant snapshots, which offer advantages over traditional third-mirror snapshots. The FastResync feature (previously called Fast Mirror Resynchronization or FMR) performs quick & efficient resynchronization of stale mirrors (a mirror that is not synchronized).

FMR increases the efficiency of the Veritas Volume Manager (VxVM) snapshot performance & functionality. The VxVM snapshot feature enables VxVM to create an exact copy of a primary volume at an instant in time.
After a snapshot is taken, it can be accessed independently of the volume from which it was taken. NOTE: FastResync must be enabled on a volume before a snapshot is taken