アカウント名:
パスワード:
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。あと、バックアップはどうするんだろうとか。raid前提か。
RAID1 というか安いのだからミラーすればいいんじゃない?仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
ミラーはバックアップの代わりにはならない。対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。バックアップとしてのコピーは別途必要。
要らない解説をすると、元コメの、
> あと、バックアップはどうするんだろうとか。
がそもそも余計で、バックアップは保存されているデータ量に比例した量の外部ストレージが要るだけで、HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
そして、「RAID1+バックアップで運用してます」というコメントに対して、「RAIDとバックアップは違うんだよー、知らなかったのー」と「みんなが知らない凄い知識」を披露したくて機会を狙い続けてた人がフライングで噛み付いてる。
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
はは。これは無いわ。差分データが十分に小さかったらその通りだけど、許容できる時間内にバックアップできて、許容できる時間内にリストアできるように設計する必要があるよ。
スンマセン、 #3852257 を書いた者ですが、テキトー過ぎて申し訳ないです。
自分語りをさせてもらえば、ウチは下のような運用をしています。なんちゃってな運用なので、バックアップは rsync で下から順番に上のマウントへと rysnc でコピー(自動的に世代管理もなされる)してます。
ファイルサーバ本体の中の /home の HDD が一番古いです。もし、 /home の HDD が壊れたら、買い置きを /dev/sdb の場所の HDD と交換して、リストアはしませんで、 /etc/fstab を書き換え( /dev/sdd1 を /home にする)て再起動で完了。 /deb/sdb に入れた HDD は parted の後、 mkfs して /mnt/sdb1 としてマウントして、 rsync のコピー順を変更して、また定期運用という感じですね。もし、途中の HDD が壊れて脱落したら、そこを入れ替えるだけで、影響は特にないです。幸いにして、データ量は 3.5TB 程度しかないので、途中の入替えの時は少々時間がかかりますが、普段は最大四時間くらいで一周しちゃいますね。18TB だと一日で終わるのかという気はしますが、私の運用だと一日おきを二日おきみたいにしたりとデータの逸失に対して諦観があるのでそんなに困らないだろうと想像します。壊れたら、入れ替えるという方法で、徐々に新しい HDD になっていて容量も少しずつ増える程度で特には困ってません。今買うなら、 6TB か 8TB 位でしょうかね。新しい NAS は RAID1 で衝動買いしたものです。
メールとか著作の原稿とか、家族の写真とかホームビデオとか、 CD のリッピングファイルや Linux のいくつかのディストリビューションや Windows10 のイメージとか、そんなもの程度しかないので、整理してクラウドにあげちゃってもいいのかもしれません。火事とか水害とか何か起こったら、一番新しい NAS を抱きかかえて脱出しようと思ってます。一週間分のデータはあきらめます。
/home (/dev/sdb1) 最新データ:一番古い HDD ≒容量が一番小さい↓/mnt/sdd1 (/dev/sdd1) 一日前データ:二番目に古い HDD↓/mnt/sdc1 (/dev/sdc1) 三日前データ:一番新しい HDD ≒容量は大きい↓192.168.48.13:/data/backup (NAS を NFS マウント) 五日前データ:古いほうの NAS↓192.168.48.14:/volume1/backup2 (NAS を NDS マウント) 一週間前データ:新しいほうの NAS ≒容量は大きい
レストアしないんならその辺の問題が解決するがそもそもレストアしないならバックアップも要らないからな。
ハードディスク1台丸ごとバックアップ・リストアするという戦略は考慮に入れなくても良いのでは?
まともに、RAID+バックアップの構成を取っているなら、HDDの故障時にしなきゃならないのはRAIDの再構築であって、バックアップからのリストアは発生しない。バックアップに頼るのは、何かの操作をミスったかRAIDで吸収しきれない台数のHDDが一度に故障した場合。
「うっかりフォーマットしてしまった」というトンデモ級のミスか、HDDの故障連発か、とにかく「HDD丸ごとバックアップから復旧させざるを得ない事態」がそれなりに起こる想定のシステム設計はおかしい。洪水やら地
バックアップからのリストアが必要になるのは故障時だけじゃなくて、ソフト的なデータロス時もありますけど。それは業務プロセスからくるものであってストレージ設計では完全に吸収できない。うっかりフォーマットのオペミス、システム更新後の不具合、通信先から化けたデータが転送されていたなど運用時に起こるトラブルはたくさんあるのに、HDDの故障だけに注目しても可用性は上がらない。
昔から言われてるRAIDはバックアップじゃないという言葉をもう一度読み返してほしい。RAIDは稼働率を上げる一要素にすぎないから。
オペレーションミスでプライマリとバックアップを両方とも削除した場合でもバックアップからレストアできるのでしょうか。なぜバックアップじにオペレーションミスが発生しないという前提が成り立つのでしょうか。
そりゃ、そういう複合事象が発生しないとはいっていない。もちろんそういうオペレーションミスもあるが、同時に起きなければ稼働率は高く保てる。
いいかな、「現在オンラインのストレージ(=プライマリ)をデータロスする」と、あなたの言う「バックアップまで含めてデータロスする」は別の事象だよ。この2つがいつも一緒に起きるならともかく。
日常のバックアップが必要になるようなストレージの容量はHDD1本の容量より十分に大きいので、ストレージを構成するディスクの球数が多少減ったところでバックアップ設計には全く関係しないのでは?転送速度もバックアップ先メディアより十分に速いでしょうからRAIDによる高速化もあまり意味がないでしょうし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
嫌な予感しかしない (スコア:0)
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。
あと、バックアップはどうするんだろうとか。raid前提か。
Re: (スコア:1)
RAID1 というか安いのだからミラーすればいいんじゃない?
仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。
だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。
一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。
だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
Re: (スコア:0)
ミラーはバックアップの代わりにはならない。
対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。
バックアップとしてのコピーは別途必要。
Re:嫌な予感しかしない (スコア:0)
要らない解説をすると、元コメの、
> あと、バックアップはどうするんだろうとか。
がそもそも余計で、バックアップは保存されているデータ量に比例した量の外部ストレージが要るだけで、
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
そして、「RAID1+バックアップで運用してます」というコメントに対して、
「RAIDとバックアップは違うんだよー、知らなかったのー」と
「みんなが知らない凄い知識」を披露したくて機会を狙い続けてた人がフライングで噛み付いてる。
Re: (スコア:0)
HDDの大容量化は、バックアップ関連に新たな問題を生じさせるものではない。
はは。これは無いわ。
差分データが十分に小さかったらその通りだけど、許容できる時間内にバックアップできて、許容できる時間内にリストアできるように設計する必要があるよ。
Re:嫌な予感しかしない (スコア:1)
スンマセン、 #3852257 を書いた者ですが、テキトー過ぎて申し訳ないです。
自分語りをさせてもらえば、ウチは下のような運用をしています。
なんちゃってな運用なので、バックアップは rsync で下から順番に上のマウントへと rysnc でコピー(自動的に世代管理もなされる)してます。
ファイルサーバ本体の中の /home の HDD が一番古いです。
もし、 /home の HDD が壊れたら、買い置きを /dev/sdb の場所の HDD と交換して、リストアはしませんで、 /etc/fstab を書き換え( /dev/sdd1 を /home にする)て再起動で完了。 /deb/sdb に入れた HDD は parted の後、 mkfs して /mnt/sdb1 としてマウントして、 rsync のコピー順を変更して、また定期運用という感じですね。
もし、途中の HDD が壊れて脱落したら、そこを入れ替えるだけで、影響は特にないです。
幸いにして、データ量は 3.5TB 程度しかないので、途中の入替えの時は少々時間がかかりますが、普段は最大四時間くらいで一周しちゃいますね。
18TB だと一日で終わるのかという気はしますが、私の運用だと一日おきを二日おきみたいにしたりとデータの逸失に対して諦観があるのでそんなに困らないだろうと想像します。
壊れたら、入れ替えるという方法で、徐々に新しい HDD になっていて容量も少しずつ増える程度で特には困ってません。
今買うなら、 6TB か 8TB 位でしょうかね。新しい NAS は RAID1 で衝動買いしたものです。
メールとか著作の原稿とか、家族の写真とかホームビデオとか、 CD のリッピングファイルや Linux のいくつかのディストリビューションや Windows10 のイメージとか、そんなもの程度しかないので、整理してクラウドにあげちゃってもいいのかもしれません。
火事とか水害とか何か起こったら、一番新しい NAS を抱きかかえて脱出しようと思ってます。一週間分のデータはあきらめます。
/home (/dev/sdb1) 最新データ:一番古い HDD ≒容量が一番小さい
↓
/mnt/sdd1 (/dev/sdd1) 一日前データ:二番目に古い HDD
↓
/mnt/sdc1 (/dev/sdc1) 三日前データ:一番新しい HDD ≒容量は大きい
↓
192.168.48.13:/data/backup (NAS を NFS マウント) 五日前データ:古いほうの NAS
↓
192.168.48.14:/volume1/backup2 (NAS を NDS マウント) 一週間前データ:新しいほうの NAS ≒容量は大きい
Re: (スコア:0)
レストアしないんならその辺の問題が解決するがそもそもレストアしないならバックアップも要らないからな。
Re: (スコア:0)
ハードディスク1台丸ごとバックアップ・リストアするという戦略は考慮に入れなくても良いのでは?
まともに、RAID+バックアップの構成を取っているなら、
HDDの故障時にしなきゃならないのはRAIDの再構築であって、バックアップからのリストアは発生しない。
バックアップに頼るのは、何かの操作をミスったかRAIDで吸収しきれない台数のHDDが一度に故障した場合。
「うっかりフォーマットしてしまった」というトンデモ級のミスか、HDDの故障連発か、
とにかく「HDD丸ごとバックアップから復旧させざるを得ない事態」がそれなりに起こる想定のシステム設計はおかしい。
洪水やら地
Re: (スコア:0)
バックアップからのリストアが必要になるのは故障時だけじゃなくて、ソフト的なデータロス時もありますけど。
それは業務プロセスからくるものであってストレージ設計では完全に吸収できない。
うっかりフォーマットのオペミス、システム更新後の不具合、通信先から化けたデータが転送されていたなど運用時に起こるトラブルはたくさんあるのに、HDDの故障だけに注目しても可用性は上がらない。
昔から言われてるRAIDはバックアップじゃないという言葉をもう一度読み返してほしい。
RAIDは稼働率を上げる一要素にすぎないから。
Re: (スコア:0)
オペレーションミスでプライマリとバックアップを両方とも削除した場合でもバックアップからレストアできるのでしょうか。
なぜバックアップじにオペレーションミスが発生しないという前提が成り立つのでしょうか。
Re: (スコア:0)
そりゃ、そういう複合事象が発生しないとはいっていない。
もちろんそういうオペレーションミスもあるが、同時に起きなければ稼働率は高く保てる。
いいかな、「現在オンラインのストレージ(=プライマリ)をデータロスする」と、あなたの言う「バックアップまで含めてデータロスする」は別の事象だよ。
この2つがいつも一緒に起きるならともかく。
Re: (スコア:0)
日常のバックアップが必要になるようなストレージの容量はHDD1本の容量より十分に大きいので、ストレージを構成するディスクの球数が多少減ったところでバックアップ設計には全く関係しないのでは?
転送速度もバックアップ先メディアより十分に速いでしょうからRAIDによる高速化もあまり意味がないでしょうし。