Off-host backup using VERITAS Volume Manager volume snapshot with disk group split/join or disk array-based mirroring will encounter problems if the original host and the backup server are running different versions of VERITAS File System (particularly File System 3.5 and 4.0).  

To enhance the performance and functionalities, substantial changes were made in VERITAS File System 4.0. Two major changes affect the operation of off-host backup.

1. Intent log format change
Intent log formats are different between File System 3.5 and File System 4.0 even if the disk layout version remains the same. That is, even if the disk layout version remains the same (such as version 5), File System 4.0 is not able to recognize the intent log written by File System 3.5 and vice versa.  This is a major obstacle for off-host backup if the original host and backup server are running different versions of File System.  Without unmounting the file system cleanly on the original host before performing the volume snapshot or disk array-based mirroring, it becomes impossible in this situation to replay the intent log, though that is mandatory to ensure the integrity of the file system data.  

Caution:
Replaying the intent log is paramount in ensuring the file system data integrity of the volume snapshot or disk array-based mirror.  If the volume snapshot or disk array-based mirror is mounted read-only without applying the intent log first,  or the file system is fixed by running full "fsck" with "nolog" option, the integrity of the file system data may be severely compromised.

2. Extended operation change
Extended operations are file operations that are delayed and performed by VERITAS File System at the background.  Due to the nature of the background processing, when the volume snapshot or disk array-based mirror is taken, these extended operations may remain on the file system. Extended operations are not handled by "fsck" and must be processed by the File System kernel driver when the file system is mounted.  But like the intent log, the File System 3.5 kernel driver is not able to recognize the extended operations generated by the File System 4.0 kernel driver and will not mount the file system successfully and vice versa. Therefore it is impossible to mount a file system in read-write mode on the backup server if the backup server is not running the same version of VERITAS File System even after the intent log is replayed.

The end result is that to perform off-host backup using a different version of VERITAS File System, the following has to be observed:
1. The intent log must be replayed (a solution is provided in the following section)
2. The file system can only be mounted read-only on the backup server


Replaying the intent log on the backup server which runs a different version of VERITAS File System than the original host
----------------------------------------------------------------------------------------------------------------------------------------------------
1. Obtaining the correct version of fsck to replay the intent log on the backup server

"fsck" is a standalone program and is independent of the File System kernel driver.  It can be executed without the presence of the File System kernel driver or if the host is running a different version of File System. However, "fsck" is OS version and word-width (32-bit and 64-bit) dependent.  Please extract the correct version of fsck from the original VERITAS File System package.

For VERITAS File System 3.5 MP2 (ftp://ftp.veritas.com/pub/products/fs.3.5MP2.sol.CD.tar.Z), the "fsck" programs are in the following directories in the tar archive:
file_system/patches/113204-10/VRTSvxfs/reloc/$ROOT_2.6/usr/lib/fs/vxfs/fsck
file_system/patches/113205-10/VRTSvxfs/reloc/$ROOT_2.7/usr/lib/fs/vxfs/fsck
file_system/patches/113206-10/VRTSvxfs/reloc/$ROOT_2.8/usr/lib/fs/vxfs/fsck
file_system/patches/113207-10/VRTSvxfs/reloc/$ROOT_2.9/usr/lib/fs/vxfs/fsck

The VERITAS File System 3.5 "fsck" program is not word-width dependent.

For VERITAS File System 4.0 (ftp://ftp.veritas.com/pub/products/fs.4.0.sol.tar.gz), the VRTSvxfs package is archived as a tar file itself,
fs.4.0.sol/file_system/pkgs/VRTSvxfs.tar.gz
The "fsck" programs are in the following directories of the above tar file:
VRTSvxfs/reloc/$ROOT_2.7/usr/lib/fs/vxfs/sparcv7/fsck
VRTSvxfs/reloc/$ROOT_2.7/usr/lib/fs/vxfs/sparcv9/fsck
VRTSvxfs/reloc/$ROOT_2.8/usr/lib/fs/vxfs/sparcv7/fsck
VRTSvxfs/reloc/$ROOT_2.8/usr/lib/fs/vxfs/sparcv9/fsck
VRTSvxfs/reloc/$ROOT_2.9/usr/lib/fs/vxfs/sparcv7/fsck
VRTSvxfs/reloc/$ROOT_2.9/usr/lib/fs/vxfs/sparcv9/fsck

Sparcv7 is for 32-bit OS and sparcv9 is for 64-bit OS.

Note that there is a dollar sign in $ROOT_2.x. Use single quotes or backslash to escape its special meaning from the shell when you try to copy it.

Extract the correct version of "fsck" from the above packages to the backup server. Note that the VERITAS File System version should be the one used by the original host. The OS version and word width are the ones used by the backup server.

For example, if the original host is running File System 4.0 and the backup server is running a 64-bit Solaris 9 OS and File System 3.5, extract the following "fsck" program from the File System package:
VRTSvxfs/reloc/$ROOT_2.9/usr/lib/fs/vxfs/sparcv9/fsck

Name the "fsck" program with the File System version and the OS version. For example, name the above "fsck" program as fsck40_sol9v9. Store the file separately from the VRTSvxfs installation directory to avoid confusion.  For example, it can be stored in /usr/local/bin.

If the original host is running the same version and word-width of Solaris, you can copy the "fsck" program directly from the original host. For File System 3.5, the "fsck" program is /usr/lib/fs/vxfs/fsck.  For File System 4.0, the "fsck" program is /usr/lib/fs/vxfs/sparcv7/fsck or /usr/lib/fs/vxfs/sparcv9/fsck.

2. Replaying the intent log before mounting the file system as read-only

Once the volume snapshot and disk array-based mirror is available on the backup server, run the correct version of "fsck" to replay the intent and mount the file system as read-only:

# /usr/local/bin/fsckXX_solXvX -F vxfs /dev/vx/rdsk/<diskgroup>/<volume>
# mount -F vxfs -o ro /dev/vx/rdsk/<diskgroup>/<volume> /<mountpoint>

For example:

# /usr/local/bin/fsck40_sol9v9 -F vxfs /dev/vx/rdsk/vvrjacdg/intentlog      
log replay in progress
replay complete - marking super-block as CLEAN

# mount -F vxfs -o ro /dev/vx/dsk/vvrjacdg/intentlog /intentlog

Now the file system can be backed up as normal. Note that the file system cannot be mounted in read-write mode due to the change in Extended Operations as described above.

Other suggestions
---------------------------
If VERITAS Volume Manager (tm)  volume snapshot is used, perform the following procedure on the original host before splitting the disk group:

- mount the file system under a different directory
- unmount the file system

This will clear the Extended Operations.  (The intent log is flushed automatically when VxVM volume snapshot is generated.)

If disk array-based mirroring is used, after the mirror is split, try to find an intermediary system running the same version of VERITAS File System as the original host to perform the following procedure before accessing the mirror from the backup server:

- run "fsck" on the snapshot volume to replay the intent log
- mount the file system
- unmount the file system

This will clear both the intent log and the Extended Operations.

Refer to TechNote 265504 for details