本部分概述了当整个 Oracle HSM 文件系统损坏或丢失时您将使用的恢复过程。此类过程会有所不同，具体取决于所涉及的文件系统类型以及您所做的备份和恢复准备工作的类型。但是您必须执行两项基本任务：
在开始前，请注意：如果您从丢失的 Oracle HSM 元数据服务器中进行恢复，在继续之前请确保您已完成恢复 Oracle HSM 配置（如第 3 章中所述）。本章中的过程假定已安装 Oracle HSM 软件，并已将该软件配置为文件系统丢失之前的状态。
在恢复文件和目录之前，您必须具有用于放置文件和目录的位置。因此，恢复过程的第一步是创建空的替换文件系统。执行如下操作：
sammkfs 命令重新创建文件系统以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果当前已挂载文件系统，请将其卸载。使用命令 umount mount-point，其中 mount-point 为挂载了文件系统的目录。
在本示例中，我们卸载文件系统 /hsmfs1：
root@solaris:~# umount /hsmfs1 root@solaris:~#
在文本编辑器中打开 /etc/opt/SUNWsamfs/mcf 文件。检查硬件配置。如果您必须更改硬件，请相应地编辑该文件，然后保存更改。
在本示例中，我们将两个故障磁盘设备的设备标识符替换为其替换磁盘设备的设备标识符。请注意，设备序号保持不变：
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #----------------------- --------- --------- --------- ------ ------------- hsmfs1 100 ms hsmfs1 on /dev/dsk/c1t3d0s3 101 md hsmfs1 on /dev/dsk/c1t4d0s5 102 md hsmfs1 on # Tape library /dev/scsi/changer/c1t2d0 800 rb lib800 on .../lib800_cat /dev/rmt/0cbn 801 li lib800 on /dev/rmt/1cbn 802 li lib800 on :wq root@solaris:~#
检查 mcf 文件中是否存在错误。使用命令 sam-fsd。
sam-fsd 命令读取 Oracle HSM 配置文件，并初始化相应软件。该命令会在遇到以下错误时停止：
root@solaris:~# sam-fsd
如果 sam-fsd 命令在 mcf 文件中找到错误，请编辑该文件以更正错误，并按照前一步骤中的描述重新检查。
在下面的示例中，sam-fsd 报告设备中出现的未指定问题。在 "Equipment Identifier"（设备标识符）字段中，这可能是一个键入错误：
root@solaris:~# sam-fsd Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem qfsms sam-fsd: Problem with file system devices.
通常，这样的错误是不经意的键入错误导致的。此处，在编辑器中打开 mcf 文件后，发现在设备 102（第二个 md 设备）设备名称的分片编号中键入了一个字符 o 而非 0：
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0so 102 md qfsms on
因此我们更正错误，保存文件，并重新检查：
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0s0 102 md qfsms on :wq root@solaris:~# sam-fsd
如果 sam-fsd 命令运行无误，则 mcf 文件是正确的。继续执行下一步。
在本示例中，sam-fsd 运行无误：
root@solaris:~# sam-fsd Trace file controls: sam-amld /var/opt/SUNWsamfs/trace/sam-amld ... Would start sam-archiverd() Would start sam-stagealld() Would start sam-stagerd() Would start sam-amld() root@solaris:~#
告知 Oracle HSM 软件读取 mcf 文件，并相应重新配置自身：
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
创建替换文件系统。使用命令 sammkfs family-set-name，其中的 family-set-name 为文件系统的名称。
在本示例中，我们重新创建文件系统 hsmfs1：
root@solaris:~# sammkfs hsmfs1 Building 'hsmfs1' will destroy the contents of devices: /dev/dsk/c0t0d0s0 /dev/dsk/c0t3d0s0 Do you wish to continue? [y/N]yes total data kilobytes = ... root@solaris:~#
如果需要，请重新创建该文件系统的挂载点目录。
在本示例中，我们重新创建目录 /hsmfs1：
root@solaris:~# mkdir /hsmfs1 root@solaris:~#
备份操作系统的 /etc/vfstab 文件。
root@solaris:~# cp /etc/vfstab /etc/vfstab.backup root@solaris:~#
在文本编辑器中打开 /etc/vfstab 文件。如果 /etc/vfstab 文件不包含您要恢复的文件系统的挂载参数，您将必须恢复该挂载参数。
在本示例中，Oracle HSM 服务器安装在替换主机中。因此，该文件不包含我们要恢复的文件系统 hsmfs1 的挂载参数：
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...
如果可能，当您必须恢复挂载参数时，请打开原始 /etc/vfstab 文件的备份副本，然后将所需的行复制到当前的 /etc/vfstab 文件中。完成更改后，请保存相应文件，然后关闭编辑器。
在本示例中，我们拥有备份副本 /zfs1/sam_config/20140127/etc/vfstab。因此，我们从该备份副本中复制 hsmfs1 文件系统的相应行，然后将其粘贴到当前的 /etc/vfstab 文件中：
root@solaris:~# vi /zfs1/sam_config/20140127/etc/vfstab.20140127 #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :q
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :wq root@solaris:~#
挂载文件系统。
在本示例中，我们挂载文件系统 hsmfs1：
root@solaris:~# mount /hsmfs1 root@solaris:~#
现在，开始恢复目录和文件。
重新创建基本文件系统后，您可以开始恢复目录和文件。有两个可能的方法：
如果您定期创建且安全存储了恢复点，则从 samfsdump (qfsdump) 恢复点文件恢复文件和目录是目前为止的最佳选项。
该方法可立即将文件系统返回至完整功能，因为它可恢复文件系统元数据。归档文件系统可立即访问归档介质上的数据，然后在用户访问文件时立即或根据需要将文件回写到磁盘高速缓存。文件随其原始属性一起恢复。
如果恢复点包含数据及元数据，则此方法也是用于恢复未被第三方应用程序备份的独立（非归档）文件系统的唯一方法。
使用恢复脚本和 Oracle HSM star 实用程序在没有恢复点文件的情况下，从归档介质中恢复文件和目录。
samfsdump (qfsdump) 恢复点文件恢复文件和目录您的文件系统恢复工作应尽可能以最新可用的恢复点文件为基础。到目前为止，这是从 Oracle HSM 文件系统故障中进行恢复的最快、最可靠、最节省人力的方法。因此，如果存在恢复点文件，请继续如下操作：
以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
如果您尚未停止归档和回收，请使用停止归档和回收过程中介绍的过程停止归档和回收。
标识最新的可用恢复点文件。
在本示例中，我们在已知位置（即独立文件系统 /zfs1 中的子目录 hsmfs1_recovery）为文件系统 hsmfs1 创建了标注日期的恢复点文件。因此可轻松找到最新文件 20140324：
root@solaris:~# ls /zfs1/hsmfs1_recovery/ 20140321 20140322 20140323 20140324 root@solaris:~#
更改为重新创建的文件系统的挂载点目录。
在本示例中，重新创建的文件系统挂载于 /hsmfs1：
root@solaris:~# cd /hsmfs1 root@solaris:~#
恢复相对于当前目录的整个文件系统。使用命令 samfsrestore -T -f recovery-point-file -g logfile 或仅 QFS 命令 qfsrestore -T -f recovery-point-file -g logfile，其中：
当命令终止时，-T 会显示恢复统计信息，包括所处理的文件和目录数目及错误和警告数目。
-f recovery-point-file 会指定选定恢复点文件的路径和文件名称。
-g logfile 会创建在创建恢复点时处于联机状态的目录和文件列表，并将该列表保存至由 logfile 指定的文件。
如果您要恢复归档文件系统，则该文件可用于从归档介质中自动回写文件，以便磁盘高速缓存所处的状态与其在创建恢复点时的状态相同。
在本示例中，我们从恢复点文件 /zfs1/hsmfs1_recovery/20140324 恢复文件系统 hsmfs1。我们将联机文件记录在文件 /root/20140324.log 中（请注意，下面的命令是作为单行输入的－使用反斜杠字符对换行符进行转义）：
root@solaris:~# samfsrestore -T -f /zfs1/hsmfs1_recovery/20140324 \ -g /root/20140324.log samfsdump statistics: Files: 52020 Directories: 36031 Symbolic links: 0 Resource files: 8 File segments: 0 File archives: 0 Damaged files: 0 Files with data: 24102 File warnings: 0 Errors: 0 Unprocessed dirs: 0 File data bytes: 0 root@solaris:~#
如果您已恢复独立（非归档）文件系统，则已恢复保存在恢复点文件中的文件系统元数据和文件数据。在此处停止。
否则，必要时重新回写已归档文件。
多数情况下，请勿在文件系统恢复后将文件从归档介质中重新回写到磁盘中。让用户根据需要，通过访问文件来回写文件。
该方法会根据用户需要自动对回写按优先级排序。该方法会在文件系统可能已脱机一段时间时最大程度地提高其可用性。仅回写立即需要的文件。因此总回写工作会分布在一段时间中。这样有助于确保文件系统资源（如驱动器）始终可用于高优先级任务（如归档新文件和回写迫切需要的用户数据）。
该方法还可减少与恢复相关的管理工作。
如果必须重新回写故障前磁盘高速缓存中的文件，请使用命令 /opt/SUNWsamfs/examples/restore.sh logfile，其中 logfile 是使用 samfsrestore (qfsrestore) 命令和 -g 选项创建的日志文件的路径和文件名。
restore.sh 脚本会回写日志文件中列出的文件。这些是在创建 samfsrestore (qfsrestore) 恢复点文件时联机的文件。
如果需要回写几千个文件，则考虑将日志文件拆分为一些较小的文件。然后依次对每个文件运行 restore.sh 脚本。这样可在一段时间内传播回写工作，并减少对归档和用户启动的回写的干扰。
现在，确定已损坏文件并找到替换副本。
samfsrestore 过程从恢复点文件恢复文件系统元数据的副本，因此您可以在磁带上找到相应的文件系统数据并将其恢复至其在文件系统中的适当位置。不过，会在文件系统丢失之前创建恢复点文件。因此，某些元数据通常会指向自恢复点创建以来已更改的数据位置，这是不可避免的。文件系统具有这些文件的记录，但无法定位其内容。因此，文件系统会在每个此类文件上设置 damaged 标志。
在某些情况下，损坏的文件的数据确实可能已丢失。但在其他情况下，恢复的元数据仅是过期而已。仅由于恢复的元数据不记录当前位置，因此恢复的文件系统可能无法找到在创建恢复点之后归档或迁移的文件的数据。在这些情况下，您可能能够通过自己找到相应的数据并更新恢复的元数据将文件恢复至未损坏的状态。
要找到丢失的数据，请更新元数据，然后将文件恢复至未损坏的状态（使用归档程序日志和介质迁移日志文件（如果有））。执行如下操作：
如果您尚未执行该操作，以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
标识最新的可用归档程序日志文件。
如果服务器上的归档程序日志仍然可用，则它有可能包含最新的信息。否则，您需要使用备份副本。
在本示例中，归档程序日志文件 hsmfs1.archiver.log 位于服务器上的 /var/adm/ 子目录中。我们还为已知位置（独立文件系统 /zfs1 上的子目录 hsmfs1_recovery/archlogs）中的归档程序日志文件标注了日期。因此，我们同时拥有最新的文件 hsmfs1.archiver.log 和最近的备份 20150324：
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
如果文件最近迁移到了替换介质，还要找到迁移日志。
在 migrationd.cmd 文件指定的日志记录目录中为每个源卷创建介质迁移日志。日志名为 media-type.vsn，其中 media-type 是附录 B 设备类型词汇表中所述的两位代码中的一个代码，vsn 是源卷的包含六个字符的字母数字卷序列号。
介质迁移日志的格式包含与归档程序日志相同的恢复信息，可按相同方式使用。有关几种格式差异的描述，请参见附录 A 了解归档程序和迁移日志。
在新近恢复的文件系统中，标识任何已损坏的文件。使用命令 sfind mountpoint -damaged，其中 mountpoint 为挂载已恢复文件系统的目录。
在本示例中，我们在目录 /hsmfs1 中开始搜索，并找到六个已损坏文件：
root@solaris:~# sfind /hsmfs1 -damaged ./genfiles/ay0 ./genfiles/ay1 ./genfiles/ay2 ./genfiles/ay5 ./genfiles/ay6 ./genfiles/ay9 root@solaris:~#
搜索归档程序日志的最新副本中是否存在与每个已损坏文件相关的条目。使用命令 grep "file-name-expression" archiver-log，其中 file-name-expression 为一个与已损坏文件相匹配的正则表达式，而 archiver-log 为您要检查的归档程序日志副本的路径和名称。
在示例中，使用正则表达式 genfiles\/ay0 在最近的日志文件中搜索与文件 genfiles/ay0 相关的条目：
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log
当您找到文件的条目时，请注意介质类型、卷序列号和其中归档数据文件的归档 (tar) 文件位置。另请注意文件类型，因为它会影响您恢复文件的方式。
在本示例中，我们找到文件 genfiles/ay0 的条目。日志条目显示该文件的归档 (A) 时间为 2015 年 3 月 4 日晚上 9:49，使用的是 LTO (li) 卷 VOL012。该文件存储在位于十六进制位置 0x78 (78) 的磁带归档文件中。该文件是常规文件，类型为 f：
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log A 2015/03/04 21:49:15 li VOL012 SLOT12 allsets.1 78.1 hsmfs1 7131.14 8087 genfiles/ay0 f 0 51 root@solaris:~#
有关归档程序日志条目中字段的详细解释，请参见附录 A 了解归档程序和迁移日志。
如果您在当前的归档程序日志副本中找不到已损坏文件的条目，请使用在创建恢复点文件之后创建的任何备份归档日志来重复搜索。
归档程序日志循环频繁。因此，如果您保留多个归档程序日志副本，那么也许可以使用在当前归档程序日志中所涵盖的时间段之前所创建的归档副本来恢复已损坏的文件。
接下来，查找在创建恢复点之后归档的文件。
samfsrestore 过程从恢复点文件恢复文件系统元数据的副本，因此您可以在磁带上找到相应的文件系统数据并将其恢复至其在文件系统中的适当位置。不过，会在文件系统丢失之前创建恢复点文件。这些文件不能包含之后创建和归档的文件的元数据。
通常，有些文件是在创建最后一个恢复点之后和文件系统丢失之前归档的。由于这些文件的元数据未位于恢复点文件中，因此 samfsrestore 无法对其进行恢复，即使作为损坏的文件进行恢复也不行。不过，文件数据确实位于归档介质上。因此，您可以使用归档日志重新创建元数据并将文件恢复至其在文件系统中的适当位置。如果在文件系统丢失之前文件已迁移到替换介质，您还可以使用介质迁移日志。
如果您尚未执行该操作，以 root 用户身份登录到文件系统元数据服务器。
root@solaris:~#
标识最新的可用归档程序日志文件。
如果服务器上的归档程序日志仍然可用，则它有可能包含最新的信息。否则，您需要使用备份副本。
在本示例中，归档程序日志文件 hsmfs1.archiver.log 位于服务器上的 /var/adm/ 子目录中。我们还为已知位置（独立文件系统 /zfs1 上的子目录 hsmfs1_recovery/archlogs）中的归档程序日志文件标注了日期。因此，我们同时拥有最新的文件 hsmfs1.archiver.log 和最近的备份 20150324：
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
如果文件最近迁移到了替换介质，还要找到迁移日志。
在 migrationd.cmd 文件指定的日志记录目录中为每个源卷创建介质迁移日志。日志名为 media-type.vsn，其中 media-type 是附录 B 设备类型词汇表中所述的两位代码中的一个代码，vsn 是源卷的包含六个字符的字母数字卷序列号。
介质迁移日志的格式包含与归档程序日志相同的恢复信息，可按相同方式使用。有关几种格式差异的描述，请参见附录 A 了解归档程序和迁移日志。
搜索归档程序日志的最新副本中是否存在创建恢复点之后创建的条目。使用命令 grep "time-date-expression" archiver-log，其中 time-date-expression 为一个与您要开始搜索的日期和时间相匹配的正则表达式，而 archiver-log 为您要检查的归档程序日志副本的路径和名称。
在本示例中，我们于 2015 年 3 月 4 日凌晨 2:02 丢失了文件系统。最后一个恢复点文件的创建时间为 2015 年 3 月 23 日凌晨 2:10。因此，我们使用正则表达式 ˆA 2015\/03\/2[45] 搜索在 3 月 23 日或 24 日记录的归档文件的最近日志文件：
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log
当您找到未恢复文件归档副本的条目时，请注意路径、名称、文件类型、介质类型和位置信息。
列出的文件类型包括 f（表示常规文件）、R（表示可移除介质）或 S（表示分段文件中数据段）。介质类型为双字符代码（请参见附录 B 设备类型词汇表）。
要找到备份副本，您需要用于存储该副本的介质卷的卷序列号。如果副本存储在顺序访问介质（如磁带）中，还要注意十六进制值，该值表示归档 (tar) 文件的起始位置。如果副本存储在随机访问介质（如归档磁盘）中，请注意相对于卷序列号的 tar 文件的路径和文件名。最后，如果该文件已分段，请注意段长度。
在以下示例中，归档程序日志条目显示，以下文件是在创建最后一个恢复点之后归档的：
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log A 2015/03/23 10:43:18 li VOL002 all.1 111.1 hsmfs1 1053.3 69 genfiles/hops f 0 0 A 2015/03/23 10:43:18 li VOL002 all.1 111.3 hsmfs1 1051.1 104 genfiles/anic f 0 0 A 2015/03/23 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0 A 2015/03/23 13:09:06 li VOL004 all.1 212.20 hsmfs1 1534.2 1497 genfiles/genA9 f 0 0 A 2015/03/23 13:10:15 li VOL004 all.1 212.3f hsmfs1 1533.2 6491 genfiles/genA2 f 0 0 A 2015/03/23 13:12:25 li VOL003 all.1 2.5e hsmfs1 1532.2 17717 genfiles/genA13 f 0 0 A 2015/03/23 13:12:28 li VOL003 all.1 2.7d hsmfs1 1531.2 14472 genfiles/genA4 f 0 0 A 2015/03/23 13:12:40 li VOL003 all.1 2.9c hsmfs1 1530.2 19971 genfiles/genA45 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.308 hsmfs1 1510.2 7797 spcfiles/spcC5 f 0 0 A 2015/03/23 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/23 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/23 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51 A 2015/03/23 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2015/03/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 11731.1 525271552 rf/rf81 f 1 220 root@solaris:~#
我们注意以下信息：
八个常规（类型 f）文件归档 (A) 在 LTO (li) 介质上：genfiles/hops 和 genfiles/anic 位于卷 VOL002 上的位置 0x111 中，genfiles/genA0、genfiles/genA9 和 genfiles/genA2 位于卷 VOL004 上的位置 0x212 中，而 genfiles/genA13、genfiles/genA4 和 genfiles/genA45 位于卷 VOL003 上的位置 0x212 中。
两个常规（类型 f）文件归档 (A) 在磁盘 (dk) 介质上：spcfiles/spcC4 和 spcfiles/spcC5 位于卷 DISKVOL1 上的归档文件 DISKVOL1 \f2 中。
由三部分组成的一个分段（类型 S）文件归档在 LTO (li) 介质上：bf/dat011，其中两个段起始位置为 0x76a，一个段起始位置为卷 VOL013 上的 1409aa4。段 /1 长度为 10485760 字节，段 /2 为 10485622 字节，段 /3 为 184 字节。
一个常规（类型 f）卷溢出文件归档 (A) 在 LTO (li) 介质上：rf/rf81，起始位置为卷 VOL036 上的 0x12d，而持续位置为卷 VOL034 上的 0x15f。
有关归档程序日志条目中字段的详细解释，请参见附录 A 了解归档程序和迁移日志。
创建恢复点文件后，使用创建的任何备份归档日志重复搜索。
归档程序日志循环频繁。因此，如果您保留多个归档程序日志副本，那么也许可以使用在当前归档程序日志中所涵盖的时间段之前所创建的归档副本来恢复已损坏的文件。
现在，恢复损坏的和/或丢失的文件。
在给定介质卷和介质上归档 (tar) 文件位置的情况下，恢复丢失或已损坏的文件只不过是访问 tar 文件和提取所需数据文件的过程。如果归档文件驻留在归档磁盘设备上，该过程非常简单，因为 tar 文件驻留在文件系统挂载点下可随机访问的目录中。然而，如果 tar 文件驻留在高容量的顺序访问介质（如磁带）中，就会增加难度：在将归档文件回写到随机访问磁盘设备中之前，我们无法从归档文件中正常提取所需的数据文件。由于归档文件可能会很大，因此该过程可能会很耗时并在恢复情况中很难操作。因此，以下过程利用了 Oracle HSM 命令 request，该命令将归档文件读取到内存中，并使文件像从磁盘中读取一样可用。
请尽可能恢复已损坏和丢失的常规文件。对于每个文件，请执行以下操作：
通过恢复未跨多个卷的常规文件来启动。使用恢复丢失和已损坏的常规文件 过程。
接下来，恢复分段文件。使用恢复丢失和已损坏的分段文件 过程。
然后恢复跨多个卷的常规文件。使用恢复丢失和已损坏的卷溢出文件 过程。
在您恢复所有具有副本的丢失或损坏的文件之后，通过从 archiver.cmd 文件中删除 wait 指令重新启用归档。通过从 recycler.cmd 文件中删除 -ignore 参数重新启用回收。
文件系统尽可能接近其原始状态。已损坏和丢失的文件仍无法恢复。
在恢复了有副本的所有缺失的或损坏的文件之后，转到将归档文件系统恢复为正常操作。
如果必须直接从归档介质恢复文件系统，没有恢复点文件的帮助，则可这样操作。执行如下操作：
如果您尝试从光学介质中恢复文件，请就此停止，并与 Oracle 支持服务部门联系以获取帮助。
对文件系统禁用网络文件系统 (Network File System, NFS) 共享。
禁用归档和回收。使用停止归档和回收过程 中概述的方法。
保留磁带机以专用于恢复过程。使用命令 samcmd unavail drive-equipment-number，其中 drive-equipment-number 为分配给 /etc/opt/SUNWsamfs/mcf 文件中的驱动器的设备序号。
samcmd unavail 命令使驱动器不可用于归档、回写和释放过程。在本示例中，我们保留驱动器 804
root@solaris:~# samcmd unavail 804 root@solaris:~#
将文件 /opt/SUNWsamfs/examples/tarback.sh 复制到备用位置，如 /tmp。
tarback.sh 为可执行脚本，该脚本可从一组指定介质卷中恢复文件。该脚本针对每个卷上的每个归档 (tar) 文件运行命令 star -n。如果磁带上的备份副本在文件系统中没有对应的文件，或磁带上的副本比文件系统中的相应文件更新，则 star -n 会恢复该副本。
在本示例中，我们将脚本复制到 /tmp：
root@solaris:~# cp /opt/SUNWsamfs/examples/tarback.sh /tmp/tarback.sh root@solaris:~#
请使用文本编辑器打开 tarback.sh 文件副本。
在示例中，我们使用 vi 编辑器：
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" EQ=28 TAPEDRIVE="/dev/rmt/3cbn" # BLOCKSIZE is in units of 512 bytes (e.g. 256 for 128K) BLOCKSIZE=256 MEDIATYPE="lt" VSN_LIST="VSNA VSNB VSNC VSNZ" ...
如果 Oracle HSM 实用程序 star、load 和 unload 安装在非标准位置中，请在 tarback.sh 文件的副本中编辑默认命令路径。
在本示例中，所有实用程序安装在默认位置中，因此不需要编辑：
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" ...
在 tarback.sh 文件的副本中，找到变量 EQ。将其值设置为您为恢复用途保留的驱动器的设备序号。
在本示例中，我们设置 EQ=804：
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
...
在 tarback.sh 文件的副本中，找到变量 TAPEDRIVE。将其值设置为设备的原始路径（括在双引号中）。
在本示例中，设备 804 的原始路径为 /dev/rmt/3cbn：
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
...
在 tarback.sh 文件的副本中，找到变量 BLOCKSIZE。将其值设置为所需块大小中 512 字节单元的数量。
在本示例中，针对 LTO-4 驱动器，我们需要 256 千字节的段大小。因此，我们指定 512：
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
在 tarback.sh 文件的副本中，找到变量 MEDIATYPE。将其值设置为附录 B针对驱动器支持的介质类型列出的两字符介质类型代码。将该介质类型用双引号括住。
在示例中，使用 LTO-4 驱动器。因此，我们指定 li：
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="li"
...
在 tarback.sh 文件的副本中，找到变量 VSN_LIST。提供空格分隔的卷序列号 (volume serial number, VSN)（用于标识可能包含您的文件备份副本的磁带）列表作为其值。使用双引号括起列表。
在本示例中，我们指定卷 VOL002、VOL003、VOL004、VOL013、VOL034 和 VOL036：
EQ=804 TAPEDRIVE="/dev/rmt/3cbn" BLOCKSIZE=512 MEDIATYPE="lt" VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036" ...
保存 tarback.sh 文件的副本。关闭编辑器。
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
:wq
root@solaris:~#
执行 /tmp/tarback.sh 脚本。
root@solaris:~# /tmp/tarback.sh
对于每个恢复的文件，根据需要重新创建用户和组所有权、模式、扩展属性以及访问控制列表 (access control list, ACL)。
/tmp/tarback.sh 脚本无法恢复这些类型的元数据。
在运行了 /tmp/tarback.sh 脚本并完成了恢复文件操作之后，转到将归档文件系统恢复为正常操作。