it-swarm-ko.tech

큰 디렉토리 트리를 로컬로 복사 하시겠습니까? cp 또는 rsync?

1.8TB 정도의 큰 디렉토리 트리를 복사해야합니다. 모두 현지입니다. 습관이 없으면 rsync를 사용 하겠지만 요점이 많고 cp를 사용해야하는지 궁금합니다.

권한과 uid/gid가 사본에 보존되어야하기 때문에 사용 권한과 UID가 걱정됩니다 (rsync 가이 작업을 수행한다는 것을 알고 있습니다). 심볼릭 링크와 같은 것들.

대상이 비어 ​​있으므로 일부 파일을 조건부로 업데이트하는 것에 대해 걱정할 필요가 없습니다. 그것은 모두 로컬 디스크이므로 ssh 또는 네트워크에 대해 걱정할 필요가 없습니다.

Rsync에서 유혹을 느끼는 이유는 rsync가 필요한 것보다 많은 것을 할 수 있기 때문입니다. rsync 체크섬 파일. 나는 그것을 필요로하지 않으며 cp보다 오래 걸릴 수 있다고 우려합니다.

rsync 또는 cp는 무엇이라고 생각하십니까?

linuxunixrsyncfile-transferfiles
244
Rory

Rsync를 사용하므로 어떤 이유로 든 중단되면 매우 적은 비용으로 쉽게 다시 시작할 수 있습니다. 그리고 rsync이기 때문에 큰 파일을 통해 부분적으로 다시 시작할 수도 있습니다. 다른 사람들이 언급했듯이 파일을 쉽게 제외시킬 수 있습니다. 대부분의 것들을 보존하는 가장 간단한 방법은 -a 플래그 –‘아카이브’따라서 :

rsync -a source dest

UID/GID 및 심볼릭 링크는 -a (보다 -lpgo), 귀하의 질문은 파일 시스템 정보의 full 사본을 원할 것임을 암시합니다. -a에는 하드 링크, 확장 된 속성 또는 ACL (Linux의 경우) 또는 위의 nor 리소스 포크 (OS X의 경우)가 포함되어 있지 않습니다. 따라서 파일 시스템의 강력한 사본의 경우 해당 플래그를 포함해야합니다.

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

기본 cp는 -u 플래그는 "SOURCE 파일이 대상 파일보다 최신이거나 대상 파일이 누락 된 경우에만 복사". 그리고 -a (아카이브) 플래그는 재귀 적이며 권한을 다시 시작하고 보존해야하는 경우 파일을 다시 복사하지 않습니다. 그래서:

cp -au source dest
214
Hamish Downer

로컬 파일 시스템으로 복사 할 때 다음 옵션과 함께 rsync를 사용하는 경향이 있습니다.

# rsync -avhW --no-compress --progress /src/ /dst/

내 추론은 다음과 같습니다.

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

다른 답변에서 제안한대로 다음 tar 명령보다 위의 rsync 설정을 사용하여 전송 속도가 17 % 빨라졌습니다.

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
120
Ellis Percival

많은 양의 데이터를 복사해야 할 때 일반적으로 tar와 rsync의 조합을 사용합니다. 첫 번째 단계는 다음과 같이 tar하는 것입니다.

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

일반적으로 많은 양의 파일을 사용하면 tar가 어떤 이유로 든 처리 할 수없는 파일이 있습니다. 또는 프로세스가 중단되거나 파일 시스템 마이그레이션 인 경우 실제 마이그레이션 단계 전에 초기 복사를 수행 할 수 있습니다. 어쨌든, 초기 복사 후, 나는 모든 것을 동기화하기 위해 rsync 단계를 수행합니다.

# cd /dst; rsync -avPHSx --delete /src/ .

/src/의 슬래시가 중요합니다.

79
Chad Huneycutt

rsync

여기에 내가 사용하는 rsync가 있습니다. 이것이 아니라 간단한 명령에 cp를 선호합니다.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

더 안전한 방법은 다음과 같습니다. cpio. 타르만큼 빠르며 조금 더 빠를 수도 있습니다.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

tar

이것도 좋고 읽기 실패로 이어집니다.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

이것들은 모두 로컬 사본 전용입니다.

14
AskApache

당신이 선호하는 것. 잊지 말고 -acp를 사용하기로 결정하면 전환합니다.

정말 대답이 필요한 경우 : rsync를 사용하면 훨씬 유연합니다. 복사가 완료되기 전에 종료해야합니까? ctrl-c 만하고 등을 돌리 자마자 다시 시작하십시오. 일부 파일을 제외해야합니까? --exclude-from. 소유권 또는 권한을 변경해야합니까? rsync가 당신을 위해 그것을 할 것입니다.

7
innaM

rsync 명령은 항상 전송하는 모든 바이트에서 체크섬을 계산합니다.

명령 행 옵션 --checksum는 파일의 체크섬을 사용하여 전송할 파일을 결정하는 데만 사용됩니다.

-c, --checksum 모드 시간 및 크기가 아닌 체크섬을 기준으로 건너 뛰기 "

맨 페이지에서도 다음과 같이 말합니다.

Rsync는 항상 전체 파일 체크섬을 확인하여 전송 된 각 파일이 수신 측에서 올바르게 재구성되었는지 확인하지만 전송 후 자동 확인은이 옵션의 전송 전 "와 관련이 없습니다. 업데이트 할?" 검사.

따라서 rsync 또한 항상 -c/ --checksum 옵션이 "꺼짐"입니다.

7
John

rsync -aPhW --protocol=28는 RSYNC를 사용하여 큰 사본의 속도를 높이는 데 도움이됩니다. 90GiB를 통해 중간에 있다는 생각 때문에 항상 rsync로 이동하고 끊기 때문에 CP에서 멀어집니다.

6
oneguynick

이 스레드는 매우 유용했으며 결과를 얻을 수있는 옵션이 너무 많았 기 때문에 그 중 몇 가지를 벤치마킹하기로 결정했습니다. 내 결과가 다른 사람들에게 도움이 될 수 있다고 생각합니다.

1,753,200 파일 사이에 분산 된 데이터의 532Gb 를 이동하려면 다음과 같은 시간을 가졌습니다.

  • rsync는 232 분이 걸렸습니다
  • tar 소요 206 분
  • cpio 소요 225 분
  • rsync + parallel 209 분 소요

제 경우에는 rsync + parallel. 이 정보가 더 많은 사람들이 이러한 대안 중에서 결정하는 데 도움이되기를 바랍니다.

전체 벤치 마크가 게시됩니다 here

6
arjones

rsync는 훌륭하지만 트리를 메모리에 저장하기 때문에 실제로 큰 디렉토리 트리에 문제가 있습니다. 나는이 스레드를 발견했을 때 그들이이 문제를 해결할 수 있는지보고 싶었습니다.

나는 또한 발견했다 :

http://matthew.mceachen.us/geek/gigasync/

트리를 수동으로 분리하고 여러 rsync를 실행할 수도 있습니다.

5
n3bulous

로컬 로컬 디렉토리 복사를 수행 할 때 "cp -van src dest"가 rsync보다 20 % 빠릅니다. 재시작 가능성까지는 "-n"이하는 것입니다. 부분적으로 복사 된 파일 만 rm하면됩니다. ISO 또는 그와 같은 것이 아니면 고통스럽지 않습니다.

3
Ron

ARJ IS SO OLD SCHOOL !!) ARJ 및/또는 rsync가 성능을 제공 할 것 같지는 않습니다.

확실히 내가 항상하는 일은 cpio를 사용하는 것입니다.

find . -print | cpio -pdm /target/folder

이것은 CP보다 거의 빠르며, tar보다 빠르며 파이프가 없습니다.

2
Gonzalo Gorosito

rclone 시도해보십시오. 이건 미친 짓이야

Sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

LITEONIT LCS-256 (256GB) SSD와 로컬 복사본입니다.

--ignore-checksum 더 빨리 만들기 위해 첫 번째 실행에서.

1
Frédéric N.

둘 다 잘 작동합니다.

0
pauska

rsync에 적용 할 수있는 몇 가지 속도 향상이 있습니다.

기피

  • -z/--compress : 전송은 네트워크가 아닌 RAM을 통해 전송되므로 CPU 만로드됩니다.
  • --append-verify : 중단 된 전송을 재개합니다. 이것은 좋은 생각처럼 들리지만 위험한 실패 사례가 있습니다. 소스와 크기가 같거나 큰 대상 파일은 무시됩니다. 또한 마지막에 전체 파일을 체크섬하므로 --no-whole-file 위험한 실패 사례를 추가하는 중입니다.

사용하다

  • -S/--sparse : null 시퀀스를 희소 블록으로 변환
  • --partial 또는 -P--partial --progress : 나중에 다시 시작하기 위해 부분적으로 전송 된 파일을 저장하십시오. 참고 : 파일 이름은 임시 이름이 아니므로 전체 사본이 완료 될 때까지 대상을 사용할 것으로 예상되지 않도록하십시오.
  • --no-whole-file 재전송해야하는 것은 델타 전송을 사용합니다. 부분적으로 전송 된 파일의 절반을 읽는 것이 다시 쓰는 것보다 훨씬 빠릅니다.
  • --inplace 파일 복사 방지 (전체 전송이 완료 될 때까지 대상을 읽는 것이없는 경우에만)
0
Tom Hale

tar도 작업을 수행하지만 rsync처럼 중단되지 않습니다.

0
pgs

ARJ를 사용하면 어떻게 되나요?

arj a -jm -m1 -r -je filepack /source

어디 -jm -m1는 압축 수준이며 -je는이를 실행 파일로 만듭니다. 이제 파일의 캡슐화 된 bash가 있습니다.

그런 다음 대상 맵으로 추출

filepack -y

소스 맵이 만들어지는 위치 (여기서 -y 항상 수락, 덮어 쓰기, 건너 뛰기 등)

그런 다음 파일 팩을 대상 영역으로 scp ftp하여 가능한 경우 실행할 수 있습니다.

0
herauthon