In my last blog, I posted some rsync test results from the BackupBouncer Mac metadata test suite, running against both a Mac-based ZFS file system and a ZFS-based Solaris server. Today, I'm going to discuss both my testing methodology and some pretty big problems I've ran into with rsync on Solaris. First off, I've compiled rsync 3.0.3 (pre2) with the fileflags and crtimes patches on both my Mac and Solaris. On Solaris, the crtimes patch wouldn't compile, so it was left out. With the same version of rsync running on both systems, I began my tests.
According to Mike Bombich (Mac backup expert and developer of CarbonCopyCloner) it is necessary to use a few specific flags to successfully backup Mac metadata: -X for extended attributes; -A for ACLs; -H for hard-links; and --fileflags for Mac file flags. Additionally, Bombich threw in a few additional flags in his recommended script: -N (unknown); --protect-args; --force-change; -a (archive mode); and -x ("don't cross filesystem boundaries". I'm not sure the utility of some of these commands, but I will include them because Bombich suggests it. The surprising result: numourous flags seem incompatable with the Solaris-compiled rsync.
The results (and rsync error message) are below:
-X won’t work (xtended attributes are not supported on this server)-H will work
-A won’t work (recv_acl_access: value out of range: 8000)
-x will work
--fileflags won’t work (on remote machine: --fileflags: unknown option)
--protect-args works
--force-change won’t work (on remote machine: --force-change: unknown option)
-N (??) won’t work (on remote machine: -svnlHogDtNprxze.iL: unknown option)
What does this mean? Well, it seems the flags necessary to make rsync backup Mac data properly (specifically -X, --fileflags, & -A) are not supported on Solaris. Thus, when running rsync without these flags, rsync doesn't backup Mac metadata and BackupBouncer reports its very poor score. This leaves the utility of a Solaris-based NAS for a Mac backup server is serious question.
I then ran a rsync --version on both the Mac and Solaris versions of rsync 3.0.3 (pre2). Here are the capabilities reported, which seem to echo the above results.
Mac: rsync version 3.0.3pre2 protocol version 30
Capabilities:
64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, file-flags
Solaris: rsync version 3.0.3pre2 protocol version 30
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
append, ACLs, no xattrs, iconv, no symtimes, no file-flags
Unfortunately, the necessary flags are seemingly just not supported in Solaris rsync. However, this doesn't explain the results I received when running Mac rsync to a SMB share of the Solaris server (never calling the incompatible Solaris rsync). These numbers are almost as poor as running through the Solaris rsync. Me
I will note, however, that the -A (ACL) flag may actually be supported by rsync, but reports a "out of range" error message. I'm going to research what might be going on here, as the Mac ACL numbers may be incompatible with Solaris (thus a Solaris issue and not an rsync issue).
Finally, I'd like to comment on the ZFS filesystem in general. It seems ZFS, at least on the Mac, has relatively good support for Mac metadata. I really have to applaud both the Sun ZFS and Apple ZFS teams here. According to BackupBouncer, old historical Mac-only data, such as resource-forks and Finder locks are some of the few things that fail the Mac-based ZFS test; and these things arn't typically used anymore on OS X. Furthermore, Mac ZFS fails the "devices," "xattrs + rsrc forks" and "lots of metadata" tests.
Posts
