HDD交換、GUIDパーティションテーブル、FileVault、TimeMachine もろもろ

photo credit: JrGMontero via photopin cc

photo credit: JrGMontero via photopin cc


悲劇は、HDD交換から始まった。
HDD交換はなんだかんだとありながら、それから起きたことに較べればえらく順調だったと言える。
せっかくHDD交換して、すっきりもしたし、マシンの挙動もきびきびしたことだからと、欲張ってMac Box Setを購入し、さぁSnow Leopardのインストールに望んだのだが、いきなりGUIDパーティションテーブルでないのでインストールできません、というわけのわからんメッセージ。

●HDDがGUIDパーティションテーブルではない
色々調べてわかったことは、HDD交換の際に、パーティションテーブルのことを何も考えずにディスクユーティリティでフォーマットしたのだが、その状態だと、なんとAppleパーティションテーブルというSnow Leopardがインストールできないパーティションテーブルになっちゃうということだったのだ。なんだよそれ。フォーマットしますか?って訊かれたからフォーマットしただけなのに、なぜ、その状態では不完全なのだ?
(ということで、MacでHDD交換するときは、パーティションテーブルには気をつけましょう。必ずGUIDパーティションテーブルかどうかを確認するようにしたほうが無難。)
パーティションテーブル変更には、一度HDDを初期化しなければならない。HDD容量が増えということもあり、外部HDDに分散させたものを内部に持ってきたりなんだかんだと時間のかかるファイル移動作業などを散々やったのに、また同じようなことをしなければならないとうわけだ。また時間がかかる…

●FileVaultが切れない
その作業がてら、以前から気になってたFileVaultについてもついでになんとかしたいと考えた。FileVaultをボクはよくわからず、なんとなくこれを「入」にしておいたほうがセキュリティ上良いのではないかと、「入」にしていたのだけれど、どうもこいつがTimeMachineとの相性がよくないらしい。そんなことも知らずにずっとTimeMachineを使ってたのかと笑われそうだが、FileVaultを使ってると、結局、ホームディレクトリは、まるごと暗号かしたイメージファイルでバックアップをとらなければいけないので、TimeMachineの利点の差分バックアップができず、毎回バックアップに時間がかかる。また、暗号化されてるイメージファイルを毎回ログイン時にマウントするので、ログインログオフ処理が重くなる。Macに詳しい色々な人のブログを読んでも8~9割ぐらいの人が、FileVaultには懐疑的で、利用しないほうが良いというようなことを言ってるではないか。さらに、何もわかってないことの究極として、FileVault設定をしていると、ログイン中のホームアカウントのデータはTimeMachineにバックアップされないということ。これを知らなかったことが、のちのち悲劇を招く。

とにかく調べれば調べるほどFileVaultの評判は芳しくない。ということで、「切」にしようと試みたわけだけど、この試みも挫折する。ホームディレクトリのデータ量が多すぎたのか、「切」にするまでにかかる所要時間が10時間、11時間、12時間とどんどん伸びていくのだ。そして、HDDからは今まで聞いたことのない盛りのついた猫の叫び声のような音がどんどん大きく鳴り響き、このまま続けてたらHDDが爆発でもしてしまうんじゃないだろうかという恐怖心もあおられ、「切」にするのは一旦諦めることにした。うーむ。

◆参考
Apple サポートコミュニティ: FileVaultを切れない

●TimeMachineのバックアップが終わらない
FileVaultを「切」ることができなかったけれど、いずれにせよHDDのパーティションマップを変えなければいけないことには変わりない。なんか楽な方法がないものかと調べて、TimeMachineでバックアップとって、そこから復元する方法をとるのが一番楽なんじゃないかと思い、TimeMachineを手動起動したのだけれど、これがまたすごい時間かかった。準備中のままずっと動かない。これも色々調べて、Spotlightのインデキシングを切ったり、なんだかんだとしつつ、結局、以前に何度か途中でTimeMachineを止めてしまったのが悪かったようで、ひたすら待つしかないだろうという結論で、約2日。ほぼ1日「準備中」状態、2日目からバックアップ開始でなんとかかんとか終了までこぎ着けた。

◆参考
Time Machineのバックアップが遅いとき (kimada’s weblog)

time machineでのバックアップがものすごく遅くなっています。 – Macintosh – 教えて!goo


●FileVaultとTime Machine併用の悲劇
最新のバックアップ状態ができたので、Leopardの起動ディスクから起動(Cを押しながら起動)して、メニューから「Time
Machineからの復元」を選んで、復元元、復元先を指定して復元を開始。これは2時間ぐらいで終了し、なかなか順調じゃないかと思っていたら、今度は、自分のアカウントにログインできないではないか。
そう。例の、FileVaultが「入」状態だと、そのアカウントでログインしてると、TimeMachineではそのアカウントのホームディレクトリはバックアップされないという仕様だ。つまり、最新のデータをバックアップから戻したのはよかったものの、そのバックアップには、ボクのホームディレクトリはなくなってしまっいる状態だったのだ。ログインしようとすると、「今はFileVaultユーザーアカウント”アカウント名”にログインできません。エラーが起きたため、アカウントへのログインに失敗しました」というエラーメッセージ。

◆参考
Apple サポートコミュニティ: TimeMachine FileVault 復元後ログインできなくなりました

いやはや、どうしたものか。ひとまずたまたまもう1つ何かあったときのために管理者権限を持ってるアカウントを1つ作ってたので、まずそちらでログインしてみた。「ユーザー」ディレクトリには、なぜか、「ユーザー名1」(「ユーザー名」は、もともとのボクのディフォルトのユーザーアカウント)というフォルダーがある。権限がないのでアクセスできない状態なので無理矢理権限を変えて中身を見るが、中は空っぽだった。
TimeMachineの最新バックアップをのぞいて見るも、ログイン状態でバックアップをとっていたわけで、当然空っぽ。TimeMachineは手動で気が向いた時にバックアップを動かしていたけれど、その時はほとんどが、自身のアカウントでログインしている時だ。なので、過去のバックアップデータを探すも、どれもホームディレクトリには何も残っていない。なんてこった。結局、さかのぼっていって、12月初旬のバックアップデータにかろうじて、「ユーザー名.sparsebundle」というイメージファイルが残ってた。おそらくだが、TimeMachineを起動して、すぐに妻のアカウントに切り替えたのだろう。12月のデータならまだなんとかなるだろう。しかし… ファイルの変更日は2007年12月15日というのが気になるが。

●FileVaultで暗号化されたホームディレクトリのイメージファイルがマウントできなかったので…
まず、この12月のバックアップのイメージデータを、てきとうな場所にコピーする。なんとなくマウントできないかなーと思い、ダブルクリックしてみるけれど、「Socket操作の権限がない」云々というメッセージがでて、マウントできない。ディレクトリのパーミッションの問題なんだろうかと思いつつ、色々試してみるもよくわからない。しょうがないので、ユーザーディレクトリにあった「ユーザー名1」のディレクトリを、「ユーザー名」に変更し(そのままでは変更できないので、まず「ユーザー」ディレクトリに、ログイン中ユーザーが読み書きできる権限を与えてから)、そのディレクトリにこの「ユーザー名.sparsebundle」ファイルを入れる。で、そのユーザー名でログイン。すると、うまくログインすることができた。とはゆえ、バックアップされてたのが昨年12月のデータということで、やっぱり古い。ただ、ファイル自体の最終更新日が2007年なので、少し気になっていたけど、中身が壊滅的なことはない。
そもそも写真や音楽類のデータは、ボクはもともと外付けHDDに全部突っ込んでるので、他のアプリケーションなどのデータなどはたいしたものはなかったのだ。
再度、その状態から、以前失敗したFileVaultの切り作業を実施してみたが、なぜかはよくわからないが、今回は約1時間ぐらいで「切」にすることができた。もう二度とFileVaultは使わないと心に決めた。

●設定回復
なんとかかんとかホームディレクトリは数ヶ月前の状態に戻せたものの、やはり各種アプリケーション類の設定はかなり古い状態なので、それの再設定を行わなければならない。
ログイン項目やらアドレス帳やらのデータはMobileMe から復帰させられる。プライベートのメールは全部Gmail上にあるので特に問題もない。って考えると、実は、けっこう古いバックアップファイルからでも元の状態に戻すのはそれほど大変なことでもなさそうだ。

◆Chrome
Chromeはらくちんだ。
Chromeは、アカウントで同期をとっててるので、ほぼそれだけで最新の状態に復元できた。ただ、Greasemonkeyスクリプトはバックアップされないので、これは手動で再設定しなければいけない。といっても僕が利用してるのは、Amazonのアフィリエイトリンク作成用のこれ「Amazonの商品を最速でブログにコピペできるGreasemonkey「Amazon Quick Affiliate (JP)」 [C!]」を入れてるだけ。インストールして、Amazonに行って再設定を行う。

◆Evernote
Evernoteは、ローカルデータが全部消えていたので、再度ダウンロードしての同期。これはかなり時間がかかる。でも、基本的にデータは全部クラウド側にあるので、これも特に問題ない。

◆iTunes/iPhone
iTunesは音楽ファイル類はホームディレクトリではなく、共有ディレクトリで妻のアカウントと共用しているので、特に問題はなかったけれど、iPhoneやiPadアプリはなんだかわからんが、接続したら全部のアプリデータがiPhone側に移行されてしまい、もともとのフォルダーやらカテゴリ分けやらがむちゃくちゃになってしまった。各アプリの設定情報も消えてしまい、しこしこ再度設定をしなおした。かなり面倒臭い。

◆etco
etcoも古いデータばかりになってしまったので、最新のデータをブログからダウンロードしてくる。最近は書きかけのものはevernoteに保存するようにしてたので、草稿データ喪失の被害は最小限に留めることができた。

◆1Password
1Passwordのデータはすっからかんだったので、iPhoneと同期をはかって復帰させた。iPhoneでも同期しておいてよかった。この手のデータがいろんな端末やバックアップに分散してるのはどうなんだろう思うけれど、いざという時は助かる。今回、データがなくなった場合に、一番ダメージが大きかったのはおそらくこのソフトのデータだ。

なんとかかんとか、ほぼ元通りのところまで戻せた。
いったんこの状態で、今度はFileVault切状態で初めてのフルバックアップを取得して、それからようやくSnow Leopardのインストールに入れる状態になる。今日はここまで。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>