アカウント名:
パスワード:
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。あと、バックアップはどうするんだろうとか。raid前提か。
RAID1 というか安いのだからミラーすればいいんじゃない?仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
ミラーはバックアップの代わりにはならない。対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。バックアップとしてのコピーは別途必要。
ミラーもデータのコピーもバックアップですよ。対象が違うだけで。細かいことを言うとあなたの言うバックアップでもオペレーションミスやソフトウェアの不具合によるデータロストへの対処は限定的です。
ミラーがバックアップではないって細かいことかな?何十年も前から言われ続けてる常識だと思っていたのだが。
バックアップだろこれをミラーっていう奴とは仕事一緒にしたくない
最近はスナップショットという便利なモノもあるから活用してみてはどうか。
スナップショットはバックアップの代わりにはならんけどな
どのレベルのバックアップが必要かによるでしょ。オペミスやアプリレベルの不具合によるデータロスト程度ならRAID+スナップショットで十分。会社はそういうわけにもいかないので、夜間の差分バックアップも併用してるけど。ファイルの復活などは、ほぼスナップショットからやってる。バックアップ間隔も2時間毎にして評判も上々。
> どのレベルのバックアップが必要かによるでしょ。> オペミスやアプリレベルの不具合によるデータロスト程度ならRAID+スナップショットで十分。そのレベルは保険の範疇ではあるがバックアップではない。
■以下解説なので読み飛ばしてもよい君の言うオペミスやアプリ不具合なるものは、「正しく書き込まれた」都合が悪いデータでしかない。そして、一般的なスナップショットはオリジナルに対して透過的な「正しく書き込まれた」差分データのレイヤーを作成して実現している。そのため「正しく書き込まれた」データしか相手に出来ない。
スナップショット運用で差分データが「壊れた」分には取得時点のオリジナルデータで復旧できると言えなくもないが、取得時点のオリジナルデータが「壊れた」らどうしようもない。また、オリジナルデータが「壊れた」のだとしても、それに対応する差分データがあれば今時点では問題ないかも知れないが、逆にスナップショットでオリジナルデータに戻すとむしろ「壊れた」状態になる。全くもってバックアップではない。
意味が分からない。差分バックアップはいわゆる古典的なバックアップ運用のことなのだが。ZFSなどはスナップショットデータ自体を他のストレージにバックアップが可能だけど、そういう意味での差分だと思った?ストレージが読めなくなるレベルで壊れたら差分バックアップから戻しますのでご心配なく。
こんなの「バックアップ」という言葉の定義次第。
ついでに対象とする障害も定義しないと、「バックアップ」になるかどうかは議論できない。あなたは、あなたの頭の中にある障害の定義を元に、他人を否定しているだけ。
差分バックアップって要するに hard linkなので、link先が壊れていたりすると・・
NetApp みたいに、ブロックレベルで差分管理して、差分情報を保持し続けるみたいなのもありますよ。
要らない解説をすると、元コメの、
> あと、バックアップはどうするんだろうとか。
がそもそも余計で、バックアップは保存されているデータ量に比例した量の外部ストレージが要るだけで、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)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
嫌な予感しかしない (スコア:0)
容量が大きくなる → クラッシュしたときのダメージが大きくなる
という気しかしない。
あと、バックアップはどうするんだろうとか。raid前提か。
Re: (スコア:1)
RAID1 というか安いのだからミラーすればいいんじゃない?
仕事でちょっと買ってみようかな。
プライベートでは、私はその時に買える 2 万円弱くらいの HDD を買い増してバックアップしてます。
だいたい二年くらいで壊れるから、二年に一回くらい買って最新の HDD をつける感じ。
一番古い HDD を /home にして丸ごと rsync してます。
今回の 18TB が 2 万円を切ってくるのはいつ頃でしょうかね。
だいたい 5 千円を切るとその容量の HDD は流通の終わりって感じ。
Re:嫌な予感しかしない (スコア:0)
ミラーはバックアップの代わりにはならない。
対処できるのは故障だけで、オペレーションミスやソフトウェアの不具合によるデータロストに対応できない。
バックアップとしてのコピーは別途必要。
Re:嫌な予感しかしない (スコア:1)
ミラーもデータのコピーもバックアップですよ。
対象が違うだけで。
細かいことを言うとあなたの言うバックアップでもオペレーションミスやソフトウェアの不具合によるデータロストへの対処は限定的です。
Re: (スコア:0)
ミラーがバックアップではないって細かいことかな?
何十年も前から言われ続けてる常識だと思っていたのだが。
Re: (スコア:0)
テープが1巻しかなくって、そこに毎日HDDのダンプを上書きしているとします。
これはバックアップですか?ミラーですか?
Re: (スコア:0)
バックアップだろ
これをミラーっていう奴とは仕事一緒にしたくない
Re: (スコア:0)
最近はスナップショットという便利なモノもあるから活用してみてはどうか。
Re: (スコア:0)
スナップショットはバックアップの代わりにはならんけどな
Re: (スコア:0)
どのレベルのバックアップが必要かによるでしょ。
オペミスやアプリレベルの不具合によるデータロスト程度ならRAID+スナップショットで十分。
会社はそういうわけにもいかないので、夜間の差分バックアップも併用してるけど。
ファイルの復活などは、ほぼスナップショットからやってる。バックアップ間隔も2時間毎にして評判も上々。
Re:嫌な予感しかしない (スコア:1)
> どのレベルのバックアップが必要かによるでしょ。
> オペミスやアプリレベルの不具合によるデータロスト程度ならRAID+スナップショットで十分。
そのレベルは保険の範疇ではあるがバックアップではない。
■以下解説なので読み飛ばしてもよい
君の言うオペミスやアプリ不具合なるものは、「正しく書き込まれた」都合が悪いデータでしかない。
そして、一般的なスナップショットはオリジナルに対して透過的な「正しく書き込まれた」差分データのレイヤーを作成して実現している。
そのため「正しく書き込まれた」データしか相手に出来ない。
スナップショット運用で差分データが「壊れた」分には取得時点のオリジナルデータで復旧できると言えなくもないが、取得時点のオリジナルデータが「壊れた」らどうしようもない。
また、オリジナルデータが「壊れた」のだとしても、それに対応する差分データがあれば今時点では問題ないかも知れないが、逆にスナップショットでオリジナルデータに戻すとむしろ「壊れた」状態になる。
全くもってバックアップではない。
Re: (スコア:0)
意味が分からない。差分バックアップはいわゆる古典的なバックアップ運用のことなのだが。
ZFSなどはスナップショットデータ自体を他のストレージにバックアップが可能だけど、そういう意味での差分だと思った?
ストレージが読めなくなるレベルで壊れたら差分バックアップから戻しますのでご心配なく。
Re: (スコア:0)
こんなの「バックアップ」という言葉の定義次第。
ついでに対象とする障害も定義しないと、「バックアップ」になるかどうかは議論できない。
あなたは、あなたの頭の中にある障害の定義を元に、他人を否定しているだけ。
Re: (スコア:0)
差分バックアップって要するに hard linkなので、link先が壊れていたりすると・・
Re:嫌な予感しかしない (スコア:1)
NetApp みたいに、ブロックレベルで差分管理して、
差分情報を保持し続けるみたいなのもありますよ。
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による高速化もあまり意味がないでしょうし。