Well, in OS 10.14.6 the answer is NO, but not due to a flaw in rsync. Somebody bumped the USB cable when it was one-third done (estimating twelve hours to go).
I tried "rsync version 3.1.3 protocol version 31" installed/updated today by
When that failed, I installed another with Macports. It gives the identical version info but is in a different path. It too failed, same message.
Both of these claim to support ACLs with -A and extended attributes with -X
MBP-WWG:~ Admin$ sudo time /opt/local/bin/rsync -aAX /Volumes/Nahshon/Backups.backupdb/ "/Volumes/Seagate Backup/Backups.backupdb"
rsync: opendir "/Volumes/Nahshon/Backups.backupdb/." failed: Operation not permitted (1)
rsync: get_xattr_data: lgetxattr("/Volumes/Seagate Backup/Backups.backupdb/.","com.apple.finder.copy.checkpoint#N",0) failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1209) [sender=3.1.3]
Looking at the first error, I tried
ls on the source backup. Not permitted, even with sudo. And
sudo chmod -RN fails to remove the ACLs. So, it must be SIP protected.
Update: as seen in comments, this error does not happen to everyone. I do not know why. I do know that before SIP, I occasionally had to relax permission restrictions on a backup set to get around a Time Machine bug. But Time Machine always tightened them back up on the next backup. Now, SIP won’t let me do that, but apparently at least one person does not have those restrictions.