バックアップ（クローン作製）

なるほど。 "復元時に不可視フォルダが可視フォルダとなってしまう。" #69, 2005/07/20 4:12pm
に書かれていた件ですね。
このときは tmp がおかしかったからかも？と書かれていましたが、確実にこれが起こってしまう手順はあるのでしょうか。ちょっと恐いですね。私も頻繁に asr は使いますが、幸いこのような現象に出会ったことがありません。
> OSX 1.42ではasrで問題なく-eraseを付けなくてもcopy出来ます。ただしOSXが問題を起こしていない時の話です。dot, .Spotlight-V100, etc, mach, tmp, varのpermissionは問題ありません
OS 10.4.2 でも、このあたりの Group ID はおかしくなります。
source　は
drwxrwxr-t 0:80 .
drw------- 0:80 .Spotlight-V100
lrwxr-xr-x 0:80 etc, mach, tmp, var
ですが、target は
drwxr-xr-x 501:501 .
drw------- 0:501 .Spotlight-V100
lrwxr-xr-x 0:501 etc, mach, tmp, var
となってしまいます。

> ですが、target は
> drwxr-xr-x 501:501 .
> drw------- 0:501 .Spotlight-V100
> lrwxr-xr-x 0:501 etc, mach, tmp, var
> となってしまいます。
壊れています。:-)
1.042のasrは正常ならdotは1775、root adminになるはずです。:-)
現在のOSXを全て消去してInstallし直さないと直りません。
外付けのHDDを繋いでいると感染してしまいます。
何とか修復出来れば良いのですが...
こちらの10.42 asrは-eraseを付けなくても...
drwxrwxr-t root admin dot
drw------- root admin .Spotlight-V100
lrwxr-xr-x root admin etc -> private/etc
lrwxr-xr-x root admin mach -> /mach.sym
lrwxr-xr-x root admin tmp -> private/tmp
lrwxr-xr-x root admin var -> private/var
...こうなりますが... :-)

> 壊れています。:-)
んー、そうですか。
1台のマシンだけじゃなく、新規にインストールした他のマシンでも出るので、仕様 (もしくはバグ) だと思っていたんですが。でも、実際にぴっぴさんは出ないなら、なにか原因があるのでしょうね。また新規インストールしてみるかなぁ。

> 実際にぴっぴさんは出ないなら、なにか原因があるのでしょうね。また新規インストールしてみるかなぁ。
外付HDDは外して内蔵HDDのOSXを全て消去してTigerを入れないと巧くいきません。大変ですが暇の時にでもおやりになったほうが... :-)

> 外付HDDは外して内蔵HDDのOSXを全て消去してTigerを入れないと巧くいきません
内蔵 HDD を初期化して、パーティションも切り直し、完全に一から Tiger をインストールしてやってみましたが、erase オプションをつけない asr では、501 の Group ID になってしまいます。何度か試しましたが変わりませんでした。target のボリュームの「このボリューム上の所有権を無視する」のチェックの有無に関わらず同じ結果でした。(なお、asr 終了後は、source の「このボリューム上の所有権を無視する」属性がコピーされているように思いました)
私の感触としては、これが現状での Tiger の振る舞いのような気がしています。本来 erase を伴わない asr はアプリケーションのインストールなどの単純なファイルのコピーに使用されるもので、システムのクローン時には erase をするのが普通ですから、このような結果になってしまってもしかたないように感じました。

ご面倒ですがお教え下さい．
お試しになったのは，10.4 素の状態ですか? 10.4.2にアップしてからですか? それともどちらでも同じですか?

> お試しになったのは，10.4 素の状態ですか? 10.4.2にアップしてからですか?
10.4.2 にアップしてからです。他の方はならないんでしょうか。
なお、erase を付ければ何も問題ありません。

clone (dng)を作ってrestoreを試してみましたか?
(例　/dev/disk0s9のclone (dmg)を作り、dmgから/dev/disk0s9にrestoreする)
残念ながらそれだとOSX 10.40, 10.41のasrと何ら変わりません。sudo asr -source A -target A 1 -eraseで作ったclone (dmg)をsudo asr -source A 1 -target A -eraseを行うとrestoreは出来ても起動するとkernel panicになり修復は不可能です。/System/Library/StartupItemsなど10カ所位がcopyされないのです。
sudo asr -source A 1 -target Aを行ってdot, .Spotlight-V100, etc, mach, tmpを修復しないと使い物になりません。またetc, mach, tmp, varのsymbolic linkは新しく作り直さないと駄目です。etc, mach, tmp, varは不可視になります。
OSX 10,40, 10,41でCarbon Copy Clonerが使えなかった原因はこれです。OSX 10.42で-eraseを付けなくてもpermissionに問題なくcloneが作れるようになったからです。
-eraseをつけて行うのがBestですが、この場合のようにOSXが混乱している場合はやむを得ませんので-eraseを付けないで修復するしかないと思います。
/dev/disk0s9以外にrestoreするのは問題はないと思いますが、混乱してしまってるので何か起こっても不思議はないように思います。:-)
なおignore ownership on this volumeは無関係です。

私が指摘したかったのは、10.4.2 になっても、asr で erase オプションをつけなかった場合は、Group ID がおかしくなってしまう、という点です（ボリューム to ボリュームの場合）。この点に関しては、他の方はどうでしょう？誰でも同じ結果になるのではと思いますが・・・。
上記は、ボリューム to ボリュームで確認していましたので、イメージ to ボリュームでどうなるか、また時間のあるときに確認してみようと思います。
なお、10.4.2 になるまで CCC が使えなかったのは、10.4 と 10.4.1 において AppleScript で管理者権限で asr を走らせるとハングしてしまっていた問題も一因です。root ユーザだとそのまま走るので、CCC をそれで使っていたユーザもいたようです。
#追記
ditto でボリュームを別のボリュームにコピーした場合も、Group ID 501 は出ました。また、10.4.1 以前の asr で起こっていた不可視ファイルが見える現象も起こります。

> sudo asr -source A 1 -target Aを行ってdot, .Spotlight-V100, etc, mach, tmpを修復しないと使い物になりません。またetc, mach, tmp, varのsymbolic linkは新しく作り直さないと駄目です。etc, mach, tmp, varは不可視になります。
一部訂正です。
etc, mach, tmp, varは可視になります。

イメージ to ボリュームでも、ボリューム to ボリュームと同様の結果でした。erase を付けない場合は、一部のファイルの Group ID が 501 になります。ただ、これらは、後述しますが、結局のところ、既存のファイル・ディレクトリの持つ値に依存しているようです。
検証をしてみたところ、以下のことがわかりました。
.Spotlight-V100 が 0:501 になってしまうのは、asr を始める前にすでに .Spotlight-V100 がボリューム上に存在するためと思われます。asr を開始する前に削除しておけばなりません。
. (current directory) が 501:501 になるのも、asr 前の所有権がそのようになっているからです。asr 前にターゲットのボリュームの所有権を 0:80 に変更しておけば、asr 後も 0:80 です。
etc, mach, tmp, var が 0:501 になるのも、上記でターゲットのボリュームの所有権を事前に調整しておけば、 0:80 となりました。
要するに、管理者権限で asr を動かしていても、erase オプションをつけない場合は、既存のものを継承する部分があるということです。これに限って言えば、ウイルスのように感染するといったものではないと言えるでしょう。
ディスクユーティリティで消去したボリュームはそのユーザの所有権になるので、こういった現象が起こっていました。asr をかける前にターゲットの所有権を調整しておけば erase オプションなしでも Group ID がおかしくなる件については避けられますね。しかし、erase オプションなしでは、不可視であるべきものが見えてしまうという問題はありますので(10.4.2 以降でも)、erase は付けるべきでしょう。
なお、asr だけでなく、ディスクユーティリティでも見ましたが、同様の結果になりました。(検証数は asr の方が多いですが)
いろいろ書きましたが、ごく簡単に「無難な」システム全体のバックアップおよび復元のしかたをまとめてみます。
□バックアップ
1. なるべく起動ボリュームをバックアップしない
2. ソースの「このボリューム上の所有権を無視する」のチェックを外す
3. ソースのシステムが Tiger の場合、作業には 10.4.2 以降を使う
4. バックアップ先は消去する、もしくはイメージとして保存する(イメージは作成後になるべくスキャンしておく)
□復元
1. ソースのシステムが Tiger の場合、作業には 10.4.2 以降を使う
2. 復元先は消去する
3. 起動ボリュームをソースにしない
内蔵ハードディスクのパーティションを切っていなくて、起動可能な外付けのディスクが1つだけある場合、外付けに OS 10.4.2 以降を入れておいて、外付けから起動、バックアップはイメージとして外付けに保存、というのが一番簡単ではないでしょうか。
Tiger のインストールディスクのバージョンが、10.4.2 以降であるならば、インストールディスクから起動してもよいと思います。(最新の iBook, Mac mini 付属のディスクは 10.4.2 では？) そうでない場合は、不可視ファイルが可視になってしまいます。

> 検証をしてみたところ、以下のことがわかりました。
一番肝心なのはdotなんです。bitが立っているか、立っていないかで丸で違います。:-)
drwxrwxr-t root admin, drwxr-xr-x 501 501 dot

erase 付けないと、sticky ビットは立ちませんね (元々立っていなかった場合)。
書いた通り、erase しない限り、その前の属性を引き継いでいます。

さっき、Activity Monitorを見ていて気がついたのですがsuorceとtargetをunmountしてcopyしている時、kernel_taskが一番上でせっせと動いていました。#28-32%
こちらはasrの中で一番難しい/Volumes/Aのdmgを元の/Volumes/Aに戻すことが-eraseを付けてできるのです。キチンとsourceとtargetをunmountしてcopyします。終わるとsourceとtargetをmountします。所有権の変更なんて行っていません。また、sourceとtargetのignore ownership on this volumeも弄っていません。sudo asr -source A 1 -target A -eraseでCloneができます。:-)
同じことを-eraseを付けなくてもbitがたってキチンとコピーされますがetc, mach, tmp, varは可視になります。sudo asr -source A 1 -target Aでcopyが出来ます。
試しに今のOSXで/Volumes/Aのdmgを作って、そのdmgから/Volumes/Aにリストアして見て下さい。そしてそのVolumesを起動するとどうなるか。今の状態では凄まじい結果になります。/Volumes/AはどのVolumeでも構いませんので同じVolumeにリストアするのです。所有権の変更、ignore ownership on this volume, dot, .Spotlight-V100, etc, mach, tmp, varは弄らないで下さい。

ヨコから失礼します。私も以前はCCCやPsyncXを使用していたのですがTigerへの以降と同時にDejaVuを使うことにしました。もともとその日に制作・編集したファイルのバックアップを毎日とる為に以前から使用していたのですが、同じソフトでシステムのバックアップもとれればそれはそれでシンプルかなと思いまして。。PsyncXより遅いようですが一応ミラーリングもありますし、日本語訳もまともです。オススメですよ！
（ホントはPsyncXが対応してくれるのが一番だけど。。早かったよな〜）