テープは、長期間にわたるデータのストレージおよび保存に適した、信頼性の高い安定したメディアです。ただし、その寿命には限りがあります。通常の機械的処理 (マウント、テンション調整、および読み取り/書き込み) による摩耗や傷が、時間の経過とともに蓄積します。より性能の高い新しいドライブが使用可能になると、古いドライブはサポートが困難になり、互換性のあるメディアも高価で希少になります。したがって、ある時点で、新しいメディアにアーカイブを転送する必要があります。
Oracle HSM 階層型ファイルシステムでは、古いメディアを新しいメディアに置き換えることは複雑なプロセスです。テープメディアはファイルシステムの不可欠な部分です。ファイルシステムのメタデータは、各ファイルのデータの複数のコピーに関する場所を記録します (一部がディスク上にあり、一部がテープ上にあるなど)。したがって、テープをコピーする際は、ファイルシステムの i ノードを更新して、移行されたファイルのコピーの新しい場所を反映させる必要があります。同時に、アーカイブ処理やステージング処理などの通常のファイルシステム操作がコピーの作成によって妨害されないように、メディアおよびドライブを管理する必要があります。
Oracle Hierarchical Storage Manager では、メディア移行の複雑さに対処するために 2 つの方法が用意されています。要件に応じて、それぞれに利点があります。
Oracle HSM 6.1 で導入されたメディア移行機能は、あるライブラリドライブにマウントされたメディアのボリューム全体を、別のドライブにマウントされたメディアにコピーし、その過程でファイルシステムのメタデータを更新します (手動でロードされたドライブはサポートされません)。これにより、システムのオーバーヘッドと管理者の作業負荷が最小限に抑えられます。ボリュームは、アーカイブ処理またはステージング処理のためにドライブが必要でないときに、バックグラウンドでコピーされます。使用するドライブの数、および 1 日のうちで移行を実行してもよい時間を指定できます。または、ドライブがアイドル状態になるたびに Oracle HSM でボリュームを移行するようにもできます。ドライブまたはボリュームがアーカイブ処理またはステージングジョブに必要になると、メディア移行プロセスは優先度の高い操作に譲ります。StorageTek T1000D (またはそれ以降) 移行先ドライブが正しく構成されて使用可能になっている場合は、T10000 拡張コピー機能および Oracle HSM xcopy オプションを使用して移行できます。要求が行われたあと、ドライブ自体がコピーを処理し、サーバーリソースは使用されません。それ以外の場合は、Oracle HSM のサーバーコピーオプションを使用してサーバーの負荷を最小限に抑えることができます。その後、ファイルシステムサーバーは、構成可能な入出力バッファーを介してドライブからドライブにボリュームをコピーします。
通常のアーカイブ処理でアーカイブファイルを 1 回に 1 つずつ処理することによっても、データを移行できます。システムを構成して、ファイルを古いメディアからディスクキャッシュにステージングしたあとで新しいメディアに再度アーカイブするようにできます。このファイルごとのアプローチでは、ファイルのグループ化および分散の方法を詳細に制御できます。ただし、より多くの管理が必要になります。ディスクキャッシュおよびドライブリソースの割り当てはユーザー自身で行うため、通常のファイルシステム操作への干渉を最小限に抑える必要がある場合は、慎重に計画する必要があります。
このドキュメントの残りの部分では、プロセスを順に説明します。
ボリューム全体の移行またはファイルのステージングおよび交換用メディアへの再アーカイブによるデータの移行。
先に進む前に、次の手順を実行します。
メディアの移行を開始する前に、通常は Oracle HSM アーカイブデータを保護する回復メカニズムが、切り替え中および切り替え後も有効に保たれていることを確認します。壊滅的なハードウェア障害とユーザーエラーの可能性は、移行操作中に大きくも小さくもなりません。そのため、通常と同様に、現存の samfsdump 回復ポイントファイルからファイルやファイルシステム全体を回復できることを確認する必要があります。
移行中および移行後しばらくは、新しい移行先ボリュームではなく移行元のテープボリュームを参照する回復ポイントファイルが回復に利用されます。重大なハードウェア障害によってファイルシステムが使用不可になり、これらの古いテープが使用できない場合は、回復できなくなります。
したがって、少なくとも、現在のファイルシステムを新しいメディアから復元するために十分な新しい回復ポイントが作成されるまで、古いテープを保持することを計画してください。特定の時点のファイルを復元できる必要がある場合は、無期限ではなくても、より長い期間にわたって古いメディアを保持する必要が生じることがあります。理想的には、古いボリュームはすぐにアクセス可能なライブラリで維持するべきです。
移行先のライブラリに、移行されたファイルを保持するために十分なメディアが含まれていることを確認します。新しいテープのラベル付けまたは既存のテープの再ラベル付けの説明に従って、すべてのボリュームに正しくラベルが付けられていることを確認します。ボリュームにラベルが付いていない場合、移行は失敗します。
移行方式は、アーカイブの状態およびユーザーとアプリケーションの要件に応じて選択します。次の手順を使用して決定してください。
移行中にアーカイブを操作可能に保つかどうかを決定します。
アーカイブを休止し、すべてのリソースを移行のためだけに使用すると、タスクを簡素化し、より速く完了できます。ただし、アーカイブがアクティブに使用されている場合、これはほとんど実用になりません。
ボリューム全体ではなくアーカイブファイルのグループを選択的に移行する必要がある場合や、アーカイブファイルのグループ間の指定された関係を保持する必要がある場合は、ステージングと再アーカイブの方式を使用します。ファイルのステージングおよび交換用メディアへの再アーカイブに進みます。
単に古いボリュームを新しいメディアにコピーする必要がある場合や、ファイルシステム操作への移行の影響を最小限に抑える必要がある場合は、ボリューム移行の方式を使用します。
移行先ドライブとして使用できるファイバチャネル Oracle StorageTek T10000D (またはそれ以降) ドライブがない場合や、ソースとターゲットのテープのブロックサイズが同じでない場合は、サーバーコピー方式を使用します。
このモードでは、Oracle HSM ソフトウェアは、移行元ドライブからファイルシステムサーバー上の構成可能な入出力バッファーに、有効なアーカイブファイルだけをコピーします。移行元と移行先のブロックサイズが異なっている場合、移行先のブロックサイズの方が大きければ、ソフトウェアは自動的に調整を実行します。次に、ソフトウェアはバッファーから移行先ドライブにテープブロックを送信します。
ファイバチャネル StorageTek T10000D (またはそれ以降) 移行先ドライブがある場合、両方のドライブで現行のファームウェアが実行されている場合、ソースとターゲットのテープのブロックサイズが同じである場合、および移行元と移行先のドライブが同じストレージエリアネットワーク (SAN) スイッチを介して接続されている場合は、Oracle HSM xcopy オプションを使用します。
xcopy を指定すると、ファイルシステムサーバーからドライブに SCSI コピー要求が送信され、T10000D ドライブはコピー元テープからコピー先テープに、最初の有効なアーカイブファイルから始めて 1 ブロックずつコピーします。何らかの理由で xcopy 操作が失敗した場合、移行ソフトウェアは自動的にサーバーコピー方式に切り替わります。xcopy 方式では、サーバーのオーバーヘッドが最小限に抑えられ、パフォーマンスが最大になります。
ドライブおよびファームウェアの要件の詳細については、リリースノート (ダウンロード ZIP ファイル内の README.txt、またはファイルシステムサーバー上の /opt/SUNWsamfs/doc/README.txt) を参照してください。
移行元ボリュームに含まれている期限切れのファイルが比較的少ない場合は、xcopy オプションを eod (データの終わり) モードで使用します。
このモードの場合、T10000 ドライブは、テープ上で最初の有効なファイルから EOD (データの終わり) マークまでの間にあるすべてのアーカイブファイルをコピーします。これらのファイルの一部が期限切れになっている場合、それらは有効なファイルを使用して移行先ボリュームにコピーされます。
移行元ボリュームに含まれている期限切れのファイルが多い場合は、xcopy オプションを repack モードで使用します。
このモードの場合、T10000 ドライブは、期限切れではないアーカイブファイルだけを移行先ボリュームにコピーします。
サーバーコピー方式または直接コピー方式を選択し、migrationd.cmd ファイルを作成して移行を構成します。次のタスクを実行します。
migrationd.cmd ファイルの作成Oracle HSM メタデータサーバーに root としてログインします。
root@solaris:~#
/etc/opt/SUNWsamfs/migrationd.cmd ファイルをテキストエディタで開きます。
この例では、vi エディタで新しいファイルを開き、最初のコメントを追加します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements
少数のボリュームを移行する場合は、移行元ボリューム、移行先ボリューム、および移行の方向をそれぞれ指定します。移行元ボリュームごとに、migrate = from source to destination という形式の行を入力します。ここでは:
media_type は、移行元のメディアの種類を識別する 2 文字のコードです (詳細は、付録A 装置タイプの用語集を参照)。
VSN は、ライブラリ内のテープボリュームを識別する一意のボリュームシリアル番号です。
この例では、古い LTO (li) テープ VOL305 から新しい Oracle StorageTek T10000 (ti) テープカートリッジ VOL820 にデータを移行します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # Migrate a single volume. migrate = from li VOL305 to ti VOL820
多数のボリュームを移行する必要がある場合は、移行元および移行先のボリュームのメディアプールを定義します。vsnpool = poolname library equipment_number media_type VSNlist という形式の行を入力して各プールを定義します。ここでは:
name は、プールを一意に識別します。
equipment_number は、移行元ボリュームを保持しているライブラリに mcf ファイルで割り当てられている元の番号です。
media_type は、移行元のメディアの種類を識別する 2 文字のコードです (詳細は、付録A 装置タイプの用語集を参照)。
VSNlist は、リテラル VSN や VSN のグループと範囲を識別する正規表現を、スペースで区切ったリストです。
この例では、古い LTO4 (li) テープボリュームから新しい LTO6 (ti) テープカートリッジにデータを移行します。移行するライブラリ 20 内の LTO4 ボリュームを表す、移行元プール pool1 の行を追加します。これらには、範囲 VOL000 から VOL299 までの VSN を持つボリュームと、2 つの個別ボリューム VOL300 および VOL304 が含まれます。次に、ライブラリ 30 内の LTO6 ボリュームの範囲を表す、移行先プール pool2 の行を追加します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # pool1 contains the source volumes vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 li ˆVOL50[0-9]
移行元および移行先のメディアプールを定義したら、移行の方向を指定します。migrate = from sourcepool to destinationpool という形式の行を入力します。ここでは:
sourcepool は、移行されるデータが含まれているメディアプールです。
destinationpool は、移行されるデータを受け取るメディアプールです
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 ti ˆVOL50[0-9] # Migrate data from tapes in pool1 to tapes in pool2. migrate = from pool1 to pool2
サーバーコピー移行方式だけを使用する予定である場合は、xcopy 機能を無効にします。xcopy = off という形式の行を入力します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Disable xcopy and the StorageTek T10000 Extended Copy feature. xcopy = off
StorageTek T10000 拡張コピー機能だけを使用し、この機能をサポートするドライブが使用できないときにはデータを移行しない予定であれば、xcopy 移行のみを有効にします。xcopy = only という形式の行を入力します。
この例では、xcopy だけを有効にします。移行元または移行先のドライブが拡張コピー機能をサポートしていない場合、移行ソフトウェアは自動的に移行を取り消します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, cancel migration. xcopy = only
可能な場合には StorageTek T10000 拡張コピー機能を活用する予定であれば、xcopy 移行方式を有効にします。xcopy = on という形式の行を入力します。
この例では、互換性のあるドライブが移行期間中常に使用できるとは限らない場合でも xcopy を有効にします。移行元または移行先のドライブが拡張コピー機能をサポートしていない場合、移行ソフトウェアは自動的にサーバーコピーモードに切り替わります。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, automatically switch # to the server buffer copy. xcopy = on
期限切れのファイルが少数含まれているテープボリュームを xcopy 方式を使用して移行する場合は、xcopy を eod (データの終わり) モードで実行するように設定します。xcopy_eod = on という形式の行を入力します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = on
期限切れのファイルが多数含まれているテープボリュームを xcopy 方式を使用して移行する場合は、xcopy を repack モードで実行するように設定します。xcopy_eod = off という形式の行を入力します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = off
より優先度の高いアーカイブまたはステージングタスクよって中断されるまでに xcopy でコピーする必要があるデータの最小量を指定します。xcopy_minsize = amountunits という形式の行を入力します。ここでは:
amount は整数です。
units は、キロバイトの場合は k、メガバイトの場合は M、ギガバイトの場合は G、テラバイトの場合は T、ペタバイトの場合は P、エクサバイトの場合は E です。
この値により、T10000 ドライブの効率的な使用とほかのタスクへの可用性の間で妥協点が定義されます。値が大きいほど、ドライブへのデータの書き込み効率が高くなります。値が小さいほど、アーカイブ処理およびステージング処理へのドライブの可用性が高くなります。この例では、最小のコピーサイズを 30G バイトに設定します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_eod = on # xcopy can be interrupted after 30GB copied. xcopy_minsize = 30G
1 日のうちで移行ジョブの実行を許可する期間を定義します。runtime = window という形式の行を入力します。ここで、window は次のいずれかの値です。
always は、アーカイブ処理またはステージング処理のためにドライブとメディアが必要でないときは常に、移行デーモンによるデータの移行を許可します。移行デーモンは、使用しているドライブまたはメディアがアーカイブ処理またはステージング処理のために必要になると、それらを譲ります。
start_time end_time。ここで、start_time と end_time はそれぞれ、許可する期間の開始時間と終了時間を、24 時間制の時間と分で表現したものです (HHMM)。
samcmd、migstart、migidle、または migstop コマンドを発行して、いつでもこのディレクティブをオーバーライドできます。
ボリュームとドライブのどちらかがステージャーまたはアーカイバで必要になると、移行サービスはボリュームとドライブを放棄します。そのため、アーカイブ処理またはステージング処理で (たとえば、ピーク時に) 問題が発生しないかぎり、デフォルト値 always を受け入れるようにしてください。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_minsize = 30G # Run all of the time. Migration daemon will yield VSNs and drives when # resources are wanted by the SAM-QFS archiver and stager. run_time = always
ログディレクトリを指定することによってロギングを有効にします。logdir = path という形式の行を入力します。ここで、path はディレクトリパスとディレクトリ名です。
ディレクトリが定義されている場合、移行デーモンは、各移行元ボリュームから移行する各アーカイブファイルの移行先をログに記録します。移行元ボリュームごとに独自のログファイルがあり、media_type.VSN という名前が付けられます。ここでは:
media_type は、移行元メディアの種類を識別する 2 文字のコードです (詳細は、付録A 装置タイプの用語集を参照)。
VSN は、移行元ボリュームを識別する一意のボリュームシリアル番号です。
そのため、たとえば、VSN が VOL300 である移行元ボリュームのログファイルの名前は li.VOL300 になります。
アーカイバログと同様に、これらの移行ログは障害回復の際に非常に役立つ場合があります (詳細は、回復ポイントおよびアーカイブログの理解および『Oracle Hierarchical Storage Manager and StorageTek QFS Software ファイルシステム回復ガイド』を参照)。そのため、可能な場合は常にログディレクトリを指定してください。/var/adm/ など、Oracle HSM ソフトウェアまたはハードウェアの障害によって影響を受けない場所を選択します。この例では、ディレクトリ /var/adm/hsm_migration_logs を指定します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... run_time = always # Log directory for the migration logs. logdir = /var/adm/hsm_migration_logs
移行 i ノードデータベースのホームディレクトリを指定します。dbdir = path という形式の行を入力します。ここで、path はディレクトリの絶対パス名です。
移行元ボリュームごとに i ノードデータベースが作成され、移行期間中は保持されます。移行元ボリューム上で見つかったアーカイブコピーごとに、224 バイトのデータベースレコードが 1 つ作成されます。そのため、移行元メディアに格納される可能性のある最大数のコピーに対応できる、十分なディスク領域がある場所を選択する必要があります。たとえば、Oracle StorageTek T10000D ボリュームごとに、最大 8,200,104,892 個のアーカイブコピーが保持される可能性があります。したがって、特定の時点で移行する T10000D ボリュームごとに、約 1.67 テラバイトのデータベース領域が必要になります (詳細は、migration.cmd(1m) のマニュアルページを参照)。
データベースのデフォルトの場所は /var/opt/SUNWsamfs/sammig/db です。この例では、デフォルトのディレクトリを指定します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... logdir = /var/adm/hsm_migration_logs # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db
移行先デバイスの移行バッファーサイズを設定します。buffsize = media_type blocks という形式の行を入力します。ここでは:
media_type は、移行元のメディアの種類を識別する 2 文字のコードです (詳細は、付録A 装置タイプの用語集を参照)。
size は [2-8192] の範囲の整数です。この整数値は、バッファーが保持できるべきテープブロックの数を指定します。デフォルトは 64 です。
この例では、デフォルト数の Oracle StorageTek T10000 テープブロックを保持するために十分な領域を割り当てます。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64
1 ライブラリ当たりの移行に使用できるドライブの最大数を指定します。max_drives = library-list という形式の行を入力します。ここでは:
library-list はライブラリエントリをスペースで区切ったリストで、各エントリの形式は library equipment-number device-count です。
equipment-number は、mcf ファイルでライブラリに割り当てられている装置の順序番号です。
device-count は、指定されたライブラリで使用できるドライブの数です。デフォルトでは、device-count はライブラリ内のドライブの数に設定されます。
ボリュームとドライブのどちらかがステージャーまたはアーカイバで必要になると、移行サービスはボリュームとドライブを放棄します。そのため、アーカイブ処理またはステージング処理で問題が発生しないかぎり、デフォルト設定を受け入れ、任意の空きドライブを移行に使用できるようにしてください。この例では、実際にドライブの使用を制限する必要があることがわかっています。そのため、移行用のドライブとしてライブラリ 20 の 8 台、ライブラリ 30 の 6 台、およびライブラリ 40 の 2 台を割り当てます。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2
同時に実行できる、移行に関連したコピー操作の最大数を指定します。max_copy = processes という形式の行を入力します。ここで、processes は整数です。
デフォルトは最大値です。これは、mcf ファイルに記載されたすべてのライブラリに構成されているドライブの数を 2 で割った値に等しくなります。この例では、最大 8 つの同時コピー処理を許可します。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Up to 8 sam-migcopy process can be run simultaneously. max_copy = 8
同時に実行できる、移行に関連したテープスキャン操作の最大数を指定します。max_scan = processes という形式の行を入力します。ここで、processes は整数です。
移行元 VSN 上のアーカイブコピーを特定するために、sam-migrationd デーモンは、mcf に構成されているすべてのファイルシステムをスキャンし、ディスクキャッシュからすべての i ノードを読み取り、各 i ノード内の vsn フィールドと移行元ボリュームのボリュームシリアル番号 (VSN) を比較します。この処理によってファイルシステムのメタデータのアクティビティーが増加するため、ファイルシステムのパフォーマンスに悪影響が生じる可能性があります。
ファイルシステムのパフォーマンスと移行速度の間で最適なバランスが得られる値を選択してください。または、デフォルトの 4 を受け入れると、ほとんどの使用状況に対応できます。移行速度を最大にするためにファイルシステムを休止する場合は、max_scan を 0 に設定して、すべての移行元ボリュームが一度にスキャンされるようにします。この例では、通常のファイルシステム操作に影響を与えることなく最大 8 つの同時スキャン処理を許可できることが、経験からわかっています。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Run up to 8 sam-migcopy processes simultaneously. max_copy = 8 # Scan up to 8 VSNs simultaneously. max_scan = 8
ファイルを保存して、エディタを閉じます。
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd
...
max_copy = 8
# Scan up to 8 VSNs simultaneously.
max_scan = 8
:wq
root@solaris:~#
このセクションの手順では、シェルコマンドプロンプトから samcmd コマンドを使用してコマンドを入力する方法について説明します。ただし、すべてのコマンドは、:command という形式で samu インタフェースからも入力できます。ここで、command はコマンドの名前です。
現在、Oracle HSM メタデータサーバーに root としてログインしていない場合は、ここでログインします。
root@solaris:~#
以前の移行が現在アクティブになっていたり不完全であったりしないこと確認します。最初に、現在の移行ステータスを確認します。コマンド samcmd x を使用します。
別の移行コピージョブが進行中の場合、このコマンドは、そのコピージョブの移行元および移行先のボリューム (メディアタイプと VSN)、コピーモード、完了率、および現在のステータスを表示します。
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart source dest cmod perc status li VOL004 li VOL042 - 60% Copy idled
ほかの移行コピージョブが実行されていない場合、このコマンドでジョブは表示されません。
root@solaris:~# samcmd x Migration status samu ver time date Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 0 Status: Idle: Waiting for :migstart source dest cmod perc status
次に、現在の移行元 (S) および移行先 (D) ボリュームのステータスを確認します。コマンド samcmd y を使用します。
最初の例では、唯一の移行元および移行先のボリュームにジョブの end time が 10/16 12:14 と表示されています。移行元ボリュームのコピーは完了しています。したがって、現在実行中のジョブはありません。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa01 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOLa80 10/16 12:12 10/16 12:14 avail 550.00M
2 番目の例では、移行元および移行先のボリュームにジョブの end time が none と表示されています。移行元ボリュームは移行先ボリュームに引き続きコピーされています。したがって、移行ジョブがまだ実行されています。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa02 10/16 12:12 none copy 0/35023 164.50M 0 D li VOLa81 10/16 12:12 none copy 148.75M
最後に、ライブラリカタログ内のボリュームのリストを確認します。コマンド samcmd v を使用します。出力で次のフラグを探します。
R は、ボリュームが読み取り専用であることを意味します。移行が開始されると、移行元ボリュームは読み取り専用としてマークされます。
S (移行元) は、データが引き続きこのボリュームからコピーされていることを意味します。
D (移行先) は、データが引き続きこのボリュームにコピーされていることを意味します。
m は、移行元ボリュームの移行が完了したことを意味します。
e は、エラーのため移行元ボリュームが移行に失敗したことを意味します。
この例では、ボリューム VOLa01 は VOLa80 に正常に移行しました。ボリューム VOLa02 は VOLa81 に引き続き移行しています。移行に失敗しました。
root@solaris:~# samcmd v Robot catalog samcmd version HH:MM:SS month day year Robot VSN catalog by slot : eq 800 slot access time count use flags ty vsn count 64 0 2015/06/29 17:00 1 95% -il---b--Rm- li VOLa01 1 2015/07/02 17:43 2 89% -il-o-b--RS- li VOLa02 2 2015/07/02 18:31 2 89% -il-o-b--Re- li VOLa03 ... 51 2015/10/16 15:18 2 82% -il-o-b----- li VOLa80 52 2015/10/16 15:25 2 84% -il-o-b---D- li VOLa81
ジョブが実行されている場合は、それらが完了するまで待機します。
それ以外の場合は、すでに進行中の移行が存在しないことを確認したら、ボリュームの移行を実行します。
このセクションの手順では、シェルコマンドプロンプトから samcmd コマンドを使用してコマンドを入力する方法について説明します。ただし、すべてのコマンドは、:command という形式で samu インタフェースからも入力できます。ここで、command はコマンドの名前です。
現在、Oracle HSM メタデータサーバーに root としてログインしていない場合は、ここでログインします。
root@solaris:~#
移行元ファイルシステムがマウントされていることを確認します。
migrationd.cmd ファイルをアクティブにします。コマンド samcmd migconfig を使用します。
構成が成功した場合は、「Configuring migration」というメッセージが表示され、詳細の参照先のログファイルが示されます。
root@solaris:~# samcmd migconfig samcmd: migconfig: Configuring migration (see /var/opt/SUNWsamfs/sammig/logfile) root@solaris:~#
それ以外の場合、このコマンドはエラーで停止します。この構成コマンドを発行する前に移行プロセスを停止しなかったか、テープボリュームがまだ移行を待機しているときに移行を停止しました。
root@solaris:~# samcmd migconfig samcmd: migconfig: Can't configure migration, migration status is not stop, or migration job is pending root@solaris:~#
移行の構成を表示します。コマンド samcmd y を使用します。
構成が成功した場合は、指定されたボリュームが一覧表示され、移行元ボリュームのステータスは sched_wait (スケジュール済み、待機中) になり、移行先ボリュームのステータスは avail (使用可能) になります。この例では、構成が成功しました。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 none none sched_wait 0/0 0 0 D li VOL501 none none avail 0
構成が成功した場合は、移行を開始します。コマンド samcmd migstart を使用します。
root@solaris:~# samcmd migstart samcmd: migstart: State changed to start root@solaris:~#
移行のステータスを確認します。コマンド samcmd x および samcmd y を使用します。
この例では、移行が開始しようとしています。この「Migration status」画面は、ジョブステータスが現在 Run であること、1 件のコピーが s (サーバー) コピーモード (cmod) で進行中であること、コピーが 0% 完了していること、0 個の i ノードが更新されたこと、および、移行元ボリュームが引き続き Loading 中であることを示しています。
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 0% Loading li.VOL001
この「Migration vsn list」画面は、2 つのボリュームが現在処理されていることを示しています (移行元 1 つと移行先 1 つ)。両方のボリュームのステータスは現在 copy で、これは移行元が移行先にコピーされていることを示しています。この時点で、移行元から移行先に 0 バイトがコピーされており、35023 個の i ノードはどれも更新されていません。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 0 0 D li VOL501 10/16 12:12 none copy 0
移行のステータスを定期的に再確認します。ここでもコマンド samcmd x および samcmd y を使用します。
この例では、「Migration status」画面は、コピーが現在 23% 完了していること、および、560 (0x00000230) テープブロックが移行元から読み取られたことを示しています。
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 24% 0x00000230 blocks read
この「Migration vsn list」画面は、164.50 メガバイトが移行元ボリュームから読み取られたこと、および、148.75 メガバイトが移行先ボリュームに書き込まれたことを示しています。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 164.50M 0 D li VOL501 10/16 12:12 none copy 148.75M
移行が完了したら、終了ステータスを確認します。コマンド samcmd x および samcmd y を使用し、移行ログファイルを調べます。
この例では、「Migration status」画面に移行元および移行先のボリュームは表示されなくなり、1 件のコピーが完了したことが示されています。移行ステータスはまだ Run で、migidle または migstop コマンドを入力するまで変化しません。
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 1 Status: Run source dest cmod perc status
この「Migration vsn list」画面は、550.00 メガバイトが移行元ボリュームから読み取られたこと、および、550.50 メガバイトが移行先ボリュームに書き込まれたことを示しています。35023 個の i ノードすべてが、移行されたアーカイブコピーの新しい場所を反映するように更新されています。
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOL012 10/16 12:12 10/16 12:14 avail 550.00M
移行デーモンのログファイルには、移行の各段階が一覧表示され、最後にサマリーが示されます。この例では、Solaris の tail コマンドを使用して、最新のエントリを表示します。
root@solaris:~# tail /var/opt/SUNWsamfs/sammig/logfile date time Info: Schedule: Create VsnList file. date time Info: Schedule: VsnList file created, source: 1, destination: 1. date time Info: Schedule: Migration status changed to Start. date time Info: 'li.VOL001' Filesystem scan: Started date time Info: 'li.VOL001' Filesystem scan: Completed, total copy bytes: 517.2M, inodes: 35023, multi vsn copy: 0, removable-media file: 0, obsolete copy: 0 date time Info: 'li.VOL001' Copy: Started, pid: 2459 destination 'li.VOL012' date time Info: 'li.VOL001' Copy: Mode - server copy date time Info: 'li.VOL001' Copy: Server copy started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check succeeded, 5 inodes checked, 0 tar header error found. date time Info: 'li.VOL001' Copy: Completed, pid: 2459, exit status: 12, signal: 0 date time Info: 'li.VOL001' Update inode: Started, source position: 0 date time Info: 'li.VOL001' Update inode: Completed. date time Info: 'li.VOL001' Log: Started, source position: 0 date time Info: 'li.VOL001' Log: Completed. date time Summ: 'li.VOL001' date time Summ: 'li.VOL001' =============== Summary =============== date time Summ: 'li.VOL001' Status: Complete date time Summ: 'li.VOL001' Copy mode: Server copy date time Summ: 'li.VOL001' Start at: date time date time Summ: 'li.VOL001' End at: date time date time Summ: 'li.VOL001' Bytes: 550.00M date time Summ: 'li.VOL001' Archive copies: 35023 date time Summ: 'li.VOL001' Read error copies: 0 date time Summ: 'li.VOL001' Multi vsn copies: 0 date time Summ: 'li.VOL001' Removable-Media file: 0 date time Summ: 'li.VOL001' ---Dest--- ---Bytes--- ---Copies--- date time Summ: 'li.VOL001' li VOL501 550.00M 35023 root@solaris:~#
最後に、ボリューム移行のログをセキュアな場所に必ずコピーします。
これらのログには、各移行元ボリュームから移行された各アーカイブファイルコピーについて、移行先ボリュームおよび開始位置が記録されます。この情報は、ファイルまたはファイルシステムを回復する必要がある場合に重要です。したがって、Oracle では、これらのファイルのバックアップコピーを回復ポイントおよびアーカイバログファイルとともに保存することを強く推奨しています。第7章 構成およびファイルシステムのバックアップおよび『Oracle Hierarchical Storage Manager and StorageTek QFS インストールおよび構成ガイド』の対応する章の説明に従ってください。
移行デーモンは、ユーザーが migrationd.cmd ファイルで指定したディレクトリに、移行ログファイルを作成します。移行されたボリュームごとに、media_type.VSN という名前のファイルが作成されます。ここでは:
media_type は、移行元メディアの種類を識別する 2 文字のコードです (詳細は、付録A 装置タイプの用語集を参照)。
VSN は、移行元ボリュームを識別する一意のボリュームシリアル番号です。
この例では、指定されたログディレクトリ /var/adm/hsm_migration_logs/ にあるボリュームログを、NFS マウントされたリモートファイルシステム上にある、ファイルシステムの回復リソースを保存するディレクトリにコピーします。
root@solaris:~# ls /var/adm/hsm_migration_logs/ li.VOL001 li.VOL002 li.VOL003 li.VOL004 li.VOL005 li.VOL006 ... ti.801 ... root@solaris:~# cp /var/adm/hsm_migration_logs/*.* /zfs/recover/hsmfs1/2015mig/
すべてのファイルが再度アーカイブされたら、要件に従ってテープを処分します (移行後の古いメディアの処分を参照)。
ここで停止します。移行が完了しました。
ステージングと再アーカイブの方式を使用してアーカイブファイルを古いメディアから新しいメディアに移行するには、通常のファイルシステム操作を妨害することなく、移行するファイルを特定し、それをディスクキャッシュにステージングし、新しいメディアに書き込む必要があります。この章では、プロセス内の次のステージについて説明します。
ステージングと再アーカイブ処理の詳細は、使用可能なディスクストレージ容量と使用可能なリムーバブルメディアドライブ数の 2 つの要素によって大きく異なります。メディアの移行中、Oracle HSM ステージャーは、古いメディアフォーマットを読み取ることができるドライブに古いリムーバブルボリュームをロードし、アーカイブされたファイルをディスクキャッシュに復元します。そのあと、Oracle HSM アーカイバが、新しいメディアフォーマットを書き込むことができるドライブを使用して、新しいリムーバブルボリュームにファイルを再度アーカイブします。そのため、特定のテープボリューム上にあるすべてのファイルを一度にディスクにステージングして、すぐに新しいメディアにアーカイブする方法が理想的です。
これを行うには、移行中に大容量のリソースを割り当てる必要があります。
テープ全体の容量と同等のディスク領域
古いテープ形式を読み込むドライブの排他的使用
新しい形式を書き込むドライブの排他的使用。
移行が完了するまでファイルシステムを休止できる場合は、上記のことは問題になりません。ただし、進行中のファイルシステムおよびアーカイブ操作を必要以上に妨害することなく、本稼動設定でデータを移行するには、検討が必要となります。ディスク領域またはテープドライブ数が不足している場合は、移行用に合理的に確保しておくことができるリソースを確認してから、移行プロセスを調整する必要があります。そのため、次のように進めます。
通常のファイルシステム操作を妨害せずに、移行用に使用できるディスクキャッシュの量を評価します。
移行専用に使用できるテープドライブの数を評価します。
使用可能なテープドライブの数が限定されている場合は、移行プロセスで通常の操作が妨害されないように、ステージングおよびアーカイブのプロセスを調整することを計画します。
上記の見積もりに基づいて、ステージングおよびアーカイブのパラメータを決定します。使用可能なディスク領域に常時保持される移行ファイルの最大数、およびファイルをキャッシュから新しいメディアに移動できる最大速度を決定します。
リソースの見積もりを行なったら、移行後の古いメディアの処分を計画します。
新しいメディアを archiver.cmd ファイルに追加し、アーカイブのコピーディレクティブを変更して、1 つのコピーは常に新しいメディアを使用して行われるようにします。
テキストエディタで /etc/opt/SUNWsamfs/archiver.cmd ファイルを開きます。
アーカイブポリシーには、2 つのコピーが指定されています。どちらのコピーも、交換対象のメディアタイプに書き込まれます。この例では、vi エディタでファイルを開きます。DLT カートリッジ (タイプ lt) を交換します。
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 lt .* endvsns
コピー 2 に対するディレクティブで、指定されたメディアタイプを新しいメディアの識別子に変更し、ファイルを保存して、テキストエディタを閉じます。
この例では、データを古い DLT テープから新しい LTO カートリッジに移行します。したがって、コピー 2 で、古いメディアタイプ lt (DLT) を li (LTO) に変更します。
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 li .* endvsns :wq root@solaris:~#
archiver.cmd ファイルに構文エラーがないかどうかを確認します。コマンド archiver -lv を実行して、エラーが見つからなくなるまでエラーを修正します。
archiver -lv コマンドは、ファイルを 1 行ずつ出力します。エラーが発生すると、エラーが発生したところで実行が停止します。
root@solaris:~# archiver -lv Reading '/etc/opt/SUNWsamfs/archiver.cmd'. 1: # ============================================= 2: # /etc/opt/SUNWsamfs/archiver.cmd 3: # --------------------------------------------- 4: # Global Directives 5: logfile = /var/opt/SUNWsamfs/archiver.log 6: # --------------------------------------------- 7: # File System Directives: 8: fs = samqfsms 9: all . 10: 1 5m ... root@solaris:~#
変更した archiver.cmd ファイルにエラーがなくなったら、コマンド samd config を使用して現在の構成にファイルをロードします。
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
次に、カートリッジからカートリッジにデータを移行します。
ステージングとアーカイブによるデータ移行方式では、sfind (GNU find コマンドの Oracle HSM 拡張機能) を使用します。sfind コマンドは、指定されたテープボリューム上でファイルを検索し、見つかったすべてのファイルに対して、stage および rearchive コマンドを起動する際に使用されます。
sfind、stage、または rearchive コマンドを使い慣れていない場合は、それぞれのマニュアルページを確認するようにしてください。次に、移行する必要のあるデータを保持しているテープカートリッジごとに、次のように進めます。
ファイルシステムホストに root としてログインします。
root@solaris:~#
移行するファイルを保持しているファイルシステムのマウントポイントディレクトリに移動します。
この例では、/hsm/hsmfs1 でマウントされた hsmfs1 ファイルシステムに格納されているファイルのアーカイブコピーを移行します。
root@solaris:~# cd /hsm/hsmfs1 root@solaris:~#
テープボリュームを選択します。
メディアタイプからメディアタイプにデータを移行する場合は、一度に 1 つのボリュームを操作します。次の例では、ボリュームシリアル番号 VOL008 を操作します。
まず、選択したボリュームに、損傷して正常にステージングできないファイルがないかどうかを検索します。Oracle HSM コマンド sfind . -vsn volume-serial-number -damaged を使用します。ここで volume-serial-number は、ライブラリ内のボリュームを一意に識別する英数字の文字列です。
この例では、現在の作業ディレクトリ (.) から検索を開始します。-vsn パラメータは、現在のテープ VOL008 上で見つかったファイルに検索を限定します。-damaged フラグは、正常にステージングできないファイルに検索を限定します。
root@solaris:~# sfind . -vsn VOL008 -damaged
sfind による損傷したファイルの検索で結果が返されたら、ファイルの修正を試行します。コマンド undamage -m media-type -vsn volume-serial-number file を使用します。ここでは:
media-type は、付録Aに一覧表示されている 2 文字のメディアタイプコードの 1 つです。
volume-serial-number は、ボリュームを一意に識別する英数字の文字列です。
file は、破損したファイルのパスおよび名前です。
一時的な入出力エラーにより、コピーに破損のマークが付くことがあります。この状態は、Oracle HSM undamage コマンドでクリアします。この例では、アーカイブファイルコピー /hsm/hsmfs1/data0008/20131025DAT が破損していると報告されます。そのため、この破損を修復し、破損ファイルの検索を再試行します。
root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged
sfind コマンドにより再度このファイルが破損されていると一覧表示された場合、そのコピーは使用できません。アーカイブに、このファイルの破損していない別のコピーがないか探します。使用可能なコピーを一覧表示するには、コマンド sls -D file を使用します。ここで file は、ファイルのパスおよび名前です。検出されたコピーのステータスをチェックするには、コマンド sfind file -vsn volume-serial-number を使用します。
この例では、undamage コマンドはコピーを修正できませんでした。そのため、sls を使用して、ファイル /hsm/hsmfs1/data0008/20131025DAT のすべてのコピーを一覧表示します。
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sls -D /hsm/hsmfs1/data0008/20131025DAT 20131025DAT: mode: -rw-r--r-- links: 1 owner: root group: other length: 319279 admin id: 7 inode: 1407.5 project: system(0) offline; archdone; stage -n; copy 1: ---- May 21 07:12 1e4b1.1 lt VOL008 copy 2: ---- May 21 10:29 109c6.1 lt VOL022 ...
テープボリューム VOL022 は、ファイルの 2 番目のコピーを保持しています。そのため、sfind で 2 番目のコピーをチェックします。
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged
コピーを使用できず、破損していないファイルのコピーが 1 つ存在する場合は、そのファイルを再アーカイブします。アーカイブに 2 つの良好なコピーが保持されたら、次に、破損したコピーをアーカイブ解除します。
この例では、ボリューム VOL008 上のファイル /hsm/hsmfs1/data0008/20131025DAT のコピー 1 が使用不能ですが、sfind コマンドでコピー 2 の破損が見つかりませんでした。そのため、archive コマンドに -c オプションを指定して発行し、有効なコピー 1 を作成してから、ボリューム VOL008 上の破損したコピーをアーカイブ解除します。
root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged root@solaris:~# archive -c 1 /hsm/hsmfs1/data0008/20131025DAT ... root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
使用可能なコピーが存在しない場合は、キャッシュ内にファイルが存在するかどうかを確認します。コマンド sfind . -vsn volume-serial-number -online を使用します。
この例では、ボリューム VOL008 のコピー 1 とボリューム VOL022 のコピー 2 がどちらも破損していて使用できません。そのため、ディスクキャッシュで、ファイルがオンラインで使用可能かどうかを確認します。
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online
使用可能なコピーが存在しないが、キャッシュ内にファイルが存在する場合は、そのファイルをアーカイブします。アーカイブに 2 つの良好なコピーが保持されたら、次に、破損したコピーをアーカイブ解除します。
この例では、ボリューム VOL008 のコピー 1 およびボリューム VOL022 のコピー 2 のいずれも使用できないため、archive コマンドを発行して 2 つの有効なコピーを作成してから、ボリューム VOL008 上の破損したコピーをアーカイブ解除します。
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
使用可能なコピーが存在せず、ディスクキャッシュ内にファイルが存在しない場合は、データが失われた可能性が高くなります。データがクリティカルである場合は、データ回復の専門家がいる会社に連絡して支援を求めてください。それ以外の場合、破損したコピーをアーカイブ解除します。
この例では、ボリューム VOL008 のコピー 1 とボリューム VOL022 のコピー 2 がどちらも使用できません。sfind コマンドは、ディスクキャッシュ内でファイルを見つけられませんでした。データは重要ではありません。そのため、ボリューム VOL008 上の破損したコピーをアーカイブ解除します。
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT
sfind による損傷したファイルの検索で結果が返されない場合は、ファイルを現在のテープからディスクキャッシュにステージングします。コマンド sfind . -vsn volume-serial-number -offline -exec stage {}\; を使用します
-vsn パラメータは、現在のテープで見つかったファイルに検索を限定します (必ず一度に 1 つのテープのデータを移行します)。
-offline パラメータは、データが上書きされないように、キャッシュ内にまだ存在しないファイルに sfind の出力をさらに限定します。
-exec stage {}\; 引数は、sfind が返す各パスとファイル名を取り、それを Oracle HSM stage コマンドの引数として使用します。次に、stage コマンドが、指定したファイルをディスクキャッシュに復元します。対象のすべてのファイルがステージングされるまでプロセスは繰り返されます。
この例では、sfind -vsn VOL008 -damaged コマンドが出力を返しません。そのため、sfind を使用して、VOL008 上で見つかったファイルのうち、キャッシュ内にないすべてのファイルをステージングします。
root@solaris:~# sfind . -vsn VOL008 -damaged root@solaris:~# sfind . -vsn VOL008 -offline -exec stage {}\;
ファイルがテープからステージングされたら、ファイルを選択的に再度アーカイブします。コマンド sfind . -vsn volume-serial-number -online -exec rearch -r -m media-type {}\; を使用します。ここで media-type は、移行元メディアのタイプです。
-vsn パラメータは、現在のテープでも見つかったファイルに検索を限定します (必ず一度に 1 つのテープのデータを移行します)。
-online パラメータは、データが上書きされないように、キャッシュ内に存在するファイルに sfind の出力をさらに限定します。
-exec rearch -r -m media-type {}\; 引数は、sfind が返す各パスとファイル名を取り、それを Oracle HSM rearch -r -m media-type コマンドの引数として使用します。-r 引数は、サブディレクトリを介してプロセスを再帰的に実行します。-m 引数は、ソースメディア上にあるファイルのみを再アーカイブします。
この例では、-vsn パラメータの値は VOL008、-m パラメータの値は DLT メディアを表す lt に指定されています。
root@solaris:~# sfind . -vsn VOL008 -online -exec rearch -r -m lt {}\;
sfind による検索でファイルが見つからなくなるまで、上記の手順を繰り返します。
すべてのファイルが再度アーカイブされたら、計画通りにテープを処分します (移行後の古いメディアの処分を参照)。
すべての古いメディアから新しいメディアにデータが移行されるまで、この手順を繰り返します。
移行が完了しても、古いメディアの価値がすべて失われるわけではありません。したがって、それらの処分方法を慎重に検討してください。
少なくとも、新しい回復ポイントファイルが十分に蓄積され、新しい交換用メディアのみを使用してファイルシステム内のすべてのファイルを回復できるようになるまで、古いメディアを保持してください。
ストレージ領域に余裕がある場合は、古いメディアを無期限に保持します。互換性のあるドライブが使用可能なかぎり、古いメディアはバックアップと回復の貴重なリソースになり得ます。
ライブラリ容量に余裕がない場合は、古いメディアをエクスポートし、オフサイトのストレージに保持します。
古いメディアが再利用可能な場合は、そこに含まれているデータが有用でなくなっていることが確実であれば、古いボリュームのラベルを付け直します。たとえば、古い Oracle StorageTek T10000C ドライブ用のメディアのラベルを付け直し、新しい T10000D ドライブで使用することもできます。
それ以外の場合は、古いボリューム上のデータにもメディアにも価値が残っていなければ、ボリュームをライブラリからエクスポートし、適切に処分します。