Articles
Server and Storage Administration
Oracle Solaris 11 でのシステムアーカイブの実行と復旧の手順
2011 年 11 月
Jesse Butler 著
インストールされて構成されたOracle Solaris 11ホストのバックアップとリカバリのために、 ZFS アーカイブを作成する方法を紹介します。
この記事に記載されている手順は、基本的な障害回復計画のコアとなるものであると同時に、システムのサービスを新しいブート環境へ、あるいは同じモデルで完全に異なるシステム上に移行するために使用することもできます。インストールされたソフトウェアの別モデルのシステムへの移行には対応していませんのでご注意ください。
|
手順の概要
ZFS アーカイブは、関連するデータセットと共にルートプールに作成されます。また、サードパーティソフトウェアやローカルユーザーのアカウントデータといったような重要な情報を格納するためのプールを移行したり復元したりするために使用される ZFS プールとしても作成されます。
システム全体をバックアップし、復元するためには、 Oracle Solaris Administration: ZFS File Systems に記述されているとおり、ルートファイルシステム以外のデータや、ノードが提供するサービスのために必要となるデータと共に、すべての ZFS プールとデータセットはアーカイブされている必要があります。これは、構成の詳細、サードパーティのソフトウェア、ノードに固有の要素 (ローカルユーザーアカウントやデータなど) を含むすべてがリカバリシステム上に復元されることが保証され、それによって完全に機能する状態で復元されることが保証されます。この記事ではルートプール上での手順について解説します。
アーカイブが作成されると、USB ドライブなどのローカルリムーバブルメディア上に保存することもできますし、ネットワークを介してファイルサーバーに送信しておいて、後で取得することも可能です。アーカイブを使用する際には、次の手順に従ってください。
- リカバリシステムは、Oracle Solaris 11 インストールメディアから起動され、スーパーユーザー権限の必要なシェルが起動します。
- ブートディスクデバイスが選択されて構成され、新しい ZFS ルートプールが作成されます。
- アーカイブされた ZFS データセットは新しいプールに復元されます。
- 最終的なシステム構成が実行され、システムはその後再起動します。
システム要件と注意事項
Oracle Solaris 11 を実行しているホストはいずれの場合もこの手順に当てはまります。新しいディスクやシステムに復元する必要のあるシステムアーカイブは、次の要件を満たさなくてはなりません。
- アーカイブされたシステムと復元されたシステムは、同じモデルである必要があり、Oracle Solaris 11 の最小要件を満たしていなくてはなりません。
- 新しい ZFS プールを収納するディスクには、少なくともアーカイブされたプールに割り当てられた領域の合計容量の大きさが必要になります (ディスク容量の詳細は後述します)。
- アーカイブされるシステム、復元するシステム共にルート権限のアクセスが要求されます。
アーカイブには、ZFS データセットとしてアーカイブされたすべてのソフトウェアと構成情報が含まれています。含まれる情報には次のものがあげられますが、この限りではありません。
- OS と OS に関連した構成、チューニング
- すべてのブート環境 (BE) と以前の ZFS スナップショット
- ホスト名、ルーティング情報、ネームサービス構成を含むネットワーク構成
- ローカルにインストールされたすべてのソフトウェアとローカルに格納された関連データ
- ローカルに構成されたユーザーアカウントとローカルユーザーデータ
- ゾーンと関連構成データ
これは、ほとんどのシナリオで、以下に示す手順を行えば、追加の構成処理は必要ないということを意味します。
ハードウェア固有の構成データはアーカイブイメージ内に含まれません。同じモデルのまったく新しいシステムに移行する際にこの手順を実行する場合、ハードウェア固有のシステムの特徴はバックアップとして転送されませんが、次の情報はその限りではありません。
- ディスク容量と構成 (ZFS プール構成を含む)
- メモリ容量と構成
- ハードウェアイーサネットアドレス
- インストールされたハードウェア周辺装置
インストールされたハードウェア周辺装置に関連した注意があります。システムが直接接続された外部ストレージや、Fibre チャネル、InfiniBand アダプタのような特別なネットワークハードウェアを使用する場合、ストレージにアクセスするために、それらの情報はリカバリシステム上にインストールされている必要があります。
フェーズ 1: アーカイブの作成
この項ではアーカイブを作成する際に必要となる準備について説明します。
準備
リカバリの準備のために、アーカイブされる各プールのディスクトポロジと ZFS プール構成に注目します。この記事の意図に沿って、ここでもルートプールにフォーカスしています。リカバリシステム上のターゲットディスクは同じように構成される必要があり、新しい ZFS プールは適切なサイズに設定する必要があります。リカバリシステム上でデータセットを復元するための十分な領域として、最小でも各プールに割り当てられたサイズ (以下に示す zpool list 出力の ALLOC 列の数値) が必要です。
# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 68G 51.6G 16.4G 75% 1.00x ONLINE -
プールの容量 (CAP 列の数値) が 80% を超えると、プールの容量を増やすことを計画するように指示されます。構成要素やワークロードにもよりますが、プールの空き容量を増やすことでパフォーマンスにも良い影響をもたらす可能性があります。ZFS ファイルシステムの管理と関連するパフォーマンスについては、Oracle Solaris Administration: ZFS File Systems を参照してください。
後で復元するための準備として、さまざまなコマンドの出力をリカバリ中に参照できるように、アーカイブのファイルと一緒に保存しておく必要があります。リスト 1 に最小限のコマンドを示しますが、システム構成によっては出力されるそのほかの構成情報も役に立つ場合があります。リスト 1 のコマンドは、ルートプール (rpool) の出力例のみを示しています。
リスト 1: 出力を保存する必要のあるコマンド
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 68G 51.6G 16.4G 75% 1.00x ONLINE -
# zpool get all rpool
NAME PROPERTY VALUE SOURCE
rpool size 68G -
rpool capacity 75% -
rpool altroot - default
rpool health ONLINE -
rpool guid 18397928369184079239 -
rpool version 33 default
rpool bootfs rpool/ROOT/snv_175a local
rpool delegation on default
rpool autoreplace off default
rpool cachefile - default
rpool failmode wait default
rpool listsnapshots off default
rpool autoexpand off default
rpool dedupditto 0 default
rpool dedupratio 1.00x -
rpool free 16.4G -
rpool allocated 51.6G -
rpool readonly off -
# zpool status
pool: rpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c5t0d0s0 ONLINE 0 0 0
errors: No known data errors
# format c5t0d0s0
selecting c5t0d0s0
[disk formatted]
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show disk ID
volname - set 8-character volume name
!<cmd> - execute <cmd>, then return
quit
format> p
PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
!<cmd> - execute <cmd>, then return
quit
partition> p
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 root wm 1 - 14086 68.35GB (14086/0/0) 143339136
1 unassigned wm 0 0 (0/0/0) 0
2 backup wu 0 - 14086 68.35GB (14087/0/0) 143349312
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0
partition> ^D
#
アーカイブされるシステムから出力される上記の情報は、リカバリ中に有益と思われるさまざまな情報と共にファイルに保存して、後のリカバリの際に使用できるようにアーカイブファイルと一緒に格納するようにしてください。
あるいは、後で参照するために必要となるすべてのシステム構成情報を収集するために Oracle Explorer Data Collector を使用することもできます。Oracle Explorer Data Collector と関連するドキュメントはMy Oracle Support から入手することができます (サポート契約とログインが必要です)。
ZFS 管理と容量計画についての詳細は Oracle Solaris Administration: ZFS File Systems を参照してください。
アーカイブの作成
ルートプールのアーカイブを作成し、すべてのスナップショットと BE を含めるために、ZFS レプリケーションストリームが作成されます。まず、プールのトップレベルから再帰的なスナップショットを作成する必要があります。 同じ方法で、アーカイブすべきそのほかのプールのアーカイブを作成し、復元したホストまで持ち出すことができます。
rpool はデフォルトルートプール名ですが、ルートプールにはシステムによって別の名前が付けられている可能性があります。すべてのプールとデータセットがアーカイブされた後であれば、これは大きな問題にはなりません。ただ、ルートファイルシステムだけが必要とされるか、あるいはバックアップ用に選択された BE のセットのみが必要で、どのプールに含まれているかはっきりしていない場合、 beadm list –d コマンドでこの情報を確認することができます。これ以降この項では、ルートプールを参照する際にはデフォルト名の rpool を使用します。
次のコマンドは archive という名前のルートプールの再帰的スナップショットを作成します。スナップショット名は、日付など、内容がわかるような名前を付けることができます。
# zfs snapshot -r rpool@archive
これで再帰的スナップショットが作成されましたが、ここからシステムの移行やリカバリに関連のあるデータを含んでいない可能性のあるスワップやダンプデバイスのスナップショットは削除します。これらを削除することで、多くの場合アーカイブのサイズを大幅に減らすことができます。
次のコマンドは、デフォルト名がスワップとダンプのデバイススナップショットを削除することができますが、ホスト上にはこのほかにも配備されている可能性があります。
注: ダンプデバイスに関していうと、/var データセット (コアアーカイブ形式) に抽出されていないデータがダンプデバイスに存在することもありますが、可能性は低いです。もしそのようなケースでダンプデバイスの内容を保存したいという場合は、ダンプデバイススナップショットを削除する前に、内容をファイルシステムにダンプしてください。詳細については dumpadm(1M) を参照してください。
# zfs destroy rpool/swap@archive # zfs destroy rpool/dump@archive
デフォルトで名前付けされたデバイス以外にもデバイスが存在するかどうか確認したい場合は、swap(1m) と dumpadm(1m) を使用して、それぞれスワップ名の一覧とダンプデバイスの一覧を表示することができます。
これでスナップショットの準備ができました。次に、このスナップショットを保管のために1つのファイルに送ります。1 つ以上の ZFS プールがアーカイブされる状況では、各プールはスナップショットを持ち、各スナップショットは自身のアーカイブファイルに送信されます。繰り返しになりますが、この例の手順ではルートプールのためのアーカイブ作成にフォーカスして説明します。もちろん同じ方法でシステム上にほかのプールをアーカイブすることも可能です。
ZFS send コマンドは gzip コマンドにパイプされ、プールのスナップショットのアーカイブが含まれるファイルが結果として圧縮されます。このアーカイブファイルを作成する際に、ホスト名、日付、または内容が容易にわかるような単語を使うなど、後にこのアーカイブの内容を見つける際に判断しやすい一意の名前を付けることをお勧めします。
後で再配置するために、アーカイブファイルはローカルに保存しておくことも可能ですし、リムーバブルメディア上に作成しておくこともできます。圧縮されてはいますが、ローカルマシン上、またはアーカイブのファイルサーバー上の十分なストレージ領域を確保する必要があります。zpool list で報告された ALLOC の数値の合計が十分な容量の基本と覚えておくと便利です。
アーカイブファイルをローカルに作成するには、次のコマンドを実行します。リカバリのイメージファイル名は、後でこのアーカイブを使用する際に判別しやすい名前であれば文字列は何を使用しても構いません。たとえばわかりやすい名前として、ホスト名に日付を追加したものが一般的です。
# zfs send -Rv rpool@archive | gzip > /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz
これで、アーカイブファイルは後で検索するためにファイルサーバーに移動されます。
オプションで、アーカイブファイルは次に示すように、NFS マウントパスに直接書きこむことができます。
# zfs send -Rv rpool@archive | gzip > /net/FILESERVER/path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz
同様に、ssh を使用してアーカイブファイルをファイルサーバーにストリームすることもできます。
# zfs send -Rv rpool@archive | gzip | ssh USER@FILESEVER "cat> /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz"
この最後のオプションを使用してネットワーク越しにアーカイブをストリームしている間、 ssh 転送は保存停止・復元再開は機能しないことに注意してください。このためネットワーク接続が中断した場合、コマンドは最初からやり直す必要があります。
このためファイルシステムに格納するアーカイブファイルは、バックアップを作成しておくことを強くお勧めします。
これでリカバリアーカイブが作成され、ローカルのスナップショットを破棄することができます。
# zfs destroy -r rpool@archive
フェーズ 2: アーカイブからのリカバリ
システムブート
リカバリフェーズは、システムリカバリやシステム移行オペレーションが必要な場合、いつでも着手することができます。
はじめに、Oracle Solaris 11 インストールメディアからリカバリシステムをブートします。リカバリシステムをブートするために使用するインストールメディアは、アーカイブが構築された Oracle Solaris 11 と同じバージョンを使用してください。たとえば、Oracle Solaris 11 11/11 ホストでアーカイブが作成された場合、このフェーズでは Oracle Solaris 11 11/11 インストールメディアを使用する必要があります。システムは DVD、USB デバイス、またはネットワークからブートすることができます。このメディアからインストールされたシステムではなく、システムのブートのためだけに利用されるメディアということです。ブートが完了すると、リカバリ手順を開始できる場所でシェルが起動します。
DVD または USB インストールメディアからブートするには、メディアを挿入し、ブートデバイスとして使用する適切なデバイスを選択します。LiveCD の場合、GNOME デスクトップセッションを使用してリカバリ処理を実行することができます。デスクトップが開始したら、端末ウィンドウで残りの手続きを実行します。テキストベースメディアを使用している場合は、テキストインストーラメニューが立ち上がったときにシェルの終了を選びます。
Oracle Solaris Automated Installer (AI) または AI メディアのローカルコピーもシステムのブートに使用することができます。x86 ホスト上では、「Text Installer and command line (テキストインストーラとコマンド行)」GRUBメニューエントリを選択するとテキストインストーラが実行され、メニューからシェルを選択することができるようになります。
同様に、SPARC ホスト上でも、自動インストーラを起動せずに AI メディアをブートすると (ローカル、ネットワーク越しいずれの場合でも)、テキストインストーラメニューからシェルを選択することができるようになります。SPARC マシン上のブートプロンプトで、次のコマンドを実行することでこれを実現します。
{0} ok boot net:dhcp
Oracle Solaris 11 でのシステムのブートに関する詳細は、 System Administration Guide: Basic Administration の x86 と SPARC のブートに関連する項目を参照してください。
ブートデバイスとルートプールの準備
最初に、新しいブートディスクデバイスを構成します。必要に応じて Oracle Solaris Administration: Devices and File Systems ガイド、System Administration Guide: Basic Administration の x86 と SPARCのブートに関連する項目で、ディスクデバイスの管理方法、ブートデバイスの決定方法、デフォルトブートデバイスの変更などについて参照してください。
前述したとおり、以下の手順を実行していて、ブートデータ用にディスクの最初の領域が確保されている限り、オリジナルのディスクレイアウトは複製が可能であり、別のものを使用することもできます。さらに、ルートプール (または他のリカバリターゲットプール) はオリジナルのサイズと同じである必要はありません。ただし、新しいプールには、それぞれのアーカイブファイル (zpool list で出力された ALLOC の項目と同等のサイズ) のすべてのデータを保持するだけの十分な大きさが必要です。
ブートデバイスが選択されると、アーカイブされたシステムの初期ディスク構成をもとに、要求されたとおりに構成されます。繰り返しになりますが、 zpool list で出力された ALLOC に表示されたサイズのデータを格納するだけの大きさの ZFS プールが最終的に必要です。
format(1M) は、ディスクのパーティションやスライスを構成するために使用するコマンドです。 ブートデバイスには VTOC ラベルが使用され、デフォルトの構成はシリンダ 1 のフルデバイススライス0 で開始します。アーカイブ作成の一部として保存されたファイルは、ブートデバイスの最適なセットアップ方法のガイドとなる内容を提供します。
開始するには、リスト 2 に示すように format ユーティリティメニューから目的のブートデバイスを選択します。
リスト 2: ブートデバイスの選択
# format
Searching for disks...done
c3t3d0: configured with capacity of 68.35GB
AVAILABLE DISK SELECTIONS:
0. c3t2d0 <SEAGATE-ST973401LSUN72G-0556 cyl 8921 alt 2 hd 255 sec 63>
/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@2,0
1. c3t3d0 <FUJITSU-MAY2073RCSUN72G-0401 cyl 14087 alt 2 hd 24 sec 424>
/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@3,0
Specify disk (enter its number): 1
selecting c3t3d0
[disk formatted]
x86 システム上の場合、選択されたディスクで、fdisk パーティションを作成する必要があるかもしれません。
format> fdisk No fdisk table exists. The default partition for the disk is: a 100% "SOLARIS System" partition Type "y" to accept the default partition, otherwise type "n" to edit the partition table. y format>
これを完了すると、必要に応じてスライスを構成することができます。リスト 3 にデフォルトの構成であるフル容量の (または「全体」) スライス 0 の設定例を示します。スライスはシリンダ 1 で開始し、ディスクの先頭からソフトウェアをブートします。パーティションテーブルは、システムアーキテクチャ、ディスクジオメトリ、そのほかの変数によって違いがある可能性があります。
リスト 3: フル容量スライスのセットアップ例
format> partition partition> print Current partition table (default): Total disk cylinders available: 8921 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 - 8920 68.34GB (8921/0/0) 143315865 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 9 unassigned wm 0 0 (0/0/0) 0 partition> 0 Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 Enter partition id tag[unassigned]: root Enter partition permission flags[wm]: Enter new starting cyl[1]: 1 Enter partition size[0b, 0c, 1e, 0.00mb, 0.00gb]: $ partition>
必要に応じてスライスが構成された後、リスト 4 に示すようにディスクのラベル付けを実行します。次の手順に進む前に、全体のレイアウトを確認してください。
リスト 4: ディスクのラベル付け
partition> label Ready to label disk, continue? y partition> print Current partition table (unnamed): Total disk cylinders available: 8921 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 1 - 8920 68.33GB (8920/0/0) 143299800 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 - 8920 68.34GB (8921/0/0) 143315865 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 9 unassigned wm 0 0 (0/0/0) 0 partition> ^D
ディスクデバイスの管理に関する詳細についてはOracle Solaris Administration: Devices and File Systems ガイドを参照してください。
ZFS プールの作成とアーカイブの復元
ディスクを構成すると、次のコマンドで新しいルートプールをスライス 0 上に作成することができます。
# zpool create rpool cXtXdXs0
アーカイブされたシステムのルートプールにデフォルト名 rpool を使用していない場合は、該当する名前を入力してください。異なるプール名でもリカバリプロシージャは正常に完了する可能性がありますが、ZFS ファイルシステムは異なるマウントポイントを取得することがあり、混乱の原因になります。このため、リカバリ用 ZFS プールはアーカイブ ZFS プールと同じ名前で作成するようにしてください。
アーカイブの復元に必要となるそのほかの ZFS プールはこのタイミングで作成することができます。システム上の既存のプールで、すでに希望する名前が使われている場合は、別の名前を指定してください。ZFS プールの作成に関する詳細については、Oracle Solaris Administration: ZFS File Systems ガイドを参照してください。
次の手順では、ZFS データセットをアーカイブファイルから復元します。アーカイブがリムーバブルメディアに保存されている場合、そのメディアを接続して構成し、ファイルにアクセスできるようにします。リムーバブルメディアの構成に関する詳細については、Oracle Solaris Administration: Devices and File Systems ガイドを参照してください。
ローカルでファイルへのアクセスが可能になれば、次のコマンドを使用してデータセットを復元することができます。
# gzcat /path/to/archive_myhost_20111011.zfs.gz | zfs receive -vF rpool
ファイルがネットワーク上のファイルサーバーに保存されている場合、次のコマンドを使用してアーカイブをストリームし、データセットを復元することができます。
# ssh USER@FILESERVER "cat /path/to/archive_myhost_20111011.zfs.gz" | gzip -d | zfs receive -vF rpool
このホスト上で別のプールが復元用にアーカイブされている場合、上記に示した ZFS オペレーションと同じ方法を使って、この段階で復元することができます。ZFS データセットに関する詳細については、 Oracle Solaris Administration: ZFS File Systems を参照してください。
データの復元手続きに関してはこれで完了です。復元されたシステムが期待どおりにブートするように、最後の手順を実行します。
フェーズ3: 構成と検証
まず、復元されたシステムで使用するスワップとダンプデバイスを作成する必要があります。デフォルト名デバイスがここでは使用されており、このシステムで実行するように構成されすでに使用中であるため、たとえばスワップデバイスを swap(1m) コマンドで追加するといったような追加の管理タスクは必要ありません。ターゲットシステムにアーカイブされたシステムによって異なるメモリ構成が存在する場合、スワップとダンプデバイスには異なるサイズが必要な場合がありますが、以前の構成で使用されていた名前はそのまま使用されます。このため、復元されたシステムの最初のブートで構成が適切に実行されます。
スワップとダンプデバイスの容量はOracle Solaris Administration: Devices and File Systems ガイド、Oracle Solaris Administration: ZFS File Systems ガイドに記述されている内容に従って作成してください。それぞれサイズの概略は以下のようになります。
| 物理メモリ | スワップサイズ | ダンプサイズ |
|---|---|---|
| 4 GB までの物理メモリを持つシステム | 1 GB | 2 GB |
| 4 GB から 8 GB の物理メモリを持つミッドレンジサーバー | 2 GB | 4 GB |
| 16 GB から 32 GB の物理メモリを持つハイエンドサーバー | 4 GB | 8 GB+ |
| 32 GB 以上の物理メモリを持つシステム | 合計メモリサイズの1/4 | 合計メモリサイズの 1/2 |
システムをブートした後でも、必要であればスワップデバイスは追加することができます。これらのデバイスの管理に関する詳細情報については、関連のドキュメントを参照してください。
スワップとダンプデバイスを適切なサイズで作成するには、次のコマンドを実行します。この例ではリカバリシステムに 8 GB のメモリがインストールされていいます。
# zfs create -b $(pagesize) -V 2GB rpool/swap # zfs set primarycache=metadata rpool/swap # zfs create -b 128k -V 4GB rpool/dump
次に、目的の BE を beadm(1M) コマンドを使用して構成します。beadm list コマンドを実行すると、使用可能な BE の一覧を表示することができます。
# beadm list BE Active Mountpoint Space Policy Created -- ------ ---------- ----- ------ ------- solaris-2 - - 2.02G static 2011-09-23 10:00 solaris - - 16.56M static 2011-09-22 21:51
目的の BE のルートファイルシステムで作業するには、そのファイルシステムがマウントされている必要があります。マウントするには、beadm mount を実行します。次の例では solaris-2 BE にマウントしています。
# beadm mount solaris-2 /tmp/mnt
これで、/tmp/mnt マウントポイントから BE のルートファイルシステムにアクセス可能になりました。最初に、ホストが新しいルートプールをブートできるようにするために、ブートソフトウェアをインストールします。以下に示すように、アーキテクチャによって手順は異なります。これらの例は、いずれも前述のように /tmp/mnt BE マウントポイントを使用しています。
x86 版のホストの場合:
# installgrub /tmp/mnt/boot/grub/stage1 /tmp/mnt/boot/grub/stage2 /dev/rdsk/cXtXdXs0
SPARC 版のホストの場合:
# installboot -F zfs /tmp/mnt/usr/platform/`uname -i`/lib/fs/zfs/bootblk /dev/rdsk/cXtXdXs2
新しいシステム上では、同じデバイスが使用されないようにするか、異なる方法で構成するようにできます。このため、デバイスファイルシステムを次のコマンドを使用してクリアします。
# devfsadm -Cn -r /tmp/mnt
これで、最初のブートで再構成されたブートをシステムで実行することができます。いずれの新しいデバイスハードウェア (アーカイブシステム対リカバリシステムに関連した) も構成します。再構成ブートは BE のルートファイルシステムの上位レベルにある reconfigure というファイルを配置することで強制的に実行します。ファイルが削除され、結果としてファイルが配置された後の最初のブートでのみ再構成が行われるため、この機能は継続しません。
再構成ブートを設定するには、アクティブな BE がマウントされているファイルシステムにこのファイルを作成します。ファイルシステムはその後 beadm unmount コマンドでアンマウントされます。
# touch /tmp/mnt/reconfigure # beadm unmount solaris-2
最後に目的の BE を beadm activate コマンドを使用してアクティブにします。
# beadm activate solaris-2
アクティブにすると、beadm list 出力の Active 列 には R が表示され、再起動後アクティブになることを示します。これは、 beadm list が 2 度目に実行されたときに確認することができます。BE 管理に関する詳細については、Creating and Administering Oracle Solaris Boot Environments を参照してください。
これでシステムを再起動する準備ができました。システムは、アーカイブされたシステムと同様に、物理トポロジ、周辺装置デバイス、あるいはハードウェアに関連したそのほかの変更を除外する必要があります。前述のように、ソフトウェア構成とデータは、回復したセカンダリ ZFS プールとともにアーカイブされたシステムから引用しなくてはなりません。ネットワーク構成を検討、検証する必要があります。システムが新しいネットワーク上に復元されている場合、あるいはネットワーク関連の構成要素がアーカイブ作成後に変更されている場合は、修正が必要になることがあります。構成に関する詳細については、Oracle Solaris の管理ガイドを参照してください。
結論
この記事では、インストールされ構成された Oracle Solaris 11 ホストのアーカイブ作成と復元をするためのいくつかの手続きについて見てきました。これらの手続きは全体的な障害回復計画の一部としても利用することが可能であり、また、別のブートデバイスでも、同じモデルのまったく異なるシステムでも、Oracle Solaris 11 システムでホストされているビジネスサービスの移行のために使用することができます。
詳細情報
追加のリソースについて以下に示します。
- Oracle Solaris 11 のダウンロード
- Oracle Solaris 11 製品のドキュメントへのアクセス
- Oracle Solaris 11 how-to guides にアクセス
- Oracle Solaris 11 training and support でトレーニングとサポートについて確認する
| Revision 1.0, 11/04/2011 |
Printer View