Rsync를 사용하여 대량의 데이터를 단방향으로 이동하고 동기화하세요.

Rsync를 사용하여 대량의 데이터를 단방향으로 이동하고 동기화하세요.

편집: 두 가지 심층 답변을 바탕으로 다음을 시도했습니다.

rsync --progress -v -az -e “ssh” /archive/images/dcam/ [email protected]:/data/archive/images/dcam --dry-run

그래서 --progress를 사용하면 결과를 볼 수 있습니다. -v를 사용하면 장황하게 만들 수 있나요? -az는 이를 보관하고(따라서 타임스탬프를 얻음) z는 이를 압축하여 네트워크 트래픽을 절약합니다. -e 10.xxxxx 시스템의 인증 키에 소스 SSH 키가 있는 SSH를 통해 로그인합니다. 아아, 이런 오류가 발생했습니다.

rsync: Failed to exec \#342\#200\#234ssh\#342\#200\#235: No such file or directory (2)
rsync error: error in IPC code (code 14) at pipe.c(84) [sender=3.0.6]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in IPC code (code 14) at io.c(600) [sender=3.0.6]

원격 시스템에 이미 데이터가 포함된 /data/archive/images/dcam이 있기 때문에 이는 이상합니다.

rsync가 어떻게 작동하는지 완전히 이해해서는 안됩니다. 저는 두 개의 서버를 가지고 있습니다. 한 서버에는 다른 서버로 전송하고 싶은 많은 데이터가 있습니다. 그래서... NFS는 서버 B(백업이 있는 곳)에서 서버 A로 폴더를 마운트했습니다.

그리고 이것은 중요한 라이브 서버이기 때문에 2TB의 데이터에서 RSYNC를 실행하는 것에 대해 긴장했습니다... 다음과 같이 수동으로 실행했습니다: (/archive/images 폴더 내에서) rsync -r imageDateXX/ /mnt/backup/ archive /images/imageDateXX를 입력하고 2TB 폴더 및 데이터에 대해 이를 반복합니다. 드디어 작동하게 됐어요. 그래서 서버를 다운시키지 않은 것이 다행이고 이 데이터는 밤새도록 업데이트되었습니다. 따라서 서버 B를 최신 상태로 유지하기 위해 cronjob을 설정했습니다.

0 8 * * * rsync -r /archive/images/ /mnt/backup/archive/images

이 작업은 시작되었지만(제 생각에는) 완료하는 데 여전히 2일이 걸릴 것입니다. 단순히 서버 A의 새로운/변경된 내용을 보고 서버 B에 넣는 것이 아니라 모든 파일을 다시 서버 B에 덮어쓰는 것 같습니다. 이 이론을 테스트하는 방법을 모르겠지만 시간이 오래 걸릴 것입니다. rsync에 스위치가 없거나 폴더별로 rsync 폴더를 실행하여 상위 폴더에서 rsync를 실행하면 rsync와 "다르게" 보일 것입니다. 왜냐하면 rsync는 그것이 모두 새로운 데이터라고 생각하고 모든 것을 복사하기 때문입니다. 서버 b와 동일한 위치?

이 이론을 테스트하거나 결정하는 방법을 잘 모르겠습니다. 간단하다고 생각하세요. rsync는 파일이 serverB에 없거나 serverA에서 변경된 경우 자동으로 파일을 덮어쓰거나 파일을 복사합니다.

답변1

rsync --progress -av -e "ssh" /archive/images/ username@[serverIP-or-domainname]:/archive/images --dry-run

견본:

rsync --progress -av -e "ssh" /archive/images/ [email protected]:/archive/images --dry-run

이는 두 시스템의 디렉토리가 /archive/images이고 키가 설정되어 있고 원격 시스템이 sshd를 실행 중이라고 가정합니다. 저는 그럴 것이라고 확신합니다.

--dry-run불쾌한 실수를 피하는 데 도움이 되도록 작업이 수행할 작업을 확인하는 것은 항상 유용합니다.

-v작업 위치를 추적하는 데 유용한 출력 세부 정보를 추가합니다.

--delete소스에 더 이상 존재하지 않는 파일을 대상에서 제거합니다. 이는 원격 시스템에 데이터 미러를 생성하려는 경우에 종종 필요합니다. 데이터가 많이 다를 경우 , 및 를 살펴보고 --delete-before어느 --delete-after것이 --delete-during요구 사항에 가장 적합한지 확인하는 것이 좋습니다. 일반적 으로 --delete이는 꽤 잘 작동하지만 TiB 데이터의 경우 이것이 중요할 수 있습니다. --delete-before예를 들어, 거의 꽉 찬 원격 디스크를 처리하는 경우 유용합니다.

삭제할 때 주의하세요! ! 로컬 경로에 없는 모든 항목을 원격 경로에 삭제합니다. 즉, 잘못된 경로를 제공하면 해당 원격 디렉터리에 있는 모든 항목을 삭제하거나 삭제하려고 시도한다는 의미입니다. 적어도 실수하지 않도록 --delete처음부터 사용하지 마세요 !--dry-run

-rtvz-a. 대부분의 애플리케이션에는 이 정도면 충분하다고 생각합니다.

-a-aHAX기본적으로 소스의 거의 실제 미러(대부분 완전한 미러)를 생성합니다 . -a/(아니요, ,)와 같습니다 --archive.-rlptgoD-H-A-X

--progress작업이 실행되는 동안 진행 상황을 표시하므로 유용합니다.

-e "ssh"ssh를 실행할 때 더 많은 ssh 옵션이나 명령에 다른 옵션(예: 특정 ssh 포트)을 사용해야 하는 경우 명령이 더 길어질 수 있습니다. 견본:-e "ssh -p 423"

-z: CPU 사용량을 줄이고 싶고 대역폭이 많이 변하지 않는 경우(이미지와 같은 바이너리 파일을 가정) -z압축 옵션을 제거하세요.

--bwlimit: 머신 간 네트워크 대역폭을 너무 많이 차지할까 봐 걱정되는 경우 유용합니다. 최소 속도 크기는 1k, 1KiB/s, 1m, 일명 1MiB/s 등이 될 수 있습니다. 이는 네트워크 전송의 대역폭을 모두 사용하고 싶지 않은 경우에 유용합니다. 사람이 말했듯이 --max-size다양한 단위의 구문을 참조하십시오.

단위 문자열의 첫 글자는 B(바이트[해당 없음 --bwlimit]), K(킬로), M(메가), G(기가), T(테라) 또는 P(페타)일 수 있습니다. 문자열이 단일 문자이거나 "ib"가 추가된 경우(예: "G" 또는 "GiB") 단위는 1024의 배수입니다. "B"로 끝나는 두 글자 접미사(예: "kb")를 사용하면 1000의 배수인 단위를 얻게 됩니다. 문자열의 문자는 사용하려는 대문자와 소문자의 조합이 될 수 있습니다.

--partial: 전송이 중단될 수 있다고 생각되는 경우 유용합니다. 이렇게 하면 중단 시 rsync가 기본적으로 전송의 일부를 삭제하는 것을 방지할 수 있습니다.

첫 번째 전체 동기화 후에는 변경된 파일만 업데이트되므로 이후의 모든 동기화 속도가 훨씬 빨라집니다. 로직이 제대로 작동하면 --delete향후 동기화에서 항상 이를 사용하여 로컬 및 원격 파일을 동기화 상태로 유지하고 삭제되거나 이름이 바뀐 파일을 제거하는 등의 작업을 수행할 수 있습니다. 일부 구성에서는 파일에서 변경된 데이터만 업데이트됩니다. 예를 들어 파일에 변경 가능한 메타데이터가 있지만 바이너리 코어 데이터는 변경되지 않고 메타데이터 부분만 변경되는 경우입니다. 이미지에는 그다지 좋지 않지만 다른 데이터 유형에는 적합하며 동기화를 100배 더 빠르게 만들 수 있습니다.

rsync 및 nfs

특히 ext4를 사용하는 경우 nfs를 통한 rsync는 모든 파일 시스템 속성을 지원하지 않기 때문에 실패합니다(-a의 경우처럼 전송하려는 경우). 또한 매우 느립니다. nfs는 확장된 파일 속성 문제가 없는 로컬 네트워크를 통한 소규모 전송에 적합하지만 프로덕션에서는 사용하지 않습니다. 나는 nfs를 통해 백업을 수행하기 위해 rsync를 사용하곤 했는데 너무 많은 속성을 전송할 수 없기 때문에 ext4가 등장했을 때 중지해야 했습니다.

매뉴얼 페이지 재동기화

이러한 시스템으로 작업할 때 rysnc 매뉴얼 페이지를 읽는 것보다 더 유용한 것은 없습니다. 예를 들어 --partial저는 오늘까지 이것이 문제라는 것을 깨닫지 못했고 매우 큰 파일 전송 중단으로 인해 어려움을 겪고 다시 시작해야 했습니다. 다음 시작 시 중단되었습니다.

비록 제 생각에는 rysnc가 지금까지 만들어진 최고의 cli 소프트웨어 중 하나이지만 맨 페이지가 끔찍하고 재구성이 절실히 필요하기 때문에 여기에 없는 항목을 찾기가 너무 어렵습니다. , 나는 오늘 그것을 읽기 전까지 그 중 일부를 알고 있었습니다. 예를 들어, --partial대용량 파일 전송 중단으로 인해 재시작 실패로 인해 셀 수 없이 많은 시간이 소요되었다는 사실을 알지 못했습니다.

Andrew Tridgell에게 피자를 보내세요, 하하, 사람들이 rsync를 위해 돈을 지불하고 싶어할 때 그가 요청하는 것입니다. 하지만 더 나은 방법은 매뉴얼 페이지를 수정하여 더 유용하게 만들고 논리적인 부분으로 나누는 것입니다. 읽고 사용하세요. 그러나 훌륭한 문서이지만 재구성이 잘 되어 있지는 않습니다.

답변2

솔루션에는 두 가지 주요 문제가 있으므로 각 복사본을 완료하는 데 오랜 시간이 걸립니다.

  • 파일을 복사할 시간이 없으므로 rsync복사된 파일을 식별하고 건너뛸 수 없습니다. 따라서 모든 호출은 모든 것을 복사합니다
  • rsync로컬 파일 시스템의 한 부분을 다른 부분으로 복사하고 있습니다 . 이 경우 증분 복사본을 얻을 수는 없지만 파일을 변경하면 전체 파일이 전체적으로 복사됩니다.

수리하다

  • 대부분의 메타데이터를 한 번에 얻으려면 --times( )을 포함 -t하거나 --archive( )을 고려하십시오. -aNFS를 계속 사용해야 하는 경우에도 이 작업을 수행하십시오.
  • NFS를 사용하지 말고 sshNFS 서버로의 전송을 사용하십시오( remoteHost내 예에서는).
  • --compress( -z)를 사용하여 네트워크의 트래픽을 압축합니다.

rsync -az /archive/images/ remoteHost:/mnt/backup/archive/images

대화형으로 실행하는 경우 일반적 으로 --partial --progress --verbose( ) 도 포함합니다.-Pv

귀하의 경우 이 수정된 명령을 처음 실행하면 완료하는 데 여전히 오랜 시간이 걸린다는 것을 알게 될 것입니다. 이는 어떤 파일이 최신인지 빠르게 식별할 수 있는 방법이 없고 파일 시간과 크기를 통해 식별하기 때문입니다 rsync. 따라서 각 파일 쌍(소스 및 대상)을 비교하여 메타데이터만 다른지 확인해야 합니다. 이후에는 rsync크기나 시간이 다른 파일만 복사 대상으로 간주되므로 변경되지 않은 파일은 건너뛰게 됩니다.

관련 정보