두 서버간에 수백만 개의 파일을 복사하는 가장 좋은 방법

하나의 디렉토리에 약 5 백만 개의 작은 (5-30k) 파일이 있으며 동일한 기가비트 네트워크의 다른 컴퓨터에 복사하려고합니다. rsync를 사용해 보았지만 몇 시간 동안 실행 한 후에 크롤링 속도가 느려질 수 있습니다 .rsync가 매번 소스 및 대상 파일을 확인해야한다는 사실 때문에 가정합니까?

두 번째 생각은 scp를 사용하는 것이지만 더 나은 방법이 있는지 알아보기 위해 외부 의견을 얻고 싶었습니다. 감사!

이와 같은 것이 잘 작동합니다.

tar c some/dir | gzip - |  ssh host2 tar xz

기가비트 네트워크에 있으므로 gzip 및 "z"플래그를 생략하여 추출 할 수도 있습니다.

하나의 디렉토리에 5 개의 MILLION 파일이 모두 있다는 사실은 많은 도구를 어지럽게 만들 것입니다. 나는 rsync가 이것을 정상적으로 처리하지 않았다는 사실에 놀라지 않습니다. 그것은 "독특한"상황입니다. 파일을 일종의 디렉토리 구조로 구성하는 방법을 알 수 있다면 rsync와 같은 표준 동기화 도구가 훨씬 반응이 좋을 것입니다.

그러나 실제 조언을 제공하는 것 중 하나는 네트워크를 통하지 않고 실제 서버에서 파일의 복사본을 만들 수 있도록 드라이브를 물리적으로 대상 컴퓨터로 일시적으로 이동하는 것입니다. 그런 다음 드라이브를 뒤로 옮기고 rsync를 사용하여 최신 상태를 유지하십시오.

기가비트 스위치 (신뢰할 수있는 환경에서)를 통해 수백만 개의 파일을 복사하려면 user55286에서 이미 제안한 것처럼 netcat (or nc)및 의 조합을 사용할 수도 있습니다 tar. 이렇게하면 모든 파일이 하나의 큰 파일로 스트리밍됩니다 ( 빠른 파일 복사-Linux! (39GB) 참조 ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

디렉토리에 약 백만 개의 파일이 있습니다 (약 4 년 분량의 파일).

그리고 robocopy를 사용하여 파일을 YYYY / MM 디렉토리 (한 달에 약 35-45,000 개의 파일)로 옮겼습니다. robocopy 스크립트를 .bat 파일에 다음과 같이 넣습니다.

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

간단한 참고 사항 .. /ns /nc /nfl /np추가 정보로 로그 파일이 부풀어 오르는 것을 방지하기 위해 /log+...요약 정보를 로그 파일에 쓰는 것입니다.

/minage and /maxage is to copy files modified with in that date range. 

예를 들어 수정 된 파일> = 01 / Nov / 2008 (포함)은 수정 된 파일 <01 / Dec / 2008 (포함하지 않음)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov 파일을 이동

그런 다음 소스 디렉토리가 온다

그런 다음 대상 디렉토리가옵니다 (필요에 따라 디렉토리가 즉시 생성됩니다).

1 개월 분량의 전송 (약 35-45,000 개 파일)에 약 40-60 분이 걸렸습니다. 1 년 분량의 전송에는 약 12 ​​시간이 걸리지 않습니다.

Windows Server 2003 사용

모든 내용이 로그 파일에 기록됩니다 ... 시작 시간, 종료 시간 및 복사 된 파일 수.

Robocopy는 하루를 구했습니다.

타르 솔루션에 플러스 1을 적용했지만 환경에 따라 다른 아이디어가 있습니다. dd (1) 사용에 대해 생각할 수 있습니다 . 이와 같은 속도 문제는 파일을 열고 닫는 데 많은 머리 움직임이 필요하다는 것입니다.이 작업은 500 만 번 수행됩니다. 이것들이 연속적으로 할당되는 것을 보장 할 수 있습니다. 대신에 그것들을 dd 수 있습니다. 이것은 헤드 모션의 수를 5 배 이상 줄입니다.

나는 현재 가장 빠른 압축 도구로 lz4 를 사용하는 것을 선호합니다 . SSH 옵션 -c arcfour128 은 기본값보다 빠른 암호화 알고리즘을 사용합니다. [1]

따라서 디렉토리 전송은 다음과 같습니다.

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

데비안 lz4 명령은 lz4c이고 CentOS에서는 lz4입니다.

Robocopy 는 이런 것들에 좋습니다. 네트워크 시간 초과 후 다시 시도하고 파이프 간 간격을 설정하여 파이프를 휩쓸 수도 있습니다.

[편집하다]

이것은 Windows 전용 응용 프로그램입니다.

나는 이것이 어리석은 일이라는 것을 알고 있지만 외부 디스크에 복사하여 다른 서버로 옮기는 것을 생각 했습니까? 실제로 가장 효율적이고 간단한 솔루션 일 수 있습니다.

현재이 문제를 조사 중입니다. 약 1,800 만 개의 작은 파일 (약 200GB)을 전송해야합니다. 우리는 평범한 오래된 XCopy를 사용하여 최고의 성능을 달성했지만 여전히 오랜 시간이 걸렸습니다. 한 서버에서 다른 서버로 약 3 일, 외장 드라이브로 약 2 주!

다른 프로세스를 통해 서버를 복제해야했습니다. 이것은 Acronis로 수행되었습니다. 약 3 시간 걸렸다! !!

우리는 이것을 좀 더 조사 할 것입니다. 위의 dd 제안은 아마도 비슷한 결과를 제공 할 것입니다.

이미 좋은 제안이 많았지 만, Beyond Compare 를 던지고 싶었습니다 . 최근 기가비트 스위치를 통해 한 서버에서 다른 서버로 5KB와 20MB 사이에서 약 750,000 개의 파일을 전송했습니다. 전혀 딸꾹질조차하지 않았습니다. 시간이 걸렸지 만 데이터가 너무 많을 것으로 예상됩니다.

zip-> copy-> unzip의 성능을 확인했습니다

또는 좋아하는 압축 / 아카이브 시스템이 무엇이든간에.

복사하기 전에 단일 파일로 압축 한 다음 복사 한 후 다시 압축을 푸십시오.

비슷한 상황에서 tar를 사용하여 파일을 배치하려고했습니다. tar 명령의 출력을 대상 시스템으로 직접 파일을 묶는 수신 tar 프로세스로 파이프하는 작은 스크립트를 작성했습니다.

tar 방식은 scp 또는 rsync (YMMV)에 비해 전송 속도가 거의 두 배가되었습니다.

tar 명령은 다음과 같습니다. 각 머신의 홈 디렉토리에 .rhosts 파일을 생성하여 r 명령을 활성화해야합니다 (복사가 완료된 후 제거하십시오. 악명 높은 보안 문제입니다). 평소와 같이 HP-UX는 어색합니다. 다른 국가에서는 원격 쉘 명령에 'rsh'를 사용하고 HP-UX는 'remsh'를 사용합니다. 'rsh'는 HP 용어에서 일종의 제한된 쉘입니다.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

첫 번째 tar 명령은이 경우 '표준 출력'을 의미하는 특수 토큰 인 '-'라는 파일을 만듭니다. 작성된 아카이브에는 현재 디렉토리 (.)의 모든 파일과 모든 서브 디렉토리가 포함됩니다 (tar는 기본적으로 재귀적임). 이 아카이브 파일은 remsh 명령으로 파이프되어 box2 시스템으로 전송됩니다. 상자 2에서 먼저 올바른 수신 디렉토리로 변경 한 다음 수신 파일을 '-'또는 '표준 입력'에서 추출합니다.

디스크 액세스가 제한 요인이었던 것으로 생각되지만 네트워크 링크가 데이터로 가득 차도록하기 위해이 tar 명령 중 6 개를 동시에 실행했습니다.

파일 시스템을 우회하십시오.

파일이있는이 파티션을 마운트 해제하거나 읽기 전용으로 마운트 할 수 있습니까? 그런 다음 다음과 같이하십시오.

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

그런 다음 diskimage.bin대상 측에 루프백 장치 로 마운트 하여 파일을 실제 대상 파일 시스템으로 복사하거나 적절한 도구를 사용하여 대상 측의 빈 파티션으로 다시 연결 (위험하지만 가능할 수 있음) , 나는 그것을 한 적이 없다.)

정말 용기가 있다면 dd대상 쪽 파티션으로 직접 되돌릴 수 있습니다 . 나는 그것을 권장하지 않습니다.

다음을 시도해 볼 수 있습니다 (파일 배치 일 수 있음)

• 파일의 배치를 tar
• 그들을 압축
• 가능하면 scp를 사용하여 복사
• 총집
• 파일을 풀다

sth가 제안한대로 ssh를 통해 tar를 시도 할 수 있습니다.

암호화가 필요하지 않은 경우 (원래 rsync를 사용했지만 rsync + ssh라고 언급하지 않은 경우) ssh 오버 헤드를 피하기 위해 netcat를 통해 tar를 시도 할 수 있습니다.

물론 gzip 또는 다른 압축 방법을 사용하여 시간을 단축 할 수도 있습니다.

고려해야 할 다른 것이 있습니다. 이 시도:

• 동적 크기의 VHD 생성
• 가능하면 디렉토리로 마운트
• '전체 디스크 압축'속성 설정

이렇게하면 디렉토리 반복 또는 압축에 대한 오버 헤드가 발생하지 않습니다. 파일을 작성할 때 수행 되었기 때문입니다. 이동할 파일은 VHD뿐입니다.

Windows에서는 기본 TCP 패킷 크기를 16348과 같이 더 크게 설정했습니다. 이는 IP 헤더 오버 헤드가 줄어 듭니다.

그러나 내가 한 가지는 네트워크 또는 USB 전송을 위해 파일 크기를 100Mb 미만으로 유지하는 것이 가장 좋습니다. Rar.exe를 사용하여 파일을 분할합니다.

챔피언처럼 작동합니다. 이것은 리눅스에서 'dd'와 같습니다. 압축 된 파일 시스템을 디렉토리에 마운트하는 개념은 Linux에서도 일반적이므로 동일한 논리가 적용됩니다. 다른 방법과 같이 작업을 시작하기 전에 모든 파일을 닫아야합니다.

이는 폴더에 크기 할당량을 넣을 수 있다는 추가 이점이 있습니다. VHD가 고정 크기 인 경우이 제한을 초과해도 서버가 중단되지 않고 파일을 만들거나 쓰는 동안 오류가 발생합니다.

NTFS로 포맷 된 VHD는 폴더의 수백만 파일을 처리 할 수 ​​있습니다.