アカウント名:
パスワード:
ちなみにQuantumはわかりませんでしたが、SeagateのLTOは32MB/sとのことです。
5年ほど前に500GB程度のデータベースの復旧計画を設計したことが有るのですが, フルバックアップから復旧するような最悪 ケースでは, システムがほとんど24時間運転でフルバックアップが半年に1回しかできないこともあって, トランザクションログの完全適応で最新の状態まで戻すのに1週間かかるなんて計算になってしまったことがあります.
最終的にはデータベースの領域分割の設計で, 障害が全体に及ばないようにして, 最悪でも半日以内で復旧できるようにしたのですが, 最近の100GBオーバのディスクの様に障害範囲の局所化ができないような構成だと, 3重ミラーとかを使って時間的に短い間隔でバックアップを取れるようにするしか対応方法が無さそうですね.
将来的には240MB/sを目指しているようです。
これはディスクでやったほうがメリットが大きいかな。
ネタかなぁ…
VTR の業務用デュプリケータが、まさにこれですけど。
ヒステリシスが非常に大きなメタルテープのマスターテープ を使い、これに生テープを密着させて、外部から磁場をかけ ます。印加された磁場はマスタテープに記録されている磁気 パタンによってバイアスがかけられた形で生テープに加え られるため、磁場が取り除かれると、メタルテープに記録 されていた磁気パタンが生テープ側に転写されます。
数千本以上、場合によっては数万本のコピーを普通の VTR なんかではとてもやってられませんからねぇ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
容量が大きいのは結構だけど (スコア:0)
テープ媒体だと特に。
データ転送速度について (スコア:2, 参考になる)
ちなみにQuantumはわかりませんでしたが、SeagateのLTOは32MB/sとのことです。
ってことは・・・ (スコア:1)
----------------------------------------
You can't always get what you want...
甘い! (スコア:4, 参考になる)
5年ほど前に500GB程度のデータベースの復旧計画を設計したことが有るのですが, フルバックアップから復旧するような最悪 ケースでは, システムがほとんど24時間運転でフルバックアップが半年に1回しかできないこともあって, トランザクションログの完全適応で最新の状態まで戻すのに1週間かかるなんて計算になってしまったことがあります.
最終的にはデータベースの領域分割の設計で, 障害が全体に及ばないようにして, 最悪でも半日以内で復旧できるようにしたのですが, 最近の100GBオーバのディスクの様に障害範囲の局所化ができないような構成だと, 3重ミラーとかを使って時間的に短い間隔でバックアップを取れるようにするしか対応方法が無さそうですね.
補足 (Re:甘い!) (スコア:4, 参考になる)
さて、3重ミラーで何をするかですが、バックアップを取りたくなったら、3重から1台を切り離します。残った2重ミラーの方は、そのまま営業を続けます。 切り離した1台で、のんびりフルバックアップなぞを取ります。
作業が終わったら、何事も無かったかのように切り離した1台を元に戻して同期を取らせます。
こうすることで、downtimeをかなり減らせるのです。(たぶん)
-----
最初にこの構成を聞いたときは、なんてゼータクな、と思ったのですが、どうも大まじめに検討される構成のようです。
fgd@素人
Re:補足 (Re:甘い!) (スコア:0)
Re:補足 (Re:甘い!) (スコア:1)
バックアップはしても、リストアの練習をする人は少ない。テープのベリファイも省略する人が多いし。
新しいマシンを買ったばかりで意味のあるデータがまだ書き込まれていないうちに、わざと消してリストアの練習をすべき。
以前某業者にRAIDのパラメータを変更するため一旦 フルダンプを取ってからあとで戻す、という作業をしてもらった ことがあったが、見事にリストアに失敗してデータの全損失。 いや、その業者がなっとらん、というのではなくて、そのくらいリストア作業は失敗しやすいという話。
Re:データ転送速度について (スコア:1)
怪しいデバイスがありました。
勢いで買ったのですが、120分テープで200MBって事は、
200MBバックアップするのに2時間・・・
それに気がついた直後に、ZIPドライブを買いに走しりました(笑
#200MBあれば、Amigaでは十分なんですけれどね。
AMIGA4000T(60/50)使い
Re:データ転送速度について (スコア:1)
Amiga用であったかPC用であったか定かではありませんが、昔雑誌で「画面写真」入りの紹介をみたことがあります。
結構粗い解像度のブロック模様が映っていました(^_^)
2時間=7200秒=432,000フィールドですから、
200,000,000/432,000=463バイト/フィールド(正味)を記録できればよいことになります。各種エラー訂正コードを入れて100x100程度の
解像度ならば15年前でも何とかなったでしょうね。
Re:データ転送速度について (スコア:0)
絵に描いた餅で良ければIBMのLTOも160MB/sec [ibm.com]を目指しているようですが、「第2世代」から全然進んでない...
Re:容量が大きいのは結構だけど (スコア:2, すばらしい洞察)
転送速度も含めると三重苦。
Re:容量が大きいのは結構だけど (スコア:1)
Re:容量が大きいのは結構だけど (スコア:0)
これはディスクでやったほうがメリットが大きいかな。
Re:容量が大きいのは結構だけど (スコア:2, 参考になる)
ネタかなぁ…
VTR の業務用デュプリケータが、まさにこれですけど。
ヒステリシスが非常に大きなメタルテープのマスターテープ を使い、これに生テープを密着させて、外部から磁場をかけ ます。印加された磁場はマスタテープに記録されている磁気 パタンによってバイアスがかけられた形で生テープに加え られるため、磁場が取り除かれると、メタルテープに記録 されていた磁気パタンが生テープ側に転写されます。
数千本以上、場合によっては数万本のコピーを普通の VTR なんかではとてもやってられませんからねぇ。
--- Toshiboumi bugbird Ohta
Re:容量が大きいのは結構だけど (スコア:1)
>コピーできる、なんてのは実現できないかなあ。
それって恐くない?
刺激が弱いと、まだらにコピーされたり。
PCにECC Registeredメモリの利用を推奨します。
Re:容量が大きいのは結構だけど (スコア:1)
バックアップは、ディスクを取り出して印画紙の上に置いて
フラッシュ焚いてやればオーケーっていうのができないかな。
復元のプロセスは、印画紙からネガを作ってディスクの上に載せて
やっぱりフラッシュ焚いてやればオーケー、と。
# たんなる思いつきなのでID
Re:容量が大きいのは結構だけど (スコア:0)
Re:容量が大きいのは結構だけど (スコア:0)