
Ubuntu日本語フォーラム

ログインしていません。
Déjà Dup が原因不明のエラーを吐いて、全然復元できません。
以下のエラーの内容から、対処方法の分かる方はいませんか?
バックアップ・ツールが復元できないというのも、
困ったものです。ほかの手段は全然用意していなかったので、
お手上げです。
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1239, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1232, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1190, in main
list_current(col_stats)
File "/usr/bin/duplicity", line 515, in list_current
for path in path_iter:
File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 344, in combine_path_iters
refresh_triple_list(triple_list)
File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 330, in refresh_triple_list
new_triple = get_triple(old_triple[1])
File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 316, in get_triple
path = path_iter_list[iter_index].next()
File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 229, in sigtar2path_iter
for tarinfo in tf:
File "/usr/lib/python2.6/dist-packages/duplicity/tarfile.py", line 1211, in next
tarinfo = self.tarfile.next()
File "/usr/lib/python2.6/dist-packages/duplicity/tarfile.py", line 543, in next
buf = self.fileobj.read(BLOCKSIZE)
File "/usr/lib/python2.6/gzip.py", line 219, in read
self._read(readsize)
File "/usr/lib/python2.6/gzip.py", line 267, in _read
self._read_eof()
File "/usr/lib/python2.6/gzip.py", line 304, in _read_eof
hex(self.crc)))
IOError: CRC check failed 0x887dc08cL != 0xe0232affL
オフライン
ytakagi による投稿:
File "/usr/lib/python2.6/gzip.py", line 304, in _read_eof
hex(self.crc)))
IOError: CRC check failed 0x887dc08cL != 0xe0232affL
上記のエラーを見るとCRCが一致しないことが問題のようです。
バックアップを取った先のメディアなどに異常は発生していないでしょうか。
オフライン
10.04 を使用してますが、システム・メニューのシステム管理、ディスク・ユーティリティから
SMART情報なるものを見てみましたが、ディスクは正常です、と出てますねぇ。
いままで小さなデータで復元のテストをしたことはありましたが、
数十GBの実際の自分のホーム・ディレクトリを復元しようとしたのは初めてです。
データが大きい場合、復元できないのかな? と思いはじめています…
デジカメの写真(数千枚)が失われてしまったようで、残念です。
みなさん、バックアップはどうしてるんでしょう?
sbackup も動作がおかしくてイヤになりましたし、Déjà Dup もどうも信用できない気がします。
rsync をcronで動かすとか?
難しそうですが、挑戦してみようかな…
オフライン
ほとんどオフトピですが、
ytakagi による投稿:
~略~
デジカメの写真(数千枚)が失われてしまったようで、残念です。
みなさん、バックアップはどうしてるんでしょう?
sbackup も動作がおかしくてイヤになりましたし、Déjà Dup もどうも信用できない気がします。~略~
解決策でなくて申し訳ありませんが、同じく写真が趣味ですので、保存方法はDVDやCDがほとんどで、ハードディスクのバックアップはしていません。Ubuntuをインストールする場合はクリーンインストールです。データはLAN接続のHDDで、RAID10で運用しています。
ローカルHDDには保存しません。特に写真などのデータはある程度まとまった時点でDVDに、1枚では心もとないので、複数枚にコピーしています。最近ビデオをもって海外に出かけていますので、かなりの容量が必要になりましたので、スピードを上げるため、USB接続のRAID-HDDの増設を考えています。
オフライン
私はバックアップツールなどは使っていないので、Déjà Dup にしろ sbackup にしろ、その挙動があまり良く分かっていないのですが・・・。
それはさておき、ホームディレクトリをすべてバックアップする必要など無いのでは無いでしょうか?
ホームディレクトリでバックアップが必要なのは、実際にデータ等を保存しているディレクトリと、.bashrc とかの設定ファイルだけではないでしょうか。
具体的には、ダウンロード、テンプレート、ドキュメント、ビデオ、ピクチャ、ミュージック、公開といったディレクトリに保存しているデータがあればそれらと、自分で作成したディレクトリがあればそれも。
あと .mozilla と .thunderbird の各ディレクトリや、VirtualBox を使って入れば .VirtualBox とか。
デスクトップをバリバリにカスタマイズしていれば他にも色々必要なものがあるのでしょうが、基本的には無くなっては困るデータや設定ファイル、メールデータやブラウザのブックマークデータとかが残って入れば、ほぼ元通りの状態に復元出来るはずですよ。
そもそも、どういう経緯でのバックアップ & 復元なのか良く分かりませんが、より安全性を高めるには、デジカメの写真など重要なデータは、別に CD-R などにも焼いておくとか、dropbox などのオンラインストレージにも保存しておくとか、冗長化するしか手は無いだろうと思います。
オフライン
あー、funatogawa さん、私のもまったくのオフトピでした & 内容的にもややかぶり気味で済みません。
オフライン
トピ主ですが、Déjà Dupもそうですが、なぜバックアップ・ツールは圧縮しようとするんでしょうかね…
いえ、容量かせごうというのは分かりますが、事故ったとき、こわれた圧縮ファイルではどうにもなりません。
こまったもんです。
数GBのかけがえのない写真が失われたのも残念ですが、メアドが自分のもの以外、
さっぱり分からない。どうしたものかと悩んでいます。
私はこれからはもう rsync しか信用しません。
オフライン
なんと! 少し前のデータで復元に成功しました。
Déjà Dup の日々の圧縮ファイルをサイズ順に並べてみますと、ほぼ2週間おきくらいに
フルバックアップを取り、その間はどうもサイズからみて増分バックアップを取っているように
思えます。
(サイズが2週間おきに10倍くらいの日がある、ということです)
そして、その増分バックアップのどこか1ヶ所に問題があると、その間すべてが復元不能なのは
言うまでもありません。
が、それなら、そのフルバックアップの日のデータを復元できないかとやってみたところ、
成功しました。
10日間分ほどのデータは失われましたが、全部失われたと思っていたので、
本当に嬉しいです。
教訓として、バックアップ・ツールだけに頼らず、rsync かなにか併用しようと思いました。
では。
オフライン
SMARTは参考程度にしか役に立ちませんし、HDDの外で起る障害によるデータ破損にも関係がありません。
バックアップは実際に復元できるかどうかまでテストしたうえで運用すべきものです。
定番(プリミティブな)のバックアップツールとしては、afio, rsync, dump/restore などがお勧めです。
オフライン
HDDからHDDにバックアップをとっているのでしょうか。
同じHDDだとなにか起きたときにバックアップデータもろともお亡くなりになるのでバックアップ先は別のメディアにしておいた方が安全かと思います。
SMARTについてはyamaさんがご指摘のとおり、参考程度の情報なのであまり当てにはできないかと思います。
なにかハード的な異常が起きている可能性もあるので
1. /var/log以下のログファイルをあたってI/O ErrorとかInput/Output Errorのようなエラーがでていないか確認(他にもHDD関連と思われるものを探してみてください)。
2. システム起動時にシフトキー連打でGrubのメニューを表示させ、memtest86を実施。
して、異常が無いか確認していただいた方がよいかも知れません。
オフライン
トピ主です。
バックアップは、メインのHDDから内蔵の別HDDに取っています。
今回は、10.04でphp のwebアプリケーションの xoops というのがあるのですが、
それを使おうとして、本番環境はさくらインターネットにレンタルサーバーを借りたのですが、
さくらの方はいいのですが、自宅ubuntu10.04の手元のテスト環境では、
なんとデフォのphpのバージョンが5.3と新しすぎて xoops がエラーを吐くため(5.2までの対応)、
対応しているphpのバージョンを強引に5.2にダウングレードしたところが、
システムのsynaptic などが動かなくなってしまい、
システム総入れ替えを余儀なくされたというものです。
バージョン新しすぎるのも考えものですね。
まあ、今回の件はDéjà Dupが悪いのかは分かりません。
たしかにみなさんおしゃるように、HDD問題がある可能性は否定できません。
ところで、実は、その後あれこれ試したところ、
なんとDéjà Dupの障害前日のデータからデータが復旧できてしまったのです。
前回うまくいかなかったときとなにが違うのか、分かりません。
今回は、バックアップ専用HDDを自動マウントの設定(etc_fstab の値の書き換え)やらパーミッションの
設定やらもやり直し、またDéjà Dup のアップデータもあったようなので、適用しました。
データは前日分まで復旧でき、大変喜んでいます。
みなさん、お騒がせしました。
結局、なにが原因だったのかよく分かりません。
HDDのマウント設定をもう一度最初からやり直してみたのがよかったような気もします。
外付けusb-HDDの方が信頼度は高いし扱いやすいだろうとは思うのですが、
usb2.0では数GBバックアップ取るのは時間的に相当にシンドイです。
usb3.0ならいいんでしょうねぇ…
オフライン
同じHDDでは無く、物理的に別れたHDDならバックアップ先のメディアとして問題無いかと思います。
ただ、同じデータを読み出そうとしてCRCが一致したり、しなかったりする場合があるというのであればやはり何らかのハードウェア異常が疑われます。HDD自体に異常があるのかも知れませんし、メモリや電源装置の安定性に問題があったり、M/B含めてどこかのパーツのコンデンサが壊れて安定しない状態になっているのかも知れません。
個人データが失われてしまうとなにかと困ることもあるだろうと思いますので、早めに確認、検証しておかれると良いのでは無いかと思います。
オフライン
hmatsueさん、いつ親切なご回答ありがとうございます。
私が思いますに、バックアップ・メディアに内蔵の別HDDを使うのは、自分でやっておいて言うのもなんですが、
いささか危険のようです。
というのも、今回のように思わぬことでos(ubuntu10.04)が不調になって
再インストールしようとするときに、間違ってそのバックアップ専用HDDにインストールしてしまえば、
データすべてが失われてしまうという点。
また、再インストールに成功したあとも、そのバックアップ専用HDDを認識させるのに、
/etc/fstab の値の書き換えやパーミッションの変更が必要とされる、という点です。
バックアップ・ソフトはそれぞれ必要とされるパーミッションが違うように思います。
少なくとも sbackup と Déjà Dup は違います。
sbackup は root 以外のユーザーにアクセス権与えないでも出来たかと思うのですが、
Déjà Dup は アクセス権777 である必要がありませんか?
今回は、復元の際にパーミッションの与え方が適切でなかったせいかも、と考えているところです。
外付け usb-HDD をバックアップ専用に割り当てておけばいずれも回避できる話で、
なるべくなら、そのようにしたいものだと思います。
いまHDD みたらデータの容量はだいたい26GBありました。
usb3.0 がほしい、と痛切に思います(^^;
オフライン
ytakagi による投稿:
sbackup は root 以外のユーザーにアクセス権与えないでも出来たかと思うのですが、
Déjà Dup は アクセス権777 である必要がありませんか?
バックアップ対象ファイル/ディレクトリによるのではないでしょうか。
バックアップソフト実行ユーザのホームだけなら、そのユーザの権限で読み出せますが、/homeまるごととかなら、通常の設定状態では一般ユーザでは読み出せないファイルやディレクトリがあるはずです。
あとはバックアップ先のパーミッションにもよるかと思います。
# 個人的にはシステムのバックアップは管理者の仕事だと思っているので、sudo tar zcpfとかでやっちゃいます。
オフライン