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

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

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

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

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

그래서 당신은 무엇을 생각한다, 할 rsync나 cp?

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

rsync -a source dest

UID / GID 및 심볼릭 링크는 -a( -lpgo)에 의해 보존되지만 질문 은 파일 시스템 정보 의 전체 사본을 원할 수 있음을 암시합니다 . 와 -a하드 링크, 확장 속성, 또는 (리눅스)의 ACL 또는 이상 포함되지 않습니다 않으며 따라서 (OS X의에) 리소스 포크를, 파일 시스템의 강력한 사본을, 당신은 그 플래그를 포함해야합니다 :

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

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

cp -au source dest

로컬 파일 시스템으로 복사 할 때 항상 다음 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 -)

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

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

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

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

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

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 --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

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

당신이 선호하는 것. -a사용하기로 결정할 때 스위치를 잊지 마십시오 cp.

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

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

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

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

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

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

그래서 rsync또한, 항상 경우에도, 수신 측에 전체 파일의 체크섬을 계산 -c/ --checksum옵션은 "OFF"입니다.

rsync -aPhW --protocol=28RSYNC로 이러한 대용량 사본의 속도를 높이는 데 도움이됩니다. 90GiB를 통해 중간에 있다는 생각 때문에 항상 rsync를 사용합니다.

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

나는 또한 발견했다 :

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

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

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

1,753,200 개의 파일에 분산 된 532Gb 의 데이터 를 이동시키기 위해 다음 과 같은 시간을 가졌습니다.

• rsync 232 분이 걸렸다
• tar 206 분 걸렸다
• cpio 225 분이 걸렸다
• rsync + parallel 209 분 걸렸다

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

전체 벤치 마크는 여기 에 게시 됩니다

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

ARJ는 너무 오래된 학교입니다! ARJ 및 / 또는 rsync가 성능을 제공 할 것이라고 의심합니다.

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

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

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

당신은 확실히 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첫 번째 런을 추가 하여 더 빠르게 만들 수 있습니다 .

둘 다 잘 작동합니다.

tar 또한 작업을 수행하지만 rsync처럼 중단되는 것을 재개하지 않습니다.

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

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

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

그런 다음 대상 맵으로 추출

filepack -y  

소스 맵이 만들어 질 곳 -y(항상 수락, 덮어 쓰기, 건너 뛰기 등)

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

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

기피

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

사용하다

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