今時tar.gzでバックアップか？ - 2007-10-31 - ’(rubikitch wanna be (a . lisper))
http://nl.sios.com/tech/dvd_backup.php tar.gzによるバックアップの信頼性がやばいことくらい今じゃ常識だと思うが、会社のサイトにこんな文書載せるのはどうかと思う。 d:id:rubikitch:20070821#1187704003 http://www.linux.or.jp/JF/JFdocs/Backup-mini-HOWTO/ ↑の文書が示しているように、1バイト書き変わっただけでファイルが全滅する恐れがある。 今ならバックアップはsquashfsがよい。高信頼性、高圧縮率。おまけにSystemRescueCdから読み込み可能。SystemRescueCdは高圧縮な圧縮アルゴリズムを採用したsquashfs-lzmaも読み込める。というかSystemRescueCdはsquashfs-lzmaで圧縮している。 バックアップすることも大事だが
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
2002/11/07 自宅(1) 「復活の日: FreeBSD ディスククラッシュ事件総括」
前回からの続き。 とりあえず、結論から言うと、データの救出は可能でした。 画像ファイルもほとんどすべて戻ってきました。 よかった！ てなわけで、一応最初からまとめた状態で今回のトラブルをまとめてみましょう。 FreeBSD におけるディスククラッシュからの救出のサンプルにはなるでしょう。 また、fsck する部分以外は他の OS でのクラッシュ時も応用がききそうです。 Windows のクラッシュしたディスクも、FreeBSD マシンに接続して、 この方法である程度復旧できる可能性もあるんじゃないかな？ 1 年と少し後になりましたが、 このノウハウの応用で BIOS からさえ認識されなくなったディスクから、 Windows XP の NTFS パーティションを救出しました。 詳しくはこちらのページをご覧下さい (2004/03/14 追記) さらにこの辺によると、最近は dd(1) の i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hard Disk Upgrade Mini How-To
