내 백업 서버의 동일한 파일 시스템에 두 개의 백업 디렉터리가 있습니다. 첫 번째는 "복제"라고 합니다. 여기에는 rsync를 통해 매일 밤 원격으로 업데이트되는 내 노트북의 복제본이 포함되어 있습니다. 두 번째는 "백업"이라고 불리는데, 이는 클론의 중요한 부분에 대한 주간 rsync 스냅샷입니다. 공간을 절약하기 위해 --link-dest를 사용하여 복사본 대신 복제할 하드 링크로 "백업"이 생성됩니다.
rsync -avum --link-dest=/clone /clone/ /backup
이제 --backup 옵션을 사용하여 변경된 파일의 이전 버전을 백업에서 보관 영역으로 복사하고 싶습니다. 필요한 경우나 실수로 중요한 항목을 삭제한 경우입니다. --link-dest 없이도 잘 작동합니다.
rsync -avumb --backup-dir=/holding/2016_10_22 /clone/ /backup
그러나 이렇게 하면 백업 시 변경된 파일의 복사본이 생성되어 공간이 낭비됩니다. 하드 링크가 필요합니다. 하지만 --link-dest parm을 다시 추가하면 다음과 같습니다.
rsync -avumb --backup-dir=/holding/2016_10_22 --link-dest=/clone /clone/ /backup
...그럼에만삭제됨파일이 백업됩니다. 변경된 파일은 자동으로 하드 링크됩니다. 그 이유는 --link-dest가 --copy-dest의 논리를 공유하기 때문입니다. 즉, 소스 파일이 copy-dest(또는 link-dest) 파일과 관련하여 변경되지 않은 경우 전송되지 않고 대신 copy/link-dest 디렉토리에서 대상 디렉토리로 복사/링크됩니다. 소스 디렉토리를 링크 대상 디렉토리로 사용하고 있기 때문에 삭제되지 않은 모든 파일은 "변경되지 않고" 자동으로 처리됩니다.
이 작업은 두 단계로 수행할 수 있습니다. 먼저 --link-dest 없이 --backup을 수행하고, 다시 --backup 없이 --link-dest를 수행합니다. (최신 버전의 rsync는 동일한 파일을 하드 링크로 대체합니다.) 하지만 저는 이 모든 작업을 한 번에 수행하는 것을 정말 선호합니다.
하드 링크만 생성하면서 --backup을 수행할 수 있는 방법이 있습니까? (실제로 내가 원하는 것은 파일 전송 대신 하드 링크를 사용하는 "일반" rsync입니다. --link-dest를 사용하는 것은 해당 옵션의 의도된 논리를 고려할 때 약간의 해킹처럼 보입니다.)
보너스 질문: 매뉴얼 페이지에는 빈 대상에만 --link-dest를 사용하는 것이 선호된다는 내용이 나와 있는 것 같습니다.
이 옵션은 기존 파일의 속성이 조정될 수 있고 하드 링크를 통해 대체 대상 파일에 영향을 미칠 수 있으므로 빈 대상 계층으로 복사할 때 가장 잘 작동합니다. 또한 변경 사항을 항목별로 분류하는 것이 약간 혼란스러울 수 있습니다.
"혼란"을 항목화하는 것에 대한 부분은 약간 모호합니다. 파일 속성에 대해 별로 신경 쓰지 않는다고 가정할 때 비어 있지 않은 대상에 --link-dest를 사용하는 것이 실제로 "위험"합니까? 누구든지 예를 들어 줄 수 있습니까?
답변1
위에서 언급했듯이 프로세스는 두 단계로 진행되었습니다.
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))
첫 번째 단계에서는 클론의 중요한 부분을 백업하고 마지막 백업 이후 삭제된 파일을 휴지통에 저장합니다. (선택한 파일만 중간 백업하고 매주 업데이트하려는 이유가 있습니다.)
두 번째 단계에서는 백업 파일을 복제본을 가리키는 하드 링크로 변환합니다. 결과적으로 백업은 실제 공간을 차지하지 않습니다. Trashdir은 복제 및 백업에서 삭제된 파일로만 구성되므로 정의상 하드 링크된 파일이 아닙니다.
--delete-excluded 플래그가 필요한지 여부는 확실하지 않습니다(특히 두 번째 명령에서). 백업을 생성할 때 무시할 클론 부분을 정의하는 필터 파일을 변경할 경우를 대비해 거기에 남겨 두었습니다.
5년 안에 휴지통이 대략 복제본 크기로 커졌으므로 전체 크기 = 복제본 x2가 됩니다. 이는 삭제된 파일에 대한 6년의 기록이 있고 다음을 통해 쉽게 정리할 수 있다는 점을 고려하면 허용됩니다. 날짜.
위의 내용 외에도 cp -al약 한 달 간의 날짜 스탬프가 찍힌 회전 하드링크 스냅샷에 복제본을 복사하기 위해 실행되는 스크립트가 있습니다. 여기에는 삭제된 파일이 아닌 변경된 파일이 포함됩니다. 한 달 동안의 전체 크기는 클론 크기의 절반 정도인 것 같습니다.
따라서 총 디스크 공간은 복제본의 ~2.5이며 다음과 같습니다.
- 클론 자체, 밤마다 업데이트됨
- 일주일 동안 안정적인 선택 파일 백업
- 한 달 분량의 버전이 지정된 클론 스냅샷
- 6년 동안의 삭제된 파일
원본 디스크의 손실, 파일 덮어쓰기, 이전 버전 필요, 파일 삭제 후 나중에 필요에 대한 보호가 매우 훌륭하다고 생각합니다.
약간 복잡하고 아마도 타사 소프트웨어를 사용하여 달성할 수 있었지만 나에게는 효과가 있었고 사라지거나 기능이 크게 변경될 가능성이 없는 낮은 수준의 도구를 기반으로 구축되었습니다.
(@gsl - 사실 업데이트를 요청해주셔서 감사합니다. python3으로 업데이트할 때 스크립트 중 하나가 손상되어 몇 달 동안 실행되지 않은 것을 발견했습니다. 오류 로그에 더 주의를 기울여야 합니다!)
하지만 이 작업을 간소화하는 방법에는 확실히 여전히 관심이 있습니다. 따라서 제가 하고 있는 작업을 좀 더 쉬운 방법으로 수행할 수 있다면 자유롭게 의견을 남겨주세요.