In theory, I don’t believe it should matter if the backup filesystem (/tmp/bb in this case) doesn’t have all the same capabilities as the target / destination filesystem, as rdiff-backup has its own store for metadata. Just to make sure, I just tried following your suggestion of backing up to a volume created by bbouncer, but got the same results.

I’m not sure what version of rdiff-backup got the extended OS X goodies, so it may be that the stable version available through macports is just too old; will find out once I’ve got the bandwidth to pull down the new version & retest.

Thanks a bunch for BB! Very handy!

$ sudo rdiff-backup /Volumes/Src /tmp/bb
$ sudo rdiff-backup — force -r 1D /tmp/bb /Volumes/rdifftest/

Perhaps you’re trying to simulate a backup/restore cycle? If so, you should probably use another bbouncer create-vol volume for the intermediate step instead of /tmp, just to be confident in the results. This is especially true on Tiger, since ACLs weren’t even enabled on the root filesystem by default IIRC.

If, after doing that, you still get failures with “critical” features like resource forks and finder flags you should talk to the rdiff backup people, since they seem to think it should work: http://www.nongnu.org/rdiff-backup/FAQ.html#OSX