ミラーリングはバックアップにはならない 229
ストーリー by hylom
そりゃそうだ、 部門より
そりゃそうだ、 部門より
Anonymous Coward曰く、
本家/.より。
皆様ご存じのように、ミラーリングはディスクの不具合には対処できるものの、OSやアプリケーションの不具合、もしくは操作ミスなどによるデータ消去/上書きには対応できない。このようなトラブルを防ぐためにはデータを別途バックアップしておくことが必要、ということなのだが、意外に「ミラーリングしているから大丈夫」と思ってバックアップはしていない管理者は少なくないように思えてならない。皆さんはちゃんとバックアップを作っていますか？Journalspace.comというサイトが障害に見舞われ、そして未だに復旧に成功していない。現在Webサイトに掲載されている情報によると、OSもしくはアプリケーションの不具合、もしかしたら何か悪意のある攻撃などにより、データベースの全データが上書きされてしまったことが障害の原因と思われるそうだ。原因が何であれ、彼らはディスクのミラーリングをバックアップのように扱っており、別途データのバックアップを行っていなかったようだ。
基本ができていないだけ (スコア:5, 参考になる)
元記事から一次ソースを見るとthe journalspace data had two large drives in a RAID configuration [journalspace.com]とあるから、「なんだ、単にバカやってただけ」「こういうのはバックアップとは言わない」だけの事。
ミラーを使って、かつバックアップを実現する事は当然可能。マシンをもう一台用意して rdist か rsync で複製作って、そいつでテープや CD-RW などにバックアップ、でできるだろ? 容量が少ないなら毎日、保存先のディレクトリの名前を変えてフルバックアップ。多ければ週末にフル、終日はインクリメンタルで。ポイントは
- rdist か rsync (他でもいいけど) はメインマシンから動かす。OS が潰れたら複製作業も止まってくれる可能性が高いから。
- テープや CD-RW などにバックアップするのはサブマシンで実行。
あたりかな。オライリーの Unixバックアップ ＆ リカバリ [oreilly.co.jp]は、2001年の本だが参考になったね。凄く詳しく書いてあるよ。Journalspace.comというサイトの管理者は、既に2001年には本も出ていて、それを読めば判るような、データを守る人間の常識として知っておくべきバックアップの基本を知らなかっただけの話で、こういうのは「事故」とは言わない。「必然」「人災」と呼ぶべきものだろう。「それをミラーリングがダメだったんだぁ！ 知らなかった、落とし穴だった」みたいに騒ぐなんて、はっきり言って「私はバカです」と宣伝しているだけだと思うけどね。とはいえ現在でもこの本を読んで「これは知らなかった」なんて驚くような奴が多いのも事実なんだろうけど。ま、諸兄も借りて読んでみれば?Re:基本ができていないだけ (スコア:3, 興味深い)
これによると、そもそも、RAIDだけで済ませるよう提案した男が、会社で盗みを働いて、やめさせられた後に、その腹いせにデータを上書きしたみたいですね。なんで、バカはバカでも、ちょっと質の悪い話みたいで。
バックアップより重要なのは (スコア:5, 参考になる)
定期的にバックアップとってる人でも、定期的にリストアしてない人が多いので。避難訓練と同じで、手順を確認すること・マニュアルを見直すことは、定期的に行うのが良いと思います。「今回は、サーバールームが地震で崩れたという事で」とかやると、意外に問題点が浮き彫りになったり。（遠隔地のバックアップ担当者が防火責任者を兼ねてて地震の時には動けないことが判った、とかorz）
また、「バックアップはこうやります」よりも「リストアするときは、こういう感じでリストアします」という説明の方が認識のズレが少なくて済む気がします。ディザスタリカバリなんかでも「壊れた瞬間に戻って欲しい」のか「壊れる1日前に戻って欲しい」のかで異なりますし、話してる内に「1年前に誤って消してしまったデータも当然復旧できると思ってた」とか言われて悶絶することがあります。（実際にデータが必要になってから、一週間のローテーションバックアップを目の前にして言われるよりも万倍マシですが:-P）
どうデータを守るのかで設計が違うのはいつものことですが、バックアップデータって元データと重要度が同じになるのが頭が痛いところ。（「期間が終わったら確実に消さなければならないが、もしかしてミスって消えたら困るのでバックアップが必要」とかだとバックアップ前に運用で対処するのか、リストア時の権限で対処するのかで大きく異なったり。権限者のバックアップ（事故時の予備）も必要だし…）
管理者はわかってるんですが (スコア:4, 興味深い)
特に中小企業
片方壊れても復旧できるんだからいいだろ、という理由で離れた営業所への
ネットワークバックアップすら駄目でした
差分なんてUSBのハードディスクでとればいいだろ、とか
MOに書き出してるから大丈夫とか・・・
あの、会社燃えたらどうするんですかと問えば消火設備があるから
大丈夫とか業務データなんか作り直せばいいとか蒟蒻問答だったので
とりあえず経理データは税理士さんのところでTKCのシステムに
突っ込んでもらうようにしましたが・・・
結局のところ情報資産の価値が見えない以上負の投資で
紙で何とかなる(足りない労働力はサービス残業で)世界ですから
そして何よりも経営者や管理層がことごとく計算機音痴で
現場の電子化は完了しても上層に情報飛ばすときは今でも
紙の稟議書の世界
ベンダに金を払う余裕のない中小の情報化の道のりは長い。
Re:管理者はわかってるんですが (スコア:5, 参考になる)
「機械的に一番故障しやすい回転部品の信頼性をあげるための装置」というわけで、もうへりくつの世界ですが「飛行機が複数台エンジンを積んでいるのと同じで、どちらかが故障しても片方だけで運用ができるようにするための装置です」とか説明しました。
バックアップと冗長化の違いを説明するよりも、ある程度技術語が分かる経営層なら、平均故障間隔とかの言葉でストレートに伝えた方がいい気がします。
とはいえ、中小企業にはバックアップは負担が重いのは事実で、取捨選択の部分でバックアップは常に一番最後に回される存在であることは代わりがありません・・・。そのため「日々更新されて壊れて困るデータは外部のバックアップができているサービスを利用する」とか「消えて困るデータはDVDに焼いてもらって工場間でお互いに持ち合う」といった程度のバックアップ体制となっています。データそのものが商品である業種ではないということもありますが。
ただ、「RAID」がバックアップとは違うものであるということだけは認識してもらっています。今後の整備計画についてはもちろん、何かあったとき経営層に責任を取ってもらうためには重要だと思っています。
Re:管理者はわかってるんですが (スコア:3, 興味深い)
コンピュータが壊れた事になれば、大義名分誤魔化す事が可能になるので経営者にとってはその方が都合がいいんですよ。
彼らの方から見ると「コンピュータ技術者はクソ真面目な人間だ」としか見えません。
Re:管理者はわかってるんですが (スコア:1)
なら問題ないじゃん。
RAIDのミラーリングすら不要だと思いますよ。
ただし、リスクは説明しておいてあげて、文書ではんこ貰っておく程度はしますが..わたしなら..
rsnapshot (スコア:4, 参考になる)
まだ、出て来てなかったようなので。
rsync --delete とかは、-n を、まず付けてとか、常識なんだけど、ひっかかったことはあるな。
DRDB みたいな、ミラーリングは、もちろん、重要なんだけど、
http://www.drbd.org/home/recovery/
履歴管理は別に必要なんだよね。
こういうトピックを年初に繰り返して上げるのは、教育的効果はあると思う。
Re:rsnapshot (スコア:3, 参考になる)
ただ、バージョンが少し違うと全く動いてくれないが結構めんどくさいところです。
以上
言葉の定義が・・・ (スコア:3, すばらしい洞察)
＞ OSやアプリケーションの不具合、もしくは操作ミスなどによる
＞ データ消去/上書きには対応できない。
おじさんとしてはタレこみ文の「ミラーリング」を「RAID」と
全置換するとしっくりくるな。
Re:言葉の定義が・・・ (スコア:1)
> 全置換するとしっくりくるな。
+1
一方、某サーバ室には、既にドライブが無い、DAT, 8mm テープが累々としているのであった。
昔はテープ１本に level 0 dump, level 1 dump ... と入れることができたのに、、、
TimeMachineに助けられました (スコア:3, 興味深い)
Re:TimeMachineに助けられました (スコア:3, 興味深い)
共有フォルダも対象に出来るので、職場のDocumentフォルダとかもこれでやってます。
ときどき生じる「ミス上書き」や「なぜかファイルが破損してて、しかも3ヶ月も誰も気づかなかった時」など、
きちんと毎日のバックアップが残ってることに幾度感謝したことか。
Re:TimeMachineに助けられました (スコア:2, 参考になる)
Windowx XPのNTFSファイルシステムから、仕様上はこの機能はあるんですが機能の一部しか実装されていないみたいなんですよね。Windows 2003サーバやWindows Vistaのファイルシステムをリモートでマウントした場合は「以前のバージョン」も見られるようにはなっているんですが。
# 細かいところで何気に良くなっているのに、目立つところでダメだからダメと言われるかわいそうな子 > Vista
Re:TimeMachineに助けられました (スコア:2, 参考になる)
一番普及してるのは多分Home Premiumでしょうからあまり話題に上らなくても仕方ないんですよ。
＃Vista最大の失敗は小銭稼ごうとして無意味に多数のバージョン作っちゃった事だよなあ
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
言葉にやられる (スコア:3, 興味深い)
その中身を理解しない(しなくて良いから)ようになるのは、
多くの分野で良くある事。だと思います。
最近では、補助記憶装置の例で言えば、
ディスクと言えばRAIDでしょ。壊れたら交換でOK。
と、一言で表現しても違和感が無くなってきましたから、
補助記憶装置の信頼性・耐障害性・可用性・保全性といった、
設計時に考えるべき点を考えなくなってしまったのではないでしょうか？
当然、
今でもミッションクリティカルな皆さんには、
相応の教育がなされていると思うのですが、
そうではない人もたくさん増えたことでしょう。
私が現役だった10-15年前と比べて、
他に知っておくべき事も増えていますから、
仕方がないだろうな。と思うのですが、
最初から便利な道具がそろっているっていうのは、
素直に良い事だとは言い切れませんね...
-- LightSpeed-J
保険が違う (スコア:1, すばらしい洞察)
うちのネットワークRAIDはほぼライトワンスだからいいけど、最近のエロ動画はサイズがバカでかくて困る。
女優以外はロッシー高圧縮してくれていいよ。
何故にAll or nothing (スコア:1, すばらしい洞察)
のであって、
「バックアップにならない」
のとは違うと思う。
# こういう「紛い物を売りつける商売の人」的な論法は避けたほうがよさげ
Re:何故にAll or nothing (スコア:4, 参考になる)
＞のとは違うと思う。
いや、バックアップになっていないのですよ。
RAIDのミラーリングは、ハードディスク単体の物理的障害耐性の向上です。
データのバックアップは、システム全体の論理的物理的破壊への耐性向上です。
同期する時間を長くしたとしても、同期途上の障害や論理的なデータ
の破損にはミラーリングは意味を持ちません。
RAIDのミラーリングは「壊れやしモノがその壊れやすいモノ一個壊れても
稼働を継続する」ためのものですが、バックアップは「何が壊れても論理的に
同じ様に再構築する」ためのものです。
用途・目的が異なるモノを同じものだとするのは、誤りです。
Re:いやだから (スコア:2, すばらしい洞察)
"バック"アップなんだから後ろにあって（つまり退避してあって）いざと言うときに前進してきて仕事をするもんです。
ミラーリングは常に前に居て、一つの仕事を冗長的にこなして片方に障害が発生しても仕事を続けられる仕組みです。
ミラーリングは三塁手と遊撃手で左方向を守っています。万一、三遊間を破られたときにボールを拾うのが左翼手のバックアップです。
（外野フライには内野手は打球に対しての守備はしません）
Re:いやだから (スコア:3, 参考になる)
同期や冗長化はオンラインのデータを失わないようにするもの。
明確に別のものです。結果が同じなら言葉も同じでいいじゃないかというのは
乱暴すぎると思います。
あとバックアップを一回分しか保管しないなんて運用は普通しません。
自分の管理下のサーバーは半年前まで段階的にさかのぼれるようにしてあります。
Re:何故にAll or nothing (スコア:1)
いえいえ、違います。
ある瞬間での障害に耐えるという障害耐性がミラーリング。
ある期間での障害に耐えるという障害耐性がバックアップ。
示された期間、指定されたデータを戻せるか、ある瞬間壊れた
デバイスの代替をデバイスの冗長可による運用継続を同じに
考えてはいけませんよ。
Re:何故にAll or nothing (スコア:1, 参考になる)
ミラーリングを、デバイスの冗長可による運用継続に求めると痛い目見ますよｗ
バックアップだと考えて対処しないと両方ともクラッシュして終わりです。
#CE時代に経験したことからの意見なんだけど、間違ってますかね？
JIS X 0008:2001による定義 (スコア:3, 参考になる)
ということですから、RAID1のミラーリングをバックアップ手続きと言って言えないことはないというのが結論になりそうです。
とはいうものの、データのバックアップ手段を要するという仕様に対してRAID1しかないシステムを納品したら、やっぱり問題になりそうではあります。
Re:何故にAll or nothing (スコア:2, すばらしい洞察)
バックアップですよね。今回の件はRAIDと書いてあるので、
バックアップにはならなかったようですが。
Re:何故にAll or nothing (スコア:3, すばらしい洞察)
一つ絶対的に異なるのは, バックアップでは複数時点の状態に戻れることでしょう.
もちろんこれはバックアップ設計に依存するのですが, ミラーリングの場合には最終の同期以前に論理的な破壊が発生していれば一巻の終わりになります. 一方適切に計画されたバックアップなら, 最新のバックアップは役に立たなくても, それ以前のいずれかの状態までは復旧することができます.
こういう観点からするとミラーリングこそがall or nothingであり, バックアップはもう少しaboutに最善を尽くせると言えます.
Re:何故にAll or nothing (スコア:1)
ミラーリングは同じデータを複数の場所に用意して負荷を分散したりデータを複数の場所に配布したりするのが目的なのであまりタイムラグが大きくなるとオリジナルの方に殺到してミラーの意味がない。
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 (スコア: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:保険が違う (スコア:1, 参考になる)
データが壊れていればバックアップから正しいデータを書き戻さなくてはなりません。
保険で例えるなら、ミラーリングが "休職中の収入を補償する保険" でバックアップが "治療費を補償する保険" でしょうか。
片割れをアンマウント (スコア:1, 興味深い)
HDDのコストさえ考えなければバックアップソフトが必要無いし、取り外した時点では論理的に同一のディスクであるため、以後論理障害が発生しても復旧可能というメリットがあります。
#バックアップソフトを使ったほうが安上がりだし、フレキシブルなのはわかってるんだけど、提案できないのはなんでだろう。
Re:片割れをアンマウント (スコア:5, 参考になる)
> 取り外した時点では論理的に同一のディスクであるため
これ、取り外すタイミングでsyncが完全に実施されていることを確認できないと
ヤバいので、「うちもやろー」とかいう安易な気持ちでやらないようにご注意
ください。> 見てる方
やるのであれば、
・RAIDコントローラの管理画面でsync状態をチェック。
・そのまま静かに電源を落とす。
・保存しておくべきHDDを抜く。
てな感じでやります。
当然ながらこのときOSからはRead Onlyにしておくか、そもそもOSを起動しては
いけませんし、できれば抜く前にBad Block Detection/Recovery(Media Scan)を
かけて、全域チェックをしてからやる方がよいです。
Re:片割れをアンマウント (スコア:2, 興味深い)
ミラーリングは同じロットの同時期の製品を使っていることが多いので、実は片方を交換中にもう一方がお亡くなりになるケースは意外と多いんです。製品寿命がほぼ同一なので(苦笑)
CE時代に、そういう話はよく聞きましたし、私自身も一度経験があります。
意図的に違うディスクユニットを持ってきて交換するのは、その意味でも正解です。
#コスト的に難しいケースがほとんどですがね。
VSS (スコア:1)
「システムの復元」でデータも戻せると思っている人も居るし.....。
Re:地球ごとバックアップすればいいんじゃね? (スコア:5, おもしろおかしい)
太陽の異常や膨張なんかで、おしゃかですね。
太陽系内でミラーリングして、太陽系外、出来たら銀河系外にバックアップしておくと安心かもしれません。
壮大なSFになりそうです。
Re:地球ごとバックアップすればいいんじゃね? (スコア:5, おもしろおかしい)
できれば中学三年生あたりまでロールバックしてもらえませんでしょうか？
なお、コメントとして「アニメ禁止」「男子校は止めろ」「女の子を避けるな」と
記載しておいてください。あ、あれ？ なんかタイピングしにくくなってきた‥‥。
（´・ω・｀）
（´・ω:;.:...
（´:;....::;.:. :::;.. .....
Re:地球ごとバックアップすればいいんじゃね? (スコア:4, おもしろおかしい)
＞できれば中学三年生あたりまでロールバックしてもらえませんでしょうか？
ロールバックしたとして、また同じ事になりますので、現状のデータにパッチを
あてるなどで対処した方がよろしいでしょう。オンラインREDOログにてのデータ
復旧をしないと浦島太郎になってしまうので、注意が必要です。
＞なお、コメントとして「アニメ禁止」「男子校は止めろ」「女の子を避けるな」と
＞記載しておいてください。
2009年という現在にてロールバックしても、貴殿の中学三年生時期と比べて
「新作アニメが増えている」
「これからもテレビなどで放映される」
といった問題があります。
また、男子校においても、活発な行動にて近隣女子校との交流会などと
称しての密度の高い時間をすごす、ある種の高校生リア充もいますので、
男子校が問題というのも難しいでしょう。
むしろ、問題は、「女の子を避けるな」という認識ですね。
「女の子が避ける」という状況を、その様に認識されているという、
既存のデータの不具合と思われます。
Re:地球ごとバックアップすればいいんじゃね? (スコア:2, おもしろおかしい)
あるいは仕様かもしれません。
再インストールをお勧めします。
Re:地球ごとバックアップすればいいんじゃね? (スコア:2, おもしろおかしい)
というわけで、ちょっくら二次元に逝ってきます＜ダメジャン
Re:地球ごとバックアップすればいいんじゃね? (スコア:2, おもしろおかしい)
困ったことに三次元の地球を二次元にバックアップするのは難しいらいしぞ。
しかも、二次元だとツンデレとかヤンデレとか難しいのが多くおるらしくて、
逃げ切れないらしい。
＞ビッククランチや
あれは重量が問題らしいから、食生活に気をつけていたらよいらしい。
ピザとか...
Re:地球ごとバックアップすればいいんじゃね? (スコア:2, おもしろおかしい)
> バックアップしておくと安心かもしれません。
>
> 壮大なSFになりそうです。
挿絵を竹本泉にすることで、壮大感をやわらげましょう。
# あの絵に騙されてるけど、『乙女アトラス』も
# 『トランジスタにヴィーナス』も『のんのんじー』も
# 『てきぱきワーキンラブ』もえらく壮大だよな。
Re:バックアップねえ (スコア:3, 興味深い)
10年ちょっと前(主流のディスクが4GBのころ), 1TB(ディスク数で300個ぐらい)のデータベースのバックアップ/リストアを設計したことがあります. 当時のテープストレージを使ってフルバックアップ/リストアにそれぞれ24時間ぐらい, さらに累積分のリストア+差分トランザクション適応を加えると最悪で復旧に1週間なんてことになってしまって, 苦労した覚えがあります.
この時は最悪ケースをRAIDセット単位のハードウェア破壊と仮定しなおし, 論理的にも特定時点での更新領域のみの差分を取るようにしたりで何とか最悪10時間程度で復旧できるようにしましたが. ただ, 幸いにしてこのリストアサブシステムは今のところ使われていないようです.
その後ディスクのビット単価の低下に伴い, トリプルミラー化やバックアップストレージとして低価格のATAディスクを使うなんてのがエンタープライズ分野では一般的になってきて速度向上には寄与しているんですが, まじめにバックアップを考えている所ほど, リストア時間の短縮には苦労していますね.
Re:良いバックアップソリューションがないので (スコア:2, 参考になる)
http://samba.anu.edu.au/ftp/rsync/src/rsync-3.0.0-NEWS
- A new incremental-recursion algorithm is now used when rsync is talking
to another 3.x version. This starts the transfer going more quickly
(before all the files have been found), and requires much less memory.
See the --recursive option in the manpage for some restrictions.
Re:上で言葉遊びしてる人達はなんなの？馬鹿なの？死ねよ (スコア:2, 参考になる)
そんなHDDを物理的にとっかえひっかえしたら, 最初にコネクタがやられます. 電子機器の運用ではコネクタは可能な限りいじらないのが基本です.
そのため, 物理的な操作を伴わずに同じことをやるのがトリプル(三重化)ミラーです. あるタイミングでディスクの更新を停止し, そこで3台の内の1台をオフラインにします. この状態でも残る2台でミラー運用されているので冗長性は維持したまま通常運用に戻ることができます. オフラインにした1台は更新されずに残るので, これを他の媒体にコピーし, それをバックアップとして保存します. バックアップが終了したら, 外した1台をミラーに戻し, 再同期させます.
この方法ではバックアップ対象のディスクと実運用のディスクが異なっているため, バックアップの時間にかかわらず直ちに実運用に戻れるという利点はそのままに, 最初から抜き差しを考慮した記録媒体(最近なら例えばUSB接続のディスク等も選択肢に入るでしょう)にバックアップできます. また, 複数の媒体にコピーすることも可能ですからダザスタリカバリに備えて地理的に複数の場所にバックアップ媒体を送ることもできます.
エンタープライズサーバなんかでは昔からよく使われる技法です.
# 普通のミラーに比べて費用が50%増しになるのが欠点ですけど