여전히 ssh로 작성된 파일을 복사하는 방법은 무엇입니까?

상황은 다음과 같습니다.

1. sftp를 사용하여 클라이언트 A에서 서버로 큰 파일을 업로드하고 있습니다.
2. 또한 ssh를 통해 서버에서 클라이언트 B로이 파일을 다운로드해야합니다.

내가하고 싶은 일은 클라이언트 A에서 업로드가 여전히 진행 중일 때 서버에서 클라이언트 B 로의 전송을 시작하는 것입니다.

이 작업을 수행하는 가장 좋은 방법 / 도구는 무엇입니까?

업데이트 :

지금까지의 답변은 흥미 롭습니다. 모두 읽고 테스트해야합니다. 클라이언트 A가 파일을 업로드하는 방법을 제어하는 ​​데 의존하지 않는 답변에 대한 보너스 포인트. (즉, 클라이언트 A로부터 우리가 아는 유일한 것은 파일이 알려진 파일 이름으로 작성되고 있다는 것입니다.)

SFTP를 사용하는 대신 단일 파일의 경우 송신 측 cat또는 pv송신 측 및 tee중간 서버 에서 ssh를 통해 파일을 파이프하여 데이터를 파일로 보내고 다른 ssh 링크를 통해 사본을 보낼 수 있습니다. 데이터를 파일에 씁니다. 정확한 부두는 지금 당장 플레이 할 시간이 없기 때문에 독자를위한 연습으로 남겨 두어야했습니다 (죄송합니다). 이 방법은 SSH를 통해 두 번째 대상에 공개적으로 액세스 할 수있는 경우에만 작동하며 클라이언트 시스템으로 설명 할 때는 그렇지 않을 수 있습니다.

"실행 및 대기"가 적지 만 rsync서버와 클라이언트 B 사이에서 사용하는 것이 더 쉬운 다른 접근 방법입니다 . 처음 실행할 때 데이터의 일부 사본을 얻을 수 있지만 다시 실행할 수 있습니다. 나중에 더 많은 데이터를 가져옵니다 (Client1-> 서버 전송이 완료되면 마지막으로 한 번 실행). 이것은 SFTP 전송 중에 서버가 데이터를 올바른 파일 이름으로 직접 넣는 경우에만 작동합니다 (때로는 데이터가 임시 파일로 들어가는 것을 볼 수 있습니다. 그런 다음 파일이 완전히 전송되면 이름이 바뀝니다. 파일을 더 원자 적으로 업데이트하지만 rsync 아이디어를 사용할 수 없게 만듭니다). scp 대신 C1-> S 전송에 rsync를 사용할 수도 있습니다 (--inplace-위에서 언급 한 문제를 피하는 옵션)-rsync를 사용하면 대량 전송 중에 C1-> Server 연결에 문제가 발생하는 경우 모든 것을 다시 보내지 않아도 보호 할 rsync --inplace -a --progress <source> <dest>수 있습니다. 이 "전송 이력서"행동).

위의 내용을 요약하려면 다음을 실행하십시오.

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매번 전체 로트를 전송하는 대신 위치를 업데이트해야하는 절대 최소값 만 전송하는 것이 매우 좋습니다. 편집증를 들어 당신은 추가 할 수 있습니다 --checksum(이 필요하지 않은 옮겨진되는 큰 파일 훨씬 더 많은 CPU 시간이 걸릴 것입니다하지만 훨씬 더 많은 데이터를 발생하지 않습니다)에 rsync를 명령에 옵션을 속도에 대한 --compress옵션은 데이터가있는 경우 도움이 될 것입니다 전송중인 압축 형식이 아닙니다.

현재 시도해 볼 수 없으므로 실패 할 수 있습니다. 제 생각은 다음과 같습니다. 파일이 클라이언트 B에 도착하는 디렉토리를 마운트하십시오. 예를 들어 클라이언트 b의 파일 시스템에서 sshfs를 / mnt / server에 그때

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 명령을 추가하십시오.

당신은 그것을 위해 fifo를 사용할 수 있습니다. 두 개의 xterm 만 포함하는 ssh가없는 단순성을 위해 먼저 :

xterm A에서 :

$ mkfifo fif
$ cat test.tar.gz | tee copy.tar.gz > fif

xterm B에서 :

$ cat fif > dest.tar.gz
$ cmp test.tar.gz dest.tar.gz
$ echo $?
0
$ cmp test.tar.gz copy.tar.gz
$ echo $?
0

ssh를 사용하면 다음 행을 따라야합니다-아마도 ssh에서 이스케이프 문자를 비활성화해야합니다 (-e none).

클라이언트 A :

 $ ssh server mkfifo fif
 $ cat src.tar.gz | ssh "tee fif > copy.tar.gz"

클라이언트 B :

 $ ssh server cat fif > dest.tar.gz

원래 포스터와 같은 해결책이 필요한 상황이 있습니다. 한 위치에서 내 컴퓨터로 하키 게임을 녹화하고 있으며 다른 위치의 내 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는 파일의 끝까지 따라 가지 않습니다. 다음으로, "파이프 뷰어 (pv)"로 파이프하고 파일의 크기가 얼마나 큰지에 대한 추정값을 제공합니다. 이것은 필요하지 않지만 진행률 표시기를보고 싶습니다. 그런 다음 스트림을 ssh 연결에 파이프합니다. ssh 연결은 -C압축을 위해 (네트워크 대역폭을 줄이고 속도를 높이기 위해) -c arcfour,blowfish-cbc가장 저렴한 암호화 (다시 속도를 높이기 위해)에 사용합니다.-p대상에서 사용중인 방화벽 포트 용이며 ssh는 대상에서 dd 명령을 실행하여 파일을 수신 할 때 파일을 다시 만듭니다. 이 솔루션이 훌륭하게 작동합니다. 파일이 생성되고 짧은 지연만으로 복사되는 동안 하키 게임을 볼 수 있습니다.

tail -f 메소드가 작동하는지 확실하지 않습니다 (파일이 텍스트 인 경우). 그 이유는 tail -f 및 sftp가 메타 정보를 전송하고 의존하는 방법을 모르기 때문입니다.

sftp가 먼저 메타 정보를 전송하고 tail -f가 메타 정보에 의존하여 파일이 더 이상 없다고 말하면 tail은 EOF 또는 널로 끝을 나쁘게 할 수 있습니다.

업로드 경로에 신경 쓰지 않으면, 즉 컴퓨터 1이 컴퓨터에 업로드되고 컴퓨터 2가 컴퓨터 3에 업로드되면 sftp 대신 bittorent를 사용하는 것이 좋습니다. 그것이 설계된 것 같습니다.

처음부터 파일을 읽으려고 시도 할 수 있지만 적어도 같은 속도로 파일을 쓸 수 있는지 확인해야합니다.