서로 다른 소스와 대상 파일 시스템 간 ACL 백업의 rsync 의미

서로 다른 소스와 대상 파일 시스템 간 ACL 백업의 rsync 의미

rsyncd(rsync의 데몬 버전)을 사용하여 macOS에서 Synology 서버로 파일을 백업하는 데 문제가 있습니다. 다음은 실패한 명령입니다.

% rsync -rlcAXtgoDiv --fake-super ~/scripts rsync://seamus@SynologyNAS-1/backups/scripts-backup/ > ~/scripts/log.txt 2>&1

오류는 다음과 같습니다. (내가 작성한 로그 파일과 명령줄에 있음):

rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(848) [sender=3.2.7]

-A몇 가지 실험을 거친 후 문제의 원인을 이 옵션을 사용하는 것으로 좁혔습니다 .

--acls, -A               preserve ACLs (implies --perms)
--xattrs, -X             preserve extended attributes
--fake-super             store/recover privileged attrs using xattrs

내가 이해한 바에 따르면 이 --fake-super옵션을 사용하면 rsyncACL을 필요 없이 확장된 속성으로 저장할 수 있습니다 sudo. 하지만 man rsync.

추가 조사에 따르면 Synology 서버에서 이 줄이 다음에 포함되어 있는 것으로 나타났습니다 /etc/rsyncd.conf.

refuse options = acls

/etc/rsyncd.conf그래서 그 줄을 편집 하고 댓글을 달았습니다 refuse options = acls. rsync이전 명령을 다시 실행하면 성공적으로 실행됩니다. :)

하지만 잠깐만요. 질문이 있어요.

  • rsyncSynologyNAS-1에 보고된 버전은 다음과 같습니다.
rsync  version 3.1.2  protocol version 31
  • 버전 차이(Synology의 경우 3.1.2, macOS의 경우 3.2.7)를 제외하면 Synology의 파일 시스템은 btrfsAPFS만큼 불투명해 보입니다!

내 질문은 내가 원하는 올바른(MacOS 호환) ACL을 실제로 백업하고 있는 걸까요? 아니면 그냥 감시인을 침묵하게 하는 걸까요? 이에 대한 어떤 생각이라도 환영합니다.

FWIW: 실제로는 제대로 백업을 하고 있는 것 같아요왜냐하면백업을 수행하면 rsyncd이러한 오류가 표시되지 않습니다. rsyncd불필요한 암호화 단계(모두 내 LAN에 있음)를 피하기 위해 전환하고 백업을 단순화하고 싶습니다.

관련 정보