[日誌]dropboxで同期がされなかったファイル

異なるパソコン間でのファイルの同期ができるサービスの一つ、dropboxを利用しているが,Macでいつまでも同期が完了しない原因を特定した。犯人は古いKeynoteのファイルだった。

現象としては、dropboxがindexファイルを作成していて、それがいつまでたっても終わらないというものであった。そのうち終わるだろうとたかをくくっていたが、1ヶ月以上たってもおわらない。

幸い、dropboxで同期が終わっていないファイルや、そのファイルを含むフォルダには、その旨を示すバッチがつく。それを目印に探ってみると、いずれも古いKeynoteでつくったファイルだった。しかも、それらはいずれもKeynoteで開けることすらできず、ファイルが壊れている旨表示される。また、あいにくTimeMachineのバックアップファイルも今年の6月からという比較的新しいファイルからしか残してなかったため,以前と比べてファイル容量が小さくなったなど,ファイルが壊れているかどうかの目安の情報も手に入らなかった。

試しに同期できないファイルについて、パッケージの内容を表示してみた。そうしたところ、いくつかの構成ファイルで、所有者がrootになっており、使っていたユーザーアカウントでは開けない状態になっていることが判明した。

そこで、sudo chown -R kuono * とおまじないをかけ、所有者を変更。これで新しいkeynoteでもそれらのファイルを開けられることを確認し、しばらく放っておいたところ、dropboxでも同期が完了した。めでたし、めでたし。ちなみに、-R とは、再帰的に子フォルダの中のファイルもchownを適用するためのオプションである。

以上、自分の覚え書きとして。

[IT]イメージのスキャンその後

昨年末,Time Machine 用ディスクのバックアップをとる話を掲載したが,その時によくわからないままやっていたイメージのスキャンの謎が判明した。

イメージのスキャンの実体は,コマンドの asr ,Apple Software Restore の イメージスキャンという機能とのこと。man コマンドで説明を見てみたら,こんなことが書いてあった(多少意訳あり):

与えられた(ディスク)イメージ上にあるデータのチェックサムを計算し,そのディスクイメージに計算結果を追記する。この計算結果は,復元が正しく行われたか否かの検証に使われるとともに,マルチキャスティングの場合にディスクイメージが順番通りに並んでいるかどうか,あるいはファイルが順番通りに再書き込みされたか否かの検証にも使われる。イメージの並び直しが必要である場合,スキャンされるディスクイメージと同容量の空きスペースが必要である。

なるほど,スキャンをするというと単にデータを読み取っているだけという意味に解釈していたんですが,書き込みの準備作業をしていたんですね。

でもだとしたら,復元の手順が複雑にならないよう,復元の指示一発でスキャンと復元をしてくれたらいいとも思うのですけど…。

[日記]FirewireドライブのTime Machineデータを移す

idiskを実験的に使い始めて急にデータ量が増えたため、少し余裕のあったタイムマシンバックアップデータ用のディスクが逼迫し、データの引越しをすることにした。現状はFirewireにつながった2パーティションにわけられたIDEディスクに格納されている。

そもそもタイムマシン用のデータが引越しできるなどという情報はアップルの公式サイトやヘルプでは簡単に見つけ出すことができず、「バックアップを別のディスクに引き継げる?」なるMacPeopleの記事データを最近ようやく見つけたところである。

まずはじめにTimeMachineの機能をオフにする。コントロールパネルでスイッチをオフにすればOKだ。自動的にFinderで表示されるディスクの色も青色系からオレンジ系に変化した。

次に,ディスクユーティリティでバックアップディスクをイメージファイルに変換する。我が家の環境の場合,いきなりイメージファイルを作ることは出来ず,ディスクユーティリティーでバックアップディスクとして使っていたドライブをアンマウントしてやらないと,すぐにイメージファイルづくりがエラーでストップした。アンマウントしてからイメージファイルを作成した所,300GBのディスクのイメージづくりにほぼ一晩を費やしていた。これは,イメージファイルの格納場所をネットワーク越しのNASにしたことも影響していると思う。うちは,いまだギガビットイーサにはなっていない。

その次はイメージファイルから,新しくバックアップの保管先にするディスクへのデータの復元だ。これもふたつほど工夫が必要だった。一つは,復元するイメージのスキャンが必要だということ。このスキャンが何をして,何の意味があるのかは未調査である[1. 調べたところ,ファイルの整合性の確認をするためのデータをイメージファイルに書き込んでいるようだ。2009年2月8日追記]が,ともかくこのスキャンをおこなうことにした。これも,ほぼ半日かけて実行された。

もうひとつは,復元の際にターゲットになるディスクの初期化オプションを選んでおくことだった。初期化直後のディスクなら問題ないのかもしれないが,今回は前述のスキャンをしていない段階で復元を試みたので,その時の失敗データが残っていた。ディスクユーティリティの出力するメッセージを見ていると,データの復元はブロック単位で行っているとのことなので,初期化直後のまっさらな状態が必要なのだろう。

復元そのものは数時間で終了したが,検証というステップが自動的に始まった。これは2時間弱で終了予定。

続きはまた後刻に。

結局、11時間かかってディスクの復元は完了した。バックアップ用に容量の半分だけ使っていたディスクのパーティションをひとつにし、今後は今までの倍の量をあてる。300GBあれば、あと数ヶ月くらいはもつだろう。次回の設備増強には多分、テラバイトのSATAディスクをRAIDで運用することになるのだろう。