この章では、個々のファイルをファイルシステムに復元する手順の概要について説明します。トピックは、次のとおりです。
損失または破損したファイルを回復する方法として、回復ポイントファイルはもっとも速く、もっとも信頼性が高く、もっとも徹底されていて、もっとも労力がかかりません。したがって、回復ポイントファイルを使用できる場合は、次の手順に従います。
ファイルシステムのメタデータサーバーに 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
最新の使用可能な回復ポイントファイルを特定します。
この例では、ファイルシステム hsmfs1 の日付付きの回復ポイントファイルを、独立したファイルシステム /zfs1 上のサブディレクトリ hsmfs1_recovery という既知の場所に作成してきました。そのため、最新のファイル (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" にパイプします (次のコマンドは 1 行で入力し、改行はバックスラッシュ文字でエスケープします)。
root@solaris:~# samfsrestore -t -f /zfs1/hsmfs1_recovery/20150324 | \ grep "genw445" ./genfiles/genw445 root@solaris:~#
ファイルの i ノードを現在のディレクトリに復元します。コマンド samfsrestore -f recovery-point file を使用します。ここでは:
-f recovery-point-file は、選択した回復ポイントファイルのパスおよびファイル名を指定します。
file は、回復するファイル用に回復ポイントファイルが一覧表示する正確なパスと名前を指定します。
この例では、回復ポイントファイル /zfs1/hsmfs1_recovery/20150324 から ./genfiles/genw445 を回復します (下のコマンドが 1 行として入力され、改行はバックスラッシュ文字でエスケープされています)。
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
2 番目の例では、通常 (タイプ 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
必要なファイルのログエントリを見つけたら、メディアタイプ、メディアのボリュームシリアル番号、およびファイルシステムのルートディレクトリに対するファイルの相対パスおよび名前をメモします。
最初の例では、ボリュームシリアル番号 (VSN) VOL004 を持つ LTO (li) テープボリューム内にファイル genA0 があります。このファイルはもともと、ファイルシステムディレクトリ /hsmfs1/genfiles/ に格納されていました。
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
2 番目の例では、ボリュームシリアル番号 DISKVOL1 を持つディスクアーカイブ (dk) 内にファイル spcC4 があります。このファイルはもともと、ファイルシステムディレクトリ /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) ファイルの開始位置を表す 16 進数値もメモします。
この例では、位置 0x212 (212) から始まるテープにファイル genA0 があります。
A 2015/03/03 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0
必要なファイルがランダムアクセスメディア (アーカイブディスクなど) に格納されている場合は、ボリュームシリアル番号に対する tar ファイルの相対パスおよびファイル名もメモします。
この例では、ディスクボリューム DISKVOL1 のルートディレクトリ直下の f2 サブディレクトリ内にファイル spcC4 があります。
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 バージョンで、指定されたファイルをアーカイブファイルから復元します。
この例では、データファイル socfiles/spcC4 を tar ファイル DISKVOL1/f2 から抽出します。このファイルは、/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 に一覧表示されている 2 文字のメディアタイプコードの 1 つを指定します。
-v volume-serial-number は、メディアボリュームを識別する 6 文字の英数字コードを指定します。
-p 0xposition は、アーカイバログエントリ内の、メモした 16 進数の開始位置を指定します。
path は、一時回復ディレクトリのパスです。
requestfile は、request コマンドでメディアから読み込むメモリー内 tar ファイルに使用する名前です。
この例では、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 バージョンで、指定されたファイルを要求ファイル (アーカイブファイルのメモリ内コピー) から復元します。
この例では、データファイル genfiles/genA0 を、要求ファイル tars/currentrequest から抽出します。このファイルは、/hsmfs1/genfiles/genA0 に復元されます。
root@solaris:~# star -xvf tars/currentrequest genfiles/genA0
必要なファイル属性を設定します。
samfsdump または qfsdump 回復ポイントファイルを使用せずにファイルを tar ファイルから復元すると、元のファイル属性が失われます。ファイルの .inodes ファイルをデフォルトの属性値を使用して新規に作成する必要があります。
すべての必要なファイルが回復されるまで、この手順を繰り返します。
必要に応じて、紛失および破損したセグメント化ファイルまたはボリュームオーバーフローファイル、あるいはその両方を復元します。
それ以外の場合は、回復手順を終了します。アーカイブファイルシステムの通常運用への復元を参照してください。
セグメント化ファイルの復元は、通常ファイルの復元とよく似ています。ただし、ファイルそのものではなく個々のセグメントを回復します。そのため、ファイルを復元するには、セグメントを 1 つのファイルに結合してから、その結果を再度セグメント化する必要があります。回復が必要な各ファイルについて、次のように進めます。
ファイルシステムメタデータサーバーに 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) ファイルの 16 進数の開始位置
ファイルシステムのルートディレクトリに対するセグメント化ファイルの相対パスおよび名前
ファイル内のセグメント数。
この例では、ファイル dat011 が 3 つのセグメント (1、2、および 3) に分割されています。3 つのセグメントは 3 つのアーカイブファイルに格納されており、これらのファイルはすべて単一の LTO (li) テープボリューム (ボリュームシリアル番号 VOL013) にあります。3 つのアーカイブファイルは、位置 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
1 つまたは複数のファイルセグメントのアーカイブされたコピーを保持する各アーカイブファイルの先頭にメディアを配置し、アーカイブをメディアからメモリーに読み込みます。コマンド request -m media-type -v volume-serial-number -p 0xposition path/requestfile を使用します。ここでは:
-m media-type は、付録B に一覧表示されている 2 文字のメディアタイプコードの 1 つを指定します。
-v volume-serial-number は、メディアボリュームを識別する 6 文字の英数字コードを指定します。
-p 0xposition は、アーカイバログエントリ内の、メモした 16 進数の開始位置を指定します。
path は、一時回復ディレクトリのパスです。
requestfile は、request コマンドでメディアから読み込むメモリー内 tar ファイルに使用する名前です。
この例では、2 つの要求ファイルを作成する必要があります。最初の /hsmfs1/tars/request76a は、LTO (li) VOL013 上の位置 0x76a から開始するアーカイブファイルをロードします。このアーカイブには、最初の 2 つのセグメントが両方とも含まれます。2 番目の要求ファイル /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 バージョンで、指定されたファイルを要求ファイルでポイントしているアーカイブファイルから復元します。
この例では、データファイル bf/dat011 の 3 つのセグメントのうち 2 つを要求ファイル (メモリー内 tar ファイル) tars/request76a から、1 つを要求ファイル tars/request1409aa4 から抽出します。このファイルは、ディレクトリ /hsmfs1/bf/dat011/ に 3 つの部分に分けて復元されます。
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 の内容を一覧表示すると、復元されたセグメントごとに 1 つの通し番号が付けられたファイルが表示されます。
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:~#
復元されたセグメントをセグメント化されていない 1 つの一時ファイルに結合します。
この例では、/hsmfs1/bf/dat011/ ディレクトリ内の 3 つのセグメントを連結して、ファイル /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 であることがアーカイバログファイルで示されています (ファイルは 3 つめのセグメントで終了するため、メディア上のデータの長さはセグメントの長さ未満になります)。
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
その他の必要なファイル属性を設定します。
samfsdump または qfsdump 回復ポイントファイルを使用せずにファイルを tar ファイルから復元すると、元のファイル属性が失われます。ファイルの .inodes ファイルをデフォルトの属性値を使用して新規に作成する必要があります。
これでファイルが復元されました。セグメント化されていない一時ファイルを削除します。
この例では、dat011file を削除します。
root@solaris:~# rm /hsmfs/bf/dat011file root@solaris:~#
すべての必要なファイルが回復されるまで、この手順を繰り返します。
回復手順を終了します。アーカイブファイルシステムの通常運用への復元を参照してください。
ボリュームオーバーフローファイルとは、複数のメディアボリュームにまたがる通常ファイルです。そのため、ボリュームオーバーフローファイルの復元は、その他の通常ファイルの復元とよく似ています。ただし、データファイルをアーカイブから抽出する前に、複数のボリューム上にあるアーカイブファイルのセクションを結合して、ディスク上で 1 つのアーカイブファイルにする必要があります。そのため、回復が必要な各ファイルについて、次のように進めます。
ファイルシステムメタデータサーバーに root してまだログインしていない場合は、ログインします。
root@solaris:~#
アーカイブおよびリサイクルをまだ停止していない場合は、アーカイブ処理およびリサイクル処理プロセスの停止の手順で停止します
ボリュームオーバーフローファイルが最後にアーカイブされた期間のアーカイバログがある場合は、そのファイルの最新のエントリを検索します。メディアのボリュームシリアル番号、ファイルの各セクションの長さ、ファイルシステムのルートディレクトリに対するファイルの相対パスおよび名前、およびファイルのセクション数をメモします。
この例では、ファイル /hsmfs1/rf/rf81 は、2 つのボリューム VOL036 と VOL034 上に存在する通常のタイプ f ファイルであり、2 つのセクション 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
先に進む前に、回復しているファイルのサイズの少なくとも 2 倍のファイルを格納できる十分な空き領域がファイルシステムにあることを確認します。
この例のファイル rf/rf81 では、ファイルの 2 つのセクションのサイズに基づくと 2 x (89128448 + 525271552) = 1228800000 バイトとなり、約 1.2G バイトの空き領域が必要です。
復元されたファイルシステムに一時アーカイブファイルを保持するためのディレクトリを作成します。
この例では、ディレクトリ /hsmfs1/tars を作成します。
root@solaris:~# mkdir /hsmfs1/tars
1 つまたは複数のファイルセグメントのアーカイブされたコピーを保持する各アーカイブファイルの先頭にメディアを配置し、アーカイブをメディアからメモリーに読み込みます。コマンド request -m media-type -v volume-serial-number -p 0xposition path/requestfile を使用します。ここでは:
-m media-type は、付録B に一覧表示されている 2 文字のメディアタイプコードの 1 つを指定します。
-v volume-serial-number は、メディアボリュームを識別する 6 文字の英数字コードを指定します。
-p 0xposition は、アーカイバログエントリ内の、メモした 16 進数の開始位置です。
path は、一時回復ディレクトリのパスです。
requestfile は、request コマンドでメディアから読み込むメモリー内 tar ファイルに使用する名前です。
この例では、2 つの要求ファイルを作成します。最初の要求ファイル /hsmfs1/tars/requestVOL036 は、LTO (li) VOL036 上の位置 0x12d から開始するアーカイブファイルをロードします。2 番目の要求ファイル /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:~#
セクションを 1 つのアーカイブファイルに結合します。
この例では、2 つのセクション tars/archive_part1 および tars/archive_part2 を連結して、1 つのアーカイブファイル /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 バージョンで、指定されたファイルを要求ファイルでポイントしているアーカイブファイルから復元します。
この例では、ボリュームオーバーフローファイル rf/rf81 を tar ファイル tars/archive_complete から抽出します。
root@solaris:~# star -xvf tars/archive_complete rf/rf81
その他の必要なファイル属性を設定します。
samfsdump または qfsdump 回復ポイントファイルを使用せずにファイルを tar ファイルから復元すると、元のファイル属性が失われます。ファイルの .inodes ファイルをデフォルトの属性値を使用して新規に作成する必要があります。
これでボリュームオーバーフローファイルが復元されました。一時ファイルを削除します。
この例では、dat011file を削除します。
root@solaris:~# rm tars/archive_* root@solaris:~#
すべての必要なファイルが回復されるまで、この手順を繰り返します。
回復手順を終了します。アーカイブファイルシステムの通常運用への復元を参照してください。
破損したアーカイブコピーとは、ディスクキャッシュに書き戻せないファイルのコピーです。単に断続的なハードウェア関連の入出力問題が原因でファイルを書き込めないことがありますが、これは簡単に解決できます。また、破損したコピーが壊れていて、データが回復不可能なこともあります。このような場合の唯一のオプションは、ファイルを代替コピーから回復することです。
破損したコピーを特定および管理するには、次のように進めます。
破損したアーカイブコピーがあるファイルを特定します。コマンド sfind mountpoint -any_copy_d (mountpoint は、回復したファイルシステムがマウントされるディレクトリ) を使用します。
この例では、ディレクトリ /hsmfs1 で検索を開始し、破損したコピーを含む 3 つのファイルを見つけます。
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 の別の破損していないコピーがあるため、破損したコピー copy 2 をアーカイブ解除します。
root@solaris:~# unarchive -c 2 /hsmfs1/genfiles/ab09 root@solaris:~#
別のコピーがない場合は、破損したコピーを破損していない状態にします。コマンド undamage -cCopyNumber file (CopyNumber はコピー番号を表す整数、file は破損したファイルのパスおよびファイル名) を使用します。
断続的なハードウェア関連の入出力エラーが原因でファイルを書き込めないことがあります。破損フラグをクリアして再書き込みすると、問題が解決することがあります。この例では、/hsmfs1/genfiles/ab11 のコピーは 1 つしかありません。
root@solaris:~# undamage -c1 /hsmfs1/genfiles/ab11
コピーの書き込みを試みます。コマンド stage -c CopyNumber -I file (CopyNumber はコピー番号を表す整数、file はファイルのパスおよびファイル名) を使用します。
オプションの -I (即時) パラメータは、書き込み操作をキューの先頭にプッシュします。
root@solaris:~# stage -c 1 -I /hsmfs1/genfiles/ab11
書き込みが成功した場合は、ここで中止します。
書き込みが再度失敗した場合、Oracle HSM は破損フラグを再度設定します。破損したコピーに対する sls -D コマンドの出力における i ノードのメジャー番号をメモします。
この例では、ファイル /hsmfs1/genfiles/ab11 の i ノード番号は 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:~#
考えられる原因を探します。まず、破損したコピーのあるファイルの i ノードに関係する書き込み関連メッセージを Oracle HSM /var/adm/sam-log ファイルで確認します。
検索は、さまざまな方法で実行できます。この例では、Solaris cat コマンドを使用してログファイルの内容を一覧表示し、出力を grep および i ノード番号と照合する正規表現にパイプ処理します。2 つのメッセージを探します。両方とも入出力エラーを示していて、1 つはテープドライブのうちの 1 つの装置 (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 コマンド (ログエントリを使用したファイルの回復 を参照) または tar や dd などの Solaris ユーティリティーを使用して、コピーの回復を試みます。
それでもファイルを回復できず、データの値が妥当であれば、データ回復サービスを利用します。Oracle StorageTek テープメディアによる支援が必要な場合は、Oracle StorageTek Enterprise Tape Data Recovery サービスを利用します。My Oracle Support (support.oracle.com) にログインします。「サービス・リクエスト」を開き、リクエストカテゴリにあるリストからテープドライブモデルを選択し、サブカテゴリにあるリストからメディアの問題を選択します。
ファイルが回復不可能であると判明した場合は、破損したコピーをアーカイブ解除します。コマンド unarchive -c CopyNumber file (CopyNumber はコピー番号を表す整数、file は破損したファイルのパスおよびファイル名) を使用します。
root@solaris:~# unarchive -c 1 /hsmfs1/genfiles/ab11 root@solaris:~#
ログファイルで明らかなドライブまたはメディアの問題がある場合は解決します。
アーカイブ処理、ステージング処理、およびリサイクル処理を無効にしていた場合は、ここでふたたび有効化します。アーカイブファイルシステムの通常運用への復元を参照してください。
それ以外の場合は、ここで終了します。