DATテープの複製を作りたい

質問

初めて質問させていただきます。情報不足など、失礼がありましたらご指摘ください。

Solaris9 で構築されたサーバのバックアップを「ufsdump」コマンドでDATテープへ採取しました。DATドライブはSCSI接続で、サーバに一基、搭載されています。
そのDATテープを、災害対策として別の場所へ保管するため、もう1つ作成する必要が出てきました。

再度バックアップを取るのことは出来ますが、サーバの台数が50台以上あり、時間と労力が惜しまれます。

手軽にDATテープの複製を作る方法はないものでしょうか。

回答No.8

wiz_sapo

同一マシン上でしか試したことはありませんが、tcopy はどうでしょうか？
> tcopy [Source] [Destination]

Sourceはコピー元のテープの入ったテープドライブのデバイス名
Destinationはコピー先のテープの入ったテープドライブのデバイス名

ネットワーク越しにコピーできるかは試したことが無いので分かりません。
man を見るとioctl(2)が使えれば使えると書いているので、無理そうですが…。

回答No.7

a-saitoh

コピー先ドライブのあるマシンで、dumpをDATに対して行った場合に、DATの内容をrestoreで読むことはできますか?

おそらく、お使いのrestoreが、明示的にブロックサイズを指定しないとうまく動かないのではないかと思います。

あと、dumpコマンドを実行した際に、書き出しているブロックサイズが標準エラーに出ていると思いますが。。。

回答No.6

a-saitoh

書き込まれたレコード数 0+370129
を出しているのが、読み込み側のddなのか、書き出し側のddなのかが気になります。

%　rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=126b >file
% dd if=file of=/dev/rmt/0 bs=126b
と、いったんファイルを経由するとどうなりますか?
また、
restore tf file
として、このファイルをrestoreは扱うことができるでしょうか?

補足

お気遣いに感謝いたします。

読むのが遅くなってしまい、結果としては妥協するような形の方法で
DATテープを複製することとしました。これについては後述しますが、
まずはご質問に答えさせていただきます。

＞%　rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=126b >file
＞% dd if=file of=/dev/rmt/0 bs=126b
＞と、いったんファイルを経由するとどうなりますか?

ファイルへの書き込みでは部分ブロックは発生しませんでした。
% rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=126b > /tmp/hoge
書き込まれたレコード数 5265+0
読み出されたレコード数 5265+0
%

テープへの書き込みで部分ブロックが発生しました。
% dd if=/tmp/hoge of=/dev/rmt/0 bs=126b
書き込まれたレコード数 5265+1
読み出されたレコード数 5265+1

テープを読み込むと「Volume is not in dump format」エラーとなりました。
% ufsrestore ivf /dev/rmt/0n
Verify volume and initialize maps
Media block size is 126
Volume is not in dump format
%

＞また、
＞restore tf file
＞として、このファイルをrestoreは扱うことができるでしょうか?

こちらは部分ブロックが無かったので読み込めるかと思いましたが、やはりテープ
同様、「Volume is not in dump format」エラーとなりました。
% ufsrestore ivf /tmp/hoge
Verify volume and initialize maps
Media block size is 126
Volume is not in dump format
%

検証では、ネットワーク越しのddで必ずエラーとなりました。以下はテストの結果です。
-------------------------------------------------
クライアント　DATがあるマシン
disk | tape　　disk | tape
□□□□・----------->・×（部分ブロック）
□□□□・----->・×（部分ブロック）
・------------------->・×（部分ブロック）
・------------->・×（部分ブロック）
□□□□□□□□ ・--->・○
□□□□□□□□ ・<---・○
-------------------------------------------------

「DATテープ－DATテープ」ではなくなってしまいますが、暫定的に以下の方法
で対応することにしました。ftpを使っています。
※マシンＡに原本のＤＡＴテープ、マシンＢに空のＤＡＴテープを入れています。
-------------------------------------------------
　マシンＡ マシンＢ
disk | tape　　disk | tape
・<-----・dd
・------------->・ftp
□□□□□□□□□・-->・dd
-------------------------------------------------

これをシェルで実行することとしました。シェルの内容は以下の通りです。
-------------------------------------------------
#!/bin/sh
#
#tapecopy.sh
#
#07/01/17
rsh DATがあるマシン mt -f /dev/rmt/0 rewind
rsh DATがあるマシン dd if=/dev/rmt/0n bs=126b of=/tmp/hoge …(1)
ftp -n < ftpget.txt
rsh DATがあるマシン rm /tmp/hoge
mt -f /dev/rmt/0 erase …（※）
mt -f /dev/rmt/0 rewind …（※）
dd if=/tmp/hoge bs=126b of=/dev/rmt/0n …(1)
rm /tmp/hoge
（以下、省略）
-------------------------------------------------
（※）は2回目以降実行しない

時間のかかるやり方ですが、このシェルを実行することでDATテープの複製
が出来、「ufsrestore」コマンドで中身に間違いが無いことを確認できました。
また、(1)のところで「0n」としたのは、データが５つに分かれているためです。

時期が迫ってきたので、これで暫定対応いたしますが、速度を上げる方法について
さらに検証を進めます。

丁寧なアドバイスに重ねて感謝を申し上げます。

回答No.5

a-saitoh

ドライブにバックアップデータが入ったテープを入れ、
dd if=/dev/テープデバイス bs=512 count=1 > /tmp/hoge
ls -l /tmp/hoge
で、先頭1ブロックだけ読み出してみることで、テープブロックサイズは知ることができます。
なお、512という数値は個々のOSやテープ装置で変える必要があります。
実際のテープブロックサイズより小さいとエラーになります。OSが許すサイズより大きすぎてもエラーになります。

お礼

お世話になっております。

昨夜から切り分けを進めていった結果をお伝えします。
まず、私の誤解がありました。ブロックサイズは「512byte」ですが、総ブロック数は126であるため、
bsの指定はANo.4で回答いただいた126bでした。失礼いたしました。

ご回答のコマンドで試験したところ、以下のような実行結果となりました。
% rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=126b | dd bs=126b of=/dev/rmt/0
書き込まれたレコード数 5265+0
読み出されたレコード数 5265+0
書き込まれたレコード数 0+370129 （…(1)）
読み出されたレコード数 5265+1
%

この複製テープを読み込もうとしたところ、「Volume is not in dump format」エラーとなりました。
% ufsrestore ivf /dev/rmt/0n
Verify volume and initialize maps
Media block size is 126
Volume is not in dump format

(1)の書き込みが部分ブロックのみになっています。リモートからの読み込み速度に対して、
テープへの書き込み速度が間に合っていないのではないかと推測し、読み込み速度を遅くして
試験しました。
（ibs=1k）
% rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=126b | dd ibs=1k obs=126b of=/dev/rmt/0
書き込まれたレコード数 5265+0
読み出されたレコード数 5265+0
書き込まれたレコード数 241595+194995 （…(2)）
読み出されたレコード数 5265+1

(2)のように完全ブロックは増えましたが、やはり部分ブロックがあります。さらにibsを減らして
いくと完全ブロックが増え、部分ブロックは減っていきます。実行結果を抜粋すると、
（ibs=128）
書き込まれたレコード数 2589267+107180
（ibs=64）
書き込まれたレコード数 5265998+64025
…
…
（ibs=2）
書き込まれたレコード数 169827953+2

完全ブロックは増えていますが、出力ブロックにNULL（？）が入っているのか、次第にレコード数が
増えていきます。また、記載していないレコード数は全て同じ結果です。

おそらくここからはチューニングになるのかと思われます。

a-saitoh様、親切にアドバイスを頂き有難うございました。大いに参考にさせて頂きました。
DATテープ複製が成功した時には、結果を記録として記載いたします。

では、長々と失礼いたしました。

補足

お世話になっております。
ご回答いただいた方法でブロックサイズが「512byte」と確認できました。有難うございました。
（コマンド結果）
# dd if =/dev/rmt bs=512 count=1 > /tmp/size
書き込まれたレコード数 1+0
読み出されたレコード数 1+0
# cd /tmp
# ls -tl size
-rw-r--r-- 1 root other 512 1月 14日 22:59 size

そこで、ddコマンドを実行したところ、以下のようなエラーとなりました。
%rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=512 | dd of=/dev/rmt/0 bs=512
read: 十分な領域がありません。
書き込まれたレコード数 0+0
読み出されたレコード数 0+0
書き込まれたレコード数 0+3
読み出されたレコード数 0+3

※bs=512はデフォルト値なので、省略したものも試しましたが、結果は同じでした。

問題を切り分けるため、bsの値を変えてみたところ、「bs=512k」のように大きなブロック
サイズ指定するとコマンドは正常終了します。
%rsh DATがあるマシン -n dd if=/dev/rmt/0 bs=512k | dd of=/dev/rmt/0 bs=512k
書き込まれたレコード数 0+5265
読み出されたレコード数 0+5265
書き込まれたレコード数 0+33898
読み出されたレコード数 0+33898

ただし、これはブロックサイズが異なるため、読み込みの際、前回と同様のエラーになります。
# ufsrestore ivf /dev/rmt/0n
Verify volume and initialize maps
Record size (66) is not a multiple of dump block size (1024)

またもや途中報告で申し訳ありません。さらに切り分けを進め、（また途中となるかも
しれませんが）明日結果を報告いたします。
ご親切にアドバイスを頂きながら、力不足で申し訳ありません。

回答No.4

a-saitoh

最近のUNIXの便利な機能は知りませんが、、

rsh DATがあるマシン　-n dd if=/dev/rmt/デバイス名　 bs=126b |dd bs=126b of=/dev/rmt/デバイス名
てなかんじで、かなり速度は遅くなりますが、コピーはできるはずです。

ddじゃなくてバッファつきのソフトを使えば多少早くなります。

お礼

ご回答ありがとうございます。
コマンドラインまで記載頂き、恐縮いたします。

これまで、ftp・dd・scpなどを試してきましたが、いずれも認証でエラーとなり頓挫しておりました。それは、サーバを提供しているベンダーとの契約上、環境設定を変更できないという事情のためです。
これもまた、初めに伝えるべきことでした。申し訳ありません。

しかしながら皆様にご助言頂きましたし、目的を達成したい気持ちがあります。こっそりと環境を変更して、ご回答の方法を試してみます。

変則的な勤務をしており、勝手ながら試験は明後日となりますが、結果は報告いたします。

補足

お世話になっております。

a-saitoh様からご回答頂いた内容を試験いたしましたので、報告いたします。
1)サーバの環境（/etc/hosts.equiv）を一時的に変更
2)ご記載いただいたコマンドを実行
結果：
無事にDATテープの内容がリモートサーバへ転送されました。ただし、複製されたテープの内容を確認しようとしたところ、以下のメッセージで参照することが出来ませんでした。
#ufsrestore ivf /dev/rmt/0n
Verify volume and initialize maps
Record size(66) is not a multiple of dump block size(1024)

記録されたサイズ（66Byte）は、ダンプブロックサイズ（1024Byte）の倍数とは異なります、と読めます。ブロックサイズの指定に誤りがあるようでした。
ANo.2に対するお礼のところで「ブロックサイズは確認できている」と申しておりましたが、その時は「mt -f /dev/rmt/0 status」での確認が出来なかったため「ufsrestore」で確認しました。このあたりが不確実だったのだろうと思われます。申し訳ありません。
明日に、ブロックサイズの確認方法を確かめた上で、再度試験してみます。
長文で失礼しました。また、結果を報告させていただきます。

回答No.3

JAWS55

リモートで他のサーバのDATにddでコピーできませんか？
昔、HP-UXではできたような記憶があります…（曖昧ですみません）

お礼

ご回答ありがとうございます。
リモートで他のサーバのDATにddでコピーする方法、試してみます。

また結果を報告いたしますので、皆さまのアドバイスを頂けたら幸いです。

回答No.2

a-saitoh

DATドライブが2台あれば、ddでコピーできます。
1台しかないのなら、いったんテープをHDDにコピーしてから、それを新しいDATに書き込むということになりますが。空き領域が十分にあるディスクはありますか?

ただし、最初のバックアップテープを作ったときのテープブロックサイズがわかってないといけません。

お礼

ご回答ありがとうございます。
ＨＤＤにコピーする場合ですが、空き容量は十分にあります。バックアップテープのブロックサイズは「ufsrestore」コマンドの結果で確認しています。具体的には以下のとおりです。
#ufsrestore ivf /dev/rmt/0n
Verify volume and initialize maps
Media block size is 126
…

DATドライブは各サーバに一基ありますので、同一セグメント内には2台以上あります。まずは、ネットワーク越しにddでコピーできるか検証してみます。

回答No.1

noname#39970

多分・・・DATデッキでダビング・・・・・できるような・・・(デジタルデータだし)

お礼

ご回答ありがとうございます。
DATデッキでダビング、確かにその方法が手軽だと思います。
ただ、切ない話ですが、お金の発生する方法は回避したいのです。
経済的に潤っていない会社であることを始めに述べておくべきでした。
申し訳ありません。