☆バックアップ☆

このエントリーをはてなブックマークに追加
1 ：ミレニアムハッカー：
おいちんはcpioマンセーなんだがどうよ？

#!/bin/sh
for DIR in `cat dir_list`
do
FILENAME = `echo FILENAME | sed -e 's/\//_/g'`
find $DIR -print | cpio -ov > /mnt/bksrv/$FILENAME.`date +%Y%m%d`.cpio
done
2 ：名無しさん＠お腹いっぱい。：02/04/20 02:43
良い子は素直にtar使おう
3 ：moge：02/04/20 02:51
tar -cf - /home | ssh $host "gzip -c > /bak/home.tgz"

4 ：aki：02/04/20 04:12
pdumpfs使ってる人いる？
http://www.namazu.org/~satoru/pdumpfs/
5 ：名無しさん＠お腹いっぱい。：02/04/20 14:02
>3
それでは何もできません（ﾜﾗ

>1
２番目のFILENAMEはDIRですね
6 ：名無しさん＠お腹いっぱい。：02/04/20 17:44
１月に１回、tar cpvf /dev/rst5 ./home* ってやってたなぁ（４年も前）。
4mmDATテープで。他の人はどんなメディアでバックアップとってます？
7 ：名無しさん＠お腹いっぱい。：02/04/20 19:03
＞６
tarってファイルの一部が壊れると戻らないから危険じゃないですか？
8 ：名無しさん＠お腹いっぱい。：02/04/20 20:52
んなもん、RAID から RAID にコピーで完了！
9 ：名無しさん＠お腹いっぱい。：02/04/20 23:28
>>8
それだと１世代バックアップじゃない？
あ...RAIDを複数台用意してるのか
10 ：名無しさん＠お腹いっぱい。：02/04/21 00:38
>>9
いや、ホットスワップだったら、タマを引っこ抜いてどっかに保存かも
知れんぞ。
11 ：名無しさん＠お腹いっぱい。：02/04/26 20:26
仕方なくWinをクライアントに使ってる方。
バックアップどうしてます？
OS付属のは、ファイルにだと圧縮出来なくていやなんですが。
Archive bitを読んでくれるコマンドライン.EXEってないっすか？
12 ：名無しさん＠お腹いっぱい。：02/04/26 22:12
solaris IAで、システムバックアップして、リストア後に
installbootがうまくいかないらしく、ディスクからブートできなくて
まいったです。
みなさん、システムのバックアップとかどうしてます？
13 ：名無しさん＠お腹いっぱい。：02/04/26 23:32
>>11
自宅だとこんな感じ。
MSバックアップでレジストリバックアップ込みでSambaのディスクへ。
Sambaのデータディスクは、ミラー。
Sambaマシンは重要なとこだけ（というかDDS2に入るだけ）DATへtar。

んで、バックアップサボってて、明日こそバックアップしようと思うと今日必ず消えるね。
何故だ。
14 ：名無しさん＠お腹いっぱい。：02/05/04 17:05
>>12
ufsdump & ufsrestore して　installboot しておくか，まったく同一のディスクなら dd するときもある．
15 ：名無しさん＠お腹いっぱい。：02/05/06 01:26
>11
俺の場合、仕方なく使ってるというのがぴったりなだけに、
ドキュメントぐらいしかバックアップ対象が無い。
だから、別のPC(UNIX)にSAMBAでコピって終わり。

この辺の仕組みって、Winに頼ると自由度がなさげ（Win側の詳細を
知らないという方が大きい）なのでUNIX側についつい頼ってしまう。

--------------------
でも、某HP-UXなんかはイニシエからのツールであるtarやcpio
なんかにファイルサイズ制限2Gの壁を残したまんまにしてるもん
だから、最近めっちゃ苦戦した。

Sun、AIXな方はいかがお過ごしでしょうか。
＃HP-UXだけなんかな、2G制限そのまま残してるって。
16 ：名無しさん＠お腹いっぱい。：02/05/06 23:54
>>15
afioって、使ってますか？
業務で使うの怖いんで、Sunの場合、シェルスクリプトでtarでテープデバイス指定して、
backupしてますが。
17 ：名無しさん＠お腹いっぱい。：02/05/07 00:05
>>15 HP の HDD は、1 or 2GB しかないのです。
18 ：15：02/05/08 12:15
>16
申し訳ない、メーカモノのユーティリティ以外は使えないっす。
・・・でもafioって知らなかった、Linuxじゃあ結構利用されてるみたいですね。

>17
HDDじゃないけど、HP-UXの一部のLVにそのテの制限があったと思います。
swapがそうですね、確か。
って、そういう意味じゃないんでしょうか？

ちなみに、HP-UXの別のユーティリティで2G制限は回避しておりますが、
なんせあまり巷に無い使い方だったのでしんどかったです。
19 ：名無しさん＠お腹いっぱい。：02/05/09 21:04
>>18
afioのwin版ﾎｽｨ
20 ：名無しさん＠お腹いっぱい。：02/05/09 21:54
afio は inode に依存しまくった構造だから Windows 版っていうのは
あっても嬉しくないんじゃないかなあ。
21 ：名無しさん＠お腹いっぱい。：02/05/10 00:19
バックアップはStoragetekのL170にLTO 170本とドライブ8つ突っ込んで、
Veritas NetBackupで1日おきにとってます。
22 ：15=18：02/05/10 00:28
>19
いや、俺に言われても・・・（笑）。
つうか、NTBackupだっけ、標準でついてる奴。これじゃだめ？
（Win環境よく知らないんだわ）
もしくはバックアップと冗長構成とを勘違いしたフリして、DISK
ミラーでお茶を濁すとか。

ところで、個人的にSUNやIBMなんかの売り物UNIXは、2G制限を
突破したtarやcpioを提供してるかどうか興味あるんで、管理者の
方情報キボンヌ。
23 ：名無しさん＠お腹いっぱい。：02/05/10 20:44
>>22
別にntbackup.exeでいいんですけどねぇ(笑)。
なんか意地でもzipとかにしたくて。
zipは-t オプションもあるんですが、archive bitまでは管理できないみたいで。
ふぅ。
24 ：名無しさん＠お腹いっぱい：02/05/11 04:46
Sun の ufsdump なら 2GB の壁は Solaris2.x の頃には
とっくに突破してたような。
Linux の dump は IDE-HDD だとファイル単位でバックアップ
できるのに SCSI-HDD だとパーティション丸ごとでも
バックアップがとれないバグが割と最近（つっても２年位前？）
あったりして、俺的信頼度がた落ち。でも使ってるけど。
25 ：名無しさん＠お腹いっぱい。：02/05/11 05:29
rsyncマンセー
26 ：名無しさん＠お腹いっぱい。：02/05/11 22:14
>>25 はﾊﾞｯｸｱｯﾌﾟの意味を知らないど素人
27 ：名無しさん＠お腹いっぱい。：02/05/11 23:29
>24
tarはどうでしょ？
常々一番痛いなと感じてるもんで。
28 ：名無しさん＠お腹いっぱい。：02/05/11 23:35
Backupはtarでしか取らないんですけど何か？
29 ：名無しさん＠お腹いっぱい。：02/05/11 23:43
GNU tar の --atime-preserve オプションを使ってバックアップすれば、
ufsdump ライクにバックアップ対象の atime を更新せずに済むのでお勧め。
30 ：名無しさん＠お腹いっぱい。：02/05/12 23:29
>>29
それだとincrementalバックアップできるの？
31 ：名無しさん＠お腹いっぱい。：02/05/14 03:18
>>29
それだとi-node番号保存できるの？
32 ：名無しさん＠お腹いっぱい。：02/05/14 07:45
>>31 i-node 番号は、 ufsdump/ufsrestore でも保存できない。
33 ：名無しさん＠お腹いっぱい。：02/05/15 01:26
Amandaたんを使ってるヤシはいないか.....
"UNIXバックアップ＆理科張り（オライリーのワニ本）"にAmandaたんの
紹介があって、SAMBA経由だとＷｉｎもバックアップできるという
マシン一括バックアップにはこれ最強！と思ったのだが、日本では
あまりユーザがいないようで。

ちなみに、今俺の事務所で一緒に働いている外人さんがＨＰの
ＤＬＴテープに3台のFreeBSDサーバを丸ごと自動バックアップ
できるように頑張ってます。
34 ：名無しさん＠お腹いっぱい。：02/05/23 07:42
誰かなんか書けやｺﾞﾗｧ!age
35 ：名無しさん＠お腹いっぱい。：02/05/23 07:44
Internetがバックアップメディアですが、なにか？
36 ：名無しさん＠お腹いっぱい。：02/05/23 21:14
脳がバックアップメディアですが、なにか？
37 ：660：02/05/24 00:53
>> 12
docs.sun.com の IA 向け installboot の説明には
誤記があった気がします。（日本語の方のみ）

そのせいだったりしませんか？
38 ：名無しさん＠お腹いっぱい。 ：02/05/25 00:33
win & unix backup は veritas 以外に
legato Networker と書いてみるテスト
39 ：名無しさん＠お腹いっぱい。：02/05/26 07:44
Archive Python 0406-XXXとSCSI-BIOSから認識されるSeagateブランドの
DDS3ドライブを入手しました。
Windows2000からは標準のバックアップコマンドで使えましたが、
solaros8からは使えなかったようです。使えている人いますか？
solarisではサポート外なんでしょうか。
40 ：名無しさん＠お腹いっぱい。：02/06/13 23:38
サーバーが３台、ＤＭＺにあります。solarisとLinux混在です。
バックアップを取りたいのですが、大体皆さんどのようなシステムを使って
いらっしゃるのでしょうか？
予算４００万円くらいです。ハード、ソフト含めて。
よろしければ、一般的な、ＵＮＩＸ環境のバックアップソフトのシェアとか
も教えていただければうれしいです。
当方、バックアップはあまり知りません。
41 ：名無しさん＠お腹いっぱい。：02/06/20 12:42
ウチの基幹サーバはOmniback2使ってるよ。
...Linux対応してたっけ？

つうか、そんだけの予算なら、ここじゃなくてベンダに相談したら
真面目に検討してくれるんじゃない？
42 ：名無しさん＠お腹いっぱい。：02/06/26 01:25
dumpを使っているのですが、dumpを使わない理由を教えてください
（すみませんが、圧縮できない、は別で）
43 ：名無しさん＠お腹いっぱい。：02/06/26 13:50
http://www.storagetek.co.jp/storage_application/medical.html

ここで相談しろボケが！
間違いねえんだよ！　シェアトップの実績が物語るぜ！クズ共
44 ：名無しさん＠お腹いっぱい。：02/06/26 17:50
>>1

pax -w "source" | gzip -9 > "target.tar.gz"
45 ：名無しさん＠お腹いっぱい。：02/06/26 19:51
>>42
おれdump。gzipで固めてどこかにおいてる。
46 ：_：02/06/29 00:23
>>40
3台で400万ですか...なかなかいまどき豪勢ですね

1bitでも欠けたら損害賠償で裁判だゴルァならほんとに
超有名ベンダーに丸投げして、責任も丸投げしたようがいいよ

よく知らない人が管理するってことは、とりあえずtarでちまちま
とってても問題なさそうだけど...

ところで、一般的にはどうか知らないけど、最近はテープってみんな
使ってるの？DDS3でも容量ぜんぜん追いつかないと思うんだけど、どうよ
すぐ読めなくなるし、クリーニングはしなきゃいけないし
ものすごい管理費がかけられるとこ以外は、あんまり使えない気がするんだよねー
47 ：40：02/07/01 00:47
40番です。
dumpは使ってもよいのですが、リストアのは簡易さ、及びバックアップの容易さ
を考えて、ソフトウェアを選びました。

昨日東京ビッぐサイトに行ってきました。データストレージＥＸＰＯです。
私は派遣なのて、いろいろと問題があったのですが、デジタルテクノロジー
には馬鹿にされました。本当に営業？と言わざる得ないほど、ひどい人材で
した。
それにくらべ、各社はほんとに良く聞いてくれました。

このなかから２社を選んで、交渉します。
48 ：41：02/07/01 01:06
>40
どういう構成で交渉すんのかチョト興味はあるっす。
バックアップサーバ立ててLAN追加するの？
49 ：名無しさん＠お腹いっぱい。：02/07/04 04:19
>>1
lha a hoge.lzh

これ良いですよ。パイプ要らないし。
部分バックアップには最適。
50 ：名無しさん＠お腹いっぱい。：02/07/04 06:19
>>46
昨年末まで勤務していた会社(小企業です)ではAIT-1使ってました。
300Mbyte強のDBファイルのフルバックアップ用途です。(サーバ機1台)
テープ5本をローテーションして毎日。

上記条件において、テープ寿命1年、テープ単価\10k前後、ヘッド寿命2,3年
ってことを考慮するとDLTの方がお得だったかも。
でも財政面で貧困な弱小会社じゃ、DLTドライブなんて価格で稟議通らない
んですよねぇ。(もう辞めちゃったからいいけど
51 ：名無しさん＠お腹いっぱい。：02/07/04 08:13
>>49
パイプ使うとなにか問題あるの?
52 ：名無しさん＠お腹いっぱい。：02/07/04 16:03
>>51
面倒くさいかなと。
解凍も
lha x hoge.lzh
で済むし。Windowsとの互換性も高い。（と思う）

インクリメンタルバックアップとか複雑なことをやり始めると、paxやdumpが
一番良いね。
53 ：名無しさん＠お腹いっぱい。：02/07/04 17:00
>>52
lhaなんて、Windowsユーザが *.lzh でファイルを送ってきた時に、
しょうがなく使うものでしょ。
主に日本でしか使われてないし、
展開することはあっても、自分で新規のアーカイブを作ることはない。

Windowsユーザとの互換性をいうならzipでしょう。
zipだと、途中までダウソ中のアーカイブをとりあえず先頭付近のみ展開してみる、
といったことができないので不便だな。
SolarisやJavaの絡みがある場合に限りしょうがなく使ってる感じ。

で、
通常は *.tar.gz または *.tar.bz2
ファイルシステムのバックアップでは *.dump.gz も使う。
54 ：名無しさん＠お腹いっぱい。：02/07/04 19:26
ところで、 cpio って使わないの？
55 ：名無しさん＠お腹いっぱい。：02/07/04 19:56
「解凍」ができるのはlhaだけ！
56 ：名無しさん＠お腹いっぱい。：02/07/05 04:35
lhaは規格がほぼ統一されてるから混乱がない。
0567については現在全く問題にならない。DOSでも使わない限り。
ヘッダ以外の部分なら壊れても回復できる可能性は高い

ZIPは色々あって駄目だし、圧縮できるソフトが限られているから使いづらい。
内部的にはUNICODEだから、ShiftJISとの対応が上手くない。
ファイルが解凍できなくなる場合がある。（一回泣きを見た）
ヘッダ以外の部分なら壊れても回復できる可能性は高い。
が、サイズが欠けると全く読めなくなる。

gzフィルタを通したファイルは、１ビット欠けても全体がエラーになり使えなくなる。
フィルタなので、gzを扱うにはフィルタの知識が必要になる。

まぁ、バックアップは
lha
pax(IEEE Std 1003.2 `POSIX.2' 標準のスーパセット)
dump
で良いんじゃねーの？
57 ：名無しさん＠お腹いっぱい。：02/07/05 10:29
ちらっとも出ないけど、pdumpfs はどう？
HDD → HDD で差分バックアップ取るならけっこう良いと思うんだけど。
俺は wrapper を自分で書いて、使いまくってまふ。
58 ：名無しさん＠お腹いっぱい。：02/07/05 12:46
lhaとかzipみたいなUNIX以外からきてるツールで
タイムスタンプとかパーミッションとかの情報もちゃんと保存されるの？
59 ：名無しさん＠お腹いっぱい。：02/07/05 14:15
>>58
lha や zipでも、UNIX上でアーカイブ作成すれば
タイムスタンプ、パーミッションや、シンボリックリンクも一応保存されるみたい。

でも lha で /dev/* とかのデバイスファイルはアーカイブできない。

いずれにしても、UNIX で lha 使うのは括弧÷杉。
60 ：名無しさん＠お腹いっぱい。：02/07/05 17:22
>>56
lha dos版ver2.55準拠であれば、じゃない？
最近のunlha.dllやオフィシャルリリースされなかったlha準拠だと
UNIXでは使えないし、統一されているとは言いがたい気がするが...

>>47
あ～、あそこは、あたりはずれあるね...

それはさておき、Solaris/Linuxの両方サポートしているソフトって
いまは結構あるよね
・NetWorker(http://www.legato.com/)
・NetBackup(http://www.veritas.com/jp/products/backup/nbubs/)
・NetVault(http://www.bakbone.co.jp/products/netvault/netvault.htm)
・Arkeia(http://www.arkeia.com/)

この中で一番日本語マニュアルがわかりやすかったのはNetVaultな気もする
でも、ちょと、設定がわかりにくいかも？

NetBackupはwizardが付いているので、適当に設定ができる

NetWorkerは玄人志向?結構細かい調整が利く&サポートリストに無いテープも使える(他のソフトだと使えない)

Arkeiaは見た目が楽しかった^^;;;
61 ：名無しさん＠お腹いっぱい。：02/07/05 18:03
＞最近のunlha.dllやオフィシャルリリースされなかったlha準拠だと
＞UNIXでは使えないし、
（ﾟДﾟ)ﾊｱ?

『オフィシャルリリースされなかったlha準拠』は解らないけど、
少なくともunlha32.dllで作ったWindowsアーカイブをUNIX上で解凍できるし、
その逆もできるよ。

>>59
まぁ、カッコイイかどうかはなぁ。MS-DOS臭さがあると言えばあるかな。
慣れてしまうと、こっちの方が精神的に落ち着くんだけどね。
逐次、処理結果を標準出力に返すし。

あと、Windowsソフトにはunlha32.dllを使用したファイラーが沢山ある。
unlha32.dllがプログラマに使いやすいからだろうけど。
ZIPはいちいち3･4つのdllを使用しなけりゃならないし面倒なんだよね。
ZIP用の圧縮ソフトは幾つかあるけど、マウスを共用したりする操作性が気に入らないし、
組み合わせができない物ばかり。シェアだったりするし。
何より、自分用のカスタムアプリに組み込めないのがイタイね。
62 ：60：02/07/06 00:27
>>61
ん...
あ...lha7書庫に対応してたのか...

http://www2m.biglobe.ne.jp/~dolphin/lha/lha-unix.htm
ん～、対応から結構たってたなぁ...
全然バージョンアップしてなかったよ^^;;;

63 ：名無しさん＠お腹いっぱい。：02/07/06 13:30
素直にufsdump
64 ：名無しさん＠お腹いっぱい。：02/07/07 00:52
素直に dd
65 ：名無しさん＠お腹いっぱい。：02/07/07 01:07
ddで個人RAID不要だね。
66 ：_：02/07/08 00:19
unlha32.dll って、ソース後悔されてないの?
67 ：名無しさん＠お腹いっぱい。：02/07/08 10:46
>>66
されてると思うよ。
統合アーカイバプロジェクトのサイトに行けばあると思う。
68 ：うひひ：02/07/08 10:55
>>65
RAID-1の話かな？だろうね
ddってのは撃ち込んだ直後、瞬間がRAID-1に近いけどさ
RAID-1ってのはミラーリングだから常時ミラーを保持されてる
わけでいつナンドキに片方がブチ壊れても良いわけで（以下略

っということでダウト
69 ：↑：02/07/08 16:15
>>65は単に、バックアップ用途での個人RAIDが不要って意味で言ってるんだろ？
大体冷静に考えてみろ、最近は半年前買ったHDDは80G、でも昨日買ったHDDは200Gなんて奴らが
たくさん居る、ddならうまくやれば2～3回分スナップ取っておけるって意味でじゃないのか？

大体最近流行のIDE-RAIDなんて、片方がいつ壊れたって大丈夫ってほど丈夫じゃないし
つーか最近のIDE、同ロットの物を同時に使うと壊れる時期までほとんどいっしょ。
かといって別々のIDE、あるいは別ロットなんか使うと相性問題が出ることもあるしな。

うちのも先日、一年前くらいに買ったST340016Aが四台、ほとんど同時に逝った。（ｗ
わざわざ1枚プラッタの方を選び、二台毎に山洋の8cmファンまで付けてやってたのにこのザマだ。
正直、SCSI-RAIDならまだしも、個人RAIDとか言ってIDE-RAIDなんか使うくらいなら
リムーバブルにでも入れて、時々ddでスナップ取って普段は外しておいたほうがよっぽどマシ。< RAID1ならね。
70 ：名無しさん＠お腹いっぱい。：02/07/08 19:42
>69
つか、「バックアップ用途のRAID」というのがよくわからないんですが。

ということで現状では
>うひひ
さんに静かに同意。
71 ：65：02/07/08 21:56
ddの方が初期投資が遙かに少ないし、応用が色々できて良いかなぁと思って。
個人用って事で、大した事無いファイルとか、一日一回dd(+tar.gz)とかでバックアップ
とっておけば、また作り直せばいいや、ダウソし直せばいいやって感じで。

業務用だと、1bit欠けても困るでしょ。業務用ならRAIDは必須。

・・・と思って書いたけど、よくよく考えてみるとただの日単位バックアップだし、
RAIDとかんけーねーやって事に気づきました。

>>68
たしかに、ダウトですた。



　　　　　お騒がせしてすいませんですた。

72 ：65：02/07/08 21:59
ん？
あれ？

とりあえず、RAIDもリアルタイムでバックアップを作成するからバックアップといえば
バックアップじゃ・・・。

73 ：名無しさん＠お腹いっぱい。：02/07/08 22:09
RAIDは過去に遡れないのでバックアップとは言わねえだろ。
74 ：名無しさん＠お腹いっぱい。：02/07/08 22:50
RAID1ではオペミスは復旧できない罠
75 ：名無しさん＠お腹いっぱい。：02/07/08 23:14
バックアップはバックアップだと思うけど。

アーカイブじゃないのは同意。
76 ：70：02/07/09 00:45
>72
3本のディスクでミラー作って、そのうちの1本はあるタイミングで
切り離すようにすれば、バックアップになりますね。
＃個人用RAIDで実現可能なのかどうかは知りませんが。

後、数世代残すバックアップの仕組みじゃないと、いやなタイミング
で障害が発生したとき、遠くに旅立ちたくなるので注意。
77 ：名無しさん＠お腹いっぱい。：02/07/09 19:26
>>76
raidしつつ定期的にdd | gzipすれば最強だな。
78 ：名無しさん＠お腹いっぱい。：02/07/09 20:00
>>77
で、火災や地震の場合の対応はどうするの？
RAID1 でも dd | gzipでもいいけど、
あるタイミングで切り離したハードディスクを
ちゃんと遠隔地に移送して保管してる？
79 ：名無しさん＠お腹いっぱい。：02/07/09 22:33
>>78
ハードディスクだとその移送がこわいよねー。
80 ：名無しさん＠お腹いっぱい。：02/07/10 21:55
バックアップとミラーリングは用途がちがうざんすよ

媒体復旧とデータ鏡像保持とかけばその文字がかたるがごとく。

媒体復旧は壊れてダメんなったときに戻すためにある　よって復元操作をしなければ壊れたまんま
データ鏡像保持とは肉を切らせて骨を絶つためにある　よって実像がブチこわれたら鏡像で運転して故障を回避するためにある

最近はOPCだのバックアップサーバだのなんだのがあるので微妙なところなんスけどね。
81 ：名無しさん＠お腹いっぱい。：02/07/10 22:02
ほんとだね。
難しい言葉オンパレード。
馬鹿な私にはさっぱり。
言葉は忘れたがリアルタイムに遠隔地にバックアップする仕組みもあるみたいだしね。
バックアップ方法は５０ぐらい勉強したけどすべて忘れました。
結局、壊れもしなければ、災害にあわなければ必要なし！！
どうか故障がないように！！と祈って、バックアップをサボります。
82 ：名無しさん＠お腹いっぱい。：02/07/10 22:08
バックアップとセキュリティって、相反するので両立が難しいよね。
リアルタイムに遠隔地にバックアップする方式は、
機密性の高いバックアップ対象には使えないし・・
83 ：名無しさん＠お腹いっぱい。：02/07/11 14:03
しつこい言い事かもしれんが、大体、上記の解釈で問題ないと思うけど、
バックアップはおそらく
バックアップ⊇RAID
バックアップ⊇ミラー
かもしれないよ。

backup
【名】
１ ａ 【U】支援，バックアップ． ｂ 【C】支援者［物］．
２ 【C】代替の人［もの］，代役．
３ 【C】《米》（交通などの）滞り，渋滞．
【形】【A】
１ 支持［支援］する．
２ 代替の，予備の，副の: a ～ candidate 予備候補．

となってるから、代替の物、支援、という意味もバックアップという言葉には内包されている。
元々英語なんで、単語の持つ守備範囲が１対１ではないからよく混乱するところだけど。

バックアップは
・ミラーリング（二重化）
・アーカイブ（倉庫）
・ヒストリ（履歴）
を全て含んでいると思われる。
84 ：70：02/07/11 18:19
>83
単語の本来の意味はそうかも知れないんだけど、それをコンピュータ扱う
人間が言う「バックアップ」「ミラー」と一緒にしちゃいかんような気が
しますが。
後、RAID0みたいに耐障害性が逆に低くなるものもありますし。

だいたい上記までに語られている意味で、コンピュータの世界限定ですけど
よろしいんじゃないでしょうか。

>81
遠隔の仕組みって一般名詞ありましたっけ（よく知らない）。
某有名メーカではSRDFって言ってたような。
85 ：名無しさん＠お腹いっぱい。：02/07/11 21:49
>>84
いやいや、用語の中にこそ、エレメント（最も重要な要素、本質、意味）
が含まれている。ほとんどの場合。
私ら、象形文字圏では漢字の形にその本質が含まれているように。


例外として、たまに当て字もあるけど。これもまた日本語と同じ。
86 ：名無しさん＠お腹いっぱい。：02/07/12 09:09
言葉上の定義は「おいといて」。

RAIDがバックアップとして通用するかどうかでは。
>73、>74に同意。

通常の（サーバなどの）運用では、たとえRAIDをしていても
テープその他のメディアで一定期間毎に、
「バックアップ」を取るのは必要かと思われ。

87 ：名無しさん＠お腹いっぱい。：02/07/12 12:52
>>86
通常のRAIDではそうだが、
RAID1で、時々ミラーを切り離し、切り離した片割れをそのまま保存して
新しいハードディスクを新たにミラーとして繋ぎ直して
再同期化する・・ということを繰り返せば、
立派に履歴が取れ、バックアップとして使えると思うが・・
88 ：名無しさん＠お腹いっぱい。：02/07/12 17:17
>>87
あんまり頻繁にやるとホットスワップのコネクタの強度とかが問題になるかも。
89 ：名無しさん＠お腹いっぱい。：02/07/12 19:54
>>87
IDE-RAIDって、ホットスワップできるの？
90 ：名無しさん＠お腹いっぱい。：02/07/13 01:13
おいおい　バックアップ⊇RAID　じゃあねーだろ

安いゼニでええディスク性能だすための技術やっちゅーねんなほんまにもーうきー！
91 ：名無しさん＠お腹いっぱい。：02/07/13 08:20
>>89
87 のどこに IDE と書いてある？
SCSI でしょ。
92 ：名無しさん＠お腹いっぱい。：02/07/13 09:30
>>89,91
ATAでもホットスワップできるよ。
http://www.3ware.com/products/ata.asp
これとか。
93 ：74：02/07/13 09:38
管理者がヘタレだと、ミラーしているdiskが全部死んでから気付くという罠。
94 ：名無しさん＠お腹いっぱい。：02/07/14 02:51
>>90
だぁからぁ。RAIDのかたわれをバックアップと呼ぶんじゃねーか。このスットコドッコイ。
ばっくうぷとは、後ろで支えるっちゅう事。
野球で言えば分かり易いやろ。
右中間の強烈なあたりでファーストのバックアップにピッチャーが行くちゅーことや。
こんぴゅーたも一緒。


ほんましばいたろかいなほんま。(#･ж･)
95 ：70：02/07/14 19:04
>94
すみませんが、それどっかのサーバ管理者に言ってみてくれませんか。
というか、その理屈がどの程度の範囲で通じてますか？
96 ：名無しさん＠お腹いっぱい。：02/07/14 19:24
>>95
平易に言うと、ﾊﾞｯｸｳﾌﾟ＝予備（全般）となる
サーバ、ディスク、デバイス、これらの予備全てを指してバックアップといえる。
『バックアップは生きてるのか？（予備サーバは大丈夫か？）』とか、
『バックアップしとけ（予備つくっとけ）』とか使う。

RAID1だとどっちもプライマリだけど、どっちか一方を指してバックアップ
と言うこともできるだろ。用法はかなり局所的だが。
ただし、RAID4・5になるとバックアップという言い方は使えなくなると思う。

ただし、カタカナ英語の氾濫する日本社会だと、どういう意味を持っているかは
人によりまちまち。
まぁ、コミュニケーションは密にとっといた方が良いよと言う事が結論かもしれない。


蛇足だが、工業用語を標準化する事も大切だと思った。
業界や会社によって違うのはあまり良くない。
97 ：名無しさん＠お腹いっぱい。：02/07/15 22:42
余談だが、
「あまり金具を曲げたり伸ばしたりするとストレスで折れるよ」
と言うと、
「えっ、金属もストレスたまるんですか。面白いこと言いますね」
と言われて唖然としたことがある。

もと技術用語が一般用語として広まって、使用される意味が変わった典型例。
「ストレス」
98 ：名無しさん＠お腹いっぱい。：02/07/16 11:26
>>97
技術用語なの?
普通の英単語だと思ってた。
99 ：名無しさん＠お腹いっぱい。：02/07/16 17:27
オカマ連中をバックアップしちゃうスレはここですか？
100 ：名無しさん＠お腹いっぱい。：02/07/16 17:50
>>90
> 安いゼニでええディスク性能だすための技術
んな事ぁ無いだろ。
可用性の向上をディスクの性能と言うのならば別だが。
101 ：うひひ：02/07/16 18:35
結局の所話をするのにまぎらわしいから
ミラー取るかアーカイブ取るか
んで各々にいろんな手段がある（方法・メディア）をはっきりうたえ
ちゅーことなんかね。



102 ：名無しさん＠お腹いっぱい。：02/07/16 20:23
>>100
RAIDは可用性と速度、両方の向上を狙った技術だよ。
103 ：名無しさん＠お腹いっぱい。：02/07/16 23:20
>>100
部品点数は少なければ少ない方がいい

これは定説だと思ってたんだが
104 ：名無しさん＠お腹いっぱい。：02/07/17 17:24
>>102
性能向上だけじゃ無いだろ、可用性の向上も狙ってるんだから。
って事では？
105 ：名無しさん＠お腹いっぱい。：02/07/18 02:02
>>103
検算は多い方が信頼性が高いって事だと思うよ。

管理コストは機種の二乗倍になるけど。
106 ：名無しさん＠お腹いっぱい。：02/07/18 02:04
>>105
それらがあっている確率はどうかな？
中心漸近定理が効くような、すなおな機器ばかりならよいのだが

いや、マジで大変なんですよ奥さん
107 ：名無しさん＠お腹いっぱい。：02/07/18 02:38
>>1
ｽﾚﾀｲのノリに、おすぎとピーコのフジテレビ深夜番組を思い出したのは漏れだけか?
108 ：名無しさん＠お腹いっぱい。：02/07/18 07:50
でもさ・・・RAID組んでも、

「一日前の業務データの戻ししたいんだけど・・・」
「rm -r で間違ってファイル消しちゃって、、、昨日のでいいから戻せません？？」

なんて要望には応えられない　バックアップにはこういう側面もあるってワケよ

なのでRAID≠バックアップに一票
109 ：名無しさん＠お腹いっぱい。：02/07/18 08:06
>>106
中心極限定理は、あくまで「定理」であって「法則」ではないから、
個々のサンプルの分布がどのような変な分布であっても、
極限では正規分布になるということが「定理」として証明できる。
110 ：名無しさん＠お腹いっぱい。：02/07/18 08:17
>>108
このスレの前の方、欲嫁。

その場合は、一日前に切り離したRAID1のカタワレを取り出して、そこからファイルを読み出せばよい。
111 ：名無しさん＠お腹いっぱい。：02/07/18 12:37
>110
普通のRAID1だと、ミラー切り離した時点でDISKの冗長性がなくなるぞ。
（ホットスタンバイといっても即同期が取れる訳じゃない）
再度くっつけたところで、同期取るまでに性能おちまくるし。
素人以外はお勧めしない。

それ以前に、>110のやり方は「テープ１本のみで毎日バックアップ取りつづける」
という愚を犯してるのと何ら変わらん。
これ最凶。

というわけで、>108に一票。
112 ：名無しさん＠お腹いっぱい。：02/07/18 12:49
>>111
RAID1の三面ミラーで、一面ずつ交換。
交換玉はイパーイあるのをなるべく長期保存してローテーション。
・・でどうよ？
113 ：名無しさん＠お腹いっぱい。：02/07/18 13:35
RAID1で、毎日定時にdd | gzip で、7day分別ディスクに取っておく。
（＋dump -9 | gzip で7day分別ディスクに取っておく）
毎週 dump -4 して、４週分別ディスクに取っておく
毎月 dump -1 して、テープかCDかDVDに永久保存する。

これ最強？
114 ：名無しさん＠お腹いっぱい。：02/07/18 13:38
あ。バックアップのファイルリストを/var/backup/以下に置いておくと良いかもな。
あれが欲しい、と思ったときにすぐ取り出せる。
115 ：111：02/07/18 20:20
>>112
俺もこの分野あんまし正確なところ語れないが。
（多分かなり知ってそうな人間の書き込みもチラホラ見るが）

(1)日々の運用で玉引っこ抜くことが前提になってる製品が多分存在しない。
(2)3volume mirror(だっけ？)が可能な製品は、普通個人で購入できる代物
じゃない。
でも、俺よく知らないけど、個人用RAIDとやらで可能なのあるのかな。
(3)もし(2)を無理に購入したとして、交換用DISKを数本買うと、普通のサラ
リーマンは破産する。
(最近は安くなってきたみたいだけど)
(4)そもそもモノがDISKなんで運び出しが恐怖。

ひらたくいうと、「モノは存在するし、やればできないことはないが、
個人レベルでは無理」じゃないの？
116 ：111：02/07/20 02:20
誰かおっきな構成のシステムでどんなバックアップしてるか
熱く語ってくれんもんだろか。
(1)テラ超えのDB
(2)24h365日運用
(3)クラスタ構成
(4)分散DB
とか、これでもか！という構成の中を血まみれで戦い続ける勇者は
いないもんかなと。
117 ：名無しさん＠お腹いっぱい。：02/07/21 02:29
>113
バックアップデータを貯めておくDISKを、オペミスか何かで飛ばしたら
まとめて（7日～1ヶ月か？）バックアップデータを失うため、最強じゃない。
テープ１本で日々バックアップするよりは世代が残る分マシといった程度。

運用は楽そうな気がするが。

素直にテープ数本+クリーニングテープ1本購入して、日々ローテーション
するのが手堅いと思う。
原始的だがバックアップ時間さえ気にしなければ最強に近いと思う。
118 ：74：02/07/21 11:10
>>95
> すみませんが、それどっかのサーバ管理者に言ってみてくれませんか。
別件で修理に行った時に、片方のDiskが逝ってるのを発見。
1ヶ月以上前から壊れている。
「いやー、気付いて良かったですね。(苦笑)」
さすがに、全部死んでるのは今まで無かったですけど、あくまで確率論。

基本的に、ヘタレ管理者=動かなくなったら気付く。

> というか、その理屈がどの程度の範囲で通じてますか？
超金かかってる案件　　　　-> リモート監視してるので通じない。
超金かかってる案件の開発　->通じる時もある。
金かかってない案件　 　　　-> そもそもミラーしてない罠。

#クラスター組んでるマシンでもdiskをミラーしてないとか。
#待機系のdiskが死んでたら切り替わっても稼働しない罠。
119 ：名無しさん＠お腹いっぱい。：02/07/22 01:02
>>117
パーミッションをきちんと管理すればオペミスで飛ばす可能性は最小限に抑えられる。
バックアップが飛ぶ可能性を考慮するならバックアップディスクを更にRAIDすればいい
と思う。

120 ：名無しさん＠お腹いっぱい。：02/07/22 01:37
>>119
パーミッション云々というよりも、そもそも同一マウントポイントに数世代の
バックアップが乗っているという時点で不安を感じないか？
可能なら世代別に物理的に分離すべきだし、マシンから離れた場所で保管する
ことのできる点でもテープというのは偉大だと思う。

ただ、利便性を追求するがために安全性をちょっと落とすというのであれば
別にそれはそれでかまわないと思うが。
121 ：名無しさん＠お腹いっぱい。：02/07/22 02:26
(1)テラ超えのDB
　200GBくらいですが参考になるのかどうか・・・
(2)24h365日運用
GWと正月には運休してます
(3)クラスタ構成
　いっぱいぶらさげてます
(4)分散DB
　いっぱいちらばってます

集約バックアップシステムなるものを立てて、
某社のとあるソフトでぢるぢる吸わせて、そいつに保管させてます。

ぢるぢる吸わせる対象は、各ノードがある決まった時間までに所定のディレクトリにつくっておき、
集約バックアップシステムに設定してあるスケジュールに基づいて吸わせます。

吸う動作は、吸う前の前処理→吸う→吸ったあとの後処理
が基本で、前処理・後処理は各ノードで仕組みを用意しておきます。

RDBMSのデータなんかは、
差分出力を担当するメインのRDBMSノードが代表してとりまとめてデータ抽出を行います。

集約バックアップシステム自体は、60日分くらいの差分を持たせてます。
日中はひがな集めたデータをテープに吐き出す作業を行ってます。

いじょ
122 ：名無しさん＠お腹いっぱい。：02/07/23 00:33
>>120
昔ほど壊れないし、１ヶ月ごとのバックアップはちゃんと取ってるから、良いかなと。
前回のバックアップまでの分がRAID共に駄目でバックアップも全部壊れたら諦めてね。という感じで。
不安なら一週間ごとに永久バックアップ取るとか、色々工夫すれば良いと思う。
あとは、遠隔サーバにNFSミラーリングってのも良いな。

とりあえず、テープは出し入れが面倒だ。
なるべく人手がかからないようにしたいと思う。
123 ：122：02/07/23 00:39
あれだ。
一台のバックアップ専用PCにネットワークバックアップを取るとして、
一週間で７台必要になる。一台が10万と多めに見積もって、
投資額は70万。更に高級にして140万積んでもいいや。

人を雇えば、年間最低700万どっち取る？
124 ：名無しさん＠お腹いっぱい。：02/07/23 00:42
>>122
テープは出し入れが大変というんだったら
出し入れの必要が無い本数のチェンジャーを買えばいいだけじゃ...
125 ：名無しさん＠お腹いっぱい。：02/07/23 00:45
>>124
だったらストレージ専用ネットワークPC買った方がお得という罠。
高速だし。

126 ：名無しさん＠お腹いっぱい。：02/07/23 01:14
結局、ハードウェア命&ソフトウェア命であってデータは二の次なんだろうな
>>122や>>125みたいな考え方の人って。
ひょっとして業務システム扱ったこと無いんとちゃう？

システム売り屋として「データ失ったら諦めて」なんて言葉吐いたら致命傷だと思う
127 ：名無しさん＠お腹いっぱい。：02/07/23 01:24
目先の金額の大小でしか物事を判断できない連中が多いってことか・・・
128 ：名無しさん＠お腹いっぱい。：02/07/23 01:27
>>126
なんでそんなにテープ使いたがるわけ？
データのビット列をある程度の信頼性で保存できればなんでも良いだろ。

あんな、使いにくくて噛んだりするし、磁気で一発消去で、湿気に弱いし、
巻き戻しとか面倒で使い勝手が悪いし、しかも不要に高い代物使わなくても
良いじゃないの？
今更、前時代的だと思うよ。テープデバイスなんて。
129 ：１２８：02/07/23 01:30
＋汎用性が足りない。

IDEインターフェースなら上位互換性があるけど、
テープなんて８つも９つも有るし、色々な記録フォーマットが乱立してるし、
コマンドもメーカーでバラバラ。
扱いにくいったらありゃしないよ。
130 ：名無しさん＠お腹いっぱい。：02/07/23 01:37
>>127
経営ってのは目先の利益は大事だよ。
目先の利益を確保しつつ、長期計画を立てないと、今の時代生きていけない。
というか、今までが楽すぎたと考えるべきか？
本来、経営というのはまず生かす事ありきだと思うよ。死んでから考えても遅い。
131 ：名無しさん＠お腹いっぱい。：02/07/23 01:57
>>1
pax ユーティリティは、 IEEE Std 1003.2 (``POSIX.2'') 標準のスーパセットです。
132 ：名無しさん＠お腹いっぱい。：02/07/23 01:57
>>128-129
IDEインターフェースとIDE-HDDが信頼性高いとでも？アフォか


磁気記録分野覗いてからモノ言いな
133 ：名無しさん＠お腹いっぱい。：02/07/23 02:03
>>130
あたり前のことをまことしやかに書いているが何を言いたい？
134 ：名無しさん＠お腹いっぱい。：02/07/23 10:43
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%A4%DE%A4%B3%A4%C8%A4%B7%A4%E4%A4%AB&sw=2
135 ：120：02/07/23 12:44
>>123とか128とかいろいろ

テープを使いたがる理由は「DISKと長所短所がまるで違う」のと「値段」だと
自分は理解しているが。
とりあえず、テープのコストと、テープと同程度容量のDISK上にバックアップ
データを置くのとではどっちが安いかというのを考えて、テープの方がコスト
が安くつくケースは（予算があれば）テープを選ぶ。
＃パソコンだとメリットは多分無いだろう。

後、長所と短所がまるで違うという点だが。
DISKが壊れるような状況でも（衝撃だな）テープは生き残る可能性がある。
逆にテープが壊れるような状況でもDISKは生き残る可能性がある。
普通、バックアップというのは災害レベルも一応は検討する（実施までする
べきなんだが、なかなかね）ものだから、そういう意味でテープは痛い短所
も持っているとはいえポータビリティのあるいいデバイスざんす。

後、IDEインタフェースと比較するなら、テープはSCSIインタフェースと思うが
どうよ。
記録方式の比較だというなら、IDE上に載ってるOSごとのファイルシステムの差異
とテープの記録方式の差異を語ることになるかと思うが、意味あるのか？
＃ちなみにtarだとブロックサイズ調整すりゃあ大抵のマシンで読めると思う。
136 ：名無しさん＠お腹いっぱい。：02/07/23 23:39
なんでテープ使うのかって？？

収容スペースすくないくてリムーバルだから　それ以上でもそれ以下でもない

集中バックアップシステム買えるよーな金持ちなんて金融だけだろ？あん？
137 ：120：02/07/24 00:09
>>135自己レス。

なんとなくDISKをバックアップ媒体として選択するケースもあるような
書き方をしたが、普通はしない。
バックアップデータのキャッシュ領域とか(直接テープに落とすと時間が
かかる）で使ってるものはあるが。
>>121
それって、モノとしてはNASのサーバ？それともバックアップソフトが
ネットワーク越しにデータをかき集めてくるやつ？
138 ：名無しさん＠お腹いっぱい。：02/07/25 15:43
>>135
最近のHDDは電源さえ切っておけば耐衝撃性はかなり高いよ。
ちょっと高い所から落としたくらいじゃまったく問題ない。
最近のHDDは電源が切られるとヘッドが固定される。昔みたいにブラブラしない。
ディスクもガラス製ではなくアルミ製が殆どで壊れる心配がない。

普通の管理なら問題はないと思うけどね。
まぁ、メディア容量とか流儀とかあるから別に良いんだけど。
下手に変えて品質落とすのは良くないだろうし。
139 ：名無しさん＠お腹いっぱい。：02/07/26 04:19
非動作時で耐えられる衝撃がたったの 400～1000G で問題ないと言えるのか？
140 ：名無しさん＠お腹いっぱい。：02/07/26 23:41
問題ない
141 ：名無しさん＠お腹いっぱい。：02/07/27 02:15
>>138
その理論はそのHDDがRAIDに組み込まれている状態では通用しないのでは?
142 ：120：02/07/27 12:44
>>138
とりあえずHDDの耐衝撃性なんてテープと比べるまでも無いと思うが。

後、「普通の管理」というのも範囲がわからない。
障害発生時のリカバリも含めての管理か？筐体全滅時を多少でも想定してるか？
「ちょっと高いところ」がどの程度を想定してるか分からないが、
阪神大震災ではかなりのユーザが泣いているぞ。
出入りのメンテ会社の人間に、その頃の苦労話を語ってもらうのも一興。

普通は余り難しく考えなくても、サーバなら大抵デフォルトでDATくらいは
つけるから、それ使ってバックアップ、で災害が心配なら他拠点へその
テープを送りつけて保管してもらう、くらいのことはする。
この程度の運用で、阪神大震災程度ならなんとか前日のデータまで戻せる。
＃日本沈没なら駄目かもしれないが。
この運用コストは企業にとって別に高くはないと思うし、この程度でマスタ
全滅が大抵の厄災から防げるなら有難いじゃないか。

こういったバックアップ運用なら最強にある程度近いと思うが、これまで上で
書かれてた「これ最強？」は全然最強じゃない。
他にも強烈な運用を、金のあるユーザはやってるからいろいろ見てみそ。
143 ：名無しさん＠お腹いっぱい。：02/07/27 15:43
>>142
阪神大震災級の災害に対応するなら、遠隔地に転送する以外ないよ。
どうせ燃えちゃう可能性があるしね。
144 ：名無しさん＠お腹いっぱい。：02/07/27 17:52
あと、水害でもダメになるなぁ。
水浸しで全とっかえだろうし。

まぁ、テープの優位性は,ある一定の規模において、メディア単価が安いということと、
メディア容量が大きいということ、これら以外に特に無いね。
145 ：名無しさん＠お腹いっぱい。：02/07/27 21:16
>>144
耐障害性も入れといてやれよ。
146 ：名無しさん＠お腹いっぱい。：02/07/30 01:45
>>145
やだ
147 ：名無しさん＠お腹いっぱい。：02/07/30 01:48
やっぱ pdumpfs でしょ。便利便利
148 ：名無しさん＠お腹いっぱい。：02/07/30 07:42
ん十TB のデータがテープの中にあるんだけど、テープ装置がメーカの
サポート終了でメディアチェンジしなきゃいけない。
でも金がないので、160GBの IDE HDD を箱買いしてきて、
リムーバブルディスクにしてちまちまとデータ移してるよ。
HDD壊れたらまずいので、ロットをずらしてミラーして遠隔地保存。
特に重要なのは三重ミラー。これでどう？
ちなみにテープも検討したけどコストが高いので却下したよ。
149 ：名無しさん＠お腹いっぱい。：02/07/30 10:09
数十TBなら、テープの方が安いと思うが…
150 ：名無しさん＠お腹いっぱい。：02/07/30 19:54
3580 Ultriumデータカートリッジ（100GB）DAT
22,000　220\/G
Maxtor 5400rpm4G160J8160GB
24,980　156\/G
151 ：名無しさん＠お腹いっぱい。：02/07/30 23:10
嘘つきは( ﾟ∀ﾟ)ﾉｶｴﾚ
152 ：148：02/07/30 23:20
ついでに HDD は全部にコントローラ付いてるから、複数台で同時に出来る。
テープ装置は本体の価格が高くて保守料金がさらに高い。
それに HDD 並の転送速度を稼ぐには、高価な本体を複数買わないといけない。
も一つおまけで 200GB HDD がもうすぐだからさらにコストが下がると思ってる。
で、TBの光ディスクが発売されたらその時にまたメディアチェンジの予定。
153 ：名無しさん＠お腹いっぱい。：02/07/31 02:46
FreeBSDで特にLevel0でdumpをとるときに正式にはシングルユーザモードに
してからとったほうがいいっていうけど、具体的にはどんな心配があるから
なの？
自分はWeb、メールサーバをバックアップするときに差分もフルダンプも
バリバリ運用中に（でも深夜に）とってるけど、一応今のところ２，３回
リストアしてもほとんど問題なかったんだけど。
154 ：anonymous：02/07/31 23:24
今日テープ交換してたら手が滑って
ラックの根本の隙間からフリースペースへテープ落としちゃったYo!
拾い上げるのにかなり苦労したが、
それはともかくあれがHDDだったらぶっ壊れてたかも。

>>153
restore した後にシステムが矛盾や不整合なく動作できるように
dump できているかってのが重要なんだな。それを確実に保証するのが
シングルユーザモードでの dump。だから理想的には差分 dump も
シングルユーザモードでやるのがいい。

たとえば、dump 対象ファイルシステムにメールスプールが
含まれていて、しかも dump の最中にメールが
届いたらどうなる? シングルユーザモードならそういう事態は防げる。
逆に、バックアップ対象が自分のホームディレクトリだけで、
バックアップの最中は誰も更新しないということが保証できるなら、
マルチユーザモードで dump してもかまわないわけさ。

# もちろん、これは FreeBSD に限らずあらゆるシステムについて言えるよん。
155 ：154：02/07/31 23:31
>>154
もちろん、わざわざシングルユーザモードに落ちなくても、
dump の最中はメールサーバプログラムだけを一時的に止める
というやり方もあるだろうね。次にメールサーバが起動した時に
不整合が発生していなければよい。
156 ：名無しさん＠お腹いっぱい。：02/08/01 00:11
rsyncって世代遡れないのと負荷がデカイ所が気になるけど
媒体障害対策としてはどうなんでしょうか？
157 ：名無しさん＠お腹いっぱい。：02/08/01 00:34
テープの媒体障害ってどのくらいの頻度で発生するのかな。
うちのテープメディア、数十本は読み込み不良起こしてるんだけど。
同じデータを複数本に書き込むしかないのかな。
158 ：名無しさん＠お腹いっぱい。：02/08/01 00:47
>>111
私はホットスワップできるIDE RAID1ユニット（4万円以下で買えるんですね）
にHDDを3台用意して，時々交換してバックアップしています．

111>普通のRAID1だと、ミラー切り離した時点でDISKの冗長性がなくなるぞ。

そのとおりですね．でも同期とっている最中にHDD死んでも，数分前のバックアップが
あるわけだからそんなに悲しくないかと．

111>再度くっつけたところで、同期取るまでに性能おちまくるし。

他のメディアにバックアップする場合にも，その作業中は性能がおちるわけなので，
これは同じかと．相手がHDDなので，テープより短時間で性能回復すると言えるかな．

111>それ以前に、>110のやり方は「テープ１本のみで毎日バックアップ取りつづける」
111>という愚を犯してるのと何ら変わらん。

「テープ１本」でもやらないよりはましかなと思っています（RAIDで動作中のHDDも
入れると2本と言っても良いかも）．もっともバックアップしているマシンが，
個人用のWWW＆ファイルサーバで，内容も，自分で書いたプログラムとか
論文とか家族の写真とかなので，こんなもんで良いかなと思っています．
159 ：名無しさん＠お腹いっぱい。：02/08/01 12:27
>>153

singleに落としておけば邪魔が少なくなる分
backupが早く終わるかも
160 ：名無しさん＠お腹いっぱい。：02/08/01 12:30
>>157
DLT14本+クリーニング1本*3台の、DLTだけで42本で運用してるけど、
１～２ヶ月に１回くらいでr/wエラー出るね。
再挑戦せずに即交換するから本当にDLTが駄目かどうかは知らない。
DLTの交換のめやすが数百回のwriteと聞いてるもので、その点は
テープは駄目すぎ。

なんか、コレ！というのって無いね。

>>158
その程度でいいと思ってるならそれでいいんじゃないの？
でも、コネクタ部の破損には気をつけてね。
161 ：名無しさん＠お腹いっぱい。：02/08/01 13:26
なんか個人用途と企業(?)のシステムと、ごった煮で話してるのが面白い。
162 ：148：02/08/01 16:05
ごった煮の業務利用側だけど、
今回保守終了になるテープドライブにかかっている保守料は私の年収より高い。
163 ：158：02/08/01 19:08
ごった煮の個人利用側なんですが、個人で使えるテープドライブ
って最近無いですよね。数年前ならいろいろあったけど、
いまふつうの個人ユーザのHDDをフルバックアップできるテープ
ドライブって個人では買えない。;_;
164 ：名無しさん＠お腹いっぱい。：02/08/01 19:24
個人で買える値段でHDDのフルバックアップできそうなテープデバイスといえば、
DVHSなんかが思い付くんだけど、どこかPCで使えるようにして販売してくれないかな。
165 ：160：02/08/01 19:25
ごった煮の業務利用側だけど、ディスク2本買うと、DLTが
15本入るチェンジャが楽に買える。
166 ：160：02/08/02 00:10
個人で買うなら、テープはちょっとアレだね。
今時、ディスクの容量にDATではすでに追いつかないし。
自分が家のPCでなんとかしようと思っても、ほかのマシンの
ディスクにバックアップ残すのが精一杯のような気がする。
CD-Rも速度の点で論外だし、何かいいのないかな。
167 ：158：02/08/02 01:41
それで、個人利用ならホットスワップできるIDE RAID1ユニット
使っての、HDDローテーションかなと思っているわけです。
コネクタ破損しないように気をつけます>160
168 ：名無しさん＠お腹いっぱい。：02/08/02 01:45
154さん遅くなりましたがどうもありがとうございます。
せっかくだからこれからはサービスを止めてからダンプさせるようにします。
169 ：名無しさん＠お腹いっぱい。：02/08/03 09:23
HDDは一々取り外さなくっても、電源を切っておくだけで良い。
外付けSCSIなら電源を統一するとか簡単でしょ？
内蔵でも工作ができれば簡単だけど。
で、使うときだけ電源入れてマウントすれば良い。
これ最強。
ただし、長期保存には向かないね。一ヶ月分とか一日分とか、そういうレベル
が最適。
テープでサイクル組むなんて面倒くさすぎるよ。（ｗ
170 ：名無しさん＠お腹いっぱい。：02/08/03 09:52
短期バックアップ：SCSI RAID1で、繋いだまま電源ON/OFFでローテーション
中期バックアップ：RAID1 HDDを物理的に交換、ローテーション
長期バックアップ：外したHDDを読み出して、*.dump.gzでDVD-Rに焼いて永久保存。

…これ最強。
171 ：名無しさん＠お腹いっぱい。：02/08/03 20:56
う～ん・・・なんだか金欠=貧乏な人や面倒くさがり屋=怠け者な人が
主観で「HDD最強説」を掲げているんですね。黙ってやってりゃいいのに。
馬鹿晒してどうすんでしょうね？：-P
172 ：名無しさん＠お腹いっぱい。：02/08/03 23:40
ごった煮の個人利用側としては、最近の数十GB HDDバックアップ
するには、HDDしか選択肢が無いと思うけど。
お奨めあったらぜひ教えてください>>171
173 ：名無しさん＠お腹いっぱい。：02/08/04 01:52
DLTってどうなんだろ
40/80が最後?

それ以降だと
SDLTかLTOか悩む
174 ：名無しさん＠お腹いっぱい。：02/08/04 03:30
>>171
データを見ても「HDD 最安説」は間違ってない。馬鹿はおまえだ。
SCSI や RAID さえもビット単価でテープを凌駕する日は近い。
テープ高い->買わない->値が下がらない、の悪循環は加速する。
バックアップメディアとして見たときに HDD には「対衝撃性」、
「ライトプロテクトが出来ない」、「メディア交換が容易でない」
等の欠点があるが、こうした点を改善すればおいしい市場が
待っている事に気付いている奴は既に結構居るはずだと思うぞ。
175 ：名無しさん＠お腹いっぱい。：02/08/04 04:10
>>174
あなたが語っている現在は「HDD最安節（ぶし）」のみです。
あなたが語っている未来は「テープダメ。HDD最高」だけです。
しかもその全ての根拠があまりにも薄弱です。

答え
あなたのせいで日立は結構大変なことになっています。
176 ：名無しさん＠お腹いっぱい。：02/08/04 04:15
RAIDのホットスワップで云々ってのはちとアレだけど、
テープメディアのbit単価 > ATA HDDのbit単価
が本当だとしたら(ごめん検算してない)、たしかにバックアップ先
メディアとしては有望かもしれないね。
衝撃に強いIEEE1394箱に突っ込んでバックアップする時だけ繋ぐようにすれば
> 「対衝撃性」、「ライトプロテクトが出来ない」、「メディア交換が容易でない」
このあたりはクリアできるかも。
177 ：名無しさん＠お腹いっぱい。：02/08/04 06:44
>>175
あっそ。

元々、ビット列をパンチカードで記録してた時代もあるんだ。
ビット列がある程度の品質で保存できればなんでも良いんだよ。
HDDで長期保存するのは馬鹿だけどね。
まぁ、どうせテープも同じだろう。
磁気記録は基本的に変化しやすいから。
178 ：名無しさん＠お腹いっぱい。：02/08/04 07:41
HDDはビット単価安いけど、耐衝撃性のなさをカバーするためにもし三重ミラーしたら
テープとさして変わらん。
メディアの移動も不安。

ソレ用に作られてないから、やっぱ無理あるっすよ。
179 ：名無しさん＠お腹いっぱい。：02/08/04 10:10
>176 テープメディアのbit単価 > ATA HDDのbit単価 ，が本当だとしたら

100GBのデータを一本（個）のユニットでバックアップしたいときの
ぷらっとオンラインでのメディア代の比較

TAPE SuperDLT データテープ（非圧縮110GB) ５本1パック＝134,800円
(一本(110GB)あたり26,960円)
HDD MAXTOR E-IDE 120GB 19,800円

(それ以前に，SDLTのドライブが698,000円するので個人利用にはだめぽ）
180 ：名無しさん＠お腹いっぱい。：02/08/04 10:43
>>174
HDD市場はやればやるほど赤字累積、採算割れ必至なんですけど。
ギリギリまで品質切り詰めたパーツ押し込んで、製品検査工程も大幅に省略して
安かろう悪かろう商売しているのが現状ですが？
少なくとも旨みのある市場なら企業がこぞって事業撤退するなんて有り得ない。
181 ：174じゃないけど：02/08/04 11:00
>>180
「おいしい市場」ってのは、そういう安いHDDを仕入れてきて、
箱に入れたりソリューションしたりすることなんだと思われ。
182 ：名無しさん＠お腹いっぱい。：02/08/04 11:59
>>179
> (それ以前に，SDLTのドライブが698,000円するので個人利用にはだめぽ）
これは各々の財源事情に起因することですよね。
金銭に余裕の無い人が「俺的には無理だ」と思うのは納得。

ただし「俺にとってナシなものは他人も同じだよな」な考え方は違うだろうと。
価格がハードルなら、それを十分クリアできる人も存在するわけだし。
183 ：名無しさん＠お腹いっぱい。：02/08/04 12:11
　　　　　　　微　　　　　笑　　　　　女　　　　　戦　　　　　士
　　　　　　＿　　　　　　　　　＿＿＿　　　　　　　　　　　　　　　＿
　＿＿＿/　/＿　　　　　　/＿＿＿/　　　　　　＿＿＿＿＿　（＿）　
/＿＿　　＿ _ 　/　＿＿　＿＿＿＿　＿＿　/＿＿＿　　　/ 　　　
　　　/　/　/＿/　/＿＿//＿＿　　//＿＿/　　　　　　./　/　　　＿　＿　　　　　＿
　　./　/＿＿　　　　　　　　　　/　/　　　　　　　　　　　/　/　　　 ＼＼＼＼　　／／　　　　　　　　
　../＿＿＿＿/　　　　　　　　/　./　　　　　　　　　　　/　/　　　　　￣　　￣ ／／
　　　　　　　　　　　　　　　　/＿/　　　　　　　　　　　/＿/　　　　　　　　　／／
　　　　 　!＼j＼　　　　　　　　　　　　　 .／　,､　☆　　　　　　　　　　　　　￣
　　　　　 ､＼＼＼　　　　　　　　　 　,.／/／/
　　　　　ヽ〈②〉.ヽ.＼＠ノノハ＠ ／ヾ／ .／/
　　　　 　 ＼ｰ＼＼／（　´,_ゝ｀）ヽ／フ-''"／　　　　月に代わってﾌﾟｯ
　　　　　　　＼ｰ､＼//ーヽ__/〉ヽヽ／フ､-'"　☆
　　　　　　　　ー／ 'ミ〉{｀ヽ_/;!｀.l=､ヽー''"´
　　　　　　　　／＞ｰ{ :＼￣`/!=|ー! |>"´
　　　　　　 ／/ー‐ノ_,,／!＼.〈.{. l｀`!. l-､_　　　　　　☆　　+　　
　　　　　/ ／　 ￣ー/'!､!ﾊヾ,､ゝヽ } .!
　　　　 /./　　　　　/. | ｀~i~´ l＼.>.| |
　　　　 { {　　　　.／　 l　 |　 /　 ＼ /
　　　　 ヽヽ　　／　　　l　|　/　　 //＼　　　☆
　　　　　　ヽ.／　　　　 }=|=〈　　／´ヽ ＼　　　　　　　　　　　　　　+
　　　　　 ＜/.　　　　　 | .|　 }/~´　　　l
　　　　　　/　　　　　　　| |　.j|　　　 　 ﾞ|　　　+　　　　　☆
　　　　　　 　　　　　　　 |. !　!　　　　　　`
　　　　　　　　　 　 　　ノ . |　.〉
　　　.　　　　　　　 　　ー''ﾞ.し'
184 ：179：02/08/04 12:46
>>182
たしかに。でも個人で70万円のSDLTドライブ買っている人いるのかなぁ。
居るかもしれないなぁ。一昔ならPCだってそれくらいの値段したんだし。
185 ：ていうか：02/08/04 12:50
月初や締め日ごとにバックアップ用のHDDが増えていくなんて
状況は割とゾッとしないっていうか。
検証用のデータをくれとか言うと、HDDが郵送されてくるなんて
様も割と勘弁して欲しいというか。
186 ：名無しさん＠お腹いっぱい。：02/08/04 13:25
20年くらい前ならメインフレームでHDの円盤取り外してバックアップ
する製品があったよね。その後も、リムーバルHDって製品群は細々と
存在していたわけで、HDDでバックアップってのもありなんじゃないかと。
187 ：名無しさん＠お腹いっぱい。：02/08/04 13:29
>>184
個人的主観だけど、仮にテープ装置に投資する場合、１ヶ月分の月収の範囲
20～30万円なら許せるかと思うです。この価格帯はDDS4, AIT-2, DLT1かな。
DLT1(非圧縮40G/圧縮80G)は30万くらいでありますから。

HDD容量(1台)>Tape容量(1本)はマルチボリュームで取るしかないけど
メディア交換の手間は目をつぶると言う事で。
188 ：なんにせよ：02/08/04 17:50





　　　　　　　　　　　テープは安くなる可能性がありません。




なぜなら、本体のコストが高すぎるから。
部品点数的に言って、HDDにまったく及ばない。
で、本体が高いからメディアも買わない。

本体だけで60万？(^Д^)ｷﾞｬﾊ!
HDDなら4T分買えるよ。
短期保存的には脱着・紛失の危険があるテープより遙かに上だし。
189 ：つーか：02/08/04 18:12
個人利用では HDD 最強だろう。TAPE装置買うには厳しすぎる。
一応個人で TRAVAN 持ってるけど、10GBにも満たない TAPEなんかにメリットはない。

ただ、業務利用ではもっと違うことになる。
履歴管理とか、システムとして落とせないマシンのデータを保管する場合、TAPE の方が利点が多い。
交換が用意だとか扱いやすいとか。

そもそも、HOTSWAP の HDD だからといって、ばんばん抜きまくるのって恐すぎないか?
どの時点で sync されてるかも分からないし、抜いた瞬間に書き込みが開始されたら壊れるだろ。
それに、そんな方法でやっていることをオペレータだとかにはとても運用引き継げません。

とにかく、個人と業務(それも規模によって) では話が違うんだから、その辺を明確にすべき。


TAPE最悪説を唱えるヤツは、SCSI最悪説を唱えるヤツと同じ様なきがしてきた。
190 ：名無しさん＠お腹いっぱい。：02/08/04 18:47
別にHDDをホットスワップしろとは一言も言ってないよ。
据え置き型で十分だろ。
必要時に電源を入れるとかすればいいだけ。
普段は電源切っておけばいいだけなんだからさぁ。紛失も皆無。
191 ：名無しさん＠お腹いっぱい。：02/08/04 18:50
>>189
さりげなく同意。

まぁ業務かどうかというより、どれぐらいシリアスか、ということだと
思うけど。
192 ：名無しさん＠お腹いっぱい。：02/08/04 18:52
むしろ、TAPE推進派はSCSI優越論者に近い。

なんていうか、１０年前に教わったことしか知らないただの馬鹿って感じ？
193 ：名無しさん＠お腹いっぱい。：02/08/04 18:57
あのなぁ、きょうび、1Tのストレージ用意するのにE-HDD7台で済む時代だよ？
もうね、アホかと。馬鹿かと。
194 ：名無しさん＠お腹いっぱい。：02/08/04 19:00
テープにしがみついてる奴は、現実を見たくないんだな。
哀れだが、そっとしておいてやろう。
首に縄つけてやるほど漏れ、親切じゃないしｗ
195 ：名無しさん＠お腹いっぱい。：02/08/04 19:11

エロ画像/動画のバックアップにテープなんて使ってられるか！！
俺はティンポ握ったらすぐにでもハァハァしたいんだＹＯ！！
196 ：名無しさん＠お腹いっぱい。：02/08/04 19:39
自分の目が届く範囲ならHDDで安く仕上げてもいいけどねー。
おしごとではなかなかそういうわけにもいかず。

>据え置き型で十分だろ。
それで十分なら、誰もテープなんか使いませんがなー。
197 ：んー：02/08/04 19:55
日々データベースのバックアップで、7世代で管理しなきゃいけない。
それもハードディスク７台でいちいち付け替えなきゃいけないんですか?
付け替える時って、ホットスワップでもなければ電源停止しないといけないよね?
もしホットスワップでディスク付け替えるとして、毎日そんなもの入れ替えるのって
危険すぎるよね?
それでもディスク推進するなら、いい方法教えてください。
198 ：名無しさん＠お腹いっぱい。：02/08/04 20:32
>>189
>そもそも、HOTSWAP の HDD だからといって、ばんばん抜きまくるのって恐すぎないか?
>どの時点で sync されてるかも分からないし、抜いた瞬間に書き込みが開始されたら壊れるだろ。

たしかに怖い．

私が使っている安物(<4万円)のホットスワップ可のRAID1ユニットには，
同期をオフにするボタンがあります．マニュアルにはいつ抜いても良いって
書いてあるけど，心配なのでいつも同期をオフにしてから抜いています．
199 ：名無しさん＠お腹いっぱい。：02/08/04 20:43
>日々データベースのバックアップで、7世代で管理しなきゃいけない。
>それもハードディスク７台でいちいち付け替えなきゃいけないんですか?

馬鹿丸出しｗ
噛付き厨ってペスト持ってるから触らんとこ。
200 ：名無しさん＠お腹いっぱい。：02/08/04 20:50
興味ないから投げやりに書くが、IDE RAIDで定期的な抜き差しはやばいだろ。
でもUSB storageならdetachできるんじゃねーの?
201 ：名無しさん＠お腹いっぱい。：02/08/04 20:55
FreeBSDならatacontrolでIDEをdetach/attachできる罠
202 ：名無しさん＠お腹いっぱい。：02/08/04 20:57
で、それは安定的に正しく機能するのか? という話なのだが。
203 ：名無しさん＠お腹いっぱい。：02/08/04 21:00
何か
・現状でもHDDが最強
・将来的にはHDDも有望
・(現状だけ見て)HDDなんて使えない
が入り乱れてて議論がびみょーにかみあってない気が。
204 ：名無しさん＠お腹いっぱい。：02/08/04 21:06
つーかテープだけで RAID 使ってないなんて不自然だし、
全銀とかのシステムのバックアップが HDD だけってのも相当不自然。
205 ：名無しさん＠お腹いっぱい。：02/08/04 21:07
噛み合わせる気もないしな。
俺はにゅ～テックがバックアップ用リムーバブルHDDを発売するまで
テープ使うヨ…
206 ：名無しさん＠お腹いっぱい。：02/08/04 21:11
不自然＝思い込みを正当化する言い訳
207 ：名無しさん＠お腹いっぱい。：02/08/04 21:19
・安全なattach/detachをどうするか。
・安全な物理的移動をどうするか。
・ファイルシステムの選択をどうするか。
・IDE RAIDの場合、将来コントローラが変わっても読み込みできるのか。
・USBやIEEE1394接続の場合、ちゃんと安定して動くのか。

あんまり考えたくないので、後は若い者にまかせた。
208 ：名無しさん＠お腹いっぱい。：02/08/04 21:24
>>188
>テープは安くなる可能性がありません。

とはいってもビデオデッキが１万円以下で売られているのを
見ると，需要さえあればなんとかなるんではと思う．
209 ：名無しさん＠お腹いっぱい。：02/08/04 21:30
>>２07
>・IDE RAIDの場合、将来コントローラが変わっても読み込みできるのか。

私が使っているハードウェアRAIDは，単体でIDE HDD使うのとまったく同じ書き
込みをするので，たとえば起動パーティション含めてRAIDに入れていれば，
取り出したIDE HDDをマザボードに直接つなげばブートするそうです．
210 ：名無しさん＠お腹いっぱい。：02/08/04 21:32
業務用と個人使用がごったに煮なっているのも議論がかみ合わない
理由の一つかも．もし110GB DLTドライブが数万円なら，個人でも
テープ使いたいと思います．
211 ：名無しさん＠お腹いっぱい。：02/08/04 21:39
テープデバイスなら、バックアッププロセス全体をちゃんと機能させる方法は
経験からわかってるんだけど(そもそも、それ目的で作られてるものだし)
HDDは
>私が使っているハードウェアRAIDは
というようなことを一つ一つ検証して、確実に動くプロセスを自力で作って証明しないと
いけないから、趣味だと楽しいんだけど、業務で使うのは難しいのです…
212 ：名無しさん＠お腹いっぱい。：02/08/04 21:42
つまり、どこぞのメーカーがHDDをカートリッジにつめこんで、それを今の
テープを同じようなオペレーションで運用できるような感じで販売して
くれればいいっつーことか。
商品企画としてはすでに進行してるような気がする。
213 ：名無しさん＠お腹いっぱい。：02/08/04 21:44
>>212
それ欲しいかも。自前で NFS しゃべるといい?
214 ：213：02/08/04 21:46
RJ-45 を差して IP 設定するだけ、みたいなイメージで。
でもバックアップ用途に使うにはもったいないような気がしてきた。貧乏性?
215 ：名無しさん＠お腹いっぱい。：02/08/04 22:08
いや、HDDだからってファイルシステム載せなきゃいけないってわけでもないでしょ。
テープと同様、だーっと生データ書き込んじゃえばいい。
216 ：名無しさん＠お腹いっぱい。：02/08/04 22:10
ナマってわけにはいかないだろ。
なんかレイヤ一個載せないと、終わりがわかんないじゃん。
217 ：名無しさん＠お腹いっぱい。：02/08/04 22:14
>>215
やっとまともな話になったね。
HDD=ファイルシステム
とかいう思い込みで話をしてもしょうがないわけさ。
HDDをrmtとして使うとか、いくらでも工夫はできるよね。
218 ：名無しさん＠お腹いっぱい。：02/08/04 22:19
… Unix板にも ID 導入しようよ～。ねぇ～。
219 ：名無しさん＠お腹いっぱい。：02/08/04 22:24
>>218
IDに頼らないとスレが読めないのか？
220 ：名無しさん＠お腹いっぱい。：02/08/05 00:07
HDD にファイルシステム載せないとどういうメリットがあるんでしょ
うか。
たとえば、
ufsdump 0f - /dev/rdsk/c0t0d0s1 | rsh backuphost "dd of=/dev/rdsk/c0t0d0s2"
とかやって幸せなことって、ファイルシステムの制限
(ファイルサイズの上限とか)を気にしなくていいこと？

221 ：名無しさん＠お腹いっぱい。：02/08/05 00:11
RAIDの話題が出た時点で話の流れが怪しくなり(w HDD一択な御仁が
他の選択肢を認めることができずモツレタわけですな。
多様性があったほうが世の中楽しいと思うのですが・・・
了見がせまいのでしょうか？
222 ：名無しさん＠お腹いっぱい。：02/08/05 00:33
つーかさー。
wolでネットワークでFreeBSDでNFSでソフトRAID。

あー。もう答え言っちゃったようなもんだー。
223 ：名無しさん＠お腹いっぱい。：02/08/05 00:35
>>219　自作自演の芳しい香りがﾌﾟﾝﾌﾟﾝするからじゃない？
224 ：名無しさん＠お腹いっぱい。：02/08/05 00:46
>>220
ファイルシステムの層が噛むと、メタデータがどうしたとか、
面倒ががつんと増えるでしょ。「ああ、こりゃ面倒だ」って
ぴんとこない人は、いいです。
225 ：名無しさん＠お腹いっぱい。：02/08/05 00:47
>>223
じゃ、＝でつないでみてくれる？
226 ：名無しさん＠お腹いっぱい。：02/08/05 08:22
俺はラトックのドライブケース使ってるけどどーよ。
ttp://www.rexpccard.co.jp/products/subpage/dk.html
227 ：名無しさん＠お腹いっぱい。：02/08/05 09:35
>>226
かなーりイケてるんじゃない？
っていうか漏れも使いたいぞ。
228 ：名無しさん＠お腹いっぱい。：02/08/05 11:11
>>226
もう5,000円払えばRAID1にできるよ（内蔵だけど）
製造元のページ見るとIEEE1394外付けもあるらしい．

ttp://online.plathome.co.jp/cgi-bin/category.phtml?parent=7091&rows=1&append=7091&kitem=1184055900009&vitem=1&details=1
229 ：名無しさん＠お腹いっぱい。：02/08/05 11:15
単なる内蔵RAIDならACS-7500が21,800円で買えますが?
つか、漏れこれ使ってるし。
230 ：名無しさん＠お腹いっぱい。：02/08/05 11:39
>>229
それは安い．IntelliMirror ACS-7500とARRAID99-1000の違いは，
サポートするHDDの最大容量が，75GBと160GBという程度のようですね．
(ARRAIDにはかっこいい液晶パネルがついていますが:-))
231 ：名無しさん＠お腹いっぱい。：02/08/07 00:47
>>199
複数のメディアに分けて保存するという意味...わかってますか?

ひょっとしてRAID組んで、そこに７世代分を保存していけばいいと思ってますか?
その場合に考えられる欠点
・RAIDだとコントローラに異常があると全滅
・HDDが複数台壊れると全滅
・雷でHDD基板が死ぬ
・誤操作/バグ/クラックなどでrm/newfs/format(fdisk)に相当するものがかかって全滅

RAIDではなく、HDD 7台を付け替えれば
上の現象って回避できますよ

んで、HDDだとあり得るけど、Tapeだと無いことで
・誤操作/バグ/クラックでバックアップしたファイルが後天的に一部だけ書き替わってしまうということが無い
テープだと部分的に消すってのは難しいからね
232 ：名無しさん＠お腹いっぱい。：02/08/07 02:00
>>231
FireWireで組むとか、使わないとき電源抜いておくとかで対処できるだろ。石頭。
233 ：名無しさん＠お腹いっぱい。：02/08/07 02:31
>>232 おまえいつもくさいな
234 ：名無しさん＠お腹いっぱい。：02/08/07 05:46
>>232
局所的な物言いしかできないのかい？　大局的な視野が無いのか・・・
235 ：名無しさん＠お腹いっぱい。：02/08/07 07:38
>>234
所詮小さな世界しかしらんのだろ。
236 ：名無しさん＠お腹いっぱい。：02/08/07 10:50
>>231
ねえ、これ、本気なの？
だとしたら、商売変えたほうがいいよ。
鼻からGNU噴き出しちゃったよ。
237 ：名無しさん＠お腹いっぱい。：02/08/07 11:18
>>236
どーでもいいがｵﾏｴ、
> 鼻からGNU噴き出しちゃった
を書きたいだけだろ。
238 ：名無しさん＠お腹いっぱい。：02/08/07 11:34
>>237
とっくに使い古されたせりふだろ。

重要なのは、>>231の勘の悪さだな。
こじつけようとするのはかまわんが、
材料が少なすぎるし組み合わせも悪い。
239 ：名無しさん＠お腹いっぱい。：02/08/07 11:53
弊社もテープなどという前時代の遺物は廃棄し、
コストパフォーマンスに優れたHDDによるバックアップシステムを採用したいので、
機器の選定と設定および運用の詳細について文書にまとめて公開して下さい。
OSはFreeBSD4.x-STABLEでおながいします。
ちなみにサーバは止められまへん。あとメディアは社長が家に持って帰りますので
その旨よろしくです。
240 ：うひひ：02/08/07 12:18
>>239
モータ屋なら耐火金庫買って地下に埋めないと危険
241 ：名無しさん＠お腹いっぱい。：02/08/07 12:53
>>239
自分で汁
242 ：名無しさん＠お腹いっぱい。：02/08/07 16:37
秋葉原のワークステーション系中古屋のぞいたら，
DDS4(20/40GB)の中古ドライブを39,800円で売っていた．
Super DLT(35/70GB)の中古ドライブは79,800円だった．
個人でも買えなくはないなと思った．
(SGI O2 (R10000)は32,000円だった）
243 ：名無しさん＠お腹いっぱい。：02/08/07 17:17
中古でテープドライブというのもちぐはぐ感があるな。
信頼していいやらわるいやら。
244 ：名無しさん＠お腹いっぱい。：02/08/07 17:53
ドライブ類だけは中古では買わないようにしてる。
ワークステーションとかパーツ類とかは
中古で今までにたくさん買いまくったが、、
245 ：名無しさん＠お腹いっぱい。：02/08/07 17:56
回りモノの中古には手を出すな、これ鉄則。
遊びで使うなら話は別だが。
246 ：名無しさん＠お腹いっぱい。：02/08/07 19:20
>>231
あんまり特殊例の話を力説されてもみなの役にはたたないです。
247 ：名無しさん＠お腹いっぱい。：02/08/07 19:22
>>239
これいいとこついてると思うのよ。逆説でしょ?

勤務先とか、金か責任もって質問してくる相手に 時に、 RAID1 ユニットとベア
ドライブ買ってこいなんて言えんでしょう。そうゆうのは、トラブルを楽しみつつ
解消できる個人ユース、パフォーマンス最優先の特殊な場合だけでしょう。

というわけで、やや obsolete になりつつある現状でも。十分枯れてて、無難
であるという点をもっと評価すべきと思いまーす。
248 ：名無しさん＠お腹いっぱい。：02/08/07 19:26
>>247
逆に聞きたいんだけど、客が得意気に
「ミラーしたディスクを保存してバックアップする
　てのやってみたいんだけど、どう?
　いいアイディアでしょ?」
って言ってきたらどう返す?
249 ：名無しさん＠お腹いっぱい。：02/08/07 19:31
>勤務先とか、金か責任もって質問してくる相手に 時に、 RAID1 ユニットとベア
>ドライブ買ってこいなんて言えんでしょう。

思い込みで商売が続くと思うならそうすればいいんじゃない？
大丈夫、それに見合うレベルの低い客がつくよ。
250 ：名無しさん＠お腹いっぱい。：02/08/07 19:43
マジメな話、今オンラインのまま1万回以上脱着可能な
ハードディスクインターフェースってあるの?
251 ：名無しさん＠お腹いっぱい。：02/08/07 19:56
>>250
1万回テープを脱着可能なテープドライブも存在しないと思うが?
つまり、1万回もの寿命は必要無いんじゃない?
252 ：名無しさん＠お腹いっぱい。：02/08/07 19:56
>>248
相手によるでしょうとしか。わかっててやってるんなら有用かも。わかって
なさそうだったら、余計トラブルのタネをまくことになるかもしれませんよ、
ぐらい言う。

いわゆる RAID1 ユニット定量的な評価、ぶっちゃけ、どれぐらいの
頻度での交換を想定してるのか、について誰か文書持ってない?
これがわかればこのスレ発展しそうだけど。 HDD 万歳のひとチャンスですよ?
僕もちょっとあたってみます。

>>249
御意見謹聴。今後の参考にさせていただきます。末尾ながら、貴君のますますの
御活躍を心よりお祈り申し上げます。
253 ：名無しさん＠お腹いっぱい。：02/08/07 19:58
結局、枯れてるものは良いけど高い、高いけど良いって事かいな。
254 ：名無しさん＠お腹いっぱい。：02/08/07 20:31
>いわゆる RAID1 ユニット定量的な評価、ぶっちゃけ、どれぐらいの
>頻度での交換を想定してるのか、について誰か文書持ってない?

自分が何言ってるのかわかってるのかね？こいつ。

>これがわかればこのスレ発展しそうだけど。 HDD 万歳のひとチャンスですよ?
>僕もちょっとあたってみます。

意味のない数字を持ち出してもスレが腐るだけだっつの。
255 ：名無しさん＠お腹いっぱい。：02/08/07 21:10
　　　　 ∧＿∧　　／￣￣￣￣￣￣￣￣
ﾋﾟｭ.ｰ　（　・∀・）＜　落ち付けッ
　　＝〔~∪￣￣〕　＼＿＿＿＿＿＿＿＿
　　＝ ◎――◎
256 ：名無しさん＠お腹いっぱい。：02/08/08 00:27
>>254
ホワイトペーパーでももらえばいいんでないの。あとおまえも何言ってるのか
わからない。具体的にプリーズ
257 ：名無しさん＠お腹いっぱい。：02/08/08 01:05
ホワイトペーパーだってさ。必死だね。

ものごとをすぱっと見抜けない間抜けが
数字をいじくりまわしてこじつけようとするわけだ。
せいぜい頑張ればいいんじゃない？
258 ：名無しさん＠お腹いっぱい。：02/08/08 02:14
このスレに意見を書き込んでる人数、2～3人ってトコか…
259 ：名無しさん＠お腹いっぱい。：02/08/08 02:27
ウニクス板ならよくあることさ。
260 ：名無しさん＠お腹いっぱい。：02/08/08 02:36
んなこたぁ、ねえだろ
まぁ、IDE-RAIDだHDDだと小うるせぇ自作厨っぽいのは1人だろうけどな
261 ：名無しさん＠お腹いっぱい。：02/08/08 10:20
お前ら！ デイリーバックアップと大容量アーカイブを一緒に話していませんか？
262 ：名無しさん＠お腹いっぱい。：02/08/08 10:23
>>261
簡潔に違いを書いてよ。
263 ：名無しさん＠お腹いっぱい。：02/08/08 16:06
>262
2日に1回ならデイリーとは(以下略)
264 ：名無しさん＠お腹いっぱい。：02/08/08 16:07
DDS3・4の選択で迷ってます。
厨な疑問ですが、バックアップ装置の容量フルに入りますか？
バックアップソフトによっても違ったりするものでしょうか？
SPECに書かれてる容量は、HDD上のサイズと同じ？
265 ：よこよこ：02/08/08 16:19
UNIXに詳しい皆さんに質問します。
UNIX上でソースファイルをコンパイルする時、ソースファイルの中に<math.h>
というヘッダファイルがあれば -lmと打ち込む事は知っているんですが、
<conio.h>というヘッダファイルがある時にはどうすればよいのでしょうか？
誰か知っていれば教えてください。お願いします。
266 ：名無しさん＠お腹いっぱい。：02/08/08 16:28
>>265
きっと前任者がコンパイルしたバイナリがどこかにあります。
バックアップしたテープから探してください。
267 ：261：02/08/08 17:14
>>262
バックアップは日々更新されるデータを過去に遡って復旧可能にする。
アーカイブは変更の無いデータを長期保存する。
くらいに考えてますが間違ってますか？

>>264 非圧縮なら容量フル。圧縮はデータの内容によって圧縮率が違う。
268 ：名無しさん＠お腹いっぱい。：02/08/08 18:08
煽り登場の予感
269 ：名無しさん＠お腹いっぱい。：02/08/08 18:34
煽る要素がないと思われ
270 ：名無しさん＠お腹いっぱい。：02/08/08 22:05
DDSって、あのヘッドが斜めに付いてる奴?(ぷっ
271 ：名無しさん＠お腹いっぱい。：02/08/08 22:10
いまどき回転ヘッド。
しかも、接触記録。
低容量。低速。
272 ：264：02/08/08 23:09
>>267
ハードウェア圧縮は考慮してません。無きものとして検討してます
実際のところ容量フルに書いたことあります？誤差が気になるんですが。

>>270 >>271
予算10万ですが、何か？
273 ：名無しさん＠お腹いっぱい。：02/08/09 00:01
>>270
わかったよ。じゃあ、 QIC-150 にするよ。
あのテープ頑丈だし、見ためにも安心感がある。
何本要るかしらないけど・・
274 ：名無しさん＠お腹いっぱい。：02/08/09 02:34
>>270
斜めだからなんだっつんだよ。おまえほんとにわかってるのか?
275 ：名無しさん＠お腹いっぱい。：02/08/09 02:49
メディア高くて容量小さくておせじにも高速と
は言えないけどカコイイから買ってしまったDVDの
話題が少ないのはなぜ？
276 ：名無しさん＠お腹いっぱい。：02/08/09 03:38
メディア高くて容量小さくておせじにも高速とは言えないから
277 ：名無しさん＠お腹いっぱい。：02/08/09 03:59
>>248
HDDは長期保存性に問題がありますので、長期保存にはテープなど他のメディアを
使用する必要があります。
また、基本的に取り外しを頻繁に行うようには設計されてないので、保証外の
使用方法になりますので、サポートは受けられません。

と言えばいいよ。大抵これで黙る。
黙らないならほっときゃ良い。責任はむこうもちにして逃げろ。
278 ：名無しさん＠お腹いっぱい。：02/08/09 04:12
きょうび、「高いから、テープは金かけて作ってるんだー」「品質が高いから
高いんだー」とかキティじみた事言ってる奴は居ないと思うが、あえて言うと、
単に売れないから開発費回収するために高いんだよ。
HDDは量が掃けるから、一個あたりの開発費分を小さくできる。それに、コントローラー
はある程度共通性があって、量産が可能だし、使い回しもできる。
テープだって工場はきょうび中国や台湾やマレーシアなんだから品質はどっこいどっこい。
単に出荷時の検査態勢の質と、製造工程の問題に過ぎないし、殆どアウトソーシングが
普通なんで、何処までブランドが通用するんだかって話だ。
国産といえど、高い公共料金対策で、検査工程をケチったり、ライン設備投資をケチったり
すれば、外国産と同レベルかそれ以下に転落するというものさ。

工業ってのは気持ちじゃない。腕なんだよ。実質なんだよ。
279 ：名無しさん＠お腹いっぱい。：02/08/09 04:30
cpioだとなにがうれしいの?
280 ：名無しさん＠お腹いっぱい。：02/08/09 06:49
ビット単価がいくら安くても、運用に必要な要件を満たさなければ
実質的にHDDはバックアップには使えないのですが、何か?

別にHDDがダメだっつってんじゃないんだよ。
お前さんの切れる頭でここはひとつ、
HDDでの運用を可能にするバックアップスキームを考えてくれよ。頼むよ。

「据え置きにすればいい」なんてのは寝言にしか聞えんよ。
オリジナルと同じ場所にあるバックアップって一体なんなんだ。
281 ：名無しさん＠お腹いっぱい。：02/08/09 06:52
>>278
HDD事業は低価格競争によるサバイバルゲームと化してますが？
IBMがHDD部門を日立に売却することで合意に達したそうですよね。
QuantamがMaxtorにHDD部門売却したことは記憶に新しいですよね。
Seagateだって投資家グループの共有事業になって久しいですよね。
収益性の高い事業なら、なぜ売却せねばならないのでしょうか？

生産拠点を第３世界に移した製品が品質を維持できているとでも？
282 ：名無しさん＠お腹いっぱい。：02/08/09 07:08
>>278
HDD の相対的な品質が低下したかどうかと、バックアップにHDDを使うのが
リーズナブルであるかどうかは関係なくないか

と中国で作ると品質低いって決めつけあり？ (話題がそれていくー
283 ：名無しさん＠お腹いっぱい。：02/08/09 07:42
想定している規模やバックアップの重要度を明らかにしないまま
議論していて、まったくかみ合っていないように見える。

俺は、大規模災害時の復旧を考えないバックアップなら、仮想
テープライブラリをHDDで構築して、そこに取るのもかまわんと思う。
バックアップ結果を遠隔地に輸送して保存する必要があるんなら、
やっぱりテープだろ。

…ていうか、そろそろ子供たちの目が点になってるだろうから、
ハイエンドのほうに移動したほうがいいではないかな？
284 ：名無しさん＠お腹いっぱい。：02/08/09 07:50
子供たち晒しあげ。でも #1 なので意味無し。がっかり。
285 ：名無しさん＠お腹いっぱい。：02/08/09 08:00
>283
晒しあげついでに同意しとく。
だけど、バックアップみたいなのは、いろいろ個別の
事情があるだろうし、程度だってピンからキリまで、
しかもそのキリの高みはとてつもない
# んでしょ? わかんないけど。大規模災害を想定っていわれても

だから、ある程度はやむを得ないんじゃないのとか。
わたしは十分勉強になってる。煽られた時は腹立った
けど。相手が違うって
286 ：名無しさん＠お腹いっぱい。：02/08/09 15:16
バックアップ結果を遠隔地に輸送して保存する必要があるんなら、
HDDを抜いて持っていけばいいのよ。
RAIDとかFireWireってのはまさにそういう話なんだけど、読めてないね。
まあ、いいんじゃない？
2chはその程度だよね。
287 ：名無しさん＠お腹いっぱい。：02/08/09 15:22
>>286
>>79
見事にループしてるな。
288 ：名無しさん＠お腹いっぱい。：02/08/09 15:26
>>286
糞スレあげるんなや、カス。
289 ：名無しさん＠お腹いっぱい。：02/08/09 15:48
IEEE1394デバイスってもう繋がるの?
290 ：名無しさん＠お腹いっぱい。：02/08/09 16:25
>>287
そうなんだよね、馬鹿ばっか。

>>288
おならﾌﾟｰage
291 ：名無しさん＠お腹いっぱい。：02/08/09 16:46
>>289
「もう」とは？
292 ：名無しさん＠お腹いっぱい。：02/08/09 16:49
>>286
そんなに自分の間抜けっぷり晒してどうしたいのよ？（ｗ
293 ：名無しさん＠お腹いっぱい。：02/08/09 16:57
もう繋がるのか、
まだ繋がらないのか。

「繋がる」というのは「安定的に運用できる」という意味で。
294 ：名無しさん＠お腹いっぱい。：02/08/09 16:57
>>286
ここでRAIDが出てくるのがわけわからん。
引き抜いて送るんなら必要なのは活性抜挿であってRAIDじゃない。
それとなぜFireWire？ Fibre Channelでいいじゃないか。
ひょっとして283の言うところのお子様か？
295 ：名無しさん＠お腹いっぱい。：02/08/09 17:07
で、振り出しに戻るってか？
これまでの要点くらい押さえとけよ。
それができんからスレが続くのか。
296 ：名無しさん＠お腹いっぱい。：02/08/09 17:17
>>293
「安定的に運用できる」は主観的な判断だよね。

>>294
例に噛み付いてもしょうがないんじゃない？
297 ：名無しさん＠お腹いっぱい。：02/08/09 17:54
飽きたからもういいよ
298 ：名無しさん＠お腹いっぱい。：02/08/09 17:55
>>171 >>292
どうも、「晒す」とか「黙ってろ」とかの語彙を好む人物が
ひとり（多分同一人物）居るようだね。
きっと、テープ屋かそれ関係の工作員なんだろうね。
299 ：名無しさん＠お腹いっぱい。：02/08/09 22:07
　
　
　
　
　
　
　
　
　　S　e　a　g　a　t　e　工　作　員　必　死　だ　な　（藁

　
　
　
　
　
　
　
　

　
　
　
　
　
300 ：名無しさん＠お腹いっぱい。：02/08/09 22:52

　　　　　　ヽ￣￣ﾞ＼
　　　　　　　＼　　ヽ ＼
　　　　　　　　 ヽ　　　　ﾞ!　 ／￣￣￣￣￣￣￣
　　　　　　 　 　/　 　 　 |＜　300げっとずさー
　　　　　　　／　　　　 ,.ｲ　 ＼＿＿＿＿＿ 　　　　　　　　　(⌒;:)
　　　　　 ∠＿＿＿／　:|｀ヽ.、　　　　　(⌒　:::..ヽ　　(⌒::;
　　　　　　　 　 ﾉ　　　 　'!　　 ＼-､( ⌒Ｙ:: : : :::::..;;:: j
　　　　　＿,.=''1　　　　　 ヽ,　 　...;:::/...:::　:　:⌒￣""⌒ヾ
　　　 　 ヽ'"　i|　　　　: :::.....:: ::: ::／:::　;　":￣　　　　　　　::)
　　　　　　　　 !　　　　　　,,..:;::::;::::::／:'（: : :　;;:;:　　　　⌒　⌒)
　　　　　　　 　　　　　　　ノ.....:::;::::／;:/:::::::::ノ;;::::::;　:　　...　....::::ﾉ
　　　　　　　　　　　￣￣￣'￣""￣" "　￣￣￣"'"" ￣￣￣"
301 ：名無しさん＠お腹いっぱい。：02/08/09 22:57
301記念age
302 ：名無しさん＠お腹いっぱい。：02/08/10 00:56
＞>>171 >>292
＞どうも、「晒す」とか「黙ってろ」とかの語彙を好む人物が
＞ひとり（多分同一人物）居るようだね。
＞きっと、テープ屋かそれ関係の工作員なんだろうね。
303 ：名無しさん＠お腹いっぱい。：02/08/10 08:57
>>302
スレを駄目にしてるのはこういう粘着だな。
304 ：名無しさん＠お腹いっぱい。：02/08/10 09:47
1.スナップショット退避が可能な構成でRAID組んで、
スナップショットしたものをufsdump/ddでテープにとる　テープは正・副２セットとる
　スナップショット機能は、ちょっといいアレイ装置なら大抵ついてる
　OS部分は、Solarisであればスナップショット機能あり

2.テープをとり終わったら、正・副２セットをデュプリケーターでさらに倍にふやして
　（コピーした正）＋（もとの副）を妻帯センターへ運送する
　（もとの正）＋（コピーした副）は自センターに保管　熱と湿気と紫外線はあてないようにすること

3.専用線ひいて妻帯センターに業務データっぽいところをぶちこむ
　ぶちこみかたは等価性をどの程度保つかによってさまざま
　（RDBMSのレプリケーションもあるだろうし、SAN連携もあるだろうし、データファイルアーカイブを送るだけもあるだろう）

1.+2.+3.がいまのところ24h365日でも最強な（災害対策＋メディアリカバリ＋アーカイビング）バックアップ

システムランタイム/システム設定ファイル/システムログ
業務ランタイム/業務設定ファイル/業務ログ/業務データ
程度の色分けは最低でもやっておくこと
（ボリュームの分けかたにそういうポリシーが反映されてるとなおよし）
そうしないとバックアップリカバリ仕様を詳細化できない

305 ：名無しさん＠お腹いっぱい。：02/08/10 09:55
妻帯センター萌え
306 ：名無しさん＠お腹いっぱい。：02/08/10 22:00
>>304
大人だ…
307 ：名無しさん＠お腹いっぱい。：02/08/11 22:00
>>304
Solarisのsnap機能っていつからサポートだっけ...
ふむ...Solaris8 HW1/01からか...
http://docs.sun.com/?l=ja&p=/doc/816-0113/6m6kenfj6&a=view

それはさておき、うちのシステム(Solaris)の場合
システムランタイム/システム設定ファイル:
　セットアップ時にufsdumpでバックアップし、別ディスクにリカバリできることは確認
システムログ:
　バックアップ無し
業務部分:
　週１フルバックアップ、その他は増分バックアップ
308 ：名無しさん＠お腹いっぱい。：02/08/14 08:13
>>307
そこで問題はメタデータ的なもので管理するもの
（RDBMSのディクショナリとデータ領域との関係とかDISK Suiteみたいなの）

こいつらをどー取り扱うか、、、、
RDBMSはRDBMSの機能でバックアップするっきゃないかなとおもうんだけど、
DISK Suiteの構成DBとかはみなさんどーやってるのかしら
（漏れは諦めて、ufsfdumpしか取ってない）
309 ：名無しさん＠お腹いっぱい。：02/08/14 08:40
大学の研究室で、
PC-UNIXで50万位のシステム(というかPC)を組むことになりました。
nfsでhomeを提供するのがメインの役割になると思うのですが、
みなさんならhomeを何で(広い意味での)バックアップしますか？

センセはできることなら20~30万くらいに抑えたいらしいです。
例えば、SCSI-RAID array + DTL なんか使ったら
それだけで100万円くらいっかってしまうと思いますので無理です。

とりあえず、IDE-Hardware RAID1 と
(SCSIかUSBの外付けドライブ+(CD-RW | DVD[+-]RW)
で見積もりを出してもらっていて、
だいたい30-50万くらいになりそうです。

どうしたら良いかセンセに相談されたのですが、みなさんなら、
こういう個人の趣味PCよりは金もかけられるけど多少の信頼性が欲しいシステム
の場合どうしますか？
(個人の趣味で、もっと金つかってる人もいるとは思いますが。)
310 ：名無しさん＠お腹いっぱい。：02/08/14 11:21
研究室のhome にしては予算安すぎ。
もっとかけられるだろ。
311 ：名無しさん＠お腹いっぱい。：02/08/14 12:36
>>309
RAIDいれときゃ値段の割には悪くない、って程度でいいんじゃないの？

>>310
頭悪いね
312 ：名無しさん＠お腹いっぱい。：02/08/14 12:45
大講座制に移行するからか助教授の先生の個人持ちで、
利用者として多分5~10人くらいしか考えてないような状態なんですけど、
それでも100万くらいはかけといたほうが良いのですかね。
313 ：309：02/08/14 12:49
>>312 は >>309です。

>>311
50万くらいの価格帯でできることって、このくらいですよね。
314 ：名無しさん＠お腹いっぱい。：02/08/14 12:58
pdumpfsがバージョンアップ。
個人で使うだけだからこれで十分。
何回救われた事だか。
315 ：311：02/08/14 15:41
>>313
そそ。
無闇に金かけて余計な手間を増やすより健全と思われ
316 ：ひよこ名無しさん：02/08/14 15:42
激しく(´_ゝ`)ﾌｰﾝなホームページ
http://www.ogaki-tv.ne.jp/~zeus/
317 ：名無しさん＠お腹いっぱい。：02/08/14 19:07
DVD[+-]RWはやめたほうがいいんじゃないかなあ。
318 ：名無しさん＠お腹いっぱい。：02/08/14 19:14
>>317
どこに対する返事？

そもそも、DVDでバックアップできる大きさのシステムって...
（JukeBox の話じゃないよね？）
319 ：318：02/08/14 19:16
すまん
見落としてた。
309ね。
320 ：318：02/08/14 19:28
最悪、DVD系ならRAMでしょ。
デフォルトでベリファイするし、交替あるし。
でも、何枚もとっかえひっかえするの、悪夢では...?

もう１セットRAID用意してそっちにコピーした方がお手軽でいいかも。
＃厳格なバックアップ（記録媒体と再生機構が同一になっていない
＃とか、保存性が云々とか）が要求されてるわけじゃなさそうだし...
321 ：309：02/08/14 23:22
>>318
記録可能 DVD or CD は、ごく一部の重要なデータの長期保存用のつもりでした。
書かなきゃわかりませんよね。スミマセン。

それぞれ、主となる役割としては
IDE-RAID1 メインのハードディスクの故障対策
外付けHDD 操作ミス等の対策に1週間単位で2,3セットの(部分)スナップショット
CD or DVD メールや重要なデータなど、絶対に消したくないデータの5-10年程度のオーダでの保存用
を考えていました。

ちなみに、 DVD系ってPC-UNIXでどの程度使えるのでしょうか？
具体的には、Debian GNU/Linux3.0 + kernel-2.4.18 or 19での運用を考えているのですが。
要はUDF file systemがマトモに使えれば良いのか。
322 ：名無しさん＠お腹いっぱい。：02/08/15 00:38
IDEの５４００rpmのHDDやSAN等が同居してておもしろいスレだ。
323 ：名無しさん＠お腹いっぱい。：02/08/15 01:39
Linuxローカルな話ですが、Software-RAIDでRAID1構成にして

　・週に数回raidhotaddで同期
　・同期後はraidsetfaultyで壊れたことにして片方切り離し
　・切り離したHDDは同期後・起動直後にhdparmで停止

してやってます。毎回のフルダンプもUDMA33ですが40GBを一時間ほどで
バックアップ完了できるのと、間違ってファイルを消しても切り離した方
からmount -o roですぐ復活できるので重宝してます。

まだ二台構成なので同期中に何かあるとまずいですが、調子よいので次から
三台にして、常に一台を停止状態にして安全確保しようかと考えてます。
火事等には無力ですが、世代バックアップになっていることと、各ディスクの
使われ方が異なるのでrm -frやディスククラッシュには結構強いんじゃないかと
思いますが、どうでしょう？バックアップに凝ってる人のツッコミ求む。
324 ：名無しさん＠お腹いっぱい。：02/08/15 19:22
>>323
software raidってのがどうもなあ。
ハコとして切り分けの見えてるhardware raidのほうが好み。
325 ：名無しさん＠お腹いっぱい。：02/08/15 19:59
>>323
rsync とかでミラーリングするのと比べてメリットが見えんなぁ。
>>324
ソフトウェア RAID を単なるミラーリングツールとして使ってる
わけだから、それは的外れな感想だな。
326 ：名無しさん＠お腹いっぱい。：02/08/15 20:38
>>324は好みの話をしてるんだろ。
的外れなのは>>325だな。
327 ：名無しさん＠お腹いっぱい。：02/08/15 21:00
>>321
俺も気になってる。LinuxでDVD-RAM使いたい。
UDFはだいじょうぶなのか？
バックアップだけに信頼性が欲しいからなー。
328 ：名無しさん＠お腹いっぱい。：02/08/15 21:16
>>327
ぶっちゃけた話、まだまだ。
ext3fsかなんかで使うほうがずっとましだろう。
329 ：名無しさん＠お腹いっぱい。：02/08/15 21:58
>>328
じゃLinuxじゃなくてもいいんだけど高いドライバは買いたくない。
なんか無い？
330 ：名無しさん＠お腹いっぱい。：02/08/15 22:55
>>329
ないものねだりしてもしょうがないよ
UDFがこなれてくるには
まだまだ時間かかるんじゃない？
331 ：名無しさん＠お腹いっぱい。：02/08/15 23:20
エンタープライズのバックアップじゃなくて厨房のバックアップね
カセットテープで十分だろ
332 ：名無しさん＠お腹いっぱい。：02/08/15 23:25
今時テープのバックアップは時代遅れ。
基本はＲＡＩＤ。しかしこれも電源共有してたらダメだし、それより
地震で地域全滅したらダメだから地理的に離れた所のマシンにrsyncして
バックアップを取る。
333 ：名無しさん＠お腹いっぱい。：02/08/15 23:45
このスレは何回ループすれば気がすむのでしょうか?
334 ：名無しさん＠お腹いっぱい。：02/08/21 21:51
テープバックアップでひどい目にあった人いる？
特に、LTOとかの高もん規格で（笑）
さすがにそういうのでは、DDSみたいなテープぶち切れとかはないのかな？
335 ：名無しさん＠お腹いっぱい。：02/08/21 23:41
それより、バックアップ用でおすすめのテープ規格はなに？
MAX 1TB くらいで。
336 ：名無しさん＠お腹いっぱい。：02/08/21 23:53
んなもんねーよ。
337 ：名無しさん＠お腹いっぱい。：02/08/22 21:53
SDLTとLTOが切れた事なんてないね > 334
4mm/8mmと同じにしないで(つか同じだったら悲しい)

一本に収めようってのが甘い > 335/336
338 ：名無しさん＠お腹いっぱい。：02/08/22 22:52
さすがに切れるなんてのは無いが、書き込みエラーはちょいちょい。
（数十本抱えてるもので）

漏れはもっとI/Oの速度が出るテープが欲しい。
最近はヘッドを何十個も増やして並列に書き込むことで、I/Oを出す
奴が出たようだけどね。
339 ：名無しさん＠お腹いっぱい。：02/08/22 23:10
SDLTとLTOで書込みエラーなんてそんな経験ねーよ
ドライブ何台使って速度出ないの? > 338
340 ：名無しさん＠お腹いっぱい。：02/08/23 05:16
おもしろそうなツールハケーン
http://www.partimage.org/
http://www.lint.ne.jp/~tomo/homeserver/backup/partimage.htm
341 ：LTO：02/08/23 12:18
>>337
LTO のオートローダ使ってるけど、今のトコ書き込みエラーはないね。1年半使用。
ただ、オートローダ的に問題が過去にあって、なんどかテープ噛んではき出さなくなったことは
あるけど。 ( それも問題か )
342 ：名無しさん＠お腹いっぱい。：02/08/23 17:29
>>337
IBMのLTOドライブで、１度だけドライブから出てこなくなったことがあったよ
IBMのwebにあるメンテナンスマニュアルに取出し方法が書いてあったんで
試してみようかな?と思ったけど、すなおに修理に出してみたり...
テープは帰ってこなかったけど^^;;;
343 ：名無しさん＠お腹いっぱい。：02/08/24 10:06
次世代DVDってどうよ？
これが出たらテープはますます存在価値がなくなる？
344 ：名無しさん＠お腹いっぱい。：02/08/24 20:39
つーてもDLTのスピードにはかなわんだろう
345 ：名無しさん＠お腹いっぱい。：02/08/25 13:30
マルチボリュームしなくてよくなったらうれしいな。
でもどうせ民生に降りてくる頃には、
"たった 1TB? ぷぷぷ。使いもんになんねーよ"
に 100メセタ
346 ：名無しさん＠お腹いっぱい。：02/08/26 00:52
>>345
まぁﾌﾟﾌﾟﾌﾟは否定しないが、でもPCのHDDが100GB以上のが2万円も出せば買える時代に
そいつをバックアップするためのメディアやドライブが60万円、というのもそれはそれで
歪んでいるなぁとも思ったりする。

DDS3ももう役に立たないか…
347 ：名無しさん＠お腹いっぱい。：02/08/27 19:30
ufsdump/ufsrestore にしても tar にしても cpio にしても、
シンボリックリンク自体のタイムスタンプや所有者を
元の状態に復元することができません。
実際上問題がないとはいえ、完全に元に戻らないのは気持ちが悪いです。

シンボリックリンクを完全に復元できるバックアップ方法はないものでしょうか？
（ここでは dd は除く）
348 ：うひひ：02/08/27 19:41
>>347
rsyncとかは？
349 ：名無しさん＠お腹いっぱい。：02/08/27 20:47
>>347
シンボリックリンクの所有者は意味がない。
リンク先のアクセス権限があるかどうかだし。
rootで十分。

シンボリックリンクはパスがかかれているただのテキスト。
システムやシェルが解釈して実行するだけの物。
350 ：名無しさん＠お腹いっぱい。：02/08/27 20:56
>>349
> シンボリックリンクはパスがかかれているただのテキスト。
短い名前の場合は直接i-nodeに埋め込む実装もあるからテキストとは限らない。

> システムやシェルが解釈して実行するだけの物。
シェルで解釈するとopen("/path/to/symlink"...)できなくて困らんか?
351 ：名無しさん＠お腹いっぱい。：02/08/27 21:19
>>350
Winから類推していると思われ
352 ：名無しさん＠お腹いっぱい。：02/08/27 21:35
>>349
quota で管理している場合、
わずかながらシンボリックリンクの分の使用ブロック数が誤差になる。
タイムスタンプも保存されないので、
find である日付以降/以前に作成されたシンボリックリンクのみを
探すということもできなくなってしまう。
あと、所有者が変わってしまったシンボリックリンクを
rm しようとした場合、Warning が出たと思う。

なので、やっぱり元通りに復元できる方がよい。

>>348
rsync でも無理。(つーか、そういう問題ではない)
353 ：名無しさん＠お腹いっぱい。：02/08/28 05:24
>>352
> rsync でも無理。(つーか、そういう問題ではない)
なんで?
rsync は lchown 使うからシンボリックリンクの所有者を復元してくれるよ。
lutime や lutimes は使わないから日付までは復元しないけど。
354 ：名無しさん＠お腹いっぱい。：02/08/28 07:28
lchown() が存在する OS なら、GNU tar でもシンボリックリンクの
所有者は復元できるみたい。
問題はタイムスタンプの方かな。
# 逆に、lchown() が無い OS では rsync でも所有者を復元しない。
355 ：名無しさん＠Ｅｍａｃｓ：02/08/28 07:58
>349,250

短い名前のときっていうか、ほぼ大抵がそれ（inode）で、一部例外がテキストでは。

日本語ファイル名とか大量に使ってるなら、数的には逆転するか。
それだって、単にパスを記録しているとはいえ、テキストファイルとは
いわないのでは。
356 ：うひひ：02/08/28 09:16
>>352
駐坊でゴメンよ。脳内manにそんな雰囲気があったので
記憶が薄かったので見てみた
＊オプションを使って、シンボリックリンクや、ハードリンク、ファイルオーナ
＊ー、パーミッション、デバイス、タイムスタンプを維持することができます。
こんなキーワードが脳内に薄く刷り込まれていた
確かにシンボリックリンクのタイムスタンプや所有者をとは書いていない
357 ：名無しさん＠お腹いっぱい。：02/08/28 17:12
>>355
inodeにsymlink名を埋め込む実装のファイルシステムって何があるの？
Solaris ufs などはそうなってないと思うんだけど。
（BSD系でそういうのがあった記憶があるようなないような・・）
358 ：名無しさん＠お腹いっぱい。：02/08/29 11:49
CD-Rでバックアップは楽しいなぁ。
8GB取るのに14枚。現在5枚目。


　　　････ｳﾜｧｧｧﾝ! 　　　ﾓｳｲﾔｰｰ!!

359 ：名無しさん＠お腹いっぱい。：02/08/30 01:03
フロッピー40枚用意してSlackware 3.3入れましたが何か？
360 ：名無しさん＠お腹いっぱい。：02/08/30 14:18
毎回毎回カセットテープでHu-BASICロードしてますが何か？
たまにS-BASICになります。
361 ：349：02/08/31 04:57
>>351
文字列と同じサイズだったからそうだと思っただけ。

それに、Winはただのテキストじゃねーし。
362 ：名無しさん＠お腹いっぱい。：02/08/31 08:47
Windowsにシンボリックリンクあったっけ。
NTFSならハードリンクやジャンクションならあるけど。
363 ：名無しさん＠お腹いっぱい。：02/09/03 03:00
>>362
シンボリックリンクはないよね。
ショートカットと混同してんでしょ。かなり性質違うのにね。

でも俺もNTFSにハードリンクその他があることを知らなかったので
人をバカにできん。
ln コマンドに相当するようなものがあるの？

364 ：名無しさん＠お腹いっぱい。：02/09/03 03:59
>>363
SFU ?
365 ：名無しさん＠お腹いっぱい。：02/09/03 10:39
昔のNTって、posix 準拠を謳うために、NTFSにいろいろ入れてなかった？
大文字と小文字の違いで別ファイルになるとか（Win32サブシステムからは利用不可だけど）
だから、symlink も入ってるかも？　posixが要求してそうだから。
例によって win32 サブシステムからは使えないかもしれないけど。

いまでも OS/2 とか POSIX サブシステムとかってサポートしてんのかな？
366 ：名無しさん＠お腹いっぱい。：02/09/03 12:54
>>365
その辺のサブシステムは Windows XP であぼーんされた模様。
OS/2 -> 無視
POSIX -> SFU使え
ということみたい。
367 ：名無しさん＠Ｅｍａｃｓ：02/09/03 13:17
>>358
リムーバブルケースとハードディスク買ってこれば？
玉ごと変えればいいんだし。
368 ：名無しさん＠お腹いっぱい。：02/09/03 19:59
HP model712/100 OS9.07を使っています。
市販のPCのディスクコピーツールを使って、
HDDのデータを同型のHDDに丸ごと完全にコピーをして、バックアップにしたいです。
HDDはIBM製のSCSI 2GBです。

（1）このようなことができるのでしょうか？
（HDD二台つけて、PCでフロッピーからOSを動かして、HDDを認識させて
コピーできたらいいなあ......と思っています。
UNIXのデータフォーマットはよく知らないけど、
SCSIとして認識すればフォーマット形式は関係ないと期待しています）

(2)コピーできたとして、バックアップしたHDDともとのHDDを交換して
WSは正常に起動して使用できるのでしょうか？

どなたかわかる方おしえてください。
369 ：名無しさん＠お腹いっぱい。：02/09/03 20:06
>368 便乗。「市販のPCディスクコピーツール」とやらにもよると思うが
(3) ディスクのCHSは厳密に揃えなきゃだめ? 大は小を兼ねる?
(4) ディスクにbad sectorがあったりしたら不幸になる?
370 ：名無しさん＠お腹いっぱい。：02/09/03 21:52
フォーマット形式
ハンドルネーム
小さな小競り合い
馬から落馬
白い白衣
371 ：名無しさん＠お腹いっぱい。：02/09/03 22:15
結局、厨房クラスのバックアップスレかよ
372 ：うひひ：02/09/04 00:19
>>368
シングルでddチョチョイのパ
HP-UX質問はココだその１参照
373 ：名無しさん＠お腹いっぱい。：02/09/04 02:51
>>370
白衣は既にある種のユニフォームであり
白色であることは自明ではない。
374 ：保守：02/09/20 21:10
全言語のページから "黒い白衣"を検索しました。
約58件中1 - 49件目 ・検索にかかった時間0.14秒
375 ：名無しさん＠お腹いっぱい。：02/09/21 09:15
cpioはFile name too long エラーでない？
376 ：(ﾟ∀ﾟ)ｱﾋｬﾋｬ：02/09/24 17:27
あげとく
377 ：ホシュ：02/10/08 10:32
ホシュ
378 ：名無しさん＠お腹いっぱい。：02/10/08 23:37
DLT4000を使っているのですが、バックアップしたいデータをハードウェア圧縮した場合、
どの程度の容量になるのかを調べる方法はないのでしょうか？
379 ：名無しさん＠お腹いっぱい。：02/10/09 01:18
ハードウェアでもソフトウェアでも情報の圧縮能力に大差ないよ。
ハードウェア圧縮なんてめんどくさい方法使わないで、素直にtar.gzすりゃ
管理が楽ってもんだ。
380 ：378：02/10/09 01:51
>>379
なるほど、確かに・・・・
tar.gzにすれば圧縮後の容量も一目でわかりますしね。
ハードウェア圧縮は中間ファイルをつくらず圧縮しながらバックアップをとって
いくから、圧縮後の容量は実際に試すまでは分からないのかな？
381 ：名無しさん＠お腹いっぱい。：02/10/09 14:10
>>380
実際にやるまでは、たぶんわかんない。
382 ：名無しさん＠お腹いっぱい。：02/10/10 20:47
概算機能があるソフトもあったと思うけど、時間がかかる割に大した効果もない。
実際にそのデータを圧縮してみて、データの傾向によって差が出る。
その差がどれくらいかを大体掴むくらいのことしかできない。

まぁ、圧縮後のサイズで必要容量を決めるというのは結構ギャンブルなんで
お勧めはしないよ。データ内容が変更になった場合に計算が狂ったりするし。

圧縮して、「思ったより少なくて済んだな」くらいの使い方がベスト。（経験則）
383 ：名無しさん＠お腹いっぱい。：02/10/30 15:45
今度の Exabyte VXA-2 ってどうよ？
VXA-1 33GB/66GB
VXA-2 80GB/160GB
384 ：あぼーん：あぼーん
あぼーん
385 ：名無しさん＠お腹いっぱい。：02/12/05 02:33
>>373
小競り合いにも規模の大小はあるでしょうしね。
386 ：名無しさん＠お腹いっぱい。：02/12/10 05:54
>>378
圧縮すると、それだけテープメディア障害の際の被害が
非圧縮の場合より大きくなるわけだが。
387 ：名無しさん＠お腹いっぱい。：02/12/10 12:13
DLTの価格からしたら、圧縮したくなる気持ちもわからないでもない


しないけど。
388 ：名無しさん＠お腹いっぱい。：02/12/15 14:50
やっぱ、日立には悪いが、HDDバックアップってのが一番良いよ。
価格性能比で。
月一くらいで永久バックアップにはテープが良いけど。
毎日テープは億劫。

HDDサーバにファイル転送の方が管理が楽だよ。
RAID化するとか、さらにサーバを立てて電源を切っておくとか、
HDDのほうがトータルコストで安い。
まぁ、UNIX使わないと、こういう運用は不可能なんだけどね。
リモートコントロールや、処理の自動化に限界があるから。
389 ：名無しさん＠お腹いっぱい。：02/12/17 20:54
>>388
日立に悪いってのは、どういう意味？
390 ：名無しさん＠お腹いっぱい。：02/12/19 01:51
ここの資料のP13～14に面白いことが書いてありますが
どう思います？

http://www.unisys.co.jp/es/expo_dwh/data/stk_a6_b7.pdf

なーんか、HDDをバックアップメディアとして
考えるのには抵抗が・・・。
391 ：名無しさん＠お腹いっぱい。：02/12/23 22:10
保守
392 ：名無しさん＠お腹いっぱい。：02/12/23 23:25
HDDがバックアップメディアで済むようなレベルのシステムもあるんだろ（藁

つか、次期メディアってどうよ
393 ：名無しさん＠お腹いっぱい。：02/12/23 23:33
>>388
せいぜい突然のハードディスククラッシュや
オペミスで消してしまう事故を防ぎたい *だけ* ならそれでもいいかもね。
日々のスナップショットの長期保存とか、
災害で拠点がつぶれたときの備え
(一応ネットワーク経由で送るという手もあるけど)としては不十分。

>>386
圧縮した分だけ、メディアを占有する面積が小さくなる分
メディア障害に遭遇する確率が小さくなるとも言えなくない?
394 ：名無しさん＠お腹いっぱい。：02/12/24 00:19
はぁ？ いったいどんなメディアか言ってみ
395 ：名無しさん＠お腹いっぱい。：02/12/25 04:56
で、今一番メディア障害の少ない、確実にリストア出来るテープメディアって何？
396 ：fdas：02/12/25 17:57
Ｓｏｌａｒｉｓ　でルートではない一般ユーザーでそのワークステーション
にｒｓｙｎｃをインストールすることは可能でしょうか？

できればデーモン化したいのです
397 ：あぼーん：あぼーん
あぼーん
398 ：名無しさん＠お腹いっぱい。：02/12/25 18:01
>>396
ホームディレクトリ以下にでも入れたら?
デーモン化はムリだろ。
399 ：396：02/12/26 08:47
シェルと、ホームディレクトリを与えられた、一般ユーザー
が、ｒｓｙｎｃをインストールする方法ですが、
pkgadd は使用できないので、
./configure
して,makefile を作らないといけません。
具体的に、ホームディレクトリにインストールする
にはどうすればいいでしょうか？
また、デーモン化はムリとのことですが、
このＳｏｌａｒｉｓをバックアップ先として
使うにはどうすればいいでしょうか？
400 ：名無しさん＠お腹いっぱい。：02/12/26 09:00
>>399
./configure --help
後半についてはmanよめ。
そもそもコピー先として使うときにデーモンとして動かすやつは
あまりおらんだろ。
401 ：396：02/12/26 10:42
>>400
レスありがとうございます。
./configure --help 調べてみます。
一台のSolarisはルート権限が、あり、もう一台はルード権限がありません。
この場合、rsync　を使ってミラーさせることは可能なのでしょうか？
402 ：名無しさん＠お腹いっぱい。：02/12/26 10:51
>>401
ssh か rsh が使えれば可能でないかな。
つーか、管理者に入れてもらえよ。
403 ：名無しさん＠お腹いっぱい。：02/12/26 11:11
>>401
ポートをデフォルトの873でなく1024以上にして、rsyncd.confでは
use chroot = false にしておけばroot以外のプロセスで起動することは
可能なんじゃないかな。
404 ：396：02/12/26 11:39
resありがとうございます。
具体的なインストール方法ですが、
/home/name/ にrsync をインストールするには、具体的に ./configure に
どういうオプションを付ければいいのでしょうか?
教えて下さい。

＞＞４０２さん ssh もrsh も入っていません。
いれてもらうことは不可能です。
>>403さん

ルート権限があるsolaris がコピーもとで、ルート権限がないsolairs が
コピー先です。
やはり二つともポートの番号を変えておかないといけないのでしょうか?
405 ：名無しさん＠お腹いっぱい。：02/12/26 11:44
>>404
./configure --help は読んだのか?
読んでわからないならあきらめろ。
406 ：396：02/12/26 12:01
./configure --prefix=/home/name/sync
make install でいけました。
rsyncd.conf
ってどこにできるのでしょうか？
/home/name/sync/bin
以下には実行可能なバイナリ-しかありませんし、他のディレクトリは
manual のディレクトリと思われます。
407 ：403：02/12/26 12:32
>>406
env MANPATH=$HOME/rsync/man man rsyncd.conf rsync
408 ：名無しさん＠お腹いっぱい。：02/12/26 19:58
お前等、今度バックアップ・ドライブ買うとしたら、
どの媒体のにしますか？オートチェンジャーはどーですか？
409 ：名無しさん＠お腹いっぱい。：02/12/26 22:04
cpioとtarでそれぞれすぐれている点とかあるんでしょうか。
あったら教えてください。
410 ：名無しさん＠お腹いっぱい。：02/12/27 01:43
cpioはメディアが分かれるときに効果を発揮するらしい。
まぁ、分割ツールで分割してカキコしても同じ事だけど。
411 ：409：02/12/27 22:27
>>410
ありがとうございました。
すると、tarよりcpioのほうが優れているとことですね
412 ：名無しさん＠お腹いっぱい。：02/12/27 23:55
>>411
>>410を読んだだけで、どうしてそういう結論が出るのだろう？
413 ：名無しさん＠お腹いっぱい。：02/12/28 00:06
>>410
tarでもできませんか?
414 ：名無しさん＠お腹いっぱい。：02/12/31 00:50
>>413

tar はディレクトリ深いと泣いてしまうんじゃなかったけ?
415 ：名無しさん＠Ｅｍａｃｓ：03/01/02 01:02
tarは、アーカイブファイルの途中でエラーすると
そっから後ろのファイルも復帰できなくなります。

あまり大規模なバックアップでなければtarでも。
416 ：山崎渉：03/01/15 13:10
（＾＾）
417 ：名無しさん＠お腹いっぱい。：03/01/16 23:39
これどうよ。
http://filesys.ntt-it.co.jp/seihin/zfs/index.html
http://filesys.ntt-it.co.jp/seihin/ifs-hr.html
RAID4でパリティあるってのが気に入った。
今まで Veritas HSM 使ってきたけど、これはブロック型階層記憶とかで
ドライブからの読み出しと同時に転送が始まるらしい。
ウォーターマークの呪縛から開放されるのもいいね。
418 ：名無しさん＠お腹いっぱい。：03/01/17 00:15
微笑んで毎日revel0でダンプしてますが。
419 ：名無しさん＠お腹いっぱい。：03/01/17 03:49
SCSI ハードウェアRAIDでミラーリング。
週１でホットスワップで入れ替え。

日々dumpでバックアップ。
FTPでコピー。

どうですか？
420 ：名無しさん＠お腹いっぱい。：03/01/18 17:00
>>418 ワッショイしながらdumpするんでつか?
421 ：名無しさん＠お腹いっぱい。：03/02/08 04:03
pdumpfs を使ってるんですけど、バックアップ用HDDが一杯になりつつあり、
大きめのHDDに内容を移したいと思ってます。pdumpfs でバックアップされた
ファイルってハードリンクが多用されてるんだけど、旧backupHDDから
新backupHDDへの移し替えに dump & restore を使って大丈夫でしょうか？
422 ：名無しさん＠お腹いっぱい。：03/02/08 10:42
>>421
うん。


423 ：名無しさん＠お腹いっぱい。：03/02/09 05:21
all or nothing
424 ：名無しさん＠お腹いっぱい。：03/02/10 15:46
>>421
dump は出来るけど，directory の数が多いため，
restore が何GB とかのメモリを要求して結局 restore 出来なかった...

tar とかでとっておけば大丈夫だったりするのかしら...
(気づいたときには手元にdumpの塊しか残っていなかったので
それ以外のテストはしていません)
425 ：名無しさん＠お腹いっぱい。：03/02/13 11:34
dumpって、directory数によって、必要メモリが増減すんの？
426 ：名無しさん＠お腹いっぱい。：03/02/14 03:17
ネタか、設定がおかしいか、サーバがデカすぎるんでしょ。
個人用とは思えない。
427 ：名無しさん＠お腹いっぱい。：03/02/14 16:01
そういや、pdumpfs の C++版ってあるのかな？
ruby無しで使いたいって人、多いんじゃないかな。
428 ：あぼーん：あぼーん
あぼーん
429 ：名無しさん＠お腹いっぱい。：03/02/15 03:37
rubyに何か問題でも？
430 ：424：03/02/16 17:38
>>426
一応まじめな話のつもり。

pdumpfs を数ヵ月程度続けた場所って普通(?)より2桁くらい directory が
多くなるわけですが，高々6GBちょっと(音声ファイルとか含む)の
home のバックアップのつもりでも，restore が swap が足りないよー
という状態で死にます．で，どうも directory 数が多いのが問題らしい．
(restore しようとしたホストを memory 256MB + swap 1GB くらいに
増やしたけどそれでも足りなかった;
home の大きさも今時は個人用でこれくらいはアリですよね)

もしかして，restore の実装が複数あってだいじょうぶな OS も
あるのかな? (手元は FreeBSD-4 です)

他に pdumpfs の塊を dump/restore された方はいらっしゃいませんか?
431 ：名無しさん＠お腹いっぱい。：03/02/17 06:34
cpio つかってみては？
432 ：名無しさん＠お腹いっぱい。：03/02/17 14:24
>>430
ディレクトリ数でメモリがそんなに必要になるってのは、ちょっとイメージできないな。
（ps で見たときに、たしかにメモリをバカ食いしてるの？）
最終的には、ソースをみてみるしかないかもね。

>>431
cpioって、pdumpfsの必要条件である、ハードリンクを再現できるの？
433 ：あぼーん：あぼーん
あぼーん
434 ：424：03/02/17 17:16
FreeBSD:/usr/src/sbin/restore/dirs.c:
#define DIRBLKSIZ 1024
struct rstdirdesc {
int dd_fd;
int32_t dd_loc;
int32_t dd_size;
char dd_buf[DIRBLKSIZ];
}; /* ～ざっと 1KB */
を opendirfile() で malloc するループが回ります．
一方，home の dir が現在 4000 程度(今数えました)．
仮に半年程度のアーカイブなら 200倍程度としてざっと 1GB 弱のメモリ，
なんじゃないでしょうか．(どっかで free してますかね?)

うーん．確かに微妙ですが，私の試したときには数時間かけて
徐々に swap の size が ..200M..500M.. と成長していって
最後には swap が足りない，と console に吐いて死んでる，
という感じでした．(3ヶ月分程度は restore 出来ていたような気もする)

で，上記の directory 数が問題じゃないの，といわれて，
そうなのかなー，と思って勝手に納得していました．違うのかな?
435 ：名無しさん＠お腹いっぱい。：03/02/17 18:42
いっそ、ddでパーティション全体をフルバックアップ＆リストアするとか。
436 ：名無しさん＠お腹いっぱい。：03/02/18 18:36
>>434
とりあえず、まともな解決方法ではないけど、
古い奴は、毎月１日とかのバックアップを残して、それ以外を削除するというのはどうよ？
437 ：名無しさん＠お腹いっぱい。：03/03/03 15:40
>>435
こんな感じですか？

# dd if=/dev/hda1 of=/dev/hdb1
438 ：名無しさん＠お腹いっぱい。：03/03/03 22:21
>>437
ddってサーバ稼動中などにやっても大丈夫でしょうか？
負荷が掛からなければやってみたいです
439 ：名無しさん＠お腹いっぱい。：03/03/04 13:00
>>438
そのパーティションをumount(or read only mount)した状態でないと、
バックアップしてもファイルシステムが論理不整合を起こすので注意。

CPU負荷は他の手法に比べてかなり小さいけど...
440 ：名無しさん＠Ｅｍａｃｓ：03/03/04 13:38
pdumpfsで指定したサイズ以上のファイルはバックアップしないようなオプショ
ンがあるといいな～っと、お願いしてみるテスト


441 ：あぼーん：あぼーん
あぼーん
442 ：名無しさん＠お腹いっぱい。：03/03/04 16:02
過去ログです。
1: http://page.freett.com/dat2ch00/030107-1041260616.html
ﾏﾀｶ[]乱交サークル個人情報漏洩[]ｱﾎ
2: http://page.freett.com/dat2ch00/030107-1041268516.html
ﾏﾀｶ[]乱交サークル個人情報漏洩[]ｱﾎ 【part2】
3: http://page.freett.com/dat2ch00/030107-1041274177.html
ﾏﾀｶ[]乱交サークル個人情報漏洩[]ｱﾎ 【part3】
4: http://page.freett.com/dat2ch00/030107-1041288143.html
ﾏﾀｶ[]乱交サークル個人情報漏洩[]ｱﾎ 【part4】
5: http://page.freett.com/dat2ch00/030107-1041311110.html
【岡ちゃん】乱交サークル個人情報漏洩【最高!】Part5
6: http://page.freett.com/dat2ch00/030107-1041321139.html
【岡ちゃん】乱交サークル個人情報漏洩【最高!】Part6
7: http://page.freett.com/dat2ch00/030107-1041353460.html
【岡ちゃん】乱交サークル個人情報漏洩【最高!】Part7
8: http://page.freett.com/dat2ch00/030107-1041609085.html
【岡ちゃん】乱交サークル個人情報漏洩【最高!】Part8
9: http://2chlog.homeftp.org/20030203/1041773755.html
【議員の息子】乱交サークル個人情報漏洩!【会社役員】Part9
10:http://2chlog.homeftp.org/20030203/1042853091.html
【議員の息子】乱交サークル個人情報漏洩【PWC大ちゃん】Part10
443 ：名無しさん＠お腹いっぱい。：03/03/05 19:28
ｲｲﾅｰ。
ﾊﾞｯｸｱｯﾌﾟしときたいﾅｰ。
444 ：名無しさん＠お腹いっぱい。：03/03/06 05:28
結局pdumpfsでも後々問題がでるってことか。。。
やっぱRAIDでミラーリングが一番って事でよろしいですか？
445 ：名無しさん＠お腹いっぱい。：03/03/06 06:56
当然ながら目的による。
446 ：名無しさん＠お腹いっぱい。：03/03/06 11:08
一日一回、別マシンにFTPでミラーリングしてます。
447 ：名無しさん＠お腹いっぱい。：03/03/07 17:55
>>446
一日一善？
448 ：名無しさん＠お腹いっぱい。：03/03/07 18:49
>444
pdumpfs した中身は別に問題ないですよ．
pdumpfs したものをさらにテープに取りたいときも
dump は問題ないし，restore の際に最新 snapshot のみ
とかだったら dump/restore でもたぶん OK.
tar で最新 snapshot のみ取るのはもちろん OK.
tar で塊を取ろうとするとどうなるのかは誰かやってみて．
449 ：名無しさん＠お腹いっぱい。：03/03/07 19:11
>>448
ハードリンクができないから、リストアサイズが...
450 ：名無しさん＠お腹いっぱい。：03/03/28 16:30
NetWorkerの運用で、レベルってありますよね。
初日フル、次の日レベル９、次の日レベル８ってとってってくとさ、
フルからの差分さえあればいいというとき、レベル9側のバックアップデータいらないよね。
これって削除して空きにできないのですかね？
消せたとしても中途半端な空きの為再利用しにくいとかありますか？

効率的な完全自動化難しいぞNetworkerよ、、
（完全自動化自体は楽ダネ）
シェルでやろうとしたけどSSID拾ってくるときミスって他の消しそう。。
451 ：名無しさん＠お腹いっぱい。：03/04/01 22:08
単なるオペレータなので理論は知りませんが、疑問。

DDS を使ってますが、容量が少なくて苦しんでます。ロボット買うまでの
規模ではないし。で、どーしてテープはみんな小さいのですか D-VHS? とかでかい
のを使えばたくさん入りそうな気がするが違いますか。それともすでにありますか？
452 ：名無しさん＠お腹いっぱい。：03/04/01 22:54
>>451
DDS4 とか DLT でも不満?
453 ：名無しさん＠Ｅｍａｃｓ：03/04/02 07:49
>451

大容量なテープもたくさんあります。DLTとか。
で、どうしてD-VHSとかを使わないのかというと、
品質の問題。あっちはちょっとエラーがあっても
（人の視覚、聴覚で気づけないほどちょっと）
それなりに波形を復元できればそれで良いのですが
こっちは、完璧にコピーしなければならない。

たとえば設定ファイルに1ビットでもエラーがあって
別の文字になってしまっては困るわけで。
454 ：名無しさん＠お腹いっぱい。：03/04/02 12:10
>>450

Non Rewind デバイスを使うから昔の一部だけって作りからして
無理なんだよねー。ディスクにもバックアップできるけど
テープと同じ形式にして書いてるからなぁ。。。

一番売れてる Ｎｅｔ○○○○ｕｐ　よか こっちの方が 色々いじくれていい
けどねー。
455 ：名無しさん＠お腹いっぱい。：03/04/03 02:07
わたしのとこのは DDS4 でした。だいぶ不満。DLTというのは100GBですか。
50万くらいからとはなかなかですね。気にしておきます。

D-VHSうんぬんというのは、民生品を流用すれば、一本にざくざく入って
安くできないかな。サイズも大きいしいっぱい入りそう、と思ったのです。
googleで眺めましたが>>453さんがおっしゃるとおりそれなりみたいですね。
456 ：名無しさん＠お腹いっぱい。：03/04/03 17:33
>>455

DLT は DLT4000/7000/8000 があって 数字の 1/2000 GB が非圧縮容量。
最近の高容量 Super DLT は 220 と 320 があってそれぞれ容量が 110 GB
160 GB (非圧縮) 。DLT4000はDDS4とほぼ一緒のスペック。値段は実売で
Super DLT 110 は 単体100マン 切るくらい。DLT 系はほとんど販売終了してる。

457 ：名無しさん＠お腹いっぱい。：03/04/04 01:15
SAIT-1
記録容量 500GB（非圧縮時）／1.3TB（2.6：1圧縮時）
http://www.sony.co.jp/Products/storagesolution/sait2.html
458 ：名無しさん＠お腹いっぱい。：03/04/11 20:54
restoresymtable のサイズくらいはメモリ使うと思うけど、
pdumpfs のダンプ先って見かけのファイルの数も結構多いんじゃないの？
459 ：名無しさん＠お腹いっぱい。：03/04/12 04:21
俺もLinux上でpdumpfs使っててdump/restore でトラブった。
結局、700MBサイズの空ファイル上にext2ファイルシステム作成して、
それをマウントしてバックアップ先にしてる。

いっぱいになったらイメージをCD-Rに直書き。

Linuxでしか読めないCDになるが、ちゃんとファイルがハードリンクのままになるよ。


460 ：山崎渉：03/04/17 11:54
（＾＾）
461 ：名無しさん＠Ｅｍａｃｓ：03/04/19 14:22
ほしゅ
462 ：名無しさん＠お腹いっぱい。：03/04/19 20:33
DVDみたいな強力なエラー修正用のデータを入れてD-VHSとかは駄目なのかなぁ。。
463 ：あぼーん：あぼーん
あぼーん
464 ：名無しさん＠お腹いっぱい。：03/04/20 12:00
>459
その路線で考えると，
* VMware の仮想ディスク(使用量の分だけディスク消費)を mount(どうやって?)
* ufs image を vnode 経由で使用，下川さんの ufscopy とかでバックアップ
とかかな．
2番目では growfs とかで大きくできるという前提，と思ったけど
inode 数変更できなかったら意味ないか．
他に良い仮想ファイルシステム的なものって何かあるますかね．
465 ：名無しさん＠お腹いっぱい。：03/04/20 12:04
>462
1コマ落ちてもそれほど問題にはならない映像用途の規格なので
1ビットのエラーを許せないデータ系で実用にするには
かなり苦労するんじゃないでしょうか．

そのほか，絶対アドレス指定でちゃんと動くとかいろいろ
やっていくと結局 S-AIT が出来上がったりして．
(出荷台数を考えても安くはならない気がする)
466 ：名無しさん＠お腹いっぱい。：03/04/21 16:49
>>465
同意。

VHS改造するならDAT使った方が良い。
467 ：名無しさん＠お腹いっぱい。：03/04/22 02:43
>>421
バックアップ元が所詮 pudmpfs の結果なんだから、
dump/restore とか dd とか面倒なこと言わないで、
cp -a backup_from backup_to
とか
tar cf - backup_from | tar xpf - -C bacup_to
でいいんじゃないの？ GNU cp, tar はこれでハードリンク保存してくれるし。
468 ：名無しさん＠お腹いっぱい。：03/04/22 02:51
古いネタだけど、Linux で dump を使うのはロシアンルーレット回すようなもんらしい。
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1-disaster-rhlspec.html
469 ：名無しさん＠お腹いっぱい。：03/04/22 09:26
mount したままなら bsd でも似たりよったり
ではないかな
470 ：名無しさん＠お腹いっぱい。：03/04/22 09:37
>470
FreeBSD-5はR/W mount中のUFSをdumpしようとすると
勝手にsnapshotsを取ってからやるので安全です。動けば。
471 ：名無しさん＠お腹いっぱい。：03/04/22 10:29
>>467
同意。
pdumpfsってファイルシステムのいろんな情報を捨てちゃうよね。
特にハードリンクはコピーされる点が困るので残念ながら俺には使えない。
472 ：名無しさん＠お腹いっぱい。：03/04/22 18:28
dumpでバックアップ取ってるんですけど、
取ったバックアップの置き場で悩んでます。

同じサーバのHDDに保存していますが、
これでは意味無いしって事で、
NASを検討しています。

DELL の PowerVault 725N はどうなんでしょう？
今 PV112T DDS4 のテープバックアップドライブとセット購入が
お得みたいなんで、まずはNASでバックアップしたのち、
定期的にテープに保管を検討してたりするんですが。。。。

皆さんはバックアップ後のデータは、直接テープバックアップですか？
473 ：名無しさん＠お腹いっぱい。：03/04/22 22:53
>>472
ちょっと前までAIT2ライブラリにバックアップしてたけど、
最近は離れたところにおいたRAIDに保存してる。
ちなみに企業の研究室で、バックアップ対象が1TBちょい。
474 ：名無しさん＠お腹いっぱい。：03/04/25 00:45
rsync+ssh+cron で定期的にリモートマシンの HDD にバックアップを取ろうと
思ってるんだけど、認証をどうすればいいのが悩んでまつ。
ssh の公開鍵を使いたいんだけど、パスフレーズありだと無人実行できない。
パスフレーズなしにするしかないのかな？
475 ：名無しさん＠お腹いっぱい。：03/04/25 01:20
>>474
専用アカウント作れるなら、
専用のパスフレーズなし鍵作ってscponly使う。

専用アカウント作れないなら、
やっぱり専用のパスフレーズなし鍵作ってauthorized_keys に
from="リモートマシン" command="rsync うんぬんかんぬん"
とか書いて、rsyncしかできないようにする。
「うんぬんかんぬん」になに入れればいいかは、
一度手動で実行してみて、実行中にps取ってみりゃわかる。
476 ：名無しさん＠お腹いっぱい。：03/05/01 15:45

Linux RH72 で 定時メンテナンスのスクリプト組んでいます。

nfs マウントしたボリュームに、dumpでイメージを追加して
いきたいのですが、初期イメージ作成中に 2G を超え、
自動的にダンプ作業を続行してくれません。

自動的に分割する方法など、dump のオプションなどで
可能でしょうか？

dump の有用性とかでイジめられそうですが(^^;;
いまあるサーバーに、nfs で別のところに置いたファイル
へバックアップを退避したい、というのが本心です。

ご存知の方、おながいします。
477 ：名無しさん＠お腹いっぱい。：03/05/01 23:07
>>476
、初期イメージ作成中に 2G を超え、
自動的にダンプ作業を続行してくれません。

これの意味が分からん・・・
実際のdumpのコマンドを書け。
478 ：名無しさん＠お腹いっぱい。：03/05/02 00:55
>477

レスサンクスです。

ext3のファイル容量制限で 2G バイト以上の
イメージを dump が出力できない・・・・ってことです。

コマンドはこんな感じです。

/sbin/dump 0Bf 2000000 /mnt/backup/xxxx.img /xxxx

対象のディレクトリは 20G なので、ダンプイメージ
作成中、 2G を超えたところで、「次のテープに
交換して下さい」旨のメッセージが出ます。

このメッセージを表示しない方法で、自働的に
分割されたイメージファイルを出力する方法は
あるでしょうか？
479 ：名無しさん＠お腹いっぱい。：03/05/02 23:27
cpio使ってみた.
% cpio --list < foo.cpio
cpio: standard input is closed: Value too large for defined data type
ダメじゃん(w
480 ：名無しさん＠お腹いっぱい。：03/05/03 08:53
afio の man には、 cpio の format だと 2GB までしか作れないって書いてあるね。
それで、 afio は 2GB 超えるようだと、 cpio 非互換の format 使うって。
481 ：479：03/05/03 23:06
>>480
> 2GB までしか作れない
いや、--listってのはね、作ったあとの話ね。
10GBくらいだけど、作るのは問題中田よ。
482 ：名無しさん＠お腹いっぱい。：03/05/05 15:12
>476
Ext3などは、２GBオーバーのファイルも普通に扱えます。

NFSで、、ってことだから、多分、NFSのVer2の制限に引っかかってるに一票。
Ver3なら2GBオーバーでもいけます。
483 ：名無しさん＠お腹いっぱい。：03/05/06 11:52
>>480 >>481

便乗で質問ですが、、ということは、２ＧＢ超えのcpioファイルは
作れても、リストアできないから無駄だということでしょうか？
実際、今そこんところでハマってるもんで、、。　afioならばＯＫ？

あ、今の環境はRedHat 8.0でつ。
484 ：483：03/05/07 13:21
afioの２ＧＢ越えﾔﾃﾐﾀーYO

【環境】
RedHat 8.0
バックアップ元：ＨＤＤ（ext3）
バックアップ先：ＤＶＤ－ＲＡＭ４．７ＧＢ（ext3）
tmpmovフォルダサイズ：約２．１ＧＢ

【バックアップ】
# find . -regex "\.\/home/hoge/tmpmov.*"|afio -ov /mnt/dvd/testbackup.afio
home/hoge/tmpmov -- okay
　：
home/hoge/tmpmov/movie1.mov -- okay
　：
home/hoge/tmpmov/movie7.mov -- okay
File size limit exceeded
「、、、。」

【リスト】
# afio -t /mnt/dvd/testbackup.afio
home/hoge/tmpmov/movie1.mov
　：
　：
home/hoge/tmpmov/movie7.mov
home/hoge/tmpmov/movie8.mov
afio: "/mnt/dvd/testbackup.afio" [offset 2047m+1023k+1023]: Fatal error:
afio: "/mnt/dvd/testbackup.afio": Premature input EOF
(´･ω･`)ｼｮﾎﾞｰﾝ
485 ：名無しさん＠お腹いっぱい。：03/05/07 15:08
ダメダメじゃん…
486 ：483：03/05/07 16:22
afio 2.4.7.9beta4 (Beta)なら2GB以上をサポートしてることをﾊｯｹｿ
http://freshmeat.net/releases/105557/

漏れのはrpmで入れたので2.4.7-1でした。
rpmﾎｽｨ
487 ：名無しさん＠お腹いっぱい。：03/05/09 00:21
>>478
外してるかもしれませんが、
dump は標準出力に出して split -b 2147483647 するのじゃだめ？

488 ：名無しさん＠お腹いっぱい。：03/05/17 02:34
DDS3の信頼性ってどんな感じだろう？
今のサーバのDDS2ドライブが3年で壊れたから
ちょっと怖いんだが。
489 ：名無しさん＠お腹いっぱい。：03/05/17 10:59
>488
使用頻度によるのでは?
毎日使って3年だったら別におどろきゃしないし。

DDS3/4辺りになるとドライブ間(メーカー間?)で
互いにテープを読めないという事態がよくある(経験済)のと
(こっちは私自身は経験していないけど)テープが結構すぐに
へたれるらしいですね。
490 ：名無しさん＠お腹いっぱい。：03/05/17 15:01
>>489
>毎日使って3年だったら別におどろきゃしないし。
う～ん、そのくらいの信頼性しかないんだ、やっぱり値段相応なんだ。
でも、毎日予約録画してるビデオデッキが（値段はDDS2ドライブの
１０分の１）が５年間トラブル無く動いてるのを見ると、なんか、ふに
落ちない気もするが。

>ドライブ間(メーカー間?)で 互いにテープを読めないという事態が
>よくある(経験済)

これは怖いね。予備のドライブを確保しておいても無駄におわる可能性
があるわけだ。
491 ：489：03/05/18 10:48
>490
書き方悪かったかな? 3年間毎日使って，"(1台が)壊れたとしても驚かない";
必ず壊れるってことではない。HDD が3年で壊れた，
というサンプルが1つあっても驚かないでしょ，程度の意味。
10台所有していて8割が3年で壊れたといわれたらビックリですが。
(あと，head 周りは DDS3/4 はテープが烝着になって
耐久性などは DDS1/2 より大分良くなっているんではないかな?)

VTR とは精度/信頼性とかの要求スペックが全然違うからねぇ。

あと，読み互換ですが，?付で書いてある通り，
私が経験しているのは基本的にはメーカー間(SONY/HP/Seagate)の
問題だけど，私が知っているのなんてそれぞれ1,2台づつで
統計的な数字をもっていないんで，
同じメーカーであれば100%大丈夫かは *私は明言できない* というだけです。

# ちなみに時々よそのテープでも読めるメディアがあって特別テープ扱いです。

もちろん，OS/圧縮有無などはそろえて，ちゃんとクリーニングは
した上での話。
492 ：488：03/05/18 21:06
>>491
具体的な話をありがとう。

>VTR とは精度/信頼性とかの要求スペックが全然違うからねぇ。
ドライブの中で「バキバキバキ」とか「メキ」という音がして
二度と動かなくなったのは、そういう高いレベルの話ではないような(w

信頼性から言ったらDLTとかの方が良いんだろうけど、メディアの値段がなぁ(汗)
493 ：489：03/05/19 00:12
>492
マジで? バキバキはおいらも普段は想定してないな。
ただ、油断していて外付けドライブの排気ファンが死んでいて
ものすごーくホカホカのドライブにしちゃったことはあって、
これで一気に寿命が縮まるんだろうな、と思ったことならある...

(でも VTR だと真っ先に壊れるのってローディング部だな)
494 ：488：03/05/19 01:57
>>493
おおマジ。テープというもののの恐ろしさが身に凍みて
分かった。
かといって、円盤系のメディアはろくな容量がないから
テープを選ばざるをえない。
495 ：名無しさん＠お腹いっぱい。：03/05/19 05:14
ほろぐらふぃっく……
496 ：名無しさん＠お腹いっぱい。：03/05/19 15:14
そういや、最近、HDD/RAID を使ったバックアップ装置、みたいなのが
徐々に増えてきてるね。
497 ：あぼーん：あぼーん
あぼーん
498 ：名無しさん＠お腹いっぱい。：03/05/29 16:09
うちとこのDDSドライブ、5年間で5台こわれた。
うるとりあむ?だったけ。あれはよさげ、高いけど。
499 ：あぼーん：あぼーん
あぼーん
500 ：名無しさん＠お腹いっぱい。：03/05/29 23:16
Ultrium(LTO)っていいんですかね．
でかい/高いに加えて，DLT 系はカートリッジの
取り扱いに(AIT/DDS と比べて)気をつけないといけない，
とどっかの white paper で読んでびびっているんですが．
501 ：あぼーん：あぼーん
あぼーん
502 ：名無しさん＠お腹いっぱい。：03/05/30 08:46
>>500
どうなんだろ?
以前FreeBSD Pressでバックアップ特集の記事読んだけど、DDSの故障率の高さを
メチャメチャ叩いてた。
やっぱ一社独占状態の閉鎖的な規格はダメだ。だからUltriumは期待できるんだ。
みたいなことが書いてあったよ。

DLT系はメディアが弱いのか。なるほど。
でもドライブ自体は構造から考えればDDSよりDLTの方が故障しなさそうな気はする。
503 ：あぼーん：あぼーん
あぼーん
504 ：500：03/05/30 21:17
DLT/LTO 系のメディアが fragile とかいう話のネタ元を
一応書こうと思ったのだが，どこだったか忘れた．
google で探すとこれじゃないかと思うのだけど，また
登録するのが面倒なんで... 誰か興味あったら見てください．
http://www.cambridgecomputer.com/knowledge/tape_comparison.html

>502
ま，DDS 系が中途半端な位置づけになって，DDS5 が行き場を失ったのは
確かだと思うけど，一社独占ってことはないよねぇ．
ドライブ製造元だって SONY/HP/Seagate(Archive) と
少なくとも3社あるわけだし．一社独占と言ったら
AIT: SONY
S-DLT: Maxtor(Quantum)
Exabyte/Mammoth/VXA: Exabyte(生き残っているうちに入るのかな?)
(Travan: 論外)
という方が普通思い当たるのだが．
(で，AIT については結構期待しているんだけど．)

# でも中途半端だったからこそ個人でも手を出せたわけで
# 消えてしまうのは残念です > DDS
505 ：500：03/05/30 21:28
見つけた:
"Tape Drive Technology Comparison"
http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=161
この p11(p7) の mechanism の記述です．

# そっか，以前見たのがこっちだとすると 504 に書いた方も
# 見ておこうかという気になってきた
506 ：名無しさん＠お腹いっぱい。：03/06/03 01:15
ファイル属性（所有者、グループ、パーミッション）を保持したままユーザ権限で
バックアップを行おうとすると tar ですよね。
rsync や pdumpfs は便利そうですが root 権限で実行しないとファイル属性が
壊れちゃうけど、何か対策ってありますか？
507 ：名無しさん＠お腹いっぱい。：03/06/03 19:48
tar だって、owner が他人で permission が 600 のファイルとかは
バックアップできないぜ。
もちろん root なら可能な訳だが。

rsync は、 source は一般ユーザでも owner/group を保存する。
destination で書き込みができないだけ。
だから工夫すれば使える(かも)。pdumpfs は知らん。
508 ：名無しさん＠お腹いっぱい。：03/06/03 19:59
ユーザ権限でアクセスできないファイルはどうするんだろう・・・
509 ：名無しさん＠お腹いっぱい。：03/06/07 19:14
サーバに友人のＨＰを置かせてあげているのですが、ＭＯなどの別機器がない場合、
どのようにバックアップすればよいでしょうか？理想では、ＬＡＮ内に繋がった
Ｗｉｎｄｏｗｓマシンでバックアップを取れればよいのですが・・・。
その友人は別ユーザでログインしており、安全のためパスワードは教えて貰ってい
ません。
510 ：名無しさん＠お腹いっぱい。：03/06/07 19:20
>>509
> その友人は別ユーザでログインしており、安全のためパスワードは教えて貰ってい
> ません。
rootにはそんなもん関係ないっつーか。


何かこの質問からアヤシイ匂いを感じるのは漏れだけかな。
511 ：名無しさん＠お腹いっぱい。：03/06/07 19:59
>>510
他のパソコンからは、どのプロトコルを使用すればよいのでしょうか？
ＦＴＰはルートでログインできませんし・・・。
512 ：あぼーん：あぼーん
あぼーん
513 ：名無しさん＠お腹いっぱい。：03/06/07 20:32
>>510

禿同。同鯖の連中をクラックしたいだけに思える
514 ：名無しさん＠お腹いっぱい。：03/06/07 20:38
>>513
自宅サーバなので、相手のファイルの中身を見るのはとても簡単です。
ルート権限で書き換えるのも簡単です。
貸している相手もそれを承知で使っています。
どちらにしろ、ＨＴＭＬファイルなので外部に公開している訳ですが。
ただ、テープドライブやＭＯ等の機器なしに簡易に一括してバックアップを
取る方法がないかと思いまして・・・。
515 ：名無しさん＠お腹いっぱい。：03/06/07 20:55
そういう基本的な知識も無い奴がサーバ立てるのか... 嘆かわしい。
516 ：名無しさん＠お腹いっぱい。：03/06/07 21:00
>>515
趣味のようなものですので・・・。
すみませんが、教えて頂けませんか？
517 ：名無しさん＠お腹いっぱい。：03/06/07 22:06
>>516
ｲﾔ
518 ：名無しさん＠お腹いっぱい。：03/06/07 23:03
>>516
そうなら、別にレスして貰わなくてもいいです。
519 ：名無しさん＠お腹いっぱい。：03/06/08 03:10
>>509
tarなどで固めてwindowsマシンからそれを吸う。
自動化の方法は自分で調べて＆考えて。なんぼでもあるでしょ。


あと


>>516
調べた？考えた？試してみた？その上での質問？
甘っちょろい考えが許されないのは2chも人生も同じよ？

>>515
禿同
520 ：あぼーん：あぼーん
あぼーん
521 ：名無しさん＠お腹いっぱい。：03/06/08 09:33
>>519
一応、ｔａｒで固めることまでは調べていました。
なるほど。それと自動化を組み合わせればよいわけですね。

ただ、他にも方法がないものかと考えていました。
「バックアップサーバ」という言葉を聞いたので、他のＬｉｎｕｘマシンから吸うときに
どのプロトコルを使用するのかと思いまして・・・。

みなさんは、どのような方法でバックアップされているのか知りたくて質問しました。
このような分野では、企業に入っているか近くにサーバをたてている友人などがいない
限り、一般的にどのような方法を採るものなのかがわかりにくいですよね・・・。
522 ：名無しさん＠お腹いっぱい。：03/06/08 10:20
頭が悪い奴にはな。
523 ：名無しさん＠お腹いっぱい。：03/06/08 11:22
>>522
貴方がどれほど頭がよいのか分かりませんが・・・。
524 ：名無しさん＠お腹いっぱい。：03/06/08 11:24
cpioはrpmをばらす時にしか使わないテスト。
525 ：名無しさん＠お腹いっぱい。：03/06/08 14:07
ショボイレスでスレ伸ばすのヤメレ...
ま，釣りのような気がしないでもないが，ちょっと釣られてみる．

>514
"テープドライブやＭＯ等の機器なしに簡易に一括してバックアップ"
って，具体的にどういうのをイメージしているんでしょ?
別メディア化したくない，という風に読めますが...???
526 ：名無しさん＠お腹いっぱい。：03/06/08 14:38
>>519

ある程度大規模なシステムの場合だと
それこそ専用のディスクアレイ装置を使ってFibreChannelで複数台ぶら下げる。
で、ディスクの中身をRAID 0+1 構成にしておいて、しかもトリプルミラーにしておく。
ミラーの１面と２面と３面があるという感じだな。

で、通常は１面＋２面＋３面でRAID1を組んでおき、バックアップのタイミングで
３面をミラーから切り離す。
切り離した３面目をバックアップを専門に行うマシン（別に特殊なものではなく、
バックアップ用ソフトとテープチェンジャがくっついたマシン）で吸い上げるという感じ。

３面目を切り離す時にはファイルシステム上の矛盾が起きないようにしなくちゃいけないけど
大概の場合、それはアレイ装置もしくはバックアップ用ソフトとセットになっている
ソフトウェアを組み込んで、ソフトウェアレベルで処理するような感じ。

とまあ、これがだいたい数千万級のディスクアレイ＋バックアップシステムの構成。

続く。
527 ：名無しさん＠お腹いっぱい。：03/06/08 14:43
もうちょっと予算を抑えたい場合（バックアップに専用のマシンぐらいは立ててもいい）
場合は、バックアップ用マシンにでっかいディスクをくっつけておいて、そこをNFSで
Exportしておく。

で、バックアップを取るマシンはそのExportされた領域をmountしておき、
tarなりufsdumpなりdumpなりで取ったバックアップをNFSで書き込む。

物理的にデータを逃がしたい場合は、バックアップサーバにMOなりDVD-RAMなり
DLTなりLＴOなりExabyteなりDDSなりくっつけておいて、リムーバブルメディアに
ちゅるちゅる吸い出して金庫に保管とか。

こうしておけば、バックアップ対象となるマシンを止めることなく、また、
物理的に弄ることなくデータを逃がすことができる。
528 ：名無しさん＠お腹いっぱい。：03/06/08 14:49
さらに続く

ようは、バックアップしたデータを同一マシンに置いておいちゃ意味がないので
どうやって別のマシンなり媒体に逃がすかだと思うのね。

で、企業なんかだと（少なくとも私が関わっているところだと）上に挙げたような
方法でやっているわけです。

個人レベルで実施するなら、先にも答えましたがftpだとかscp、または
samba経由でwindowsマシンから吸うとか、その程度で済ませちゃうのが
手軽でいいかなと思います。

おしまい。
529 ：名無しさん＠お腹いっぱい。：03/06/08 22:26
tarでパーミッションも一緒に固めれる方法教えてください。。
530 ：名無しさん＠お腹いっぱい。：03/06/08 22:34
>>529

普通にやればパーミッションついてるよ。

tar cvf backup.tar /need/to/be/save
less backup.tar

これで中身の属性が見られる。

解凍時にrootでやらないと、chownできないよ。
531 ：名無しさん＠お腹いっぱい。：03/06/08 22:36
>>530
展開時に p オプションもお忘れ無く。
532 ：名無しさん＠お腹いっぱい。：03/06/08 23:14
アーカイブ時にも意味なく p オプションつけている雑誌記事が時々あるな
533 ：名無しさん＠お腹いっぱい。：03/06/08 23:59
癖なんでしょうね。と好意的に解釈(笑

俺もtarの第１引数に z とか Z とか j とか含めて gnu tar じゃない tar で
「そんなオプション知らん」と言われること多々。

身体が覚えてしまってるからなあ。
534 ：吉川洋太郎（仮名）：03/07/03 22:41
tgzの拡張子は何と呼んでますか？
私はターグーズです。
535 ：名無しさん＠お腹いっぱい。：03/07/03 23:26
ターゲーゼー。
tbzはターベーゼーね。
536 ：名無しさん＠お腹いっぱい。：03/07/04 21:43
bz2は？
537 ：名無しさん＠お腹いっぱい。：03/07/04 22:04
ベーゼードバ？
538 ：名無しさん＠お腹いっぱい。：03/07/04 22:15
tar.gzは?
zipは?
lhzは?
539 ：名無しさん＠お腹いっぱい。：03/07/04 23:35
zipはいくらなんでもジップじゃないのか?
540 ：名無しさん＠お腹いっぱい。：03/07/05 05:30
ジプーだす
541 ：名無しさん＠お腹いっぱい。：03/07/07 13:12
>>536 ビージーズ　・・・苦しいか。

マジレス、ビーゼットツーって呼んでます。
542 ：名無しさん＠お腹いっぱい。：03/07/08 05:33
スレ違いの話はそろそろやめてよ
543 ：あぼーん：あぼーん
あぼーん
544 ：名無しさん＠お腹いっぱい。：03/07/18 07:00
〒
545 ：名無しさん＠お腹いっぱい。：03/07/19 02:55
lzhで良いじゃん。
546 ：名無しさん＠お腹いっぱい。：03/07/19 03:55
etc/以下をlzhでバックアップしてたら、
いざという時に解凍できなくて不便だったことが…
547 ：名無しさん＠お腹いっぱい。：03/07/19 16:16
/dev以下じゃなくて？
何で？
548 ：名無しさん＠お腹いっぱい。：03/07/19 16:39
正直、lzhならオプション指定とかで悩む必要もなく、zip並の圧縮率で
ファイルを処理できるけどな。
パーミッションやシンボリックリンクにも対応してる。
tar.gzよりは良いと思うけどなぁ。

まぁ、英語圏の標準じゃあないんだけど。
549 ：あぼーん：あぼーん
あぼーん
550 ：名無しさん＠お腹いっぱい。：03/07/19 22:34
>>546
lha コマンドがない環境だということじゃないかな
551 ：名無しさん＠お腹いっぱい。：03/07/21 00:17
portsにlhaがあるよ。
フルバージョンの奴が。
552 ：あぼーん：あぼーん
あぼーん
553 ：名無しさん＠お腹いっぱい。：03/07/22 18:54
etc のバックアップを戻さなきゃならんような状況ってのはわりと非常時だと思うが、
そんなときに呑気に lha のインストールなんぞやっとれんような。

ちなみに、sash というシェルは tar と gzip がビルトインなので、
緊急事態用に入れておくとよかれ。mount とか dd とか ed とかも
ビルトインなので、/bin、/sbin 以下が全滅しても sash が残っていれば
なんとか復旧できるかもしれないと言えなくはないと思わんこともない。
554 ：名無しさん＠お腹いっぱい。：03/07/22 19:04
どんな熟練のemacs使いでも、viやedの最低限の操作は覚えとくべきだというのと
似たようなもんかねえ。
555 ：名無しさん＠お腹いっぱい。：03/07/22 21:35
でも、tar.gzって1バイトでも欠けるとそれ以降のファイルはすべてだめになるじゃん。
gzが止まって読めなくなる。
zipやlhaならそういう事は無いよ。
一部が壊れても、ほかのファイルはちゃんと読み出せる。

556 ：名無しさん＠お腹いっぱい。：03/07/22 22:02
tarで纏めた時点で1つのファイルだと思うが。
557 ：名無しさん＠お腹いっぱい。：03/07/22 22:07
>>555
多少機能が上でも標準で入ってないコマンドは使いたくないのだよ。
個人的には、特許関連とかグレーなものも使いたくない。
558 ：名無しさん＠お腹いっぱい。：03/07/22 22:16
>>556
こういう話のことじゃない?
http://www.linux.or.jp/JF/JFdocs/Backup-mini-HOWTO/tar-gz.html
559 ：名無しさん＠お腹いっぱい。：03/07/22 22:20
そもそも/usr以下のバックアップなんて何使ってもいいんじゃないの？
560 ：名無しさん＠お腹いっぱい。：03/07/22 22:25
/bin,/sbinで展開できるならね
561 ：名無しさん＠お腹いっぱい。：03/07/22 22:33
俺は再インスト、データ直上書きリブート野郎なので、正直lhaで間に合ってますわ。
freebsdですし｡
562 ：名無しさん＠お腹いっぱい。：03/07/22 23:08
>>558
いや、それは判っていて「それ以降のファイル」という表現に
ツッコミを入れたのだが。
563 ：名無しさん＠お腹いっぱい。：03/07/22 23:24
>>562
察してやれよ。
564 ：名無しさん＠お腹いっぱい。：03/07/25 08:58
死ねカス
565 ：名無しさん＠お腹いっぱい。：03/07/30 11:05
きな臭いのが一匹いるな。
566 ：あぼーん：あぼーん
あぼーん
567 ：名無しさん＠お腹いっぱい。：03/08/04 06:28
きな臭いって何？
568 ：名無しさん＠お腹いっぱい。：03/08/04 11:12
きなこ臭いの間違いだろ
569 ：名無しさん＠お腹いっぱい。：03/08/05 09:07
きなこじじいのようだな。
570 ：名無しさん＠お腹いっぱい。：03/08/05 09:09
どっかショートしてんじゃないの。まさにバックアップの出番だな
571 ：あぼーん：あぼーん
あぼーん
572 ：名無しさん＠お腹いっぱい。：03/08/29 19:35
山崎うぜぇ
573 ：名無しさん＠お腹いっぱい。：03/09/13 18:08
ＤＩＳＫのバックアップってどうよ？
速いかもしれないけどまだまだＬＴＯとかのテープ媒体の方が
安いよなあ？今ひとつメリット見出せないんだけど、みんなど
う思う？


574 ：名無しさん＠お腹いっぱい。：03/09/13 20:25
トーシロの質問で申し訳ないですが。。

アーカイブの過程でトラブることって想定するもんなんですか？
1, バックアップ対象をtarなりgzipで処理
2, アーカイブをメディアにコピー
っていう時、2においてビット毎の比較はやったりするんですが、
1の時にも比較するべきかな、とか思ってしまいました。
実際に展開してみてオリジナルと比較をとるのも二度手間でアホくさいし。
手練の皆様の御意見をお聞かせ願えませんでしょうか
575 ：名無しさん＠お腹いっぱい。：03/09/13 22:57
>573
価格が byte 単価を指すのであれば最近はむしろ HDD の方が
安かったりしない? LTO2 ならイケるのかな?

いずれにせよ，tape メディアのいいところはドライブとメディアが
切り放されていて，ドライブがダメなら(原理的には)それを変えて
試せるというところと，HDD よりは保管が楽というところですね．

もちろん，byte 単価もあったんだけど，最近は HDD 安いからねぇ．
576 ：名無しさん＠お腹いっぱい。：03/09/14 00:57
>>575
バイト単価はLTO2のほうが安いかな。（ウチの取引先の値引きだと）
ＤＩＳＫの単価は１年もすればかなり下がるとおもうけど、世代管理
できないからねえ。

> tape メディアのいいところはドライブとメディアが
> 切り放されていて，ドライブがダメなら(原理的には)それを変えて
> 試せるというところと，
まあＤＩＳＫもタマごと取り替えれるから、これは別にかまわんのだが、

> HDD よりは保管が楽というところですね．
これがデカイんだよなあー。保管しやすいタマとかでてきて、単価下が
ればサーバフリーかつ高速なバックアップ環境をつくれるね。

まあ、とりあえず様子見です。
577 ：名無しさん＠お腹いっぱい。：03/09/14 01:28
>>574
心配ならやればいいんじゃねーの?
578 ：名無しさん＠お腹いっぱい。：03/09/14 01:41
>>574
1.の段階でトラブルって、コマンドそのものが
信用できないってこと？
579 ：名無しさん＠お腹いっぱい。：03/09/14 02:01
>>578
引き数間違えてたりしないか、ってことかも。
580 ：574：03/09/14 02:30
>>577,578,579
お返事ありがとう。

うん、信用できないっていったらアレなんですが、ここは盲目的に
コマンドとその出力を信頼しちゃっていいところなのかどうかが知りたいんですよ。
#十二分に運用実績はあるんだろうけど、念のため。引数チェックも含めて。
でも皆さんの反応を見ると、コマンドに起因するトラブルは無いと考えていいのかな？
581 ：名無しさん＠お腹いっぱい。：03/09/14 02:35
>>580
なんでそんな結論になるんだ?
582 ：名無しさん＠お腹いっぱい。：03/09/30 05:51
>>580
なくはないけど、滅多にない。
だから、半ばどうでもいいような場合はチェックしない。
貴重なデータなら、面倒でも復元してチェックする。
583 ：名無しさん＠お腹いっぱい。：04/01/09 01:59
>>347-356
遅レスでで申し訳ないのですが、シンボリックリンクのタイムスタンプを
維持したままコピーするツールは無いのでしょうか。
パーティションに余裕が無くなったので新しいHDDに
移そうと思っているのですが、タイムスタンプが変わるのが
なんとなくいやで、実行できていません。
dump,tar,rsyncは試したのですが、シンボリックリンクの
タイムスタンプは維持できないようです。
最終手段としてtouchで無理やりタイムスタンプを戻そうと
しましたが、これも本体のファイルが変わるだけで
シンボリックリンクのタイムスタンプは変わりません。
何か方法はありませんか？
584 ：名無しさん＠お腹いっぱい。：04/01/09 08:57
そのためのシステムコールがOSにあって、
さらにツールが対応してないと、駄目。
585 ：名無しさん＠お腹いっぱい。：04/01/26 21:26
FreeBSDなんですが、最近HDが怪しくなってきてまして、
バックアップしてHD交換して復元したいと思っています。
セカンダリのHDをつなげてバックアップ後にプライマリと入れ替えてしまうことは可能ですか？
586 ：名無しさん＠お腹いっぱい。：04/01/26 21:43
>>585
可能です。
587 ：名無しさん＠お腹いっぱい。：04/01/27 16:11
>>586
具体的に手順を指導していただく事は可能ですか？
588 ：名無しさん＠お腹いっぱい。：04/01/27 16:59
>>587
fdiskしてdisklabelしてdumpしてrestoreして
disklabelでboot書き込めばおしまい。
589 ：not 588：04/01/27 19:18
>>588
そうか。最近のFreeBSDのdisklabelにはnewfsの機能もあるのか？

>>587
ハードディスクのコピーは当然可能だが、
それをここで質問している君には不可能だろうな。
590 ：名無しさん＠お腹いっぱい。：04/01/27 20:13
>>587
ケーブルをつなぎかえるだけです。
591 ：名無しさん＠お腹いっぱい。：04/02/28 04:57
pdumpfsって必ずdailyにやるように指示されてるけど、weeklyだと何か問題でもあるのでしょうか？
592 ：名無しさん＠お腹いっぱい。：04/02/28 06:23
毎日取らないとバックアップの意味合いが薄れるということだけでしょう
593 ：名無しさん＠お腹いっぱい。：04/02/29 13:43
>591
もともと差分で扱うシステムなんで，それほど頻度をあげても
容量も手間もかわらんということでは?
594 ：名無しさん＠お腹いっぱい。：04/03/09 22:43
まあ、バックアップなんて、ピンきりだわな。

そのへんで売ってるような、安物ディスクから、軽く億を超えるオーダーのディスクまであるし、
これをバックアップする装置だって、ピンきりだ。

億を越えるディスクのバックアップだったら、テープアレイ使っても安いもんだ。
テープのメディア代なんて、ゴミみたいなもんだ。

安物ディスクのバックアップは、バックアップの意味もわからん香具師は、
ディスクtoディスクでいつまでも勘違いバックアップやってりゃいいってことだな。

不毛な議論だな・・・
595 ：名無しさん＠お腹いっぱい。：04/03/10 22:40
>>594
disk to diskの勘違いバックアップってどゆ意味？
596 ：名無しさん＠お腹いっぱい。：04/03/10 23:34
>594
俺もホットスワップベイでディスク入れ替えてディスク２ディスクでバックアップしてるので非常に気になる。
コストとスピードで一番現実的な解だと思うのだがまずいのだろうか？
597 ：名無しさん＠お腹いっぱい。：04/03/17 11:02
Maildir形式のメールデータについての
バックアップを考えています。

tarにより、対象メールデータディレクトリを
テープへバックアップさせると、
MaildirではMailBoxの様に
全メールデータが1ファイルに保存されるわけ
ではないので、新規メールが来た場合、
少なくとも受け取ること
（HDDに書き込まれること）は可能ですよね？
598 ：名無しさん＠お腹いっぱい。：04/03/19 10:10
>>596

個人の自己責任でやってる分には、いいんじゃないの。

同じシステム上にバックアップがあることじたいがまずいんではないかと思われる。
誤操作で消しちゃったり、ウィルスで消えたり、物理的要因以外に元に戻せなくなる、
可能性があるから、そういう意味ではバックアップではないかもしれん。
599 ：名無しさん＠お腹いっぱい。：04/03/19 10:30
> 同じシステム上にバックアップがあることじたいがまずいんではないかと思われる。
>
いや、ホットスワップなんでローテーションで入れ替えてるんだけど。

なにがまずいんだろう、594さん教えてちょうだい。
600 ：名無しさん＠お腹いっぱい。：04/03/19 11:14
>>599

ホットスワップで普段は、外部に保存していたとしても、バックアップを戻すときには、
システムに接続しなければいけないはずだから、その時には、やっぱり誤操作とか、
ウィルスとかの危険性は同じになっちゃうから、やっぱまずいと思う。

601 ：名無しさん＠お腹いっぱい。：04/03/19 12:36
downmark パッチは本体に取り入れられないんでしょうか
602 ：名無しさん＠お腹いっぱい。：04/03/19 12:51
NetVaultどうかな？
金出すくらい便利になる？
603 ：名無しさん＠お腹いっぱい。：04/03/19 12:52
s/金出すくらい/金出しても良いくらいに
604 ：602：04/03/20 10:25
NetVaultあんまり使われて
ないのかな．．．
605 ：名無しさん＠お腹いっぱい。：04/03/20 18:26
NetVaultに限らず
わざわざ商用ソフトを使うメリットがよく分からない。
製品によってはGUI操作が必須で
コンソールが使えなったりするし。
そうなるとシェルスクリプトから呼び出すとかはできないわけで。
tar, dump, rsync あたりで十分だと思ってるけど。
606 ：名無しさん＠お腹いっぱい。：04/03/20 21:07
>>604,605
オートローダ使っているから
デバイス操作は
tarやdumpやnfsdumpだけではできない。
NetVaultは多くのオートローダに対応可能。
607 ：名無しさん＠お腹いっぱい。：04/03/24 23:52
バックアップを取っていて、助かったディレクトリは/etc以外に何がありますか？
といっても環境が人それぞれなので、

「いやー、これをピンポイントで取っておいてよかったよ」みたいなものが
あれば教えてください。

システム障害時には、再インストするぐらいのサーバです。
RAIDもテープ、バックアップ用ハードディスクも無い、
tarで固めてftpする程度なので・・・。
608 ：名無しさん＠お腹いっぱい。：04/03/25 00:48
>>607
/etcだけから再構築してみれば？
609 ：名無しさん＠お腹いっぱい。：04/03/25 10:01
どんだけインストールしてるかにもよるけど
沢山プログラムをインストールしてるなら最初から構築する手間を考えて
/usr/local 以下等も有った方がいいかも
でどうせそこまでするならdumpで全部とっても良いと思う
逆にそれが必要ないのなら/etc以下もいらないんじゃないの？
610 ：名無しさん＠お腹いっぱい。：04/03/25 10:03
>>607
インストール後に変更した/されたファイルを取っとけ。
611 ：607：04/03/25 22:04
/usr/local/ は apacheぐらいなので、一応取ってます。
というのも、バックアップの目的は「confが書くのが面倒」だけなもので、

bind、postfix、apacheぐらいで、ログも必要ないので、
たしかに/etcがメインだけでいいかもしれません、ありがとうございました。
612 ：名無しさん＠お腹いっぱい。：04/03/27 04:28
すまんどす、windows向けのpdumpfsみたいなツールないですか？
613 ：名無しさん＠お腹いっぱい。：04/03/27 09:09
>612
Windows の file system(NTFS,FAT*)に hard link ってありましたっけ?
614 ：名無しさん＠お腹いっぱい。：04/03/27 09:19
>>613
NTFS にはある。ディレクトリのハードリンクもつくれるという代物。
615 ：614：04/03/27 09:29
スマソ違った、ディレクトリに対してはシンボリックリンク相当のものだけ。
616 ：名無しさん＠お腹いっぱい。：04/03/28 17:07
pdumpfs をもとにした mdumpfs というのがある
617 ：名無しさん＠お腹いっぱい。：04/04/03 09:26
すげぇ、本当にあるとは思わんかった＞win用pdumpfs
618 ：名無しさん＠お腹いっぱい。：04/04/03 10:26
make_tape_recovery 萌え
619 ：名無しさん＠お腹いっぱい。：04/04/03 22:37
dumpって遅くね？
何で4つもプロセスが立ち上がってランダムアクセスするの？
ヘッドシークばっかりで転送速度落ちるんだけど。
620 ：名無しさん＠お腹いっぱい。：04/04/04 20:00
>>618
それって結局 tar じゃねーか。
621 ：名無しさん＠お腹いっぱい。：04/04/04 23:23
やっぱりpaxだろ？
622 ：名無しさん＠お腹いっぱい。：04/04/06 22:30
rsyncつかっているのですけど

オプションに -auvの-avの違いがわからないのです。
一応説明では、-uは「-u 追加されたファイルだけバックアップする」
とあるのですが、-auvでも-avでどっちも同じような気がするのです。

試しに、2chのログのバックアップに使ったのです。

-avは新規取得スレだけバックアップ
-avuでは、新規取得スレ＋取得済みの更新スレをバックアップ

となるところですが、

-auvでも、既得済みの更新スレをバックしているのです。

う～ん
623 ：名無しさん＠お腹いっぱい。：04/04/06 22:49
>>622
man 見てもわからないか?
> -u, --update update only (don't overwrite newer files)
624 ：名無しさん＠お腹いっぱい。：04/04/06 22:57
>>623
なるほど。
「バックアップ先に、バックアップ元より、新しいファイルがある場合は書き込まない。」という意味でしたか。
625 ：名無しさん＠お腹いっぱい。：04/04/06 23:43
英語がわからないとunixは(ry
626 ：名無しさん＠お腹いっぱい。：04/04/07 00:12
その前にちゃんと日本語で質問できるように(ry
627 ：名無しさん＠お腹いっぱい。：04/04/07 11:14
>>607
~/.ssh/以下を取っておく。
628 ：名無しさん＠お腹いっぱい。：04/04/07 23:27
>>627
それは確かに重要だ
629 ：名無しさん＠お腹いっぱい。：04/04/19 19:43
すみませんが、man 見ても判らなかったので、
rsync について、教えてもらえないでしょうか。

rsync で A ディレクトリの内容を、定時に B
ディレクトリに移しています。条件は、削除は
せず、ファイル名が一致したときのみ上書き
する、という設定です。

そこで、Bフォルダの内容が本当に要らなく
なったときに、FTPの 新しいアカウントで操作
し、１ファイルづつ削除できるようにしようと考え
ています。

しかし、Bフォルダは、Aフォルダから所有者を
引き継いでいるので、削除処理を、新しいユー
ザーが行なうことができません。

そこで、rsync の後に、　chmod [user]:[user] -r B
としようと思うのですが、rsync は、更新要件
チェックで、所有者が変わったことについても
更新が必要と判断するのでしょうか？所有者が
替わることで、rsync 実行時に、再度、前と同じ
所有者のファイルを上書きされるのがNGなので。

ご存知であれば、宜しくお願いします。
630 ：名無しさん＠お腹いっぱい。：04/04/20 01:58
>>629
実際に試してみる、ということも大事だよ
明日までの宿題だったらともかく
631 ：629：04/04/20 09:59
早速やってみました。アドバイスサンクス。

chown -R user:user ./B/test/

などとやってみて、その後に、rsync を実行。
すると、ファイルは更新されなかったのですが、
上記　./B/test/　および以降のサブフォルダ
全ての権限が、元に戻されてしまいました。

rsync のファイルリストの構築順を見てみると、
./B/test/ 以降を全て再評価しようとしている
ようにも思えます(ファイルは更新されませんが)。

よって、フォルダBにアクセスできるFTP権限で
削除を行なおうとしても、フォルダのオーナーが
違うために操作ができない状態です。

何か、いい方法はないでしょうか・・・・？
・rsync で、更新時評価で、所有者を無視する設定
とかあればいいのですが・・・
632 ：名無しさん＠お腹いっぱい。：04/04/20 10:35
>>631
その２つのユーザーを同じグループに
入れるのはダメなの？
633 ：名無しさん＠お腹いっぱい。：04/04/23 14:43
OSによるけど、その上でグループのStickyビットが有用だね。
634 ：名無しさん＠お腹いっぱい。：04/05/15 15:52
pdumpfs をずっっと FreeBSD で使っていて、今度 Linux で
使うことにしました。しかし動作が違うところがあります。
FreeBSD なら前回と変更の無かってディレクトリでもハードリンク
が張られ、毎回表示されるのですが、Linux の場合は変更の無かった
ディレクトリはバックアップされません。

/home/hoge/a (前回から変更なし)
/home/hoge/b (変更あり)

[FreeBSD の場合]
# ls /backup/2004/05/15/home/hoge
/backup/2004/05/15/home/hoge/a
/backup/2004/05/15/home/hoge/b

[Linux の場合]
# ls /backup/2004/05/15/home/hoge
/backup/2004/05/15/home/hoge/b

こんな感じです。ハードリンクによる扱いの違いでしょうか？
よくわかないのでアドバイス下さい。
635 ：名無しさん＠お腹いっぱい。：04/05/16 18:59
うちじゃ，
そんなことはないですねぇ．
Linux 2.4.25， ファイルシステム，ext3
pdumpfs 0.8
636 ：名無しさん＠お腹いっぱい。：04/05/16 20:19
OS のバージョン
ruby のバージョン
pdumpfs のバージョン

plz
637 ：635：04/05/17 04:07
rubyは1.6.7です．
638 ：629：04/05/24 00:19
ひさしぶりのUNIX板ですが、参考までに、解決策を報告します。

グループとオーナーを、rsync実行時にチェックしていたのは、-a
オプションを付加していたからでした。

オプションを変更し、rlptD とすることで、rsync 実行後に、転送先
ディレクトリのオーナーとグループを全て変更しても、次回のrsync
で全評価を行なうようなことはなくなりました。

ちなみに、こんな感じで使っています。

■バックアップ元フォルダ /home/*
　→ProFTPd を使っていて、各ユーザーは、　/home/~ 以下を / として利用します。

■バックアップ先フォルダ /mnt/bak/
　→これは、nfs で共有した別マシンの領域。
　　但し、このフォルダは、ftp ホストの bk 　　ユーザーの権限にしています。

■rsync オプション　-rlptDv --exclude /home/bk/
　→cron.d に登録し、メイルで v オプションの出力結果を　　得るようにしています。

■削除方法
　元ファイルの削除→各ユーザーが自身で行なう。
　バックアップの削除
　　　→proftpdの設定で、bk のftpルートを/mnt/bak/へのリンクとしているので、
　　　　　bkユーザーがftp を通して行なう。

639 ：629：04/05/24 10:46
あ、rsync した後、毎回、chown -R bk:bk /mnt/bak　してます。
いずれも、cron に登録したスクリプトで順次処理します。
640 ：名無しさん＠お腹いっぱい。：04/09/09 04:48
今時のハードディスクは信頼性が皆無だからハードディスクバックアップなんてうんこ。
大昔の3GBのディスクがまだまだ現役なのに1年前に買った大容量ディスクが先に逝くってどういうことだ？
だからこそDVD-RAMとかを護衛につけないと心配。
641 ：名無しさん＠お腹いっぱい。：04/09/09 12:54
12年前のディスクがいまだ現役です
642 ：名無しさん＠お腹いっぱい。：04/09/09 13:03
20～40MBとか？
643 ：名無しさん＠お腹いっぱい。：04/09/09 16:01
意外とフロッピーじゃね?
644 ：名無しさん＠お腹いっぱい。：04/09/09 19:17
rsyncのように送り元と送り先のディレクトリツリーを同じにするツールはあるけど、
送り先にgzipなどの圧縮がかけられるツールはない？
更新バックアップは送り先のタイムスタンプを見るだけでいいはずだし。
これがあれば短時間で圧縮バックアップができていい感じなんだが。

アーカイバでまとめるやりかただと、巨大な圧縮ファイル全体を遅いDVD-RAMに運ばないといけないのが嫌。
645 ：名無しさん＠お腹いっぱい。：04/09/14 19:09:45
mdumpfsのバックアップディスクが手狭になってきたんで、容量大きめのを買い足して、
今までのバックアップをハードリンクを維持したまま新ディスクにコピーしたいのですが、
どのコマンドを使えばいいですか？
646 ：名無しさん＠お腹いっぱい。：04/09/14 19:38:40
cp -ax
647 ：名無しさん＠お腹いっぱい。：04/09/15 06:54:39
今時ハードディスクバックアップってのもなー。故障率高すぎるし。
だから俺、pdumpfs使うのやめたよ。
648 ：名無しさん＠お腹いっぱい。：04/09/15 07:59:54
バックアップとアーカイヴは違うだろ
649 ：名無しさん＠お腹いっぱい。：04/09/15 10:20:49
> 今時ハードディスクバックアップってのもなー。故障率高すぎるし。
こういう変な理屈持ち出す奴に限ってバックアップしてないよね

実際問題としてHDが大容量化してるのに手軽に行うには同容量のHDでバックアップしかないだろ
心配ならバックアップ用に複数台用意してコピーしとけば
確率的に両方のHDがダメになってる事は天文学的確率だから心配ないだろ。
それに故障率高杉ってなんだよ、他のメディアの方が高くないか？

でさ、HDでバックアップしない奴は今時の300GBとか1Tとかのディスクのバックアップをなにでやってんの？
650 ：647：04/09/15 11:37:07
ハードディスクすべてをバックアップする必要ないだろ。
頻繁にバックアップする必要があるのは更新頻度の高い一部分のみ。
だからハードディスク80GBとはいえCD-RWとDVD-RAMだけで間に合ってるさ。
故障率高いというのは店員の話と実際の体験談。
1年ちょいでハードディスクが逝ってしまわれたのだ。
651 ：647：04/09/15 11:46:56
>こういう変な理屈持ち出す奴に限ってバックアップしてないよね
安直な見解だ。当然のことだがcronで毎日バックアップしとるぞ。
バックアップ領域が大きいのならバックアップ周期ごとにDVD-RAMを取り換えればいい話。

>心配ならバックアップ用に複数台用意してコピーしとけば
ハードディスクを積みすぎると、今度は放熱の問題にもなる。

>それに故障率高杉ってなんだよ、他のメディアの方が高くないか？
カートリッジ付きのDVD-RAMだから大丈夫だと思う。少なくともハードディスクよりは。
652 ：名無しさん＠お腹いっぱい。：04/09/15 11:54:31
>>649､650
自分の運用と他人の運用を同列で見るからそうなる

だいたデータサーバとWebサーバを比較するのも
バックアップポリシーは大違い
>>649は明らかに頻繁にデータ変更されるサーバだろうし
>>650はWS等の話に受け取れるが

何をどこの時点までどれくらい確実に守るかが重要

653 ：名無しさん＠お腹いっぱい。：04/09/15 11:59:06
ちゅーかDVD-RAMでもHDDでもいいじゃん。
どっちも壊れるし。

端末まで行く手間と、バックアップ対象を絞って容量を考えるというミスを誘発する仕組み。というデメリットがあるんだし。
他人のやり方に文句を言う前に、HDDとDVD-RAM両方ですりゃいいじゃん。
654 ：名無しさん＠お腹いっぱい。：04/09/15 12:00:31
データサーバならテープが一番だと思うが。
655 ：名無しさん＠お腹いっぱい。：04/09/15 12:34:00
オススメの紙テープドライブはどれですか？
656 ：名無しさん＠お腹いっぱい。：04/09/15 13:12:30
紙テープドライブ？
657 ：名無しさん＠お腹いっぱい。：04/09/15 13:38:11
ウルトラDLT とか AIT-7 とか
658 ：名無しさん＠お腹いっぱい。：04/09/15 13:59:42
>>656-657
紙テープつったら8単位だろ

もうパンチャのリビルト終了されて困ってる
在庫持ってる香具師ｷﾎﾞﾝﾇ
659 ：名無しさん＠お腹いっぱい。：04/09/15 14:23:51
紙テープって波止場で船に向かって投げるやつでしょ？
660 ：名無しさん＠お腹いっぱい。：04/09/15 14:53:00
>>659
物理的には船から波止場のほうが楽だけどな
661 ：名無しさん＠お腹いっぱい。：04/09/15 15:49:57
＞647
HDDよりDVD-RAMが信頼性高いって思ってる時点で話になんないだろ
それにDVD-RAMってせいぜい9Gだし書き込みにいくら時間が掛かるとおもってんだ？
>>それに故障率高杉ってなんだよ、他のメディアの方が高くないか？
>>カートリッジ付きのDVD-RAMだから大丈夫だと思う。少なくともハードディスクよりは。
あのさ単価が安ければいいのか、じゃFD使ってろ！
普通はさ、容量/円だろ　から付きDVD-RAM、10枚つかったらいくらするんだよ

で根拠が店員の話で・・・ なんてな
もしかしてGTOのコピペのまねか？
釣られた？
662 ：661：04/09/15 15:51:03
コピペの場所間違えた
鬱
死んでくる。
663 ：名無しさん＠お腹いっぱい。：04/09/16 04:56:29
>>646

ありがとうございます。板違いを承知でお聞きしたいのですが、
Windows(2000/XP)のCygwinでも出来ますか？
664 ：名無しさん＠お腹いっぱい。：04/09/16 05:51:26
サーバ交換したのを機会に古いマシンをバックアップ専用にして
毎日2回 cron で rsync させてる。メインが具合悪くなったら
即交替できるし。あと、DVDへのバックアップもやってる。が、
これはまぁ時々ってかんじ。だって面倒くせんだもん。
サーバは qmail, mysql, apache, vsftpd とか。んなもん全部
一台に入れるなとか言わんでくれ。
665 ：名無しさん＠お腹いっぱい。：04/09/16 09:53:35
DVD-RAMも沢山使ってると、一回しか書いてなくてもいきなり片面だけ死んでた
りするからあまり当てにならない。
DVD-RAMのジュークボックス買うよりHDDのミラーの方が手っ取り早いし。

666 ：名無しさん＠お腹いっぱい。：04/09/16 11:34:51
DVD-RAMでいきなりI/O errorを起こした。でも
mke2fs -c -c /dev/dvd
をやったら生き返った。
667 ：661：04/09/16 12:04:33
DVDメディアって結構ばらつきが激しい
安定性を求めれば結局メーカ品割高な物を買わなければいけない
それでも数百枚に１枚くらいはエラーになったりする
その上書き込み安定性を求めれば他のプロセスを停止させなければならない
よって信頼性が求められるバックアップにDVD使うなんて狂ってるとしか思えないな。
まあ現実に使えるとすればp2p廚がダウンした消えても困らない様なエロ動画を保存するくらいじゃないの。
668 ：名無しさん＠お腹いっぱい。：04/09/16 15:01:26
>667
負荷がかかっているときは書き込み安定性が悪いってほんと?
バッファが干上がらない限りはどう書き込むかなんてドライブの方の
問題だと思うんだけど...
(FreeBSD で dvd+rw-tools 使ってます)

書き込んだ結果の品質を確認する方法ってなにかあるんでしょうか?
(雑誌でやっているみたいな業務用の測定器を使う方法の他に)
669 ：名無しさん＠お腹いっぱい。：04/09/16 17:43:07
>668
負荷がかかる＝バッファが干上がるじゃないの？
CPUが100%になったりIDEバスがビジーになれば自ずとエラーなりやすくなるのでは？
特にWinなんかではアプリがフリーズなんて珍しくないし、

>書き込んだ結果の品質を確認する方法ってなにかあるんでしょうか?
FreeBSDではやった事無いけど
DVD-Rなんかだと書き込んでいる最中にエラーになるよ
まあ俺の環境がぼろいのかもしれないけどね。
670 ：名無しさん＠お腹いっぱい。：04/09/16 18:15:21
>669
そういう意味では以前(CD-R時代)から unix 系(*BSD系?)は
負荷がかかっていても焼きに失敗するなんてことはぜーんぜんないよねー，
という話はありました．make world しながら焼くなんて朝飯前，とか．

で，unix 板なのでそういう環境を念頭に置いていたつもりでした．
cdrecord とかでも buffer 容量は楽勝，みたいな表示しか見たことないし．
671 ：名無しさん＠お腹いっぱい。：04/09/16 18:24:51
何年もやってるけど、焼き失敗したことないぜ？
672 ：名無しさん＠お腹いっぱい。：04/09/17 10:00:50
何年もやってるって？
でもDVDが使える様になったのってここ１年くらい、頑張っても２年迄じゃないの？
673 ：名無しさん＠お腹いっぱい。：04/09/17 10:18:04
>>672
松下の片面2.6Gケース入りを発売当初から使ってるが
もう5年以上は経ってると思うが
さすがに近年はDVD土Rだが
674 ：名無しさん＠お腹いっぱい。：04/09/17 15:38:25
＞673
そうなんか、知らんかったよ
Win系で安定して使える様になったのがここ２年くらいだったんでUNIX系はもう少し遅いと思ってた
かなり進んでたんだな
でもメディア単価迄含めたバックアップに実用的かどうか考えるとどうなんだろうね
そんな昔ならメディアも超高級だったんじゃないのだろうか？
それでもDVDを使う価値があったの？

俺の考えではバックアップはコストも重要だと思うのだが。
675 ：名無しさん＠お腹いっぱい。：04/09/17 15:58:36
>>674
つーかさぁ
その時代は対抗馬DATだよ実質2Gパンパンの
（DDSは2.6Gなんだが）

事情はまちまちだろうがウチはデータスペースが速攻で
埋まっていたので
DATで2Gを多用したがメディアもそう安くもないし
最後の方のでーた読み出すには泣きたいほど時間がかかった
1G落としで本数を使って時間を稼いだが
ランダムアクセスのメディアには飛びついたよ

バックアップであり書庫であったため
DDS3も入れたけどユーザは速攻の復帰を願うので
やっぱDVD
最近は時代が変わってHDDを多用して最終保存にDVD-R
障害対策のバックアップはHDDのみ
676 ：名無しさん＠お腹いっぱい。：04/09/17 16:27:40
>675
あのー... "その時代" = "5年前" であれば
余裕で DDS3 生12GB があるし DDS が対抗というのはどう考えても変。

ちなみに DDS は 2GB(90m テープ;圧縮4GB)で 60m テープだと 1.3/2.6GB。
DDS2 で 4/8GB なんで >675 は DDS系使ったことがないこと確定。
677 ：名無しさん＠お腹いっぱい。：04/09/17 16:55:59
>>676
ちゃんと読んでよ「５年以上前」だってば
正確には記憶ないんだけど95から98年頃かなぁ？
2000年には達してない
DDS3はあったよ。DVDの少し前に買ってる
しかし上記の理由で人気はなかったからあまり使ってないのは確か
ちょっとした利用はマシンの標準DDSがまだ楽だったしね
DDS3はデータの保存には使わずシステムフルに使ってた

対抗するってのは量だけじゃないっしょ
1ファイルの読み出しと当初のDVDはRWなので
1ファイルの変更も可能なメリットはDATに勝ってた
678 ：名無しさん＠お腹いっぱい。：04/09/17 17:05:06
いま調べたら98年だったよ
DDS3買ったのは97年
DDS買ったのは93-4年だったかなぁ？
HP715-100だな
その前はたぶんHITACHIの2050とか
オムロンのFS180の一個前の型でのデータカセットテープだった

679 ：名無しさん＠お腹いっぱい。：04/11/01 21:43:00
バックアップめんどくさくなた('A`)
680 ：名無しさん＠お腹いっぱい。：04/11/01 22:55:11
>>679
と思って止めた瞬間に HDD というのはとぶものだ。
経験者は語る。
681 ：名無しさん＠お腹いっぱい。：04/11/02 12:09:48
手動でやるのはムリ。自動でやるようにしといて普段は忘れてるな。
結構助かってるよ。
682 ：名無しさん＠お腹いっぱい。：04/11/03 15:47:25
最近 pdumpfs を使いはじめたんですが、ヘルプでは -w と -s のショートオプションが
載ってますが実際には効きませんね。

それと試しに samba 越しにバックアップを取ってもみたのですが、Text file busy の
エラーが出るとそこで中止してしまいますね。最初の試行でとりこぼすファイルが
あったりして挙動がちょっとあやしい。ローカルでのバックアップはそういうことが
ないんですが。
683 ：名無しさん＠お腹いっぱい。：04/12/05 21:02:12
tarのインクリメントバックアップって便利だね。
Cygwin版のもそうだし。

tar -g
684 ：名無しさん＠お腹いっぱい。：04/12/30 00:00:03
そんなのもあったんだ。今度試してみようかな
685 ：名無しさん＠お腹いっぱい。：04/12/31 23:47:40
>>683
それ、やってたんだけど、挫折した。
どうも解凍時にフォルダ名によってエラーになって解凍出来てないパスがあったりして。
そんなトラブルない？
686 ：名無しさん＠お腹いっぱい。：05/01/01 22:21:08
baculaのメディアにリムーバルHDDを使用する事は可能なんでしょうか？

簡単にいってしまえばテープライブラリの代わりにHDDアレイを使いたいんですが。
687 ：名無しさん＠お腹いっぱい。：05/01/02 00:15:49
やっぱHOMRCFだろ。
688 ：名無しさん＠お腹いっぱい。：05/01/02 01:50:45
>>687
何それ？詳細キボンヌ。
689 ：名無しさん＠お腹いっぱい。：05/01/02 01:56:03
日立系ストレージのシャドウコピー機能。
690 ：名無しさん＠お腹いっぱい。：05/01/12 21:57:57
次の件で何かアドバイスを頂ければ幸いです。

rsyncか同様のツールを用いて
マシンAのユーザuser_aのホームディレクトリ以下全てを
マシンBのユーザuser_bの下に、
オーナーをuser_bとしてタイムスタンプ保持しながら
コピーする方法はありませんでしょうか？
691 ：名無しさん＠お腹いっぱい。：05/01/12 23:15:22
>>690
user_b の権限で rsync 動かせばいいんでは。
692 ：名無しさん＠お腹いっぱい。：05/01/13 03:18:34
user_a@MACHINE_A% rsync -avr ~ user_b@MACHINE_B:~
693 ：690：05/01/13 16:33:20
>>691
>>692
有難うございます。あっなるほどぉ。
っと思ってとりあえず1ファイルだけやってみたのですが、
画面表示は転送成功っぽいのですが、
ファイルが転送されていないのです。
何かアドバイスを頂ければ幸いです。

画面表示は次のようでした。
------ここから画面表示(一部改訂)-------
[user_b@machine_B ~]$rsync -avv user_a@machine_A:~/file
opening connection using ssh -l user_a machine_A rsync --server --sender -vvlogDtpr . "~/file"
Password:
receiving file list ...
expand file_list to 4000 bytes, did move
done
-rwxr--r-- 1206 2003/10/02 14:32:52 file
delta transmission enabled
total: matches=0 tag_hits=0 false_alarms=0 data=0

sent 16 bytes received 181 bytes 18.76 bytes/sec
total size is 1206 speedup is 6.12
[user_b@machine_B ~]ls file
ls: file: No such file or directory
-------------ここまで画面表示(一部改訂)----------
よろしくお願い申し上げます。
694 ：690：05/01/14 14:51:33
>>693
自己レスです。
私の不注意でした。
rsync -avv user_a@machine_A:~/file ./
のように転送先を指定することによって正しく転送されました。
ftpのgetコマンドのように捉えていましたが、
cpコマンドのように考えるべきだったのですね。
それにしても、転送先をしない場合のログはどこかに転送したような
メッセージですが、一体どこに転送されてしまったのでしょう？
695 ：名無しさん＠お腹いっぱい。：05/01/15 09:31:24
>>694
うちに来たよ。
696 ：名無しさん＠お腹いっぱい。：05/01/16 14:13:48
>>694
うちにも来た。
697 ：名無しさん＠お腹いっぱい。：05/01/16 19:24:15
nullpo
698 ：名無しさん＠お腹いっぱい。：05/01/16 23:00:15
　　 （　・∀・）　　　|　|　Gatt!
　　と　　　　）　 　 |　|
　　　 Ｙ　/ノ　　　 人
　　　　 /　）　 　 < 　>__Λ∩
　　 ＿/し'　／／. Ｖ｀Д´）/
　　（＿フ彡　　　　　 　　/ 　←>>697
699 ：名無しさん＠お腹いっぱい。：05/01/19 00:04:06
>>693
暗号化とか関係なくrsync -e sshにしようよ。
余計なデーモンたちあげなくて済むし、認証で鍵もつかえるし。
700 ：名無しさん＠お腹いっぱい。：05/01/19 00:05:33
ごめんsshつかってるね。生パスだから気づかんかった。
スレよごしｽﾏｿ
701 ：名無しさん＠お腹いっぱい。：05/01/19 00:38:18
>693
×[user_b@machine_B ～]$rsync -avv user_a@machine_A:～/file

○[user_b@machine_B ～]$rsync -avv user_a@machine_A:～/file .

702 ：690：05/01/26 19:59:02
>>699
>>700
御指摘ありがとうございます．
生パスを使わないやり方は私にはまだ先の話でして，
とりあえず手動で良いので転送できることが先決かと思って放置しております．
>>701

レスを有難うございました．

ええと，度々で恐縮なのですが，
一つのファイル転送の成功に気を良くした私はようやく，目標であった
「異なる計算機/異なるユーザのホームディレクトリ以下全てを転送」
しようと思って，
[user_b@machine_B ～]$rsync -avvr user_a@machine_A:~ .
とすると，machine_B:~user_b/user_aの下に転送されてしまいました
(考えてみれば当然なんですが...)．
また，
[user_b@machine_B ～]$rsync -avvr user_a@machine_A:~/* .
とすると，
rsync: 照合パターンに合いません.
なるエラーメッセージが表示されます(ワイルドカードが先に展開されてしまうから?)．
machine_A:~user_aの下全て(user_aを含まない)をmachine_B:~user_bの下に
転送する方法について
何かアドバイスを頂ければ幸いです。






703 ：名無しさん＠お腹いっぱい。：05/01/26 21:04:53
>>702
[user_b@machine_B ~] $rsync -auz -e ssh machine_A:/asoko/ /asoko
とやると machine_Aの絶対パス /asoko 以下のすべてが machine_B の
/asoko以下にコピーされる。というのを元にしてがんがってみてくれぃ。
704 ：690：05/01/27 15:59:09
>>703
アドバイスを有難うございました．
[user_b@machine_B ~] $rsync -auz -e ssh machine_A:~/
で目的を達成することが出来ました．

[user_b@machine_B ~] $rsync -auz -e ssh machine_A:~ ~
との違いはまさに
cp -r foo/ bar
と
cp -r foo bar
の違いだったのですね．
どうやらcpコマンドすら分かっていないようです．

有難うございました．
705 ：名無しさん＠お腹いっぱい。：05/01/30 23:02:46
まーrsyncの最後に/をつけるかつけないかの挙動はシェルとも微妙に違うので混乱しがちではある。
706 ：名無しさん＠お腹いっぱい。：05/02/01 21:55:32
pdumpfs はバックアップにハードリンクを利用しているけど、ハードリンクそのものには
対応していないんだね。実体をハードリンクの数だけコピーしている。実用的に問題に
なることはあまりないとは思うが。
707 ：名無しさん＠お腹いっぱい。：05/02/01 22:02:44
ぜんぜんしらなかったけどpdumpfsってのはそういう動作しんてんだ。
おもしろい。
iノードの消費が問題になりそうだけど、いまどきのファイルシステムは可変なのかな。
708 ：名無しさん＠お腹いっぱい。：05/02/02 00:10:48
いまどきのファイルシステムはsnapshotあるからハードリンクでごまかす必要が無い
709 ：名無しさん＠お腹いっぱい。：05/02/02 09:46:22
今時のファイルシステムの snap shotって多段階の
snapshot をまともに確保できる?
1,2段以上やると死ぬとかいうことはない?

>706
まあ単純なコードだからね。アイディアだけ拝借してパクって作り直すのも簡単。
rsync 使って相当品つくって使ってるんだけど、似たようなこと考える奴がいるな:
ttp://tach.arege.net/software/pdumpfs-rsync/

>707
pdumpfs の保存庫を dump/restore するのは
restore 側がほとんど対応不能になります(メモリを数GB とか平気で喰っちゃう)
710 ：名無しさん＠お腹いっぱい。：05/02/02 19:14:25
>709

うほ、こりゃべんり
711 ：名無しさん＠お腹いっぱい。：05/02/19 09:16:23
今一ヶ月に一回、CD-Rにバックアップ取ってるんですけど、
うまい管理方法とか、これに最適なCD収納ケースとか無いですかね
queue状に収納されて、24枚目より古いものは、最新のが入った時点で破棄される、みたいな
まあ挿入と破棄は手動でやるしかないんですが
712 ：名無しさん＠お腹いっぱい。：05/02/19 09:43:38
24枚収納のケースを買ってリングバッファ的にやるんじゃダメなん?
713 ：名無しさん＠お腹いっぱい。：05/02/19 10:28:20
>>15
ignite UXは？
714 ：名無しさん＠お腹いっぱい。：05/02/19 10:28:52
>>713
て二年前か。。。なっとく。
715 ：名無しさん＠お腹いっぱい。：05/03/10 20:24:21
このスレ的にはS-ATA2の期待度は？
716 ：名無しさん＠お腹いっぱい。：05/03/11 14:28:48
最近楽になったよなぁ。

大掛かりなシステムでなければ、最近はデータ領域のバックアップだけ、増設のATAHDDに
毎日RSYNCで更新して、事故ったらデータをシステムをバックアップしてたHDDに差替えて、
データを復旧するだけ。これが一番早いし確実。エンタープライズ向けの大型の同期バック
アップシステムを組むなら別だけど、俺はこれが一番。何といっても安いしね。
717 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 21:22:11
シンボリックリンク自体のタイムスタンプも
そのまま保存できるような、完璧なバックアップ方法はありませんか?
ufsdump | restore でも、tar | tar でも GNU cp -aでも、
シンボリックリンク自体のタイムスタンプは保存できず、
リストアするとオリジナルとは異なったものになってしまいます。

あと、できれば、ファイルのctimeとか、
i-node番号とか、ディレクトリ自体のサイズとか、
ls -fで見た時のファイルの順序とか、
sparseを含むファイルは元通り同じブロック位置にsparseを
含むようにとか、とにかくありのままに保存できる方法を
求めています。

ただし、ddでまるごと保存というのは無しで、
それ以外の方法でお願いします。
718 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 21:28:54
シャドウコピー
719 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 21:52:05
>>718
Shadow Copyも、概念的には dd でのコピーみたいなものでしょうから、
それ以外の方法でお願いします。

たとえば、ext3上のシンボリックリンクのタイムスタンプや、
ディレクトリエントリの順序を変えずに、
新しい UFS 上にコピーするとかのように、
異なるファイルシステム間での完全コピー方法です。
720 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 21:55:14
>ただし、ddでまるごと保存というのは無しで、
>それ以外の方法でお願いします。
なんで？
721 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 22:01:46
それがこのクイズのルールなんだからしかたない
722 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 22:12:57
symlink の時間については自分で作ればいいじゃん。

単に lstat(2)/lutimes(2) の面倒を見ないソフトが多い
(そのシステムコールがない OS もあるので)ってだけなんだから。

で、2番目以降は何か勘違いしているとしか思えない。
"dd で丸ごと保存したい" 以外に読み取りようのない内容を
第2段落に書いておいて矛盾する第3段落...
(ufscopy 位なら納得してもらえるのかね?)

多分 file system とか i-node の意味を勘違いしていると思われ。
723 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 22:36:25
>>722
勘違いしてませんよ。
ちょっと例は古いけど、Wnnの辞書みたいに
自分自身のi-node番号がファイルに書き込まれていて
これが変わるとwnntouchしないといけないので、それを避けたいのです。
コピー先で、該当のi-node番号は空いているものとします。

ディレクトリエントリ順については、
find とか tar とかは、ソート前のディレクトリエントリ順で
動作するため、この順を変えたくないのです。

symlink の時間は自分でやるって、そういうプログラムか
シェルスクリプトを自分で書けということですかね?
でも、lutimes(2)って、Linuxにはありませんね。

ddが駄目なのは、ファイルシステムを変えたい場合にも
対応できる方法が欲しいからです。
724 ：名無しさん＠お腹いっぱい。：2005/03/23(水) 22:53:05
>ddが駄目なのは、ファイルシステムを変えたい場合にも
>対応できる方法が欲しいからです。
ddのイメージを流し込め。
725 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 01:01:14
>723
明らかに勘違いしています。

i-node が変わって問題が起きるものも歴史的にはありましたが
それとこれとは話が別。

あなたが言っていることは無い物ねだりというか、矛盾して崩壊してます。
726 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 07:01:34
723 の言っていることは、無いものねだりかも知れんが、
別に矛盾はしてないんじゃないかな。
sym-linkのタイムスタンプ保存は俺もやりたいと思うことがある。
lutimes はどうも FreeBSDローカルっぽいし、
UNIX標準的な方法で完全なバックアップ・リストア方法が未だに
存在しない現状は何とかしないとな。
727 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 07:32:37
ddでイメージとって、ループバックマウント。
728 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 08:36:59
>726
symlink については >722 に書いたように対処すればできるので終了。
sparse の件も dump でも tar でも対処できるからいい。

問題は i-node のような本来 file system の内部構造にあたるものを
バックアップ後復元したいというのは file system について
誤解していることの証でしょう。
restore 先で既にその i-node が使われていたらどうすんねん。
つまり、"現在ある file system そのものを保存したい" と
言っていることと等価なのに、
一旦 "backup として抽象化して別ファイルシステムに再現したい" という
要求は矛盾とまでは行かなくても無謀な要求だと思う。

その他: ファイルの順序については... まあ元通りになって
困ることはないかもしれないけどそうならなきゃいけないものはない
(あったとしたらそっちの設計が悪い、と思うのが普通)。
729 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 08:56:55
>>728

723より引用:
>コピー先で、該当のi-node番号は空いているものとします。

とおっしゃっていますが。
目的のi-nodeナンバーが出るまでopen() unlink()を繰り返せば
原理的には可能なように思われるが。


728より引用:
>symlink については >722 に書いたように対処すればできるので終了。

symlink を、lutimesがないOSでどう対処するの?
730 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 09:34:39
>729
lutimes がないと出来ないから lutimes システムコールが
新しく出来たわけなのでそれこそ自明なんですけど。

前半は… 正気ですか? 現実的に可能だと思っているんですか?

# 昔 "i-node 番号指定でファイルをごにょごにょ出来たらいいのにな"
# とつぶやいていた方がいらっしゃいましたが、ちょっと考えて
# "やっぱダメだ" になってましたですな。
731 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 10:23:36
dumpが、rawレベルのファイルシステムに直接アクセスするのに対し、
restoreはあくまでnewfs(mkfs)した後のファイルシステムを通して
しかアクセスしないのが根本の原因の気がする。
つまり、dumpとrestoreは完全対称ではないと。

rawレベルのファイルシステムに直接アクセスする、新たな
restoreコマンドを作れば、lutimes()がなくても可能だろうな。
同様にi-nodeの保存も可能。
ufsとかext2とかで共通レベルの抽象化ができているなら、
ufsからext2へとか、その逆とかやっても、
symlinkやi-nodeは保存できると思われる。
732 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 11:12:33
とりあえず i-node 関連の話に限定させてください。

>731
やればできるけどそれは dd でコピーする以上に
頑張って実現する価値のある話なのか? それは正しい設計なのか?

i-node はあくまで file system の内部構造の話(*)であって
本来保存する必要性のないものでしょ。
Wnn が例外と言うか今となっては時代遅れの実装なだけ。

(*) 通常の file system の操作で i-node をいじれないものなので
733 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 11:37:02
犬厨はくだらないことにエネルギーを使うでFA?
734 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 11:39:37
チートを防ぐためにセーブデータに i-node 番号を埋め込む rogue があったり。
この場合、バックアップできないようにわざとそうしてるわけで。
735 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 12:28:30
>>732
i-nodeは、ls -i とかのユーザーレベルの操作で簡単に
見えるし、「i-nodeはfilesystemの内部構造だから、隠蔽すべきもの」
と言うには無理がある。
これが、例えば、ファイルの物理セクタ位置とかなら
確かに内部のみの問題なので、保存しても意味ないが、
i-node保存は意味あるものと俺は思うけど。
736 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 12:33:15
i-nodeの番号なんて銀行窓口の受け付け番号みたいなもんじゃん。
保存するのに意味なんかないべ。
737 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 12:44:56
>735
弄れますか?

ps でプロセス番号が見えるからプロセス番号を保存したいとか
弄りたいっていうのと同じに聞こえるんだけど、気のせいですか?
738 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 13:26:01
>>737
i-nodeは、直接的に番号を指定できないだけで、
ユーザー操作でいじれることはいじれる。

psのプロセスIDのように、プロセスの生存中しか有効じゃない
一過性のものと違って、i-nodeはディスクにしっかりと記録された
長期間使い続ける番号なので、プロセスIDと同列に考えるのはおかしい。

それから、NFSを経由しても、i-node番号は(v-node経由で)
ちゃんと保存されている。もし、i-node番号が内部データでしかないなら、
NFSでは切り捨てても良かったはずだ。(別の話だけど、NFSで
ファイルの削除時の挙動とかは一部切り捨てられてるよね)

ここまでちゃんと保存できているのに、dump | restoreの時は
保存できないのはやはりフに落ちない。
実際、Wnnやrogueの例もあるわけだし、
ちゃんと対応する価値はあると思うよ。
739 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 13:29:39
ファイルの生存中しか有効じゃない一過性のものでしょうに……。
740 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 13:34:42
ファイルが削除されても魂は不滅です
741 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 13:51:47
restore時に再生できないのに、
なぜdumpはi-node番号も含めて記録するんだ?
と言ってみるテスト。
742 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 14:18:03
そりゃファイルの実体はパスじゃなくてinodeに結びつけられてるからだろ。
ハードリンクの復元やインクリメンタルバックアップのチェックをinode抜きで
どうやればいいのか教えてくれよ。

743 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 15:01:49
>>742
tarはi-nodeを使わずにハードリンクを保存している。
いまどきインクリメンタルバックアップなどしないが、
GNU tarにはインクリメンタル相当の機能があったはず。
なので、i-nodeを使わなくても実現できるかと。
744 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 15:10:49
tar は 低位 file system に依存しない必要があるんで
そうなっているけど、
単一ファイルシステム内の話で i-node 使えば出来るものを
無理に他の手法を使う理由はないでしょ。
(特許回避じゃないんだから)
745 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 15:57:25
>>743
それはファイルをリネームしただけのときもdumpと同じ効率でインクリメンタルバックアップできるわけ?
746 ：名無しさん＠お腹いっぱい。：2005/03/24(木) 16:28:23
inodeがないfsを扱うときにhashでごまかすことがあるよね。
fatとか。
747 ：名無しさん＠お腹いっぱい。：2005/08/22(月) 14:38:30
ほっしゅほっしゅ
748 ：名無しさん＠お腹いっぱい。：2005/09/08(木) 02:02:14
ここで聞いていいのかな

mt ｺﾏﾝﾄﾞ に weof とか smk とかのｺﾏﾝﾄﾞが有るけど、このコマンドの使い方が
よく分かりません。

どういう場合に EOF ﾏｰｸを手で書き込む必要があるんですか？
ちなみに主にDDSかDLTかLTOを使ってます。大抵、tar (gnu tar) か dd 使います。

通常、tar でﾃｰﾌﾟに書いたら、書き終わった後に必ず EOF も書かれますよね？
749 ：名無しさん＠お腹いっぱい。：2005/09/08(木) 09:25:53
いきなり EOF を書いてその先を読まさせないため
750 ：名無しさん＠お腹いっぱい。：2005/09/08(木) 09:35:45
＞749
それはどういう場合にそうするのですか？
751 ：名無しさん＠お腹いっぱい。：2005/09/10(土) 00:28:07
>>748
昔の名残だよ。
DDS1やDDS2、travan辺りは自動的にeofを書いてくれないから
自分で書く必要がある。

あと、カートリッジ１巻を丸々初期化したい時に、端から端まで
eofで埋めるとかは今でも良くやるよ。
752 ：名無しさん＠お腹いっぱい。：2005/09/10(土) 00:56:04
>751
普通 eof で埋めるんじゃなくて zero で埋めない?
(mt erase とか)

FreeBSD の man mt:
| weof と同義のコマンドであった eof コマンドは FreeBSD 2.1 で破棄されまし
| た。なぜなら、しばしば eom との混乱があり、非常に危険だったためです。

そういや、泣いたことあるなぁ…
753 ：名無しさん＠お腹いっぱい。：2005/09/10(土) 12:40:25
>>DDS1やDDS2、travan辺りは自動的にeofを書いてくれないから

そんな話は聞いた事も無いんだが・・・
もしかして、漏れ、釣られた？
754 ：名無しさん＠お腹いっぱい。：2005/09/29(木) 21:48:22
fbackup
755 ：名無しさん＠お腹いっぱい。：2005/10/14(金) 22:53:00
同じディスクを用意して

dump -0 -f - /|(cd /xxx_root;restore -xy -f -)
dump -0 -f - /|(cd /xxx_home;restore -xy -f -)
dump -0 -f - /|(cd /xxx_var;restore -xy -f -)

戻すときは、マスターとスレーブ交換
MBR書いてから起動

すげー楽ですよ
756 ：名無しさん＠お腹いっぱい。：2005/10/15(土) 02:15:59
>>751
close時にEOFを書くか書かないかはデバイスドライバの実装依存。
ふつうは、closeされると自動的にデバドラがEOFを書いてくれるけど。

>>748
EOFだけを書き込みたい場合もあるから。EOFが連続で二つ続くと普通はEnd Of Tapeと見なす。
あとmt fsrとかで任意の位置にseekした後で強制的にEOF書いたりしたい場合もあるから。
757 ：名無しさん＠お腹いっぱい。：2005/10/21(金) 10:02:24
>>430
pdumpfsのdump/restore問題に思いっきり
はまりました。ぐぐってここをみつけましたが、
やっぱだめなんすねー。捨てるしかないか...

しかしdumpできてrestoreできないのはかなり
納得いかないです。restoreは何か変なアルゴ
リズムになってるんじゃないだろうか...

758 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 01:31:33
source 追い掛けてないから断言できないんだけど、
restore は directory tree まではメモリ上に
展開しようとして pdumpfs は非常識に巨大なツリーを
産み出すので自爆する、だったはず。

で、"記念のアーカイブツリーを保存・展開" は無理があっても
「特定の日付の snapshot を指定しての restore」 は
できるんじゃないのかな、と予想。
759 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 18:02:25
こんにちは。WIN2000でのバックアップで恐縮ですが、
プロの皆さん、私が考えたスケジュールは問題ない（破綻・重複）ですかしょうか？
ご意見頂けると勉強になります。
仕事のファイル郡とＯＳ・使用アプリをバックアップする予定です。

方針：一月間に起こるトラブルには必ず対応出来る。
対策：１世代まで残す。

方法　フルバックアップ　 .１／月　外部ＨＤＤ保存
　　　　差分バックアップ 　　１／日　
　　　　差分バックアップ　　 １／週　外部ＨＤＤ保存


DDS4の導入も考えていますが、自営業のためＨＤＤにしています・・
760 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 18:47:17
>>759
＞WIN2000でのバックアップで恐縮ですが
論外。板違い。
教えて欲しいならカネ払ってコンサル雇え。

まあ、イマドキ差分バックアップなんてはやらない。
すべてフルバックアップで桶とだけ言っておこう。
761 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 18:51:23
>>760
仕事ファイルの冗長化もかねているつもりだったんですが、そうなのですか。。
板違いなら誘導してくだされ・ＷＩＮ板は道具ばっかり拘ってて、ちょっと傾向違うので・・
762 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 19:00:56
>>759
月&週の終わりだと最悪9回くらい差分合てなきゃいけない計算になるが、
その場合復帰作業にどんくらいかかるか計算したか？
763 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 19:19:51
テープをとっかえひっかえするわけじゃないからそんなにかからないんじゃないか?
同じディスクに載ってる全差分を自動で当てられるのかどうかは知らないが。
764 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 19:20:12
>>762
皆さんのようなとんでもないデータ量じゃなく
一日に増えるデータは多くて２００ＭＢほどですので、
フルバックアップの復旧以外は１･２時間程度で終わると思っています。
（ほんとＵＮＩＸスレでこんなこと言ってすんません）
765 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 20:21:35
>>761
ちょっと勘違いしてない?
1日1回、週1回の差分バックアップが必要ないと言ってるんじゃなく、
1日1回、週1回についてもフルバックアップしろという意味だと思うが・・
(差分バックアップ自体中途半端だから)
766 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 21:06:34
うちが燃えたときが心配なんですが、
でかいディスクとrsync over sshだけ提供してくれる
リモートバックアップストレージサービスってありませんかね?
767 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 22:29:20
友人宅(遠方ならなお良し)との間でやれ。

但し見られて恥ずかしいデータについては
もう少し検討の余地あり。
768 ：名無しさん＠お腹いっぱい。：2005/10/22(土) 22:38:07
後半の点については暗号化かませるrsync改造予定なので大丈夫。
769 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 00:31:44
>>765
なるほど。難しいな・・

ＯＳと主要アプリと設定（６Ｇ）　３日毎にフルバックアップ＋差分毎日（それぞれ当日　外部ＨＤＤ＋内部ＨＤＤ保存）
仕事ファイルとメール関連（２Ｇ）　を毎日フルバックアップ（それぞれ当日　外部ＨＤＤ＋内部ＨＤＤ保存）

更新頻度から考えてみました。仕事ファイルは月１でＣＤＲなどに保存しています。
これで行ってみようと思います(`･ω･´)
770 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 19:59:28
>>768
経路の問題もあるけど、肝心なデータそのものは相手の管理者に丸見えじゃん。
身内の方がまだ信用できる面もある。逆に恥ずかしい面もあるｗ
771 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 20:01:21
>>770
> 経路の問題もあるけど、肝心なデータそのものは相手の管理者に丸見えじゃん。

なんか誤解してない? そのための暗号化改造。
経路中は over ssh なんだから問題じゃあない。
772 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:04:32
あぁ、送信側の rsync を改造（？）してバイナリデータそのものも暗号化するわけね。
確かに勘違いしてますた。
773 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:12:57
そして素人暗号が瞬時に解読されるってわけだ。
774 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:15:58
うらもt(ry じゃあるまいし
775 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:31:39
Winnyって使ったことないのでよく知らないんだけど，
暗号化してWinny上にアップするってのどうかな?
776 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:45:23
>>771
tar czpg tag -f - dir|gpg -er myid|ssh remote cat ">" backup.tar.gz.gpg
とかじゃダメなのか？
777 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 21:57:40
OSとアプリを三日毎か。
そんなに頻繁にとる必要あるんか？
778 ：名無しさん＠お腹いっぱい。：2005/10/23(日) 22:24:56
762が阿呆。
779 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 04:00:20
定期的にミラーリングバックアップを行いたいのですが、どのソフトがよいですか？
780 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 05:25:21
ミラーリングバックアップ?
最近そういう言葉があるんですか?
# 変な言葉だなあ…
781 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 09:03:07
>>780
時代について行けてないようだな。ぐぐれ
782 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 09:50:11
時代についていっていると勘違いしている人がいますね
783 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 10:04:07
>>758
あーたしかにディレクトリツリー展開してるっぽいですね。で、調べたらディレクトリだけで4GB
超えてたのでこりゃたりるわけねーな。そのうち64bit CPUになってメモリ増えれば解決する
のだろうか...
784 ：780：2005/10/24(月) 19:05:07
>>781
ぐぐってみたけど頭の悪そうなページしかなかった
まじで知ってたら教えておくれ
785 ：名無しさん＠お腹いっぱい。：2005/10/24(月) 19:11:24
>>783
ディレクトリが問題なの? ソース見た?
俺てっきりハードリンクの問題だと思ってた.
テープ等seekし直せないことを前提としたアルゴリズムだと先に
inode番号ソートしたりできないから, リンクカウントが 2以上の
ファイルは覚えとかないといけないよね?

仮にもしディレクトリの問題だとすると, ある程度使われている
ファイルシステムの dump/restore は常にうまく動かなそうだけど.

786 ：名無しさん＠お腹いっぱい。：2005/12/08(木) 23:01:42
Linuxで共有ディスクを使った正、副のコールドスタンバイの構成を求められています。
WebSrv、MailSrv等デーモンの設定ファイルは共有ディスクに置けますが、
hostsファイル、ノードネーム情報を共有ディスクに置くと、マウント失敗した場合にシステムとして動作しません。本構成で一般的な組み方を教えてください。そもそも共有ディスクを使用しないのでしょうか。スマートな構成ができるといいのですが。
787 ：名無しさん＠お腹いっぱい。：2005/12/08(木) 23:22:47
スレ違いな気がするが、
クラスタソフトを導入すればいいんじゃないの？
最低限のhosts情報だけファイルにして、あとはDNSやNIS参照にすればいい。
788 ：名無しさん＠お腹いっぱい。：2005/12/09(金) 02:59:05
同じくスレ違いな気がするが、
システム一式共有ディスク(といってもコールドスタンバイなので、
FCなりSCSIなりのヒモを共有しているだけだよね)に置くのは可能。
hostsは関係ない。

しかし、そもそもそのような構成は一般的でないと思われ。
クラスタ構成(HAクラスタとかフェイルオーバクラスタ)にするのが
一般的じゃないかな。LinuxならLVSとか。

789 ：名無しさん＠お腹いっぱい。：2005/12/09(金) 03:22:32
本当の意味でのコールドスタンバイなら、クラスタでは無理というか意味ないかw
しかもこの場合なら”共有”ディスクとは言わないし。
790 ：名無しさん＠お腹いっぱい。：2005/12/09(金) 11:44:56
こんな事2chで聞く糞業者に金ふんだくられる客が可愛そうだな。
791 ：名無しさん＠お腹いっぱい。：2005/12/23(金) 11:11:11
これはどう？

http://www.iomega.com/direct/main/target.jsp?family=rev

Iomega社プロデュースなのがちょと引っ掛かるが。
792 ：名無しさん＠お腹いっぱい。：2005/12/28(水) 11:07:48
WinはBunBackupで落着きそう。
793 ：名無しさん＠お腹いっぱい。：2005/12/29(木) 09:55:00
>>792
それ知らないんだけど，WindowsだったらNetBackupじゃない？
まあ，VERITASはSymantecに食われてしまったわけだが
794 ：792：2005/12/29(木) 11:17:34
>>793
家庭用PCなので充分。
795 ：793：2005/12/30(金) 15:11:21
>>794 そうか。ｽﾏｿ。
796 ：名無しさん＠お腹いっぱい。：2006/01/26(木) 15:35:30
DAR ってどお?
797 ：名無しさん＠お腹いっぱい。：2006/01/26(木) 17:04:57
>>796
使ったことなかったけど, tar程度にUNIXのファイルシステムを知ってて,
しかも, 圧縮した状態でアーカイブの中の1つのファイルを素速く
取り出せるならけっこうおもしろいね.
今度試してみよ.
http://dar.linux.free.fr/#feat
Direct Access
Even when using compression, dar does not have to read the whole
backup to extract one file. If you just want to restore one file
from a huge backup, the process will be much faster than using tar.
798 ：名無しさん＠お腹いっぱい。：2006/01/26(木) 22:40:16
ACLとかBSDのfile flagsとかも知っててくれるんかしら?
799 ：名無しさん＠お腹いっぱい。：2006/01/27(金) 00:39:28
darを検討してたけど、knoppixとかのCDブートリナックスに
標準でdarが入ってないからやめた。(aptすればいいんだが、、、)
システムをバックアップするのには向かないと思った。
/homeとかならいいんじゃね？
800 ：名無しさん＠お腹いっぱい。：2006/02/05(日) 22:29:43
amand-erは居ないんですかそうですか
801 ：名無しさん＠お腹いっぱい。：2006/02/05(日) 23:40:40
行けよポイントマン。

後ろは俺が守る。昔のようにな。
802 ：名無しさん＠お腹いっぱい。：2006/02/09(木) 23:21:37
darで / をバックアップしてから、HDDフォーマットして復元してみたけどちゃんと動いたよ。
(マンガイチを考えてddでもバックアップを取っておいたんだけど)
803 ：名無しさん＠お腹いっぱい。：2006/02/10(金) 09:56:09
dar の tar/dump に対するアドバンテージって何?
804 ：名無しさん＠お腹いっぱい。：2006/02/11(土) 10:13:05
/etc/dumpdatesが癌だと思ふ
805 ：名無しさん＠お腹いっぱい。：2006/02/11(土) 11:04:05
常にレベル0 dumpのみ実行すれば、/etc/dumpdatesは関係なくなる。
イマドキ差分dumpはobsolete。
806 ：名無しさん＠お腹いっぱい。：2006/02/11(土) 16:48:55
ちと教えてください。

環境：FreeBSD5.4R、IBM LTO1

大量のファイル（75GB程度）をテープに落としたいんですが、まとめて
テープに書くと後ろの方にかかれたファイルを取り出すのが死ぬほど
ｳｻﾞくなるんで、いつくかのフォルダに分けて格納した上で

．
└dat1
└dat2
　　　：
└dat10

find ． -maxdepth 1 -exec tar xvf /dev/nsa0 '{}' ';'

とやって、各フォルダ単位でテープに書き込みました。
ですが、書き込んだ後の結果を確認すると、期待した

BOT <dat1> EOF <dat2> EOF ・・・・ EOF <dat10> EOF

ではなく

BOT <dat1><dat2>・・・・<dat10> EOF

という形で格納されていました。そこで質問なのですが

(1) tarをつかってテープに書いた場合、EOFはナニを契機に書き込まれるのでしょうか？

(2) findとtarを使ってフォルダ単位でテープに書きたい場合、mtを使ってEOFを明示的に
書いてやらないとダメでしょうか？
807 ：名無しさん＠お腹いっぱい。：2006/02/11(土) 18:10:54
tar xvf ???
808 ：名無しさん＠お腹いっぱい。：2006/02/15(水) 03:03:16
ここ数年RAID1+ddでバックアップ取ってたのですが、数百GBの
HDDだとHDD-to-HDDでも３時間とか時間がかかってしょうがないので、
ddではなく差分操作による同期方式の導入を考えてます。

Linuxなのでinotifyつかってopen/unlinkのログ取って、
同期時に対象のディスクに操作を反映する方式で考えてますが、
既にあったりしませんかね？
809 ：名無しさん＠お腹いっぱい。：2006/02/15(水) 10:20:51
RAID1 + dd ???
カブってるような?

>Linuxなのでinotifyつかってopen/unlinkのログ取って、
inotify ってのをしらんのですがリアルタイムに
差分記録をしたいのか?
日々の定期記録だったら pdumpfs みたいなのでいいんじゃない?
810 ：名無しさん＠お腹いっぱい。：2006/02/15(水) 19:46:31
>>809
被ってないよ。
raid1+ddだと、ミラーを分割した片側からバックアップが取れる。
サービス停止の時間を短くできるのが利点。
欠点は、バックアップの最中負荷がかかることと、再ミラーのときにもう一回サービスを止める必要があること。


ちなみに、これの発展系がストレージの3rdミラーを使ったバックアップ。
利点は、ミラーの再同期の際に本番系を止める必要がないこと。
バックアップ中に本番系に負担をかけないこと。
スナップショット機能とOracleなどのDBMSが持っている静止点をつくる機能を組み合わせると、
ミラーの分割のときでさえ、サービスを停止する必要がなくなること。
欠点は、金がかかること。
811 ：名無しさん＠お腹いっぱい。：2006/02/15(水) 21:21:51
被ってない以前になにやってるのか意味不明だがな
812 ：名無しさん＠お腹いっぱい。：2006/02/16(木) 12:21:53
＞811　意味不明だがな
これが解らないなんて　アホ？

810の方法はうちでも使ってる
ハードRAIDでミラーしつつ夜中に別ディスクにバックしてる

ハードRAIDはHDDの物理的な故障に対してだが
実は物理的故障時にはデータの整合性も崩れて双方ともダメ(残ったデータが使えない)になる事も有るし
人為的やプログラムミスでデータを消去する事も有る
その場合に丸ごとバックアップのHDDがあればそこから戻しても良いし
時間が掛かりそうならそれもメインに付け替えれば直ぐ普及出来る

さらにddするディスクを複数用意して偶数日とか曜日毎にターゲットを変えとけば数日さかのぼる事も出来るので安全性は高まる

うちでは基本はハードRAID＋１台にコピーだが重要なサーバは２台にコピーしてる
813 ：名無しさん＠お腹いっぱい。：2006/02/16(木) 19:35:24
>>812
>>808 の RAID1+dd という書き方が悪いんジャマイカ？
アホなヤシが RAID1 のミラーにさらに dd でカブせてる可能性あるだろ？

だいたい書き方もおかしいが書いてることもおかしいだろ？

RAID1 ならバックアップ取る時ミラーをはずせばいいだけで、
サービス停止する必要ないじゃないか。

逆にサービス停止するのなら、ミラーはずさずバックアップ取ればいいので
再ミラーの必要もないし。

俺は普通のミラーも運用してるし、3 面ミラーも運用してる。
814 ：名無しさん＠お腹いっぱい。：2006/02/16(木) 20:48:34
>>813
>RAID1 ならバックアップ取る時ミラーをはずせばいいだけで、
>サービス停止する必要ないじゃないか。

サービス停止（ベストはアンマウントまでやる）せずに、いきなり分割すると、
バックアップ側のファイルが壊れまくるから、バックアップにならん。

もっと勉強しなさい。
815 ：名無しさん＠お腹いっぱい。：2006/02/16(木) 20:50:07
DiskSuiteはlockfsしといてサブミラー外すけど？
816 ：813：2006/02/16(木) 21:52:41
>>814 分割ってなに？(OS何？)
>>815 俺はこっちに同意！(Solaris)
817 ：なんか突然変なのが沸いてるな：2006/02/17(金) 00:51:15
>814
dd の方がもっと酷いことになりますが...
もっと勉強してはいかが?
818 ：808：2006/02/17(金) 01:14:54
なんか本筋のつもりだったinotifyの話がなくてあれなんだけど、
ddは上のほうで誰か書いてるようにRAID1の冗長に加えてオフライン
バックアップのためにやってること（週一だけど）。

ファイルシステム整合性がddで問題という椰子はLVM snapshotすれば
いいし、実際のところRAID1のHDD両面死亡というような最悪自体では、
少々の整合性問題よりもきちんと回るHDD上にデータビットが存在して
いるだけで助かるので素のddでもありがたい。上のどちらもブロック
レベルだから実は不十分というならXFSでも使ってxfs_freezeしてから
LVM snaptshotして、そのあとddしてくれ（そこまでは自分はしてない。
自宅でする気もない）。

で、元の話に戻ってinotifyなんだけど、これ使うと差分検出処理
自体が不要になるはずなので、ホームディレクトリ程度ならともかく、
数百万ファイルあるようなディスク全体がバックアップ対象の時は
激しく高速化できるんじゃないかと思うんだけど、どうだろ？
819 ：名無しさん＠お腹いっぱい。：2006/02/17(金) 09:39:58
意欲があるのは結構。ソースはそこにある。ガンガレ
820 ：名無しさん＠お腹いっぱい。：2006/02/18(土) 19:06:13
最近のNAS/SANだと、業務用ディスク(RAID0+1)とバックアップディスク(RAID5あたり)で
業務用ディスクとバックアップディスクを同期開始
→同期完了
→バックアップの欲しいタイミングで同期停止、バックアップディスク切り離し
→バックアップディスクからLTOあたりにテープバックアップ
って感じだな。
バックアップディスク切り離しから再同期までの差分情報に対してのアプローチが
・更新情報をNAS直轄の別ディスクに記録して一瞬で再同期完了にする(保存できる差分情報は直轄のディスク容量に束縛)
・更新された箇所の情報を大まかなブロック単位で記録(=必要ディスク容量小)しておいて
再同期時に更新された大まかなブロックごとに同期
って感じで分かれててベンダーごとに細かい部分はバラバラって感じ。
821 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 00:10:29
>>808
変なのに噛みつかれてご愁傷さま。

実現しているレイヤは違うけど、レプリケーションソフトはいくつ
かあるよね。

で、inotify については、inotify を使ったバックアップは、探し
たけどなかったので自分で作ったことがある。バックアップ先を
NFSマウントしておいて、直近1分くらいの更新分を同期するように
してた。夜中のディスクガリガリがいらなくなって快適だった。
open/unlink だけじゃなくて、更新(IN_MODIFY)をどう扱うかとか
を考えだすとパフォーマンスと同期の精度とのトレードオフになる
(俺はマイファイルサーバに余裕があったので、迷ったら全部同期
するような仕様にした)

一人で使っている間は問題なかったけど、激しくイベントが発生す
るような場合はとりこぼしが発生するので、多人数が細かい入出力
をするような状況では難しいと思った(これは俺のプログラム側の
問題もあるんだけど)。

>>813
DBMS とか使ったことないの? 整合性って各レイヤで保つ必要があ
るんだよ。

822 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 02:32:31
　
823 ：813：2006/02/21(火) 14:00:44
>>821
そういう類のものについては当然

> 逆にサービス停止するのなら、ミラーはずさずバックアップ取ればいいので
> 再ミラーの必要もないし。

ですが。
DBMS のバックアップは >>810 に書いてあるような３面のミラーでも
サービス停止しないと無理じゃないの？
824 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 14:35:36
>821 は最後の2行で知ったか君自爆だね

読み直してみると出だしからして自演臭い
825 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 19:10:11
>>823
よく読め。
3面ミラーじゃなくて3rdミラー（3番目のミラー）だ。
hitachiでいうところのshadowimage
EMCなら、TimeFinderみたいな機能。

で、これらの機能と、OSとアプリケーションの組合せで、
はじめて、サービス停止なし・負荷なしバックアップが可能となる。
Windows2003＋SQLserver
826 ：813：2006/02/21(火) 21:16:29
>>825
3rd ミラーって３面ミラーのことじゃないのか。
調べてみよ。
827 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 21:32:15
漏れはレプリケーションと四㌦
828 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 22:18:18
素朴な疑問なんだが、なんで dump なり xfsdump なりで
バックアップしないんだ？
dd よりは安全だし、dd より必要な容量も少なくて速いし、
なにより、差分バックアップ機能はあるし…

バックアップにdd使うってのは、わりと特殊な状況でしか
意味がないと思うけどなあ。

829 ：821：2006/02/21(火) 22:52:58
>>823 >>824
なんちゅうかまったく…
今時「バックアップするからDBMS止めます」なんて運用が通るかよ。
止めないとしてバックアップするためには、それぞれの層での整合
性を取る必要があるってことだ。何が「当然停止するなら…」だ。

俺からのありがたい教えだから、素直に受け取ったら?

あと、なんか基本的な仕組みを理解しないで言葉に翻弄されてる奴
らが多いぞ。
要は、どっかで「せーのっ」っていうタイミングを作って、
DBMS のキャッシュを書き出すのと、ミラーの切離しやスナップショッ
トなどをまとめてやればいいだけの話(ついでにファイルシステム
のロックも切離す一瞬だけかける)。

ミラー切離しだろうがスナップショット(シャドウコピー)だろうが、
あるいは、log structured FS のチェックポイント設定だろうが、
問題ない。
(ただ、システムのパフォーマンスが若干デグレードするタイミン
グや影響の大きさがそれぞれ異なってくる)

個別の商品名や細かな違いで煙に巻こうとするようじゃ今後成長し
ないよ。
830 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 23:05:23
>>828
適材適所。
dd が「遅くて安全でない」というわけではない。
ディスク同一で、細かなファイルが多い状況なら俺も dd を
使うかもしれない。あと、ACL使ってるときとかも。

一方、バックアップひとつしかない状況(HDD 2台で a -> b にバッ
クアップとか)では、不意の事故でバックアップが途中で止まった
場合に、dd だとファイルシステム自体が壊れている可能性がある
ので良くない。

831 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 23:32:49
> dd が「遅くて安全でない」というわけではない。

パーティション全部をダンプしなきゃいけないから、
空き容量が多い状況では確実に遅いでしょ。
まあ細かいファイルが多くて、かつディスクフルに近い状況では
dd の方が速いケースがないとは言えないけど、そういう状況の
まま定常的に運用することって、普通はあまりないわけで。

> ディスク同一で、

まず、これだけでバックアップ方法の候補からはずすけどなあ。

> あと、ACL使ってるときとかも。

なんで ACL が関係するん？
Linux の dump って、ACL 対応してないの？

停止中のシステムの、ディスクのまるごとコピーをしたい場合
なら、dd を使うのも意味があるけどね。
832 ：名無しさん＠お腹いっぱい。：2006/02/21(火) 23:53:47
> パーティション全部をダンプしなきゃいけないから、
> 空き容量が多い状況では確実に遅いでしょ。
> まあ細かいファイルが多くて、かつディスクフルに近い状況では
> dd の方が速いケースがないとは言えないけど、そういう状況の
> まま定常的に運用することって、普通はあまりないわけで。

やってから言ってみな。「かつディスクフルに近い状況」とかいら
ない。妄想で状況を変更するなよ。
全体の10%しか使ってなくてもdd が速いことあるよ。

> > あと、ACL使ってるときとかも。
>
> なんで ACL が関係するん？
> Linux の dump って、ACL 対応してないの？

逆に聞きたいがいつから対応してるようになったの?
833 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 00:20:18
ハイエンドSANの機能なんか一部の人間しかシラネっつの
834 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 01:13:20
> 全体の10%しか使ってなくてもdd が速いことあるよ。

そりゃ結構びっくりだねえ。
何に使ってるパーティション？
IMAP 用のスプールしか置いてないとか、そういうの？

> > Linux の dump って、ACL 対応してないの？
>
> 逆に聞きたいがいつから対応してるようになったの?

俺、Linux は管理者じゃないから良く知らないんだよなあ。
少なくとも、xfsdump の方は昔から対応してるでしょ。
ググってみたところ、ext3 用の dump も、2005年5月リリースの
dump-0.4b40 からは対応してるみたい。
ttp://dump.sourceforge.net/
ttp://sourceforge.net/project/showfiles.php?group_id=1306
835 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 09:22:18
っていうか DB 管理者の知ったかぶりはもういいよ

仮に一面の真実はあるとしても "君ら知らないの～" だけ
書くんなら邪魔だから他所いってくれ

少なくとも 821 829 (830?) とか...
>なんか基本的な仕組みを理解しないで言葉に翻弄されてる奴
>個別の商品名や細かな違いで煙に巻こうとするようじゃ

それは激しくお前

つーわけで以後スルーしてあげるからコテハンつけてくれ
836 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 11:16:31
>>821や>>829は別にDBに限った話ってわけじゃないし、
嘘は書いてない。>>835は理解できないこと言われて
僻んでるんだろ。
837 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 12:47:02
(　´д)ﾋｿ(´д｀)ﾋｿ(д｀　)
838 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 12:50:42
ddマンセーでいいよ
DBはrawデバイスでつかってんだろ
839 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 13:09:46
誰もそんなこと言ってないと思うんだけど。
>>838はUNIXの前に言葉の勉強した方が良いぞ。
840 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 13:43:38
dumpはファイル多すぎると戻せないことあるしなぁ...

841 ：結局DB屋はなにがしたかったんだろ：2006/02/22(水) 14:52:16
言葉を学ばずに暴れる DB屋相手で揉めてるのに
「言葉の勉強した方が」
…なんて不毛なお言葉…
842 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 15:58:54
>>840
初耳です。戻せなかった時の dump/restoreとOSのバージョン、
戻せなかった時のファイル数等を書いてください。
843 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 16:17:49
このスレを pdumpfs で検索してみ
844 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 16:22:01
>>843 それはdumpとは別物
845 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 16:23:03
>>842
pdumpfsを使うとディスク容量に比べてファイル数がべらぼうに
増えるので、dump/restoreではメモリ不足で戻せないという
報告がこのスレにも以前あったよ。たとえば424。オレも
はまったあとでここを見て知ったくち。

レベルを変えて差分ダンプしたのを戻すために全てのファイル
について管理情報が必要で、それをメモリ上にもつため
ファイル数(と多分ファイル名の長さ)に応じてメモリが必要らしい。

ただ一部を指定してrestoreすれば指定した部分だけのメモリで
済むので、pdumpfsのバックアップが詰まったディレクトリだけ
あきらめて他は戻せた.

ディスク容量は100GBぐらいだったが、ディレクトリファイルの
容量合計があとで数えたら6GBぐらいだったかな。OSはLinux。
詳しい情報は忘れた。
846 ：844：2006/02/22(水) 16:52:34
おおなるほど。サンクス。
847 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 18:33:37
メモリが足りないというよりは、limit に引っかかってるか
スワップが足りないんじゃないの？
limit を増やすとか、スワップを足すといった対策をとった？
848 ：813：2006/02/22(水) 18:55:58
>>829
そんな運用してないよ。
そんなに DB のファイルをバックアップしたいのならそうすればいいよと言っただけ。
DB には DB なりの正しいバックアップ方法があるはずだからそれをすればいい。
ファイルのバックアップとは別口で。
849 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 20:49:05
>847
1GB のスワップがいっぱいいっぱいになって死亡しましたが?
これ以上はやる気しなかったよ。
850 ：830：2006/02/22(水) 20:58:23
>>845がおもしろかったのと、>>834が素直で良い子だった(ACL対応
教えてくれたし)ので実験してみた。
・Linuxで10GBのLV(lv1, lv2)を2つ作成。
・ファイルは、>>834をヒントに俺の Maildir の下全部
それを、>>845をヒントに10ずつハードリンクしてあるもの
・ディスク使用量約 700MB、ファイル数約10万
・以下の3種類を比較
a) dump 0f - | restore rf - b) tar cf - | tar xpf - c) dd
※a) b) は両LVをマウントして実行、 c) アンマウントして実行

== 結果 ==
時間 (各コマンド+sync のtimeのelapsed)
a) 約6分 b) 1分20秒 c) 約3分
メモリ使用量 (topでのRESを目視)
a) 200MB b) 13MB c) 1MB未満(bs次第)
==========
というわけでハードリンクがたくさんある場合の dump
の代替としては tar なんかどうだい

dd は >>830で書いた通り適材適所で使えばいい。
今回bs=65536だったんだけどもっと大きくすると速くなる可能性が高い。

ちなみに俺が>>829で書いたことに噛み付いてる奴がいるが、俺は
DB屋でないし、個別の商品にはまるで興味ない。
>>825なんかの情報はあってもいいと思うけど。

あと、今日の日中ぐだぐだ言ってた>>835は悪いこと言わないからUNIX
から足を洗え。向いてない。お前>>808にも理解できないからって拒否
してただろ。おかげで至極全うなこと書いてた>>808がひっこんだじゃないか。
851 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:13:23
ばっか
852 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:21:50
>>830
tarはそのままだとsparseをzeroで埋めちゃうから、
本気でtarを代わりに使うなら、
tar cf - | tar xpf - じゃなく、
tar cSf - | tar xpSf -
としたほうがいいな。
853 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:34:42
採用側ではコミュニケーション能力が求められているけど
イマドキの学生は欠如してて採用側とずれてるって

テレビで言ってた
854 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:36:15
restore rf - や tar xpf - って、かなり遅いから、
バックアップ用途だったら、dump するだけ／tar cf -するだけ
の方が速くていいと思うな。
restore rf - や tar xpf - しておいた方が、参照するには
便利なんだけど。
855 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:40:11
>854
意味がわからん

普通バックアップは dump (tar c)するもの
バックアップを戻すときに restore (tar x)するわけだが?

んでもって取っておいた塊が restore でほどけないよー って話
856 ：830：2006/02/22(水) 21:49:30
>>852
ごもっとも。ついでなのでやり直してみた。
結果は変わんなかった。

>>854
純粋にバックアップ目的ならそうかも。
今回は>>845にあったrestoreのメモリ使用量も
同時に見たかったからああいう実験してみた。
857 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 21:58:25
cpioも試して～
tarよか速いと聞いた
858 ：830：2006/02/22(水) 22:05:44
cpio の場合
find . -print0 | cpio -0o | (cd /backup_to; cpio -i)
でいいの?
ハードリンクとかデバイスファイルとかいけるんだっけ?
859 ：830：2006/02/22(水) 22:15:00
>>858 試してみた。大丈夫みたいだな。
>>850 の設定で試してみる。
860 ：830：2006/02/22(水) 22:31:28
d) cpio -0o | cpio -i
時間: 約7分、メモリ: 6.5MB
だった。

興味深かったのは、tar だとxSpfしてる側のプロセスが
CPUびっちり使ってたんだけど、cpioだと -i してる側の
プロセスがCPUを使ってた。
使ったマシンはけっこう速いCPU(Opteron254)積んでるので、
遅いCPUだとどうなんだろ。
でももう飽きたからやらない。
861 ：名無しさん＠お腹いっぱい。：2006/02/22(水) 22:40:02
やるなら各々のコマンドで
扱うファイル数(リンク数)が変わってメモリ使用量がどう変わるか
を見た方がいいんじゃないの?

10ずつハードリンク
100ずつハードリンク(大杉だったら2,30位?)

を比べるとか。
restore だけリニアに変化する、って感じかな?
862 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 19:52:16
テープにバックアップをとるソフトで
以下のような仕様のものってあるんでしょうか?
dump がディレクトリ単位を扱えればよかったんですが…

* ディレクトリ単位のバックアップ
(tarみたいに xx ディレクトリ以下を保存する)
* dump みたいに先頭にメタデータを放り込んでおいて
一部分のみ展開の時に restore -i みたいなことが出来る
863 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 19:57:40
>>862
dumpはディレクトリ単位を扱える。

よって、質問終了。
864 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 21:46:44
それ何てダンプ?
865 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 22:10:16
>>864
普通のdump。
逆に、部分ディレクトリのみのdumpができないようなバージョンがあるなら、
そのOSやdumpのバージョンを教えて欲しいくらいだ。
866 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 23:04:43
4.3BSDの頃のdumpはできなかったよ。
1990年頃から、ディレクトリ単位でできるdumpが出現しだして、
おお、と思った記憶がある。
現役OSで、できないのがあるかどうかは知らん。
867 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 23:10:19
Solarisのufsdump 2.6,7,8
868 ：名無しさん＠お腹いっぱい。：2006/03/05(日) 23:24:46
>>867
Solaris 2.6,7,8のufsdumpなら部分ディレクトリdumpはできるでしょ。
SunOS 4.xですらできるんだから。
869 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 00:04:17
マジか？
出来ないって常識を 20 年近く信じてたぞ。
俺的には dump はファイルシステムを理解する dd なんだが、
そんなことが出来るのなら dd じゃないょ(>_<)
870 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 00:09:07
>>869なんとなく気持ち分かる。
俺Linuxのdump初めて見た時
「へーディレクトリ指定できるんだー、やっぱ犬はわけわからんな」
とか思った記憶がある。dumpがファイルシステム全体を扱わないのって、
どうも腑に落ちなかった。
871 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 00:45:33
> 俺的には dump はファイルシステムを理解する dd なんだが、
> そんなことが出来るのなら dd じゃないょ(>_<)

俺は、イマイチその気持ちが分からん。カーネルのファイル
システム処理コードを通さず、直接デバイスにアクセスして、
ファイルシステム構造を理解する… っていう意味なら、部分
ディレクトリdumpができるバージョンのdumpでも、その通り
で変わってないぞ。

>>870
SunOS 4.x を使ってなかってってことか。
それとも使ってたけど気づいてなかった？
872 ：863：2006/03/06(月) 00:56:46
863に OS を明示しないで済みません。
FreeBSD で使えるものが欲しいです
(別に dump に限らず OS 独立に
ポータブルなツールがあればそれはそれで歓迎ですが)

>865
風の噂で NetBSD の dump がディレクトリ指定を受け付けると
聞いた気がしますが、それ以外の dump でディレクトリ指定
出来るものは聞いたことないです。
(linux はまあ別なんでしょう。
solarisは... 久しく触ったことないからワカラン)
873 ：862：2006/03/06(月) 00:57:51
うげ、>872=>862 です。間違えました…
874 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 01:02:43
え、FreeBSD の dump って、いまだにできなかったの？
知らなんだ。

> 風の噂で NetBSD の dump がディレクトリ指定を受け付けると
> 聞いた気がしますが、

できます。ディレクトリじゃなくてファイルも指定できる。
NetBSD と FreeBSD って、ファイルシステム構造はほとんど同じ
だから、NetBSD での変更をそのまま持っていけばできるように
なるはずだけどな。

> solarisは... 久しく触ったことないからワカラン)

Solaris も当然できる。というか、dump でディレクトリ指定が
できるようになったのは、Solaris 1 が最初ではないかな？
875 ：870：2006/03/06(月) 01:08:24
>>871
使ってたけど気づいてなかった、です。
そう思うと、最初の感想からして間違ってたのか…

876 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 04:51:56
ｌｆｔｐとrysyncではどこら辺が違うのでしょうか？
どちらを使うか迷っています。
877 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 05:15:06
もしかして、rsync のことだろうか…
lftpとrsyncつったら「どこら辺が違う」というより
同じところを探す方が大変な気がする。
878 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 08:00:52
>>872
まさかと思って試してみたが、本当だ。
FreeBSDだとdumpが個別ディレクトリに対応していない…
だっせー
879 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 08:17:10
仮にディレクトリ対応していても
dump 使うには /dev/da?s?? を
読めないといけないんですよね?

一般ユーザーが tar 的な使い方として
個別ディレクトリのバックアップをとるには
不向きでは?
880 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 08:50:53
一般ユーザ権限で行なうにはもちろん不向き。
管理者権限がいる。

逆に管理者が行なうのであれば、atime を保存できるから、
tar よりも dump の方が良い。
881 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 08:56:10
atimeもそうだし、なにより restore i できるのが便利だな。
882 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 10:37:19
げげっ、SunOS4.1.4のman dumpを見たら、filesystemの代りにfilenameが指定
できるって書いてある。全然知らなかった…。dumpはfilesystem単位というの
が完全に刷り込まれておりました。今メインで使っているのはFreeBSDだしなぁ
…。そうかぁ、世の中のたいていのdumpはファイル単位で指定できるのね。勉
強になりました。

883 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 10:40:51
FreeBSD は「たいてい」の例外ですかそうですか… orz
884 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 11:19:44
当たり前だろｗ
885 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 21:31:21
>>863
目から鱗。パーティション毎と脳内決め付けてたYo!

良スレage
886 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 21:36:33
dumpって誤解の多いコマンドだねぇ。
昔々は、dumpはまるでddのように、パーティションを直接イメージとして
読み出していると誤解している人が相当居た。
mountせずにdumpできることが誤解に拍車をかけたのかも。

そして今は、dumpがディレクトリごとにバックアップできることを
知らない人が多いとは・・
まあ、ディレクトリ指定でdumpした場合はレベル0固定になり、
インクリメンタルとかはできないんだが、
今時インクリメンタルなんてやらないから、ディレクトリごとのフルバックアップで桶。
887 ：名無しさん＠お腹いっぱい。：2006/03/06(月) 23:46:01
ん?
>886 は基本的なことを誤解してない?

オプションとしてディレクトリ指定を受け付けるだけで
あくまでパーティションダンプツールじゃないのか?
>880 から見てもしていされたディレクトリ以外を
スルーするだけであくまで "/dev/ディスク" を読むんだと思うけど。
888 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 04:16:42
なぜ今時インクリメンタルやらないの？

dump の問題？インクリメンタルの問題？
俺は Unix でも Windows でも DOS でもインクリメンタルやってる。
dump ではないけど。
889 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 08:29:10
めんどくさい。
メディアがやすい。
1個こわれたらそれ以降全部だめになる。
890 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 09:21:56
以前DDS4のオートローダを使っていたときは、フルダンプに時間がかかるんで、
週1フルダンプあとはインクリメンタルにしていた。今は、LTO2なんで毎日フル
ダンプでも何とかなることはなるんだけど、惰性で以前と同じように取ってい
る。いずれLTO2でも朝までにフルダンプが終わらなくなることは目に見えてい
るし。
891 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 09:24:13
>>887
「パーティションダンプ」ってどういうイメージ? OSを通さないで直接iノード
をたどるってだけで、基本はファイル単位でしょう?
892 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 09:41:00
根本的に別のものだと思うけどな。
dump がファイル単位(でのアクセス)であると言われるとすげー違和感。

「ファイル単位」: path を識別子として file system を経由してアクセス
「パーティション(FSイメージ)ダンプ」: file system の正規のルートを
バイパス(アクセス権・ファイルのパスなどは属性に過ぎない)してアクセス

dump 互換のアーカイブ(restore で解ける)を吐く
ユーザーレベル(ファイル・ディレクトリ単位でアクセス)の
ツールがあれば個人的にはとても嬉しい
893 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 09:46:20
違和感なんていままでずっとそう思ってたからだろ
894 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 09:48:41
「FSイメージ」っていったら、それこそDDでコピーするイメージだけど。dump
がやっているのは全然違うじゃん。おまえ、本当にわかってんの?
895 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 10:34:16
ということで、一番わかっていないのは
>>887 ということでFA。>>886 は正しいと思う。
896 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 10:47:03
まあ>>887はともかく、>>892では「イメージ」と書いてなければ
ちょっとおもしろいことを言っている。

ファイルシステムとしてはinode番号からファイルを辿る手順を
提供するのは簡単なことだけど、実際には提供していない。
# そういうのがあると、ハードリンクの発見が楽になるなど
# うれしいことがありそうな反面、ディレクトリのパーミッションを
# 守れなくなる。

唯一dumpがinode番号からのアクセス(フェーズ1)をしている点は
おもしろい。
897 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 10:53:01
>>896
iノードからファイル名をたどれるようにするのって本当に簡単? ひとつのiノ
ードにいくつでもファイル名をつけられるのに? あんまり簡単には思えないん
だけど、こんなことは些細なことなの?

ディレクトリのパーミッションが守れなくなるっていうのは良く分からない。
もうちょっと詳しく説明して。ポインタでもいいから。
898 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:12:06
>>897
「ファイル名」はともかく、ファイル(の実体)は簡単だよね。

たとえば、/secret/foo.txt っていうパスになっているとして、
secretが700だったときに、他の人がfoo.txtをinode番号から
statしたりopenしたりするのを防ぐのができなくなるという意味で
です.


899 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:13:57
ごめん>>898は見ずらかった。
上の一行が>>897の上の疑問への回答で、下4行が>>897の下の疑問
への回答です。
900 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:32:58
dumpはファイル数によって時間変わるしな。
NetBackupのFlashオプションみたいなのとも違う。
901 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:43:32
>>898
「ファイルの実体」ってどういうこと? UFSはiノードにファイル名が含まれて
いないので、iノードからファイル名を知ろうと思ったら一度ディレクトリを全
てたどってファイル名とiノード番号のリストをつくる必要がある、という理解
なんだけど。iノードから簡単にファイル名を知る方法はないということでいい
のかな?

ディレクトリのパーミッションに関しては了解です。
902 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:45:55
FreeBSDのrestoreが表示するダンプヘッダにLabelっていうのがあるんだけど、
これってdumpするときに指定できるものなの? dumpのオプション見てもそうい
うのは見当たらないし…。いつもLabel: noneになってます。
903 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 11:52:41
>>901 そういうことです。

なんでこいつはファイル名にこだわるんだろうと思ってたけど、
俺が、「ハードリンクの発見が楽になるなど」って書いたからか。
これは間違いです。ごめん。
>>896 では、
fd = open(path_to_the_file, flags) の代わりに
fd = open_by_inum(inum, flags)
を提供するといった程度のことを言ってただけ。
904 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 12:28:00
>>903
inode からのアクセスをしてたら特定のディレクトリ以下のファイルをダンプ
しないということをどうやって実現しているのだろう。FreeBSD の dump は、
一部のディレクトリをダンプしないことはできるみたいなので:
Directories and regular files which have their ``nodump'' flag
(UF_NODUMP) set will be omitted along with everything under such directo-
ries, subject to the -h option.
905 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 12:37:32
dump は、ディレクトリツリーをいったん全て辿ってパス名を保存する
から、その時に、このi-nodeは、ダンプしないディレクトリに含まれて
るよってことを記録してるんじゃないの？
ただ、そうするとハードリンクされていると駄目か。
じゃ、逆かな。
ディレクトリツリーを全て辿る時に、ダンプするファイルをマークする
んだけど、nodumpとなっているディレクトリは辿らないようにしてるん
だろうな。

しかし、ということは、ディレクトリ単位でダンプするための機能の
ほとんどは、FreeBSD版dumpにも既に含まれているわけだ。なんで実装
しないのかねえ。
906 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 12:44:16
> ファイルシステムとしてはinode番号からファイルを辿る手順を
> 提供するのは簡単なことだけど、実際には提供していない。

いや、*BSDは提供してるよ。
fhopen(2)ってのが、それ。
ディレクトリを使ったアクセス制御をバイパスできるから、
rootしか使えないけど。
ユーザレベルでNFSサーバを実装したりする場合に使える。
907 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 12:56:07
なんで >892 が評判悪いのかねぇ。
file 単位の dump では仮にファイル1,2個を取るだけの作業をしたくても
ファイルシステム全体の path tree を構成して舐める作業を
しないといけないでしょ。
path => i-node は準ハッシュ関数みたいに一方向変換(901指摘の通り)なんだし。

イメージって言葉がいけなかった?
ファイルシステムの裏口を叩いているってことを言いたかったんだけど、、

準 root 権限を要求する時点で "dump で事足りる" というのは
ごく一部の場面に過ぎない。
なんか dump の中身を知らずに、dump の man のオプションから
dump コマンドの動作を考えている奴がいる感じだな
908 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 13:01:21
>906
げ、まじ?
と思ったけど、fhopenはファイルの実体を触る手段であって
ファイルの path はわからんよね。
909 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 13:39:13
>>904
そのフラグはiノードに格納されている。
910 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 14:53:47
>>909
良くわからんが、ディレクトリに対してnodumpフラグをセットすると、そのデ
ィレクトリの配下の全てのファイルに対してnodumpフラグがセットされるの?
それなら確かに話は簡単だが…。

911 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 15:07:17
>>908
そう。分かりません。
inode番号(から構成されたファイルハンドル)を使って、
直接ファイルをオープンできるだけ。

>>910
セットされない。
912 ：896：2006/03/07(火) 15:46:38
>>906 へー。知らなかった。
貴重な情報サンクス。
913 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 22:41:54
ところでさー、最近仕事でしかたなく Linux のバックアップとってるんだけど
cpio で ustar フォーマットでとったらタイムスタンプが正しく保存されないんよ。
2002 年とかのファィルは大丈夫なんだが、最近の時間が 1971 年とかになる。

で、聞きたいのは、ネット探しまくってもそれについての情報が見付からないんだけど
cpio -ov -H ustar ってマイナー？(^^;
914 ：名無しさん＠お腹いっぱい。：2006/03/07(火) 22:44:09
その他のフォーマットでどうなるか確認してみるわ
915 ：名無しさん＠お腹いっぱい。：2006/03/08(水) 18:31:30
やはり ustar がダメなようです。
2004/01/11 が 1970/01/01 になる。
明らかに桁あふれしているね。
GNU cpio version 2.5 でした。

全部で 70Gbyte 分のファイルを tar.gz にして CD-R に保存したいのだけど、
split で分割するのではなくて、ひとつひとつの tar.gz ファイルを独立して
利用できるようにしたいのだけど、何かいい方法ありませんか？

今までは find / -print | cut -c2- | sort -r を用意しておいて
cat filelist.txt | cpio -ov -H ustar | gzip -c | dd bs=1 count=500000000
で、どのファイルまで入るか調べて（ｒｙ
……てな事をスクリプトでしてました。
ディレクトリ単位で tar.gz で固めて、500MB を超えた物についてはもう一階層
下のディレクトリ単位で tar.gz で固める、というような事もしていました。

何かいいアイデア求む。
916 ：名無しさん＠お腹いっぱい。：2006/03/08(水) 18:46:35
>>915
なんで、-H ustar にしてるの?
-Hを指定せずに、デフォルトのold ASCIIフォーマットじゃダメなの?
917 ：名無しさん＠お腹いっぱい。：2006/03/08(水) 19:23:30
>>916
tar を使い慣れてるからというだけですが、それを諦めようかな。
/ partition だけで i-node 50万くらい使用してますけど、大丈夫ですかね？
918 ：名無しさん＠お腹いっぱい。：2006/03/19(日) 18:37:50
mt の man を見ると"データ塊"の単位が
"ファイル" "レコード" "位置決定マーク(?)" って
3つくらいあるのですが、これらはどういう関係なのでしょう?

man mt より抜粋:
fsf ファイル count 個分早送りします。
fsr レコード count 個分早送りします。
fss 位置決定マーク count 個分早送りします。
919 ：名無しさん＠お腹いっぱい。：2006/03/19(日) 19:00:33
>>918
普通は fsf だけ考えれば良い。
tar/cpio/dump等で、バックアップをとった1個分全体が mtでいう1ファイル。

レコードとは、書き込時のブロックサイズ分のこと。

位置決定マークは、wsetで位置決定マークを書き込んだ場合に有効。
920 ：名無しさん＠お腹いっぱい。：2006/03/19(日) 20:52:03
>919
解説 thx.
位置決定マークは使い道からして良く分かりませんが、
分からない人間は気にしなくてもいいってことですかね。
921 ：名無しさん＠お腹いっぱい。：2006/03/19(日) 22:46:07
mtなんて、status、rewind、offlineしか使ったこと無いな。
922 ：名無しさん＠お腹いっぱい。：2006/03/20(月) 00:25:56
mt comp on/off よく使うよ
923 ：名無しさん＠お腹いっぱい。：2006/03/20(月) 02:48:07
>>922
BSD厨氏ね
924 ：名無しさん＠お腹いっぱい。：2006/03/20(月) 09:47:58
?
925 ：名無しさん＠お腹いっぱい。：2006/03/22(水) 03:06:53
mt off は便利だね。本当ちょっとしたことだけどさ。
926 ：名無しさん＠お腹いっぱい。：2006/03/22(水) 13:42:58
>>925
ある種のオートローダは、mt offで次のスロットのテープをロードしてくれた
りするので、めちゃくちゃ便利。dumpにパッチを当てて、複数のテープへのバ
ックアップを自動化できた。
927 ：名無しさん＠お腹いっぱい。：2006/03/22(水) 14:50:05
offとかcompとか。
どのUnixについてるん？
SolarisとHP-UXにはないぞ、そんなもん。
928 ：名無しさん＠お腹いっぱい。：2006/03/22(水) 14:58:16
off って offline の省略じゃないの?

comp: Set compression mode.
は少なくとも FreeBSD にはついてる。
ハードウェア圧縮の on/off を設定できる。
929 ：名無しさん＠お腹いっぱい。：2006/03/22(水) 17:43:06
いちいちmtコマンドで圧縮の指定をやるのか、それはめんどくさいなｗ
930 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 00:38:42
>929
意味がわからん
931 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 01:13:03
デバイス名で切り替えるほうがいいやん。
932 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 01:49:41
トリッキーだとは思うけど
デバイス名方式の方が合理的だもんな。

>>927
職場のSolaris2.8ではoffで省略できたよ。
933 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 10:19:27
いいかどうかは主観の問題
合理的って言うのもどうかなぁ…
最初にテープ触ったときに
「st0 rst0 nrst0 とかなにがどれでどうなっとるんじゃ!」
って思った。
別途モード切替コマンドによるのに比べて
デバイス名による識別がとくに合理的かどうかは
自明ではないと思う。chmod 等も連動しないし。
934 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 11:08:47
tarコマンドを使って書き込むときに、HW圧縮（有効/無効）にしたい場合は、
mtで前もって指定する必要があるから、面倒だと言ってるんジャマイカン？
935 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 12:43:55
Solarisのデバイス指定は結局どれ使えば
いいんだよ？って感じなんだけど、
ufsdump+DDS3なら0cbnでおけ？
936 ：名無しさん＠お腹いっぱい。：2006/03/23(木) 21:01:02
>926
おぉ、いいこと聞いた。ありがとぅ。
使いようによっては便利かもね、その使い方。

>935
オラ、田舎もんだから、わがんね”ぇ～
937 ：名無しさん＠お腹いっぱい。：2006/04/09(日) 12:22:22
rsyncを使っているのですが、ディスクの容量の関係で圧縮をしてバックアップをしたいのですが、
どのようにすればよいのでしょうか？
938 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 03:34:14
それは無理だろうｗ
rsyncでミラーしたあとに
find /path/to/backup/ -type f -exec gzip {} \;
とでもしないと出来ないかと。
939 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 08:20:30
>937 は rsync を誤解している
940 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 08:43:20
>>937
rsync 先を圧縮ファイルシステムにすれば?
941 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 09:34:15
ダブルスペースで圧縮したドライブをsambaクライアントを使って接続。
そこにバックアップすればいい。
942 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 12:31:52
ダブルスペース(笑)
943 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 12:47:56
ドライブスペースでしょw
944 ：名無しさん＠お腹いっぱい。：2006/04/10(月) 23:51:14
圧縮ファイル内のルートをfooにしたいのですが、
-xrや-dのオプションをつけると、hogehogeがルートになってしまいます。
E:\>"C:\Program Files\LHA32\LHA32.EXE" a -xr e:\test e:\hogehoge\foo

fooをルートにした上で、サブディレクトリーも含めて
圧縮できるようにするにはどうしたらいいでしょうか？
945 ：名無しさん＠お腹いっぱい。：2006/04/11(火) 00:02:06
失礼しましたこちらはUNIX板ですね。
情報がとにかく無くて、やっとの事でたどりついたので、思わず取り乱して質問してしまいました。

Win用のLHA32のコマンドラインについて質問できる場所が全然見つからないので、こちらで…といいたいです、
もしよければ適切な場所を教えていただければと思います。
探しても全然見つからないので。
946 ：名無しさん＠お腹いっぱい。：2006/04/11(火) 00:05:21
> もしよければ適切な場所を教えていただければと思います。
この質問すらする場所を間違ってる。
Windows板かソフトウェア板のくだ質で尋ねるべきでしょう。

947 ：名無しさん＠お腹いっぱい。：2006/04/11(火) 00:48:31
>>946
なるほど。
くだ質という手がありましたね。
それで本ヌレが無くても大丈夫な訳ですね。

Win板かソフトウェア板の方へ行きます。
ありがとうございましたm(_ _)m
948 ：名無しさん＠お腹いっぱい。：2006/04/11(火) 02:03:52
すみません、いい加減スレ違いなのに申し訳ありません。

適当に調べまくったり、色々実験してたらできました。
スレ違いですが、上記の私の質問でこちらのスレに来た人の人のためと、
後学のためにこちらに張っておきます。

"C:\Program Files\LHA32\LHA32.EXE" a -x -r e:test E:\hogehoge\ foo\*
ただこの場合は、fooディレクトリ内にファイルが一つも無いと圧縮されたファイルが妙な形になってしまう恐れがあります。

それでは、本当にスレ違いなのに、申し訳ありませんでした。
何かの知識の断片になればと思います。
基準ディレクトリとかでも出てこないので割と検索が難しかったです。
949 ：名無しさん＠お腹いっぱい。：2006/04/11(火) 03:15:39
もうスレの残りが少ないのに追記してすみません。
圧縮の対象ベースフォルダをダブルクォーテーションでくくる場合は\を二つでエスケープしないとエラーになります。
"C:\Program Files\LHA32\LHA32.EXE" a -x -r e:test "E:\hogehoge\\" "foo\*"

上記の時に分かっていれば重複レスにもならずに…
住民の方々、見苦しいレスすみませんでした。
950 ：名無しさん＠お腹いっぱい。：2006/06/13(火) 08:58:07
freebsdの dar のアップグレードでちょっと悩んだから、サマリーを書いておくぜ。

portsでアップグレードしようとしてリファレンスエラー(undefined reference)で止まる場合、
いったん古いバージョンのdarをpkg_deleteして、新しいバージョンのdarをインストールする。

http://www.freebsd.org/cgi/query-pr.cgi?pr=97547

しかしdarはあまり人気無いな。
951 ：名無しさん＠お腹いっぱい。：2006/06/22(木) 22:38:03
rsyncをcronで回してバックアップ取ろうと思うんだけど，
cronでrsyncが動いている事忘れてバックアップ元のマシンをシャットダウンしちゃったら，
差分の情報とかどうなるんでしょうか．

同期が途中で止まるだけで，バックアップ先のファイルが壊れるとかは無いですか？
952 ：名無しさん＠お腹いっぱい。：2006/06/23(金) 00:08:33
人間は考える葦である

* 自分でためす
* 方法を考え直す
* 最初からそのために作られた仕組みを使う
953 ：名無しさん＠お腹いっぱい。：2006/06/30(金) 14:27:54
rsyncでバックアップを取る際に、バックアップファイルを暗号化しておくことはできますか？
954 ：名無しさん＠お腹いっぱい。：2006/07/01(土) 20:52:56
rsync だけではできません。むしろ tar + gpg とかかな。
955 ：名無しさん＠お腹いっぱい。：2006/07/01(土) 22:09:08
暗号化ファイルシステムにすればいいんじゃね?
956 ：名無しさん＠お腹いっぱい。：2006/07/17(月) 08:26:20
rsyncのオプションで密度の低いファイルを効率的に扱うという項目がありますが、
密度の低いファイルというのは具体的にどういうものを言うのでしょうか？
957 ：名無しさん＠お腹いっぱい。：2006/07/17(月) 08:40:57
そろそろ backup スレで rsync 話は禁止にしないか?

だいたい >956 はなんで "sparse" を
わざわざワケの分からない日本語に直して質問してるんだ?
958 ：名無しさん＠お腹いっぱい。：2006/07/17(月) 12:46:36
rsyncで最後に表示されるファイルのサイズをMBなどで表示するようにはできませんか？
959 ：名無しさん＠お腹いっぱい。：2006/07/19(水) 19:19:10
>>956
ホールを含んだようなファイル。
見た目のサイズがディスク上での実際の使用サイズより大きい。

960 ：名無しさん＠お腹いっぱい。：2006/07/19(水) 19:22:30
>>958
最近の rsync にはまさに目的通りの -h オプションがある。
961 ：名無しさん＠お腹いっぱい。：2006/07/21(金) 17:27:44
rsyncで最後に表示されるspeed upとはどういうものですか？
962 ：名無しさん＠お腹いっぱい。：2006/07/21(金) 18:00:22
>>961
えー、それ分からないってかなり頭悪いぞ。
total-size / (sent + received)
すなわち、
転送元の総バイト数 / (送ったバイト数 + 送られてきたバイト数)

963 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 00:17:48
>>962
圧縮率ということ？
964 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 06:51:39
>>963
少し違う。1回目はすべて転送されるので正しいが、
2回目からはtotalサイズには送られなかった分も含まれるので、圧縮率とは異なる。
965 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 08:08:45
だから rsync はスレ違いだと何度i(ry
966 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 11:42:37
rsyncでバックアップを取ってる奴が多いんだからいいじゃないか。
967 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 11:59:04
>>965
rsyncも含めたバックアップ関連で1スレ4年くらい掛かるんだから
縛りを増やすほどじゃないだろ
1スレ2年くらいを目安に縛れば？（ｗ
968 ：名無しさん＠お腹いっぱい。：2006/07/22(土) 13:17:59
>>965さんは何を使ってバックアップしてるの？
969 ：968：2006/07/23(日) 04:03:12
tar
970 ：名無しさん＠お腹いっぱい。：2006/07/25(火) 10:32:16
rdiff-backup
971 ：名無しさん＠お腹いっぱい。：2006/07/25(火) 16:46:06
脳内バックアップ
972 ：名無しさん＠お腹いっぱい。：2006/07/25(火) 22:31:18
まあ、このスレでは引き続きrsyncネタも許容ってことで。
973 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 00:20:18
rsyncうめぇwwwwwwwwwwwwwwwwwwwwwwwww
974 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 19:29:04
ftp の代わりにrsyncでファイルをアップロードしているんですが、
できませんか？
ユーザー権限の設定ってできませんよね・・・
ftpのミラーリング機能使った方が早いかな
975 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 19:32:19
何を言いたいのかわからん。
976 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 20:27:12
いやー、何も考えずにrsync -e sshしたら、
属性が、ローカルのをそのままコピーしているのか、
400になってしまうんですよ。
977 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 20:32:39
まずは man でも読んだらどうかね
978 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 20:54:52
>>977 同意
>>976 -a とかつけたら?
979 ：名無しさん＠お腹いっぱい。：2006/07/26(水) 22:19:59
-pog
980 ：名無しさん＠お腹いっぱい。：2006/07/30(日) 19:14:22
バックアップてよー
ネイティヴの発音きいたら「ﾊﾞｯｶｰ」ってしかきこえねえよなー

馬鹿じゃねえよ！！
981 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 00:17:47
>>980
その話をしたいが為に、わざわざ上げたの？
982 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 00:23:07
どなたか、次スレの用意してくれない？
あと、このスレのバックアップ(笑)も、やっておいてくれると
みんなが助かるかも、知れません。
自分は、どっちもしないけどさ。
983 ：極悪人：2006/07/31(月) 00:26:51
ume
984 ：極悪人：2006/07/31(月) 00:28:54
ume
985 ：極悪人：2006/07/31(月) 00:30:22
ume
986 ：極悪人：2006/07/31(月) 00:32:58
ume
987 ：極悪人：2006/07/31(月) 00:34:16
ume
988 ：極悪人：2006/07/31(月) 00:35:46
ume
989 ：極悪人：2006/07/31(月) 00:36:41
ume
990 ：極悪人：2006/07/31(月) 00:37:20
ume
991 ：極悪人：2006/07/31(月) 00:38:32
あとよろしゅう。
992 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:15:22
埋まってないな？
993 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:22:52
埋め
994 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:23:25
埋め
995 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:25:49
次スレ
バックアップ_(2)
http://pc8.2ch.net/test/read.cgi/unix/1154337899/l50
996 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:26:30
次スレ
バックアップ_(2)
http://pc8.2ch.net/test/read.cgi/unix/1154337899/l50
997 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:27:23
埋めるよ。
998 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:28:07
埋め
999 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:28:57
999
1000 ：名無しさん＠お腹いっぱい。：2006/07/31(月) 18:32:05
さらば!!
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。