두 컴퓨터간에 대량의 데이터를 보내는 가장 빠른 방법은 무엇입니까? [닫은]

이것은 내가 자주하는 상황입니다.

• 내부에 320GB 하드 드라이브와 16GB 램 ( 정확한 사양은 여기 에 나와 있지만 소스 는 다른 시스템에서도 자주 발생하는 문제이므로 모든 시스템에서 작동하는 응답을 선호합니다) "합리적인"리눅스 머신)
• 몇 테라 바이트의 하드 드라이브 공간이있는 백업 서버가 있습니다 ( 정확한 사양 은 위의 면책 조항 참조).

320GB의 데이터를 소스 서버에서 대상 서버로 (특히,의 데이터 /dev/sda) 전송하고 싶습니다 .

1. 두 컴퓨터는 물리적으로 나란히 있으므로 케이블을 서로 연결할 수 있습니다.
2. LAN에 있고 새로운 라우터 를 사용하고 있습니다. 즉, 네트워크 속도가 "이상적으로"1000Mbit 여야합니다.
3. 보안은 문제가되지 않습니다. 로컬 네트워크에 있고 라우터를 포함하여 네트워크의 모든 시스템을 신뢰 합니다.
4. (선택 사항) 필자는 반드시 데이터의 서명 된 체크섬이 필요하지는 않지만 출력에서 ​​사라지기보다는 기본 오류 검사 (예 : 패킷 손실 또는 드라이브를 읽을 수 없게 됨)를 감지해야합니다.

이 질문을 온라인으로 검색하고 여러 명령을 테스트했습니다. 가장 자주 나타나는 것은 다음과 같습니다.

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

이 명령은 너무 느리다는 것이 입증되었습니다 (1 시간 동안 실행되었으며 데이터를 통해 약 80GB 만 사용). 1GB 테스트 패킷의 경우 약 1 분 22 초가 걸렸으며 압축하지 않으면 두 배 빠릅니다. 전송 된 파일이 소스 시스템의 RAM 용량보다 작기 때문에 결과가 왜곡 될 수 있습니다.

또한 (그리고 이것은 1GB 테스트 조각에서 테스트되었습니다), gzip명령을 사용하면 문제가 발생합니다 dd. 결과 파일은 대상에서 추출 될 때 직접 파이프 된 경우와 다른 체크섬을 갖습니다. 나는 왜 이것이 일어나고 있는지 알아 내려고 노력하고 있습니다.

서버가 물리적으로 나란히 있고 주석에 물리적 액세스 권한이 있다고 언급 했으므로 가장 빠른 방법은 첫 번째 컴퓨터에서 하드 드라이브를 꺼내고 두 번째 컴퓨터에 놓고 파일을 전송하는 것입니다. SATA 연결을 통해.

netcat 보안이 문제가되지 않는 이와 같은 상황에 적합합니다.

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

ddGNU coreutils에서 사용 SIGUSR1하는 경우 프로세스로 보내면 stderr로 진행됩니다. BSD의 경우을 dd사용하십시오 SIGINFO.

pv 는 복사 중 진행 상황을보고하는 데 더욱 도움이됩니다.

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. 마십시오 사용 빠른 압축을.

   • 전송 매체 (특히 네트워크 또는 USB 용)가 무엇이든간에 읽기, 캐시 및 쓰기를위한 데이터 버스트 를 사용하게되므로 정확하게 동기화되지는 않습니다.
   • 당신은 또한 당 교환되는 데이터의 양에 집중하기 위해 어떤 방법으로 시스템 'CPU를 채택 할 경우 디스크 펌웨어, 디스크 캐시, 커널 / 램 캐시 외에, 버스트를 당신은 그렇게해야합니다 .
   • 압축 알고리즘은 가능한 한 빨리 스파 스 입력을 자동으로 처리하지만 나머지 네트워크 처리량에서 나머지를 처리 ​​할 수있는 것은 거의 없습니다.
   • lz4 가장 좋은 옵션은 다음과 같습니다.

     LZ4는 매우 빠른 무손실 압축 알고리즘으로 멀티 코어 CPU로 확장 가능한 코어 당 400MB / s의 압축 속도를 제공합니다. 또한 코어 당 여러 GB / s의 속도로 매우 빠른 디코더가 특징이며, 일반적으로 멀티 코어 시스템에서 RAM 속도 제한에 도달합니다.

2. 바람직하게는 않습니다 하지 불필요하게 추구하고 있습니다.

   • 측정하기 어려울 수 있습니다.

   • 복사 한 장치에 사용 가능한 공간이 많고 최근에 장치를 0으로 설정하지 않았지만 모든 소스 파일 시스템을 복사해야하는 경우, 먼저해야 할 가치가 있습니다. 같은 :

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • 그러나 그것은 당신이 소스를 읽는 수준에 달려 있습니다. /dev/some_disk파일 시스템 수준에서 읽는 것은 일반적으로 비 순차적으로 디스크를 앞뒤로 탐색하기 때문에 장치 파일 에서 처음부터 끝까지 장치를 읽는 것이 바람직합니다 . 따라서 읽기 명령은 다음과 같아야합니다.

     </dev/source_device lz4 | ...

   • 그러나 소스 파일 시스템을 전체적으로 전송하지 않으면 파일 시스템 수준에서 읽는 것은 피할 수 없으므로 입력 내용을 스트림으로 묶어야합니다. pax이 경우 일반적으로 가장 좋고 가장 간단한 솔루션이지만 고려할 수도 있습니다 mksquashfs.

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. 마십시오 하지 와 암호화 ssh.

   • 신뢰할 수있는 매체에 암호화 오버 헤드를 추가하는 것은 불필요 하며, 데이터 읽기가 두 번 읽혀 져야한다는 지속적인 전송 속도에 크게 해가 될 수 있습니다 .
   • PRNG는 판독 데이터를 필요로하거나, 적어도 일부는 무작위성을 유지.
   • 물론 데이터도 전송해야합니다.
   • 또한 암호화 오버 헤드 자체를 전송해야하므로 버스트 당 전송되는 데이터가 적을수록 더 많은 작업을 수행 할 수 있습니다.

   • 따라서 다른 곳에서 제안한 것처럼 간단한 네트워크 사본에 netcat( 또는 선호하는대로 nmap프로젝트의 기능이 더ncat 좋습니다) 사용해야합니다 .

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

전송 속도를 제한 할 수있는 몇 가지 제한 사항이 있습니다.

1. 1Gbps 파이프에는 고유 한 네트워크 오버 헤드가 있습니다. 일반적으로 ACTUAL 처리량을 900Mbps 이하로 줄입니다. 그런 다음이 트래픽은 양방향 트래픽이므로 900Mbps 미만의 다운이 예상됩니다.

2. "새로운 라우터"를 사용하더라도 라우터가 1Gbps를 지원한다고 확신하십니까? 모든 새 라우터가 1Gbps를 지원하는 것은 아닙니다. 또한 엔터프라이즈 급 라우터가 아닌 경우 비효율적 인 라우터의 추가 전송 대역폭이 손실 될 수 있습니다. 아래에서 찾은 것을 기반으로하지만 100Mbps 이상인 것처럼 보입니다.

3. 네트워크를 공유하는 다른 장치에서 네트워크 정체가 발생할 수 있습니다. 할 수 있다고 말한대로 직접 연결된 케이블을 사용해 보셨습니까?

4. 어느 정도의 디스크 IO를 사용하고 있습니까? 아마 당신은 네트워크가 아니라 디스크 드라이브에 의해 제한을 받고있을 것입니다. 대부분의 7200rpm HDD는 약 40MB / s에 불과합니다. 당신은 전혀 습격을 사용하고 있습니까? SSD를 사용하고 있습니까? 원격 쪽에서 무엇을 사용하고 있습니까?

백업을 위해 재실행 될 것으로 예상되는 경우 rsync를 사용하는 것이 좋습니다. ssh / http / https / ftp 연결을 병렬화하기 때문에 filezilla와 같은 다운로더를 사용하여 scp, ftp (s) 또는 http를 사용할 수도 있습니다. 다른 솔루션이 단일 파이프를 통해 이루어 지므로 대역폭이 증가 할 수 있습니다. 단일 파이프 / 스레드는 여전히 단일 스레드라는 사실에 의해 제한되며 이는 CPU에 바인딩 될 수도 있습니다.

rsync를 사용하면 압축, 권한 보존 및 부분 전송을 허용 할뿐만 아니라 솔루션의 복잡성을 상당 부분 제거 할 수 있습니다. 몇 가지 다른 이유가 있지만 일반적으로 대기업에서 선호하는 백업 방법 (또는 백업 시스템 실행)입니다. Commvault는 실제로 소프트웨어 아래에서 rsync를 백업 전달 메커니즘으로 사용합니다.

주어진 80GB / h의 예에 따르면 약 177Mbps (22.2MB / s)가됩니다. 기가비트에서 rsync를 사용하여 자체 테스트에서이를 얻을 수 있었으므로 두 상자 사이의 전용 이더넷 회선에서 rsync로 이것을 쉽게 두 배로 늘릴 수 있다고 생각합니다.

우리는 이것을 정기적으로 처리합니다.

우리가 사용하는 두 가지 주요 방법은 다음과 같습니다.

1. SATA / eSATA / 스니커 넷
2. 직접 NFS 마운트, 로컬 cp또는rsync

첫 번째는 드라이브를 물리적으로 재배치 할 수 있는지 여부에 따라 다릅니다. 항상 그런 것은 아닙니다.

두 번째는 놀랍게 잘 작동합니다. 일반적으로 직접 NFS 마운트를 사용하면 1GBps 연결을 쉽게 얻을 수 있습니다. scp, dd over ssh 또는 이와 유사한 것을 사용하면 이와 가까운 곳을 얻을 수 없습니다 (종종 100mpbs에 가까운 최대 속도를 얻습니다). 매우 빠른 멀티 코어 프로세서에서도 두 머신 중 가장 느린 코어 중 하나의 최대 암호화 처리량에 병목 현상이 발생합니다. 이는 암호화되지 않은 네트워크 마운트의 풀 보어 cp 또는 rsync에 비해 매우 느립니다. 때때로 당신은 잠시에 대한 IOPS 벽에 부딪 힐 것입니다 주위에 붙어 ~ 53메가바이트 / 대신 전형적인 ~ 110메가바이트 / s의 s의,하지만 소스 또는 대상이 아닌 경우 즉, 일반적으로 짧은 살고있다 실제로단일 드라이브 인 경우 드라이브 자체의 지속 속도에 의해 제한을받을 수 있습니다 (실제로 시도하기 전까지 알 수없는 임의의 이유로 충분히 달라질 수 있음)-meh.

NFS는 익숙하지 않은 배포판에 설치하는 경우 약간 성가 시게 할 수 있지만 일반적으로 파이프를 가능한 한 완전히 채우는 가장 빠른 방법이었습니다. 마지막으로 10gbps 이상을 수행했을 때 커피를 가져 오기 전에 다시 전송이 완료 되었기 때문에 연결이 최대치인지 실제로 알지 못했습니다. 소스와 대상 사이에 몇 개의 네트워크 장치가있는 경우 네트워크 연결 효과로 인해 약간의 지연 또는 장애가 발생할 수 있지만 일반적으로 사무실 전체 (다른 트래픽을 처리하는 다른 장치) 또는 데이터 센터의 한쪽 끝에서 다른 (내부에서 어떤 종류의 필터링 / 검사가 발생하지 않는 한, 모든 베팅은 꺼져 있습니다 ).

편집하다

압축에 관한 대화가 나타났습니다 ... 연결을 압축 하지 마십시오 . 암호화 계층과 같은 방식으로 속도가 느려집니다. 연결을 압축하면 병목 현상은 항상 단일 코어가됩니다 (특히 해당 코어 버스의 활용도는 높지 않음). 가장 느린 작업은 1GBps 이상의 연결에서 서로 옆에 앉아있는 두 컴퓨터간에 암호화 된 압축 채널을 사용하는 것입니다.

미래 교정

이 조언은 2015 년 중반을 기준으로합니다. 이것은 너무 많은 시간 동안 거의 그렇지 않을 것입니다. 따라서 소금 한 덩어리로 모든 것을 가져 가십시오.이 작업을 정기적으로 마주 치면 상상하는 대신 실제 하중 에 대해 다양한 방법을 시도하십시오. 이론적 인 이론에 가장 가까운 것이거나 웹과 같은 것들에 전형적인 압축 / 암호 처리량 비율을 관찰 할 수 있습니다. 트래픽, 많은 (텍스트 protip로되어있는 벌크 전송은 보통 등의 이미지, 오디오, 비디오, 데이터베이스 파일, 이진 코드, 오피스 파일 형식의 주로 구성되어 이미 압축을압축 블록 크기는 이미 압축 된 이진 데이터와 정렬되지 않습니다.)

미래에는 SCTP와 같은 개념이 결합 된 연결 (또는 내부적으로 결합 된 스펙트럼 별 채널 화 된 파이버 연결)이 일반적이고 각 채널이 다른 채널과 독립적 인 스트림을 수신 할 수있는보다 흥미로운 장소로 옮겨 갈 것이라고 생각합니다. 스트림 등을 병렬로 압축 / 암호화 할 수 있습니다. 그러나 2015 년 현재는 그렇지 않으며, 환상과 이론화는 훌륭하지만 대부분 크라이 오 챔버에서 실행되는 맞춤형 스토리지 클러스터는 Watson에 대한 Blue Gene / Q 내부 응답에 직접 데이터를 공급하지 않습니다. 그것은 현실이 아닙니다. 압축이 좋은 아이디어인지 아닌지를 파악하기 위해 데이터 페이로드를 철저히 분석 할 시간도 없습니다. 분석을 마치기 전에 전송 자체가 끝날 것입니다.

그러나...

시간이 바뀌고 압축 및 암호화에 대한 권장 사항이 적용되지 않습니다. 나는이 조언이 전형적인 경우에 뒤집 히기를 정말로 좋아합니다 . 내 인생이 더 쉬워 질 것입니다.

과거에 사용한 멋진 도구는 bbcp입니다. 바와 같이 여기에 본 : https://www.slac.stanford.edu/~abh/bbcp/ .

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm 참조

이 도구를 사용하면 전송 속도가 매우 빠릅니다.

당신이 어떻게 든 (전선 / 운동화 / 무엇이든간에) 첫 번째 패스를 얻는다면 rsync후속 전송 속도를 크게 높일 수있는 특정 옵션을 살펴볼 수 있습니다. 가장 좋은 방법은 다음과 같습니다.

rsync -varzP sourceFiles destination

옵션은 상세, 보관 모드, 재귀, 압축, 부분 진행입니다.

zackse의 답변에 대한 의견에서 원래 포스터의 주장에 추가되었지만 일반적인 상황 에서는 가장 빠르지 는 않습니다 .

bash특수한 재 지정 구문이 있습니다.
출력의 경우 :      > /dev/tcp/ IP  / 포트
입력의 경우 :       < /dev/tcp/ IP  / 포트
IP 금지는 점 분리 십진 IP 또는 호스트 이름입니다. 포트 금지는 10 진수 또는 포트 이름입니다 /etc/services.

실제 /dev/tcp/디렉토리 가 없습니다 . bashTCP 소켓을 만들고 지정된 대상에 연결 한 다음 일반적인 파일 리디렉션과 동일한 작업을 수행하는 명령 (즉, dup2 (2)을 사용하여 각 표준 스트림을 소켓으로 교체) 하는 특수 구문 kludge입니다 .

따라서 TCP를 통해 직접 소스 머신 에서 dd또는 tar소스 머신으로 데이터를 스트리밍 할 수 있습니다 . 또는 반대로 tarTCP를 통해 직접 또는 이와 유사한 방식으로 데이터를 스트리밍 할 수 있습니다. 어쨌든 하나의 불필요한 netcat이 제거됩니다.

netcat에 대한 참고 사항

이 고전적인 netcat을하고 GNU netcat을 사이 구문의 불일치 . 익숙한 고전적인 구문을 사용하겠습니다. 교체 -lp와 -lGNU netcat을합니다.

또한 GNU netcat이 -q스위치를 허용하는지 확실하지 않습니다 .

디스크 이미지 전송

(. zackse의 대답의 라인을 따라)
대상에서 :

nc -lp 9999 >disk_image

소스에서 :

dd if=/dev/sda >/dev/tcp/destination/9999
 

다음을 사용하여 tar.gz 아카이브 작성 tar

목적지에서 :

nc -lp 9999 >backup.tgz

소스에서 :

tar cz files or directories to be transferred >/dev/tcp/destination/9999

교체 .tgz로 .tbz와 cz함께 cj얻을 bzip2- 압축 아카이브.

파일 시스템으로 즉시 확장하여 전송

또한 tar.
목적지에서 :

cd backups
tar x </dev/tcp/destination/9999

소스에서 :

tar c files or directories to be transferred |nc -q 1 -lp 9999

없이 작동 -q 1하지만 데이터가 끝나면 netcat이 중단됩니다. 의 구문과주의 사항에 대한 설명은 tar (1)를 참조하십시오 tar. 이 높은 중복 (낮은 엔트로피), 다음 압축 파일 수 있습니다 (예. g. 경우 cz와 xz대신 c과 x) 시도 할 수 있지만 파일은 일반적인 네트워크가 충분히 빠른 경우, 그것은 단지 과정을 느리게합니다. 압축에 대한 자세한 내용은 mikeserv의 답변을 참조하십시오.

대체 스타일 (대상이 포트를 청취 함)

목적지에서 :

cd backups
nc -lp 9999 |tar x

소스에서 :

tar c files or directories to be transferred >/dev/tcp/destination/9999

직접 연결에 관한 제안을 시도하고 ssh와 같은 암호화 된 프로토콜을 피하십시오. 그런 다음 모든 성능을 유지 하려면 TCP 창 최적화에 대한 조언을 얻으려면 이 사이트에 https://fasterdata.es.net/host-tuning/linux/ 를 읽어보십시오 .

필자가 작성한 이 스크립트를 사용 하여 socat패키지 가 필요합니다 .

소스 머신에서 :

tarnet -d wherefilesaretosend pass=none 12345 .

대상 머신에서 :

tarnet -d wherefilesaretogo pass=none sourceip/12345

는 IF vbuf패키지 (데비안, 우분투)가 다음 파일을 보낸 사람은 데이터 진행 상황을 보여줍니다. 파일 수신자는 수신 된 파일을 보여줍니다. pass = 옵션은 데이터가 노출 될 수있는 곳에서 더 느리게 사용될 수 있습니다.

편집하다:

-nCPU가 병목 상태 인 경우 압축을 비활성화 하려면이 옵션을 사용 하십시오 .

예산이 주요 관심사가 아닌 경우 Intel Xeon E5 12 코어 "드라이브 커넥터"로 드라이브를 연결해보십시오. 이 커넥터는 일반적으로 매우 강력하여 현재 서버 소프트웨어를 실행할 수도 있습니다. 두 서버에서!

이것은 재미있는 대답처럼 보일지 모르지만 서버간에 데이터를 이동하는 이유와 공유 메모리 및 스토리지가있는 큰 서버가 더 의미가있는 경우 실제로 고려해야합니다.

현재 사양에 대해서는 잘 모르지만 느린 전송은 네트워크가 아닌 디스크 속도에 의해 제한 될 수 있습니까?

하드 드라이브의 바이트 사본에 대한 바이트가 아닌 백업에만 관심이 있다면 backupPC를 권장합니다. http://backuppc.sourceforge.net/faq/BackupPC.html 설정하기가 약간 힘들지만 매우 빠르게 전송됩니다.

약 500G의 데이터에 대한 초기 전송 시간은 약 3 시간이었습니다. 후속 백업은 약 20 초 후에 발생합니다.

백업에 관심이 없지만 동기화하려는 경우 rsync 또는 unison이 필요에 더 잘 맞습니다.

하드 디스크의 바이트 사본 용 바이트는 일반적으로 백업 목적으로 끔찍한 아이디어입니다 (증분 없음, 공간 절약 없음, 드라이브를 사용할 수 없음, "빈 공간"을 백업해야하며 가비지를 백업해야합니다. (16G 스왑 파일 또는 200G의 코어 덤프 또는 이와 유사한 것 등) rsync (또는 backuppc 또는 기타)를 사용하여 "스냅 샷"을 제 시간에 만들 수 있으므로 "파일 시스템이 30 분 전의 모습"으로 이동할 수 있습니다. 오버 헤드가 거의 없습니다.

즉, 바이트 복사를 위해 바이트를 실제로 전송하려는 경우 드라이브에서 데이터를 가져 오는 것이 아니라 전송에 문제가 있습니다. 400G의 RAM이 없으면 320G 파일 전송에 시간이 오래 걸립니다. 암호화되지 않은 프로토콜을 사용하는 것은 선택 사항이지만, 무엇이든 관계없이 네트워크를 통해 몇 시간 동안 기다려야합니다.

프로그램에 관계없이 일반적으로 네트워크를 통한 "풀링"파일이 "푸시"보다 빠릅니다. 즉, 대상 컴퓨터에 로그인하여 읽기를 수행하는 것이 원본 컴퓨터에 로그인하여 쓰는 것보다 빠릅니다.

또한 중간 드라이브를 사용하려는 경우 다음 사항을 고려하십시오. USB 대신 eSATA를 사용하는 외장 드라이브 (패키지 또는 도킹 스테이션에 연결된 별도 드라이브)를 가져옵니다. 그런 다음 두 컴퓨터 각각에 eSATA 포트가있는 카드를 설치하거나 내부 SATA 포트 중 하나를 외부 eSATA 커넥터로 가져 오는 간단한 어댑터 케이블을 얻습니다. 그런 다음 드라이브를 소스 컴퓨터에 꽂고 드라이브의 전원을 켜고 자동 마운트 될 때까지 기다리십시오 (수동으로 마운트 할 수 있지만이 작업을 반복적으로 수행하는 경우 fstab 파일에 넣을 수도 있습니다). 그런 다음 복사하십시오. 내장 드라이브와 같은 속도로 글을 쓸 것입니다. 그런 다음 드라이브를 마운트 해제하고 전원을 끄고 다른 컴퓨터에 연결 한 다음 전원을 켜고 자동 마운트를 기다렸다가 읽습니다.

NIC 팀을 살펴 보는 것이 좋습니다. 병렬로 실행되는 여러 네트워크 연결을 사용합니다. 실제로 1Gb 이상의 전송이 필요하고 10Gb가 비용이 많이 든다고 가정하면 NIC 팀에서 제공하는 2Gb는 약간의 비용이 들며 컴퓨터에 이미 추가 포트가있을 수 있습니다.

FWIW, 나는 항상 이것을 사용했습니다 :

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

이 방법에 대한 것은 컴퓨터간에 파일 / 폴더 권한을 유지한다는 것입니다 (동일한 사용자 / 그룹이 둘 다 있다고 가정). (또한 -S 매개 변수를 사용하여 스파 스 파일을 처리 할 수 ​​있기 때문에 가상 디스크 이미지를 복사하기 위해이 작업을 수행합니다. )

두 대의 바쁜 서버 사이에서 이것을 테스트하고 216 대 (약 64MB / s)에서 최대 14GB를 관리했습니다. 전용 컴퓨터와 압축 사이에 더 좋을 것입니다.

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

파일 시스템 포렌식을 수행하지 않으려면 파일 시스템에 덤프 / 복원 프로그램을 사용하여 FS에서 사용하지 않는 여유 공간을 복사하지 마십시오. 사용중인 파일 시스템에 따라 일반적으로을 포함한 모든 메타 데이터가 유지 됩니다ctime . 그러나 inode 번호는 파일 시스템 (xfs, ext4, ufs ...)에 따라 다시 변경 될 수 있습니다.

복원 대상은 대상 시스템의 파일 일 수 있습니다.

파티션 테이블이있는 전체 디스크 이미지를 원할 경우 디스크 dd의 첫 1M은 파티션 테이블 / 부트 로더 / 물건을 가져온 다음 파티션을 가져올 수 xfsdump있습니다.

나는 정보 덤프에서 실제로 어떤 종류의 파일 시스템을 가지고 있는지 알 수 없습니다. BSD ufs라면 덤프 / 복원 프로그램이 있다고 생각합니다. ZFS, IDK라면 뭔가있을 수 있습니다.

일반적으로 전체 복사 디스크는 복구 상황을 제외하고는 너무 느립니다. 그런 식으로 증분 백업을 수행 할 수도 없습니다.

공유 스토리지를 갖도록 시스템을 설정할 수도 있습니다!

나는 이것들이 서로 옆에 있다고 생각하고 있으며, 당신은 이것을 다시 반복 할 것입니다 ....

이더넷 크로스 오버 케이블은 어떻습니까? 무선 속도에 의존하는 대신 NIC의 유선 속도로 제한됩니다.

이러한 종류의 솔루션에 대한 몇 가지 예와 비슷한 질문이 있습니다.

오늘날 일반적인 이더넷 케이블만으로도 충분할 것입니다. NIC가 좋을수록 전송 속도가 빨라집니다.

요약하면, 네트워크 설정이 필요한 경우 서브넷 마스크 255.255.255.0으로 서버 및 백업 컴퓨터에 고정 IP를 설정하는 것만으로 제한해야합니다.

행운을 빕니다!

편집하다:

@Khrystoph는 그의 대답에서 이것을 만졌습니다.

암호화를 사용하면 속도가 느려지므로 ssh를 건너 뛰는 것이 좋습니다. 최신 CPU는 실제로 1Gb에서 충분히 빠를 수 있지만 OpenSSH에는 내부 윈도우 구현에 문제가있어 속도가 크게 느려질 수 있습니다.

ssh로이 작업을 수행하려면 HPN SSH를 살펴보십시오 . 창 문제를 해결하고 멀티 스레드 암호화를 추가합니다. 불행히도 클라이언트와 서버 모두에서 ssh를 다시 빌드해야합니다.

OK 나는 "매우 큰 파이프"(10Gbe)를 가진 두 대의 컴퓨터에 대해이 질문에 대답하려고했습니다.

여기서 문제는 파이프가 너무 커서 대부분의 압축이 CPU에서 병목 현상을 일으키는 것입니다.

10GB 파일 전송 성능 (6Gb 네트워크 연결 [linode], 압축 할 수없는 데이터) :

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

그리고 10Gbe의 두 개의 상자, 약간 오래된 버전의 netcat (CentOs 6.7), 10GB 파일 :

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

따라서 하나의 인스턴스에서 netcat은 CPU를 덜 사용하고 다른 socat에서는 YMMV를 사용했습니다.

netcat을 사용하면 "-N -q 0"옵션이 없으면 잘린 파일을 전송할 수 있습니다. "-w 10"과 같은 다른 옵션도 잘린 파일을 생성 할 수 있습니다.

거의 모든 경우에 발생하는 일은 네트워크가 아니라 CPU가 최대치입니다. scp약 230MB / s로 최대 한도에서 100 % 활용률로 한 코어를 페깅합니다.

불행히도 Iperf3는 손상된 파일을 만듭니다 . netcat의 일부 버전은 전체 파일을 전송하지 않는 것 같습니다. 특히 오래된 버전.

"netcat에 대한 파이프로서 gzip"또는 "mbuffer"의 다양한 주문도 gzip 또는 mbuffer를 사용하여 CPU를 최대로 사용하는 것처럼 보였으므로 이러한 큰 파이프로 더 빠른 전송을 수행하지 못했습니다. lz4가 도움이 될 수 있습니다. 또한 내가 시도한 gzip 파이프 항목 중 일부는 매우 큰 (> 4GB) 파일에 대한 전송이 손상되었으므로 조심하십시오. :)

특히 대기 시간이 길어질 수있는 또 다른 이유는 TCP 설정을 조정하는 것입니다. 제안 된 값을 언급하는 가이드는 다음과 같습니다.

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm 및 https://fasterdata.es.net/host-tuning/linux/ (다른 답변에서) IRQ 설정 가능 : https://fasterdata.es .net / host-tuning / 100g-tuning /

linode의 제안은 /etc/sysctl.conf에 추가하십시오.

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

또한, 그들은 당신이 실행하기를 원합니다 :

 /sbin/ifconfig eth0 txqueuelen 10000 

변경 후에도 해를 입히지 않도록 조정 한 후 다시 확인해야합니다.

창 크기를 조정할 가치가있을 수도 있습니다 : https://iperf.fr/iperf-doc.php#tuningtcp

느린 연결을 사용하면 압축이 확실히 도움이 될 수 있습니다. 파이프가 큰 경우 압축 속도 가 매우 빠르면 데이터를 쉽게 압축 할 수 있지만 시도하지 않았습니다.

"하드 드라이브 동기화"에 대한 표준 답변은 파일을 재 동기화하여 가능한 경우 전송을 피하는 것입니다.

또 다른 옵션 : "병렬 scp"(어떻게 든 또는 다른 방식)를 사용하면 더 많은 코어를 사용합니다 ...