バックアップ、してますか? 177
ストーリー by GetSet
いつ/何の媒体に/何を取るかが問題 部門より
いつ/何の媒体に/何を取るかが問題 部門より
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先より引用)
第1章 はじめに
第2章 計画の策定
第3章 文書の作成
第4章 信頼性の高いシステムの構築
第5章 LANのセキュリティ
第6章 データのバックアップ
第7章 電源のバックアップと調整
第8章 業務再開計画
第9章 復旧計画の策定とテスト
ただ、絶版になってますが。(汗)
ついさっき (スコア:2, おもしろおかしい)
もう少しタレコミが早かったら.........(T_T)
# 今そこにあった危機(T_T)
Re:ついさっき (スコア:1)
手ですか...私は,足でやった事があります.
ええ,もちろん電源ケーブルに足を引っかけてですが...
# バッキャロー!!
# ケーブルが抜けないように虎縞テープで固定しておけ!!
Re:ついさっき (スコア:2, おもしろおかしい)
>
> # すみません!!
> # 首を引っ掛けてしまいました!
首吊った管理者のバックアップ要員は用意されてますか?
汎用のバックアップソフト (スコア:2, 参考になる)
データサイズを自動的に判別してバックアップするソフト「これだけは」 [impress.co.jp]
ということで、Windows/IE/Outlook限定のようですが、バックアップを行う仕組みを提供する汎用のバックアップソフトが出るとか、OSごとに共通のバックアップの機構があって、アプリケーション側がそれに対応する、というようにならないでしょうか。
バックアップの機能こそ、OSに統合されてるといいように思います。
ちなみに最近時々「どうにかならない?」ときかれる事のひとつに、オフィス文書を「保存しますか?」という時に開くダイアログに「いいえ」と答えてしまった場合、復旧できないか、と聞かれることがあります。これもごく短時間でのバックアップをとっているかどうかということになるのですが、さすがにこればっかりは新規ファイルを作った瞬間に保存してもらう癖をつけてもらうほかないですよね。
- Ryuzi Kambe -
Re:汎用のバックアップソフト (スコア:1)
1分とかに指定しておけば、まぁ大丈夫でしょう。
# ディスクを圧迫しそうだけど
というか、その場合は×で閉じてしまってるような気がするので
ちゃんと保存してから終了するのを啓蒙した方が良いような気がしますね(^^;
いつ/何の媒体に/何を取るかが問題 部門 (スコア:2, 興味深い)
データはもちろんだけど (スコア:2, おもしろおかしい)
# むしろオフトピックなのでAC
Re:データはもちろんだけど (スコア:5, おもしろおかしい)
ボスに相談したら、互換性があれば誰でも構わないと言われました。
Copyright (c) 2001-2014 Parsley, All rights reserved.
個人のPCだと (スコア:2, 参考になる)
2ちゃんねるからですが
再インストの前にこれをバックアップしろ! [2ch.net]
というスレがあったりします。
まぁ、一番最強の保存メディアって紙なんですよね。
火事になっても印画紙を使った写真とか、書籍とかって火事になっても結構焼け残っていて、なおかつ内容が読み取れますし。
#かといって全部をプリントアウトするのはアフォですが
ハードディスクとかは熱や衝撃、水に弱いので、震災のような大規模災害には無力です。
なので、バックアップがちゃんと取れてる、取れていないも大事だとは思いますが、データの保管場所を考えないと真のバックアップにはならないと思います。なんつーか、危機管理にもつながることかと思いますですね。
Re:個人のPCだと (スコア:2, 参考になる)
以前Linux Magazine(号数失念)に紙よりも写真(印画紙)の方が強い、と書いてあった。
火事の時、放水で水浸しになっても写真は大丈夫だった、とのこと。
ちなみに、その記事を書いたライターさん宅が火事になったときのことを
参考にした記事でした。
その火事でライターさんのお父様がお亡くなりになったそうです。
ものすごく、説得力のある記事でした。
バックアップそのものについても悩むけど (スコア:2, 興味深い)
戻せるのか、といったことで悩むのは当たり前だけど、 最近は、サービス
止められる制限時間内にバックアップが終わるのか、というのが一番の
悩みですね。
LTOとか高速書き込みしてくれるものを使ってもデータが多すぎて、
バックアップを取りきる前に業務開始時間が来たなんてことが…
ええ、そのときはめちゃくちゃ怒られました。
ハードディスクが安くなって大容量になった恩恵の分、バックアップで
悩んでる人って、多いんじゃないかな。
まぁ、それを補うのにSANやNASがあるとも言えるんですけど。
#でも、まだまだサーバ向けのSAN、NASは高いな
Re:バックアップそのものについても悩むけど (スコア:3, 参考になる)
> シングルドライブ構成だと、障害時に1日止める覚悟が必要だもんな。
その程度ならかわいいものです. データベースなどでレコード単位のトランザクションログのバックアップを使って時系列順で復旧する場合などには, コールドバックアップからの累積分(数日から最悪数ヶ月以上)を読み込み, さらに順次更新するという作業が必要になるため, まともに復旧を行っていたのでは数日から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の方が確実にバック
アップ出来てそうな気はしますけどね。
テープなら (スコア:1)
(ワシも昔は定期的にフルバックアップのテープを倉庫会社に預けていた)
Re:テープなら (スコア:1)
です。DLTは週に1回ですが遠くの支店に送ってます。
ただ「運送会社に頼んでDLTを送るのも今時、何だかなあ」と感じて
ます。支店とVPNで接続しNASのデータを送り込めたらなあと。し
かし、60Gも有るデータをちゃんと送れるのかしら?
Re:テープなら (スコア:1)
以前、ADSL経由のVPNで、それぞれの拠点ファイルサーバ同士で
rsync -sshで、リモートバックアップをとりあってました。
Re:テープなら (スコア:2, 参考になる)
> なって効率が良くなるかも。
そーでもないですよ。NFS だと差分検証と差分伝送の合計で結局ネットワーク上を全データが流れるんで、差分だけ伝送するっていう rsync の旨味がなくなってしまいます。
VPN してるなら rsync -z --rsh=rsh でディスクをローカルマウントしている装置同士でやりとりするのが多分効率がいいです。
Re:テープなら (スコア:1)
>です。DLTは週に1回ですが遠くの支店に送ってます。
1Gbps回線が安くなって身近になったら、
遠隔地同士でinternet越しのNAS RAIDみたいなモノが
実用的に使えるようになるのかな。
常時、リアルタイムで、地理的に離れた遠隔地にデータのバックアップ。
internet回線上でのレイテンシーとIP変換のオーバヘッドが
問題になりそうだから、
常時大量のデータが読み書きされるような
大規模データベースでは難しいか・・・。
小規模で軽い処理しかしていないデータベースなら、
現状の100Mbps回線上でも、遠隔地NAS RAIDも可能かな?
Re:NAS+DLT (スコア:1)
使うというのはどうでしょう。
snapshot の作成の時だけサーバをとめればあとは作成した
snapshot からゆっくりコピーできます。
負荷が高いサーバだとそもそもバックアップのためのディスク
アクセスが問題になっちゃったりするのかもしれませんが...
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 * (スコア:4, 参考になる)
rm -f -i だと-iが優先だから。
Re:rm * (スコア:2, 参考になる)
\rm -rf *
エイリアス無効にしてくれます。
Re:rm * (スコア:2, 参考になる)
とすべきでしたね。
UNIX への招待、で教えてもらったんだっけ。 > .??*
ついこのあいだ (スコア: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)
いいんじゃないですか。焦らないことも大事です。
Re:せめて買う前に言えよ (スコア:1, すばらしい洞察)
しかも、話を聞いていくと
向こうの要求を満たすには、いまあるバックアップ装置では
到底間に合わないとかいうことも…
Re:天災用バックアップ (スコア:2, 参考になる)
そういう用途向けの耐火金庫もあるです。一例 [firecooler-shop.com]
# つまりそういう用途向けでなきゃ磁気メディアなんてすっとぶってこった