本章概述了将单个文件恢复至文件系统的过程。本章涵盖以下主题：
在恢复丢失的或损坏的文件时，恢复点文件是最快速、最可靠、最彻底也最省力的方法。因此，如果可以使用恢复点文件，请继续如下操作：
以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果您尚未停止归档和回收，请使用停止归档和回收过程中介绍的过程停止归档和回收
在目标文件系统中，创建一个临时恢复目录以容纳所恢复的文件。
在本示例中，我们在重新创建的文件系统的挂载点 /hsmfs1 下创建临时目录 restore：
root@solaris:~# mkdir /hsmfs1/restore
防止归档程序从临时目录中进行归档。使用命令 archive -r -n directory，其中：
-r -n 递归禁用位于指定目录之中或之下的文件归档。
directory 是临时恢复目录的路径和目录名称。
root@solaris:~# archive -r -n /hsmfs1/restore
转到临时恢复目录。
root@solaris:~# cd /hsmfs1/restore
标识最新的可用恢复点文件。
在本示例中，我们在已知位置（即独立文件系统 /zfs1 中的子目录 hsmfs1_recovery）为文件系统 hsmfs1 创建了标注日期的恢复点文件。因此可轻松找到最新文件 20150324：
root@solaris:~# dir /zfs1/hsmfs1_recovery/ 20150321 20150322 20150323 20150324 root@solaris:~#
请确保您需要恢复的文件位于恢复点文件中。在命令 samfsrestore -t -f recovery-point 的输出搜索所需的文件，其中：
-t 显示目录。
-f recovery-point-file 会指定选定恢复点文件的路径和文件名称。
在本示例中，我们尝试恢复文件 genw445。因此，我们使用恢复点文件 /zfs1/hsmfs1_recovery/20150324 运行命令 samfsrestore -t。为了简化搜索，我们将 samfsrestore -t 的输出通过管道传输至 Solaris grep 命令和正则表达式 "genw445"（请注意，下面的命令是作为单行输入的－使用反斜杠字符对换行符进行转义）：
root@solaris:~# samfsrestore -t -f /zfs1/hsmfs1_recovery/20150324 | \ grep "genw445" ./genfiles/genw445 root@solaris:~#
将文件的 inode 信息恢复至当前目录。使用命令 samfsrestore -f recovery-point file，其中：
-f recovery-point-file 会指定选定恢复点文件的路径和文件名称。
file 指定恢复点文件针对您要恢复的文件所列出的精确路径和名称。
在本示例中，我们从恢复点文件 /zfs1/hsmfs1_recovery/20150324 恢复 ./genfiles/genw445（请注意，下面的命令是作为单行输入的－使用反斜杠字符对换行符进行转义）：
root@solaris:~# samfsrestore -f /zfs1/hsmfs1_recovery/20150324 \ ./genfiles/genw445 root@solaris:~#
确保已正确恢复该文件。使用命令 sls -D file，其中，file 用于指定相对于临时恢复目录的文件的路径和名称。
在本示例中，已将文件 genfiles/genw445 恢复至临时目录 /hsmfs1/restore/：
root@solaris:~# sls -D genfiles/genw445 genfiles/genw445: mode: -rw-r--r-- links: 1 owner: data group: hsmfs1 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:~#
如果已正确恢复该文件，则将其移动至文件系统中的正确位置。
在本示例中，我们将文件 genw445 从临时工作目录 /hsmfs1/restore/genfiles/ 移动至其位于 /hsmfs1/genfiles/ 的原始位置：
root@solaris:~# mv -f genfiles/genw445 /hsmfs1/genfiles/genw445 root@solaris:~#
重复上述过程，直到所有丢失的文件恢复为止。
完成恢复过程。转至将归档文件系统恢复为正常操作。
如果涉及到大量文件，那么使用归档程序日志和/或介质迁移日志恢复文件始终是一个单调乏味、劳动密集型的过程。因此，只要有可能，仅当恢复点无法恢复您需要的文件时，才使用本节中阐述的流程。
虽然在所有情况下从归档介质中恢复文件的过程在本质上是相同的，但对于不同的文件类型，细节是不同的。因此请选择针对您要恢复的文件类型的过程：
请注意，您从介质恢复副本时文件可能无法恢复到您所期望的确切位置。创建归档副本时，文件会恢复到其位置。因此，随后移动的文件将不会恢复到这些文件当初丢失时所在的原始目录中。
对于每个您需要恢复的文件，执行以下操作：
如果您尚未执行该操作，以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果您尚未停止归档和回收，请使用停止归档和回收过程中介绍的过程停止归档和回收
转到您要恢复的文件系统的根目录。
Oracle HSM 归档文件相对于文件系统根目录存储副本。因此要将它们恢复到其原始位置，我们要从根目录恢复它们。
在本示例中，我们转到 hsmfs1 文件系统的根：
root@solaris:~# cd /hsmfs1 root@solaris:~#
如果您拥有常规文件上次归档期间的归档程序日志，请查找该文件的最新条目。
在第一个示例中，我们查找常规（类型 f）文件 genA0 的条目：
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
在第二个示例中，我们查找常规（类型 f）文件 spcC4 的条目：
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
找到所需文件的日志条目后，请注意介质类型、介质的卷序列号以及相对于文件系统根目录的文件的名称。
在第一个示例中，文件 genA0 位于卷序列号 (Volume Serial Number, VSN) 为 VOL004 的 LTO (li) 磁带卷上。该文件最初存储在文件系统目录 /hsmfs1/genfiles/ 中：
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
在第二个示例中，文件 spcC4 位于卷序列号为 DISKVOL1 的磁盘归档 (dk) 中。该文件最初存储在文件系统目录 /hsmfs1/socfiles/ 中：
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
如果所需文件驻留在顺序访问介质（如磁带）中，还要注意十六进制值，该值表示归档 (tar) 文件的起始位置。
在本示例中，文件 genA0 位于磁带上，起始位置为 0x212 (212)：
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
如果所需的文件位于随机访问介质（如归档磁盘）中，还请注意相对于卷序列号的 tar 文件的路径和文件名。
在本示例中，文件 spcC4 位于 f2 子目录中，该子目录恰好位于磁盘卷 DISKVOL1 的根目录之下：
A 2015/03/03 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0
如果您要恢复的文件已归档到磁盘介质，请从磁盘卷上的 tar 文件中提取丢失或已损坏文件的归档副本。使用命令 star -xv -f tarfile file，其中：
tarfile 是归档文件的名称。
file 是需要恢复的文件的路径（相对于文件系统根目录）和名称。
star 命令为 GNU tar 的增强型 Oracle HSM 版本，可从归档文件恢复指定的文件。
在本示例中，我们从 tar 文件 DISKVOL1/f2 中提取数据文件 socfiles/spcC4。该文件恢复到 /hsmfs1/socfiles/spcC4：
root@solaris:~# star -xvf DISKVOL1/f2 socfiles/spcC4
如果您已从磁盘归档恢复所需的文件，则继续恢复丢失和已损坏的常规文件，直到已恢复所有所需的文件。
如果您要恢复的文件归档在可移动介质（如磁带）中，请在恢复的文件系统中创建一个目录来容纳临时归档文件。
在本示例中，我们创建目录 /hsmfs1/tars
root@solaris:~# mkdir /hsmfs1/tars
将介质放置在归档文件（该文件保存已归档副本）的 tar 文件头的开头处，并将归档从介质读取到内存。使用命令 request -m media-type -v volume-serial-number -p 0xposition path/requestfile，其中：
-m media-type 指定附录 B中列出的两字符介质类型代码之一。
-v volume-serial-number 指定用于标识介质卷的六字符字母数字代码。
-p 0xposition 指定您在归档程序日志条目中注明的十六进制起始位置。
path 为临时恢复目录的路径。
requestfile 为您要用于内存 tar 文件（request 命令从介质中读取该文件）的名称。
在本示例中，我们从 LTO (li) 卷 VOL012 上的位置 0x78 开始创建请求文件 /hsmfs1/tars/currentrequest：
root@solaris:~# request -m li -v VOL012 -p 0x78 /hsmfs1/tars/currentrequest
从您在前一步骤中创建的内存 tar 文件中提取丢失或已损坏的文件的归档副本。使用命令 star -xv -f requestfile，其中：
requestfile 是内存 tar 文件的名称。
file 是需要恢复的文件的路径（相对于文件系统根目录）和名称。
star 命令为 GNU tar 的增强型 Oracle HSM 版本，可从请求文件（归档文件的内存副本）恢复指定的文件。
在本示例中，我们从请求文件 tars/currentrequest 提取数据文件 genfiles/genA0。该文件恢复到 /hsmfs1/genfiles/genA0：
root@solaris:~# star -xvf tars/currentrequest genfiles/genA0
设置任何必需的文件属性。
从 tar 文件恢复文件时，如果没有 samfsdump 或 qfsdump 恢复点文件，则原始文件属性将丢失。必须使用默认属性值从头开始为该文件创建 .inodes 文件。
重复上述过程，直到所有必需的文件恢复为止。
否则，完成恢复过程。转至将归档文件系统恢复为正常操作。
恢复分段文件与恢复常规文件十分相似。但是，您恢复的是各个段，而不是文件本身。因此，要恢复文件，您必须将各个段重装到单个文件中，然后对结果重新分段。对于每个您需要恢复的文件，执行以下操作：
如果您尚未执行该操作，以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果您尚未执行归档和回收，请使用 停止归档和回收过程 中的过程执行归档和回收
如果您拥有分段文件上次归档期间的归档程序日志，请搜索分段（类型 S）文件的条目。选择所需文件的段的最近条目。
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 2476f.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
找到最新的段条目后，注意以下详细信息：
介质类型
存储文件段的介质卷的卷序列号
存储段的归档 (tar) 文件的十六进制起始位置
分段文件相对于文件系统的根目录的路径和名称
文件中段的数量。
在本示例中，将文件 dat011 分为三个段（1、2 和 3）。将这三个段存储在三个归档文件中，这些文件都位于卷序列号为 VOL013 的单个 LTO (li) 磁带卷上。这三个归档文件的起始位置为 0x76a (76a)、0x2476f (2476f) 和 0x1409aa4 (1409aa4)。
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 2476f.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
转到您要恢复的文件系统的根目录。
Oracle HSM 归档文件相对于文件系统根目录存储副本。因此要将它们恢复到其原始位置，我们要从根目录恢复它们。
在本示例中，我们转到 hsmfs1 文件系统的根：
root@solaris:~# cd /hsmfs1
在恢复的文件系统中，创建一个目录以保存临时归档文件。
在本示例中，我们创建目录 /hsmfs1/tars
root@solaris:~# mkdir /hsmfs1/tars
将介质放置在保存一个或多个文件段的已归档副本的每个归档文件开头处，并将归档从介质读取到内存。使用命令 request -m media-type -v volume-serial-number -p 0xposition path/requestfile，其中：
-m media-type 指定附录 B中列出的两字符介质类型代码之一。
-v volume-serial-number 指定用于标识介质卷的六字符字母数字代码。
-p 0xposition 指定您在归档程序日志条目中注明的十六进制起始位置。
path 为临时恢复目录的路径。
requestfile 为您要用于内存 tar 文件（request 命令从介质中读取该文件）的名称。
在本示例中，我们需要创建两个请求文件。第一个请求文件 /hsmfs1/tars/request76a 装入的归档文件从 LTO (li) VOL013 上的位置 0x76a 开始。此归档同时包含前两个段。第二个请求文件 /hsmfs1/tars/request1409aa4 在 0x1409aa4 位置装入归档文件，在本示例中位于同一个卷上（段可驻留在库的任何卷中）：
root@solaris:~# request -m li -v VOL013 -p 0x76a /hsmfs1/tars/request76a root@solaris:~# request -m li -v VOL013 -p 0x1409aa4 \ /hsmfs1/tars/request1409aa4
从您在前一步骤中创建的内存 tar 文件中提取丢失或已损坏文件的备份副本的每个段。使用命令 star -xv -f requestfile segment，其中 requestfile 为内存 tar 文件的名称，而 segment 为您需要恢复的文件的每个段的路径（相对于文件系统根目录）和名称。
star 命令为 GNU tar 的增强型 Oracle HSM 版本，该命令可借助请求文件从您指向的归档文件中恢复指定文件。
在本示例中，我们从请求文件（内存 tar 文件）tars/request76a 中提取数据文件 bf/dat011 的三个段中的两个段，并从请求文件 tars/request1409aa4 中提取一个段。文件会分为三个独立的部分恢复到目录 /hsmfs1/bf/dat011/ 中：
root@solaris:~# star -xvf tars/request76a bf/dat011/1 root@solaris:~# star -xvf tars/request76a bf/dat011/2 root@solaris:~# star -xvf tars/request1409aa4 bf/dat011/3
列出 /hsmfs1/bf/dat011 的内容时，会针对每个已恢复段看到一个按顺序编号的文件：
root@solaris:~# ls /hsmfs/bf/dat011 total 40968 -rw-rw---- 1 root other 10485760 Mar 5 17:06 1 -rw-rw---- 1 root other 10485760 Mar 5 17:06 2 -rw-rw---- 1 root other 184 Mar 5 17:07 3 root@solaris:~#
将已恢复段重装到单个未分段的临时文件中。
在本示例中，我们串联 /hsmfs1/bf/dat011/ 目录中的三个段，以创建文件 /hsmfs1/bf/dat011file：
root@solaris:~# cat /hsmfs/bf/dat011/1 /hsmfs/bf/dat011/2 \ /hsmfs/bf/dat011/3 > /hsmfs/bf/dat011file root@solaris:~#
我们列出 /hsmfs1/bf/ 的内容时，新文件会显示在包含段的目录旁边。
root@solaris:~# ls -l /hsmfs/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:~#
删除相应段和包含这些段的目录。
root@solaris:~# rm -r /hsmfs/bf/dat011/ root@solaris:~#
使用分段文件的原始路径和名称创建空文件。使用命令 touch file，其中 file 为原始路径和文件名。
在本示例中，我们创建空文件 /hsmfs/bf/dat011，这是我们正在恢复的分段文件的原始名称：
root@solaris:~# touch /hsmfs/bf/dat011 root@solaris:~#
在新创建的空文件中设置 Oracle HSM 段属性。使用命令 segment -l segment-length file，其中 segment-length 为您在归档程序日志条目中注明的段长度，而 file 为分段文件的原始路径和名称。
在本示例中，归档程序日志显示文件 dat011 的段长度为 10485760（该文件在第三段结束，因此介质上数据的长度小于段长度）：
A 2015/03/03 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/03 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/03 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51
因此我们将空文件的段长度设置为 10485760：
root@solaris:~# segment -l 10485760 /hsmfs/bf/dat011 root@solaris:~#
将未分段临时文件复制到空分段文件。
在本示例中，我们将 dat011file 复制到 dat011：
root@solaris:~# cp /hsmfs/bf/dat011file /hsmfs/bf/dat011 root@solaris:~#
我们使用命令 sls -2K hsmfs/bf/dat011 列出段时，它们列出如下。因此该文件已恢复。
root@solaris:~# sls -2K /hsmfs/bf/dat011 -rw-rw---- 1 root other 20971704 Mar 5 17:12 hsmfs/bf/dat011 ---------- ----- sI {3,0,0,0} -rw-rw---- 1 root other 10485760 Mar 5 17:12 hsmfs/bf/dat011/1 ---------- ----- sS -rw-rw---- 1 root other 10485760 Mar 5 17:12 hsmfs/bf/dat011/2 ---------- ----- sS -rw-rw---- 1 root other 184 Mar 5 17:12 hsmfs/bf/dat011/3 ---------- ----- sS
设置任何其他必需的文件属性。
从 tar 文件恢复文件时，如果没有 samfsdump 或 qfsdump 恢复点文件，则原始文件属性将丢失。必须使用默认属性值从头开始为该文件创建 .inodes 文件。
现已恢复该文件。删除未分段临时文件。
在本示例中，我们删除 dat011file：
root@solaris:~# rm /hsmfs/bf/dat011file root@solaris:~#
重复上述过程，直到所有必需的文件恢复为止。
完成恢复过程。转至将归档文件系统恢复为正常操作。
卷溢出文件是跨多个介质卷的常规文件。因此恢复卷溢出文件与恢复其他任何常规文件十分相似。但是，首先必须将驻留在多个卷上的归档文件的部分合并到磁盘上的单个归档文件中，然后再从归档中提取数据文件。因此，对于您需要恢复的每个文件，请执行以下操作：
如果您尚未执行该操作，以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果您尚未执行归档和回收，请使用 停止归档和回收过程 中的过程执行归档和回收
如果您拥有卷溢出文件上次归档期间的归档程序日志，请查找该文件的最新条目。请注意介质的卷序列号、文件每个部分的长度、相对于文件系统根目录的文件的路径和名称，以及文件中的部分数目。
在本示例中，我们知道文件 /hsmfs1/rf/rf81 为卷溢出，因为它是一个常规的 f 类型文件，该文件驻留在 VOL036 和 VOL034 这两个卷中，并拥有两个部分，即 0 和 1：
A 2015/03/03 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2013/08/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 11731.1 525271552 rf/rf81 f 1 220
转到您要恢复的文件系统的根目录。
Oracle HSM 归档文件相对于文件系统根目录存储副本。因此，要将它们恢复到其原始位置，我们要将它们恢复到根目录。
在本示例中，我们转到 hsmfs1 文件系统的根：
root@solaris:~# cd /hsmfs1
在继续前，请确保文件系统中包含足够的可用空间，可容纳文件的大小至少是您要恢复的文件大小的两倍。
对于本示例中的文件 rf/rf81，基于该文件两部分的大小，我们大约需要 1.2 千兆字节的可用空间：2 x (89128448 + 525271552) = 1228800000 字节。
在恢复的文件系统中，创建一个目录以保存临时归档文件。
在本示例中，我们创建目录 /hsmfs1/tars
root@solaris:~# mkdir /hsmfs1/tars
将介质放置在保存一个或多个文件段的已归档副本的每个归档文件开头处，并将归档从介质读取到内存。使用命令 request -m media-type -v volume-serial-number -p 0xposition path/requestfile，其中：
-m media-type 指定附录 B中列出的两字符介质类型代码之一。
-v volume-serial-number 指定用于标识介质卷的六字符字母数字代码。
-p 0xposition 是您在归档程序日志条目中注明的十六进制起始位置。
path 为临时恢复目录的路径。
requestfile 为您要用于内存 tar 文件（request 命令从介质中读取该文件）的名称。
在本示例中，我们创建两个请求文件。第一个请求文件 /hsmfs1/tars/requestVOL036 装入的归档文件从 LTO (li) VOL036 上的位置 0x12d 开始。第二个请求文件 /hsmfs1/tars/requestVOL034 在 LTO (li) VOL034 上的位置 0x15f 装入归档文件：
root@solaris:~# request -m li -v VOL036 -p 0x12d /hsmfs1/tars/requestVOL036 root@solaris:~# request -m li -v VOL034 -p 0x15f /hsmfs1/tars/requestVOL034
将您所创建的每个内存 tar 文件保存到磁盘中，作为归档文件的一部分。使用命令 dd if= requestfile of=archive_section，其中 requestfile 为内存 tar 文件的路径和名称，而 archive_section 为每部分归档文件的路径和名称。
在本示例中，我们将请求文件（内存 tar 文件）tars/requestVOL036 和 tars/requestVOL034 另存为 tars/archive_part1 和 tars/archive_part2：
root@solaris:~# dd if=tars/requestVOL036 of=tars/archive_part1 root@solaris:~# dd if=tars/requestVOL034 of=tars/archive_part2 root@solaris:~#
将各个部分重新组装到单个归档文件中。
在本示例中，我们将 tars/archive_part1 和 tars/archive_part2 这两个部分进行串联，以创建单个归档文件 /tars/archive_complete：
root@solaris:~# cat tars/archive_part1 tars/archive_part2 > \ tars/archive_complete root@solaris:~#
从您在前一步骤中创建的归档 (tar) 文件中提取丢失或已损坏的卷溢出文件的备份副本。使用命令 star -xv -f tarfile file，其中 tarfile 为归档文件的名称，而 file 为您需要恢复的卷溢出文件的路径（相对于文件系统根目录）和名称。
star 命令为 GNU tar 的增强型 Oracle HSM 版本，该命令可借助请求文件从您指向的归档文件中恢复指定文件。
在本示例中，我们从 tar 文件 tars/archive_complete 中提取卷溢出文件 rf/rf81：
root@solaris:~# star -xvf tars/archive_complete rf/rf81
设置任何其他必需的文件属性。
从 tar 文件恢复文件时，如果没有 samfsdump 或 qfsdump 恢复点文件，则原始文件属性将丢失。必须使用默认属性值从头开始为该文件创建 .inodes 文件。
现已恢复该卷溢出文件。删除临时文件。
在本示例中，我们删除 dat011file：
root@solaris:~# rm tars/archive_* root@solaris:~#
重复上述过程，直到所有必需的文件恢复为止。
完成恢复过程。转至将归档文件系统恢复为正常操作。
已损坏的归档副本是无法回写到磁盘高速缓存中的文件副本。有时，该文件只是由于间歇性、与硬件相关的 I/O 问题而无法回写，此问题可轻松解决。而有时候，已损坏的副本被破坏，其数据不可恢复。这种情况下，您唯一的选择是从备用副本中恢复该文件。
要确定和管理已损坏的副本，请执行以下操作：
标识拥有已损坏归档副本的文件。使用命令 sfind mountpoint -any_copy_d，其中 mountpoint 为挂载已恢复文件系统的目录。
在本示例中，我们在目录 /hsmfs1 中开始搜索，并找到拥有已损坏副本的三个文件：
root@solaris:~# sfind /hsmfs1 -any_copy_d ./genfiles/ab09 ./genfiles/ab11 ./genfiles/ay12 root@solaris:~#
对于您已标识的每个文件，请标识已损坏的副本。使用命令 sls -D file，其中 file 为您要检查的路径和文件名。
已损坏的副本带有 D 标志。在本示例中，/hsmfs1/genfiles/ab09 的 copy 2 和 /hsmfs1/genfiles/ab11 的 copy 1 已损坏：
root@solaris:~# sls -D /hsmfs1/genfiles/ab09 /hsmfs1/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 VOL011 copy 2: ---D Mar 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 /hsmfs1/genfiles/ab11 /hsmfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0 inode: 1460.1 project: system(0) copy 1: ---D Mar 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:~#
如果有备用副本，则取消归档已损坏的副本。使用命令 unarchive -c CopyNumber file，其中 CopyNumber 为一个整数，代表副本编号，而 file 为已损坏文件的路径和文件名。在此处停止。
如果您取消归档已损坏的副本，则 Oracle HSM 会从剩余的副本中回写，并在下次归档程序进程运行时创建其他归档副本。在本示例中，我们拥有 /hsmfs1/genfiles/ab09 的另一个未损坏副本，因此我们取消归档已损坏的副本，即副本 2：
root@solaris:~# unarchive -c 2 /hsmfs1/genfiles/ab09 root@solaris:~#
如果您没有其他副本，请修复已损坏的副本。使用命令 undamage -cCopyNumber file，其中 CopyNumber 为一个整数，代表副本编号，而 file 为已损坏文件的路径和文件名。
有时，文件由于间歇性、与硬件相关的 I/O 错误而无法回写。清除已损坏文件并重新回写可能可以解决此问题。在本示例中，只有 /hsmfs1/genfiles/ab11 的一个副本：
root@solaris:~# undamage -c1 /hsmfs1/genfiles/ab11
尝试回写该副本。使用命令 stage -c CopyNumber -I file，其中 CopyNumber 为一个整数，代表副本编号，而 file 为该文件的路径和文件名。
可选 -I (immediate) 参数会将回写操作推送到队列头：
root@solaris:~# stage -c 1 -I /hsmfs1/genfiles/ab11
如果回写成功，请在此处停止。
如果回写再次失败，Oracle HSM 会再次设置已损坏标志。针对已损坏副本，记下 sls -D 命令的输出中的主 inode 编号。
在本示例中，文件 /hsmfs1/genfiles/ab11 的 inode 编号为 1460：
root@solaris:~# sls -D /hsmfs1/genfiles/ab11 /hsmfs1/genfiles/ab11: mode: -rw-r----- links: 1 owner: root group: other length: 380051 admin id: 0 inode: 1460.1 project: system(0) copy 1: ---D Mar 01 10:21 431.21bc6 li VOL024 ... root@solaris:~#
查找可能的原因。首先，检查 Oracle HSM /var/adm/sam-log 文件中是否存在与拥有已损坏副本的文件有关的回写相关消息。
可采用多种方式执行搜索。在示例中，使用 Solaris cat 命令列出了日志文件的内容，并通过管道将输出传递到 grep 以及与 inode 编号相匹配的正则表达式中。我们找到了两条消息。两条消息均指示 I/O 错误，其中一条消息明确表明设备 (eq) 序号 804（我们的其中一个磁带机）：
root@solaris:~# cat /var/adm/sam-log | grep "inode 1460" Mar 11 15:35:44 server1 genu-20[8899]: Stage request canceled for inode 1460 (eq 804): I/O error. Jan 11 15:35:44 server1 samfs[8894]: /sam4 inode 1460.1 - Archive copy 1 marked damaged: I/O error
如果 /var/adm/sam-log 文件表明特定 Oracle HSM 设备序号，请检查设备日志 /var/opt/SUNWsamfs/devlog/drive-equipment-number，其中 drive-equipment-number 为 /var/adm/sam-log 文件中列出的序号。
如果问题显示为特定于具体的某一磁带机，请使用命令 samcmd unavail drive-equipment-number 让关联磁带机不可用于回写过程。然后取消破坏相应副本，并尝试再次回写该副本。
root@solaris:~# samcmd unavail 804 root@solaris:~# stage -c 1 -I /hsmfs1/genfiles/ab11 root@solaris:~# undamage -c1 /hsmfs1/genfiles/ab11 root@solaris:~#
如果回写再次失败，或没有任何单个磁带机显示为出故障，请尝试使用 request 和 star 命令（如使用日志条目恢复文件中所述）或 Solaris 实用程序（如 tar 和 dd）来恢复副本。
如果仍无法恢复文件并且数据的值证明了这一点，请使用数据恢复服务。要获取 Oracle StorageTek 磁带介质帮助，请使用 Oracle StorageTek 企业磁带数据恢复服务。登录 My Oracle Support (support.oracle.com)。创建一个服务请求，从请求类别下的列表中选择磁带机型号，然后从子类别下的列表中选择 "Media Issues"（介质问题）。
如果事实证明文件不可恢复，请取消归档受损的副本。使用命令 unarchive -c CopyNumber file，其中 CopyNumber 为一个整数，代表副本编号，而 file 为已损坏文件的路径和文件名。
root@solaris:~# unarchive -c 1 /hsmfs1/genfiles/ab11 root@solaris:~#
解决日志文件中所揭示的任何磁带机或介质问题。
如果在之前的步骤中禁用了归档、回写和回收进程，现在请重新将其启用。转至将归档文件系统恢复为正常操作。
否则，请在此处停止。