변경된 파일을 백업하는 동안 rsync가 소스 디렉터리에 대한 하드 링크를 생성하도록 하려면 어떻게 해야 합니까?

Question

위에서 언급했듯이 프로세스는 두 단계로 진행되었습니다.

src = the "live" clone directory, a mirror of my laptop = primary backup
dst = the weekly snapshot of important parts clone
trashdir = the items from src that don't exist in dst, because they have since been deleted, sorted into date-stamped directories

cmd = ("rsync -avumb --stats --delete --delete-excluded --filter='merge %s' --backup-dir=%s %s %s" %
       (filterfile, trashdir, src, dst))

cmd = ("rsync -avum --stats --delete --delete-excluded --filter='merge %s' --link-dest=%s %s %s" %
       (filterfile, src, src, dst))

첫 번째 단계는 복제본의 중요한 부분을 백업하고 마지막 백업 이후 삭제된 파일을 휴지통에 저장하는 것입니다. (어떤 이유에서인지 선택한 파일의 중간 백업만 하고 일주일에 한 번만 업데이트하기를 원합니다.)

두 번째 단계에서는 백업의 파일을 복제본에 대한 하드 링크로 변환합니다. 결과적으로 백업은 실제 공간을 전혀 차지하지 않습니다. 정의에 따르면, 휴지통은 클론 및 백업에서 삭제된 파일만 포함하므로 하드 링크 파일이 아닙니다.

--delete-excluded 플래그가 필요한지 확실하지 않습니다(특히 두 번째 명령에서). 백업을 생성할 때 무시할 복제본 부분을 정의하는 필터 파일을 변경할 경우를 대비해 그대로 둡니다.

나는 5년 안에 휴지통이 클론 크기만큼 커졌으므로 총 크기 = 클론 x2라는 사실을 발견했습니다. 이는 삭제된 파일의 기록이 6년 동안 있었고 날짜별로 쉽게 정리할 수 있었기 때문에 허용될 수 있었습니다.

위의 것 외에도 cp -al날짜가 표시되고 순환되고 하드 링크된 약 한 달 전의 스냅샷에 대한 복제본을 실행하는 스크립트가 있습니다. 여기에는 변경되었지만 삭제되지 않은 파일이 포함됩니다. 한 달의 전체 크기는 클론 크기의 약 절반 정도인 것으로 보입니다.

따라서 총 디스크 공간은 복제본의 약 2.5배입니다.

자체 복제, 밤마다 업데이트
선택한 파일 백업, 일주일 동안 안정적
버전이 지정된 클론의 1개월 스냅샷
6년간의 삭제된 파일

이는 원본 디스크 분실, 파일 덮어쓰기, 이전 버전 필요, 파일 삭제 후 나중에 필요 방지를 위한 좋은 방법이라고 생각합니다.

약간 복잡하고 타사 소프트웨어를 사용하면 달성할 수 있지만 저에게는 효과적이며 사라지거나 기능이 크게 변경될 가능성이 없는 낮은 수준의 도구를 기반으로 구축되었습니다.

(@gsl - 실제로 업데이트를 요청해 주셔서 감사합니다. python3으로 업데이트했을 때 스크립트 중 하나가 손상되어 몇 달 동안 실행되지 않는 것을 발견했습니다. 오류 로그에 더 주의를 기울여야 합니다!)

그러나 저는 이것을 단순화하는 방법에 여전히 관심이 있습니다. 따라서 제가 하고 있는 작업을 좀 더 간단한 방법으로 수행할 수 있다면 언제든지 의견을 주시기 바랍니다.

Answer 1