このセクションでは、Oracle HSM ファイルシステムが破損または損失したときに使用する回復プロセスについて概要を説明します。手順は、該当するファイルシステムのタイプ、および実行したバックアップと回復の準備のタイプによって異なります。しかし、実行する必要のある基本タスクには 2 つあります。
開始する前に、次の点に注意してください。Oracle HSM メタデータサーバーの損失から回復している場合は、先に進む前に、第3章の説明に従って Oracle HSM 構成の復元を完了していることを確認してください。この章の手順では、ファイルシステムの損失前に Oracle HSM ソフトウェアがインストールおよび構成されていることを前提としています。
ファイルおよびディレクトリを回復する前に、それらを配置する場所が必要です。そのため、回復プロセスの 1 つめのステップは、空の代替ファイルシステムを作成することです。次のように進めます。
sammkfs コマンドを使用したファイルシステムの再作成ファイルシステムのメタデータサーバーに root としてログインします。
root@solaris:~#
ファイルシステムが現在マウントされている場合は、アンマウントします。コマンド umount mount-point (mount-point は、ファイルシステムがマウントされているディレクトリ) を使用します。
この例では、ファイルシステム /hsmfs1 をアンマウントします。
root@solaris:~# umount /hsmfs1 root@solaris:~#
テキストエディタで /etc/opt/SUNWsamfs/mcf ファイルを開きます。ハードウェア構成を確認します。ハードウェアを変更する必要があった場合は、ファイルを適宜編集し、変更を保存します。
この例では、2 つの障害のあるディスクデバイスの装置 ID を代替デバイスの装置 ID と交換します。装置番号は変化しないことに注意してください。
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 はデバイスの未指定の問題を報告します。これは、装置 ID フィールドの入力ミスである可能性があります。
root@solaris:~# sam-fsd Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem qfsms sam-fsd: Problem with file system devices.
通常、このようなエラーの原因は不注意なタイプミスです。ここで、エディタで mcf ファイルを開くと、デバイス 102 (2 番目の md デバイス) の装置名のスライス番号の部分に 0 ではなく文字 o を入力したことがわかりました。
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:~#
mcf ファイルを読み取り、適宜再構成を実行するよう、Oracle HSM ソフトウェアに指示します。
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:~#
次に、ディレクトリおよびファイルの復元を開始します。
ベースファイルシステムを再作成したら、ディレクトリおよびファイルの復元を開始できます。2 つの方法が考えられます。
定期的に回復ポイントを作成し、安全に格納している場合は、samfsdump (qfsdump) 回復ポイントファイルからのファイルおよびディレクトリの復元が間違いなく最適なオプションです。
この方法は、ファイルシステムのメタデータを復元するため、ファイルシステムがただちにフル機能に戻ります。アーカイブファイルシステムは、ユーザーがファイルにアクセスしたときには、ただちにまたは必要に応じてアーカイブメディア上のファイルに迅速にアクセスして、ファイルをディスクキャッシュに書き戻すことができます。ファイルは元の属性で復元されます。
回復ポイントにデータとメタデータが含まれる場合、この方法は、サードパーティーアプリケーションによってバックアップされていないスタンドアロン (非アーカイブ) ファイルシステムを復元する唯一の方法でもあります。
回復スクリプトと Oracle HSM star ユーティリティーを使用した、回復ポイントファイルなしでのアーカイブメディアからのファイルおよびディレクトリの復元。
samfsdump (qfsdump) 回復ポイントファイルからのファイルおよびディレクトリの復元可能なかぎり、もっとも最新の回復ポイントファイルを基にファイルシステムの回復を行なってください。Oracle HSM ファイルシステムの障害から回復する方法として、この方法は間違いなくもっとも速く、もっとも信頼性が高く、もっとも徹底されていて、もっとも労力がかかりません。したがって、回復ポイントファイルが存在する場合は、次の手順に従います。
ファイルシステムのメタデータサーバーに root としてログインします。
root@solaris:~#
アーカイブおよびリサイクルをまだ停止していない場合は、アーカイブ処理およびリサイクル処理プロセスの停止の手順で停止します。
最新の使用可能な回復ポイントファイルを特定します。
この例では、ファイルシステム hsmfs1 の日付付きの回復ポイントファイルを、独立したファイルシステム /zfs1 上のサブディレクトリ hsmfs1_recovery という既知の場所に作成してきました。そのため、最新のファイル (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 で指定されるファイルに保存します。
アーカイブファイルシステムを復元している場合は、このファイルをアーカイブメディアからファイルを自動で書き込むために使用することができるため、ディスクキャッシュは回復ポイントが作成された時点と同じ状態になります。
この例では、ファイルシステム hsmfs1 を回復ポイントファイル /zfs1/hsmfs1_recovery/20140324 から復元します。オンラインファイルをファイル /root/20140324.log に記録します (次のコマンドは 1 行で入力し、改行はバックスラッシュ文字でエスケープします)。
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 装置タイプの用語集で説明されている 2 桁のコードのいずれかであり、vsn はソースボリュームの 6 文字の英数字のボリュームシリアル番号です。
メディア移行ログの形式はアーカイバログと同じ回復情報を含んでいるため、同じ方法で使用できます。これらの形式のいくつかの違いについては、付録A アーカイバおよび移行ログの理解を参照してください。
新しく復元したファイルシステムで、破損ファイルを特定します。コマンド sfind mountpoint -damaged (mountpoint は、回復したファイルシステムがマウントされるディレクトリ) を使用します。
この例では、ディレクトリ /hsmfs1 で検索を開始し、6 個の破損ファイルを見つけます。
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 のエントリを探します。このログエントリは、2015 年 3 月 4 日の午後 9:49 に LTO (li) ボリューム VOL012 を使用してアーカイブされた (A) ことを示しています。ファイルは、16 進数の位置 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 装置タイプの用語集で説明されている 2 桁のコードのいずれかであり、vsn はソースボリュームの 6 文字の英数字のボリュームシリアル番号です。
メディア移行ログの形式はアーカイバログと同じ回復情報を含んでいるため、同じ方法で使用できます。これらの形式のいくつかの違いについては、付録A アーカイバおよび移行ログの理解を参照してください。
アーカイバログの最新のコピーで、回復ポイントが作成されたあとに作成されたエントリを検索します。コマンド grep "time-date-expression" archiver-log (time-date-expression は検索を開始する日時と一致する正規表現、archiver-log は調べているアーカイバログのコピーのパスおよび名前) を使用します。
この例では、2015 年 3 月 24 日の午前 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 として一覧表示されます。メディアタイプは、2 文字のコードです (付録B 装置タイプの用語集 を参照)。
バックアップコピーを探すには、コピーを格納するメディアボリュームのボリュームシリアル番号が必要です。コピーが順次アクセスメディア (磁気テープなど) に格納されている場合は、アーカイブ (tar) ファイルの開始位置を表す 16 進数値もメモします。コピーがランダムアクセスメディア (アーカイブディスクなど) に格納されている場合は、ボリュームシリアル番号に関連する 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:~#
次の情報に注意してください。
8 つの通常 (タイプ f) ファイルは、LTO (li) メディア上にアーカイブ (A) されています。genfiles/hops および genfiles/anic はボリューム VOL002 の位置 0x111、genfiles/genA0、genfiles/genA9、および genfiles/genA2 はボリューム VOL004 の位置 0x212、genfiles/genA13、genfiles/genA4、および genfiles/genA45 はボリューム VOL003 の位置 0x212 にあります。
2 つの通常 (タイプ f) ファイルは、ディスク (dk) メディア上にアーカイブ (A) されています。spcfiles/spcC4 および spcfiles/spcC5 はボリューム DISKVOL1 のアーカイブファイル DISKVOL1 \f2 にあります。
1 つの 3 分割されたセグメント化 (タイプ S) ファイルは、LTO (li) メディア上にアーカイブされています。bf/dat011 はボリュームVOL013 の位置 0x76a から始まる 2 セグメント内、および位置 1409aa4 から始まる 1 セグメント内にあります。セグメント /1 は 10485760 バイト、セグメント /2 は 10485622 バイト、セグメント /3 は 184 バイトの長さがあります。
1 つの通常 (タイプ f) ボリュームオーバーフローファイルは、LTO (li) メディア上にアーカイブ (A) されています。rf/rf81 はボリューム VOL036 の位置 0x12d から始まり、ボリューム VOL034 の位置 0x15f から続行します。
アーカイバログエントリのフィールドの詳細については、付録A アーカイバおよび移行ログの理解を参照してください。
回復ポイントファイルの作成後に作成されたバックアップアーカイブログを使用して、検索を繰り返します。
アーカイバログは、頻繁にロールオーバーされます。そのため、複数のアーカイバログのコピーを保持すると、現在のアーカイバログの対象期間よりも前に作成されたアーカイブのコピーを使用して、破損ファイルを回復できる可能性があります。
メディアボリュームおよびアーカイブ (tar) ファイルのメディアでの位置がわかれば、不明ファイルや破損ファイルの復元は、単に tar ファイルにアクセスして必要なデータファイルを抽出するだけで済みます。アーカイブファイルがアーカイブディスクデバイス上に存在するときは、tar ファイルはファイルシステムマウントポイント下のランダムアクセス可能なディレクトリにあるので、簡単な作業です。しかし、tar ファイルがテープのような大容量の順次アクセスメディア上にあるときは、複雑さが増します。通常は、アーカイブファイルがランダムアクセスディスクデバイスに書き込まれるまで、アーカイブファイルから必要なデータファイルを抽出できません。アーカイブファイルは大きくなる可能性があるため、これでは回復時に時間がかかり、扱いにくいことがあります。そのため、次の手順では Oracle HSM コマンド request を使用してアーカイブファイルをメモリーに読み込み、ディスクから読み取っているかのように利用できるようにします。
できるだけ多くの破損または不明の通常ファイルを復元します。ファイルごとに次の手順を実行します。
複数のボリュームにまたがっていない通常ファイルの回復から開始します。紛失および破損した通常ファイルの復元の手順を使用します。
次にセグメント化ファイルを回復します。紛失および破損したセグメント化ファイルの復元の手順を使用します。
次に、ボリュームにまたがる通常ファイルを復元します。紛失および破損したボリュームオーバーフローファイルの復元の手順を使用します。
コピーがあるすべての不明ファイルおよび破損ファイルを復元したら、archiver.cmd ファイルから wait ディレクティブを削除してアーカイブを再度有効にします。recycler.cmd ファイルから -ignore パラメータを削除してリサイクルを再度有効にします。
ファイルシステムは、可能なかぎり元の状態に近づきます。これでも破損または不明なファイルは、回復できません。
コピーのある欠落または破損したファイルをすべて復元したら、アーカイブファイルシステムの通常運用への復元に進みます。
回復ポイントファイルの支援なしでファイルシステムをアーカイブメディアから直接回復する必要がある場合は、そのように実行できます。次のように進めます。
ファイルを光学メディアから復元しようとする場合は、ここで作業を中止して、Oracle サポートサービスに連絡してください。
ファイルシステムのネットワークファイルシステム (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 を探します。その値を、デバイスの raw パスに設定します (二重引用符で囲む)。
この例では、デバイス 804 の raw パスは /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 ドライブで 256K バイトのセグメントサイズにします。そのため、512 と指定します。
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
tarback.sh ファイルのコピーで、変数 MEDIATYPE を探します。その値を、ドライブがサポートするメディアのタイプを表す、付録B に一覧表示されている 2 文字のメディアタイプコードに設定します。メディアタイプは二重引用符で囲みます。
この例では、LTO-4 ドライブを使用しています。そのため、li と指定します。
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="li"
...
tarback.sh ファイルのコピーで、変数 VSN_LIST を探します。その値として、ファイルのバックアップコピーが含まれている可能性のあるテープを識別する、ボリュームシリアル番号 (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
復元されたファイルごとに、必要に応じてユーザーおよびグループの所有権、モード、拡張属性、およびアクセス制御リスト (ACL) を再作成します。
/tmp/tarback.sh スクリプトでは、このようなタイプのメタデータを復元できません。
/tmp/tarback.sh スクリプトを実行してファイルの回復が終了したら、アーカイブファイルシステムの通常運用への復元に進みます。