アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
rsnapshot (スコア:4, 参考になる)
まだ、出て来てなかったようなので。
rsync --delete とかは、-n を、まず付けてとか、常識なんだけど、ひっかかったことはあるな。
DRDB みたいな、ミラーリングは、もちろん、重要なんだけど、
http://www.drbd.org/home/recovery/
履歴管理は別に必要なんだよね。
こういうトピックを年初に繰り返して上げるのは、教育的効果はあると思う。
Re:rsnapshot (スコア:3, 参考になる)
ただ、バージョンが少し違うと全く動いてくれないが結構めんどくさいところです。
以上
rsyncでバックアップしてます (スコア:1, 参考になる)
うちのドキュメントサーバは昔はpdumpfsでバックアップしていたのですが
以下のようなことがあったので現在は別マシンにrsyncで毎日バックアップしています。
1.同一マシンでは障害時のバックアップにならない
2.同一マシンに詰めるHDD容量には限りがある(同一マシンにpdumpfsのレポジトリを用意するのがつらい)
3.rsyncはOS標準で入っていることが多い
コマンド:
rsync -e ssh -aH --delete --link-dest=yymmdd-1 host:src yymmdd/
(確かオプションはこんな感じ --link-destがミソ)
あとはpdumpfsと同様にファイルが更新されてない場合でも
ディレクトリのinodeは食うので保存するデータを減らすために
a.前日バックアップと当日バックアップ比較し
差分ファイルのみをtarballで保存(保存先はさらに別マシン)
b.スナップショット自体は1ヶ月保存
なにかあった場合は1次バックアップ先のスナップショット1ヶ月分から、
それよりも前のデータは2次バックアップ先に圧縮保存したファイルから復旧することができます。
1次バックアップ先が死んでも2次バックアップ先の圧縮ファイルを順々に処理していけば
最新のバックアップを再現することもできます
extのdump/restoreのインクリメントバックアップだと保存できる
世代数に限界があるのでこのようにしました。
うちはSubversionで Re:rsyncでバックアップしてます (スコア:1)
うちの場合、個人だと壊れて困るのは写真とか文章なので、Subversion使ってます。(写真はFlickrへ)
ファイルサーバにSubversion入れてネットワーク越しに投げてます。Subversion側はコミットされたら他のSubversionにまた投げて多重化してます。
で、帰省の前にdumpをDVDに焼いて持って帰る:-)
(昔は毎日dump吐いてバックアップしてましたが、リストアがめんどくなったので)
利点は、管理の手間がほとんど要らないこと、どの時点にでも戻れること、代替機から取り出しが楽なこと、柔軟に構成を変えられること。
欠点は、複数台のマシンが必要になること、家が火事になったら半年前のデータに戻ること、サイズが際限なく増えていくこと。
最大の欠点は、バックアップの基礎の基礎たる「全てをバックアップ=バックアップしないモノを選ぶ」ではなくて「バックアップするモノを選ぶ」運用になってること。
本当に消えて困るデータはPCに入ってないからかなあ…
DRDB → DRBD (スコア:0)
http://srad.jp/developers/article.pl?sid=07/12/09/2038217 [srad.jp]
lsyncdも使ってみたいのですが、kernelのバージョンによっては再構築
とか必要そうですし。更新の多い環境には向いてないみたいだし。(そん
な場合はDRBD使った方がいいよーって書いてあった気が)
http://code.google.com/p/lsyncd/ [google.com]
MogileFSとかもパフォーマンスがよければ使ってみたいけどアプリ側に
変更を強いるので、途中から導入はちょっと腰が引