こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

ufsdump と ufsrestore に関する質問

Solaris初心者ですが、仕事で以下の課題をクリアしなくてはなりません。

課題)
Solaris サーバ(ディスクはHD一台のみの構成)で、
主にHDの物理的破損に備えたバックアップ&リストアの手順を確立すること
※都合上、HD内にバックアップファイルを一旦作成し、後でテープ装置へ送ります

現在のSolarisでdf -h すると、
ファイルシステム     サイズ 使用済 使用可 容量 マウント先
/dev/dsk/c1t0d0s0    5.5G  4.1G  1.3G  77%  /
/devices          0k   0k   0k  0%  /devices
ctfs             0k   0k   0k  0%  /system/contract
proc            0k   0k   0k  0%  /proc
objfs             0k   0k   0k  0%  /system/object
sharefs           0k   0k   0k  0%  /etc/dfs/sharetab
swap            7G  922k  1.7G  1%  /etc/svc/volatile
/usr/lib/libc/libc_hwcap2.so.1 5.5G  4.1G  1.3G  77%  /lib/libc.so.1
fd             0k   0k   0k   0%  /dev/fd
swap           1.7G   44K  1.7G   1%  /tmp
swap           1.7G   24K  1.7G   1%  /var/run
/dev/dsk/c1t0d0s7   61G  4.3G   56G   8%  /export/home
と、なります。

この状態で、Solaris丸ごと完全バックアップ&リストアをおこなう場合、
ufsdump対象となるファイルシステムは、/ と /export/home のみで、
他のファイルシステムのufsdumpは必要ないのですか? --- (1)
(/usr/lib/libc/libc_hwcap2.so.1は、何に使うのでしょうか?)

またリストアする場合、
1.CDでブート
2.リストア前と同じになるようにHDのフォーマット、パーティショニングを手動でおこない
3.dumpしたファイルシステムについて ufsrestore で復元する

この方法でよいのでしょうか? --- (2)
マスターブート部位などはdumpしていないようにも思えますが、大丈夫でしょうか --- (3)
この方法だと手作業も多く、誤操作が発生しやすいかと思います。
コマンド一回で丸ごとバックアップして、丸ごとリストアするような方法は、ないのですか? --- (4)

勘違いしているかもしれませんが、アドバイスが頂けたら、幸いです。

投稿日時 - 2009-06-23 17:31:41

QNo.5068553

困ってます

質問者が選んだベストアンサー

仕事なら、正しく書いてある本を買う、docs.sun.com を読む、保守業者に
問い合わせする、などして準備しましょう。

他のファイルシステムのufsdumpは必要ないのですか? --- (1)
(/usr/lib/libc/libc_hwcap2.so.1は、何に使うのでしょうか?)

ここは僕にもよくわかりませんが、/lib/libc.so.1 をマウントしている
ようですので、/ と /export/home のみでバックアップはとれていると
思います。
vfstabあたりに、/usr/lib/libc/libc_hwcap2.so.1 の記述があるのでは
ないでしょうか。

この方法でよいのでしょうか? --- (2)

こんな感じになると思います。

1.CDでブート
2.リストア前と同じになるようにHDのフォーマット、パーティショニングを手動でおこない
2.1 ファイルシステムをマウント 
3.dumpしたファイルシステムについて ufsrestore で復元する
3.1 restoresymtable を削除
3.2 ファイルシステムをアンマウント
3.3 fsck -m で整合性チェック
4 ブートブロックの作成
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t0d0s0
5 作成したファイルシステムをバックアップ
6 リブート

マスターブート部位などはdumpしていないようにも思えますが、大丈夫でしょうか --- (3)

必要です。手順は上に示しました。

コマンド一回で丸ごとバックアップして、丸ごとリストアするような方法は、ないのですか? --- (4)

いくつか手段はあると思いますが、お勧めはミラーすることです。
ミラーしたディスクを切り離して取っておくと、戻すのも簡単です。
シェルは・・・間違ったとき目も当てられないのでお勧めしません。

投稿日時 - 2009-06-23 20:17:48

お礼

回答、ありがとうございます。
大変たすかります。

>仕事なら、正しく書いてある本を買う、docs.sun.comを読む、
>保守業者に問い合わせする、などして準備しましょう。
まったくその通りです。
ただ手持ちの本や見つけたネットの情報では、
「ファイルシステムの完全なバックアップ&リストア」ばかりで、
「Solaris丸ごと・・・」は、なかなか見つからなかったのです。
確かに保守業者に問い合わせるべきですね。
それは掛け合ってみます。


> 4 ブートブロックの作成
> # installboot /usr/platform/`uname -
> i`/lib/fs/ufs/bootblk /dev/rdsk/c1t0d0s0
なるほど、やはりこういった処理が必要でしたか。
パラメータ等は、後でよく調べます。

> いくつか手段はあると思いますが、
> お勧めはミラーすることです。
確かにそうですね。
ミラーすれば、OS完全バックアップ用のufsdump/restoreは不要に思えてきます。

今回は貴重なアドバイスをして頂き、感謝します。
それでは失礼します。

投稿日時 - 2009-06-24 00:49:15

このQ&Aは役に立ちましたか?

3人が「このQ&Aが役に立った」と投票しています

回答(4)

ANo.4

少々補足させてください。

> formatコマンドでもパーティション構成を確認できますが・・・

パーテションの情報は、以下のコマンドで保存することができます。
全く同一のHDD(同じベンダの同じディスク)の場合、保存したパーテション情報
をコマンドで戻すことができます。
同一の状態で非常に多くのHDDをフォーマットする場合は、この手段で
短時間にこなすことができます。
昔は Ultra Enterprise 450 みたいなのもありましたので・・・

 パーテション情報を保存する(以下の例では /var/tmp/vtoc というファイルができる)
 prtvtoc /dev/rdsk/c1t0d0s0 > /var/tmp/vtoc

 パーテション情報を戻す(以下の例ではターゲットが異なるディスクに戻している)
 fmthard -s /var/tmp/vtoc /dev/rdsk/c1t1d0s0

> /tmpを含む全てのファイル対象となります。

昔のSUNOSの時代などは /tmp を取る必要がありましたが、
Solarisの場合、「通常は」 /tmp は tmpfs にマウントされるので
リブートすると消えますので、バックアップは取らないことが多いです。
何らかの理由で ufs にマウントしている場合はバックアップが必要です。
今回のケースでは、普通に tmpfs にマウントされているので /tmp
は必要ありません。

> RAIDは、ハードRAIDとソフトRAIDがあって、

Sparcマシンで内蔵ディスクを使う場合は、一般的にはOSの機能で
ソフトRAIDすることが多いでしょう。
Solaris10以降であれば、ZFSでRAIDを管理するのがとても便利です。
ハードウェアRAIDの方が多くの面で優れていますが、導入はお財布との
相談だと思います。

投稿日時 - 2009-06-25 01:20:12

お礼

補足情報、ありがとうございます。
手元の文献やネットでは見つけられなかった情報が多く、助かります。

> パーテションの情報は、以下のコマンドで保存することができます。
> 全く同一のHDD(同じベンダの同じディスク)の場合、保存したパーテション情報
> をコマンドで戻すことができます。
 // 中略
> パーテション情報を保存する(以下の例では /var/tmp/vtoc というファイルができる)
> prtvtoc /dev/rdsk/c1t0d0s0 > /var/tmp/vtoc
> パーテション情報を戻す(以下の例ではターゲットが異なるディスクに戻している)
> fmthard -s /var/tmp/vtoc /dev/rdsk/c1t1d0s0

パーテション情報の保存・復元方法ですね。
直接は関係ないですが、憶えておくべき方法ですね。


>> /tmpを含む全てのファイル対象となります。
> 昔のSUNOSの時代などは /tmp を取る必要がありましたが、
> Solarisの場合、「通常は」 /tmp は tmpfs にマウントされるので
> リブートすると消えますので、バックアップは取らないことが多いです。
> 何らかの理由で ufs にマウントしている場合はバックアップが必要です。
> 今回のケースでは、普通に tmpfs にマウントされているので /tmp
> は必要ありません。

Solarisは、/tmpのバックアップは不要ですか。
/tmpなので、基本的に不要とは思っていますが、
リストア実行上必要かも知れないと思っていました。


> Solaris10以降であれば、ZFSでRAIDを管理するのがとても便利です。
> ハードウェアRAIDの方が多くの面で優れていますが、導入はお財布との
> 相談だと思います。

今回は、ハードウェアRAID構成になることのこと(別担当者)です。
したがってバックアップ(ufsdump/restore)に関して、専念します。

さまざまな関連情報を教えて頂き、ありがとうございます。
私の周りにSolarisのdump/restoreに詳しい者がいないので、
こうした情報は本当に有り難いです。
それでは、失礼します。

投稿日時 - 2009-06-25 11:21:48

ANo.3

>> お勧めはミラーすることです。
>確かにそうですね。
>ミラーすれば、OS完全バックアップ用のufsdump/restoreは不要に思えてきます。
RAIDは注意が必要ですよ!!

RAIDは、ハードRAIDとソフトRAIDがあって、それぞれ一長一短があるのですが・・・ソフトRAIDの状態でバックアップを作成すると、作成されたバックアップは「ソフトRAID」の状態でバックアップされるので、ソフトRAIDされていない状態でリストアすることが難しいです。

RAID構成はバックアップを考慮して決定しないと・・・リストアしたけどブートに失敗するバックアップが取得されていたという困ったことにならないように注意する必要があります。


>ミラーすれば、OS完全バックアップ用のufsdump/restoreは不要に思えてきます。
バックアップとRAIDは相互に補完し合うもので、どちらか一方で完全というものではないです。

まぁ~2、3重のRAID5とか、3重ミラー(RAID1)などバックアップが活躍する機会が少ないシステムもありますが・・・操作ミスで削除したデータは、どんなRAIDでも復旧できないのでバックアップが必要です。

投稿日時 - 2009-06-25 00:31:45

お礼

追加情報ありがとうございます。

>>> お勧めはミラーすることです。
>> 確かにそうですね。
>> ミラーすれば、OS完全バックアップ用のufsdump/restoreは不要に思えてきます。
> RAIDは注意が必要ですよ!!
> RAIDは、ハードRAIDとソフトRAIDがあって、それぞれ一長一短があるのですが・・・
> ソフトRAIDの状態でバックアップを作成すると、作成されたバックアップは「ソフトRAID」の状態でバックアップされるので、
> ソフトRAIDされていない状態でリストアすることが難しいです。

RAIDで単純にリストアできない場合もあるのですね。


> RAID構成はバックアップを考慮して決定しないと・・・リストアしたけど
> ブートに失敗するバックアップが取得されていたという困ったことにならないように注意する必要があります。

なるほど、そうした考慮も必要ですね。
この場合もRAIDでリストア!とはいかないのですね。


>> ミラーすれば、OS完全バックアップ用のufsdump/restoreは不要に思えてきます。
> バックアップとRAIDは相互に補完し合うもので、どちらか一方で完全というものではないです。
> まぁ~2、3重のRAID5とか、3重ミラー(RAID1)などバックアップが活躍する機会が少ないシステムもありますが・・・
> 操作ミスで削除したデータは、どんなRAIDでも復旧できないのでバックアップが必要です。

「バックアップとRAIDは相互に補完」
この言葉は、そのまま覚えます。
バックアップとRAIDに関するアドバイス、参考になりました。
まだまだ苦労しそうですが、お蔭様で少しずつ前進できています。

投稿日時 - 2009-06-25 10:46:29

ANo.2

ufsdumpで重要なのは・・・パーティション構成です!!

> 現在のSolarisでdf -h すると
/etc/vfstabに記述されているパーティション構成を確認しましょう
formatコマンドでもパーティション構成を確認できますが・・・間違えるとディスクを消してしまう可能性があるので注意が必要です


>/usr/lib/libc/libc_hwcap2.so.1は
どのようなソフトが使われているか不明ですが・・・不慮の事故に対するバックアップは原則、/tmpを含む全てのファイル対象となります。


>またリストアする場合、
>1.CDでブート
>2.リストア前と同じになるようにHDのフォーマット、パーティショニングを手動でおこない
>3.dumpしたファイルシステムについて ufsrestore で復元する
正しい手順です。


>マスターブート部位などはdumpしていないようにも思えますが、大丈夫でしょうか --- (3)
ブート・ディスクをdumpでバックアップを作成すると同時にバックアップされます


>コマンド一回で丸ごとバックアップして、丸ごとリストアするような方法は、ないのですか?
1個のパーティションなら1回のdump/restoreでバックアップ&リストアすることが可能です。

投稿日時 - 2009-06-25 00:19:44

お礼

回答、ありがとうございます。
いろいろなアドバイスが聞けて、本当に助かります。

> ufsdumpで重要なのは・・・パーティション構成です!!
> /etc/vfstabに記述されているパーティション構成を確認しましょう

vfstab、確認しました。
ここにコピーを貼ろうと思ったのですが、全部だと文字数オーバーになってしまうので、割愛します。

> 不慮の事故に対するバックアップは原則、/tmpを含む全てのファイル対象となります。

/tmpは不要と思っていましたが、必要なのですね。


>> 1.CDでブート
>> 2.リストア前と同じになるようにHDのフォーマット、パーティショニングを手動でおこない
>> 3.dumpしたファイルシステムについて ufsrestore で復元する
> 正しい手順です。

ここまでは、大丈夫ですね。


>> マスターブート部位などはdumpしていないようにも思えますが、大丈夫でしょうか --- (3)
> ブート・ディスクをdumpでバックアップを作成すると同時にバックアップされます

>> コマンド一回で丸ごとバックアップして、丸ごとリストアするような方法は、ないのですか?
> 1個のパーティションなら1回のdump/restoreでバックアップ&リストアすることが可能です。

1個のパーティションのみの構成であれば、dump/restore 作業は、かなり簡略化できそうですね。
この場合、ブートブロックの作成 installboot は、不要のようですね。

ありがとうございました。

投稿日時 - 2009-06-25 10:43:04

あなたにオススメの質問