ファイル・システムのデータのバックアップは,アプリケーション障害,システム障害,およびさまさまな予期しない事態に備えた包括的な計画の重要な要素の 1 つです。 適切なバックアップ計画をたてることで,バックアップしたデータが必要なときに確実に使用できるようになります。
この章では,バックアップ計画をたてる際に考慮する必要のある,次のような項目について説明します。
データをバックアップする前に,バックアップするソース,つまり,ファイルのデータと AdvFS メタデータ (ファイル構造情報) が整合性のとれた状態にあり,バックアップの間に変わってしまわないことを確認します。
4.1.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 では次の方法で,アプリケーションが書き込んだデータが,アプリケーションまたはファイル・システムのバッファ・キャッシュにではなく,確実に固定記憶装置に書き込まれることを保証します。
fsync()
システム・コールを使用してキャッシュされたデータをフラッシュします。
ファイルを
O_SYNC
または
O_DSYNC
フラグをつけてオープンすると,すべてのキャッシュされたデータが同期をとってストレージに書き込まれます。
これらの技術を使用するアプリケーションを適切にシャットダウンすると,すべてのキャッシュされたデータは固定記憶装置に確実に書き込まれることになります。
4.1.1.3 同期書き込み方式を用いないデータ整合性の保証
アプリケーションが休止機能を持っていず,同期書き込みを呼び出さない場合,次に示す方法のいずれかを採ることで,アプリケーションがデータ・ファイルに書き込んだすべてのデータが,バックアップを開始する前に,固定記憶装置に書き込まれていることを保証できます。
ファイルセットを -o sync オプションを指定してマウントします。 これによってファイルセットのファイルへの更新が,同期をとってストレージに書き込まれるようになります。 このオプションを使用すると,そのファイルセットを使用するすべてのアプリケーションの性能が著しく低下します。 そこで,この他の方法のいずれかで,ストレージにフラッシュする必要があるデータ部分だけをフラッシュする方法をアプリケーション側で行なわせるようにする方が賢明です。
chfile
コマンドに
-l on
オプションを指定して実行すると,そのファイルを使用するアプリケーションの要求する I/O モードが何であっても,ファイルへの更新が同期をとってストレージにフラッシュされるようになります。
I/O モードについては,5.5.1 項を参照してください。
アプリケーションを適切な段取りを踏んで停止します。
これにより,オペレーティング・システムの
smoothsync
デーモンがキャッシュされたデータをすべてディスクにフラッシュします。
アプリケーションが停止された後,smoothsync_age
カーネルのチューニング・パラメータに指定した秒数の 2 倍以上待ってから,バックアップを開始,またはバックアップ・ソースを作成してください。
smoothsync_age
チューニング・パラメータの値は,次のコマンドで表示することができます。
# sysconfig -q vfs smoothsync_age
データ・ファイルがアプリケーションの観点で矛盾がないことを確認したら,次は AdvFS メタデータの整合性を確認します。 これを適切に行なわないと,AdvFS ドメイン・パニック,システム・パニック,またはユーザ・データの損傷が生じる可能性があります。 バックアップ・ソース内の AdvFS メタデータの整合性を保証するには,次のいずれかの手順を実行します。
4.1.2.1 ドメインをフリーズすることによるメタデータ整合性の保証
freezefs
コマンドによって,ドメインはメタデータの整合を保った状態になり,指定した凍結時間が過ぎるまで,または
thawfs
コマンドで明示的に解凍されるまで,その状態を保ちます。
ドメイン内のすべてのファイルセットが凍結されます。
すべてのメタデータは,複数のボリュームまたは論理ユニット (LUN) に分散されて配置されていることもありますが,すべてディスクにフラッシュされ,凍結期間中は変更されません。
ファイル・システムをフリーズすると,すべての処理中のファイル・システムの操作は処理を完了することができます。 メタデータのアップデートが必要ないファイル・システム操作 (読み取り操作など) は,ファイル・システムがフリーズしても正常に機能します。
ファイル・システムはフリーズすると,次のいずれかの動作で解凍されるまでメタデータの整合が取れている状態を保ちます。
タイムアウト
thawfs
コマンドの実行
クラスタ環境では,フリーズしたファイル・システムのあるノードのシャットダウン,またはクラスタ・メンバのいずれかでの障害の発生。
freezefs
コマンドは,省略時設定でファイル・システムを 60 秒間フリーズします。
タイムアウト値を,これより大きく,あるいは小さくするには
-t
オプションを使用し,秒単位で指定します。
またこのオプションで,thawfs
コマンドで解凍されるまでフリーズしたままになるように指定することもできます。
詳細については,
freezefs
(8)4.1.2.2 ファイルセットをアンマウントすることによるメタデータ整合性の保証
ドメインのすべてのファイルセットをアンマウントすれば,AdvFS メタデータが変更されないことが保証されます。
メタデータの整合性を保ちたい場合は,アンマウントしたドメインに対して実行できる AdvFS Utilities は使用しないでください。
4.2 バックアップ・ソースの作成
マウントしたファイルセットからバックアップ・ソースを作成すると,バックアップを行なうことができます。 ソースは次のいずれかをもとにして作成します。
オリジナルのファイルセット(4.2.1 項)
ファイルセット・クローン (4.2.2 項)
Logical Storage Manager (LSM) スプリット・ミラー (4.2.3 項)
コントローラ・ベースのクローン (4.2.4 項)
コントローラ・ベースのスナップショット (4.2.5 項)
4.2.1 マウントしたオリジナル・ファイルセットのバックアップ・ソースとしての使用
状況によっては,マウントしたオリジナル・ファイルセットをバックアップ・ソースとして使用することができます。
4.2.1.1 長所と短所
表 4-1に,オリジナル・ファイルセットをバックアップ・ソースとして使用することの長所と短所を示します。
表 4-1: マウントしたオリジナル・ファイルセットのバックアップ・ソースとしての使用
長所 | 短所 |
簡単さ。 新しくマウント・ポイントを作成する必要はありません。 | バックアップ中はマウント・ポイントにあるファイルをアップデートできない。 アップデートすると,データに矛盾が生まれる恐れがあります。 |
バックアップ処理を他のホストに任せることはできない。 |
ファイルセットのデータの整合性を保つには 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.1 節の手順に従います。 データが複数のファイルセットにまたがっている場合,すべての関連するファイルセットの整合性を確認する必要があります。
ファイルセット・クローン作成はすべて,AdvFS 内で行なわれるので,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。
4.2.2.3 バックアップ・ソースの準備
ファイルセット・クローンを作成するために,オリジナル・ファイルセットのデータが整合性のとれた状態であることを確認します。
そして,clonefset
コマンドでファイルセット・クローンを作成します。
次の例では,ドメイン
domain1
内の ファイルセット
pssm
のクローンを作成しています。
新しいファイルセット・クローンの名前は
pssm_clone
です。
クローンを作成しマウントします。
# clonefset domain1 pssm pssm_clone # mkdir /pssm_clone # mount -t advfs domain1#pssm_clone /pssm_clone
pssm_clone
を使用してバックアップ・プロセスを実行します。
詳細は
4.3.11 項
を参照してください。
クローンを削除します。
# 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.1 節の手順に従います。
ストレージが 1 つのLSM ボリュームからなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。
ストレージが複数の LSM ボリュームからなる場合は,4.1.2 項
を参照してください。
4.2.3.3 バックアップ・ソースの準備
ドメインが複数の LSM ボリュームからなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなるかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。
次の例では,オリジナル・ドメインが 2 つの LSM ボリュームからなり,それぞれからミラーが切り離されていると仮定します。
データは,/data
にマウントされているファイルセット
data
のあるドメインにあります。
2 つのミラー・ボリュームは,/dev/vol/mirrorvol1
と
/dev/vol/mirrorvol2
です。
ドメインをフリーズします。
# /usr/sbin/freezefs /data
ミラーを切り離し,新しい LSM ボリュームとして再構築するために LSM コマンドを実行します。 手順は,『Logical Storage Manager』 を参照してください。
LSM スプリット・ミラーを作成したら,ドメインのメタデータを解凍します。
# /usr/sbin/thawfs /data
アプリケーションは引き続き,オリジナル・ドメインで動作できます。
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
コマンドは使用しないでください。
ミラーにアクセスできなくなります。
マウント・ポイント・ディレクトリを作成し,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.1 節の手順に従います。
ストレージが 1 つのハードウェア LUN からなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。
ストレージが複数のハードウェア LUN からなる場合は,4.1.2 項
を参照してください。
4.2.4.3 バックアップ・ソースの準備
ドメインが複数の LUN からなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなるかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。
次の例では,データは,ファイルセット
data
があるドメインに置かれていて,そのドメインは
/data
にマウントされていると仮定します。
作成されるクローンは,/dev/disk/dsk25c
と
/dev/disk/dsk26c
です。
ドメインをフリーズします。
# /usr/sbin/freezefs /data
コントローラ・ベースのクローンを作成するのに必要なコマンドを実行します。 たとえば,Compaq HSG80 コントローラを使用する場合の,これらのコマンドの例は,Best Practice ドキュメントの『Using StorageWorks HSG80 Controller-Based Cloningand Snapshotting』を参照してください。
ドメインのメタデータを解凍します。
# /usr/sbin/thawfs /data
アプリケーションは引き続き,オリジナル・ドメインで動作できます。
新しくクローンを作成した LUN のブロック型デバイス特殊ファイルを作成します。
これは,新しいバックアップ・ソースをマウントするホスト上で行ないます。
/sbin/hwmgr
コマンドは非同期に実行されるため,実際にブロック型デバイス特殊ファイルが作成される前に終了している場合があります。
スタンドアロン・システムの場合,次のコマンドを実行します。
# /sbin/hwmgr -scan scsi
クラスタの場合,次のコマンドを実行します。
# /sbin/hwmgr scan component -category scsi_bus -cluster
新しい LUN が作成されるたびに,新しいデバイス特殊ファイルが作成されます。
ブロック型デバイス特殊ファイルを探します。
# /sbin/hwmgr -view devices
/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
コマンドは使用しないでください。
クローン・データにアクセスできなくなります。
ディレクトリを作成し,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.1 節の手順に従います。
ストレージが 1 つのハードウェア LUN からなるドメインの場合,AdvFS メタデータの整合性を保証するために特に何もする必要はありません。
ストレージが複数のハードウェア LUN からなる場合は,4.1.2 項
を参照してください。
4.2.5.3 バックアップ・ソースの準備
ドメインが複数の LUN からなる場合だけ,凍結/解凍の手順が必要です。 複数のボリュームからなっているかわからない場合は,とりあえず,これらのコマンドを試してみます。 ドメインに影響はありません。 単一ファイルセットの凍結/解凍の手順で,ドメイン全体を凍結/解凍できます。
次の例では,データが,ファイルセット
data
があるドメインに置かれていて,そのドメインは
/data
にマウントされていると仮定します。
作成されるスナップショットは,/dev/disk/dsk25c
と
/dev/disk/dsk26c
です。
ドメインをフリーズします。 省略時の凍結時間は 60 秒です。
# /usr/sbin/freezefs /data
コントローラ・ベースのスナップショットを作成するのに必要なコマンドを実行します。 たとえば,Compaq HSG80 コントローラを使用する場合の,これらのコマンドの例は,Best Practice ドキュメントの『Using StorageWorks HSG80 Controller-Based Cloning and Snapshotting』を参照してください。
ドメインのメタデータを解凍します。
# /usr/sbin/thawfs /data
アプリケーションは引き続き,オリジナル・ドメインで動作できます。
新しくスナップショットを作成した LUN のブロック型デバイス特殊ファイルを作成します。
これは,新しいバックアップ・ソースをマウントするホスト上で行ないます。
/sbin/hwmgr
コマンドは非同期に実行されるため,実際にブロック型デバイス特殊ファイルが作成される前に終了している場合があります。
スタンドアロン・システムの場合,次のコマンドを実行します。
# /sbin/hwmgr -scan scsi
クラスタの場合,次のコマンドを実行します。
# /sbin/hwmgr scan component -category scsi_bus -cluster
新しい LUN が作成されるたびに,新しいデバイス特殊ファイルが作成されます。
ブロック型デバイス特殊ファイルのファイルを探します。
# /sbin/hwmgr -view devices
/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
コマンドは使用しないでください。
スナップショット・データにアクセスできなくなります。
ディレクトリを作成し,snap_domain
のファイルセット
data
をマウントします。
# mkdir /backup
スナップショット・ドメインとファイルセットを元のホストにマウントしていない場合,次のコマンドを入力します。
# mount snap_domain#data /backup
スナップショット・ドメインとファイルセットを元のホストにマウントしている場合,次のコマンドを入力します。
# mount -o dual snap_domain#data /backup
バックアップは
/backup
ディレクトリから行なえるようになります。
4.3 バックアップ方式とツール
データとメタデータの整合性が確認されたバックアップ・ソースを作成したら,データをバックアップすることができます。 これには,いくつかの方法があります。
バックアップを行なうのにオリジナル・データと同じホスト上にバックアップ・ソースをマウントする。 バックアップ・ソースがオリジナル・ファイルセットまたはファイルセット・クローンのときに必要です。
バックアップを行なうのにオリジナル・データとは異なるホスト上にバックアップ・ソースをマウントする。 これによって元のホストのバックアップ処理による負荷を軽減することができます。
raw LUN の内容をディスクから直接テープ,または他のメディアにバックアップする。
バックアップとリストアには,多くのコマンドを使用することができます。
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
コマンドで保管された情報を正しくリストアすることができません。vdump
とvrestore
のダンプ・ファイルの形式は,Version 4 と Version 5 のオペレーティング・システムで互換性があります。
セーブセットは,複数のテープにまたがってバックアップすることができ,また同じテープに複数のセーブセットを収めることもできます。
テープ上の各セーブセットはファイル・マークによって区切られます。
ファイル・マークは, 次の例では,
マウントされたファイルセットを保存する。
バックアップしたいサブディレクトリを選択する。
必ずしもファイルセット全体をダンプする必要はありません。
ファイルを圧縮して,セーブセット・サイズを最小限に抑える。
メモリ内のバッファ数を指定する。
ストレージ・デバイスに適したバッファ数を指定することにより,スループットを最大限に高めることができます。
現在の
ダンプ・プロセス中にヘルプ情報を表示する。
警告メッセージは表示しないで,エラー・メッセージのみを表示するように指定する。
バックアップ時にファイルの名前を表示する。
エラー保護システムによって出力を構成することにより,リストア時に読み取りエラーが生じた場合でもデータをリストアする。
ゼロで満たさない AdvFS および UFS のスパース・ファイルを処理する。
ユーザおよびグループの,クォータ・ファイルとファイルセット・クォータは,root ユーザがダンプ・レベル 0 でバックアップした場合のみ保存されます。
バックアップできるクォータは,ローカルでマウントしているシステムのクォータのみです。
セーブセットをダンプするのに複数のテープが必要な場合, 複数のセーブセットを含むテープからデータをリストアする方法については,4.3.16 項を参照してください。
システムのテープ・デバイスの情報を知るには, 詳細は
バックアップのセーブセット・デバイスとしてハイフン ( セーブセットはファイルとしてディスク上に保存することが可能です。
たとえば,完全バックアップを週一回の頻度でテープに格納して保管しておく一方,増分バックアップをディスク上に保存すれば,増分バックアップを手軽に利用できます。
ディスクはテープ・デバイスより高速なので,ディスクに保存すれば,バックアップやリストアをより速やかに実行できます。
月曜日に行った作業の増分バックアップを,その日の夕方にファイルとして保存する例を次に示します。
この例では,その日のファイルをファイルセット
月曜日にディスク上にバックアップした
セーブセットは空のパーティションに格納することも可能です。
しかしその場合,格納したセーブセットはファイル・システムの制御下では利用できず,パーティションの再割り当てを行うと失われてしまう可能性があります。
システムのデバイスを調べるには, パーティション
パーティション
詳細は,
ディスク全体をコピーする方法については,『システム管理ガイド』を参照してください。
バックアップ時には,セーブセットを圧縮できます。
これによりバックアップに必要なストレージの量が減り,書き込まれるデータが少なくなるため,低速デバイス上でもより高速にダンプを実行できるようになります。
圧縮を行うには
ハードウェア圧縮を自動的に行うテープ・ドライブを使用している場合は,圧縮を指定して
エラー保護付きのダンプでは,n
ブロックごとに余計な 1 ブロックを保管する必要があります。
この機能では,ブロックのリストア時に,一連の
n
ブロックの次の 1 ブロックしか修正できません。
この機能では,保護機能を上げるほど,ストレージが余計に必要になります。
テープでは信頼性が低いと思われる場合,あるいは正確なバックアップが必要でバックアップ用に多数のテープを利用できる場合には, テープの信頼性は高いと考えられるが,稀に発生する不良ブロックを訂正できるようにするためには,
セーブセットを調べることで,必要なファイルがバックアップできているかどうかを確認することができます。
バックアップが完了したら, この例では, ファイルセット・クローンを作成する間は,システムをシャットダウンし,シングルユーザ・モードでリブートすることをお勧めします。
これにより, 現在のシステム・ディスクから直接ディスク・ラベルをコピーし,新しいシステム・ディスクにリストアします。
バックアップ・ドメインとバックアップ・ファイルセットを作成し,マウントします。
ファイルセット・クローンを作成し,マウントします。
バックアップの
次のようにして
スワップ・デバイスを設定しているエントリを探します。
新しいスワップ・デバイス名と置き換えます。
システムをシャットダウンし,新しく作成したバックアップを確認するため
リモート・テープ・デバイスからファイルセットをリストアする場合は,次のように入力します。
リモート・バックアップ・コマンドでは,ユーザおよびグループのクォータ・ファイルとファイルセット・クォータはバックアップできません。
ソース・ディレクトリ・パスを表示することができます。
セーブセット構造を表示することができます。
これは,保存したファイルのリストです。
情報メッセージは表示せずにエラー・メッセージだけを表示することができます。
既存のファイルを見つけた場合の
また, AdvFS ファイルセット・クローンからデータをリストアする作業は,その他のファイルセットからデータをリストアする場合と同様です。
ファイルセット全体をリストアする場合,まずフル・バックアップをリストアしてください。
次にバックアップ以降に変更されたファイルのみが含まれる増分バックアップを使用してリストアしてください。
この場合,フル・バックアップ実行後に削除されたファイルもリストアされることになります。
そこで,これらのファイルは手作業で削除する必要があります。
AdvFS のユーザおよびグループのクォータ・ファイルは,AdvFS ファイルセット,UFS ファイル・システムのどちらにもリストアできます。
AdvFS クォータ・ファイルを UFS ファイル・システムにリストアする場合,そのクォータは UFS ファイル・システム上で有効にしなければなりません。
UFS には AdvFS ファイルセット・クォータに相当するものがないため,AdvFS ファイルセット・クォータを UFS ファイル・システムにリストアすることはできません。
クォータのリストア操作は,root ユーザとして実行しなければなりません。
複数のセーブセットを含んでいるテープから現在の作業ディレクトリに対してリストアを行うには, 次の例では,テープ上の 4 番目のセーブセットを選択しリストアしています。
リストアするセーブセット・ディレクトリの位置がわからない場合には, 次の例では,ファイル
リストア処理に複数のテープが必要な場合には,vdump
コマンドは,新しいファイルや一定の日付以降に変更したファイルを,省略時のストレージ・デバイスまたは指定のデバイスにコピーする際に,vdump
コマンドがセーブセットをクローズするときに書き込まれます。
vdump
コマンドの構文を次に示します。
vdump
options mount_point
/psm
にマウントされたファイルセットをテープにダンプしています。
# vdump -0 -f /dev/tape/tape0_d1 /psm
vdump
コマンドは,次に示すように,UFS
dump
コマンドが持っていない多数の機能を備えています。
vdump
コマンドを使用して次の作業を行なうことができます。
vdump
バージョン番号を表示する。
4.3.3 vdump コマンドを使用したバックアップ・レベルの指定
vdump
コマンドでは,増分バックアップのレベル (ダンプ・レベル) を指定することができます。
0 を指定すると,ファイルセットの完全なバックアップが作成されます。
ダンプ・レベルの値が大きいほど,バックアップされるデータ量は小さくなります。
vdump
(8)vdump
コマンドは,ファイルの更新日時を基にバックアップを行います。
ところが,この方法では増分バックアップが意図したとおりに実行されない可能性があります。
ファイルの名前や場所を変更しても,ファイルの内容が変わらない限り,更新日時は変更されないからです。
この問題を回避するには,バックアップ後にファイルの名前や場所を変更した場合に,touch
コマンドを使って該当する各ファイルの更新日時を変更してください。
touch
filename
4.3.4 vdump コマンドを使用したテープへのダンプ
vdump
コマンドで,1 本のテープに複数のセーブセットを格納 (ダンプ) することができます。
-N
オプションを設定して,巻き戻しを行わないように指定するか,あるいは
/dev/ntape/tape0
などの巻き戻しなしのデバイスを指定してください。
これにより,vdump
コマンド終了時のテープの巻き戻しを回避できます。
次回の
vdump
コマンドの実行時には,セーブセットが現在のテープ位置から格納されます。
vdump
コマンドはその時点で別のテープをマウントするよう指示します。
/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
rvdump
や
rvrestore
コマンドでも,同じ結果になります。
disklabel
(8)vdump
(8)vrestore
(8)4.3.8 セーブセットの圧縮
vdump
コマンドに
-C
オプションを指定して実行します。
圧縮率を指定することはできません。
圧縮率はダンプの内容によって決まります。
注意
vdump
コマンドを使用しても,期待したよりも大きいセーブセットになることがあります。
場合によっては,圧縮アルゴリズムが原因で,圧縮済みのデータをさらに圧縮しようとすると,データが大きくなることがあります。
vdump
コマンドに
-x
オプションを使用すれば,破損したブロックを
vrestore
コマンドでリストアできるように,テープ上にvdump
コマンドは,ユーザが指定する
n
ブロックごとに,これらのブロックを作成します。
n
の有効範囲は 2 〜 32です。
省略時の値は 8 です。
vrestore
コマンドがブロックの不良で読み取りエラーを検出すると,他のブロックおよびチェックサム・ブロックを使用して不良ブロックを再作成します。
-x
オプションの値を 2 に設定します。
これにより,保存される 2 ブロックごとに不良ブロックが 1 つあるようなエラーの訂正を行うことが可能になります。
ただし,2 ダンプ・ブロックごとにチェックサム・ブロックが書き込まれるため,必要なテープの量は 50% 増加します。
-x
オプションの値を 32 に設定します。
この場合には,32 ブロック書き込むごとにブロックが 1 つ追加されるため,3% の余分なテープが必要になります。
これで,32 ダンプ・ブロックごとに 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
で他のユーザが作業していないことが保証されます。
バックアップ作業はマルチ・ユーザ・モードでも可能ですが,システムの活動の少ない時期を選んで作業することを強くお勧めします。
# disklabel -r dsk0 > /tmp/backupdisklabel
# disklabel -R -r -t advfs dsk6 /tmp/backupdisklabel
# rm /tmp/backupdisklabel
# 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
# 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
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
/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
/etc/sysconfigtab
ファイルを編集し,新しいスワップ・ファイルを指すようにします。
swapdevice=/dev/disk/dsk0b
swapdevice=/dev/disk/dsk6b
dsk6
からリブートします。
dsk6
をバックアップ用に作成していて,元のルート・ドメインに戻したいときは,シャットダウンして
dsk0
からリブートします。
rvdump
コマンドは,単一のマウント・ファイル・システムあるいは AdvFS ファイルセット・クローンからリモート・ストレージ・デバイスにファイルをバックアップします。
このコマンドを使用する場合,ダンプしようとするリモート・ノードで
rsh
コマンドが実行可能であることが必要です。
サーバおよびクライアント・アクセス規則については
rsh
(8)rvdump
コマンドは
vdump
コマンドと同じオプションを持ちますが,ファイルのバックアップを置きたいデバイスのノード名を指定する必要があります。
次の例では,ファイルセット
sar
をノード
rachem
上のテープにダンプしています。
# rvdump -0f rachem:/dev/tape/tape0 /sar
# rvrestore -xf rachem:/dev/tape/tape0 -D /sar
rvdump
と
rvrestore
コマンドでは,標準出力を表すダッシュ (-) は認識しません。
出力デバイスを指定する必要があります。
4.3.13 vrestore コマンド固有の機能
vrestore
コマンドは,vdump
コマンドで作成したセーブセットのブロックを処理することによってファイルを復元します。
vrestore
コマンドは,UFS
dump
コマンドで作成したセーブセットには機能しません。
vrestore
コマンドを実行するのに root ユーザの権限は必要ありませんが,リストア先のディレクトリの書き込み権限を持っている必要があります。
root ユーザだけが,クォータ・ファイルとファイルセット・クォータをリストアできます。
詳細については,
vrestore
(8)vrestore
コマンドでは,UFS
restore
コマンドではサポートしない次のような処理をサポートします。
vrestore
の現在のバージョン番号を表示することができます。
vrestore
コマンドの動作を指定することができます。
既存ファイルを常に上書きするか,既存ファイルは常に上書きしないか,あるいはそのたびにユーザに確認するかを選択することができます。
4.3.14 vrestore コマンドを使用したファイルのリストア
vrestore
コマンドでは,リストアするファイルやディレクトリを選択することができます。
このコマンドは,ファイル,パイプ,磁気テープ,またはディスクからデータをリストアすることができます。
vdump
および
vrestore
コマンドは,同じバージョンのものを使用してください。
使用しているバージョンの
vrestore
でセーブセットのフォーマットを読み取ることができない場合,エラー・メッセージが表示されます。
vrestore
コマンドでリストアを実行する前に,このコマンドを
-t
オプション付きで実行すれば,セーブセットに含まれているすべてのファイルの名前とサイズを一括して表示できます。
この場合リストア操作は行われません。
vrestore
コマンドに
-i
(interactive) オプションを指定して実行すると,保存したファイルおよびディレクトリを表示することができます。
これによって,リストアするファイルやディレクトリをリストから個々に選択することができます。
4.3.15 vrestore コマンドを使用したクォータのリストア
4.3.16 vrestore コマンドを使用した複数のセーブセットを含むテープからのリストア
mt fsf n
コマンド (n
個のセーブセットまたはファイルをスキップ) を実行して,リストアするセーブセットの位置を指定します。
続いて,vrestore
コマンドを実行します。
# 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
コマンドによって残りのテープのマウントが促されます。