GetSetによる
2004年02月04日 15時34分の掲載
いつ/何の媒体に/何を取るかが問題部門より。
いつ/何の媒体に/何を取るかが問題部門より。
Anonymous Component曰く、"CNET Japanに掲載されたJon Oltsik氏のコラム「
バックアップにご用心」によると
「バックアップ／リストアは相変わらず確実とはほど遠い状態にある」
そうです。200名を超える米国企業のIT担当者を対象にアンケートを行った結果、
「バックアップ作業の失敗」「バックアップがとれているかどうか自信がない」
などの回答が多かったそうです。
理由もいくつか挙げられていますが、「事態が改善されなければ、責任追求訴訟がはじまるのは時間の問題だ」と結ばれています。
個人でもデータ量が増えてくるとバックアップ作業が重要になってくるのですが、表立って利益を生まないバックアップ作業って、企業の中ではどう位置づけられているんでしょう？ 日本でも米国と同じように「確実とはほど遠い状態」なんでしょうか？"
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
|
|
自分の鯖に関しては (スコア:3, 参考になる)
(1)夜間に一時的にサービスを停止
(2)該当パーティションのLVM snapshotを作成
(3)サービス再開
(4)ddで差分バックアップ、終了後snapshotを開放
(5)DVD-Rに追記書き込み
snapshotを作る時間は数秒もかからないので、止まってる時間は1分ぐらいでしょうかね。
問題はこれをちゃんと書き戻せるかだ...
-- やさいはけんこうにいちば〜ん！
Unix って書いてるけどそれ以外でも使えるだろ (スコア:2, 参考になる)
何を recovery したいか考えましょう。
話はそれから。
関連書籍 (スコア:2, 参考になる)
章立てはこうなっています。(URL先より引用)
第１章 はじめに
第２章 計画の策定
第３章 文書の作成
第４章 信頼性の高いシステムの構築
第５章 LANのセキュリティ
第６章 データのバックアップ
第７章 電源のバックアップと調整
第８章 業務再開計画
第９章 復旧計画の策定とテスト
ただ、絶版になってますが。(汗)
ついさっき (スコア:2, おもしろおかしい)
もう少しタレコミが早かったら.........(T_T)
# 今そこにあった危機(T_T)
Re:ついさっき (スコア:2, おもしろおかしい)
>
> # すみません！！
> # 首を引っ掛けてしまいました！
首吊った管理者のバックアップ要員は用意されてますか？
親コメント
汎用のバックアップソフト (スコア:2, 参考になる)
データサイズを自動的に判別してバックアップするソフト「これだけは」 [impress.co.jp]
ということで、Windows/IE/Outlook限定のようですが、バックアップを行う仕組みを提供する汎用のバックアップソフトが出るとか、OSごとに共通のバックアップの機構があって、アプリケーション側がそれに対応する、というようにならないでしょうか。
バックアップの機能こそ、OSに統合されてるといいように思います。
ちなみに最近時々「どうにかならない？」ときかれる事のひとつに、オフィス文書を「保存しますか？」という時に開くダイアログに「いいえ」と答えてしまった場合、復旧できないか、と聞かれることがあります。これもごく短時間でのバックアップをとっているかどうかということになるのですが、さすがにこればっかりは新規ファイルを作った瞬間に保存してもらう癖をつけてもらうほかないですよね。
- Ryuzi Kambe -
いつ/何の媒体に/何を取るかが問題 部門 (スコア:2, 興味深い)
データはもちろんだけど (スコア:2, おもしろおかしい)
# むしろオフトピックなのでＡＣ
Re:データはもちろんだけど (スコア:5, おもしろおかしい)
ボスに相談したら、互換性があれば誰でも構わないと言われました。
Copyright (c) 2001-2009 Parsley, All rights reserved.
親コメント
個人のPCだと (スコア:2, 参考になる)
２ちゃんねるからですが
再インストの前にこれをバックアップしろ！ [2ch.net]
というスレがあったりします。
まぁ、一番最強の保存メディアって紙なんですよね。
火事になっても印画紙を使った写真とか、書籍とかって火事になっても結構焼け残っていて、なおかつ内容が読み取れますし。
#かといって全部をプリントアウトするのはアフォですが
ハードディスクとかは熱や衝撃、水に弱いので、震災のような大規模災害には無力です。
なので、バックアップがちゃんと取れてる、取れていないも大事だとは思いますが、データの保管場所を考えないと真のバックアップにはならないと思います。なんつーか、危機管理にもつながることかと思いますですね。
Re:個人のPCだと (スコア:2, 参考になる)
以前Linux Magazine（号数失念）に紙よりも写真（印画紙）の方が強い、と書いてあった。
火事の時、放水で水浸しになっても写真は大丈夫だった、とのこと。
ちなみに、その記事を書いたライターさん宅が火事になったときのことを
参考にした記事でした。
その火事でライターさんのお父様がお亡くなりになったそうです。
ものすごく、説得力のある記事でした。
親コメント
バックアップそのものについても悩むけど (スコア:2, 興味深い)
戻せるのか、といったことで悩むのは当たり前だけど、 最近は、サービス
止められる制限時間内にバックアップが終わるのか、というのが一番の
悩みですね。
LTOとか高速書き込みしてくれるものを使ってもデータが多すぎて、
バックアップを取りきる前に業務開始時間が来たなんてことが…
ええ、そのときはめちゃくちゃ怒られました。
ハードディスクが安くなって大容量になった恩恵の分、バックアップで
悩んでる人って、多いんじゃないかな。
まぁ、それを補うのにSANやNASがあるとも言えるんですけど。
＃でも、まだまだサーバ向けのSAN、NASは高いな
Re:バックアップそのものについても悩むけど (スコア:3, 参考になる)
> シングルドライブ構成だと、障害時に１日止める覚悟が必要だもんな。
その程度ならかわいいものです. データベースなどでレコード単位のトランザクションログのバックアップを使って時系列順で復旧する場合などには, コールドバックアップからの累積分(数日から最悪数ヶ月以上)を読み込み, さらに順次更新するという作業が必要になるため, まともに復旧を行っていたのでは数日から1週間以上かかるというケースが最近ではごく普通に起こり得ます.
ですから復旧時間を短縮するためには, データの物理的な障害単位をいかに小さくし, そのデータ単位毎にコールドバックアップに近い形式でバックアップを取ることによって, 複雑な操作を避ける設計にすることが重要です. その点でLVMの様なソフトウェアRAIDよりもハードウェアRAID, さらに三重ミラーとの組み合わせによるシンプルなバックアップ手順というのがエンタープライズ用途では主流で, おそらくはかなり下のクラスまで普及するのではないかと思います..
親コメント
目的を明確に (スコア:2, 参考になる)
ハードウェア障害による損失を避けたいなら、RAID 等のリアルタイムでの冗長化が可能な形で。
オペレーションミスによる損失を避けたいなら、世代管理をしてくれるシステムが必要でしょう。
当然、別メディアにバックアップする際には、リストア作業が発生するので、そいつの見積もりも必要。
私はというと、個人的には明確にはやってません。
個々のマシンは RAID で冗長化されているし、複数マシンで作業しているので、程よく分散バックアップされているような状況ですね。
サービスに使っているマシンは、それなりにさらっと戻せるようにはしてあります。
以前… (スコア:1)
実稼働に入った本番用をきれいに消してしまったことがあ
ります。
そのときは、始業前に走らせていたバックアップのおかげで、
「半日分の作業がパー」という程度で済みましたが、一瞬、
頭が真っ白～になりました。
----------------------------------------
You can't always get what you want...
Re:以前… (スコア:2, おもしろおかしい)
＃どうやってリストアするんだろ
にゃにゃ(=－人－=)
親コメント
反省はしたが苦労はしない。 (スコア:1, 興味深い)
苦労は良くないぞ、苦労は。習慣として続かない。
私は数年前よりミラーリングとバックアップソフトの定期実行ですね。
ないにもしないか、せいぜいワンクリックでバックアップを実行します。
テープなどを使うと「苦労」するので相手は常にハードディスク。
PS.バックアップの場合ちゃんと暗号化しています? >ALL
Re:反省はしたが苦労はしない。 (スコア:3, 参考になる)
僕の場合は必要データのほとんどが プログラム、ドキュメント類なので、
・全部CVS化
・定期的にCVSサーバのリポジトリを別サーバにバックアップ
・一カ月おきにメディアに焼く
という感じで足りてます。ハードディスク吹っ飛んだ時も、
CVS入れてcheckoutするだけでリカバリできますし。
＞苦労は良くないぞ、苦労は。習慣として続かない。
これは同意。うちではプログラム初心者の
後輩が入ってきた時、最初から
「そうするもんだ」
としてCVS化してしまいました。
おかげで何か作業をした後にはcvs commitが習慣化しています。
どうでもいいですが、commitってやると、
ひと仕事終わった！って気になるんですよね・・・。
#ボーナス消費中
親コメント
いつcommitするのか （Re:反省はしたが苦労はしない。 (スコア:2, 参考になる)
> ひと仕事終わった！って気になるんですよね・・・。
これについて、Radium Softwareかなんかのコラムで面白いことが書いてありました。
「commitして帰ると、もしバグがあった場合に対応できないから、みんなの仕事が遅れる。だからcommitするなら朝にやれ。」という感じの内容で、確かにその通りで僕も気をつけるようにしています。
問題は僕のCVSは僕しか使ってないという所ですが。
親コメント
NAS+DLT (スコア:1)
バックアプ中、グループウェアの運用が停止するんで、出来るだけ
短時間で処理したいけど、高価なテープ装置は買えないし、夜間、
一旦NASにバックアップして、翌日、手作業でNASのバックアップ
データをDLTに再度バックアップしてます。
ただ何となくテープというメディアより、HDDの方が確実にバック
アップ出来てそうな気はしますけどね。
Re:テープなら (スコア:2, 参考になる)
> なって効率が良くなるかも。
そーでもないですよ。NFS だと差分検証と差分伝送の合計で結局ネットワーク上を全データが流れるんで、差分だけ伝送するっていう rsync の旨味がなくなってしまいます。
VPN してるなら rsync -z --rsh=rsh でディスクをローカルマウントしている装置同士でやりとりするのが多分効率がいいです。
親コメント
Re:NAS+DLT (スコア:2)
のですが、Linuxの場合、ルートファイルシステムをLVで運用
しても問題はないでしょうか。やはり、カーネルを置く /boot
だけは別にしてLVMの管理外にしたほうがいいのでしょうかね。
親コメント
Re:NAS+DLT (スコア:2, 参考になる)
というわけで、ルートディレクトリに、スナップショットを作成する目的でLVMを適用するのは無理っぽいです。でもそんな事したい人いないかな？ 動的なディスクの追加とかが目的ならいけるかもしれません。
また、上記の問題は置いておくとしても、LinuxのLVMは Logical Volume レベルのスナップショットであるが故に、ファイルシステムの整合性を取るためには必ず umount してディスクイメージを確定する必要がある [samba.gr.jp]という問題もあるみたいです。
カーネル2.6からのLVM2ではどうなっているのか分かんないです。詳しい方教えて下さい。
親コメント
Re:NAS+DLT (スコア:2)
アンマウントしないと、ジャーナリングファイルシステムの
(マウント可能な)スナップショットをとれないというのは、
あまりにも痛いですね…。やはり、商用のVxFSとVxVMの組み
合わせしかないのでしょうか(いずれにしても、ルートファイル
システムは厳しそうですが)。
SolarisのUFSスナップショットは、UFSロギングと組み合わせても
OKでしょうかねぇ…
親コメント
ハードウェアRAID (スコア:1)
バックアップ対象が大きくなりすぎて、リムーバブルメディアだと数枚になったりするのと、今はハードディスクのGB単価が安いので。
ホットスワップ対応なので、3台ディスクを用意しておいて適当な頃合をみはからって交換してます。
物理的に外しておけば安心ですし、自動的にリビルドしてくれるので楽といえば楽です。
学級委員さん、ちゃんとしてくださーい (スコア:1)
実際には誰に押し付けるかが重要な問題、ってとこか。
そう、小学校の時の学級委員のような。
--------------------
/* SHADOWFIRE */
ありがちな例 (スコア:1, おもしろおかしい)
Re:ありがちな例 (スコア:2, すばらしい洞察)
親コメント
Re:ありがちな例2 (スコア:4, おもしろおかしい)
結構対応ハードウェアの数はあると思うのですが...
例えば,古参のSEさんとか.
親コメント
rm * (スコア:1)
rm *
を実行してしまった時ほど、バックアップが欲しいと思ったことはありません・・・。
＃つい最近やっちゃいました・・・。
うきゅ〜
Re:rm * (スコア:2, 参考になる)
とすべきでしたね。
UNIX への招待、で教えてもらったんだっけ。 > .??*
親コメント
Re:rm * (スコア:4, 参考になる)
rm -f -i だと-iが優先だから。
親コメント
Re:rm * (スコア:2, 参考になる)
\rm -rf *
エイリアス無効にしてくれます。
親コメント
ついこのあいだ (スコア:1)
/home以下 80～90G程飛ばしました。
けっきょく書い足さなくてもよかった事になってしまった訳ですが、
バックアップは取ってなかったのですべて消えてしまいました。
せめて亡くなった猫達の写真だけでもDVD-RAMに出しておく
べきだったと後悔していますが、もう遅いですねハイ。
とりあえず、作業コピー以外は先週から rsync で最低3台の
マシンにミラーするようにしてます。
4台中3台が同一家屋にあるので、火事と電源からみが
まだちと不安ではありますが、外部メディアへちょくちょく書き出す
のは手間がかかりすぎるんですよ。
wild wild computing
Re:ついこのあいだ (スコア:2, すばらしい洞察)
紙にプリントしておくっていうアナログな手段も検討されたし。
[udon]
親コメント
復活ツール (スコア:2, 参考になる)
[fol] Linux、FreeBSDで削除したファイルの復活 [luky.org]以下のスレッドを参考 にさせていただきましたです。結局、salvage-1.0: ディスクからファイルを救出する [imasy.or.jp]を使って復旧できました。
ファイルが完全に復旧されるという保証はないですが、万一のときに備えて/usr以下にでも突っ込んでおいた方がいいですよ。
飛ばしてしまってからあわててGoogle、数分後にツール発見で、すごく運がいいと思うAC
親コメント
してません (スコア:1)
なぜかバックアップ取ると、一週間もしないうちに壊れて、バックアップが役に立つんですよね。
取ってない時は壊れないので、取らないほうがいいみたいです(をい
Re:してません (スコア:2, おもしろおかしい)
さらに、万一壊れても、リカバリなんていう面倒なことを
せんでもよいというメリットがありますね。
親コメント
Re:してません (スコア:2, おもしろおかしい)
「こんなこともあろうかと」予備を用意して
おいたのだよ...という台詞を吐きたいという
のも、隠せないと...
親コメント
まぬけ (スコア:1)
シリアス度は足りないのですが、
バックアップ前にツリーを圧縮して、
iso イメージではなくその圧縮ファイルを
そのまま焼き付けてしまった苦い想い出があります。
いろんなデータが走馬灯のように…。
Shiromal@ぼんやりさん
Re:まぬけ (スコア:2)
いいんじゃないですか。焦らないことも大事です。
親コメント
こまめに取っていますが (スコア:1)
DVD-R(１倍メディア)で焼いているのでなかなか終わりません。
結果、ディスクの空きとバックアップ&削除の追いかけっこになっています。
負けると、増設してます。(^^;
致命的にならないくらいは… (スコア:1)
致命的にならないくらいの範囲でバックアップしています。
具体的にはWindowsシステムドライブ(Cドライブ)をディスクイメージで丸々、外付けハードディスクにバックアップしてます。
容量的には最大40GBです。
で、外付けハードディスク(160GB)はバックアップしていません。
消えちゃ困る物も多いけど。
次に会社のサーバ。
私が製品選定をして購入をかけたサーバについては、搭載ディスク丸々を1晩でフルバックアップできるくらいのバックアップ装置を付けてます。
(RAID1/5、バックアップは毎晩)
上司にはバックアップはRAIDを搭載していても必要だと言うことを説明しています。
ただ、他の人が購入をかけたサーバは、あまりバックアップを考慮していないみたいです。
ま、たまにサーバが壊れてデータ消失があっても、消えちゃったということで上司に報告しているようで、そっちの部署のポリシーがどうなっているのかよくわかりませんが。
余所任せ (スコア:1, 興味深い)
そこで rsync で大学送りにしてます、出来るところに任せちゃう。
大学のディスクが飛んだらどうするかって？
それを復旧するのは……あ、俺だ(死
自宅の場合 (スコア:1)
バックアップテープを2組作成して，片方を実家に。 CDRやDVDと違って普通は読めないので， 得ろ画像が入っていても安心です。:)
HIRATA Yasuyuki
会社のはミラー、自宅のはゴースト (スコア:1)
/etc の下とかは他のWinなPCにコピーしたりしてますが。
ゴーストって便利ですよ。80～120GBぐらいあっても30～40分ほどです。
サイズが変わっても起動ディスクで立ち上げ、grub だけ、
# /usr/sbin/grub-install /dev/hda でOKです。
backupは、1～2ヶ月に１度ぐらいの頻度ですが。
昔はどうだったんだろう (スコア:1)
逆にその時代を現役だった方は磁気ディスクへの時代変化を不安に感じていたんじゃないかなぁ。
#今はデータ量がアレなんでどうしようもありませんが。
知識が無いと痛い目を見る、それが馬鹿なりの経験 (スコア:1, 参考になる)
私は皆さんほどの知識・テクニックがありませんで...
昨日、会社の個人用端末のレジストリが壊れて(ユーザを消したのがまずいのか、そのユーザしか読めない項目は Administrators からも読めなくなりました) IE の緊急パッチもあてられない Widows XP Professional を再インストールしたのですが、ドキュメント・ソースコード・メールそれぞれを ZIP 圧縮した計3ファイルを1枚の CD-R に焼いたらその CD-R は CRC エラーで読めないことが再インストール後に分かったんですよ。ドキュメントとソースコードはなんかの拍子に読めたんですが、メールは結局戻ってきませんでした。
知識の無い私ですがこれからは「バックアップメディアから正しくリストアできるか」だけは確認しようと肝に銘じました。
そもそも (スコア:1)
すぐに思いつくのはメールアドレスだが、電話etc.の別の手段で聞けばいいだけだし、
メール以外の連絡先がない、という相手なら、なくなっても困らない程度の関係だろうし。
＃ということで、家のマシンでバックアップなんて取ったことないのでID。
Re:せめて買う前に言えよ (スコア:1, すばらしい洞察)
しかも、話を聞いていくと
向こうの要求を満たすには、いまあるバックアップ装置では
到底間に合わないとかいうことも…
親コメント
Re:天災用バックアップ (スコア:1)
耐火金庫の中って、燃えはしないにしろ、それなりに高温になりますよね。現金や紙の書類は無事でもテープメディアは耐えられるんでしょうか。
そいう用途向けの耐火金庫ってのがあるんですか？
[udon]
親コメント
Re:天災用バックアップ (スコア:2, 参考になる)
そういう用途向けの耐火金庫もあるです。一例 [firecooler-shop.com]
# つまりそういう用途向けでなきゃ磁気メディアなんてすっとぶってこった
親コメント
Re:前の職場にて (スコア:1, すばらしい洞察)
「これからバックアップ作業を行うのでファイルを開放してください」って、本当は必要なかったとしても作業を中断させて。
そうすりゃより多くの人間が時間外労働をせざるをえなくなり、命令を下した奴も己の馬鹿さ加減に気づくだろう。
親コメント
Re:天災用バックアップ (スコア:1)
私が設計した某化粧品メーカの経理システムでは, 特に重要なデータのみをネットワーク経由で1日毎に地方に設置された工場のメインフレームとの間で同期をとるようにしていました. さらにデータベースのコールドバックアップは業務の停止している夜間に8mmテープにイメージバックアップを取り, 翌日の物理メール便で工場におくる運用になっていました.
このシステムもほとんど10年前の物なので, DB容量も数GBということでバックアップ運用の設計も楽だったですね. とは言っても夜間のバッチとバックアップでほとんど24時間連続運転が続くことが多かったですが.
親コメント
そんなあなたにひとこと (スコア:1)
にゃにゃ(=－人－=)
親コメント
Re:バックアップって (スコア:1)
親コメント
Re:天災用バックアップ (スコア:1)
その(2)に居たときはソースだけ毎週金曜日にdatasafe とかいう会社がバックアップテープを取りに来ていた。http://www.datasafe.com かもしれない。
親コメント