오래된 파일이 이미있는 경우 rsync가 동일한 파일을 --link-dest 옵션으로 연결하는 방법은 무엇입니까?


11

--link-dest동일한 파일을 사용하는 것이 모든 경우에 효과적 이라고 생각할 수도 있습니다 . 그러나 파일이 오래되었거나 내용이 다른 경우에도 파일이 존재하는 경우에는 그렇지 않습니다.

이는 rsync 매뉴얼 페이지의 다음 때문입니다 --link-dest.

"이 옵션은 rsync가 기존 파일을 최종 파일로 취급하므로 빈 대상 계층 구조로 복사 할 때 가장 효과적입니다 (따라서 대상 파일이 이미 존재하는 경우 rsync는 링크 대상 디렉토리에서 절대로 보이지 않음 )"

즉 y/file, 소스와 동일하고 z/file최신 상태가 아닌 경우 ,

rsync -a --del -link-dest=y source:/file z

TWO 아이 노드 (그리고 두 배의 디스크 공간)를 사용하고, 발생한다 y/file과 z/file동일한 내용과 datestamps있을 것이다.

기본적 으로이 스크립트를 하루에 한 번 실행하여 매일 백업을 수행하기 때문에이 문제가 발생했습니다.

mv $somedaysago $today; 
yest=$today; today=`date +%Y%m%d`;
rsync -avPShyH --del --link-dest=../$yest host:/dirs $today

내 백업은 최대 10M 파일까지 확장되므로 rm -rf $olddir; rsync source:$dir newdir너무 오래 걸리는 경우가 있습니다 (특히 매일 0.5 %의 파일 만 변경되는 경우 50K 개의 새 파일 또는 변경된 파일을 처리하기 위해 10M 디렉토리 항목의 삭제 및 생성이 발생하여 다음날 백업이 완료되지 않습니다).

상황에 대한 데모는 다음과 같습니다.

a번호가 매겨진 백업을 1통해 소스입니다 4.

$ mkdir -p 1 2; echo foo > 1/foobar; cp -lrv 1/* 2
`1/foobar' -> `2/foobar'
$ ls -i1 */foobar
1053003 1/foobar
1053003 2/foobar

$ mkdir a; echo quux > a/foobar
$ mv 1 3; rsync -avPhyH --del --link-dest=../2 a/ 3
sending incremental file list
./
foobar
           5 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/2)

sent 105 bytes  received 34 bytes  278.00 bytes/sec
total size is 5  speedup is 0.04

$ ls -i1 */foobar
1053003 2/foobar
1053007 3/foobar
1053006 a/foobar

$ mv 2 4; rsync -avPhyH --del --link-dest=../3 a/ 4
sending incremental file list
./
foobar
           5 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/2)

sent 105 bytes  received 34 bytes  278.00 bytes/sec
total size is 5  speedup is 0.04


$ ls -il1 */foobar
1053007 -rw-r--r-- 1 math math 5 Mar 30 00:57 3/foobar
1053008 -rw-r--r-- 1 math math 5 Mar 30 00:57 4/foobar
1053006 -rw-r--r-- 1 math math 5 Mar 30 00:57 a/foobar

$ md5sum [34a]/foobar
d3b07a382ec010c01889250fce66fb13  3/foobar
d3b07a382ec010c01889250fce66fb13  4/foobar
d3b07a382ec010c01889250fce66fb13  a/foobar

이제 우리는 a/foobar타임 스탬프를 포함하여 모든 방법에서 동일하지만 다른 inode를 점유하는 2 개의 백업이 있습니다.

해결책은 --delete-before증분 스캔의 이점을 없애는 해결책이라고 생각할 수도 있지만 파일이 삭제되지는 않지만 증분 복사가 가능한 경우 기본으로 사용되므로 도움이되지 않습니다.

을 사용 하여이 증분 복사 헤지를 끌 수 --whole-file있지만, 알고리즘을 전혀 지원하지 않으므로 원하는 것을 얻을 수있는 방법이 없습니다.

이 동작을 rsync의 또 다른 버그로 생각합니다. 여기서 다양한 명령 인수를 신중하게 선택하여 유익한 동작을 해석 할 수 있지만 원하는 결과를 얻을 수 없습니다.

안타깝게도 솔루션은 단일 rsync에서 원자 작업으로 드라이 런으로 이동 -n하고 로깅하여 변경된 모든 파일을 수동으로 사전 삭제하는 입력으로 로그를 처리 한 다음 rsync --link-dest원하는 것을 얻기 위해 실행 합니다. 하나의 깨끗한 rsync와 비교할 때.

부록 : 프로덕션 박스에 대해 백업하기 전에 백업 서버 $yesterday와 $today백업 서버에서 사전 연결을 시도 rsync --link-dest=../$yesterday $yesterday/ $today했지만 같은 결과- 길이가 0이더라도 어떤 방식 으로든 존재하는 모든 파일은 제거되지 않고 전체 링크 대신 삭제되지 않습니다. 새로운 inode와 함께 더 많은 디스크 공간을 사용하여 sourcedir에서 새 사본이 작성됩니다.

보면 pax(1)가능한 사전 연결-전에 백업 솔루션으로.


내가 사용하는 --delete-after이 사용 시나리오에서,이 문제점은 무엇입니까?
— gogoud

1
--delete-after괜찮지 만 현재 문제와 관련이 없습니다. 복사가 완료되면 소스에서 누락 된 파일이 삭제됩니다. 내가 밝히고있는 문제는 어제와 동일하지만 어제 inode에 연결되지 않았지만 어제 일 때 총 디스크 공간의 두 배에 새 파일로 저장된 오래된 파일에 대해 오늘 수행되는 백업과 관련이 있습니다. 동일한 사본이 고려됩니다.
— math

당신이 무엇을 질문하는지 완전히 알지 못합니다. 당신은 고려 했습니까 rsnapshot? 또한 "동일한"파일을 다시 연결하는 작은 스크립트를 작성하는 것이 좋습니다. 나는 내 시스템에서 둘 다한다.
— roaima

1
여기에 필요한 답변을 얻지 못하면 rsync 목록에 게시 할 수 있습니다. rsync 개발자는 정기적으로 많은 고급 사용자와 함께 질문에 대답합니다. list.samba.org/mailman/listinfo/rsync 를 통해 찾을 수 있습니다 . 나는 주로 그곳에 숨어 많은 것을 배웁니다.
— Joe

rsnapshot은 이전 백업을 재활용하지 않습니다. 2 개월 및 2 개월 +1 일 이전 백업이있는 경우 새 백업으로 순환 할 수 있습니다. ~ 5 %의 파일이 매일 변경되므로 10M 대신 50K 하드 링크를 만듭니다. 이 속도 차이로 밤에 서버 5 대를 백업 할 수 있습니다. hardlink(1)rsync의 메타 데이터 스캔보다 15 배 느립니다. pax이전 백업과 새로운 백업을 비교할 때 HDD 헤드가 더 빠르지 만 충돌합니다. rsync -n델타 목록을 얻으려면 프로덕션 서버를 두 번 누르십시오 (10M 파일 스캔은 50K 변경 사항을 복사하는 것보다 훨씬 더 영향을 미칩니다). 이것을 허용하기 위해 rsync의 옵션에 대한 목록을 메일로 보내드립니다.
— math

답변:


12

(질문 편집에서 변환)

이것은 rsync를 업그레이드하여 해결됩니다. 버전 3.1.1 이상은 이제 대상 및 --link-dest디렉토리 에서 동일한 파일 을 하나의 하드 링크 된 파일로 대체 합니다. 많은 공간을 절약합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.