현재 시스템의 백업 성능을 향상시킬 수 있는 방법을 찾고 있으며 일부 테스트에서 다음과 같은 결과를 얻었습니다.
압축되지 않은 TAR을 사용하여 Ubuntu 시스템을 SSD에서 HDD(ext4 모두)로 백업하는 것은 동일한 콘텐츠를 SSD에서 HDD로 동기화하는 것보다 훨씬 빠릅니다.
상세히:
TAR1h 15min429G의 대용량 파일 획득 및 생성rsync5h큰 406G 폴더를 촬영 하고 생성하세요
두 도구 모두에서 사용하는 무시 파일의 내용이 동일하고 두 도구에 대해 약간 조정되었으므로 동일한 데이터를 복사해야 합니다.
최종 TAR이 실제로 rsynced 폴더보다 큰 이유는 잘 모르겠지만 ATM에는 별로 관심이 없습니다.
내가 정말 관심 있는 건TAR이 왜 그렇게 빠른가요?& 내가 할 수 있다면어떤 방식으로든 rsync를 개선하세요.(또는 다른 파일 복사 도구) 비슷한 성능을 얻으려면?
저는 TAR를 백업 전략으로 사용하고 싶지 않습니다. 이렇게 큰 아카이브의 압축을 풀거나 단일 파일을 추출하는 데 "오랜 시간"이 걸리고 실제로 액세스해야 할 때 문제가 될 수 있기 때문입니다.
항상 동일한 대상 폴더에 복사하면 rsync 성능이 크게 향상될 수 있다는 것을 깨달았습니다.증분 복사하지만 분명해내가 찾고 있는 게 아니야왜냐하면 항상 다른 날짜의 여러 백업을 갖고 싶기 때문입니다.
업데이트, 추가 정보
대안 "TAR을 통한 복사" 테스트
나는 또한 "TAR을 통해 복사"를 시도했습니다.여기또는여기)은 rsync보다 조금 느리기 때문에 병목 현상은 쓰기 속도인 것 같습니다.
사용된 명령
위의 결과를 얻기 위해 다음 명령을 사용했습니다.
tar -X "tar-excludes.txt" -cvf "/media/backup/full" "/"rsync -aAXWvh --stats --info=progress2 --exclude-from "rsync-excludes.txt" --log-file="log.txt" "/" "/media/backup/full"
문서
전체 운영 체제(일부 예외 포함)를 백업하므로 백업에는 모든 유형의 파일이 포함됩니다. 일부 큰 파일과 많은 작은 파일.
장치 세부정보
호스트는 Intel NUC D34010WYKH ~8년 된 제품입니다.
원본 드라이브는 내부 SSD이고 대상 드라이브는 USB 3.0을 통해 연결된 외부 HDD입니다. 두 드라이브가 모두 사용됩니다 ext4.
답변1
다양한 cpio 및 tar 파일 형식은 파일 헤더와 파일 데이터의 간단한 순서입니다. 새 파일 헤더를 작성하면 레코드가 출력 파일에 추가됩니다. 파일 데이터를 작성하면 출력 파일에 더 많은 레코드가 추가됩니다.
이것이 일어나는 유일한 일입니다. 레코드가 출력 파일에 추가됩니다. 종종 이러한 레코드는 10KiB 또는 5KiB(경우에 따라 1MiB) 청크로 일괄 처리되기도 합니다.
이는 매우 효율적인 작업입니다. 출력 파일이 실제인 경우테이프 장치이는 단순히 테이프의 현재 위치에 쓰기(순차 출력)를 추가하는 것뿐입니다. 이것은 놀라운 일이 아닙니다. 이러한 유틸리티는 파일을 테이프에 보관하도록 설계되었으며 순차 I/O 특성은 양호하고 임의 액세스 I/O 특성은 좋지 않습니다.
(압축을 추가해도 이 내용은 변경되지 않습니다. 압축 유틸리티도 순차 I/O를 사용하도록 설계되었습니다.)
이것이 디스크 볼륨에 있는 파일이더라도 레코드의 각 추가 배치는 본질적으로 세 가지 작업입니다. 즉, 다른 블록을 얻기 위해 디스크 볼륨의 여유 공간 맵을 조정하고, 파일 끝에 해당 새 블록을 포함하도록 파일 inode를 조정합니다. 파일 시스템이 비용을 절감할 수 있는 범위와 적절한 할당 전략을 사용하고 블록을 작성합니다. 이는 순차 추가 쓰기 패턴이 감지될 때 연속 데이터 블록의 실행을 추론적으로 사전 할당하는 일반적인 파일 시스템 드라이버 최적화를 사용하면 실제로 매우 저렴하게 수행될 수 있습니다.
rsync백업은 디렉토리 항목 생성, B-트리 업데이트 등을 포함하는 전체 트리를 디스크 볼륨에 생성하고, i-노드 할당, 하드 링크 생성 및 모든 로그 업데이트를 생성합니다 .또한디스크 볼륨의 여유 공간 매핑 조정, inode의 블록 할당 조정, 파일 데이터 블록 쓰기 등 개별 파일 수준에서 cpio/tar 아카이브에 대한 작업을 수행합니다.
순차 추가 작업만 사용하여 아카이브를 작성하는 것은 테이프에 매우 효율적이며 디스크 볼륨에 저장된 단일 아카이브 파일에도 매우 효율적일 수 있습니다. 많은 수의 개별 파일을 작성하려면 본질적으로 더 많은 작업이 필요합니다.
물론 이러한 효율성을 위해 지불하는 대가는 아카이브의 손쉬운 인라인 수정, 우수한 아카이브 무작위 액세스 읽기 및 스마트 증분 백업 기능입니다.
1980년대에 Rahul Dhesi는 아카이브 형식을 만들었습니다.최대Serial(직렬)은 소량의 무작위 액세스 I/O를 사용하여 기존 아카이브에 대한 인라인 업데이트를 가능하게 하여 대체된 파일의 헤더를 덮어씁니다. 단점은 전체 아카이브를 다시 작성하여 대체된 파일의 파일 헤더와 데이터를 종종 제거해야 하며, 물론 아직 제거되지 않은 파일의 이전 버전을 저장하려면 더 많은 공간이 필요하다는 것입니다.
답변2
TAR은 429G의 대용량 파일을 생성하는 데 1시간 15분이 걸렸습니다.
rsync는 5시간이 걸리고 406G 대용량 폴더를 생성합니다.
수정구슬을 살펴보면서 몇 가지 추론을 할 수 있습니다. 작은 파일이 많고 원본 장치와 대상 장치 사이에 상당한 대기 시간이 있다는 것입니다. 이러한 요소를 살펴보고 문제에서 발견한 내용과 백업을 생성하기 위해 실행한 실제 명령을 포함하면 도움이 될 것입니다.
Tar는 다음과 같은 이유로 훨씬 빠릅니다.
- 데이터 트래픽은 한 방향으로만 흐르며 (아마도) 연결을 포화시킬 수 있습니다. - OTOH rsync는 양쪽 끝에서 동시에 데이터를 검색해야 합니다.
- tar는 단일 스트림에 쓰기 때문에 파일 생성에는 영향이 없습니다.
항상 동일한 대상 폴더에 복사하여 증분 복사본을 얻음으로써 rsync 성능을 크게 향상시킬 수 있다는 것을 알고 있지만, 항상 다른 날짜의 여러 백업을 갖고 싶기 때문에 이것은 분명히 내가 원하는 것이 아닙니다.
원본과 대상이 동일한 호스트(agan, 지정되지 않음)에 연결된 블록 장치라고 가정하면 파일 시스템을 덮어써야 할 수도 있습니다.
답변3
이것은 centos/ 디렉토리입니다(여기서는 중요하지 않습니다).
bin boot dev etc home lib lost+found media mnt opt proc root sbin selinux srv sys tmp usr var
/dev, /proc 및 /sys를 복사하고 싶지 않을 가능성이 높으며 필요에 따라 /media도 복사하고 싶지 않을 수도 있습니다.
따라서 사용하는 대신 rsync / $DEST($DEST가 다른 호스트에 있다고 가정합니다).
넌 달릴 수 있어
rsync /bin /boot /etc /lib /root /sbin /selinux $DEST &
sleep 300
rsync /home $DEST &
sleep 300
rsync /opt $DEST &
...
wait
모든 데이터가 /home에 있으면 계속해서 읽을 수 있습니다.
rsync /home/dir1 $DEST &
sleep 300
rsync /home/dir2 $DEST &
...
$DEST를 조정하거나 제외 옵션을 사용해야 합니다.rsync
1,000,000개의 파일이 있다고 가정하면 rsync(s)는 여전히 1M 파일 통계(소스 부분)와 1M 파일 통계(대상 부분)를 확인하고 압축 등을 수행해야 합니다.
댓글에서 언급했듯이, 1억 개의 파일이 포함된 디렉터리를 하루에 두 번 동기화해야 하며 rsync는 14~16시간 동안 지속됩니다. 위의 전략(그리고 일부 시행착오)을 사용하여 시간을 4~16시간으로 줄일 수 있었습니다. 5시간, 20개의 rsync 사용(그 중 15개는 임시)