ここまでこのドキュメントでは、ユーザーとアプリケーションが定期的にファイルの作成、変更、および削除を行う通常の UNIX ファイルシステムとしての Oracle Hierarchical Storage Manager and StorageTek QFS Software ソリューションの管理について説明しました。主に高度に統合されたバックアップサービスとしての役割を果たすアーカイブとともに、ディスクキャッシュに焦点を当てました。この章では、長期間のデータ保存のためのリポジトリおよび管理ソリューションとしてのアーカイブに再度焦点を当てます。以前に説明した管理の原則と手法が引き続き関係します。ただし現在では、ディスクキャッシュは主に、取り込み後に削除や変更が可能ではないアーカイブにファイルを取り込む手段としての役割を果たします。
正確な要件は条件によって異なります。法で定められた期間業務記録または医療記録を保持するリポジトリは、定期的な記録の破棄が必要になる場合があります。ただし、科学データ、歴史的記録や家系の記録、デジタル音楽、映画、またはテレビ番組を格納するアーカイブは、事実上永続的な内容の格納が必要になる場合があります。このため、Oracle HSM では、複数の方法でデジタル保存をサポートします。
メッセージダイジェスト (チェックサム) を使用すると、損害、データ破損、およびファイルに対する未承認の変更を検出できるため、ハードウェアの問題を修正して、異常なファイルを、アーカイブの別の場所に格納されている正常なコピーと置き換えることができます。
ファイルの fixity 属性は、修正されたファイルを変更できるのがスーパーユーザーだけになるようにメッセージダイジェストを処理します。Oracle HSM は、固定ファイルをステージングまたはアーカイブするたびに、このファイルが変更されていないことを証明するために、fixity 属性とともに格納されたチェックサムを再検証します。
Oracle HSM Write Once Read Many (WORM) ファイルシステムを使用すると、ファイルを読み取り専用にして、指定された期間の保持を適用できます。これらのファイルシステムは、スーパーユーザーがファイルや、前述した fixity 属性などのファイル属性を変更できないように構成できます。
この章では、長期間のストレージソリューションのベースとなる基本的な Oracle HSM データ保護対策を簡単に見直すことから始めます (「保存用ファイルシステムの構成」)。その後、特にデータの保存に対処するタスクについて説明します。
すべての保存ソリューションが、正常な冗長性の高いファイルシステムから始まります。そのため、付属の『Oracle Hierarchical Storage Manager and StorageTek QFS インストールおよび構成ガイド』の実装の章をまだ確認していない場合は、この章を確認します。冗長なサーバー、ネットワーク接続、およびストレージデバイスを提供することで、アーカイブへのアクセスを保護します。それぞれが独立したメディアに格納された各ファイルの追加のコピーを少なくとも 2 つ構成することで、ファイルデータを保護します。ほとんどの場合、1 つのコピーをディスクまたはソリッドステートストレージデバイスにアーカイブして、2 つのコピーをテープメディアにアーカイブすることが理想的です。可能な場合は、Oracle HSM のデータ整合性の検証機能を実装することで、テープブロックが正しく読み書きされていることを確認します。定期的にダンプファイルを生成して、アーカイブログを定期的にバックアップすることで、ファイルシステムのメタデータを保護します。
メッセージダイジェスト (チェックサム) を使用すると、保存担当者は、段階的な劣化、ハードウェアまたはオペレータのエラー、または内容に対する故意の承認されていない変更を示す可能性がある変更についてアーカイブ済みファイルをテストできます。メッセージダイジェストは単に、一方向の暗号化ハッシュ関数によって生成されたファイルの内容の数学上のサマリーです。暗号化ハッシュ関数は、その入力データでの変更に対して非常に敏感です。入力のわずかな変更であっても、出力が大きく変更されます。そのためメッセージダイジェストは、ファイルの破損と承認されていない変更を検出するうえで理想的です。ファイルのダイジェストを再計算して、格納されているダイジェスト値と結果の値を比較することで、ファイルが変更されたかどうかが示されます。
Oracle Hierarchical Storage Manager ファイルシステムは、次のいずれかの暗号化ハッシュ関数を使用して、メッセージダイジェストの取り込み、作成、格納、および検証を行うことができます。
暗号化関数の Secure Hash Algorithm ファミリの 160 ビットメンバーである SHA1
Secure Hash Algorithms は、連邦情報処理標準 (Federal Information Processing Standard、FIPS) の資料 180-4、米国国立標準技術研究所 (2012 年) で定義されています。Oracle HSM ではデフォルトで SHA1 が使用されます。
Secure Hash Algorithm ファミリの 256 ビットメンバーである SHA256
Secure Hash Algorithm ファミリの 384 ビットメンバーである SHA384
Secure Hash Algorithm ファミリの 512 ビットメンバーである SHA512。
Request for Comment (RFC) 1321 で Internet Engineering Task Force (IETF) によって定義された 128 ビットのメッセージダイジェスト関数である MD5
現在では主に古い Storage Archive Manager 実装との下位互換性のために役に立つ、独自の 128 ビットの Oracle HSM 関数。
ユーザーは、ファイルがリポジトリに取り込まれたときに既存のダイジェスト値を指定することも、即時に、またはファイルが最初にアーカイブされたときに、ファイルシステムにダイジェスト値を計算させることもできます。Oracle HSM ファイルシステムは、特殊なファイル属性を使用して、ファイルシステムメタデータとともにダイジェスト値を格納します。属性の設定後、対応するファイルが再アーカイブされるたびに、またオプションでファイルがアーカイブメディアからディスクキャッシュにステージングされるたびに、ファイルシステムはダイジェストを再計算し、格納されている値と照合して検証します。
ただし、Oracle HSM メディアの移行機能は、チェックサムを再計算せずにファイルを新しいメディアにコピーします (メディアの移行については、第8章 新しいストレージメディアへの移行を参照)。そのために、ファイルが正しくコピーされなかった場合、ファイルが再ステージングされて検証されるまで、破損が検出されないリスクがわずかに発生します。データ整合性検証 (DIV) を使用することで、このリスクが最小限に抑えられます (詳細は、『Oracle Hierarchical Storage Manager and StorageTek QFS インストールおよび構成ガイド』を参照)。
メッセージダイジェストの使用を開始する前に、最初に「ファイルシステムホストのパフォーマンスが適切であることの確認」を読むようにしてください。その後、ダイジェストの指定、生成、および検証の手順について次のセクションを参照できます。
メッセージダイジェストを大いに利用する予定がある場合、適切なパフォーマンスを実現するために十分な計算リソースがファイルシステムホストにあることを確認してください。ほとんどの最新のプラットフォームでは、中央のプロセッササイクルを消費することなく、特殊な計算を効率的に実行できる専用の暗号化ハードウェアが組み込まれています。可能な場合は、これらの機能を必ず活用してください。
潜在的なファイルシステムホストの機能をチェックするには、次のように進めます。
ファイルシステムホストに 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 システムである場合、isainfo -v コマンドの出力に ssse3 (Supplemental Streaming SIMD Extensions 3) 命令セットが含まれていれば、SHA-1 ハードウェアアクセラレーションがサポートされます。
この例では、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 属性を更新しました。変更されていないファイルのコピーは、アーカイバが copy 2 を作成する時間になるまで、S (無効) フラグが付けられたままテープ上に残ります。
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 属性を更新しました。変更されていないファイルのコピーは、アーカイバが copy 2 を作成する時間になるまで、S (無効) フラグが付けられたままテープ上に残ります。
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:~#
2 番目の例では、アーカイブ前に、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 は、ファイルのパスと名前です。
この例では、SHA256 ダイジェストを計算して、ファイル data200 の値を検証し、ファイルを不変にするようにファイルシステムに指示します。コマンド 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:~#
1 つ以上のファイルのメッセージダイジェストと fixity 属性を表示するには、Oracle HSM のディレクトリ一覧表示コマンド sls を使用します。次のように進めます。
ファイルシステムホストに root としてログインします。
root@solaris:~#
コマンドプロンプトで、コマンド sls -D -h filename を入力します。ここでは:
-D は、ファイル属性の詳細表示を指定します。
-h は、表示にハッシュ (ダイジェスト) 値を含めます。
filename は、パスと名前で 1 つ以上のファイルを識別します。
この例では、表示の 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) ディレクトリとファイルをサポートするように構成された Oracle HSM ファイルシステムでこれらのディレクトリとファイルを作成できます。このセクションでは、WORM ファイルシステムと、次を含む、WORM ファイルとディレクトリの操作時に実行する必要がある特定のタスクの理解に焦点を当てます。
ファイルシステムの WORM サポートの有効化については、『Oracle Hierarchical Storage Manager and StorageTek QFS インストールおよび構成ガイド』を参照してください。
Write Once Read Many (WORM) ファイルシステムは、指定された保持期間ユーザーがファイルを読み取り専用にできるようにすることでデータを保護します。WORM 対応の Oracle HSM ファイルシステムでは、デフォルトおよびカスタマイズ可能なファイル保持期間、データとパスの不変性、および WORM 設定のサブディレクトリの継承がサポートされます。
ファイルシステムの構成方法に応じて、次の 2 つの Oracle HSM WORM モードのうちの 1 つを使用します。
標準のコンプライアンスモード (デフォルト)
エミュレーションモード
標準の 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 対応rディレクトリ内にあるファイルとのハードリンクのみを作成できます。作成されたハードリンクは、元のファイルと同じ WORM 特性を持ちます。ソフトリンクも作成できますが、ソフトリンクでは WORM 機能を使用できません。WORM ファイルへのソフトリンクは、Oracle HSM ファイルシステム内の任意のディレクトリに作成できます。
WORM ファイルシステムの作成および構成の詳細は、お客様向けドキュメントライブラリの『Oracle Hierarchical Storage Manager and StorageTek QFS インストールおよび構成ガイド』を参照してください。
ディレクトリを 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
ただし、2 番目の例では、ターゲットディレクトリ /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 は、4 桁の年、2 桁の月、2 桁の日、2 桁の時間、2 桁の分、オプションで 2 桁の秒で構成される数字の文字列です。
path-name は、ファイルのパスと名前です。
touch などの Oracle Solaris UNIX ユーティリティーは、2038 年 1 月 18 日午後 10:14 を超えて保持期間を延長できません。これらのユーティリティーは、符号付き 32 ビット数値を使用して、1970 年 1 月 1 日から秒単位で時間を表します。そのため、この期限を超えてファイルを保持する必要がある場合、デフォルトの保持期間を使用してください。
この例では、4 年後の 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 が 4 年に設定されていることを確認します。
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 または emul_lite マウントオプションを使用してマウントされた場合、Solaris コマンド chmod 555 path-name を使用して WORM 保護をアクティブにします。path-name は、ファイルのパスと名前です。
コマンド chmod 555 によって、ディレクトリの書き込みアクセス権が削除されます。そのため、必要に応じて実行可能ファイルを WORM 保護できます。次の例では、ファイル master-plan.odt の WORM 保持をアクティブにします。sls -D を使用して結果をチェックして、retention 属性が現在は active に設定され、retention-period が 4 年に設定されていることを確認します。
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 は、4 桁の年、2 桁の月、2 桁の日、2 桁の時間、2 桁の分、オプションで 2 桁の秒で構成される数字の文字列です。
次の例では、2015 年 1 月 1 日午前 12:01 のあとで保持期間が期限切れになるファイルを一覧表示します。
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 (分) とペアになった、負ではない整数の文字列です。
この例では、少なくともさらに 3 年間保持される、ディレクトリ /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 (分) とペアになった、負ではない整数の文字列です。
この例では、3 年と 90 日を超えて保持される、ディレクトリ /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:~#