アカウント名:
パスワード:
論理破壊を認知する時期は、関係ありません。「壊れたままをバックアップしたら壊れたままに戻します」
違うレイヤーのことに同じ単語を使うからかみ合わないのではないかと。
私はファイルの冗長性を取るものをバックアップだと思いますが、そうでない人もいるんだというのは発見でした。
08.07.04 バックアップ手続き 故障又は災害の場合のデータの復元のために準備する手続き。例 バックアップファイルの作成 08.07.01 データの復元 失われたデータ又は汚染されたデータを再生する行為。備考 記録保管庫のデータの複写、原本のデータからのデータの再構築、代わりの情報源からのデータの再構成などの方法がある。 08.07.03 データの再構成 代わりの情報源で得られる構成要素からのデータの組み立てによるデータの復元方法。
一つ絶対的に異なるのは, バックアップでは複数時点の状態に戻れることでしょう.
もちろんこれはバックアップ設計に依存するのですが, ミラーリングの場合には最終の同期以前に論理的な破壊が発生していれば一巻の終わりになります. 一方適切に計画されたバックアップなら, 最新のバックアップは役に立たなくても, それ以前のいずれかの状態までは復旧することができます.
こういう観点からするとミラーリングこそがall or nothingであり, バックアップはもう少しaboutに最善を尽くせると言えます.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
保険が違う (スコア:1, すばらしい洞察)
うちのネットワークRAIDはほぼライトワンスだからいいけど、最近のエロ動画はサイズがバカでかくて困る。
女優以外はロッシー高圧縮してくれていいよ。
何故にAll or nothing (スコア:1, すばらしい洞察)
のであって、
「バックアップにならない」
のとは違うと思う。
# こういう「紛い物を売りつける商売の人」的な論法は避けたほうがよさげ
Re:何故にAll or nothing (スコア:4, 参考になる)
＞のとは違うと思う。
いや、バックアップになっていないのですよ。
RAIDのミラーリングは、ハードディスク単体の物理的障害耐性の向上です。
データのバックアップは、システム全体の論理的物理的破壊への耐性向上です。
同期する時間を長くしたとしても、同期途上の障害や論理的なデータ
の破損にはミラーリングは意味を持ちません。
RAIDのミラーリングは「壊れやしモノがその壊れやすいモノ一個壊れても
稼働を継続する」ためのものですが、バックアップは「何が壊れても論理的に
同じ様に再構築する」ためのものです。
用途・目的が異なるモノを同じものだとするのは、誤りです。
バックアップをわかりやすく.. (スコア:1)
うわ！間違って消しちゃったぜ！
で戻せるのがバックアップ
うわ！HDDが死んだぜ！
で稼働するのがRIAD1なミラーリング
うわ！間違って消しちゃったぜ！
でRIADは無力です。
Re:いやだから (スコア:2, すばらしい洞察)
"バック"アップなんだから後ろにあって（つまり退避してあって）いざと言うときに前進してきて仕事をするもんです。
ミラーリングは常に前に居て、一つの仕事を冗長的にこなして片方に障害が発生しても仕事を続けられる仕組みです。
ミラーリングは三塁手と遊撃手で左方向を守っています。万一、三遊間を破られたときにボールを拾うのが左翼手のバックアップです。
（外野フライには内野手は打球に対しての守備はしません）
Re:いやだから (スコア:3, 参考になる)
同期や冗長化はオンラインのデータを失わないようにするもの。
明確に別のものです。結果が同じなら言葉も同じでいいじゃないかというのは
乱暴すぎると思います。
あとバックアップを一回分しか保管しないなんて運用は普通しません。
自分の管理下のサーバーは半年前まで段階的にさかのぼれるようにしてあります。
Re:いやだから (スコア:1)
混同して使うからややこしいのです。
たとえば、カットオーバー直後に障害に備えて、「バックアップ体制」を
とることがありますが、これはディスクがなんとかとか、データ同期が
なんとかとかとは関係なく「バックアップ」ですね。
RAIDミラーリングは、ディスク障害という「有事の備え」に対応するための
ものですから、「バックアップ手段」ではあるが「データバックアップ」では
ないということでいいじゃないですか。
Re:いやだから（オフトピ） (スコア:1)
しかしこのrsync3.0.0の話は参考になりました。
ありがとうございます。
#今見たら3.0.5があった。
Re:何故にAll or nothing (スコア:1)
いえいえ、違います。
ある瞬間での障害に耐えるという障害耐性がミラーリング。
ある期間での障害に耐えるという障害耐性がバックアップ。
示された期間、指定されたデータを戻せるか、ある瞬間壊れた
デバイスの代替をデバイスの冗長可による運用継続を同じに
考えてはいけませんよ。
Re:何故にAll or nothing (スコア:1, 参考になる)
ミラーリングを、デバイスの冗長可による運用継続に求めると痛い目見ますよｗ
バックアップだと考えて対処しないと両方ともクラッシュして終わりです。
#CE時代に経験したことからの意見なんだけど、間違ってますかね？
Re:何故にAll or nothing (スコア:1)
片肺飛行中に万が一のことがあった場合にも備えてバックアップはとっておきますけどね。
Re:何故にAll or nothing (スコア:1)
バックアップもとっていて良かった経験だと,仮想テープ装置 [keyman.or.jp]のファームウェアのバグで変なデータが書かれたが、たまたま別のバックアップテープが存在したので直せたけど... 仮想テープ装置はバックアップ装置なので致命的だよな。
他に聞いた話だと、開発用データをマスクしようとして本番用のデータをマスクしてしまってバックアップから直したとか。
皆さんのやり方を教えていただきたいのですが24時間365日稼働のシステムが増えてきてバックアップを採るために静的状態を作るのが大変になってきました。動かしながらHDDへのバックアップやテープへのバックアップはどのようにしていますか?
Re:何故にAll or nothing (スコア:1)
もちろん、求められている(SLAで示されている)様に
迅速にミラーの回復を行いますね。
片方生きているからそのまま..というのは、求められて
いる可用性を損ねた運用ですからね。
＞バックアップだと考えて対処しないと両方ともクラッシュして終わりです。
対処するかどうかは、わたしの投稿には入っておりませんが、
対処しないという前提のお話ですか？
ITをなめていますね。
Re:何故にAll or nothing (スコア:1)
s/バックアップ/スペア/g
と置き換えれば、常識的な意見に読める。
# でも今度は何が参考になるのかがさっぱり。
# #1484891 [srad.jp]との継がりもさっぱり。
Re:何故にAll or nothing (スコア:1)
主流は以下の通りかな？
内蔵のディスクには基本的に稼働に必要な動的なデータは置かない様にする。
シンク＆スプリット機構(完全コピーを別媒体に作成する機構)を持っている外付けのストレージを使う。
# メーカによって「RecoverPoint」とか「ShadowImage」とかある。
DBが持っているbegin backup/end backupの間に、(更新を抑制して復元可能な状態の内容を)別媒体に取得する。
その別媒体をシステム側から切り離して、テープや他所にあるVTLにコピーする。
Re:何故にAll or nothing (スコア:1)
＞と置き換えれば、常識的な意見に読める。
スペアというと、わたしとして以下の様な機構のことを思います。
RIAD0やRIAD5において一点障害の時に自動的に
冗長性回復するホットスペア
スペアといってしまうと、「通常時は何もしていない単なるお荷物
だけど、何か壊れた時に付け替えて使う部品」になってしまいます。
バックアップは「通常時には何もしない単なるお荷物だけど、全部
が壊れても元に戻すための情報」ということになります。
バックアップを採るために静的状態 (スコア:1)
いや、実際静的状態を作れないよね。お金を掛ける気はないしシステムも止めたくない、というシステムが多くなってきているのでしょう。そういう半端なシステムについてということで。
ストレージ装置のスナップショットとか、通常のファイルコピー/syncなどで複製する。それだと不整合がある可能性があるので、複数世代のスナップショットやらを用意しておいて、リストアの場合にはどれかでうまくいくんじゃないかしら、という感じでしょうか。こんなやり方良くないけどね...オカネないし。
システムの三重化をして、1システム切り離して停止&バックアップ、バックアップ後三重化へ戻すとかできたらいいなぁ、と思うんだけどね。
Re:何故にAll or nothing (スコア:1, すばらしい洞察)
バックアップとして想定しているエラー要因として物理デバイスの故障に的を絞っているだけ。
なんにでも対応できる万能バックアップがあるのならともかく、
あらゆるバックアップ手段には「想定しているエラー要因」と「復旧をあきらめざるを得ないエラー要因」がある。
おまえが言ってるのは、「トヨタ車なんてクルマじゃないやい！」と似たり寄ったり。
Re:何故にAll or nothing (スコア:1)
すまんが、何にでも対応できる万能バックアップというものは、話題になっていないよ。
RAIDのミラーリングはバックアップではないという話題だよ。
Re:何故にAll or nothing (スコア:1)
重要なのは運用する立場としてそれを「バックアップ」と呼べるかどうかだと思いますが。
毎分のスナップショット＆＆それを７世代分というものを「バックアップです」と言われると、普通は「そんな無茶な」となりますね。
＃そういうのがバックアップとなりうるシステムもあるでしょうけど。
Re:何故にAll or nothing (スコア:1)
「ミラーリングでは、クラッカーやOSに論理的に破壊されたままに戻します」
どう違うよ？
Re:何故にAll or nothing (スコア:1)
ミラーリングの場合、壊れたら速やかにバックアップ先で稼動を続けるだけの話。
ま、あくまでリストアする為のものがバックアップと狭く定義したところで、交換後のsync作業で同じことをやるから（CEは交換後、syncが無事終わるまで通常なら帰らない）結局は同じことだしね。
レイヤーが合ってない (スコア:1)
違うレイヤーのことに同じ単語を使うからかみ合わないのではないかと。
私はファイルの冗長性を取るものをバックアップだと思いますが、そうでない人もいるんだというのは発見でした。
-- siu
Re:何故にAll or nothing (スコア:1)
「定義からしてバックアップである(過去の一時点に戻れるから・もっと漠然と兎に角データが復旧できるものだから)」
「定義からしてバックアップではない(複数の過去の時点に戻れないから・論理的破壊への耐性が皆無だから)」
「定義からしてミラーリングである(ほぼ同じデータが現に対として別の場所にあるから)」
「定義からしてミラーリングではない(リアルタイムではないから)」
という説の組み合わせがあるわけですね。
厳密な解釈を好む人の意見を集めると「こんな運用はミラーリングでなければバックアップですらない、なんか名前のない不可能存在」ということになりますが、なんだかなー。
個人的にはこれをバックアップと呼ぼうとミラーリングと呼ぼうと大した違和感はないですが。
JIS X 0008:2001による定義 (スコア:3, 参考になる)
ということですから、RAID1のミラーリングをバックアップ手続きと言って言えないことはないというのが結論になりそうです。
とはいうものの、データのバックアップ手段を要するという仕様に対してRAID1しかないシステムを納品したら、やっぱり問題になりそうではあります。
Re:JIS X 0008:2001による定義 (スコア:1)
手元にJIS規格書がないのですが、RAIDや冗長性について定義されていますか?
Re:JIS X 0008:2001による定義 (スコア:1)
読むと、
＞08.07.04 バックアップ手続き
＞故障又は災害の場合のデータの復元のために準備する手続き。
RAIDではありませんね。
＞08.07.01 データの復元
＞失われたデータ又は汚染されたデータを再生する行為。
RAIDが戻せるのは「失われていない」「汚染されていない」データですよね。
よって、これもRAIDではありませんね。
＞08.07.03 データの再構成
＞代わりの情報源で得られる構成要素からのデータの組み立てによるデータの復元方法。
すでに正しいデータがあり、それを転写するわけですから、
「代わりの情報源」ではないし、「データの組み立て」でも
ありませんね。
よって、これもRAIDではありませんね。
以上から、３項目ともRAIDは外れておりますね
RAID5だとパリティ生成を「現状あるデータから組み立てる」
ということで、第三項目の後半にあたりますが、既存の正しい
データを元にしているわけで「代わりの情報源」からではない
ので、これも範囲外でしょう。
Re:何故にAll or nothing (スコア:2, すばらしい洞察)
バックアップですよね。今回の件はRAIDと書いてあるので、
バックアップにはならなかったようですが。
Re:何故にAll or nothing (スコア:3, すばらしい洞察)
一つ絶対的に異なるのは, バックアップでは複数時点の状態に戻れることでしょう.
もちろんこれはバックアップ設計に依存するのですが, ミラーリングの場合には最終の同期以前に論理的な破壊が発生していれば一巻の終わりになります. 一方適切に計画されたバックアップなら, 最新のバックアップは役に立たなくても, それ以前のいずれかの状態までは復旧することができます.
こういう観点からするとミラーリングこそがall or nothingであり, バックアップはもう少しaboutに最善を尽くせると言えます.
Re:何故にAll or nothing (スコア:1)
ミラーリングは同じデータを複数の場所に用意して負荷を分散したりデータを複数の場所に配布したりするのが目的なのであまりタイムラグが大きくなるとオリジナルの方に殺到してミラーの意味がない。
Re:何故にAll or nothing (スコア:1, 興味深い)
後頭部のチェックとかに便利かと……
思ったが犯罪チックな使用法を想像できたので、ACは考えるのを止めた。
Re:何故にAll or nothing (スコア:1)
障害の内容･タイミングによっちゃうんと昔に戻らないといけないこともあるので。
+深夜残業プラス１+
Re: (スコア:0)
普通はリアルタイムに同期させるRAID1だと思うけど。
同期間隔を空けるのは単なるディスクバックアップで
ミラーリングとは違う。
Re:何故にAll or nothing (スコア:2, 参考になる)
そこにリアルタイムという要素は介在しません。rsyncでファイルの同期を取ることはリアルタイムではありませんが、
「ミラーリングしてる」と表現しています。
今回の場合は厳密には「RAID1によるミラーリング」と言わなければいけないと思います。
バッチ処理で1日に1回、遠隔地のサーバにミラーリングしてる。とか言う場合は、
十分バックアップの要素を備えているからです。RAID1だけがミラーリングではありません。
Re:何故にAll or nothing (スコア:2, 興味深い)
ミラーリングは同期されているものです。
鏡という言葉を使うようにずれがあるものではないのです。
そして現在進行形です。(mirrorは名詞じゃなくて動詞です。)
rsyncでミラーリングするとは確かに言いますが、それはその時点では同期されているからです。
時間がたてばもうrsyncとは無関係なバックアップです。
ミラーされた(=鏡のように映し出された>バッチ処理で1日に1回、遠隔地のサーバにミラーリングしてる。とか言う場合
どっちかというとおかしな言い方なんです。
確かにその時点ではミラーなんですがね。意図していることとは違うはずです。
確かにミラーリングはRAIDだけではありません。
データベースにもあります。
バックアップ、レプリケーション、ミラーリング、スナップショット、似たようなことをしますが全部異なるものです。
この場合でもミラーリングは二台以上でずれを生じさせないものです。
時間間隔とか生じる時点でもうミラーリングではないのです。
ミラーリングにそんな概念はないのです。というか生じてはならないものです。
広義とか狭義とかでもありません。
別のものです。
当然、方言でもありません。
誤用でしかありません。
Re:何故にAll or nothing (スコア:1)
元々ミラーリングを含めてRAIDはHDDの
ハード障害への対応のものだし。
ソフト的な障害のために設計されてないから
バックアップとして考えるのは駄目。
Re:何故にAll or nothing (スコア:1, すばらしい洞察)
ハード的な障害の場合にも、HDD交換後、テープからリストアとかするんですがね。
まさかと思うけれど、ハード的障害の場合、ミラーリングしか手段がないとか思ってます？
ソフト的な問題だろうがハード的な問題だろうが、データが破損して駄目になったらバックアップから戻すんだよ。ちなみにミラーリングはバックアップじゃないとか言ってる人がいるみたいだけど、あれもバックアップなんです。少なくとも機構的にはね。
ディスクのトラブルで丸ごと死んじゃった時にもう一方から死ぬ直前までのデータを戻すためのものです。交換後、ちゃんとそういう操作を内部的にはしているんです（交換後、データのsyncをしています。CEがやってたのを見たことありませんか？）
実際は片肺でも動いてしまうもんだから表面的には分からないんだろうけどね。
バックアップじゃないとかの問題じゃなくてバックアップとしては不完全ってだけの話だと思うが、違うのか？＞アンタラ
#ま、たしかにソフト屋さんにはハードに疎い人も多いのは知ってるけどさ。
Re:何故にAll or nothing (スコア:2, すばらしい洞察)
＞バックアップじゃないとかの問題じゃなくてバックアップとしては不完全ってだけの話だと思うが、違うのか？＞アンタラ
それってただのミラーリング。ディスクの片割れが死んだらミラーではなくなるのだから
復旧中は単にミラーリングを実行しているだけ。論理的にも物理的にもデータは失われて
いないのだからバックアップからリストアという表現は不適当。
ミラーセットが完全崩壊してほかの媒体から再構築したミラーセットに書き込んだというならリストアといえるが。
Re:何故にAll or nothing (スコア:1)
Re:何故にAll or nothing (スコア:2, 参考になる)
ミラーリングもバックアップです、リストアするんです、なんて通用しないと思いますがね。
もしユーザにそんな説明したら突っ込まれること間違いなし。
突っ込まれ内容はJBD01226さんが書かれておられます。
そんな私は運用屋ですが、現場でCEがディスク交換後のミラーリングを「バックアップ」「リストア」なんて言葉を使うことはまずありませんね。
間違いなく混乱の元になります。
CEの作業報告書にも、RAID再構築、ミラーリング、再同期、といった言葉はあっても、リストアとは書かれません。
CEの範疇外になってしまいますから。
Re:何故にAll or nothing (スコア:1, 参考になる)
ミラーセットをバックアップと主張して再構築中に生き残ったディスクも死んだら
何のためのバックアップだという話になる。生き残ったディスクだけが唯一の
データ保持媒体ならその瞬間にバックアップが存在しないことになってしまう。
そして冗長化ディスクの冗長性復旧中に生き残りも死ぬってのはない訳じゃない。
バックアップってのは復元できる可能性を上積みして想定の範囲内で
データの保持を行う訳だから、想定の範囲がそんな程度だと復旧の可能性がバクチになってしまう。
Re:何故にAll or nothing (スコア:1)
そんなこと言い出したらキリ無くないですか？
他のどんなバックアップ手段だって、バックアップメディアが燃えちゃったらとか壊れちゃったらとか言ったら同じじゃ？
#ミラーリングって、何も2台限定じゃないですよね？
Re:何故にAll or nothing (スコア:1)
>
> そんなこと言い出したらキリ無くないですか？
ロットも納入時期も同じ場合、一番懸念される事態ですね。
１００台くらいのマシン(ディスクはその10倍くらいはある)を管理してたころは、
年に一回くらいはそういう面倒な障害が報告されてました。
> 他のどんなバックアップ手段だって、バックアップメディアが燃えちゃったらとか壊れちゃったらとか言ったら同じじゃ？
マシンと同時に被害を被らない限り、取り直せばOKです。
Re:何故にAll or nothing (スコア:1)
役に立ったかどうかの話じゃなくて、あてになるかどうかの話をしているように見えるのですが。
Re:何故にAll or nothing (スコア:2, 参考になる)
>
> そんなこと言い出したらキリ無くないですか？
他の方も書かれていますが、案外、結構な確率で発生します。特に、IDE / SATAのHDDでのRAID5はキケン。
SATA 500GB x 8のRAID5の再構築、3回に1回は失敗するって記事があります。↓
http://knowledge.ontrack-japan.com/ontrack_now/20060515_mamechisiki.html
# RAID6を勧めるための記事ですが、参考になります。
> 他のどんなバックアップ手段だって、バックアップメディアが燃えちゃったらとか壊れちゃったらとか言ったら同じじゃ？
なので、どこで割り切るかという問題になりまして。
徹底的にやるなら、ストレージは遠隔地に置いて、バックアップテープはさらに遠隔地(場合によっては海外)に保管するなんてことも、本当に大事なデータを管理しているデータセンターならやりますね。コストとの兼ね合いがありますんで、ふつーはそこまではやらんですが。
でも、上で書いたような事情もあるし論理破壊に対応する必要もありますので、「RAIDだけで十分なバックアップソリューションだ」なんてこと、ふつーのSEは言わんと思います。テープで数世代は取れるように設計するのがふつーでしょう。
# テープは遅くて高価で扱いづらいので、最近はSATA HDDを使った安価な別のストレージにバックアップするというソリューションもありますね。
RAID1だってバックアップの一種だ。なんて言ってる人もいるようですが、そりゃ言葉遊びってもんでして。「ハード故障から迅速に復旧してシステムの停止時間を短縮する」ことが目的のRAID等ハードウェア冗長化と、「万一データ破壊が発生しても確実に破壊前の状態に戻す」ことが目的のいわゆるバックアップとでは、そもそも目的が違うんですから一緒にしちゃダメですよ。
Re:何故にAll or nothing (スコア:1)
余談ですが、そのためにRIADもRAID5+1(6)とか、RAID7とか、
ミラーでもRAID 1+1みたいなことがあったりしますね。
＞想定の範囲がそんな程度だと復旧の可能性がバクチになってしまう。
ハード屋さんとしては博打を打ちたいのかもしれませんが、
システム屋さんはもっとクールなんですね。
どこまでどういった場合まで戻せるか？その手法は？といった
想定範囲が、システム屋さんには求められるわけで、それを
考えて実装するわけです。
ミラーリングでは「単に生き残っているデータのミラー復帰」
程度しか出来ないわけですよね。
リストアは出来ないのに、バックアップを名乗るのが、
おこがましいというわけです。
Re:何故にAll or nothing (スコア:1)
これ許される時間の問題もあるんだ。
静的にデータバックアップ取得するためにサービスの停止を伴うケースがあるわけな。
ここで、「安全に負荷をかけないでバックアップすると５時間よけいに停止させる
必要がある」といった「サービス停止」をどうするかの考えが入るんだ。
でもって、場所によっては「RAID1の復元の場合は、生き残ったデータのバックアップ
の取得をしない」という「決め」がある。
# 10システム程度しか運用設計していないけど、顧客のポリシーなどから、
# そういうサイトが複数あった。
そういった決めがある場合を含めて、SMARTで確認して,RAID1の復元が困難そうだから
止むなく停止時間の延長を呑む場合もあるんだ。
＞いちいちSMARTなんかで確認してヤバそうだからやる、なんて場当たりやってるからあてにならん奴なんだよ。
場当たりではなく、状況を検分して判断するということも、考えられるよ。
障害復旧について、「この場合にはこうする」だけの決め打ちではなくて、
「この場合には○○をみて(調べて)判断する」といったことが事前に(もしくは、
その場で)決められる場合もあるからね。
一番まずいのは、君の様に「こうするのは当たり前」という思い込みで仕事を
することな。
安全性もあるけど、ダウンタイム／復旧時間を考えるのは、よくあること。
Re:何故にAll or nothing (スコア:1)
>ハード的な障害の場合にも、HDD交換後、テープからリストアとかするんですがね。
>まさかと思うけれど、ハード的障害の場合、ミラーリングしか手段がないとか思ってます？
この部分は全くのイミフ（議論のすり替え？）
>ちなみにミラーリングはバックアップじゃないとか言ってる人がいるみたいだけど、
>あれもバックアップなんです。少なくとも機構的にはね。
この部分の説明を詳しくよろ。
ハード障害の問題を軽減するだけのものと思ってたのだが違うのかな？ミラーリング/RAID
Re:何故にAll or nothing (スコア:1)
データがだめになっていない(片肺)の場合は、データを復旧するのではなく、
データの可用性を復元するんですよ。
ハード屋さんだと、そこらへんが切り分けできていないわけなんですよね。
システム屋としたら、データが「失われた」「破壊された」場合に戻すための
モノをバックアップと位置づけているわけです。
Re:保険が違う (スコア:1, 参考になる)
データが壊れていればバックアップから正しいデータを書き戻さなくてはなりません。
保険で例えるなら、ミラーリングが "休職中の収入を補償する保険" でバックアップが "治療費を補償する保険" でしょうか。