開発用マシンのMacはTime Machineでバックアップしています。
ですが時々エラーが起こり、再度のフル・バックアップからやり直してくれと言ってきます。
これまでは諦めて支持通りに新規のフル・バックアップを行っていました。
（プロジェクト関連はTime Machineとは別に個別のバックアップは取っています）
しかしこのところ頻繁に起こるようになりましたので、何とか修復は出来ないかと試してみました。
フル・バックアップが始まるとMacにもかなりの負荷がかかり開発等も効率が悪くなりますので。
結論から言うとFix Time Machine Sparsebundle NAS Based Backup Errorsの記述通りに行うと修復出来たようです。
記述は全て英語なので、簡単に訳してみます。
- ターミナルを開き以下コマンドでrootになって下さい。
sudo su -
- Verificationが既に実行されてsparsebundleがbadにマークされていますので、まずそれをnormalにする必要があります。
コマンドラインから以下のコマンドを実行して下さい。
chflags -R nouchg /Volumes/{name of your network share}/{name of}.sparsebundle
このコマンドは少し時間が掛かります。 - 次に以下のコマンドを実行して下さい。
hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your network share/{name of}.sparsebundle
以下のような実行結果が表示されます。
/dev/diskx Apple_partition_scheme
/dev/diskxs1 Apple_partition_map
/dev/diskxs2 Apple_HFSX
x は外部ディスクのディスクIDです。
Apple_HFSX または Apple_HFS と出力されたものが対象のディスクです。 - この時点でファイルシステム・チェックのプロセス(fsck)が既に起動されています。
下記のコマンドでfsckの実行状況を追跡する事が出来ます。
tail -f /var/log/fsck_hfs.log
fsckが起動されていれば sparsebundleを修復するはずです。このコマンドは数時間かかります． - fsckが終了すると以下のどちらかが表示されます。
‘The Volume was repaired successfully’
‘The Volume could not be repaired’
- もし後者の場合にはもう一度ディスク修復のために以下のコマンドをもう一度実行します。
fsck_hfs -drfy /dev/diskxs2
fsck_hfs -drfy -c 750 /dev/diskxs2
上記の例では750MBのRAMを使用します。システム構成により変更して下さい。もしよく分からない場合には最初の例を使用してください。x は環境により置き換えて下さい。 - １〜２時間かかります。
もう一度下記のコマンドを実行して下さい。
tail -f /var/log/fsck_hfs.log
修復が成功していれば下記のように表示されます。
‘The Volume xxxxx was repaired successfully’
- 以下のコマンドを実行して下さい。
hdiutil detach /dev/diskxs2
- 上記の処理を何度か実行して下さい。
- 上記処理が完了したら、バックアップの状態を記録している sparsebundle 内の plist ファイルを編集する必要があります。sparsebundle の直下にある com.apple.TimeMachine.MachineID.plist を編集します。
- 以下の２行を削除します
<key>RecoveryBackupDeclinedDate</key>
<date>{whatever-the-date}</date>
（私の環境では上記の行はありませんでした） - 以下の行を変更します。
変更前
<key>VerificationState</key>
<integer>2</integer>
変更後
<key>VerificationState</key>
<integer>0</integer>
上記の作業で無事、Time Machineを復旧する事が出来ました。
所要時間は約３時間。
過去のバックアップも見る事が出来ます。
Leave a Reply