8.8 VxFS Snapshots

     

Logically, a VxFS snapshot is the same idea as a VxVM snapshot in that they give us a freeze-frame view of our data so that we can perform online actions, such as backups , while users are accessing the data. Whereas with a VxVM snapshot, we could resynchronize the original volume from the snapshot ( reverse resync ), a VxFS filesystem is a read-only freeze frame of the current filesystem. There is no additional copy of the data made for a VxFS snapshot like in a VxVM snapshot; the snapshot occurs immediately, and access is immediate as well. Fundamentally, the concepts are the same, but the way they are implemented is quite different. Figure 8-6 gives us an idea of how a VxFS snapshot works.

  1. The snapshot is taken using the mount command. Both the user and the backup utility have the same view of all data blocks in the filesystem. The snapshot uses a (smaller) volume for storing original blocks should an update occur in the filesystem.

  2. The user makes a change to the online snapped filesystem. The update is blocked. The original blocks are copied to the temporary volume used by the snapshot. The user update is now written to the online snapped filesystem.

  3. The view of the filesystem seen by the backup utility will always be the view as seen at the time of the snapshot. When accessing a block that has been snapped, the block in the snapshot is accessed instead of the blocks in the original filesystem. This is completely transparent to the backup utility.

Figure 8-6. VxFS snapshot.
graphics/08fig06.jpg

One drawback of this scenario is that the snapshot is a read-only filesystem. Some backup utilities ( fbackup for one) will attempt to update inode timestamps as part of the backup process. If this will cause a backup utility to fail, then a VxFS snapshot is not the best solution for online backups.

Other things to consider before using VxFS snapshots:

  1. You should try to inactivate the application before taking the snapshot. It is important that the snapshot is a stable view of the data.

  2. Read performance of the snapped filesystem should not be affected. Write performance of the snapped filesystem will be affected the first time a change occurs to a block in the snapped filesystem. An initial update to the snapped filesystem will require the original blocks to be written to the snapshot. Subsequent writes to the same blocks are not affected. Some studies have shown that heavily used OLTP applications can see an overall downturn in performance of as much as 10-20 percent while a snapshot is active.

  3. Make sure that the snapshot is housed on physical disk other than the original filesystem to ensure that writes to the snapshot don't cause massive movements of read-write heads on the online disks.

  4. Performance of the snapshot will be affected if the snapped filesystem is busy because reads from the snapshot are coming from the online snapped filesystem.

  5. Try to take snapshots at quiet times of the day, when online activity is at it quietest.

  6. The size of the snapshot volume needs to accommodate as many changes as can occur in the filesystem during the time the snapshot is active. If every block in the online snapped filesystem changed the snapshot volume would have to be as big (plus approximately 1 percent of additional space for snapshot structural data) as the original volume. On average, a snapshot volume should be at least 15-20 percent the size of the original volume.

The process of taking a snapshot is relatively simple:

  1. Create a new volume to house the snapshot. You should create the snapshot volume on a different disk(s) than the online filesystem. The configuration of the snapshot volume is not restricted to a concatenated volume.

     

     root@hpeos003[]  lvcreate -L 500 -n snapdb /dev/vg00  Warning: rounding up logical volume size to extent boundary at size "504" MB. Logical volume "/dev/vg00/snapdb" has been successfully created with character device "/dev/vg00/rsnapdb". Logical volume "/dev/vg00/snapdb" has been successfully extended. Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf root@hpeos003[]    root@hpeos003[]  newfs -F vxfs /dev/vg00/rsnapdb  version 4 layout     516096 sectors, 516096 blocks of size 1024, log size 1024 blocks     unlimited inodes, largefiles not supported     516096 data blocks, 514880 free data blocks     16 allocation units of 32768 blocks, 32768 data blocks     last allocation unit has 24576 data blocks root@hpeos003[] 

  2. Use the mount command to take the snapshot.

     

     root@hpeos003[]  mount -o snapof=/db /dev/vg00/snapdb /snapdb  root@hpeos003[]  bdf  grep db  /dev/vx/dsk/ora1/dbvol                    10485760 2282920 7946508   22% /db /dev/vg00/snapdb   10485760 2282920 7946502   22% /snapdb root@hpeos003[] 

    As you can see, even though our snapshot volume is only 500MB, all reads through the snapshot are as if they were coming from the original snapped filesystem.

  3. Perform online backups.

    I will simply demonstrate that updates to the original snapped filesystem will not affect the view of the data in the snapshot:

     

     root@hpeos003[]  ll /db  total 4558980 -rw-rw-r--   1 root       sys        1073741824 Nov 14 14:42 db.finance -rw-rw-r--   1 root       sys        1260447712 Nov 14 12:43 db.finance2 drwxr-xr-x   2 root       root            96 Nov 14 11:09 lost+found root@hpeos003[]  ll /snapdb  total 4558980 -rw-rw-r--   1 root       sys        1073741824 Nov 14 14:42 db.finance -rw-rw-r--   1 root       sys        1260447712 Nov 14 12:43 db.finance2 drwxr-xr-x   2 root       root            96 Nov 14 11:09 lost+found root@hpeos003[]  cp /stand/vmunix /db  root@hpeos003[]  rm /db/db.finance2  /db/db.finance2: ? (y/n)  y  root@hpeos003[]  ll /db  total 2131504 -rw-rw-r--   1 root       sys        1073741824 Nov 14 14:42 db.finance drwxr-xr-x   2 root       root            96 Nov 14 11:09 lost+found -rwxr-xr-x   1 root       sys        17586896 Nov 15 12:09 vmunix root@hpeos003[]  ll /snapdb  total 4558980 -rw-rw-r--   1 root       sys        1073741824 Nov 14 14:42 db.finance -rw-rw-r--   1 root       sys        1260447712 Nov 14 12:43 db.finance2 drwxr-xr-x   2 root       root            96 Nov 14 11:09 lost+found root@hpeos003[] 

    Remember that updates to the snapshot are not allowed because it is a read-only filesystem:

     

     root@hpeos003[]  grep snap /etc/mnttab  /dev/vg00/snapdb /snapdb vxfs   ro   ,snapof=/dev/vx/dsk/ora1/dbvol,snapsize=516096 0 0 1068897785 root@hpeos003[]  >   /snapdb/testfile  sh[2]: /snapdb/testfile: Cannot create the specified file. root@hpeos003[] 

  4. Unmount the snapshot when backups have finished.

     

     root@hpeos003[]  umount /snapdb  root@hpeos003[]  bdf  grep db  /dev/vx/dsk/ora1/dbvol                    10485760 1069182 9122318   10% /db root@hpeos003[] 

    It is up to you what you do with the snapshot volume. If you decide to keep the volume for the next time you are going to perform a snapshot, remember to recreate the filesystem in the snapshot volume. The process of taking a snapshot has effectively corrupted the filesystem in the snapshot beyond all recognition:

     

     root@hpeos003[]  fstyp /dev/vg00/snapdb  unknown_fstyp (no matches) root@hpeos003[]  mount /dev/vg00/snapdb /snapdb  /dev/vg00/snapdb: unrecognized file system root@hpeos003[]  mount -o snapof=/db /dev/vg00/snapdb /snapdb  /dev/vg00/snapdb: unrecognized file system root@hpeos003[] 



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net