it-gundan.com

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

상황은 다음과 같습니다.

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

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

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

업데이트 :

지금까지의 답변은 흥미 롭습니다. 모두 읽고 테스트 할 것입니다. 클라이언트 A가 파일을 업로드하는 방법에 의존하지 않는 답변에 대한 보너스 포인트. (즉, 클라이언트 A로부터 우리가 아는 유일한 것은 파일이 알려진 파일 이름에 기록된다는 것입니다.)

20
Steven D

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

"실행 후 대기"가 적지 만 더 쉬울 수있는 또 다른 접근 방식은 서버와 클라이언트 B간에 rsync을 사용하는 것입니다. 처음 실행하면 데이터의 일부 사본을 얻을 수 있지만 나중에 더 많은 데이터를 얻기 위해 다시 실행할 수 있습니다 (Client1-> Server 전송이 완료되면 한 번의 최종 실행으로). 이것은 SFTP 전송 중에 서버가 올바른 파일 이름에 데이터를 직접 넣는 경우에만 작동합니다 (때로는 파일이 완전히 전송되면 이름이 변경되는 임시 파일로 이동하는 데이터를 볼 수 있습니다. 파일 업데이트는 더 원자 적이지만 rsync 아이디어를 사용할 수 없게 만듭니다). scp 대신 C1-> S 전송에 rsync를 사용할 수도 있습니다 (위에서 언급 한 문제를 피하기 위해 --inplace 옵션을 사용하는 경우). rsync를 사용하면 C1이 모든 것을 다시 보낼 필요가 없도록 보호 할 수 있습니다. -> 대량 전송 중에 서버 연결에 문제가 발생합니다 (이 "전송 재개"동작을 위해 rsync를 사용할 수있을 때 scp/sftp 대신 rsync --inplace -a --progress <source> <dest>를 사용하는 경향이 있습니다).

위의 내용을 요약하면 다음을 실행합니다.

rsync --inplace -a --progress <source> [email protected]:/<destination_file_or_folder>

client1에서 다음 실행

rsync --inplace -a --progress [email protected]:/<destination_file_or_folder> <destination_on_cli2>

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

10
David Spillett

지금은 시도 할 수 없으므로 실패 할 수 있습니다. 제 생각은 다음과 같습니다. 파일이 클라이언트 B에 도착하는 디렉토리를 마운트합니다. sshfs를 사용하여 클라이언트 파일 시스템의/mnt/server에 b. 그때

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

그것을 위해 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
1
maxschlepzig

원래 포스터가 물었던 것과 같은 해결책이 필요한 상황이 있습니다. 한 위치에서 내 컴퓨터로 하키 게임을 녹화하고 있는데 다른 위치에서 내 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 명령을 실행하여 파일을 수신 할 때 파일을 다시 만듭니다. 이 솔루션은 훌륭하게 작동합니다. 파일이 생성되고 복사되는 동안 짧은 지연 시간으로 하키 게임을 볼 수 있습니다.

1
Neophraz

나는 이것이 효과가 있다고 생각한다.

[email protected]:~$ cat file | ssh server "cat > dest"

그리고

[email protected]:~$ ssh server "tail +0 -f dest" > file

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

1
wiretapped

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

Sftp가 먼저 메타 정보를 전송하고 tail -f가 메타 정보에 의존하여 더 이상 파일이 없음을 알리면 tail은 EOF 또는 null로 끝을 잘못 표시 할 수 있습니다.

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

0
HandyGandy

처음부터 파일 읽기를 시도 할 수 있지만 최소한 동일한 속도로 쓸 수 있는지 확인해야합니다.

0
Tim Connor