PRIMECLUSTER Global File Services Configuration and Administration Guide 4.2 (Solaris(TM) Operating Environment)

24.5.3 Set up after Restoration

24.5.3.1 Resetting the partition information

It is necessary to change management information only when restoring it to a partition different from the backup because it enters the state with different partition information in the medium by the following procedures. It is not necessary to work because there is no change in partition information in the medium when restoring it to quite the same partition as the backup.

By the following ways, if the GFS Shared File System is restored to a partition that is different from a backup, it is necessary to change management information because partition information is not corresponding to an actual partition composition.

• Restoring to a partition that differs from the backup source with the dd(1) command
• Snapshot created with the snapshot function or other than GDS

Use the sfcadm(1M) command to reset the partition information.

If the GFS Shared File System is restored to a partition that is different from a backup, it differs according to the procedure of restoration is whether the partition at the restoration destination is GFS Shared File System. Each procedure is shown as follows.

• The following shows how to reset the partition information with sfcadm(1M) after you have restored the three-volume GFS Shared File System to another partition (/dev/sfdsk/gfs/rdsk/vol0301, /dev/sfdsk/gfs/rdsk/vol0400, /dev/sfdsk/gfs/rdsk/vol0500) that is different from the creation source. Note that the representative partition is /dev/sfdsk/gfs/rdsk/vol301 and that the shared nodes are host0001, host0002, host0003.

# sfcadm -m host0001,host0002,host0003 -g host0001,host0002 /dev/sfdsk/gfs/rdsk/vol0301,/dev/sfdsk/gfs/rdsk/vol0400,/dev/sfdsk/gfs/rdsk/vol0500

• The following shows how to reset the partition information with sfcadm(1M) after you have restored the three-volume GFS Shared File System to another partition (/dev/sfdsk/gfs/rdsk/vol0301, /dev/sfdsk/gfs/rdsk/vol0400, /dev/sfdsk/gfs/rdsk/vol0500) that has not changed the configuration from the creation source. Note that the representative partition is /dev/sfdsk/gfs/rdsk/vol301 and that the shared nodes are host0001, host0002, host0003.

# sfcadm /dev/sfdsk/gfs/rdsk/vol0301

Note that the state of the file system creation for the restoration destination can be confirmed with sfcinfo(1M).

For details on sfcinfo(1M), see Appendix F.2.11, "sfcinfo(1M)."

For details on sfcadm(1M), see Appendix F.2.2, "sfcadm(1M)."

24.5.3.2 Repairing the file system

If you attempt to back up file systems that are mounted in units of file systems, a file access may occur while backup is being performed, such that an inconsistency occurs in the backup content.

To repair this state, the administrator must execute a file system consistency check and perform a repair with fsck_sfcfs(1M). If no inconsistency occurs, fsck_sfcfs(1M) will be completed in several seconds to one minute.

An example of file system repair is shown below. The representative partition is /dev/sfdsk/gfs/rdsk/vol0301. Execute the repair after confirming that nothing is mounted.

# fsck -F sfcfs -y work=/dev/rdsk/c2t3d0s1 /dev/sfdsk/gfs/rdsk/vol0301

For details on fsck_sfcfs(1M), see Appendix F.1.2, "fsck_sfcfs(1M)."