バックアップ対象のファイルの整合性を確保するため、バックアップは、CD-ROM 装置 (またはネットワーク) からブートするか、または、シングルユーザモードに移行して行います。整合性を確実に確保するためには、CD-ROM 装置 (またはネットワーク) からブートしてバックアップを行うことを推奨します。
a) CD-ROM 装置 (またはネットワーク) からブートしてバックアップを行う場合
a1) バックアップの際に、バックアップ対象のスライスに対して書込みを行う可能性がある場合は、バックアップ対象のディスクのミラーリングを一時的に解除します。
例えば、バックアップ対象のファイルシステムに対して fsck(1M) コマンドを実行すると、fsck(1M) コマンドがバックアップ対象のスライスに書込みを行うことがあります。また、ufs ロギングが有効なファイルシステムを ufsdump(1M) コマンドでバックアップすると、ufsdump(1M) コマンドがバックアップ対象のスライスに書込みを行います。このような場合、事前に本手順を実行してミラーリングを一時的に解除しておく必要があります。
例として、ディスク Root1 とディスク Root2 がグループ Group1 に接続されてミラーリングされていて、Root1 をバックアップ対象とする場合に、Group1 から Root2 を切断する場合のコマンド行を示します。
# sdxdisk -D -c System -g Group1 -d Root2 |
グループ Group1 に接続されているディスク (GROUP フィールドに Group1 と表示されるディスク) が 1 つだけであることを確認します。
# sdxinfo -D -c System |
参考
ディスク Root1 上に INVALID 状態のスライスがある場合は、Root1 の方を切断してください。
keep タイプのディスクを切断した場合 (sdxinfo -D コマンドの出力のうち切断したディスクの TYPE フィールドの値が keep の場合) は、後でグループに接続できるように、タイプ属性を undef に変更してください (または、一旦クラスから削除してから、undef タイプのディスクとして登録しなおしてください)。ディスクのタイプ属性の変更方法は、「5.4.1 クラス構成」の「ディスク属性の変更」または「D.7 sdxattr - オブジェクトの属性値変更」を参照してください。
例) keep タイプのディスク Root1 を Group1 から切断した場合に、Root1 のタイプ属性を undef に変更する方法
# sdxattr -D -c System -d Root1 -a type=undef |
参照
GDS 運用管理ビューを使用する場合は、「5.4 変更」の「5.4.2 グループ構成」を参照してください。
fsck(1M) コマンド、ufs ロギング、および、ufsdump(1M) コマンドについては、Solaris のマニュアルを参照してください。
注意
本手順を実行せずに、以降の手順でバックアップ対象のスライスに対して書込みを行ってしまった場合、バックアップ対象のボリュームの等価性は保証されません。この場合、「6.1.3 リストア手順 (システムがブートできない場合)」に従って、バックアップ対象のボリュームのリストアを行ってください。
a2) システムをシャットダウンします。
# shutdown -g0 -i0 -y |
a3) CD-ROM 装置 (またはネットワーク) からシステムをブートします。
CD-ROM 装置からブートする場合
ok boot cdrom -s |
ネットワークからブートする場合
ok boot net -s |
注意
CD-ROM 装置 (またはネットワーク) からブートする OS のバージョンは、バックアップする OS と同じバージョンにしてください。
GDS でミラーリングしているシステムにおいて、CD-ROM 装置 (またはネットワーク) からブートして不当な操作を行うと、ミラーリング状態が破壊される場合があります。必ず本手順に従って操作を行い、本手順にない操作はできるだけ避けてください。
復旧作業に伴い、物理スライス上にファイルシステムをマウントする場合には、不当な書込みを防ぐために、読取り専用でマウントしてください。読取り専用のオプションを指定せずにマウントした場合、マウントしたスライスへの書込みが行われて、ミラーリング状態が破壊される場合があります。
a4) バックアップするルート (/)、/usr、/var ファイルシステムの物理スライス名を調べて記録します。
# eeprom nvramrc | grep sdx-root-slice
devalias sdx-root-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw
devalias sdx-root-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:a,raw# eeprom nvramrc | grep sdx-usr-slice
devalias sdx-usr-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:g,raw
devalias sdx-usr-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:g,raw# eeprom nvramrc | grep sdx-var-slice
devalias sdx-var-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:b,raw
devalias sdx-var-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:b,raw |
この例では、主となる物理スライス名は以下のとおりです。
/ ： /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw
/usr ： /devices/pci@1f,4000/scsi@3/sd@0,0:g,raw
/var ： /devices/pci@1f,4000/scsi@3/sd@0,0:b,raw
また、副となる物理スライス名は以下のとおりです。
/ ： /devices/pci@1e,4000/scsi@3/sd@0,0:a,raw
/usr ： /devices/pci@1e,4000/scsi@3/sd@0,0:g,raw
/var ： /devices/pci@1e,4000/scsi@3/sd@0,0:b,raw
参考
手順 a1) を実行した場合は、副となる物理スライス名は表示されません。
/usr、/varファイルシステムが存在しない構成の場合は、以下のように物理スライス名が表示されません。
# eeprom nvramrc | grep sdx-usr-slice # eeprom nvramrc | grep sdx-var-slice |
MPLB ディスクの場合、2 本目以降のパスの物理スライス名は以下の方法で調べることができます。ネットワークからブートした環境で、2 本目以降のパスが定義されていれば、そのパスの物理スライスからバックアップを採取することも可能です。
# eeprom nvramrc | grep sdx-root-slice (1 本目のパス)
devalias sdx-root-slice-1 /devices/pci@1f,4000/fibre-channel@4/sd@10,0:a,raw
～# eeprom nvramrc | grep sdx-root-alt-slice (2 本目のパス)
devalias sdx-root-alt-slice-1b /devices/pci@1f,4000/fibre-channel@5/sd@10,0:a,raw
～ |
a5) 手順 a4)で確認した物理スライスのデバイス名から、物理スライス名を確認します。
例として、ルート (/) の主となる物理スライス名を確認する場合の手順を示します。
# ls -l /dev/rdsk | grep /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw |
grep コマンドの引数には、手順 a4) で確認したデバイス名を指定します。
この例では、ルート (/) の主となる物理スライス名は c0t0d0s0 です。
a6) ファイルシステムデータのバックアップをテープ媒体に採取します。
例として、ルートファイルシステムのファイルシステムタイプが ufs である場合に、ufsdump(1M) コマンドを使用して、ルートファイルシステムのデータをテープ装置 /dev/rmt/0 のテープ媒体にバックアップする場合のコマンド行を示します。
# ufsdump 0cf /dev/rmt/0 /dev/rdsk/c0t0d0s0 |
参照
ufsdump(1M) コマンドの詳細については、Solaris のマニュアルを参照してください。使用方法やオプションの意味を確認し、適切なオプションを指定してください。
a7) システムをリブートします。
# shutdown -g0 -i6 -y |
参照
手順 a1) を実行せずに ufs ロギングが有効なファイルシステムを ufsdump(1M) コマンドでバックアップした場合、ミラーの等価性が崩れ、OS が起動できなくなることがあります。このような操作を行った場合は、必ず、対象のファイルシステムをリストアしてください。リストア方法については、「6.1.2 リストア手順 (システムがブートできる場合)」または「6.1.3 リストア手順 (システムがブートできない場合)」を参照してください。
a8) 手順 a1) を実行した場合は、手順 a1) で切断したディスクをグループに再接続します。
# sdxdisk -C -c System -g Group1 -d Root2 |
ディスク Root2 がグループ Group1 に接続されたこと (Root2 の行の GROUP フィールドに Group1 と表示されること) を確認します。
# sdxinfo -D -c System |
等価性コピーが自動的に行われ、等価性コピーが完了するとミラーリング状態が復旧されます。
参照
GDS 運用管理ビューを使用する場合は、「5.4 変更」の「5.4.2 グループ構成」を参照してください。
参考
手順 a1) で keep タイプのディスクをグループから切断し、タイプ属性を undef に変更しなかった場合、手順 a8) がエラーとなりエラーメッセージ "keep disk cannot be connected to existing group" が出力されます。この場合、ディスクのタイプ属性を undef に変更してから、手順 a8) を再実行してください。
ディスクのタイプ属性の変更方法は、手順 a1) の「参考」を参照してください。
b) シングルユーザモードに移行してバックアップを行う場合
b1) 動作中のアプリケーションプログラムを停止します。
b2) システムをシャットダウンします。
# shutdown -g0 -i0 -y |
b3) システムをシングルユーザモードでブートします。
ok boot -s |
b4) バックアップするファイルシステムのボリュームを確認します。
ここでは、/ (ルート) ファイルシステムをバックアップする場合を例として説明します。
# mount
/ on /dev/sfdsk/System/dsk/root
read/write/setuid/largefiles on Mon Aug 9 04:02:38 1999
/usr on /dev/sfdsk/System/dsk/usr
read/write/setuid/largefiles on Mon Aug 9 04:02:38 1999
/var on /dev/sfdsk/System/dsk/var
read/write/setuid/largefiles on Mon Aug 9 04:02:38 1999 |
この例では、/ (ルート) ファイルシステムのボリュームのデバイス特殊ファイルは、/dev/sfdsk/System/dsk/root です。
b5) ファイルシステムのデータのバックアップをテープ媒体に採取します。
ここでは、ufsdump(1M) コマンドを使用してテープ装置 /dev/rmt/0 のテープ媒体にバックアップする場合を例として示します。
# ufsdump 0uf /dev/rmt/0 /dev/sfdsk/System/rdsk/root |
ufsdump(1M) コマンドの引数には、手順 b4) で確認したボリュームのデバイス特殊ファイルを指定します。
参照
ufsdump(1M) コマンドの詳細については、Solaris のマニュアルを参照してください。使用方法やオプションの意味を確認し、適切なオプションを指定してください。
b6) システムを再起動します。
# shutdown -g0 -i6 -y |
