두 서버간에 많은 수의 파일을 빠르게 복사하는 방법

두 서브 (Ubuntu) 사이에 엄청난 양의 mp3를 전송해야합니다. 엄청나게 평균 300K 인 약 백만 개의 파일을 의미합니다. 나는 노력 scp했지만 일주일 정도 걸렸을 것이다. (약 500KB / s) HTTP로 단일 파일을 전송하면 9-10MB / s가되지만 모든 파일을 전송하는 방법을 모르겠습니다.

그들 모두를 빨리 옮길 수있는 방법이 있습니까?

나는 타르를 추천합니다. 파일 트리가 이미 비슷한 경우 rsync가 매우 잘 수행 됩니다. 그러나 rsync는 각 파일에 대해 여러 번의 분석 단계를 수행 한 다음 변경 사항을 복사하므로 초기 복사본의 tar보다 속도가 훨씬 느립니다. 이 명령은 아마도 당신이 원하는 것을 할 것입니다. 권한과 사용자 / 그룹 소유권을 유지하면서 시스템간에 파일을 복사합니다.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

아래 Mackintosh의 의견에 따르면 이것은 rsync에 사용할 명령입니다.

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

외장 하드 드라이브 및 당일 택배 배송.

rsync를 사용합니다.

디렉토리 목록을 사용할 수있는 HTTP를 통해 내 보낸 경우 wget 및 --mirror 인수도 사용할 수 있습니다.

SCP가 모든 것을 암호화하므로 CPU에 병목 현상이 발생하기 때문에 HTTP가 SCP보다 빠르다는 것을 이미 알고 있습니다. HTTP와 rsync는 암호화되지 않기 때문에 더 빠르게 이동할 것입니다.

Ubuntu에서 rsync를 설정하는 데 필요한 문서는 다음과 같습니다. https://help.ubuntu.com/community/rsync

이 문서에서는 SSH를 통한 rsync 터널링에 대해 이야기하지만 개인 LAN에서 데이터를 옮기는 경우 SSH가 필요하지 않습니다. (개인 LAN에 있다고 가정합니다. 인터넷을 통해 초당 9-10MB를 얻는다면 어떤 종류의 연결이 있는지 알고 싶습니다!)

다음은 상대적으로 안전하지 않은 rsync 서버를 설정하는 데 사용할 수있는 매우 기본적인 문서입니다 (SSH에 의존하지 않음). http://transamrit.net/docs/rsync/

많은 논의없이 netcat, 네트워크 스위치 나이프를 사용하십시오. 프로토콜 오버 헤드가 없으며 네트워크 소켓에 직접 복사하고 있습니다. 예

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

rsync를 사용하면 많은 파일을 사용 하여 양쪽 끝에서 버전 3 이상을 얻으려고합니다 . 더 작은 버전은 전송을 시작하기 전에 모든 파일을 열거하기 때문입니다. 새로운 기능을 incremental-recursion 이라고 합니다.

rsync가 다른 3.x 버전과 통신 할 때 새로운 증분 재귀 알고리즘이 사용됩니다. 그러면 모든 파일을 찾기 전에 전송이 더 빨리 시작되고 훨씬 적은 메모리가 필요합니다. 일부 제한 사항은 맨 페이지의 --recursive 옵션을 참조하십시오.

rsync는 다른 사람들과 마찬가지로 이미 권장했습니다. 암호화로 인한 CPU 오버 헤드가 병목 현상 인 경우 복어와 같이 덜 CPU 집중적 인 알고리즘을 사용하십시오. 예를 들어

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

어제 80TB의 데이터 (수백만 개의 작은 파일)를 이동 하면서 시도를 중단함에 따라 에서 rsync로 전환 tar 하는 것이 훨씬 빨라졌습니다 .

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

tar대신에 전환 ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

이러한 서버는 동일한 LAN에 있으므로 대상은 소스 시스템에서 NFS 마운트되어 푸시를 수행합니다. 더 빨라지지는 않았으므로 atime파일 을 보존하지 않기로 결정했습니다 .

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

아래 그래픽은 rsync에서 tar로 변경 한 차이점을 보여줍니다. 그것은 내 상사의 아이디어 였고 동료 는 그것을 실행하고 그의 블로그에 큰 글을 올렸습니다 . 나는 단지 예쁜 그림을 좋아한다 . :)

많은 수의 파일을 복사 할 때 tar 및 rsync와 같은 도구가 많은 파일을 열고 닫는 오버 헤드로 인해 필요한 것보다 비효율적이라는 것을 알았습니다. 이 시나리오에서는 tar보다 빠른 fast-archiver라는 오픈 소스 도구를 작성했습니다. https://github.com/replicon/fast-archiver ; 여러 개의 동시 파일 작업을 수행하여 더 빠르게 작동합니다.

다음은 2 백만 개가 넘는 파일을 백업 한 빠른 아카이브 대 타르의 예입니다. 빠른 보관자는 보관하는 데 27 분이 걸리고 tar는 1 시간 23 분이 걸립니다.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

서버간에 파일을 전송하기 위해 다음과 같이 ssh와 함께 빠른 아카이브를 사용할 수 있습니다.

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

예를 들어 ms를 조정하여 상황에 맞게 훨씬 더 많은 힘을 netcat사용하는 것을 선호하는 것을 제외하고 는 tar 방식을 사용 socat합니다. (또한 원한다면 웃으십시오.하지만 socat일관성이 있기 때문에 기억하기 쉬운 주장이 있습니다). 그래서 최근에 새로운 서버로 물건을 옮길 때 매우 흔합니다.

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

별명은 선택 사항입니다.

다른 대안은 Unison 입니다. 이 경우 Rsync보다 약간 더 효율적일 수 있으며 리스너를 설정하는 것이 다소 쉽습니다.

인기 답변에 오타가 몇 개있을 수 있습니다. 이것은 더 잘 작동 할 수 있습니다 :

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• 네트워크 파일 시스템 (NFS) 을 선택한 다음 원하는대로 복사하십시오 (예 : Midnight Commander (mc), Nautilus (gnome의)). 좋은 결과로 NFS v3을 사용했습니다.
• 삼바 (CIFS) 다음 원하는대로 파일을 복사하지만 그것이 얼마나 효율적인지 모르겠습니다.
• HTTP 와 wget --mirror같이 에반 앤더슨이 제안 또는 다른 HTTP 클라이언트있다. 불쾌한 심볼릭 링크 나 잘못된 색인 파일이 없도록주의하십시오. 당신이 가진 모든 것이 MP3라면, 당신은 안전해야합니다.
• rsync . 나는 그것을 꽤 좋은 결과로 사용했으며 그 좋은 기능 중 하나는 나중에 전송을 중단하고 다시 시작할 수 있다는 것입니다.

다른 사람들이 netcat을 사용하는 것이 좋습니다 . 그것에 대한 나의 경험 을 바탕으로 다른 솔루션에 비해 느리다고 말할 수 있습니다.

Scott Pack의 훌륭한 답변 (이전에 ssh 로이 작업을 수행하는 방법을 몰랐습니다) 덕분 에이 개선 사항을 제공 할 수 있습니다 ( bash쉘 인 경우). 병렬 압축, 진행률 표시기를 추가하고 네트워크 링크에서 무결성을 검사합니다.

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv파이프에 대한 훌륭한 진행률 뷰어 프로그램이며 pigzCPU가 기본적으로 많은 스레드를 사용하는 병렬 gzip 프로그램입니다 (최대 8까지). 당신은 조정 압축 수준은 더 나은 대역폭 네트워크와 함께 그것을 교환하는 CPU의 비율에 맞게 수 pxz -9e및 pxz -d당신이 대역폭보다 훨씬 더 많은 CPU가있는 경우. 완료시 두 합계가 일치하는지 확인하면됩니다.

이 옵션은 대기 시간이 긴 네트워크뿐만 아니라 대량의 데이터에 유용하지만 링크가 불안정하고 끊어지면 크게 도움이되지 않습니다. 이 경우 재 동기화 할 수 있으므로 rsync가 최선의 선택 일 수 있습니다.

샘플 출력 :

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

블록 장치의 경우 :

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

분명히 count =, skip =, seek = 등과 같은 크기 또는 제한인지 확인하십시오.

이 방법으로 파일 시스템을 복사 dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs하면 사용하지 않는 공간의 대부분을 먼저 0으로 설정하여 xfer 속도를 높입니다.

더 빠른 네트워크 카드를 설치하지 않으면 scp보다 더 잘 할 것이라고 생각하지 않습니다. 인터넷을 통해이 작업을 수행하는 경우 도움이되지 않습니다.

rsync 사용하는 것이 좋습니다 . 더 빠르지는 않지만 적어도 실패하면 (또는 너무 오래 걸리므로 종료 한 경우) 다음에 중단 한 곳에서 다시 시작할 수 있습니다.

기가비트 이더넷을 사용하여 2 대의 컴퓨터를 직접 연결할 수 있다면 아마도 가장 빠를 것입니다.

100Mb / s의 경우 이론적 인 처리량은 12.5MB / s이므로 10MB / s에서는 꽤 잘 수행됩니다.

또한 아마도 ssh를 통해 rsync를 제안합니다. 다음과 같은 것 :

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

100Mb / s에서 CPU는 데이터 속도에 큰 영향을 미치지 않으면 서 암호화 / 암호 해독을 처리 할 수 ​​있어야합니다. 그리고 데이터 흐름을 중단하면 중단 한 지점부터 다시 시작할 수 있습니다. "수백만"의 파일이 있으면 시작시 실제로 어떤 항목을 전송하기까지 시간이 걸립니다.

Oracle 로그를 전송하는 것을 제외 하고는이 문제가 발생했습니다.

여기 고장이 있습니다

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

FTP를 큰 성공으로 사용했습니다 (Gb 네트워크에서 ~ 700Mb / s에 해당). 10MB (80Mb / s에 해당)를 얻는다면 무언가 잘못되었을 수 있습니다.

데이터의 출처와 목적지에 대해 무엇을 알려줄 수 있습니까? 단일 드라이브 대 단일 드라이브입니까? RAID를 USB로?

나는이 질문에 이미 답이 있다는 것을 알고 있지만 네트워크가 Gb / s 크로스 오버 케이블에서 느리게 진행되면 무언가를 수정해야합니다.

두 시스템이 같은 LAN에 있는지 또는 보안 채널 (예 : SSH 사용)이 필수인지 언급하지 않았지만 사용할 수있는 또 다른 도구는 netcat 입니다.

수신 시스템에서 다음을 사용합니다.

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

그런 다음 보내는 쪽에서 :

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

다음과 같은 장점이 있습니다.

• ssh의 암호화에 대한 CPU 오버 헤드가 없습니다.
• 이 제품 gzip -1은 CPU를 포화시키지 않고 가벼운 압축을 제공하므로 균형을 잘 유지하면서 최대 처리량을 유지하면서 약간의 압축을 제공합니다. (아마도 MP3 데이터에는 유리하지 않지만 아프지 않습니다.)
• 파일을 그룹으로 분할 할 수있는 경우 두 개 이상의 파이프를 병렬로 실행하여 실제로 네트워크 대역폭을 포화 상태로 유지할 수 있습니다.

예를 들어

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

노트:

• 당신이 어떤 방식으로 전송하든, 나중에 모든 것을 확보하기 위해 rsync 또는 unison을 실행합니다 .
• 원하는 경우 tar대신 사용할 수 있습니다 cpio.
• ssh를 사용하더라도 압축 자체를 사용하지 gzip -1않도록하고 CPU 포화를 피하기 위해 스스로를 통해 파이프 하십시오. 또는 최소한 CompressionLevel을 1로 설정하십시오.

적절한 옵션을 갖춘 간단한 scp는 LAN을 통해 9-10MB / s에 쉽게 도달합니다.

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

이러한 옵션을 사용하면 옵션이없는 것보다 처리량이 4 배 또는 5 배 빨라질 수 있습니다 (기본값).

src쪽에 ftp 서버가있는 경우 ncftp site 에서 ncftpget 을 사용할 수 있습니다 . tar를 내부적으로 사용하므로 작은 파일로 prefect를 작동합니다.

하나의 비교는 이것을 보여줍니다 : 1.9GB 작은 파일 (33926 파일) 이동

1. scp 사용에는 11m59s가 걸립니다
2. rsync를 사용하는 데 7m10s 소요
3. ncftpget을 사용하는 데 1m20s 소요

BBCP 명령을 사용하여 전송을 시도 할 수도 있습니다. 실제로 비명을 지르는 버퍼링 된 병렬 ssh입니다. 파이프를 계속 공급할 수 있다면 보통 90 % 이상의 라인 속도를 얻을 수 있습니다.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

일반적으로 우리는 질식을 피하는 것을 피하기 위해 열심히 노력합니다. 우리는 항상 더 많은 디스크 공간을 "추가"할 수있는 ZFS 풀을 사용합니다. 그러나 때로는 ... 물건을 옮기기 만하면됩니다. "실시간"파일 시스템을 사용하는 경우 전체 폭발이 발생하더라도 복사하는 데 몇 시간 (또는 며칠)이 걸릴 수 있습니다. ole two step zfs send routine :

1. ZFS 스냅 샷을 작성하고 새 머신의 새 풀로 전송하십시오. 시간이 오래 걸리도록하세요.
2. 두 번째 스냅 샷을 만들어 증분으로 보냅니다. 증분 스냅 샷에는 첫 번째 이후의 (훨씬 작은) 변경 세트 만 포함되므로 비교적 빠르게 진행됩니다.
3. 증분 스냅 샷이 완료되면 원본을 켜고 새 사본으로 넘어갈 수 있으며 "오프라인 다운 타임"이 최소로 유지됩니다.

또한 BBCP를 통해 zfs 덤프를 전송합니다. 네트워크 활용도를 최대화하고 전송 시간을 최소화합니다.

BBCP는 무료로 사용할 수 있으며, Google에서 사용할 수 있으며, 간단하게 컴파일 할 수 있습니다. src와 대상 컴퓨터의 / usr / local / bin에 복사하면 거의 작동합니다.

내 대답은 약간 늦었지만 하나의 서버에서 mc (Midnight Commander)를 사용하여 SFTP를 통해 다른 서버에 연결하는 데 좋은 경험을했습니다.

FTP를 통해 연결하는 옵션은 다음과 같이 주소를 입력하여 "왼쪽"및 "오른쪽"메뉴에 있습니다.

/#ftp:name@server.xy/

또는

/#ftp:name@ip.ad.dr.ess/

로컬 파일 시스템에서와 거의 같이 파일 작업을 탐색하고 수행 할 수 있습니다.

백그라운드에서 복사를 수행하는 옵션이 내장되어 있지만 mc가 복사되는 동안 screen 명령을 사용하고 화면에서 분리하는 것이 좋습니다 (나도 빨리 실행되는 것 같습니다).

rSync 옵션의 @scottpack 답변으로

업로드 진행률을 표시하려면 아래 그림과 같이 명령에서 -avW 뒤에 옵션으로 '--progess'를 사용하십시오.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

다음은 일부 기술을 비교하기위한 빠른 벤치 마크입니다.

• 소스는 250Mbps 및 SATA 드라이브를 갖춘 4 코어 Intel Xeon XE CPU E5-1620 @ 3.60GHz
• 대상은 1Gbps 대역폭 및 SSD 드라이브를 갖춘 6 코어 Intel® Xeon® CPU E-2136 @ 3.30GHz

파일 수 : 9632, 총 크기 : 814 MiB, 평균 크기 : 84 KiB

• RSYNC : 1 분 40.570 초
• RSYNC + 압축 : 0m26.519s
• TAR + NETCAT : 1m58.763 초
• TAR + 압축 + NETCAT : 0m28.009s

tar / netcat 명령은 다음과 같습니다.

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync 또는 하나의 파일 내에서 압축을 풀고 scp를 원할 수도 있습니다. 디스크 공간이 부족한 경우 tar를 만드는 동안 ssh 위에 직접 tar를 파이프 할 수 있습니다.

MP3 및 기타 압축 파일을 통해 전송하는 경우 해당 파일을 추가로 압축하려고 시도하는 솔루션을 많이 얻지 못합니다. 이 솔루션은 두 서버 사이에 다중 연결을 생성하여 두 시스템 사이의 대역폭에 더 많은 스트레스를 줄 수있는 것입니다. 이것이 최대치가되면 하드웨어를 개선하지 않고도 얻을 수있는 것이 많지 않습니다. (예를 들어 해당 서버 간의 네트워크 카드 속도가 빨라집니다.)

1GB 파일을 복사하기 위해 몇 가지 도구를 사용해 보았습니다. 결과는 다음과 같습니다. rsync를 다시 시작하는 방법은 ssh를 백엔드로 사용하지 않으므로 동일한 결과입니다. 결론적으로 wget -bqc를 사용하여 http로 이동하여 시간을 줄 것입니다. 이것이 도움이되기를 바랍니다.

BackupPC 디스크를 다른 컴퓨터에 복사해야했습니다.

나는 rsync를 사용했다.

기계에는 256MB의 메모리가 있습니다.

내가 따르는 절차는 다음과 같습니다.

• rsync없이 실행 -H(9 시간 소요)
• rsync가 끝나면 cpool디렉토리를 동기화하고 디렉토리로 시작했습니다 pc. 전학을 끊었 어
• 그런 다음 플래그 로 다시 시작 rsync하고 디렉토리에 -H하드 링크 된 모든 파일 pc이 올바르게 전송되었습니다 (프로 시저는 모든 실제 파일을 찾은 cpool다음 pc디렉토리에 링크했습니다 ) (3 시간이 걸렸습니다).

결국 df -m추가 공간이 사용되지 않았 음을 확인할 수있었습니다 .

이런 식으로 나는 메모리와 rsync 문제를 피했다. 항상 top과 top을 사용하여 성능을 확인할 수 있으며 마지막으로 165GB의 데이터를 전송했습니다.