rsync가 계속 연결을 끊습니다. 파이프 파손

rsync홈 디렉토리를 백업 하는 데 사용 하고 있습니다. 이것은 오랫동안 오랫동안 잘 작동했습니다. 내가 사용하는 명령은 다음과 같습니다.

rsync \
    -pavz \
    --delete \
    --exclude 'mnt/' \
    --exclude '.cache/' \
    --exclude 'Videos/' \
    --exclude 'Music/' \
    --exclude 'Documents/virtualbox' \
    /home/"${USER}" "${server}":"${dir}" 2>> "${errorFile}"

그러나 백업중인 서버를 전환했으며 이제 rsync몇 초 (최대 몇 분) 동안 시작 및 실행되지만 오류 메시지와 함께 중지됩니다.

packet_write_wait: Connection to x.x.x.x: Broken pipe
rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.1]

다른 서버에서 작동하기 때문에 문제가 연결 또는 서버 자체라고 생각합니다. 연결이 안정적인 것 같습니다. 케이블로 연결되어 있는데 방해가 없습니다. 또한 백업을 수행하는 동안 서버에 핑을 시도했습니다. ping은 백업이 중단 된 경우에도 100 %의 응답 속도를 갖습니다.

kerberos원격 서버에서 인증 하는 데 사용 합니다.

나는 여러 조합을 시도 ServerAliveInterval, ServerAliveCountMax또는 ClientAliveInterval내에서 ~/.ssh/config,하지만 아무 소용.

서버 rsync에서 어떤 이유로 명령을 죽이는 것이있을 수 있지만 조사 방법을 모르겠습니다. 어떤 아이디어?

문제가 메모리 부족 일 수 있습니다. 서버에 1GB가 크면 큰 데이터 세트의 경우 rsync가 실패합니다. 아마도 알고리즘의 메모리 용량이 향상되었지만 8 년 정도 지나서도 그 문제를 보지 못했습니다. 실제로 이것은 외부 촬영이지만 탐험 할 가치가 있습니다. 더 작은 데이터 세트를 먼저 시도하십시오. 위생 검사의 양식으로 타르 타르를 시도해 볼 수도 있습니다.

tar cf - $HOME | ssh ${server} tar xf -

그 경우 도 몇 분 후 실패, 그것은 메모리 아니다.

나는 rsync과거에도 이것을 만났다 . 나를 위해 해결 한 솔루션은 screen세션 내에서 실행했기 때문에 원격 서버에 대한 연결을 유지하는 데 도움이되었습니다.

screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session

실행을 통해 상태를 확인할 수 있습니다 screen -x rsync(또는 세션에 이름을 지정하면 세션 이름을 지정하기로 결정한 것은 필요하지 않음). 현재 셸을 해당 세션에 다시 연결합니다. 백그라운드에서 계속 실행되도록 상태를 확인한 후 다시 분리하십시오.

또한 screen[누군가가 틀렸다면 수정 해주세요]를 수행하여 한 번의 실패로 백그라운드에서 실행되도록 명령을 실행할 수도 있습니다 screen -dm 'command'. man screen마지막 것을 시도 하기 전에 할 수도 있습니다 .

편집하다:

나는 screen이 시나리오에서 도움이되지 않는다는 것을 확인했기 때문에 내 대답을 편집하고 있지만, scp어떤 종류의 결과를 얻었는지, 그 이상하게 대답 한 결과 를 보라고 제안하는 내 의견에 대답했지만 제대로 작동했습니다.

: 그래서 내 새로운 대답은 이것이다 사용 scp- 나 ssh(와 함께 tar) - 대신rsync

부여, scp같은 기능의 광대 한 수를 지원하지 않습니다 rsync,하지만 당신은 실제로는 것을 얼마나 많은 기능을 발견하고 놀라게 될 것 않습니다 거의있다 지원 동일한 의 그것을 rsync.

다음에 대한 실제 시나리오 scp및 다른 대안 rsync:

얼마 전 저는 프로덕션 서버에서 로그를 가져와 웹 서버에 로컬로 저장하여 개발자가 문제 해결 목적으로 액세스 할 수있는 셸 스크립트를 작성해야했습니다. 유닉스 팀이 rsync서버 에 설치하는 데 실패한 후 , 나는 그것을 사용하여 해결 방법을 생각해 냈습니다 scp.

그 존재는 사용하는 모든이되도록 나는 최근 스크립트를 수정했다 ssh및 tar- GNU tar/ gtar, 정확하게 할 수 있습니다. GNU는 tar당신이 실제로에서 찾을 수있는 옵션의 많은 지원 rsync과 같은 --include, --exclude등의 허가 / 속성 보존, 압축,

내가 이것을 달성하는 방법은 ssh(pubkey auth를 통해) 원격 서버 에 -ing하여 사용하는 것입니다 gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]-이것은 모든 정보를에 쓴 stdout다음 tar -xzf원격 프로덕션 서버에서 변경 사항이 없도록 [locally]로 파이프됩니다. , 모든 파일을 로컬 서버로 그대로 가져옵니다. rsync이 경우에 대한 훌륭한 대안 입니다. 증분 백업과 해당 기능을 검사하는 블록 수준 오류 수준 만 중요하지 않은 tar것도 중요 합니다.scprsync

사용할 때 내가 말하는거다 전체 명령 ssh과 tar이 같은 것 (원격 솔라리스 10은, 현지는 무엇의 가치를 위해, 데비안입니다) :

cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz

귀하의 시나리오에서는 반대의 경우- tar -cf -로컬 및 원격 서버로의 파이프 연결 ssh user@remotehost "tar -xf -"-이 유형의 동작을 참조하지만 자세한 내용은 다루지 않는 또 다른 대답이 있습니다.

속도를 높이기 위해 포함시킨 몇 가지 다른 옵션이 있습니다. 나는 실행 시간을 가능한 한 짧게하기 위해 모든 것을 끊임없이 시간을 정했다. 압축을 사용하는 것은 의미가 없다고 생각 tar하지만 압축 을 활성화하기 위해 -Cwith 플래그를 사용하는 것처럼 실제로 속도가 약간 빨라집니다 . 내가 사용하는 정확한 명령 (내가 게시 한 것과 매우 유사 함)을 포함하도록 나중에이 게시물을 업데이트 할 수 있지만 이번 주 휴가를 마치고 나서 현재 VPN을 사용하고 싶지는 않습니다.sshssh

Solaris 10에서도 -c blowfish인증하는 것이 가장 빠르며 속도를 높이는 데 도움이되기 때문에을 사용하지만 Solaris 11에서는이를 지원하지 않거나이 암호 제품군을 비활성화합니다.

또한 ssh/ tar옵션 을 사용하기로 선택한 screen경우 시간이 오래 걸리는 백업을 수행하는 경우 원래 사용 하는 솔루션을 실제로 구현하는 것이 좋습니다 . 그렇지 않은 경우 keepalive / timeout 설정 ssh_config이 올바르게 조정 되었는지 확인하십시오. 그렇지 않으면 이 방법으로 파이프가 파손될 가능성이 높습니다.

당신이 이동하더라도 scp, 나는 항상 사용하는 것이 좋습니다로 발견 screen또는 tmux이런 종류의 작업을 수행 할 때, 단지의 경우 . 여러 번 필자의 조언을 따르지 않고이를 수행하지 못하는 경우가 있지만 실제로는 이러한 도구 중 하나를 사용하여 활성 셸 세션의 연결이 끊어져 원격 작업이 망가지지 않도록하는 것이 좋습니다.

rsync문제 의 근본 원인을 파악하고 싶다는 것을 알고 있습니다 . 그러나 이것이 정말로 중요한 경우, 그 동안 실험 해 볼 수있는 두 가지 훌륭한 대안입니다.

OSX El Capitan에서 동일한 문제가 있었고 rsync v3.11로 업그레이드 하여이 문제를 해결했습니다. v2.6.9에서 문제가 발생했습니다.

Kerberos는 인증만을위한 것으로 연결에 성공한 후에는 아무런 문제가 발생하지 않습니다.

rsync 데몬도 사용해 보셨습니까?

서버가 동일한 네트워크에 있습니까? 아니면 방화벽 / 라우터가 있습니까?

서버간에 netcat 세션을 설정할 수 있습니다. 이는 서버간에 연결 문제가있는 경우 간단한 방법입니다.

첫 번째 서버에서 :

nc -lk <port-number>

그리고 클라이언트에서

nc <server> <port-number>

연결을 열어두고 연결 상태를 유지하는지 또는 연결이 느슨한 지 확인할 수 있습니다. 당신은 또한 클라이언트에 무언가를 써볼 수 있습니다, 그것이 다른 쪽에서 끝나는 것을보십시오.

원격 서버에 stdout에 쓰는 무언가가 있습니다 . .profile또는에 있을 수 있습니다 .bash_profile. stty또는 보다 덜 분명한 것일 수 있습니다 mesg. 확실하지 않은 경우 서버에 로그인 할 때 질문에 대화 내용을 복사하십시오 (반드시 호스트 이름 수정).

rsync로 이와 같은 문제가 발생한 유일한 시간은 대상 서버와 동일한 IP 주소를 가진 다른 컴퓨터의 여분의 이더넷 포트로 추적했습니다. rsync에 결함이 있으면 네트워크 안정성 또는 (제 경우에는) 구성 문제 일 것입니다.

실행할 때 나는 비슷한 문제가 발생 rsync하거나 수동으로 (중 하나에 cp, scp또는 그놈 노틸러스에서) 리눅스 NAS 기가비트 케이블로 연결된 네트워크를 통해 (아무 근거 낮은 전원 ARM에 리눅스 데스크탑에서 큰 파일을 복사하는 kerberos내 설정에서). NAS 드라이브는을 사용하여 공유되며을 사용 samba하여 클라이언트에 마운트됩니다 cifs. 나를위한 해결책은 캐싱없이 클라이언트에서 NAS 파일 시스템을 마운트하는 것이 었습니다 ( mount.cifs 매뉴얼 페이지 참조 ).

sudo mount -t cifs //server.lan/somedir /mnt/somedir/ -o cache=none

또한, 사용하는 클라이언트의 NAS 드라이브 설치시 gvfs에 nautilus큰 파일을 복사 할 때 유지되지 것입니다이 문제를 (하지만 그와 함께 일을하지 않습니다 rsync하지만).

로컬 디스크 읽기와 동시에 Linux가 네트워크 파일 시스템에 쓰기를 수행 하면이 문제가 발생하는 이유에 대해 자세히 설명 할 수 있습니다.

rsync 버전을 업그레이드하여 송신 및 수신 PC 모두에서 정확히 동일 하도록하십시오. /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794에서 내 대답을 참조 하십시오 .