rsync 버전 3.1.3-6 프로토콜 버전 31 cifs-utils/stable 2:6.8-2 amb64 nfs-common/stable 1:1.3.4-2.5 Debian Linux 10 Buster FreeNAS 11.3-U3.2(IxSystems FreeNAS Mini)
저는 일부 원격 시설을 백업하기 위해 작은 가상 Debian Linux 서버를 사용합니다. 저는 Debian 서버를 사용하고 있습니다. FreeNAS(FreeBSD)를 사용하여 많은 소란 없이 cifs 공유를 일관되게 마운트할 수 없기 때문에 저는 Linux에 좀 더 익숙하고 FreeNAS의 후드 아래에서 장난치는 것을 좋아하지 않습니다. 피할 수 있다면 - Debain이 cif를 일관되고 안정적으로 마운트하도록 하고 NFS를 사용하여 FreeNAS 서버를 마운트할 수 있다면 - 몇 달 동안 잘 작동했습니다. 그래서 저의 작은 Debian 백업 서버는 FreeNAS 서버와 클라이언트 컴퓨터 사이의 다리 역할을 합니다.
Debian - 부팅 시 FreeNAS에 마운트 및 NFS 공유 - 영구적으로 문제가 발생하지 않습니다. Debian - 6시간마다 작은 배치 스크립트를 실행하여 대상 클라이언트 Windows PC를 마운트한 다음 마운트된 cifs 공유의 데이터를 마운트된 nfs 공유로 rsync합니다.
이게 문제일지도 모른다고 생각했는데 이걸 찾았어요우편 엽서이용자가 지적한 곳
rsync에 관한 한 두 개의 로컬 파일 트리 간에 복사하므로 대부분의 최적화(유명한 델타 알고리즘 포함)가 비활성화됩니다.
그래서 제 질문은 두 개의 로컬 파일 시스템으로 간주되더라도 최적화를 강제하는 방법이 있습니까?입니다. 그 기사에서 그들은 삭제를 시도했지만 나는 그렇지 않았습니다. 내 것은 단지 모든 사용자 비축물을 백업했을 뿐입니다.
답변1
이 플래그를 사용하여 최적화를 강제할 수 있지만 --no-whole-file전송 프로세스 속도를 늦추는 것 외에는 아무것도 수행하는 것이 거의 불가능합니다.
이 옵션을 고려하기 전에 파일 수정 시간이 보존되도록 --archive( -a) 또는 --times( ) 플래그를 사용하십시오 . -t파일 크기와 결합하면 rsync"빠른 확인"이 파일을 다시 복사하는 대신 건너뛰기에 충분한지 확인하는 데 도움이 됩니다.
--no-whole-file이것이 나쁜 생각인 이유는 다음과 같습니다 .
델타 알고리즘은 파일의 블록을 검사하여 어떤 블록을 전송해야 하는지 확인합니다. 작은 변화의 경우 블록 하나만 변경하면 되므로 매우 매력적일 수 있습니다. 그러나 어떤 블록이 변경되었는지 확인하려면 원본 파일과 대상 파일을 모두 읽어야 합니다. 두 개의 서로 다른 시스템이 있는 경우 두 개의 독립적인 프로세서/디스크 조합을 사용하여 이 작업을 병렬로 수행할 수 있으며 어쨌든 소스 파일을 읽어야 하므로 유일한 적중은 대상 시스템의 대상 파일을 읽는 것입니다. 그러나 두 개의 로컬 파일 시스템이 있는 경우에도 두 개의 파일을 읽어야 하지만 프로세서와 디스크 경합이 발생합니다.
최악의 경우 변경된 블록을 쓰려면 두 개의 파일을 처음부터 끝까지 읽어야 한다는 뜻이다. 그러나 이 시점에서는 어쨌든 대상 파일의 일부 또는 전체를 다시 작성해야 하므로 하나를 읽고 다른 하나에 쓸 수 있습니다.