バックアップ_(2)

**名無しさん＠お腹いっぱい。** · 2006/07/31(月) 18:24:59

前スレ
http://pc8.2ch.net/test/read.cgi/unix/1019233825/l50

W. Curtis Preston
『Unixバックアップ&リカバリ』
長原宏治_監訳，田和勝_訳，
オライリー・ジャパン，2001/8/16．
http://www.amazon.co.jp/gp/product/4873110491/249-3251594-6585132?v=glance&n=465392&s=gateway

**名無しさん＠お腹いっぱい。** · 2008/06/05(木) 15:34:29

紙に書き写しておいて、データが飛んだら復活の呪文を唱えると…

**名無しさん＠お腹いっぱい。** · 2008/06/06(金) 10:48:06

そうそう、そんな感じ

**名無しさん＠お腹いっぱい。** · 2008/06/07(土) 03:48:15

しかしHDD って3-5年程度寝かせるだけで駄目になるもんなのかね

**名無しさん＠お腹いっぱい。** · 2008/06/07(土) 14:27:08

なる！

通電しといたほうがいい。

**名無しさん＠お腹いっぱい。** · 2008/06/07(土) 18:00:46

ブロックデバイス間でコピーしてるからファイルシステム関係ない。
xfs->xfsとかでやると速度どれくらい？ファイルシステム的にはそっちの方が
いいだろうから、速度次第でやってみたい。

ダイレクトだと50MB/s程度は出る。

**名無しさん＠お腹いっぱい。** · 2008/06/07(土) 18:19:46

キャラクタデバイスにしろよ

**名無しさん＠お腹いっぱい。** · 2008/06/08(日) 04:34:14

>>139
低温、低湿の保管庫なら
10年間くらいはは、全く問題ない

**名無しさん＠お腹いっぱい。** · 2008/06/08(日) 18:04:28

定期的に繋いでスピンアップさえしとけばいいもんだと思ってたが。

**名無しさん＠お腹いっぱい。** · 2008/06/09(月) 02:28:33

ほとんどの人がHDDバックアップなのかね？

**名無しさん＠お腹いっぱい。** · 2008/06/09(月) 03:04:51

希少でしょ

**名無しさん＠お腹いっぱい。** · 2008/06/09(月) 09:31:10

個別のファイルのバックアップは HDD2HDD が
利便性を含めて一般化してきているのではないかな?
HDDの一領域とかでなく，きちんとバックアップ用HDDという
意識で別に運用する分にはかなり有効だと思う。

毎日の差分とかも取り出す作業含めてテープよりやりやすいし。

でも，システム丸ごとの「これ、バックアップね」って
シール貼って保管する用はテープの方が安心感100倍だけど

**名無しさん＠お腹いっぱい。** · 2008/06/09(月) 15:51:22

> でも，システム丸ごとの「これ、バックアップね」って
> シール貼って保管する用はテープの方が安心感100倍だけど

かかるコストの割に使用頻度が低い(というか、ない)ので
今後はそういった慣習は無くなるのではないだろうか。

**名無しさん＠お腹いっぱい。** · 2008/06/09(月) 20:09:22

まあ、保険みたいなものだな。
保険にどれだけ金を掛けるかは、守るもの次第。

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 04:06:45

そう言う事
モーターなんか壊れたって取り換えれば良いんだよ
記録面自体は壊れていないんだから

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 08:45:20

モーターなんて、すぐ換えれるのか！？

いくらかかるの？

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 12:16:58

基板が死んだだけなら、同じ方のやつと交換すれば戻ったりするらしいけど。
モーターの交換はクリーンルームみたいな所じゃなくても大丈夫なの？

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 14:25:35

モーター交換って現実的じゃなさそう。
ttp://www.guestone.net/data/q_hdd.htm#hdd07

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 14:34:48

ネチネチいたぶるのがUNIX流

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 15:49:40

>>152
一時的に読み出せば、捨てて良いのだから
クリーンルームは不要

つーか長期在庫のHDDが壊れると思ってるのは
何の伝説を盲信してるの？

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 15:58:20

>何の伝説を盲信してるの？
何が目的でD2Dの布教活動してるの？

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 16:02:35

>155
伝説だというのなら
まずはおまえが試して10年後に報告してくれ

温度管理とか統計的誤差評価とかも忘れずにな

**名無しさん＠お腹いっぱい。** · 2008/06/10(火) 16:27:22

>>156-157
オマエら新品買う度に、製造年月日とにらめっこすんの？
卵じゃねーんだからさぁ（ｗ

**名無しさん＠お腹いっぱい。** · 2008/07/16(水) 07:42:39

取れたての新鮮なHDを産地直送！

なんか嫌な表現だなぉぃｗ

**名無しさん＠お腹いっぱい。** · 2008/09/26(金) 00:45:13

ちょっとスレチかもしれませんが、質問させてください。

バックアップで使用するテープドライブ(DDS/SDLT/LTO等)の
クリーニングについて調べていたら、
ドライブの累積走行時間を目安に実施してください、的な説明があったのですが、
ドライブの累積走行時間は何かUNIXのコマンドで分かるのでしょうか？

とりあえず、mt -f /dev/st0 status は試したのですが、
それらしい情報はありませんでした。

mtのmanもよく読んだんですが、該当するオプションはありませんでした。
OSはRHEL4で、mtのバージョンは0.8です。

何かご存知の方がいらしたら、よろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2008/09/26(金) 01:23:13

>>160
週に何回、どれくらいのテープをとか
月に何回とかの頻度を考えて、オオヨソの時間を考える

**名無しさん＠お腹いっぱい。** · 2008/09/26(金) 01:45:59

LTO,DLTはドライブによっちゃ、クリーナ入れても必要なけりゃ
そのままドライブ側でスルーするよ

**名無しさん＠お腹いっぱい。** · 2008/09/26(金) 23:28:43

レスありがとうございます。

>>161
やっぱり運用でカバーしかないですよね。

>>162
なるほど。
LTOやDLTではやり過ぎは良くないみたいですね。

自分はロギング大好きなので、
毎月記録を残そうかと思ってたんですが、
ググっても、マニュアル読んでも、
情報が出てこないのであきらめます。

**名無しさん＠お腹いっぱい。** · 2008/09/30(火) 09:39:46

LTO,DLT (リニア系?)は槍杉は×
ベンダ側も「クリーニングランプ点灯時以外やるな」

DDS,AIT とかのヘリカルスキャン系は
ある程度積極的にやるのを推奨なので
ランプ点灯しなくても定期的にやるとか
そんなのが推奨されてるんじゃなかったかな

**名無しさん＠お腹いっぱい。** · 2008/10/01(水) 22:42:54

D2Dの場合、通電は必須。
ミッドレンジのまともなストレージならば、定期的にDiskの
表面チェックをやってくれる。Checksum値が異なっていたら
エラーを出力して、HotSpareに切り替える。
こうした機構が無い場合、データが飛んでも分からないだろ。
電気代がもったいない？
そんな時はMAIDを買えば良い。一定時間ごとに通電して表面
チェックしてくれる

**名無しさん＠お腹いっぱい。** · 2008/10/03(金) 10:01:42

テープドライブ取り扱いに関する資料を置いときますね
ベンダ(テープメーカーじゃないけどサーバ屋さん)からのお・ね・が・い

http://www.express.nec.co.jp/teci/tecbook-pdf/tb070509/option/back.pdf

結構参考になるんじゃないかな

**名無しさん＠お腹いっぱい。** · 2008/10/06(月) 20:45:17

こんなのもあるでよ。

テープ装置媒体の定期交換とクリーニング
http://primeserver.fujitsu.com/primergy/pdf/tape.pdf

**名無しさん＠お腹いっぱい。** · 2008/10/19(日) 01:32:07

何か長期保存可能かつ長期可用性に優れたメディアってないかな？
テープはカビや劣化とか磁気転写が問題になるし
CDやDVDも色素が飛んだら終わりだし。
他のデジタルメディアも長期供給可能かどうかわからんし
何よりも再生機器が現存してるかどうか問題。

実家の押入に眠っていた大量のVHSテープとデータが記録されたカセットテープを見てふと思った。

**名無しさん＠お腹いっぱい。** · 2008/10/19(日) 02:46:48

>>168
MO
テープ
紙

現実的にはこれらだろ。MOとテープは30年だっけか。
紙は和紙と墨だと何百年も持つ。

**名無しさん＠お腹いっぱい。** · 2008/10/19(日) 03:32:10

>>168
穿孔紙テープだろうな
8単位10巻くらいなら、在庫有るよ
お安くしておきますが（ｗ

バックアップってのはさぁ
意味わかってる？
バックアップなんだよ。（ｗ

磁気情報が消えるとか、物理劣化してしまうとか
機器劣化してしまうとか、読み出せなくなる「可能性」に対して
バックアップを取るの。

まず2系統取って、確認して、常識的な劣化時間を考えて
その前に、その媒体を、その時代に安全な媒体で＊バックアップ＊する
それを繰り返すんだよ

その頻度と手間暇を勘定して、石に彫るもよし
和紙に綴るもよし

**名無しさん＠お腹いっぱい。** · 2008/10/19(日) 10:28:22

DVD 系(もう少し普及したらBD?)を複数とっておくのが無難じゃないかなぁ

DVD は割と長く再生互換な機器は出回るんじゃない?

**名無しさん＠お腹いっぱい。** · 2008/10/19(日) 22:47:31

>>168
ttp://h50146.www5.hp.com/products/storage/whitepaper/pdfs/tapemedia_WP.pdf

こんなのがあったので貼っておく。

**名無しさん＠お腹いっぱい。** · 2008/10/20(月) 00:22:43

MO,PD,DVD-RAMだな、長持ちするのは。
PDはメディアより規格が先に寿命を迎えたが。

**名無しさん＠お腹いっぱい。** · 2008/10/20(月) 09:05:19

>173
技術的にはそういう主張をしたくなるかもしれないが
いずれも規格の寿命は短いぞ

DVD±RW は読める期間は長そうだが
DVD-RAM 対応ドライブがいつまで供給されるか…

「その時」は DVD±RW メディアの寿命よりは先に来るでしょう

**名無しさん＠お腹いっぱい。** · 2008/10/20(月) 22:33:10

DVD±Rは規格寿命より個々のメディア寿命の方が短いな。
なにしろただの色素ですんで・・・

**名無しさん＠お腹いっぱい。** · 2008/10/20(月) 23:24:28

だから R じゃなくて RW なんじゃん

**名無しさん＠お腹いっぱい。** · 2008/10/22(水) 02:59:33

メディアの寿命にしろ規格の寿命にしろ、現状は大して長持ちしないわけだ。
ひたすらコピーし続けるしかないのか。

**名無しさん＠お腹いっぱい。** · 2008/10/22(水) 10:58:32

>>177
その遠い未来に必要なデータならな

**名無しさん＠お腹いっぱい。** · 2008/10/22(水) 14:52:21

100年先は生きていないから、そんなに持たなくていいよ。

**ｳｻﾁｬｿ** ◆/0IEZmXnQ6 · 2008/10/22(水) 21:45:25

3.5"FDでとっといた98の資産が、見事に全部読み込めなかった俺が通りますよ。
磁気メディアは一切信用しねえ。

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 23:43:28

全然触れられていないけれどmicroSDとかCFか゛
だいぶ安くなっている。DVD-RAMよりちょっと高い程度だけれど
なんやかやでms-dosfsとか無難
CFとかはIDEにつないでブートデバイスにもなる。
電子機器だけどもちはいいんじゃないかな。
テキストとか写真は2Gbyteくらいのにバックアップしている。
最初はまとまったらDVD-Rに焼こうかと思ったけれど
小さいしどんどん値下がりするのでこのままでいいかなと

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 11:29:35

>181
フラッシュメモリは↓みたいな壊れ方されると困るよね
http://gigazine.net/index.php?/news/comments/20080204_usb_memory_life/
エラーチェックがちゃんとしている品ならいいけど

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 11:45:56

繰り返し使っているとドライバとか対応しないと特定の場所ばかり使うことになるだろうから
ファイルを累積させていらないものは落としてあとはROM使用というのなら問題ないと思う。
だめなやつは初期にパーになるらしいから最初は分散保存しておくのが良いとは思う。

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 11:58:25

>>182 リンク先の記事根本的に「100万回」を勘違いしているよね、
単に不良品掴んだだけ
メーカーによってはずれのでやすいものと全然でないものとあるみたいだから
しばらく「運搬用」とかに使って大丈夫だと思ったらROM的に書き込み
チェックしたらそれでReadOnlyにするのがよさそう。

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 15:14:55

>>184
回数の勘違いはあるけど、他のメディアなら読み取りエラーになるところを、
エラーなく化けたデータが読み込めているのが、怖い

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 09:36:17

バックアップをとるのには、いまのところrsync3が選択肢として最有力？
rdiff-backup使ってみたけど、なんかエラーで動かない・・・

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 10:40:33

何をしたいかによって異なるのに
前提なしの最強を決めようとな?

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 11:21:03

ええっと、何をしたいか、ということについて
どのような選択肢がありますか？

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:26:02

>188
とりあえず以下について調べてレポートしてくれ給え

dump/restore, zfs send/receive, tar, afio,
rsync, unison, pdumpfs, rdiff-backup, duplicity,
amanda, bacula,

よろしく!

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:44:01

cpioも入れてよ

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 01:00:13

afioがあるからいいじゃん。

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 08:51:50

>188 に期待 age

**188** · 2009/01/07(水) 10:21:33

>189-191

ちょ、、、少し時間を下さい・・・orz

ところで、少し古いパソコンにLinux（debian）を入れて、rsyncで200GBほどのデータをほかのパソコンから
コピーしようとしたら、途中で応答がなくなってかたまってしまいます。
壊れているのか、原因がちょっとわからないのですが、とりあえず、メモリが224MBしか乗っていないのですが、
これだと不十分ということはあるでしょうか？

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 11:01:23

>193
rsync 2.x だと全体容量は関係ないけど
200GB というのが「多数のファイル」の場合には
メモリ食い過ぎて死ぬ可能性はある

転送中に top で rsync がメモリを食う様子くらいは眺めても罰はあたらない

rsync は 3.x 以降だとその辺は変わっているので
改善されるかもしれないような気もするかもしれない

rsync だめなら tar cf - xxx|ssh dokosoko 'tar xpf -' とかかな

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 11:06:51

2台が同じLAN内だったら、NFSマウントしてcp -aとか。

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 11:08:16

rsyncはファイル数に依存するね
ファイル数が多いとすぐ1Gくらいメモリ食ったりする

**193** · 2009/01/07(水) 11:54:40

もういちどrsyncを実行して、top画面を見てみました。
メモリ使用量10%弱のところでハングアップしてしまいました。
メモリ量ではないようですね
壊れてるにしても、どこがいかれているんだろう・・・・orz

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 11:58:11

すいません、もはや板違いですが、再起動したらBIOS画面で
Mwmory Testing : 229376K OK
のところで止まって起動しなくなってしまいました。
何回か電源を切って、入れてを繰り返すと起動しましたが・・・

どこが壊れてるんでしょう？

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 12:04:26

暖めてみれば？
ていうか古い機械ならもう寿命かもね
各所の接触が悪くなっているとか
部品の劣化とか

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 12:22:52

memtest86をはしらせてみたら40%でかたまってしまった
メモリエラーじゃなくて、テストプログラム自体がフリーズしてる・・・

寿命ですかね・・・

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 12:23:42

めでたしめでたし

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 22:04:24

換えるタイミング

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 13:12:24

ごく短い間隔でミラーリングをとる方法ってありますか？
ミラーリングというか、ごく短いスパンでミラーリングをかけたいのですが
10分おきとか

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 13:35:44

>>203
cronでrsync廻せばいいじゃん。

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 15:20:27

そもそも想定しているものの容量によっては 10分で終わらない罠

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 15:44:51

zfsとかnetappあたりのスナップショット機能つきの
ファイルシステムを使うのが手っ取り早いかと。

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 17:35:45

すいません、わけわからんこと言ってるのは分かってるんですけど^^;

Raidのミラーリングなら、同時に二台のHDDにデータを書き込んでるわけですが
たとえば一台のデータを間違って消してしまったら、ミラーのデータも同時に消されてしまうんですよね？

そこで、ミラーリングしながらなおかつ遅延をかけるというか・・・
あ、やべっ、って時に、ぎりぎり直前までバックアップがとれてる、みたいな事はできるのかな？とふと思ったもので

なんかテレビのHDD録画みたいですね（遅れて見られる）

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 17:39:50

だから >>206 でいいじゃん。

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 17:40:22

あと Raid なんて気持ち悪い書き方すんな。
RAID だ。

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 17:47:52

>208
ググってきました
たしかに、よさそうですね

>209
スマソ

**名無しさん＠お腹いっぱい。** · 2009/01/21(水) 17:38:25

IMAPサーバーのメールをバックアップしたいんです。
できればバックアップというよりはレプリケーションしたいんです。
それも遠いところ(500kmほど離れたVPNで繋がっているLAN)にあるディスクに
バックアップ(レプリケーション)したいんです。

同じサイズのISCSIなディスクを使えば解決できるだろう。
と思います。つまり、できたも同然なのですが、
具体的にどうすればよいのかという些細な点で躓いています。

例えば、二つのISCSIディスクをミラーリングすればパーフェクトなレプリケーションができるはずですが、
VPNが切れたときにリビルドされると随分時間がかかるなあとか、思います。

rsyncとかでいいかな？とも思うのですがrsyncだとファイルがディレクトリー間で移動させられたときには
コピーが発生するのかな、と思うとブルーな気分になります。

なにか良い方法はないですか？
これがうまくいったら、地震でメールサーバーのあるビルが崩壊してみんなが途方に暮れているときに、
「こんなこともあろうか○○支社にコピーしてあったのですよ」と颯爽と回復して見せれば
ボーナスの査定が上がるのも間違いないですし(もし出れば)、女子社員たちも
「△山さんカッコいい。抱いて」とくるのは確実なので、そのときは皆さんにも紹介してあげます。

よろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2009/01/21(水) 17:51:25

それを些細と思っているうちはアレかもね

**名無しさん＠お腹いっぱい。** · 2009/01/21(水) 17:57:08

> つまり、できたも同然なのですが、
> 具体的にどうすればよいのかという些細な点で躓いています。

新しいコピペにするには決めゼリフがちょっと長すぎるような?

**名無しさん＠お腹いっぱい。** · 2009/01/21(水) 18:22:23

　できたも同然なのですが、些細な点で躓いています。

こんな感じですか

**名無しさん＠お腹いっぱい。** · 2009/01/22(木) 00:07:51

> 具体的に

は外せなくネ？

**221** · 2009/01/22(木) 10:39:14

なるほど。暖かいご指摘ありがとうございます。勉強になります。

DRBDを使ってprimaryとsecondaryを一台のマシンで動作させて(出来ないのかもしれませんが)、
primaryをこっちのiSCSIディスク、secondaryを遠くのiSCSIディスクにすれば出来るような気がしますが、
DRBDとiSCSIでネットワークの不安定さをより考慮しているのはDRBDでしょうから、
ネックになる遠くとのVPNトンネルを通過するのがiSCSIなのは何かサブプライムローンやリボ払い的な
問題があるように思います。

secondary側にもlinux機を置いてDRBDというのが正攻法でしょうか。

あと、回答してもらいたいときには、これを書いておいたほうがいいというの教えてもらったので書いておきます。
「私は女子高生です。」

**名無しさん＠お腹いっぱい。** · 2009/01/22(木) 13:26:58

未来マン、颯爽登場!

**名無しさん＠お腹いっぱい。** · 2009/01/22(木) 14:33:38

>ボーナスの査定が上がるのも間違いないですし(もし出れば)、女子社員たちも
>「△山さんカッコいい。抱いて」とくるのは確実なので、そのときは皆さんにも紹介してあげます。

>「私は女子高生です。」

百合は大好物です。

**名無しさん＠お腹いっぱい。** · 2009/01/22(木) 16:14:43

僕も僕も

**名無しさん＠お腹いっぱい。** · 2009/01/23(金) 03:02:35

俺漏れも

**211** · 2009/01/23(金) 12:02:41

どうも、こんにちは。
向こう(遠いほう)のLANのユーザーも、こっちのメールボックスを使ってるんですが
IMAPなら向こうとこっちは別にしたほうがいいなと思います。
だったら向こうにもIMAPサーバーを置いて、こっちのIMAPサーバーと向こうのIMAPサーバーで
DRBDで相互にレプリケーションし合えば万事オッケーな気がします。

それと「女子高生です」と書くとレスをもらえるというのが本当だったのでうれしいです。
でもレズはいらないです。

**名無しさん＠お腹いっぱい。** · 2009/02/01(日) 01:29:58

じゃ俺女子大生ということで

**名無しさん＠お腹いっぱい。** · 2009/02/03(火) 11:35:26

この板のグダスレらしい展開になってまいりました。

**名無しさん＠お腹いっぱい。** · 2009/02/03(火) 11:51:25

百合とレズは別腹

**名無しさん＠お腹いっぱい。** · 2009/10/01(木) 19:29:42

rsync(2.6.9) で、例えばこんな状態になっていて

sync/a/1/
sync/a/2/A/x.txt

sync/b/1/B/y.txt
sync/b/2/

nオプション付きだと

$ /usr/bin/rsync --delete -auvn --include "/1/" --include "/1/*" --include "/2/" --include "/2/*" --include "/2/A/" --include "/2/A/*" --exclude "*" "./sync/a/" "./sync/b/"
building file list ... done
deleting 1/B/
1/
2/
2/A/
2/A/x.txt

「deleting 1/B/」とでるのに
実際に実行すると

$ /usr/bin/rsync --delete -auv --include "/1/" --include "/1/*" --include "/2/" --include "/2/*" --include "/2/A/" --include "/2/A/*" --exclude "*" "./sync/a/" "./sync/b/"
building file list ... done
1/
2/
2/A/
2/A/x.txt

「sync/b/1/B/」ディレクトリが削除されません。
削除させる方法はあるのでしょうか？
（複数の場所を指定したくて「include」がたくさんな書き方になっています）

**225** · 2009/10/01(木) 19:33:46

補足ですが、

--exclude "*"

で全否定して、include で追加というイメージです。

**名無しさん＠お腹いっぱい。** · 2009/10/02(金) 15:38:07

>>206 >>208 スナップショット系はディスクスペースの無駄を増やすだけ
管理ポリシーがないひとが使うとゴミだらけになる。
zfsは完全にパーになる可能性もあるから
実態の明確なファイルバックアップには向かない。
気づけば再起不能

**名無しさん＠お腹いっぱい。** · 2009/10/05(月) 12:58:53

管理ポリシーは作ればいい。
バックアップは別にやればいい。

**名無しさん＠お腹いっぱい。** · 2009/10/05(月) 15:12:14

先生っ!

実態の明確な

の意味がサッパリ分かりません

**名無しさん＠お腹いっぱい。** · 2010/01/04(月) 22:51:30

rsyncが使うネットワークの帯域を制限する方法はありませんか？

**名無しさん＠お腹いっぱい。** · 2010/01/05(火) 09:49:53

--bwlimit=KBPS
This option allows you to specify a maximum transfer rate in
kilobytes per second. This option is most effective when using
rsync with large files (several megabytes and up). Due to the
nature of rsync transfers, blocks of data are sent, then if
rsync determines the transfer was too fast, it will wait before
sending the next data block. The result is an average transfer
rate equaling the specified limit. A value of zero specifies no
limit.

**名無しさん＠お腹いっぱい。** · 2010/01/07(木) 06:03:01

ありません

**名無しさん＠お腹いっぱい。** · 2010/01/07(木) 10:49:57

>>232
>>231

**名無しさん＠お腹いっぱい。** · 2010/01/07(木) 14:29:19

もちろん >>231 も読んだ上で
「ありません」
と答えてるわけだが、、

**んじゃ↓って書けばいいのかな?** · 2010/01/07(木) 14:35:38

あります

**名無しさん＠お腹いっぱい。** · 2010/01/07(木) 14:45:56

くだらねぇ