4    データのバックアップとリストア

ファイル・システムのデータのバックアップは,アプリケーション障害,システム障害,およびさまさまな予期しない事態に備えた包括的な計画の重要な要素の 1 つです。 適切なバックアップ計画をたてることで,バックアップしたデータが必要なときに確実に使用できるようになります。

この章では,バックアップ計画をたてる際に考慮する必要のある,次のような項目について説明します。

4.1    データとメタデータの整合性

データをバックアップする前に,バックアップするソース,つまり,ファイルのデータと AdvFS メタデータ (ファイル構造情報) が整合性のとれた状態にあり,バックアップの間に変わってしまわないことを確認します。

4.1.1    データ整合性の保証

バックアップは,収集したデータの整合性がとれていて,はじめて役に立ちます。 バックアップを実行する前に,データ・ファイルをそのような状態にする必要があります。 これには,次の 2 つの手順を行ないます。

  1. アプリケーションを停止または休止し,データ・ファイルの現在の状態がアプリケーションの観点から矛盾がないようにします。

  2. アプリケーションのデータ・ファイルへの更新が固定記憶装置に書き込まれ,アプリケーションまたはファイル・システムによってキャッシュされていないことを確認します。

これらの手順を踏まないと,バックアップしたデータがアプリケーションの観点から矛盾のあるものになり,バックアップとして使えなくなります。

Oracle のようなアプリケーションは,休止しデータをディスクにフラッシュする明示的な方法を用意しています。 アプリケーションによっては,このような機能は用意していなくても,同期書き込み方式により,アプリケーションが停止するとデータがディスクに書き込まれるものがあります。 しかし,休止・フラッシュ機能も同期書き込み技術も使用していないアプリケーションもあります。

4.1.1.1    アプリケーションの休止機能を使用したデータ整合性の保証

アプリケーションによっては,バックアップに備えて休止し,ディスクへのフラッシュを行なうものがあります。 たとえば,Oracle では,これを Hot Backup Mode と呼んでいます。 これを使用するには,次のような Oracle SQL コマンドを実行します。

ALTER TABLESPACE name BEGIN BACKUP

バックアップのソースが作成されると (4.2 節),次の Oracle SQL コマンドを使用してテーブル・スペースを Hot Backup Mode から解放します。

ALTER TABLESPACE name END BACKUP

4.1.1.2    同期書き込み方式を使用したデータ整合性の保証

AdvFS では次の方法で,アプリケーションが書き込んだデータが,アプリケーションまたはファイル・システムのバッファ・キャッシュにではなく,確実に固定記憶装置に書き込まれることを保証します。

これらの技術を使用するアプリケーションを適切にシャットダウンすると,すべてのキャッシュされたデータは固定記憶装置に確実に書き込まれることになります。

4.1.1.3    同期書き込み方式を用いないデータ整合性の保証

アプリケーションが休止機能を持っていず,同期書き込みを呼び出さない場合,次に示す方法のいずれかを採ることで,アプリケーションがデータ・ファイルに書き込んだすべてのデータが,バックアップを開始する前に,固定記憶装置に書き込まれていることを保証できます。

4.1.2    メタデータの整合性の保証

データ・ファイルがアプリケーションの観点で矛盾がないことを確認したら,次は AdvFS メタデータの整合性を確認します。 これを適切に行なわないと,AdvFS ドメイン・パニック,システム・パニック,またはユーザ・データの損傷が生じる可能性があります。 バックアップ・ソース内の AdvFS メタデータの整合性を保証するには,次のいずれかの手順を実行します。

4.1.2.1    ドメインをフリーズすることによるメタデータ整合性の保証

freezefs コマンドによって,ドメインはメタデータの整合を保った状態になり,指定した凍結時間が過ぎるまで,または thawfs コマンドで明示的に解凍されるまで,その状態を保ちます。 ドメイン内のすべてのファイルセットが凍結されます。 すべてのメタデータは,複数のボリュームまたは論理ユニット (LUN) に分散されて配置されていることもありますが,すべてディスクにフラッシュされ,凍結期間中は変更されません。

ファイル・システムをフリーズすると,すべての処理中のファイル・システムの操作は処理を完了することができます。 メタデータのアップデートが必要ないファイル・システム操作 (読み取り操作など) は,ファイル・システムがフリーズしても正常に機能します。

ファイル・システムはフリーズすると,次のいずれかの動作で解凍されるまでメタデータの整合が取れている状態を保ちます。

freezefs コマンドは,省略時設定でファイル・システムを 60 秒間フリーズします。 タイムアウト値を,これより大きく,あるいは小さくするには -t オプションを使用し,秒単位で指定します。 またこのオプションで,thawfs コマンドで解凍されるまでフリーズしたままになるように指定することもできます。 詳細については, freezefs(8) および 『クラスタ管理ガイド』 を参照してください。

4.1.2.2    ファイルセットをアンマウントすることによるメタデータ整合性の保証

ドメインのすべてのファイルセットをアンマウントすれば,AdvFS メタデータが変更されないことが保証されます。 メタデータの整合性を保ちたい場合は,アンマウントしたドメインに対して実行できる AdvFS Utilities は使用しないでください。

4.2    バックアップ・ソースの作成

マウントしたファイルセットからバックアップ・ソースを作成すると,バックアップを行なうことができます。 ソースは次のいずれかをもとにして作成します。

4.2.1    マウントしたオリジナル・ファイルセットのバックアップ・ソースとしての使用

状況によっては,マウントしたオリジナル・ファイルセットをバックアップ・ソースとして使用することができます。

4.2.1.1    長所と短所

表 4-1に,オリジナル・ファイルセットをバックアップ・ソースとして使用することの長所と短所を示します。

表 4-1:  マウントしたオリジナル・ファイルセットのバックアップ・ソースとしての使用

長所 短所
簡単さ。 新しくマウント・ポイントを作成する必要はありません。 バックアップ中はマウント・ポイントにあるファイルをアップデートできない。 アップデートすると,データに矛盾が生まれる恐れがあります。
  バックアップ処理を他のホストに任せることはできない。

4.2.1.2    データとメタデータ整合性の保証

ファイルセットのデータの整合性を保つには 4.1 節の手順に従います。

ファイル・システムに POSIX インタフェースを介してアクセスするバックアップ・アプリケーション (vdump ユーティリティなど) では,メタデータの整合性を保証するのに特に何もする必要はありません。

4.2.1.3    バックアップ・ソースの準備

マウントしたオリジナル・ファイルセットを使ってバックアップ・ソースを準備する場合,データとメタデータの整合性を保つために特に何もする必要はありません。

4.2.2    マウントしたファイルセット・クローンのバックアップ・ソースとしての使用

ファイルセット・クローン (2.4.10 項を参照) は,既存のファイルセット・データの読み取り専用スナップショットです。 ファイルセット・クローンには,作成時のすべてのデータが入っている訳ではありません。 オリジナル・ファイルのデータを変更すると,AdvFS はオリジナルにあるデータをページ単位でファイルセット・クローンに保存します。

ファイルセット・クローンを作成するには,オプションの AdvFS Utilities が必要です。 ファイルセットのクローンを作成できるのは,root ユーザだけです。 1 つのファイルセットにつき,1 つのクローンしか作成できません。

4.2.2.1    長所と短所

表 4-2 に,ファイルセット・クローンをバックアップ・ソースとして使用することの長所と短所を示します。

表 4-2:  マウントしたファイルセット・クローンのバックアップ・ソースとしての使用

長所 短所
追加のストレージ・ハードウェアは必要ない。 ドメインにクローン用のスペースがある。 ファイルセット・クローンは,同じドメイン内のファイルセットとして作成される。 ストレージに障害が発生するとオリジナルとクローンの両方のファイルセットが影響を受けることになります。
簡単に使用できる。 [脚注 1] バックアップ処理の負荷を他のマシンに移行できない。 ファイルセット・クローンは,オリジナルのファイルセットと同じホストにマウントされる必要があります。
オリジナルのファイルセットのオフライン時間はファイルセット・クローンを作成するのにかかる時間だけでよい (通常数秒)。 クローンへの書き込みはファイルセットの I/O に影響を与える。
  オリジナルのファイルセットにつき,1 つのファイルセット・クローンしか作成できない。 データが複数のファイルセットにまたがっている場合,クローン作成の際は,一貫性を保証するためにアプリケーションを停止する必要がある場合があります。

4.2.2.2    データとメタデータの整合性の保証

ファイルセットのデータの整合性を保つには 4.1 節の手順に従います。 データが複数のファイルセットにまたがっている場合,すべての関連するファイルセットの整合性を確認する必要があります。

ファイルセット・クローン作成はすべて,AdvFS 内で行なわれるので,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。

4.2.2.3    バックアップ・ソースの準備

ファイルセット・クローンを作成するために,オリジナル・ファイルセットのデータが整合性のとれた状態であることを確認します。 そして,clonefset コマンドでファイルセット・クローンを作成します。

次の例では,ドメイン domain1 内の ファイルセット pssm のクローンを作成しています。 新しいファイルセット・クローンの名前は pssm_clone です。

  1. クローンを作成しマウントします。

    # clonefset domain1 pssm pssm_clone
    # mkdir /pssm_clone
    # mount -t advfs domain1#pssm_clone /pssm_clone
    

  2. pssm_clone を使用してバックアップ・プロセスを実行します。 詳細は 4.3.11 項 を参照してください。

  3. クローンを削除します。

    # umount /pssm_clone
    # rmfset domain1 pssm_clone 
    

4.2.3    LSM スプリット・ミラーからマウントしたファイルセットのバックアップ・ソースとしての使用

バックアップしたいデータが,LSM ミラー・ボリュームに構築されたドメイン上にある場合,LSM ミラーをスプリットし (ミラーを切り離し),マウントし,バックアップ・ソースとして使用することができます。 この操作を行なうには,root ユーザの権限が必要です。 ミラーを切り離す方法については,『Logical Storage Manager』を参照してください。

4.2.3.1    長所と短所

表 4-3 に,LSM スプリット・ミラーをバックアップ・ソースとして使うことの長所と短所を示します。

表 4-3:  LSM スプリット・ミラーからマウントしたファイルセットのバックアップ・ソースとしての使用

長所 短所
データの完全な物理コピーが作成される。 オリジナル・ファイルセットが置かれるストレージのハードウェアが故障しても,スプリット・ミラーには影響しません。 LSM ライセンスが必要。
オリジナルのファイルセットのオフライン時間は,LSM ミラーをスプリットするのにかかる時間だけですむ (通常数秒)。 少なくとも データの 2 つのコピーを保持するのに十分な物理ストレージが必要。
データが複数のシングル・ドメインのファイルセットにまたがっている場合,LSM スプリット・ミラーはそのすべてのバックアップとなる。 LSM と AdvFS の両方のコマンドが必要なので複雑。
複数の LSM スプリット・ミラーを,同時に 1 つのドメインについて作成できる。 バックアップ処理の負荷を他のマシンに移行できない。 LSM スプリット・ミラー・ファイルセットは,オリジナルのファイルセットと同じホストにマウントされる必要があります。

4.2.3.2    データとメタデータの整合性の保証

ファイルセットのデータの整合性を保つには 4.1 節の手順に従います。

ストレージが 1 つのLSM ボリュームからなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。 ストレージが複数の LSM ボリュームからなる場合は,4.1.2 項 を参照してください。

4.2.3.3    バックアップ・ソースの準備

ドメインが複数の LSM ボリュームからなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなるかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。

次の例では,オリジナル・ドメインが 2 つの LSM ボリュームからなり,それぞれからミラーが切り離されていると仮定します。 データは,/data にマウントされているファイルセット data のあるドメインにあります。 2 つのミラー・ボリュームは,/dev/vol/mirrorvol1/dev/vol/mirrorvol2 です。

  1. ドメインをフリーズします。

    # /usr/sbin/freezefs /data
    

  2. ミラーを切り離し,新しい LSM ボリュームとして再構築するために LSM コマンドを実行します。 手順は,『Logical Storage Manager』 を参照してください。

  3. LSM スプリット・ミラーを作成したら,ドメインのメタデータを解凍します。

    # /usr/sbin/thawfs /data
    

    アプリケーションは引き続き,オリジナル・ドメインで動作できます。

  4. 2 つの新しく作成した LSM ボリュームを使用して,新しいドメインのディレクトリを作成します。

    # mkdir /etc/fdmns/mirror_domain
    # ln -fs /dev/vol/mirrorvol1 /etc/fdmns/mirror_domain
    # ln -fs /dev/vol/mirrorvol2 /etc/fdmns/mirror_domain  
    

    新しいディレクトリを作成するのに mkfdmn コマンドは使用しないでください。 ミラーにアクセスできなくなります。

  5. マウント・ポイント・ディレクトリを作成し,mirror_domain のスプリット・ミラーから作成したファイルセット data をマウントします。

    # mkdir /backup
    # mount -o dual mirror_domain#data /backup
    

バックアップは /backup ディレクトリから行なえるようになります。

4.2.4    コントローラ・ベースのクローンからマウントしたファイルセットのバックアップ・ソースとしての使用

Compaq HSG80 や HSV110 などのストレージ・コントローラは,コントローラ・ベースのコマンドを使用してハードウェア・ミラーをスプリットできます。 これは,概念的にはスプリット・ミラーと同じ原理です。 すなわち,データの 2 つ以上の完全な物理コピーが存在し,1 つがバックアップのために切り離されている状態です。

4.2.4.1    長所と短所

表 4-4に,コントローラ・ベースのクローンをバックアップ・ソースとして使用することの長所と短所を示します。

表 4-4:  コントローラ・ベースのクローンからマウントしたファイルセットのバックアップ・ソースとしての使用

長所 短所
データの完全な物理コピーが作成される。 オリジナル・ファイルセットが置かれるストレージのハードウェアが故障しても,コピーには影響しません。 少なくとも 2 つのデータのコピーを収容するのに十分な物理ストレージが必要。
オリジナルのファイルセットのオフライン時間は,コントローラ・ベースのクローンを作成するのにかかる時間だけですむ (通常数秒)。 コントローラと AdvFS の両方のコマンドが必要なので複雑。
バックアップ処理の負荷を他のマシンに移行できる。 コントローラ・ベースのクローンは,多くの場合,異なるホストにマウントできます。  
ドメインのすべてのファイルセットに対し単一のバックアップ・ソースとして機能できる。  
複数のコントローラ・ベースのクローンを,同時に同じドメインに作成できる。  

4.2.4.2    データとメタデータの整合性の保証

ファイルセットのデータの整合性を保つには 4.1 節の手順に従います。

ストレージが 1 つのハードウェア LUN からなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。 ストレージが複数のハードウェア LUN からなる場合は,4.1.2 項 を参照してください。

4.2.4.3    バックアップ・ソースの準備

ドメインが複数の LUN からなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなるかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。

次の例では,データは,ファイルセット data があるドメインに置かれていて,そのドメインは /data にマウントされていると仮定します。 作成されるクローンは,/dev/disk/dsk25c /dev/disk/dsk26c です。

  1. ドメインをフリーズします。

    # /usr/sbin/freezefs /data 
    

  2. コントローラ・ベースのクローンを作成するのに必要なコマンドを実行します。 たとえば,Compaq HSG80 コントローラを使用する場合の,これらのコマンドの例は,Best Practice ドキュメントの『Using StorageWorks HSG80 Controller-Based Cloningand Snapshotting』を参照してください。

  3. ドメインのメタデータを解凍します。

    # /usr/sbin/thawfs /data  
    

    アプリケーションは引き続き,オリジナル・ドメインで動作できます。

  4. 新しくクローンを作成した LUN のブロック型デバイス特殊ファイルを作成します。 これは,新しいバックアップ・ソースをマウントするホスト上で行ないます。 /sbin/hwmgr コマンドは非同期に実行されるため,実際にブロック型デバイス特殊ファイルが作成される前に終了している場合があります。

    スタンドアロン・システムの場合,次のコマンドを実行します。

    # /sbin/hwmgr -scan scsi
    

    クラスタの場合,次のコマンドを実行します。

    # /sbin/hwmgr scan component -category scsi_bus -cluster
    

    新しい LUN が作成されるたびに,新しいデバイス特殊ファイルが作成されます。

  5. ブロック型デバイス特殊ファイルを探します。

    # /sbin/hwmgr -view devices 
    

  6. /dev/disk/dsk25c/dev/disk/dsk26c の新しいドメインにアクセスするための,ディレクトリとシンボリック・リンクを作成します。

    # mkdir /etc/fdmns/clone_domain 
    # ln -fs /dev/disk/dsk25c /etc/fdmns/clone_domain 
    # ln -fs /dev/disk/dsk26c /etc/fdmns/clone_domain 
    

    新しいディレクトリを作成するのに mkfdmn コマンドは使用しないでください。 クローン・データにアクセスできなくなります。

  7. ディレクトリを作成し,clone_domain のファイルセット data をマウントします。

    # mkdir /backup
    

    クローン・ドメインとファイルセットを元のホストにマウントしていない場合,次のコマンドを入力します。

    # mount clone_domain#data /backup 
    

    クローン・ドメインとファイルセットを元のホストにマウントしている場合,次のコマンドを入力します。

    # mount -o dual clone_domain#data /backup 
    

バックアップは /backup ディレクトリから行なえるようになります。

4.2.5    コントローラ・ベースのスナップショットからマウントしたファイルセットのバックアップ・ソースとしての使用

Compaq HSG80 や HSV110 などのストレージ・コントローラでは,データセットの重要な RAID メタデータのコピーであるスナップショットを別のメディアに作成できます。 この機能では,書き込み時コピー技術を使用して,オリジナル・データ・セットの変更に即したコピーを維持します。 これは,概念的にはファイルセット・クローンと同じ原理です。

4.2.5.1    長所と短所

表 4-5に,コントローラ・ベースのスナップショットをバックアップ・ソースとして使用することの長所と短所を示します。

表 4-5:  コントローラ・ベースのスナップショットからマウントしたファイルセットのバックアップ・ソースとしての使用

長所 短所
ドメインのすべてのファイルセットのバックアップ・ソースとして機能できる。 少なくとも 2 つのデータのコピーを収容するのに十分な物理ストレージが必要。
オリジナルのファイルセットのオフライン時間は,コントローラ・ベースのスナップショットを作成するのにかかる時間だけですむ (通常数秒)。 コントローラと AdvFS の両方のコマンドが必要なので複雑。

4.2.5.2    データとメタデータの整合性の保証

ファイルセットのデータの整合性を保つには 4.1 節の手順に従います。

ストレージが 1 つのハードウェア LUN からなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。 ストレージが複数のハードウェア LUN からなる場合は,4.1.2 項 を参照してください。

4.2.5.3    バックアップ・ソースの準備

ドメインが複数の LUN からなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなっているかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。

次の例では,データが,ファイルセット data があるドメインに置かれていて,そのドメインは /data にマウントされていると仮定します。 作成されるスナップショットは,/dev/disk/dsk25c/dev/disk/dsk26c です。

  1. ドメインをフリーズします。 省略時の凍結時間は 60 秒です。

    # /usr/sbin/freezefs /data 
    

  2. コントローラ・ベースのスナップショットを作成するのに必要なコマンドを実行します。 たとえば,Compaq HSG80 コントローラを使用する場合の,これらのコマンドの例は,Best Practice ドキュメントの『Using StorageWorks HSG80 Controller-Based Cloning and Snapshotting』を参照してください。

  3. ドメインのメタデータを解凍します。

    # /usr/sbin/thawfs /data  
    

    アプリケーションは引き続き,オリジナル・ドメインで動作できます。

  4. 新しくスナップショットを作成した LUN のブロック型デバイス特殊ファイルを作成します。 これは,新しいバックアップ・ソースをマウントするホスト上で行ないます。 /sbin/hwmgr コマンドは非同期に実行されるため,実際にブロック型デバイス特殊ファイルが作成される前に終了している場合があります。

    スタンドアロン・システムの場合,次のコマンドを実行します。

    # /sbin/hwmgr -scan scsi
    

    クラスタの場合,次のコマンドを実行します。

    # /sbin/hwmgr scan component -category scsi_bus -cluster
    

    新しい LUN が作成されるたびに,新しいデバイス特殊ファイルが作成されます。

  5. ブロック型デバイス特殊ファイルのファイルを探します。

    # /sbin/hwmgr -view devices 
    

  6. /dev/disk/dsk25c/dev/disk/dsk26cの新しいドメインにアクセスするための,ディレクトリとシンボリック・リンクを作成します。

    # mkdir /etc/fdmns/snap_domain 
    # ln -fs /dev/disk/dsk25c /etc/fdmns/snap_domain 
    # ln -fs /dev/disk/dsk26c /etc/fdmns/snap_domain 
    

    新しいディレクトリを作成するのに mkfdmn コマンドは使用しないでください。 スナップショット・データにアクセスできなくなります。

  7. ディレクトリを作成し,snap_domain のファイルセット data をマウントします。

    # mkdir /backup
    

    スナップショット・ドメインとファイルセットを元のホストにマウントしていない場合,次のコマンドを入力します。

    # mount snap_domain#data /backup 
    

    スナップショット・ドメインとファイルセットを元のホストにマウントしている場合,次のコマンドを入力します。

    # mount -o dual snap_domain#data /backup 
    

バックアップは /backup ディレクトリから行なえるようになります。

4.3    バックアップ方式とツール

データとメタデータの整合性が確認されたバックアップ・ソースを作成したら,データをバックアップすることができます。 これには,いくつかの方法があります。

バックアップとリストアには,多くのコマンドを使用することができます。 AdvFS では,vdump および vrestore コマンドと,リモートから実行する rvdump および rvrestore コマンドを利用できます。 この節では,これらのコマンドの使用法を説明します。

4.3.1    vdump および vrestore コマンドの概要

バックアップ・ソースを準備したらvdump コマンドを使用してバックアップ作業を行なうことができます。 vdump コマンドはファイル・レベルで作用します。 このコマンドは,各ディレクトリを走査し,正規の POSIX ファイル・システム・コールを使用してディレクトリおよびファイルにアクセスします。 詳細については, vdump(8) および vrestore(8)を参照してください。

dump および restore コマンドは,vdump および vrestore コマンドと違った機能をします。 これらは,i ノード・レベルで作用するので,UFS ファイルだけを扱うことができます。

この項では,vdump および vrestore コマンドについてのみ説明しますが,リモート操作の場合は rvdump および rvrestore コマンドに置き換えてお読みいただけます。

注意

vdump コマンドや vrestore コマンドは,root 以外のユーザでも実行できます。 ただし,ファイルのリストア先ディレクトリへの書き込み許可が必要になります。 AdvFS のユーザとグループの,クォータ・ファイルとファイルセット・クォータの保存およびリストアができるのは root ユーザだけです。

注意

Version 4.0 より前のオペレーティング・システムの vrestore コマンドでは,Version 4.0 以降の vdump コマンドで保管された情報を正しくリストアすることができません。 vdumpvrestore のダンプ・ファイルの形式は,Version 4 と Version 5 のオペレーティング・システムで互換性があります。

vdump コマンドは,新しいファイルや一定の日付以降に変更したファイルを,省略時のストレージ・デバイスまたは指定のデバイスにコピーする際に,セーブセットと呼ばれる固定長ブロックの集合を作成します。

セーブセットは,複数のテープにまたがってバックアップすることができ,また同じテープに複数のセーブセットを収めることもできます。 テープ上の各セーブセットはファイル・マークによって区切られます。 ファイル・マークは,vdump コマンドがセーブセットをクローズするときに書き込まれます。

vdump コマンドの構文を次に示します。

vdump options mount_point

次の例では,/psm にマウントされたファイルセットをテープにダンプしています。

# vdump -0 -f /dev/tape/tape0_d1 /psm

4.3.2    vdump コマンド固有の機能

vdump コマンドは,次に示すように,UFS dump コマンドが持っていない多数の機能を備えています。 vdump コマンドを使用して次の作業を行なうことができます。

4.3.3    vdump コマンドを使用したバックアップ・レベルの指定

vdump コマンドでは,増分バックアップのレベル (ダンプ・レベル) を指定することができます。 0 を指定すると,ファイルセットの完全なバックアップが作成されます。 ダンプ・レベルの値が大きいほど,バックアップされるデータ量は小さくなります。 vdump(8) のリファレンス・ページには,ダンプ・レベルをサイクリックに増減して,2 本のテープに完全なバックアップを確保する方法が示されています。

ユーザおよびグループの,クォータ・ファイルとファイルセット・クォータは,root ユーザがダンプ・レベル 0 でバックアップした場合のみ保存されます。 バックアップできるクォータは,ローカルでマウントしているシステムのクォータのみです。

vdump コマンドは,ファイルの更新日時を基にバックアップを行います。 ところが,この方法では増分バックアップが意図したとおりに実行されない可能性があります。 ファイルの名前や場所を変更しても,ファイルの内容が変わらない限り,更新日時は変更されないからです。 この問題を回避するには,バックアップ後にファイルの名前や場所を変更した場合に,touch コマンドを使って該当する各ファイルの更新日時を変更してください。

touch filename

4.3.4    vdump コマンドを使用したテープへのダンプ

vdump コマンドで,1 本のテープに複数のセーブセットを格納 (ダンプ) することができます。 -N オプションを設定して,巻き戻しを行わないように指定するか,あるいは /dev/ntape/tape0 などの巻き戻しなしのデバイスを指定してください。 これにより,vdump コマンド終了時のテープの巻き戻しを回避できます。 次回の vdump コマンドの実行時には,セーブセットが現在のテープ位置から格納されます。

セーブセットをダンプするのに複数のテープが必要な場合,vdump コマンドはその時点で別のテープをマウントするよう指示します。

複数のセーブセットを含むテープからデータをリストアする方法については,4.3.16 項を参照してください。

システムのテープ・デバイスの情報を知るには,/sbin/hwmgr コマンドに -view devices オプションを指定します。

詳細は hwmgr(8) および 『ハードウェア管理ガイド』 を参照してください。

4.3.5    vdump コマンドを使用した標準出力へのダンプ

バックアップのセーブセット・デバイスとしてハイフン (-) を指定すると,vdump コマンドは標準出力に書き出します。 したがって,vdump コマンドと vrestore コマンドをパイプで連結すれば,ファイルセットを別のファイルセットにコピーすることができます。 一般的なコマンド例を以下に示します。 この 2 例は同等の動作を実行します。

# vdump -0f - /usr | vrestore -xf - -D /mnt

# vdump -0 -f - /usr | (cd /mnt; vrestore -x -f -)

rvdump および rvrestore コマンドには,ハイフン (-) は使用できません。 出力デバイスを指定する必要があります。

4.3.6    vdump コマンドを使用したサブディレクトリのダンプ

vdump コマンドに -D オプションを使用して,サブディレクトリを指定すれば,ファイルセット内の指定したサブディレクトリのみをバックアップできます。 -D オプションを使用せずに,ファイルセットの代わりにサブディレクトリを指定すると,vdump コマンドは,そのサブディレクトリを含むファイルセット全体をバックアップします。 -D オプションを指定すると,バックアップは常にレベル 0 で実行されます。

4.3.7    ファイルやディスク・パーティションへのダンプ

セーブセットはファイルとしてディスク上に保存することが可能です。 たとえば,完全バックアップを週一回の頻度でテープに格納して保管しておく一方,増分バックアップをディスク上に保存すれば,増分バックアップを手軽に利用できます。 ディスクはテープ・デバイスより高速なので,ディスクに保存すれば,バックアップやリストアをより速やかに実行できます。

月曜日に行った作業の増分バックアップを,その日の夕方にファイルとして保存する例を次に示します。 この例では,その日のファイルをファイルセット projects.Monday としてバックアップします。 このファイルセットは /projects にマウントされています。

# vdump -9f /backup/projects.Monday /projects

月曜日にディスク上にバックアップした revenue という名前のファイルをリストアするには,次のコマンドを実行します。

# vrestore -xf /backup/projects.Monday -D /projects revenue

セーブセットは空のパーティションに格納することも可能です。 しかしその場合,格納したセーブセットはファイル・システムの制御下では利用できず,パーティションの再割り当てを行うと失われてしまう可能性があります。 /projects にマウントされているファイルセットをパーティション /dev/disk/dsk2g にダンプする例を次に示します。

# vdump -f /dev/disk/dsk2g -D /projects

システムのデバイスを調べるには,/sbin/hwmgr コマンドに -view devices オプションを指定します。

パーティション a やパーティション c は,バックアップの保存先として指定しないでください。 これらのパーティションにはブロック 0 が含まれており,その中にはディスク・ラベルが格納されているためです。 デバイス・ドライバは,ディスク・ラベルを上書きしないので,データの一部が消滅します。 パーティション a やパーティション c へのバックアップを試みると,文字型デバイス (つまり raw デバイス) を使用している場合のみエラー・メッセージが表示されます。 ブロック型特殊デバイスを使用している場合には,エラーは返されません。 ディスクの空きスペースに余裕があるときには,ブロック 0 を含まない他のディスク・パーティションをバックアップ先として使用してください。

パーティション a やパーティション c をバックアップ先として使用する場合には,ディスクの残りの領域にデータが存在しないこと,および disklabel コマンドに -z オプションを使用してあらかじめディスク・ラベルをクリアすることが条件になります。 ディスク・ラベルをクリアすると,そのディスクに格納されていたデータはすべて失われます。 ディスク・ラベルをクリアしない場合でも,vdump コマンドではセーブセットが正しく作成されたように見える場合があります。 ところが,vrestore コマンドを実行すると,ディスク・ラベルがセーブセットの一部として解釈され,次のようなメッセージが表示されます。

vrestore: unable to use save-set; invalid or corrupt format

rvdumprvrestore コマンドでも,同じ結果になります。

詳細は, disklabel(8), vdump(8), vrestore(8), および 『システム管理ガイド』 を参照してください。

ディスク全体をコピーする方法については,『システム管理ガイド』を参照してください。

4.3.8    セーブセットの圧縮

バックアップ時には,セーブセットを圧縮できます。 これによりバックアップに必要なストレージの量が減り,書き込まれるデータが少なくなるため,低速デバイス上でもより高速にダンプを実行できるようになります。 圧縮を行うには vdump コマンドに -C オプションを指定して実行します。 圧縮率を指定することはできません。 圧縮率はダンプの内容によって決まります。

注意

ハードウェア圧縮を自動的に行うテープ・ドライブを使用している場合は,圧縮を指定して vdump コマンドを使用しても,期待したよりも大きいセーブセットになることがあります。 場合によっては,圧縮アルゴリズムが原因で,圧縮済みのデータをさらに圧縮しようとすると,データが大きくなることがあります。

4.3.9    エラー保護機能付きのダンプ

vdump コマンドに -x オプションを使用すれば,破損したブロックを vrestore コマンドでリストアできるように,テープ上にチェックサム・ブロックを置くことができます。 vdump コマンドは,ユーザが指定する n ブロックごとに,これらのブロックを作成します。 n の有効範囲は 2 〜 32です。 省略時の値は 8 です。 vrestore コマンドがブロックの不良で読み取りエラーを検出すると,他のブロックおよびチェックサム・ブロックを使用して不良ブロックを再作成します。

エラー保護付きのダンプでは,n ブロックごとに余計な 1 ブロックを保管する必要があります。 この機能では,ブロックのリストア時に,一連の n ブロックの次の 1 ブロックしか修正できません。 この機能では,保護機能を上げるほど,ストレージが余計に必要になります。

4.3.10    vdump セーブセットに保存したファイルのリスト

セーブセットを調べることで,必要なファイルがバックアップできているかどうかを確認することができます。 バックアップが完了したら,vrestore コマンドに -t オプションを指定して実行し,保存したファイルを表示します。 このコマンドでは,リストア処理は行われません。

4.3.11    clonefset コマンドと vdump コマンドを使用したシステム・ディスクのバックアップ(例)

この例では,clonefset コマンドでバックアップ情報のソースを作成したディスクの,レベル 0 のバックアップを示します。 ここで,バックアップ用ディスク dsk6 は,バックアップ対象ディスク dsk0 と同じサイズであるとします。 この例では,ルート・ドメイン root_domain/dev/disk/dsk0a 上にあります。 ユーザ・ドメイン usr_domain/dev/disk/dsk0g 上にあり,スワップ・パーティションは /dev/disk/dsk0b 上にあリます。/var ファイルセットは usr_domain にあります。

ファイルセット・クローンを作成する間は,システムをシャットダウンし,シングルユーザ・モードでリブートすることをお勧めします。 これにより,//usr, /var で他のユーザが作業していないことが保証されます。 バックアップ作業はマルチ・ユーザ・モードでも可能ですが,システムの活動の少ない時期を選んで作業することを強くお勧めします。

  1. 現在のシステム・ディスクから直接ディスク・ラベルをコピーし,新しいシステム・ディスクにリストアします。

    # disklabel -r dsk0 > /tmp/backupdisklabel
    # disklabel -R -r -t advfs dsk6 /tmp/backupdisklabel
    # rm /tmp/backupdisklabel
    

  2. バックアップ・ドメインとバックアップ・ファイルセットを作成し,マウントします。

    # mkfdmn -F -r /dev/disk/dsk6a root_domain_backup
    # mkfset root_domain_backup root
    # mkfdmn -F /dev/disk/dsk6g usr_domain_backup
    # mkfset usr_domain_backup usr
    # mkfset usr_domain_backup var
    # mkdir /root_backup /usr_backup /var_backup
    # mount root_domain_backup#root /root_backup
    # mount usr_domain_backup#usr /usr_backup
    # mount usr_domain_backup#var /var_backup
    

  3. ファイルセット・クローンを作成し,マウントします。

    # clonefset root_domain root root_clone
    # clonefset usr_domain usr usr_clone
    # clonefset usr_domain var var_clone
    # mkdir /clones /clones/root /clones/usr /clones/var
    # mount root_domain#root_clone /clones/root
    # mount usr_domain#usr_clone /clones/usr
    # mount usr_domain#var_clone /clones/var
    

  4. vdump コマンドを使用してファイルセット・クローンをダンプし,vrestore コマンドを使用してファイルセットをリストアします。

    # vdump -0f - /clones/root | vrestore -xf - -D /root_backup
    # vdump -0f - /clones/usr | vrestore -xf - -D /usr_backup
    # vdump -0f - /clones/var | vrestore -xf - -D /var_backup
    

  5. バックアップの /etc/fdmns ディレクトリを変更して正しいディスクを指すようにします。

    # rm -rf /root_backup/etc/fdmns/root_domain
    # mv /root_backup/etc/fdmns/root_domain_backup\
      /root_backup/etc/fdmns/root_domain
    # rm -rf /root_backup/etc/fdmns/usr_domain
    # mv /root_backup/etc/fdmns/usr_domain_backup\
      /root_backup/etc/fdmns/usr_domain
    

  6. 次のようにして /etc/sysconfigtab ファイルを編集し,新しいスワップ・ファイルを指すようにします。

    1. スワップ・デバイスを設定しているエントリを探します。

      swapdevice=/dev/disk/dsk0b
      

    2. 新しいスワップ・デバイス名と置き換えます。

      swapdevice=/dev/disk/dsk6b
      

  7. システムをシャットダウンし,新しく作成したバックアップを確認するため dsk6 からリブートします。

    dsk6 をバックアップ用に作成していて,元のルート・ドメインに戻したいときは,シャットダウンして dsk0 からリブートします。

4.3.12    リモートでのファイルのダンプおよびリストア

rvdump コマンドは,単一のマウント・ファイル・システムあるいは AdvFS ファイルセット・クローンからリモート・ストレージ・デバイスにファイルをバックアップします。 このコマンドを使用する場合,ダンプしようとするリモート・ノードで rsh コマンドが実行可能であることが必要です。 サーバおよびクライアント・アクセス規則については rsh(8) を参照してください。

rvdump コマンドは vdump コマンドと同じオプションを持ちますが,ファイルのバックアップを置きたいデバイスのノード名を指定する必要があります。 次の例では,ファイルセット sar をノード rachem 上のテープにダンプしています。

# rvdump -0f rachem:/dev/tape/tape0 /sar

リモート・テープ・デバイスからファイルセットをリストアする場合は,次のように入力します。

# rvrestore -xf rachem:/dev/tape/tape0 -D /sar

リモート・バックアップ・コマンドでは,ユーザおよびグループのクォータ・ファイルとファイルセット・クォータはバックアップできません。

rvdumprvrestore コマンドでは,標準出力を表すダッシュ (-) は認識しません。 出力デバイスを指定する必要があります。

4.3.13    vrestore コマンド固有の機能

vrestore コマンドは,vdump コマンドで作成したセーブセットのブロックを処理することによってファイルを復元します。 vrestore コマンドは,UFS dump コマンドで作成したセーブセットには機能しません。

vrestore コマンドを実行するのに root ユーザの権限は必要ありませんが,リストア先のディレクトリの書き込み権限を持っている必要があります。 root ユーザだけが,クォータ・ファイルとファイルセット・クォータをリストアできます。 詳細については, vrestore(8) を参照してください。

vrestore コマンドでは,UFS restore コマンドではサポートしない次のような処理をサポートします。

4.3.14    vrestore コマンドを使用したファイルのリストア

vrestore コマンドでは,リストアするファイルやディレクトリを選択することができます。 このコマンドは,ファイル,パイプ,磁気テープ,またはディスクからデータをリストアすることができます。

vdump および vrestore コマンドは,同じバージョンのものを使用してください。 使用しているバージョンの vrestore でセーブセットのフォーマットを読み取ることができない場合,エラー・メッセージが表示されます。

vrestore コマンドでリストアを実行する前に,このコマンドを -t オプション付きで実行すれば,セーブセットに含まれているすべてのファイルの名前とサイズを一括して表示できます。 この場合リストア操作は行われません。

また,vrestore コマンドに -i (interactive) オプションを指定して実行すると,保存したファイルおよびディレクトリを表示することができます。 これによって,リストアするファイルやディレクトリをリストから個々に選択することができます。

AdvFS ファイルセット・クローンからデータをリストアする作業は,その他のファイルセットからデータをリストアする場合と同様です。

ファイルセット全体をリストアする場合,まずフル・バックアップをリストアしてください。 次にバックアップ以降に変更されたファイルのみが含まれる増分バックアップを使用してリストアしてください。 この場合,フル・バックアップ実行後に削除されたファイルもリストアされることになります。 そこで,これらのファイルは手作業で削除する必要があります。

4.3.15    vrestore コマンドを使用したクォータのリストア

AdvFS のユーザおよびグループのクォータ・ファイルは,AdvFS ファイルセット,UFS ファイル・システムのどちらにもリストアできます。 AdvFS クォータ・ファイルを UFS ファイル・システムにリストアする場合,そのクォータは UFS ファイル・システム上で有効にしなければなりません。 UFS には AdvFS ファイルセット・クォータに相当するものがないため,AdvFS ファイルセット・クォータを UFS ファイル・システムにリストアすることはできません。 クォータのリストア操作は,root ユーザとして実行しなければなりません。

4.3.16    vrestore コマンドを使用した複数のセーブセットを含むテープからのリストア

複数のセーブセットを含んでいるテープから現在の作業ディレクトリに対してリストアを行うには,mt fsf n コマンド (n 個のセーブセットまたはファイルをスキップ) を実行して,リストアするセーブセットの位置を指定します。 続いて,vrestore コマンドを実行します。

次の例では,テープ上の 4 番目のセーブセットを選択しリストアしています。

# mt fsf 3
# vrestore -xf /dev/ntape/tape0

リストアするセーブセット・ディレクトリの位置がわからない場合には,vrestore コマンドに -i オプションを指定してを実行します。 このコマンドで必要なセーブセットまで移動し,対話型インタフェースを使って取り込むファイルを指定します。

vrestore コマンドに -x オプションを指定し,ファイル名を指定して実行すると,セーブセットから選択的にファイルをリストアすることができます。 リストアするファイルに対して,現在の作業ディレクトリ以外のリストア先パスを指定することもできます。

次の例では,ファイル data_file をセーブセット /mnt/fdump からリストアしています。 このセーブセットは,/mnt ディレクトリに保存されています。

# vrestore -f /mnt/fdump -D /mnt -x data_file
vrestore: Date of the vdump save-set: Fri Apr 26 15:27:36 2002
 

リストア処理に複数のテープが必要な場合には,vrestore コマンドによって残りのテープのマウントが促されます。