그래서이 이야기GNU coreutils ML에서 누군가 cp를 사용하여 4억 3천만 개의 파일을 복사했으며 하드 링크를 보존해야 했습니다.겨우 겨우10일만에 이루어졌습니다.
가장 큰 문제는 하드 링크를 보존하기 위해 cp가 복사된 파일의 해시 테이블을 보존해야 했기 때문에 결국 17GB의 메모리를 차지하고 스왑 시 시스템이 충돌하게 된다는 점이었습니다.
이 작업을 더 잘 처리하는 유틸리티가 있습니까?
답변1
tar해결 방법 이 rsync실패하고 디렉터리가 파일 시스템의 루트인 경우 이전 dump/restore백업 유틸리티를 사용할 수 있습니다(예, 여전히 작동합니다).
dump커널 파일 시스템 인터페이스를 거치지 않고 파일 시스템 특성을 복제하므로 속도가 상당히 빠릅니다.
불편한 점은 dump복사가 소스 파일 시스템의 변경 사항에 민감하다는 것입니다. 따라서 파일 시스템을 마운트 해제하거나 읽기 전용으로 다시 마운트하거나 복사를 시작하기 전에 파일 시스템에 액세스할 수 있는 모든 응용 프로그램을 중지하는 것이 가장 좋습니다. 해당 조건을 존중한다면 사본은 신뢰할 수 있습니다.
파일 시스템 유형에 따라 dump명령 이름이 변경될 수 있습니다. 예를 들어 xfsdumpXFS에 대한 명령 이름을 사용할 수 있습니다.
다음 명령은 예제와 유사합니다 tar.
dump 0uf - /dev/sdaX | (cd /target && restore rf -)
숫자는 증분 복사 수준이며 0전체 복사를 나타냅니다.
답변2
rsync가 나에게 몇 가지 문제를 일으켰던 것을 기억합니다. 이것이 하드 링크인지 장치 파일인지, 아니면 무엇인지 잘 모르겠습니다. 그 이후로 나는
tar -cv $(ls) | ( cd /mnt; tar xv )
그러면 모든 파일이 복사됩니다. /mnt로. 내 전체 이야기는 여기에서 찾을 수 있습니다.http://www.linuxintro.org/wiki/Cloning#file-by-file_copy_2