Windows Knowledge Base

[EMC Clariion]Why is running FSCK &CHKDSK required when creating a SnapView clone?

When a clone of a file system (UNIX or Windows) is created, the file system will be "dirty" unless it was unmounted at the time the clone was added to the Clone Group. In order to use the clone it will be necessary to "clean" the "dirty" file system by using CHKDSK (for Windows) and FSCK (for UNIX), and if necessary, create  the mount point.  See "Using Clones" in  EMC SnapView for Navisphere Administrator's Guide (P/N 069001180) on Powerlink for more information.

The following example shows steps for cloning an Oracle database in a Windows environment and describes the reasons for performing the steps:
Note: The procedure applies to some UNIX environments (with FSCK used instead of CHKDSK).

1. Start synchronizing.
2. Begin the Oracle online backup. <== The clone will be "consistent", but never "synchronized."
3. Fracture the clone.                     <== Unless the clone is "synchronized," the integrity of the clone cannot be guaranteed.
4. End the Oracle online backup.
5. On the backup server activate the clone.
6. On the backup server perform CHDSK for clone. <== CHDSK  is necessary because Windows has determined that the disk is not clean at this point.
7. Flush the clone.
8. Deactivate the clone
9. Reboot the backup server.
Note for Step 2:  According to the EMC SnapView of Navisphere Administrator's Guide (P/N 0690011180) on Powerlink: "When a source LUN receives a server write request, the clone transitions into a Consistent state because the clone is no longer a byte-for-byte copy of its source."
CHKDSK returns messages like the following when run on a clone:

According to an Oracle Technical Paper that describes how to use SnapView to facilitate backing up an Oracle database:
If the source LU includes files and directories which are not part of the Oracle database, activity in those files, while we are trying to snap the LU and capture the Oracle files, may still create a subsequent SNAP LU file system mounting problem. For that reason, it is probably a good idea to avoid having unrelated files on that file system.

However, if that is not operationally convenient, another option is to perform a file system check before mounting the SNAP LU, and allowing FSCK to "fix" the file system for mounting. Unless there are extensive file system structure changes, such as adding and deleting files and subdirectories, on that LU, FSCK (or CHKDSK under Windows/NT) generally will not lose sectors on the "device" holding the relevant Oracle files.