web-dev-qa-db-ja.com

ddrescueを使用して、Mac OS Xのブートボリュームを別のより大きなボリュームに直接複製できますか?

ddrescueまたはddを使用して、Mac OS Xブートボリューム(具体的には「MacOS Extended、Journaled」、別名JHFS +ボリューム)を別のより大きなボリュームに直接クローンし、ターゲットボリュームを作成できますか?完全に機能する起動可能なボリュームになりますか?

以前は、ddrescueを使用して死にかけているハードドライブのMacOS Xブートボリュームの生の.dmgバックアップを作成し、ディスクユーティリティを介してその.dmgを別のボリュームに「復元」しましたが、この場合、中間の.dmgファイルを保存するための予備のハードドライブスペースがないため、ddrescueを呼び出して、死にかけているボリュームを新しいボリュームに直接クローンする必要があります。しかし、復元部分にディスクユーティリティを使用するのではなく、ddrescueを使用してこれを直接行うと、設定が正しく行われず、結果のボリュームが起動できなくなるのではないかと心配しています。

故障したハードドライブを再び処理しているので、ddrescueを使用する必要があります。 SMARTユーティリティによると、500GBドライブのうち保留中の不良セクタは1つしかないため、その不良セクタに重要なデータがない可能性はかなり高いと思います。心配しているのは、1つのボリュームからわずかに大きいボリュームへのブロックごとの生のクローンが、ターゲットボリュームを何らかの形で正しくセットアップしたままにしない可能性があるかどうかです。

誰かが以前にMacOS Xでこれを行ったことがあり、それが機能することを保証できますか?

更新:自分の回答を投稿する必要がありました(「いいえ」または「試した方法ではありません」)が、他の誰かが正常に指示を提供できる場合は、別の回答を受け入れて喜んでいますこれを行う。

4
Spiff

したがって、答えは「いいえ」か、少なくとも「私が試した方法ではない」のいずれかであるように見えます。結果のボリュームは一度マウントされましたが、ディスクユーティリティの「ディスクの修復」は、ファイルシステム構造にディスクユーティリティが修復できないエラー(おそらくbツリーのサイズが正しくない?)があると述べました。 DiskWarriorまたは他のツールで修正できるかどうかを確認する機能がありませんでした。故障したソースドライブにはこれらの問題はなかったので、おそらくそれを台無しにしたのは私のddrescueベースのコピー手順に関するものでした。

私の友人は、ddを使用してMac上のドライブ全体(パーティションテーブルとすべてを含む)のクローンを作成することに成功したため、個々のJHFS +ボリュームだけでなく、この方法でデバイス全体のクローンを作成できる可能性があると述べました。

失敗の原因となった可能性のあるもう1つの点は、ターゲットパーティションをソースパーティションとまったく同じ数のセクター/ブロックにするのに時間がかからなかったことです(もちろん、ターゲットの方が大きかった)。

2
Spiff