SSH를 통해 아직 작성 중인 파일을 복사하는 방법은 무엇입니까?

단일 파일의 경우 SFTP를 사용하는 대신 전송 측에서 ssh를 통해 파일을 사용 cat하거나 파이프하고 중간 서버에서 사용할 수 있으며, 그곳의 파일로 데이터를 보내고 다른 쪽 끝에서 다른 SSH 링크를 통해 복사본을 보낼 수 있습니다. 파일에 데이터를 씁니다. 지금은 그것을 가지고 놀 시간이 없기 때문에 연습으로 필요한 정확한 부두교를 독자에게 맡기겠습니다(죄송합니다). 이 방법은 두 번째 대상이 SSH를 통해 공개적으로 액세스할 수 있는 경우에만 작동하며 클라이언트 시스템으로 설명하는 경우에는 그렇지 않을 수 있습니다.pvtee

"실행하고 기다리는" 방식은 덜하지만 아마도 더 쉬운 또 다른 접근 방식은 rsync서버와 클라이언트 B 간에 사용하는 것 입니다. 이 방법을 처음 실행하면 데이터의 부분 복사본을 얻을 수 있지만 다시 실행하면 더 많은 데이터를 얻을 수 있습니다(클라이언트 1->서버 전송이 완료된 후 마지막 실행). 이는 SFTP 전송 중에 서버가 데이터를 올바른 파일 이름에 직접 입력하는 경우에만 작동합니다(때때로 데이터가 임시 파일로 이동한 다음 파일이 완전히 전송된 후 이름을 바꾸는 경우가 있습니다. 이는 파일을 더 많이 업데이트하기 위한 것입니다. 원자적이지만 rsync 아이디어를 사용할 수 없게 만듭니다). C1->S 전송에 scp 대신 rsync를 사용할 수도 있습니다( --inplace위 문제를 피하기 위해 해당 옵션을 사용하는 경우). rsync를 사용하면 C1->서버 연결에 문제가 발생할 경우 모든 것을 다시 보내지 않아도 되는 보호 기능도 제공됩니다. 대규모 전송( rsync --inplace -a --progress <source> <dest>저는 rsync를 사용할 수 있을 때 "전송 재개" 동작을 위해 scp/sftp 대신 scp/sftp를 사용하는 경향이 있습니다).

위 내용을 요약하려면 다음을 실행하세요.

rsync --inplace -a --progress <source> user@server:/<destination_file_or_folder>

client1에서 다음을 실행하십시오.

rsync --inplace -a --progress user@server:/<destination_file_or_folder> <destination_on_cli2>

첫 번째 전송이 완료될 때까지 client2에서 반복합니다(그런 다음 다시 실행하여 모든 것을 얻었는지 확인합니다). rsync매번 전체를 전송하는 대신 위치를 업데이트하는 데 필요한 절대 최소값만 전송하는 데 매우 능숙합니다. 편집증의 경우 해당 옵션을 rsync 명령에 추가할 수 있습니다 (대용량 파일의 경우 CPU 시간이 더 많이 걸리지만 필요하지 않은 경우 더 많은 데이터 가 --checksum전송되지는 않음). --compress전송된 형식은 압축되지 않습니다.

지금은 시도할 수 없으므로 실패할 가능성이 높습니다. 내 생각은 다음과 같습니다. 클라이언트 B의 디렉토리에 파일을 마운트합니다. 예를 들어 클라이언트 B의 파일 시스템에서 /mnt/server에 sshfs를 사용합니다. 그 다음에

tail -c +0 -f /mnt/server/thefileinquestion > ~/finalfile

나는 이것이 효과가 있다고 생각합니다:

user@clientA:~$ cat file | ssh server "cat > dest"

그런 다음

user@clientB:~$ ssh server "tail +0 -f dest" > file

처리량을 보려면 pv 명령을 추가하십시오.

원래 포스터에서 요청한 것과 같은 솔루션이 필요한 상황에 직면했습니다. 한 장소에서는 컴퓨터로 하키 경기를 녹화하고 있는데 다른 장소에서는 TV로 시청하고 싶습니다. 두 위치 간의 링크를 통해 약 1.3Mb/s의 복사 속도와 약 1.5Mb/s의 비디오 녹화 속도가 가능합니다. 그래서 녹음이 시작되면 파일을 복사하고 싶습니다. 이런 식으로 내 3시간 게임을 약 3.5시간 안에 복제할 수 있습니다. 그래서 녹화 시작하면 복사해서 녹화 시작하고 30분 뒤에 시청을 시작하면 됩니다. 그러면 거의 실시간으로 중단 없이 시청할 수 있습니다. 즉, 새 파일을 작성할 때 복사할 수 있는 한입니다. rsync 및 scp와 같은 도구의 문제점은 복사를 시작할 때 파일 크기를 확인하고 해당 복사 중에 파일이 두 배 이상 복사되었음에도 불구하고 해당 양의 데이터가 복사되면 종료된다는 것입니다. 그리고 복사하기 위해 루프에서 rsync를 사용하면 일단 중지되고 다음 rsync가 완료되면 대상 파일이 다시 작성되어 내 비디오 플레이어가 종료되고 다시 시청을 시작해야 하며 내가 갑자기 프로그램을 죽였을 때 프로그램에 포인트를 줬어요. 더 나은 솔루션을 원했지만 찾을 수 없어서 다음과 같이 정리했습니다.

dd if=2031_20160514030000.mpg |
pv --size 4653819304 |
ssh -C -c arcfour,blowfish-cbc -p 5555 myserver.com 'dd of=/media/TV/2031_20160514030000.mpg'

그러면 이것이 무엇을 하는가?

먼저 dd를 사용하여 파일이 커지면 이를 복사합니다. dd가 네트워크를 통해 전송될 수 있는 것보다 파일이 더 빨리 커지므로 dd는 파일 끝에 도달하지 않습니다. 다음으로, 이를 Pipe Viewer(pv)에 연결하고 해당 파일의 일반적인 크기를 기준으로 파일 크기를 추정했습니다. 필수는 아니지만 진행률 차트를 보는 것이 좋습니다. 그런 다음 스트림을 SSH 연결로 파이프합니다. ssh는 -C압축(네트워크 대역폭을 줄이고 속도를 높이기 위해), -c arcfour,blowfish-cbc가장 저렴한 암호화(다시 속도를 높이기 위해)를 위해 연결합니다 . 이는 -p대상에서 사용하는 방화벽 포트입니다. 그리고 ssh를 사용하고 마지막으로 dd 명령을 실행합니다. 수신된 파일을 다시 생성하기 위한 대상입니다. 이 솔루션이 훌륭하게 작동한다고 말하게 되어 기쁩니다. 파일이 생성되고 복사되는 동안 지연을 최소화하면서 하키 경기를 볼 수 있습니다.