到目前为止，本文档讨论了将 Oracle Hierarchical Storage Manager and StorageTek QFS Software 解决方案作为普通的 UNIX 文件系统进行管理，在这些文件系统中，用户和应用程序会定期创建、修改和删除文件。重点关注磁盘高速缓存，归档主要充当高度集成的备份服务。在本章中，我们将关注重点重新置于用于长期数据保留的作为系统信息库的归档和管理解决方案。以前涵盖的管理原则和技术仍适用。但是，现在，磁盘高速缓存主要用于将文件获取到在获取之后不允许删除或修改的归档中。
确切的要求会有所不同。保留法律规定期间的业务或医疗记录的系统信息库可能需要定期放弃记录。但是，存储科学数据、历史记录、家谱记录、数字音乐、电影或电视节目的归档实际上可能需要永久存储内容。因此，Oracle HSM 通过多种方式支持数字保留：
使用消息摘要（校验和）可以检测文件的损坏、数据破坏和未经授权的修改，以便您可以更正硬件问题并将不可靠的文件替换为归档中其他位置存储的可靠副本。
文件固定性属性与消息摘要一起可确保只有超级用户可以更改已经修复的文件。每当 Oracle HSM 回写或归档固定文件时，它会重新验证与固定性属性一起存储的校验和以证明文件保持未变。
Oracle HSM 一次写入多次读取 (Write Once Read Many, WORM) 文件系统可以使文件变为只读并在指定时间段内实施保留。这些文件系统可以配置为超级用户无法更改文件或文件属性（如上面讨论的固定性属性）。
本章首先简要回顾了基本的 Oracle HSM 数据保护措施，这些措施构成了任何长期存储解决方案（为保留配置文件系统）的基础。本章随后介绍了具体解决数据保留的任务：
每个保留解决方案都以一个可靠的高度冗余文件系统开始。因此请回顾配套《Oracle Hierarchical Storage Manager and StorageTek QFS Software 安装和配置指南》的实现章节（如果尚未这样做）。通过提供冗余服务器、网络连接和存储设备保护对归档的访问权限。通过为每个文件至少配置两个额外的副本（每个副本存储在独立介质上）来保护文件数据。在多数情况下，最好将一个副本归档到磁盘或固态存储设备上，将两个副本归档到磁带介质上。如有可能，请确保通过实现 Oracle HSM 数据完整性验证功能来确保正确写入和读取了磁带块。通过定期生成转储文件和定期备份归档日志来保护文件系统元数据。
消息摘要（校验和）允许保留人员检验归档文件是否存在可能会指示逐渐恶化、硬件错误、操作员错误的更改，或者是否存在对内容故意进行的未经授权的更改。消息摘要只是文件内容的、已由单向加密散列函数生成的数学汇总。加密散列函数对其输入数据中的更改极其敏感。即使在输入中执行微小的更改也会在输出中生成较大的更改。因此，消息摘要最适合用于检测文件损坏和未经授权的更改。重新计算文件的摘要并将结果值与存储的摘要值进行比较可显示文件是否已更改。
Oracle Hierarchical Storage Manager 文件系统可以使用下面的任何加密散列函数获取、创建、存储和验证消息摘要：
SHA1，加密函数的安全散列算法系列的 160 位成员
安全散列算法在美国联邦信息处理标准 (Federal Information Processing Standard, FIPS) 出版物 180-4 国家标准和技术协会 (2012) 中定义。Oracle HSM 在默认情况下使用 SHA1。
SHA256，安全散列算法系列的 256 位成员
SHA384，安全散列算法系列的 384 位成员
SHA512，安全散列算法系列的 512 位成员
MD5，由 Internet 工程任务组 (Internet Engineering Task Force, IETF) 在互联网信息文档和标准 (request for comments, RFC) 1321 中定义的 128 位消息摘要函数
专有的 128 位 Oracle HSM 函数，现在主要用于与早期的 Storage Archive Manager 实现向后兼容。
当文件获取到系统信息库中时，用户可以提供现有的摘要值；或者用户可以让文件系统立即或在首次归档文件时计算摘要值。Oracle HSM 文件系统使用特殊的文件属性将摘要值和文件系统元数据一起存储。在设置属性之后，文件系统会重新计算摘要，并在重新归档相应的文件和（可选）将文件从归档介质回写到磁盘高速缓存时对照存储的值验证摘要。
但是，请注意，Oracle HSM 介质迁移功能将文件复制到新介质，而不重新计算校验和（有关介质迁移的信息，请参见第 8 章 迁移到新存储介质）。如果文件未正确复制，则说明在对文件重新回写和验证之前，将存在检测不到损坏的小风险。使用数据完整性验证 (Data Integrity Validation, DIV) 可将此风险降到最低（请参见《Oracle Hierarchical Storage Manager and StorageTek QFS Software 安装和配置指南》了解详细信息）。
在开始使用消息摘要之前，应当首先确保文件系统主机性能将足够高。有关提供、生成和验证摘要的说明，请参阅以下各部分：
如果您打算充分利用消息摘要，请确保文件系统主机的计算资源足以实现高性能。大多数现代平台都合并了专用的加密硬件，加密硬件可以高效执行专业计算而不占用中央处理器周期。如果可用，请确保充分利用这些功能。
要检查潜在文件系统主机的功能，请执行如下操作：
以 root 用户身份登录到文件系统主机：
root@solaris:~#
确保主机操作系统运行 Solaris 11.1 或更高版本。使用命令 uname -v。
早期版本的操作系统不支持散列函数的硬件加速。在示例中，主机操作系统是 Solaris 11.2：
root@solaris:~# uname -v 11.2 root@solaris:~#
显示指令集体系结构。在命令提示符处，输入命令 isainfo -v：
root@solaris:~# isainfo -v
如果 Solaris 11 主机是 Oracle Sun SPARC T3 或更高版本的系统，则 isainfo -v 命令的输出应当列出支持 sha512、sha256、sha1 和 md5 加密算法的指令集。
在示例中，Sun SPARC T4-2 主机为 SHA1、SHA2 和 MD5 算法系列提供硬件加速：
[Sun_SPARC_T4-2]root@solaris:~# isainfo -v
64-bit sparcv9 applications
crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia kasumi
des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc
root@solaris:~#
如果 Solaris 主机是 x86/64 系统，它将支持 SHA-1 硬件加速，但前提是 isainfo -v 命令的输出中包括 ssse3（补充流 SIMD 扩展 3）指令集。
在示例中，Sun X3-2 主机支持 SHA-1 摘要的硬件加速：
[Sun_X3-2]root@solaris:~# isainfo -v
64-bit amd64 applications
avx xsave pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3
sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
root@solaris:~#
在对已经具有关联消息摘要的文件进行归档时，请执行如下操作。
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -a algorithm -h digest -G [-u]filename，其中：
-a algorithm 标识在对照所提供的消息摘要验证文件时，文件系统应当使用的加密散列函数。
-h digest 标识文件系统应当用来验证文件的消息摘要。
-G 指定立即验证。文件系统将 hash 文件属性设置为所提供的消息摘要的值，独立计算该文件的消息摘要，并将结果与所存储的值进行比较。如果所提供的摘要和计算得出的摘要相匹配，则文件系统会为文件设置 validated 属性。它随后会设置 generate 属性，以便在对文件重新归档时重新检查其有效性。
-u 设置 use 文件属性（可选）。在对文件回写时，文件系统会重新计算摘要并对照 hash 属性中存储的值验证结果。
filename 是文件的路径和名称。
在示例中，提供了一个 SHA256 摘要，并让文件系统立即为 data10 文件重新计算摘要值并对照所提供的值验证计算结果。在使用命令 sls -D -h data10 检查文件属性时，会发现 generate 和 validated 文件属性已经设置，algorithm 属性已经设置为 SHA-256，摘要值已经计算而且已经存储在 hash 属性中：
root@solaris:~# ssum -h f03ce01b3828...f7459503007e -a sha256 -g data10 root@solaris:~# sls -D -h data10 data10: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
必要时，按照通常的方式编辑该文件。
在示例中，自上次对名为 data10m 的文件进行归档以来，对该文件进行过修改。sls -D -h 命令显示已在两个副本上设置 S（过时）标志，因为这两个副本都未反映最新的更改。使用 Solaris digest 命令检查已修改文件的 SHA-256 摘要时，我们发现该文件的 hash 属性还存储过时摘要值：
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data10m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
必要时，可以在重新归档之前更改已修改文件的摘要属性。
在示例中，将摘要算法从 SHA256 更改为 SHA1，便可立即显示其效果：
root@solaris:~# ssum -a sha1 -G data10m root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
否则，等待文件系统归档已修改的文件并自动更新与摘要相关的属性。
在对已修改的文件归档时，文件系统会重新计算摘要值，将新值存储到 hash 属性，并在旧版本文件的所有归档副本上设置 S（过时）标志。在示例中，对 data10m 文件进行了编辑但未更改摘要属性。归档程序已经按照计划在磁盘上创建了一个新的 copy 1，并更新了 hash 属性。未经修改的文件的副本仍保留在磁带上并标记为 S（过时），直到归档程序可以创建 copy 2 为止：
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
要为文件生成摘要并启用验证，请执行如下操作：
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -a algorithm -g|G [-u] filename，其中：
-a algorithm 指定在为文件生成消息摘要时，文件系统将使用的加密散列函数。
-g 为文件设置 generate 文件属性。首次对文件归档时，文件系统会计算消息摘要。在对文件重新归档时，文件系统会重新计算摘要并对照所存储的值验证结果。
-G 为文件设置 generate 和 validate 文件属性。文件系统会立即计算消息摘要并将结果存储在 hash 属性中。在对文件归档时，文件系统会重新计算摘要并对照所存储的值验证结果。
-u 设置 use 文件属性（可选）。在对文件回写时，文件系统会重新计算摘要并对照 hash 属性中存储的值验证结果。
filename 是文件的路径和名称。
在示例中，在归档之前，让文件系统使用 SHA256 算法为 data11 文件计算摘要。在使用命令 sls -D -h data10 检查文件属性时，我们发现，对于每个文件，generate 文件属性已经设置，并且 algorithm 属性已经设置为 SHA-256。文件尚未进行归档，因此摘要值尚未计算而且未存储在 hash 属性中：
root@solaris:~# ssum -a sha256 -g data11 root@solaris:~# sls -D -h data11 data11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90218.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:22 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
必要时，按照通常的方式编辑该文件。
在示例中，自上次对名为 data11m 的文件进行归档以来，对该文件进行过修改。sls -D -h 命令显示已在两个副本上设置 S（过时）标志，因为这两个副本都未反映最新的更改。使用 Solaris digest 命令检查已修改文件的 SHA-256 摘要时，我们发现该文件的 hash 属性还存储过时摘要值：
root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data11m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
必要时，可以在重新归档之前更改已修改文件的摘要属性。
在示例中，将摘要算法从 SHA256 更改为 SHA1，便可立即显示其效果：
root@solaris:~# ssum -a sha1 -G data11m root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
否则，等待文件系统归档已修改的文件并自动更新与摘要相关的属性。
在对已修改的文件归档时，文件系统会重新计算摘要值，将新值存储到 hash 属性，并在旧版本文件的所有归档副本上设置 S（过时）标志。
在示例中，对 data11m 文件进行了编辑但未更改摘要属性。归档程序已经按照计划在磁盘上创建了一个新的 copy 1，并更新了 hash 属性。未经修改的文件的副本仍保留在磁带上并标记为 S（过时），直到归档程序可以创建 copy 2 为止：
root@solaris:~# sls -D -h data11m mdata11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
要为目录中的每个文件以递归方式生成摘要并设置验证属性，请执行如下操作：
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -a algorithm -g|G [-u] -r directoryname，其中：
-a algorithm 指定在生成消息摘要时，文件系统将使用的加密散列函数。
-g 为每个文件设置 generate 文件属性。首次对文件归档时，文件系统会为该文件计算消息摘要。在对文件重新归档时，文件系统会重新计算摘要并对照所存储的值验证结果。
-G 为每个文件设置 generate 和 validate 文件属性。文件系统会立即计算消息摘要并将结果存储在 hash 属性中。在对文件归档时，文件系统会重新计算摘要并对照所存储的值验证结果。
-u 设置 use 文件属性（可选）。在对文件回写时，文件系统会重新计算摘要并对照所存储的值验证结果。
-r 以递归方式将该命令应用于指定目录中的所有文件。
directoryname 是目录的路径和名称。
在第一个示例中，在归档之前，我们让文件系统使用 SHA256 算法为 datasetA 目录中的文件计算摘要。在使用命令 sls -D -h datasetA 检查文件属性时，我们发现，对于每个文件，generate 文件属性已经设置，并且 algorithm 属性已经设置为 SHA-256。这些文件尚未进行归档，因此摘要值尚未计算而且未存储在 hash 属性中：
root@solaris:~# ssum -a sha256 -g -r datasetA root@solaris:~# sls -D -h datasetA datasetA/pdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... datasetA/pdata20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... root@solaris:~#
在第二个示例中，在归档之前，我们让文件系统使用 SHA256 算法为 datasetB 目录中的文件计算摘要。在使用命令 sls -D -h datasetB 检查文件属性时，我们发现 generate 和 validated 文件属性已经设置，algorithm 属性已经设置为 SHA-256，摘要值已经计算而且已经存储在 hash 属性中：
root@solaris:~# ssum -a sha256 -G -r datasetB root@solaris:~# sls -D -h datasetB datasetB/qdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 4d2800eb82b3...520341edde95 ... datasetB/qdata12: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 5b057f1b7b48...88c590d47dec ... root@solaris:~#
需要时，可以在将文件回写到磁盘高速缓存以供使用之前验证该文件。执行如下操作：
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -u [-a algorithm [-h digest] -g|G] filename，其中：
-u 通过在回写之前设置 use 文件属性来指定验证。在为某个文件设置 use 属性时，文件系统不会将该文件从归档介质复制到磁盘高速缓存，直到它生成了消息摘要并对照该文件的 hash 属性中存储的值成功验证了结果。
-a algorithm、-h digest 和 -g|G 是可选参数，这些参数在文件上设置必需的 algorithm、hash 和 generate 属性（如果以前未设置）。
filename 是文件的路径和名称。
在示例中，已经为 data102 文件启用了验证。正如命令 sls -D -h data102 所示，generate 和 validated 文件属性已经设置，algorithm 属性已经设置为 SHA-256，摘要值已经计算而且已经存储在 hash 属性中：
root@solaris:~# ssum -a sha256 -F data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
因此，可以设置 use 属性以确保文件系统在回写该文件之前对其进行验证。命令 sls -D -h data102 显示现在设置了 use 属性：
root@solaris:~# ssum -u data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate use validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
如果某个文件尚未设置为不可变而且尚未归档，则可以使用下面的过程更改消息摘要和验证属性。
以 root 用户身份登录到文件系统主机：
root@solaris:~#
必要时，更改摘要算法。在命令提示符处，输入命令 ssum -a newalgorithm filename，其中：
-a newalgorithm 指定用来替换以前指定的摘要算法的加密散列函数。
filename 是文件的路径和名称。
在示例中，我们的保留策略需要使用高度抗冲突的 SHA256 函数。但是，正如命令 sls -D -h 所示，我们在设置 data319 文件的摘要属性时无意中指定了 SHA1 算法。由于尚未对该文件归档，因此我们可以成功地将算法更改为 SHA256：
root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-1 hash: root@solaris:~# ssum -a sha256 data319 root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
必要时，清除摘要属性并恢复默认文件设置。在命令提示符处，输入命令 ssum -d filename，其中：
-d 将文件摘要属性重置为其默认值。
filename 是文件的路径和名称。
在示例中，我们并不打算为 data44 文件配置消息摘要和验证。但是，正如命令 sls -D -h 所示，我们无意中进行了配置。由于该文件尚未进行归档，因此我们可以成功地清除 generate 和 use，这两个属性在归档和回写期间控制消息验证。validated、algorithm 和 hash 属性中的数据仍保留但不会影响文件系统的行为：
root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate use validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~# ssum -d data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
必要时，在对文件归档之前重置任何必需的消息摘要和验证属性。在命令提示符处，输入带有相应选项和文件名的命令 ssum。
在示例中，我们决定在 qndat44 文件上重新启用消息摘要并在归档之前验证摘要。但是，我们不需要在回写之前进行验证。因此，我们恢复 generate 属性但不恢复 use 属性：
root@solaris:~# ssum -g data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
保留要求通常需要使用可确保文件固定性的机制。归档必须既防止发生更改又证明此类更改尚未发生。为了提供固定性，Oracle HSM 归档文件系统将上面讨论的消息摘要和与摘要相关的文件属性与将文件呈现为不可变的额外属性结合使用。在将文件设置为不可变之后，只有具有超级用户授权的用户才能更改文件状态。将不可变性与严格的一次写入多次读取 (Write Once Read Many, WORM) 文件系统结合使用时，即使超级用户也将无法进行更改（有关详细信息，请参见了解 WORM 文件系统）。
您可以按照下面的任一方式将文件设置为不可变：
如果需要确保文件在获取到归档中之后仍保持不变，请执行如下操作。
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -a algorithm [-h digest] -F filename，其中：
-a algorithm 标识在对照所提供的消息摘要验证文件时，文件系统应当使用的加密散列函数。
-h digest 标识文件系统应当用来验证文件的消息摘要。
-F 指定立即验证和不可变性，并设置 fixity、generate、validated 和 use 文件属性。文件系统立即计算并验证消息摘要。在对文件回写或归档之后，文件系统会重新计算并重新验证消息摘要。
filename 是文件的路径和名称。
在示例中，提供了一个 SHA256 摘要并通知文件系统为 data20 文件重新计算摘要、验证摘要值并将该文件设置为不可变。在使用命令 sls -D -h data10 检查文件属性时，我们会发现，对于每个文件，fixity、generate、use 和 validated 文件属性已经设置，algorithm 属性已经设置为 SHA-256，摘要值已经计算而且已经存储在 hash 属性中：
root@solaris:~# ssum -h bfaefde932cf...d450892eda63 -a sha256 -F data20 root@solaris:~# sls -D -h data20 data20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: bfaefde932cf...d450892eda63 root@solaris:~#
如果对已经具有关联消息摘要的文件进行归档并且需要确保文件在获取到归档中之后仍保持不变，请执行如下操作。
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 ssum -a algorithm [-h digest] -F filename，其中：
-a algorithm 标识用来生成 -h digest 参数中所指定的摘要的加密散列函数。
-F 设置 fixity、generate、validated 和 use 文件属性。文件系统立即计算并验证消息摘要。在对文件回写或归档之后，文件系统会重新计算并重新验证消息摘要。
filename 是文件的路径和名称。
在示例中，我们通知文件系统为 data200 文件计算 SHA256 摘要、验证摘要值并将该文件设置为不可变。在使用命令 sls -D -h data10 检查文件属性时，我们会发现，对于每个文件，fixity、generate、validated 和 use 文件属性已经设置，algorithm 属性已经设置为 SHA-256，摘要值已经计算而且已经存储在 hash 属性中：
root@solaris:~# ssum -a sha256 -F data200 root@solaris:~# sls -D -h data200 data200: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: efde93cc12cf...d496602e36dd root@solaris:~#
要查看一个或多个文件的消息摘要和固定性属性，请使用 Oracle HSM 目录列出命令 sls。请执行如下操作。
以 root 用户身份登录到文件系统主机：
root@solaris:~#
在命令提示符处，输入命令 sls -D -h filename，其中：
-D 指定文件属性的详细显示内容。
-h 在显示内容中包含散列（摘要）值。
filename 按路径和名称标识一个或多个文件。
在示例中，可以查看所显示内容的 checksum 和 hash 字段中列出的 data02 文件的文件摘要属性：
root@solaris:~# sls -D -h data02 data02: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate use validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
hash 属性存储 f03ce01b3828...f7459503007e 文件的消息摘要。
algorithm 属性显示 SHA-256 加密散列函数生成了所存储的消息摘要。
generate 属性显示文件系统会在对文件归档时，独立地重新计算消息摘要并对照所存储的值验证摘要值。
use 属性显示文件系统会在对文件回写时，独立地重新计算消息摘要并对照所存储的值验证摘要值。
validated 属性显示在上次检查时，独立计算的消息摘要与 hash 属性中存储的值相匹配。
fixity 属性会在文件设置为不可变时显示。
当法律或归档注意事项要求使用一次写入多次读取 (write-once read-many, WORM) 文件系统时，可以在已经配置为支持 WORM 的任何 Oracle HSM 文件系统中创建 WORM 目录。本节的重点是了解 WORM 文件系统以及在处理 WORM 文件和目录时需要执行的特定任务，其中包括：
有关为文件系统启用 WORM 支持的信息，请参见《Oracle Hierarchical Storage Manager and StorageTek QFS Software 安装和配置指南》。
一次写入多次读取 (Write Once Read Many, WORM) 文件系统通过让用户将文件设置为在指定保持期内只读来保护数据。启用 WORM 的 Oracle HSM 文件系统支持默认的和可定制的文件保持期、数据和路径的不可更改性以及 WORM 设置的子目录继承性。
根据文件系统的配置情况，可以使用两种 Oracle HSM WORM 模式中的一种：
标准符合性模式（默认）
仿真模式
在标准 WORM 模式下挂载的文件系统中，用户通过执行命令 chmod 4000 path_name 针对目录启用 WORM 并为文件启动只读保持期，其中 path_name 是文件或目录的路径和名称。这会设置 UNIX setuid（执行时设置用户 ID）权限。针对同时具有 execute 权限的文件设置 setuid 权限会面临安全风险，因此，在标准 WORM 模式下，只有非可执行文件才能设置为只读。
在 WORM 仿真模式下挂载的文件系统中，用户通过执行命令 chmod 555 path_name 针对目录启用 WORM 并为文件启动只读保持期，其中 path_name 是可写文件或目录的路径和名称。由于仿真模式不需要 setuid 权限，因此可以将可执行文件设置为只读并为其分配保持期。
标准模式和仿真模式具有严格的 WORM 实施和不太严格的轻量级实施。在触发了对文件或目录的保留之后，严格实施和轻量级实施都不允许更改数据或路径。这两个模式均将默认保持期设置为 43,200 分钟（30 天）。但是，轻量级实施会放松对 root 用户的一些限制。
严格实施不允许任何人在保持期结束之前缩短指定的保持期或者删除文件或目录。严格实施也不允许使用 sammkfs 来删除存放当前保留的文件和目录的卷。因此，严格实施适用于满足最严苛的法律、法规遵从性和保留要求。
轻量级实施允许 root 用户使用 sammkfs 命令缩短保持期、删除文件和目录。这会为防止出现数据意外丢失而提供高级别的防护，并在管理文件系统和存储资源时提供更大的灵活性。但是，允许超级用户进行这种程度的控制的文件系统可能无法满足某些法律和法规遵从性要求。
可以创建到 WORM 文件的硬链接和软链接。只能对启用了 WORM 的目录中的文件创建硬链接。创建硬链接后，该链接与原始文件具有同样的 WORM 特征。也可以创建软链接，但软链接无法使用 WORM 功能。可以对 Oracle HSM 文件系统的任何目录中的 WORM 文件创建软链接。
有关创建和配置 WORM 文件系统的完整信息，请参见客户文档库中的《Oracle Hierarchical Storage Manager and StorageTek QFS Software 安装和配置指南》。
在为目录启用 WORM 时，会添加针对 WORM 文件的支持，但不会以其他方式更改目录的特征。用户可以继续创建和编辑启用了 WORM 的目录中的文件，并且可以删除启用了 WORM 但不包含 WORM 文件的目录。要为目录启用 WORM，请执行如下操作：
登录文件系统服务器。
user@solaris:~#
查看目录是否启用了 WORM。使用命令 sls -Dd directory，其中 directory 是目录的路径和名称。在该命令的输出中查找属性 worm-capable。
通常，目录会启用 WORM，因为当用户为目录启用 WORM 时，所有当前的和将来的子目录都将继承 WORM 功能（有关该命令的完整信息，请参见 sls 手册页）。在第一个示例中，我们发现，目标目录 /hsm/hsmfs1/records 已启用 WORM：
user@solaris:~# sls -Dd /hsm/hsmfs1/records/2013/ /hsm/hsmfs1/records/2013: mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1048.1 project: user.root(1) access: Mar 3 12:15 modification: Mar 3 12:15 changed: Mar 3 12:15 attributes: Mar 3 12:15 creation: Mar 3 12:15 residence: Mar 3 12:15 worm-capable retention-period: 0y, 30d, 0h, 0m
但在第二个示例中，目标目录 /hsm/hsmfs1/documents 未启用 WORM：
user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28
如果目录未启用 WORM，但挂载文件系统时使用了 worm_capable 或 worm_lite 挂载选项，则可使用 Solaris 命令 chmod 4000 directory-name 启用 WORM 支持，其中，directory-name 是将存放 WORM 文件的目录的路径和名称。
命令 chmod 4000 为目录设置 setuid（执行时设置用户 ID）属性并启用标准 WORM 支持。在示例中，为目录 /hsm/hsmfs1/documents 启用 WORM 并使用 sls -Dd 检查结果。该操作将成功，而且将针对该目录启用 WORM：
user@solaris:~# chmod 4000 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
如果目录未启用 WORM，但挂载文件系统时使用了 worm_emul 或 emul_lite 挂载选项，则可使用 Solaris 命令 chmod 555 directory-name 启用 WORM 支持，其中，directory-name 是将存放 WORM 文件的目录的路径和名称。
命令 chmod 555 会删除目录的写入权限并启用 WORM 仿真支持。在示例中，为目录 /hsm/hsmfs1/documents 启用 WORM 并使用命令 sls -Dd 检查结果。该操作将成功，而且将针对该目录启用 WORM：
user@solaris:~# chmod 555 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
如果针对启用了 WORM 的目录中的文件激活 WORM 保护，则在保持期内，文件系统不再允许对文件数据或数据路径进行修改。因此，您必须谨慎使用。要激活 WORM 保护，请执行如下操作：
登录文件系统服务器。
user@solaris:~#
如果文件需要保留的期限与文件系统的默认设置不同，可通过更改文件的访问时间来指定所需的保留时间。使用 Solaris 命令 touch -a -texpiration-date path-name，其中：
expiration-date 是一个数字字符串，其中包括四位年、两位月、两位月中日期、两位小时、两位分钟和（可选）两位秒钟。
path-name 是文件的路径和名称。
请注意，Oracle Solaris UNIX 实用程序（如 touch）不能将保持期延长到 2038 年 1 月 18 日下午 10:14 之后。这些实用程序使用带符号的 32 位数字表示自 1970 年 1 月 1 日以来的时间（以秒为单位）。因此，如果需要将文件保留到此截止日期之后，请使用默认保持期。
在示例中，将文件的保持期设置为在 2019 年 10 月 4 日上午 11:59 之后到期：
user@solaris:~# touch -a -t201910141159 /hsm/hsmfs1/plans/master.odt
如果挂载文件系统时使用了 worm_capable 或 worm_lite 挂载选项，则可使用 Solaris 命令 chmod 4000 path-name 激活 WORM 保护，其中 path-name 是文件的路径和名称。
chmod 4000 命令为指定的文件设置 setuid（执行时设置用户 ID）属性。为可执行文件设置此属性是不安全的。因此，如果挂载文件系统时使用了 worm_capable 或 worm_lite 挂载选项，将无法为具有 UNIX execute 权限的文件设置 WORM 保护。
在示例中，为文件 master.odt 激活 WORM 保护。我们使用 sls -D 检查结果，并注意到 retention 属性现在设置为 active，retention-period 设置为四年：
user@solaris:~# chmod 4000 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
如果挂载文件系统时使用了 worm_emul 或 worm_lite 挂载选项，则可使用 Solaris 命令 chmod 555 path-name 激活 WORM 保护，其中 path-name 是文件的路径和名称。
命令 chmod 555 会删除对目录的写入权限。因此，您可以在需要时通过 WORM 保护可执行文件。在该示例中，为文件 master-plan.odt 激活 WORM 保留。我们使用 sls -D 检查结果，并注意到 retention 属性现在设置为 active，retention-period 设置为四年：
user@solaris:~# chmod 555 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
要查找并列出符合指定搜索条件的 WORM 文件，请使用 sfind 命令。执行如下操作：
登录文件系统服务器。
user@solaris:~#
要列出受 WORM 保护并在保持期内的文件，请使用命令 sfind starting-directory -ractive，其中 starting-directory 是需要列表进程开始列举的目录的路径和名称。
user@solaris:~# sfind /hsm/hsmfs1/ -ractive /hsm/hsmfs1/documents/2013/master-plan.odt /hsm/hsmfs1/documents/2013/schedule.ods /samma1/records/2013/progress/report01.odt /samma1/records/2013/progress/report02.odt /samma1/records/2013/progress/report03.odt ... user@solaris:~#
要列出保持期已到期的受 WORM 保护的文件，请使用命令 sfind starting-directory -rover，其中 starting-directory 是需要列表进程开始列举的目录的路径和名称。
user@solaris:~# sfind /hsm/hsmfs1/ -rover /samma1/documents/2007/master-plan.odt /samma1/documents/2007/schedule.ods user@solaris:~#
要列出其保持期在指定日期和时间之后将过期的、受 WORM 保护的文件，使用命令 sfind starting-directory -rafter expiration-date，其中：
starting-directory 是您希望启动列表进程的目录的路径和名称
expiration-date 是一个数字字符串，其中包括四位年、两位月、两位月中日期、两位小时、两位分钟和（可选）两位秒钟。
在示例中，列出保持期将在 2015 年 1 月 1 日午夜后一分钟到期的所有文件：
user@solaris:~# sfind /hsm/hsmfs1/ -rafter 201501010001 /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
要列出必须在文件系统中至少保留指定时间的受 WORM 保护的文件，请使用命令 sfind starting-directory -rremain time-remaining，其中：
starting-directory 是在目录树中开始搜索的位置。
time-remaining 是由非负整数与以下时间单位组成的字符串：y（表示年数）、d（表示天数）、h（表示小时数）、m（表示分钟数）。
在示例中，在目录 /hsm/hsmfs1/ 下查找至少还要保留三年的所有文件：
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
要列出必须在文件系统中保留超过指定时间的受 WORM 保护的文件，请使用命令 sfind starting-directory -rlonger time，其中：
starting-directory 是在目录树中开始搜索的位置。
time-remaining 是由非负整数与以下时间单位组成的字符串：y（表示年数）、d（表示天数）、h（表示小时数）、m（表示分钟数）。
在示例中，在目录 /hsm/hsmfs1/ 下查找将保留三年零九十天以上的所有文件：
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y90d /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
要列出必须在文件系统中永久保留的受 WORM 保护的文件，可使用命令 sfind starting-directory -rpermanent。
在示例中，我们发现，在目录 /hsm/hsmfs1/ 下没有要永久保留的文件：
user@solaris:~# sfind /hsm/hsmfs1/ -rpermanent user@solaris:~#