| Oracle® Hierarchical Storage Manager and StorageTek QFS Software File System Recovery Guide Release 6.0 E42065-03 |
|
 Previous |
 Next |
| Oracle® Hierarchical Storage Manager and StorageTek QFS Software File System Recovery Guide Release 6.0 E42065-03 |
|
Previous |
Next |
This chapter outlines procedures for restoring individual files to the file system. It covers the following topics:
A recovery point file is the fastest, most reliable, most thorough, and least labor-intensive way of recovering lost or damaged files. So, if a recovery point file is available, proceed as follows:
Log in to the file-system metadata server as root.
root@solaris:~#
If you have not already done so, stop archiving and recycling using the procedures in "Stopping Archiving and Recycling Processes"
In the target file system, create a temporary recovery directory to hold the recovered files.
In the example, we create the temporary directory restore under the mount point for the recreated file system, /samqfs1:
root@solaris:~#mkdir/samqfs1/restore
Keep the archiver from archiving from the temporary directory. Use the command archive -r -n directory, where:
-r -n recursively disable archiving of files that reside in or under the specified directory.
directory is the path and directory name of the temporary recovery directory.
root@solaris:~#archive-r-n/samqfs1/restore
Change to the temporary recovery directory.
root@solaris:~#cd/samqfs1/restore
Identify the most recent available recovery point file.
In the example, we have been creating dated recovery point files for the file system samqfs1 in a well-known location, the subdirectory samqfs1_recovery on the independent file system /zfs1. So the latest file, 20150324, is easy to find:
root@solaris:~#dir/zfs1/samqfs1_recovery/20150321 20150322 20150323 20150324 root@solaris:~#
Make sure that the file that you need to recover is in the recovery point file. Search for the required file in the output of the command samfsrestore -t -f recovery-point, where:
-t displays a table of contents.
-f recovery-point-file specifies the path and file name of the selected recovery point file.
In the example, we are trying to recover the file genw445. So we run the command samfsrestore -t with the recovery point file /zfs1/samqfs1_recovery/20150324. To simplify the search, we pipe the output of samfsrestore -t to the Solaris grep command and the regular expression "genw445" (note that the command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#samfsrestore-t-f/zfs1/samqfs1_recovery/20150324|\grep"genw445"./genfiles/genw445 root@solaris:~#
Restore the file's inode information to the current directory. Use the command samfsrestore -f recovery-point file, where:
-f recovery-point-file specifies the path and file name of the selected recovery point file.
file specifies the exact path and name that the recovery point file lists for the file that you want to recover.
In the example, we recover ./genfiles/genw445 from the recovery point file /zfs1/samqfs1_recovery/20150324 (note that the command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#samfsrestore-f/zfs1/samqfs1_recovery/20150324\./genfiles/genw445root@solaris:~#
Make sure that the file has been restored correctly. Use the command sls -D file, where file specifies the path and name of the file relative to the temporary recovery directory.
In the example, the file genfiles/genw445 has been recovered to the temporary directory /samqfs1/restore/:
root@solaris:~#sls-Dgenfiles/genw445genfiles/genw445: mode: -rw-r--r-- links: 1 owner: data group: samqfs1 length: 14975 inode: 25739.1 offline; archdone; copy 1: ---- Mar 4 11:55 8ae.1 xt 000000 copy 2: ---- Mar 4 15:51 cd3.7f57 xt 000000 access: Mar 4 11:55 modification: Mar 4 21:50 changed: Mar 4 11:50 attributes: Mar 4 21:50 creation: Mar 4 11:50 residence: Mar 4 21:50 root@solaris:~#
If the file has been correctly restored, move it to the correct location in the file system.
In the example, we move the file genw445 from the temporary, working directory /samqfs1/restore/genfiles/ to its original location in /samqfs1/genfiles/:
root@solaris:~#mv-fgenfiles/genw445/samqfs1/genfiles/genw445root@solaris:~#
Repeat this procedure until all missing files have been recovered.
Finish the recovery procedure. Go to "Restoring Archiving File Systems to Normal Operation".
Recovering files with an archive log is always a tedious and labor-intensive process, if more than a few files are involved. So, whenever possible, use the procedures in this section only when a recovery point cannot restore the file that you need.
While the overall process for recovering files from archival media is essentially the same in all cases, details can differ for different types of file. So select the procedure intended for the type of file that you are restoring:
Note that files may not be restored to the precise location that you expect when you recover a copy from the media. Files are restored to their location at the time when the archive copy was made. So files that were subsequently moved are not restored to the directory where they were when they were lost.
For each file that you need to recover, proceed as follows:
If you have not already done so, log in to the file-system metadata server as root.
root@solaris:~#
If you have not already done so, stop archiving and recycling using the procedures in "Stopping Archiving and Recycling Processes"
Change to the root directory of the file system that you are restoring.
Oracle HSM archive files store copies relative to the file-system root directory. So to restore them to their original locations, we want to restore them from the root directory.
In the example, we change to the root of the samqfs1 file system:
root@solaris:~#cd/samqfs1root@solaris:~#
If you have an archiver log for the period when the regular file was last archived, find the most recent entry for the file.
In the first example, we look for an entry for the regular (type f) file genA0:
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 samqfs1 1535.2 1971 genfiles/genA0f0 0
In the second example, we look for an entry for the regular (type f) file spcC4:
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 samqfs1 1511.2 8971 socfiles/spcC4f0 0
Once you have located a log entry for a required file, note the media type, the volume serial number of the media, and the path and name of the file relative to the root directory of the file system.
In the first example, the file genA0 resides on an LTO (li) tape volume with the Volume Serial Number (VSN) VOL004. The file was originally stored in the file system directory /samqfs1/genfiles/:
A 2015/03/03 13:09:05liVOL004all.1 212.1 samqfs1 1535.2 1971genfiles/genA0 f 0 0
In the second example, the file spcC4 resides in a disk archive (dk) with the volume serial number DISKVOL1. The file was originally stored in the file system directory /samqfs1/socfiles/:
A 2015/03/03 21:49:15dkDISKVOL1/f2 all.1 2.2e9 samqfs1 1511.2 8971socfiles/spcC4 f 0 0
If a required file resides on sequential-access media, such as magnetic tape, also note the hexadecimal value that represents the starting position of the archive (tar) file.
In the example, file genA0 resides on tape starting at position 0x212 (212):
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 samqfs1 1535.2 1971 genfiles/genA0 f 0 0
If a required file resides on random-access media, such as archival disk, also note the path and file name of the tar file relative to the volume serial number.
In the example, file spcC4 resides in the f2 subdirectory immediately under the root directory of disk volume DISKVOL1:
A 2015/03/03 21:49:15 dk DISKVOL1/f2all.1 2.2e9 samqfs1 1511.2 8971 socfiles/spcC4 f 0 0
If the file that you are restoring is archived on disk media, extract the archive copy of the missing or damaged file from the tar file on the disk volume. Use the command star -xv -f tarfile file, where:
tarfile is the name of the archive file
file is the path—relative to the file-system root directory—and name of the file that you need to restore.
The star command is an enhanced Oracle HSM version of GNU tar that restores specified files from the archive file.
In the example, we extract the data file socfiles/spcC4 from the tar file DISKVOL1/f2. The file is restored to /samqfs1/socfiles/spcC4:
root@solaris:~#star-xvfDISKVOL1/f2socfiles/spcC4
If you have restored the required file from a disk archive, continue to Restore Lost and Damaged Regular Files until all required files have been restored.
If the file that you are restoring is archived on removable media, such as magnetic tape, create a directory in the restored file system to hold temporary archive files.
In the example, we create the directory /samqfs1/tars
root@solaris:~#mkdir/samqfs1/tars
Position the media at the beginning of the tar header for the archive file that holds the archived copy, and read the archive from the media into memory. Use the command request -m media-type -v volume-serial-number -p 0xposition path/requestfile, where:
-m media-type species one of the two-character media type codes listed in Appendix B.
-v volume-serial-number specifies the six-character, alphanumeric code that identifies the media volume.
-p 0xposition specifies the hexadecimal starting position that you noted in the archiver log entry.
path is the path to the temporary recovery directory.
requestfile is the name that you want to use for the in-memory tar file that the request command reads from the media.
In the example, we create a request file, /samqfs1/tars/currentrequest starting from position 0x78 on LTO (li) volume VOL012:
root@solaris:~#request-mli-vVOL012-p0x78/samqfs1/tars/currentrequest
Extract the archive copy of the missing or damaged file from the in-memory tar file that you created in the preceding step. Use the command star -xv -f requestfile, where:
requestfile is the name of the in-memory tar file.
file is the path—relative to the file-system root directory—and name of the file that you need to restore.
The star command is an enhanced Oracle HSM version of GNU tar that restores specified files from the request file (the in-memory copy of the archive file).
In the example, we extract the data file genfiles/genA0 from the request file tars/currentrequest. The file is restored to /samqfs1/genfiles/genA0:
root@solaris:~#star-xvftars/currentrequestgenfiles/genA0
Set any required file attributes.
When you restore a file from a tar file, without a samfsdump or qfsdump recovery point file, the original file attributes are lost. An .inodes file has to be created for the file from scratch, using default attribute values.
Repeat this procedure. Restore Lost and Damaged Regular Files until all required files have been recovered.
If necessary, Restore Lost and Damaged Segmented Files or Restore Lost and Damaged Volume Overflow Files.
Otherwise, finish the recovery procedure. Go to "Restoring Archiving File Systems to Normal Operation".
Restoring a segmented file is much like restoring a regular file. However, you recover the individual segments rather than the file itself. So, to restore the file, you must reassemble the segments into a single file and then re-segment the result. For each file that you need to recover, proceed as follows:
If you have not already done so, log in to the file-system metadata server as root.
root@solaris:~#
If you have not already done so, stop archiving and recycling using the procedure in "Stopping Archiving and Recycling Processes"
If you have an archiver log for the period when the segmented file was last archived, search the entries for segmented (type S) files. Select the most recent entries for segments of the required file.
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 samqfs1 14.5 10485760 bf/dat011/1S0 51 A 2015/03/03 14:04:11 li VOL013 all.1 2476f.5002 samqfs1 15.5 10485760 bf/dat011/2S0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 samqfs1 16.5 184 bf/dat011/3S0 51
Once you have located the latest entries for the segments, note the following details:
the media type
the volume serial numbers of the media volumes that store file segments
the hexadecimal starting positions of the archive (tar) files that hold the segments
the path and name of the segmented file relative to the root directory of the file system
the number of segments in the file.
In the example, the file dat011 is divided into three segments (1, 2, and 3). The three segments are stored in three archive files, all on a single LTO (li) tape volume, volume serial number VOL013. The three archive files start at positions 0x76a (76a), 0x2476f (2476f), and 0x1409aa4 (1409aa4)
A 2015/03/03 14:01:47liVOL013all.176a.1 samqfs1 14.5 10485760bf/dat011/1S0 51 A 2015/03/03 14:04:11liVOL013all.12476f.5002 samqfs1 15.5 10485760bf/dat011/2S0 51 A 2015/03/03 14:06:24liVOL013all.11409aa4.1 samqfs1 16.5 184bf/dat011/3S0 51
Change to the root directory of the file system that you are restoring.
Oracle HSM archive files store copies relative to the file-system root directory. So to restore them to their original locations, we want to restore them from the root directory.
In the example, we change to the root of the samqfs1 file system.
root@solaris:~#cd/samqfs1
Create a directory in the restored file system to hold temporary archive files.
In the example, we create the directory /samqfs1/tars
root@solaris:~#mkdir/samqfs1/tars
Position the media at beginning of each archive file that holds an archived copy of one or more of the file segments, and read the archive from the media into memory. Use the command request -m media-type -v volume-serial-number -p 0xposition path/requestfile, where:
-m media-type specifies one of the two-character media type codes listed in Appendix B.
-v volume-serial-number specifies the six-character alphanumeric code that identifies the media volume.
-p 0xposition specifies the hexadecimal starting position that you noted in the archiver log entry.
path is the path to the temporary recovery directory.
requestfile is the name that you want to use for the in-memory tar file that the request command reads from the media.
In the example, we need to create two request files. The first, /samqfs1/tars/request76a, loads the archive file that starts at position 0x76a on LTO (li) VOL013. This archive contains both of the first two segments. The second request file, /samqfs1/tars/request1409aa4, loads the archive file at position 0x1409aa4, in this case on the same volume (segments can reside on any volume in the library):
root@solaris:~#request-mli-vVOL013-p0x76a/samqfs1/tars/request76aroot@solaris:~#request-mli-vVOL013-p0x1409aa4\/samqfs1/tars/request1409aa4
Extract each segment of the backup copy of the missing or damaged file from the in-memory tar file that you created in the preceding step. Use the command star -xv -f requestfile segment, where requestfile is the name of the in-memory tar file and segment is the path—relative to the file-system root directory—and name of each segment of the file that you need to restore.
The star command is an enhanced Oracle HSM version of GNU tar that restores specified files from the archive file that you are pointing to with the request file.
In the example, we extract two of the three segments of the data file bf/dat011 from the request file (in-memory tar files) tars/request76a and one from the request file tars/request1409aa4. The file is restored to a directory, /samqfs1/bf/dat011/, in three separate pieces:
root@solaris:~#star-xvftars/request76abf/dat011/1root@solaris:~#star-xvftars/request76abf/dat011/2root@solaris:~#star-xvftars/request1409aa4bf/dat011/3
When we list the contents of /samqfs1/bf/dat011, we see one sequentially numbered file for each restored segment:
root@solaris:~#ls /samqfs/bf/dat011total 40968 -rw-rw---- 1 root other 10485760 Mar 5 17:061-rw-rw---- 1 root other 10485760 Mar 5 17:062-rw-rw---- 1 root other 184 Mar 5 17:073root@solaris:~#
Re-assemble the restored segments into a single, unsegmented, temporary file.
In the example, we concatenate the three segments in the /samqfs1/bf/dat011/ directory to create the file /samqfs1/bf/dat011file:
root@solaris:~#cat/samqfs/bf/dat011/1/samqfs/bf/dat011/2\/samqfs/bf/dat011/3>/samqfs/bf/dat011fileroot@solaris:~#
When we list the contents of /samqfs1/bf/, the new file appears alongside the directory containing the segments.
root@solaris:~#ls -l/samqfs/bf/dat011*drwxr-xr-x 2 root root 4096 Mar 5 17:06 dat011 -rw-rw---- 1 root other 20971704 Mar 5 17:14 dat011file root@solaris:~#
Remove the segments and the directory that contains them.
root@solaris:~#rm -r/samqfs/bf/dat011/root@solaris:~#
Create an empty file using the original path and name of the segmented file. Use the command touch file, where file is the original path and file name.
In the example, we create the empty file /samqfs/bf/dat011, the original name of the segmented file that we are restoring:
root@solaris:~#touch/samqfs/bf/dat011root@solaris:~#
Set the Oracle HSM segment attribute on the newly created, empty file. Use the command segment -l segment-length file, where segment-length is the segment length that you noted in the archiver log entry and file is the original path and name of the segmented file.
In the example, the archiver log shows that the segment length for the file dat011 is 10485760 (the file ends in the third segment, so the length of the data on the media is less than the segment length):
A2015/03/03 14:01:47liVOL013all.176a.1 samqfs1 14.510485760bf/dat011/1S0 51A2015/03/03 14:04:11liVOL013all.176a.5002 samqfs1 15.510485760bf/dat011/2S0 51A2015/03/03 14:06:24liVOL013all.11409aa4.1 samqfs1 16.5184bf/dat011/3 S 0 51
So we set the segment length for the empty file to 10485760:
root@solaris:~#segment-l10485760/samqfs/bf/dat011root@solaris:~#
Copy the unsegmented temporary file to the empty segmented file.
In the example, we copy dat011file to dat011:
root@solaris:~#cp/samqfs/bf/dat011file/samqfs/bf/dat011root@solaris:~#
When we use the command sls -2K samqfs/bf/dat011 to list the segments, they are listed as shown. So the file has been restored.
root@solaris:~#sls -2K/samqfs/bf/dat011-rw-rw---- 1 root other 20971704 Mar 5 17:12samqfs/bf/dat011---------- ----- sI {3,0,0,0} -rw-rw---- 1 root other10485760Mar 5 17:12samqfs/bf/dat011/1---------- ----- sS -rw-rw---- 1 root other10485760Mar 5 17:12samqfs/bf/dat011/2---------- ----- sS -rw-rw---- 1 root other184Mar 5 17:12samqfs/bf/dat011/3---------- ----- sS
Set any other required file attributes.
When you restore a file from a tar file, without a samfsdump or qfsdump recovery point file, the original file attributes are lost. An .inodes file has to be created for the file from scratch, using default attribute values.
The file has now been restored. Delete the unsegmented temporary file.
In the example, we delete dat011file:
root@solaris:~#rm/samqfs/bf/dat011fileroot@solaris:~#
Repeat this procedure until all required files have been recovered.
Finish the recovery procedure. Go to "Restoring Archiving File Systems to Normal Operation".
A volume overflow file is a regular file that spans media volumes. Restoring a volume overflow file is thus much like restoring any other regular file. However, you must combine sections of an archive file that resides on multiple volumes into a single archive file on disk before you extract the data file from the archive. So, for each file that you need to recover, proceed as follows:
If you have not already done so, log in to the file-system metadata server as root.
root@solaris:~#
If you have not already done so, stop archiving and recycling using the procedure in "Stopping Archiving and Recycling Processes"
If you have an archiver log for the period when the volume overflow file was last archived, find the most recent entry for the file. Note the volume serial number(s) of the media, the length of each section of the file, the path and name of the file relative to the root directory of the file system, and the number of sections in the file.
In the example, we know that the file /samqfs1/rf/rf81 is a volume overflow because it is a regular, type f file that resides on two volumes, VOL036 and VOL034, and has two sections, 0 and 1:
A 2015/03/03 18:28:51 liVOL036all.1 12d.1 samqfs1 11731.189128448rf/rf81f0210 A 2013/08/23 18:28:51 liVOL034all.1 15f.0 samqfs1 11731.1525271552rf/rf81f1220
Change to the root directory of the file system that you are restoring.
Oracle HSM archive files store copies relative to the file-system root directory. So to restore them to their original locations, we want to restore from to the root directory.
In the example, we change to the root of the samqfs1 file system.
root@solaris:~#cd/samqfs1
Before proceeding, make sure that the file system contains enough free space accommodate a file at least twice the size of the file that you are recovering.
For the file in the example, rf/rf81, we will need about 1.2 gigabytes of free space, based on the sizes of the two sections of the file: 2 x (89128448 + 525271552) = 1228800000 bytes.
Create a directory in the restored file system to hold temporary archive files.
In the example, we create the directory /samqfs1/tars
root@solaris:~#mkdir/samqfs1/tars
Position the media at beginning of each archive file that holds an archived copy of one or more of the file segments, and read the archive from the media into memory. Use the command request -m media-type -v volume-serial-number -p 0xposition path/requestfile, where:
-m media-type specifies one of the two-character media type codes listed in Appendix B.
-v volume-serial-number specifies the six-character alphanumeric code that identifies the media volume.
-p 0xposition is the hexadecimal starting position that you noted in the archiver log entry.
path is the path to the temporary recovery directory.
requestfile is the name that you want to use for the in-memory tar file that the request command reads from the media.
In the example, we create two request files. The first request file, /samqfs1/tars/requestVOL036, loads the archive file that starts at position 0x12d on LTO (li) VOL036. The second request file, /samqfs1/tars/requestVOL034, loads the archive file at position 0x15f on LTO (li) VOL034:
root@solaris:~#request-mli-vVOL036-p0x12d/samqfs1/tars/requestVOL036root@solaris:~#request-mli-vVOL034-p0x15f/samqfs1/tars/requestVOL034
Save each of the in-memory tar files that you created to disk as a section of the archive file. Use the command dd if= requestfile of=archive_section, where requestfile is the path and name of the in-memory tar file and archive_section is the path and name of each section of the archive file.
In the example, we save the request files (in-memory tar files), tars/requestVOL036 and tars/requestVOL034 as tars/archive_part1 and tars/archive_part2:
root@solaris:~#ddif=tars/requestVOL036of=tars/archive_part1root@solaris:~#ddif=tars/requestVOL034of=tars/archive_part2root@solaris:~#
Re-assemble the sections into a single archive file.
In the example, we concatenate the two sections, tars/archive_part1 and tars/archive_part2, to create a single archive file, /tars/archive_complete:
root@solaris:~#cattars/archive_part1tars/archive_part2>\tars/archive_completeroot@solaris:~#
Extract the backup copy of the missing or damaged volume overflow file from the archive (tar) file that you created in the preceding step. Use the command star -xv -f tarfile file, where tarfile is the name of the archive file and file is the path—relative to the file-system root directory—and name of the volume overflow file that you need to restore.
The star command is an enhanced Oracle HSM version of GNU tar that restores specified files from the archive file that you are pointing to with the request file.
In the example, we extract the volume overflow file rf/rf81 from the tar file tars/archive_complete:
root@solaris:~#star-xvftars/archive_completerf/rf81
Set any other required file attributes.
When you restore a file from a tar file, without a samfsdump or qfsdump recovery point file, the original file attributes are lost. An .inodes file has to be created for the file from scratch, using default attribute values.
The volume overflow file has now been restored. Delete the temporary file.
In the example, we delete dat011file:
root@solaris:~#rmtars/archive_*root@solaris:~#
Repeat this procedure until all required files have been recovered.
Finish the recovery procedure. Go to "Restoring Archiving File Systems to Normal Operation".
A damaged archive copy is a copy of a file that cannot be staged back to the disk cache. Sometimes, the file has merely failed to stage due to an intermittent, hardware-related I/O problem and can be easily resolved. At other times, the damaged copy is corrupt and the data is irrecoverable. Your only option in such cases is to recover the file from an alternate copy.
To identify and manage damaged copies, proceed as follows:
Identify files that have damaged archive copies. Use the command sfind mountpoint -any_copy_d, where mountpoint is the directory where the recovered file system is mounted.
In the example, we start the search in the directory /samqfs1 and find three files that have damaged copies:
root@solaris:~#sfind/samqfs1-any_copy_d./genfiles/ab09 ./genfiles/ab11 ./genfiles/ay12 root@solaris:~#
For each file that you identified, identify the damaged copies. Use the command sls -D file, where file is the path and file name that you want to check.
Damaged copies are flagged with a D. In the example, copy 2 of /samqfs1/genfiles/ab09 and copy 1 of /samqfs1/genfiles/ab11 are damaged:
root@solaris:~#sls -D/samqfs1/genfiles/ab09/samqfs1/genfiles/ab09: mode: -rw-r----- links: 1 owner: root group: other length: 306581 admin id: 0 inode: 11748.11 project: system(0) copy 1: ---- Mar 11 13:52 76f.421bc li VOL011copy 2: ---DMar 31 14:02 286.1324f li VOL021 access: Mar 11 13:50 modification: Mar 11 13:50 changed: Mar 11 13:50 attributes: Mar 11 13:50 creation: Mar 11 13:50 residence: Mar 11 13:50 root@solaris:~#sls -D/samqfs1/genfiles/ab11/samqfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0 inode: 1460.1 project: system(0)copy 1: ---DMar 01 10:21 431.21bc6 li VOL024 access: Mar 01 10:21 modification: Mar 01 10:21 changed: Mar 01 10:21 attributes: Mar 01 10:21 creation: Mar 01 10:21 residence: Mar 01 10:21 root@solaris:~#
If there is an alternate copy, unarchive the damaged copy. Use the command unarchive -c CopyNumber file, where CopyNumber is an integer representing the copy number and file is the path and file name of the damaged file. Stop here.
When you unarchive the damaged copy, Oracle HSM stages from the remaining copy and creates an additional archive copy the next time that the archiver process runs. In the example, we have another, undamaged copy of /samqfs1/genfiles/ab09, so we unarchive the damaged copy, copy 2:
root@solaris:~#unarchive-c2/samqfs1/genfiles/ab09root@solaris:~#
If you do not have another copy, undamage the damaged copy. Use the command undamage -cCopyNumber file, where CopyNumber is an integer representing the copy number and file is the path and file name of the damaged file.
Sometimes a file fails to stage due to an intermittent, hardware-related I/O error. Clearing the damage flag and restaging may solve the problem. In the example, there is only one copy of /samqfs1/genfiles/ab11:
root@solaris:~#undamage-c1/samqfs1/genfiles/ab11
Try to stage the copy. Use the command stage -c CopyNumber -I file, where CopyNumber is an integer representing the copy number and file is the path and file name of the file.
The optional -I (immediate) parameter pushes the staging operation to the head of the queue:
root@solaris:~#stage-c1-I/samqfs1/genfiles/ab11
If staging succeeds, stop here.
If staging failed again, Oracle HSM again sets the damaged flag. Note the major inode number in the output of the sls -D command for the damaged copy.
In the example, the inode number of the file, /samqfs1/genfiles/ab11, is 1460:
root@solaris:~#sls -D/samqfs1/genfiles/ab11/samqfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0inode:1460.1 project: system(0) copy 1: ---D Mar 01 10:21 431.21bc6 li VOL024 ... root@solaris:~#
Look for possible causes. First, examine the Oracle HSM /var/adm/sam-log file for staging related messages that pertain to the inode of the file with the damaged copy.
The search can be carried out in various ways. In the example, we list the contents of log file using the Solaris cat command and pipe the output to grep and a regular expression that matches the inode number. We find two messages. Both indicate an I/O error and one explicitly implicates equipment (eq) ordinal number 804, one of our tape drives:
root@solaris:~#cat/var/adm/sam-log|grep "inode 1460"Mar 11 15:35:44 server1 genu-20[8899]: Stage request canceled for inode1460(eq804): I/O error. Jan 11 15:35:44 server1 samfs[8894]: /sam4 inode1460.1 - Archive copy 1 marked damaged: I/O error
If the /var/adm/sam-log file implicates a specific Oracle HSM equipment ordinal number, examine the device log, /var/opt/SUNWsamfs/devlog/drive-equipment-number, where drive-equipment-number is the ordinal number listed in the /var/adm/sam-log file.
If the problem appears to be specific to a particular drive, make the implicated drive unavailable to the staging process using the command samcmd unavail drive-equipment-number. Then undamage the copy, and try to stage it again.
root@solaris:~#samcmdunavail804root@solaris:~#stage-c1-I/samqfs1/genfiles/ab11root@solaris:~#undamage-c1/samqfs1/genfiles/ab11root@solaris:~#
If staging fails again or if no single drive appears to be at fault, try to recover the copy using the request and star commands, as described in "Recovering Files Using Archiver Log Entries", or Solaris utilities such as tar and dd.
If you still cannot recover the file and if the value of the data warrants it, engage a data recovery service. For assistance with Oracle StorageTek tape media, engage Oracle StorageTek Enterprise Tape Data Recovery services. Log in to My Oracle Support at support.oracle.com. Open a Service Request, select the tape drive model from the list under the request category, and select Media Issues from the list under subcategory.
If the file proves to be irrecoverable, unarchive the damaged copy. Use the command unarchive -c CopyNumber file, where CopyNumber is an integer representing the copy number and file is the path and file name of the damaged file.
root@solaris:~#unarchive-c1/samqfs1/genfiles/ab11root@solaris:~#
Resolve any drive or media issues that are revealed by the log files.
If you disabled archiving, staging, and recycling processes in a previous step, re-enable them now. Go to "Restoring Archiving File Systems to Normal Operation".
Otherwise, stop here.
