バックアップ
OS X LionのSpotlightとTime Machineの不適切な関係
2011/09/25 13:21 Mac OS X
Lionにアップデート後、Time Machineのバックアップ・ディスクがアンマウントされないのはSpotlightが原因。気長にSpotlightがバックアップのインデックス作業を終えるのを待てば、いつかはアンマウントされるとレポートした。１度インデックス作業が終われば、Spotlightが忙しくなることもないはず。
ところがその後も、頻度は下がったものの、Time Machine バックアップが同じ原因でアンマウントが遅れる事態が起こったのだ。システムのログを見ると、mdworkerが過去のバックアップのインデックス作業に勤しんでいる様子… 過去１年分のバックアップをさかのぼって一生懸命インデックスの再構築をしているようなのである。そのあおりを食らって、たとえ数十MBでもTime Machineのバックアップ時間が20分以上かかることがざら。もう勘弁してくれ。
最後の手段として、過去の遺産であるTime Machine バックアップ（約340GB）を別のHDDに退避した上で、Spotlight再構築（sudo mdutil -E /）をし、Time Machine バックアップも１から作り直すことにした。バックアップ先のTime CapsuleとはギガビットEthernetでつながっているとはいえ、100GBの新規バックアップともなると15時間かかってしまった。
新規バックアップの結果は劇的である。
Time Machine バックアップでのSpotlightインデックス作業は止まった。いや、実際には動いているのかも知れないが少なくともユーザ感知外のレベルにはなった。バックアップ作業も３分くらいで終了するし、バックアップディスクは即座にアンマウントされる。Snow Leopard時と変わらないレベルに落ち着いた。
今回得られたバッドノウハウは、「Time Machine バックアップ上では旧OSとの混在は避けた方がよろしい」。
ところがその後も、頻度は下がったものの、Time Machine バックアップが同じ原因でアンマウントが遅れる事態が起こったのだ。システムのログを見ると、mdworkerが過去のバックアップのインデックス作業に勤しんでいる様子… 過去１年分のバックアップをさかのぼって一生懸命インデックスの再構築をしているようなのである。そのあおりを食らって、たとえ数十MBでもTime Machineのバックアップ時間が20分以上かかることがざら。もう勘弁してくれ。
最後の手段として、過去の遺産であるTime Machine バックアップ（約340GB）を別のHDDに退避した上で、Spotlight再構築（sudo mdutil -E /）をし、Time Machine バックアップも１から作り直すことにした。バックアップ先のTime CapsuleとはギガビットEthernetでつながっているとはいえ、100GBの新規バックアップともなると15時間かかってしまった。
新規バックアップの結果は劇的である。
Time Machine バックアップでのSpotlightインデックス作業は止まった。いや、実際には動いているのかも知れないが少なくともユーザ感知外のレベルにはなった。バックアップ作業も３分くらいで終了するし、バックアップディスクは即座にアンマウントされる。Snow Leopard時と変わらないレベルに落ち着いた。
今回得られたバッドノウハウは、「Time Machine バックアップ上では旧OSとの混在は避けた方がよろしい」。
BackupBuddy for MacOS X Beta
本日３本目の記事。BackupBuddyを提供しているBlue Nomad Softwareからメールがあった。なんとMacOS X版 BackupBuddy 2 Betaをリリースしたのですと！ >> 続きを読む...
iPhoneのバックアップ時間が長い原因を発見！
2009/06/20 06:24 iPhone
iPhone OS 3.0にアップデートして、楽しみと苦しみの両方を味わっている最中。
だが、一番の問題はiTunesへのバックアップに時間かかりすぎること！ ３時間半かかって半分も終わらない。いい加減頭に来て、本気で原因調査を開始した。そしてその諸悪の根源は「AppSniperのアイコン・キャッシュ」だった！
iPhoneのバックアップ・ファイルは、Macの場合、”~/Library/Application Support/MobileSync/Backup”のフォルダに、符号化されたフォルダ名で保存される。当然、最新のタイムスタンプのフォルダが最新のバックアップだ。
iPhoneのバックアップ中にこのフォルダの中身を見ていると、どんどんファイルが増えていくので、一向に前進しないiTunesのプログレスバーにじりじりしなくてもよくなる。うーん、ファイルは確かに増えていっているけど…なに!? ３時間半で12,139個のファイル？ そりゃいくらなんでも多すぎだろ!?
バックアップ・データは、xxxx.mdinfoとxxxx.mddataという２つのファイルで一組になったSQLightのデータベース、平たく言えばSpotlightのデータである。バックアップされたばかりのxxxx.mdinfoファイルをエディタで無理矢理開くと、”icon, AppSniper, IMG”の文字が見える。ふうん、AppSniperのデータをバックアップ中か。じゃあ、２時間前にバックアップしたファイルは…やはり”AppSniper”だ！ こいつか！ AppSniperだけで１万個以上のデータ、それはキャッシュ以外に考えられない。
後はもう簡単。即、バックアップを中断し、iPhoneでAppSniperを開き、Configの画面を探すと、下から2番目の目立たないところに「Clear Icon Cache」があった。これを押すとポップアップ・メッセージが現れ、「iTunesと同期する前にキャッシュをクリアしておくと、バックアップ時間をかなり短くできるよ」だと。orz
OKすると、えらく時間がかかり（１万個以上だからそりゃそうだろう）、バックアップを再開したところ、見違えるようにバックアップがどんどん進み、わずか７分で終了。バックアップ・ファイルは1,800個程度。iPhone 3.0にアップデートして最初のフルバックアップなので、こんなもんだろう。２度目のバックアップ（同期）は１分以内で終了。いや、もう、脱力。
だが、一番の問題はiTunesへのバックアップに時間かかりすぎること！ ３時間半かかって半分も終わらない。いい加減頭に来て、本気で原因調査を開始した。そしてその諸悪の根源は「AppSniperのアイコン・キャッシュ」だった！
iPhoneのバックアップ中にこのフォルダの中身を見ていると、どんどんファイルが増えていくので、一向に前進しないiTunesのプログレスバーにじりじりしなくてもよくなる。うーん、ファイルは確かに増えていっているけど…なに!? ３時間半で12,139個のファイル？ そりゃいくらなんでも多すぎだろ!?
後はもう簡単。即、バックアップを中断し、iPhoneでAppSniperを開き、Configの画面を探すと、下から2番目の目立たないところに「Clear Icon Cache」があった。これを押すとポップアップ・メッセージが現れ、「iTunesと同期する前にキャッシュをクリアしておくと、バックアップ時間をかなり短くできるよ」だと。orz
OKすると、えらく時間がかかり（１万個以上だからそりゃそうだろう）、バックアップを再開したところ、見違えるようにバックアップがどんどん進み、わずか７分で終了。バックアップ・ファイルは1,800個程度。iPhone 3.0にアップデートして最初のフルバックアップなので、こんなもんだろう。２度目のバックアップ（同期）は１分以内で終了。いや、もう、脱力。
rsyncによるバックアップ
2011/07/19 22:33 Mac OS X
Mac OS XでのローカルディスクのバックアップはTime Machineで完璧だが、FireWireやUSB接続の外付けHDDを丸ごとバックアップするときはTime Machineのような履歴は必要ない場合がある。
数あるバックアップツールの中でも、Backuplist+はフリーウェアだし、rsyncのフロントエンドなので信頼性が高いことからも重宝しており、Snow Leopardでも全然問題なく動いてきた。
ところが、ベータリリースである8.0.2へ移行したところ、パーミッションエラーを吐くようになったので、これを機にいろいろと調べてみた。するとバックアップ先がNASだったり、Time CapsuleのようにファイルシステムがHFS+の場合は、ちょっとしたコツが必要なようだ。
Backuplist+ 8.0.2にはrsync 3.0.8がバインディングされているが、rsync 3ではMac OS Xを正式にサポートするようになった。そこで、Time Capsuleにバックアップする場合は、サポートのページに記載があるように、次のオプションを"Expert options"で指定すると良いことになっている。
ところが、8.0.2ではこれだけではrsyncがchownエラーをコンソールに吐き続けることになる。-aオプションは-rlptgoDと同等であるが、どうもowner, groupオプションが悪さ(?)をしている模様。そこで、以下のようにオプション指定すると、エラー無しで動くようになった。
ちなみに、--inplaceは大きなファイルを置換しながらバックアップするオプション。通常rsyncはいったんテンポラリファイルにコピーした後にファイルを書き戻す処理をするが、巨大なファイルのバックアップの場合はこのオプションで高速化が可能になる。このほか、--protect-decmpfsはHFS+圧縮に対応したオプション、-AはWindowsとの互換性を取るためのACLを有効にするオプション、-XはUTF-8文字コードに関するオプション…ということらしい。
…という訳でrsyncをMac OS X上できちんと理解して動かすには、なかなか敷居が高いことが分かった次第。バックアップと一言で言っても、実はいろいろと大変で、ユーザに何も考えさせずに動くTime Machineがいかに良くできているか、改めて認識した。
数あるバックアップツールの中でも、Backuplist+はフリーウェアだし、rsyncのフロントエンドなので信頼性が高いことからも重宝しており、Snow Leopardでも全然問題なく動いてきた。
ところが、ベータリリースである8.0.2へ移行したところ、パーミッションエラーを吐くようになったので、これを機にいろいろと調べてみた。するとバックアップ先がNASだったり、Time CapsuleのようにファイルシステムがHFS+の場合は、ちょっとしたコツが必要なようだ。
Backuplist+ 8.0.2にはrsync 3.0.8がバインディングされているが、rsync 3ではMac OS Xを正式にサポートするようになった。そこで、Time Capsuleにバックアップする場合は、サポートのページに記載があるように、次のオプションを"Expert options"で指定すると良いことになっている。
-aHAXNx --fileflags --force-change --protect-decmpfs --inplace --stats -vところが、8.0.2ではこれだけではrsyncがchownエラーをコンソールに吐き続けることになる。-aオプションは-rlptgoDと同等であるが、どうもowner, groupオプションが悪さ(?)をしている模様。そこで、以下のようにオプション指定すると、エラー無しで動くようになった。
-rltpDHAXNx --fileflags --force-change --protect-decmpfs --inplace --stats -vちなみに、--inplaceは大きなファイルを置換しながらバックアップするオプション。通常rsyncはいったんテンポラリファイルにコピーした後にファイルを書き戻す処理をするが、巨大なファイルのバックアップの場合はこのオプションで高速化が可能になる。このほか、--protect-decmpfsはHFS+圧縮に対応したオプション、-AはWindowsとの互換性を取るためのACLを有効にするオプション、-XはUTF-8文字コードに関するオプション…ということらしい。
…という訳でrsyncをMac OS X上できちんと理解して動かすには、なかなか敷居が高いことが分かった次第。バックアップと一言で言っても、実はいろいろと大変で、ユーザに何も考えさせずに動くTime Machineがいかに良くできているか、改めて認識した。
