preserving Mac OS X metadata in rsync backups and restores
rdutoit at capecod.net
Mon Jan 21 11:58:03 GMT 2008
I ran the bouncer tests too and came up with same results except the
"fifo" and "devices" failed. I ran it from command line as well as
from "do shell script" command with same results. I used the same
patches. Nevertheless, I am thrilled with the results here for OSX and
can't thank you all enough for putting rsync 3 together. I did some
incremental speed tests with my 16GB Home folder from my old powerbook
from do shell script; destinations all to external firewire drive on
initial backup 54 minutes
no-change-incremental backups 7 - 14 minutes
initial backup 52 minutes
no-change-incremental backups 5 - 7 minutes
the patches don't make a huge difference for the initial backups but
no-change-incrementals do seem to go on twice as long. Not sure why
really- The output showed nothing unusual. Things would go faster
from the command line since I am running rsync 3 through my wrapper
application with the "do shell script" command. . I changed one letter
on some deeply nested files and they all showed up fine in the
By the way, after the initial 16+ GB copy, the incrementals took up an
incredible .05 +- Gb of space. The apple supplieed rsync on Tiger and
Leo both recopy a lot of data each time so the incrementals never
Thanks Again, Rob D
On Jan 20, 2008, at 4:17 PM, Mike Bombich wrote:
> With rsync 3 pre8 and Mac OS 10.5.1:
> bash-3.2# patch -p1 <patches/osx-create-time.diff
> bash-3.2# patch -p1 <patches/flags.diff
> bash-3.2# ./prepare-source
> bash-3.2# patch -p1 <patches/backup-dir-dels.diff
> bash-3.2# ./configure
> bash-3.2# make
> bash-3.2# ~/rsync-3.0.0pre8/rsync -aHAX --fileflags /Volumes/
> Source/ /Volumes/Target/
> bash-3.2# bbouncer verify -d /Volumes/Source /Volumes/Target
> Verifying: basic-permissions ... ok
> Verifying: timestamps ...
> Sub-test: modification time ... ok
> Verifying: symlinks ... ok
> Verifying: symlink-ownership ... ok
> Verifying: symlink-permissions ... ok
> Verifying: hardlinks ... ok
> Verifying: resource-forks ... ok
> Verifying: finder-flags ... ok
> Verifying: finder-locks ... ok
> Verifying: creation-date ... ok
> Verifying: bsd-flags ... ok
> Verifying: extended-attrs ...
> Sub-test: on files ... ok
> Sub-test: on directories ... ok
> Sub-test: on symlinks ... ok
> Verifying: access-control-lists ...
> Sub-test: on files ... ok
> Sub-test: on dirs ... ok
> Verifying: fifo ... ok
> Verifying: devices ... ok
> Verifying: combo-tests ...
> Sub-test: xattrs + rsrc forks ... ok
> Sub-test: lots of metadata ... ok
> As far as performance is concerned, I'm surprised how fast rsync
> 3pre8 is for no-change-incrementals. Incremental recursion alone
> doesn't really explain it, I'm still trying to see if something is
> fishy or if it really can be this good.
> On Jan 18, 2008, at 10:38 PM, Moritz Heckscher wrote:
>> Am 2008-01-19 um 05:31 schrieb Matt McCutchen:
>>> On Sat, 2008-01-19 at 05:12 +0100, Moritz Heckscher wrote:
>>>> Using the following options for rsync:
>>>> --archive --hard-links --acls --xattrs --executability --numeric-
>>>> I get the following output from backup-bouncer: [...]
>>>> Verifying: bsd-flags ... FAIL
>>> BSD flags are handled by flags.diff in rsync-
>>> patches-3.0.0pre8.tar.gz .
>>>> Verifying: finder-locks ... FAIL
>>> A request for enhancement was recently entered for finder locks:
>>> But Wayne says he thinks they are handled by flags.diff too.
>>>> Verifying: creation-date ... FAIL
>>> Creation dates are handled by osx-create-time.diff .
>> Thanks for mentioning those diffs. I'll try tomorrow and report here.
>>>> Verifying: fifo ... FAIL
>>>> Verifying: devices ... FAIL
>>> These are supposed to work with --archive, at least if rsync runs as
>>> root. In any event, you probably don't care about these if you're
>>> backing up user data.
>> Yes, I was expecting this to work. I did run as root (using sudo)
>> and also tried --device and --specials, but these are already
>> included in --archive. Hm, I'll run it again tomorrow, maybe I've
>> messed up somehow (it's 05:30 in the morning...).
>>>> Adding --fake-super to the options of rsync doesn't help:
>>> Naturally, because that option makes rsync wrap the source
>>> metadata in
>>> an rsync-specific extended attribute that it sets on the destination
>>> file, whereas the checker tool is expecting the real destination
>>> metadata to be set.
>> Yes, that absolutely makes sense. I shouldn't have included the
>> output here. Obviously one would need a second "recover" step using
>> rsync before checking with the tool.
>> Thanks for your fast help, I'm learning a lot!
>> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
More information about the rsync