백업 전에 Linux에서 이동 또는 이름이 바뀐 파일을 감지하는 도구 또는 스크립트 [닫기]

기본적으로 이동 또는 이름이 바뀐 파일을 감지하여 이름이 변경되거나 이동 된 파일 목록을 얻고 네트워크의 다른 쪽 끝에서 동일한 작업을 적용하여 대역폭을 절약 할 수있는 도구 또는 스크립트가 있는지 확인하려고합니다.

기본적으로 디스크 스토리지는 저렴하지만 대역폭은 크지 않으며 문제는 파일을 종종 더 나은 디렉토리 구조로 재구성하거나 이동하여 rsync를 사용하여 백업을 수행 할 때 rsync가 이름이 바뀌 었음을 알 수 없다는 것입니다. 다른 쪽 끝에 같은 파일이 있더라도 파일을 이동하고 네트워크를 통해 다시 전송합니다.

따라서 모든 파일의 위치와 이름을 기록 할 수있는 스크립트 또는 도구가 있는지 궁금한 다음 백업 직전에 이동하거나 이름이 바뀐 파일을 다시 검색하고 감지 한 다음 해당 목록을 가져 와서 다시 적용 할 수 있습니다 다른 쪽의 이동 / 이름 변경 작업

파일의 "일반"기능 목록은 다음과 같습니다.

1. 변하지 않는 큰 파일
2. 이름을 바꾸거나 이동할 수 있습니다.

[편집 :] 이것들은 모두 좋은 대답이며, 결국 내가하는 일은 모든 답을보고 있었고 이것을 처리하기위한 코드를 작성할 것입니다. 기본적으로 지금 생각하고 / 현재하고있는 것은 :

1. "초기"스캔에 AIDE와 같은 것을 사용하면 파일이 변경되지 않아야하기 때문에 파일에 체크섬을 유지할 수 있으므로 손상을 감지하는 데 도움이됩니다.
2. 이러한 파일 / 디렉토리를 모니터링하는 inotify 데몬을 만들고 파일 이름 변경 및 로그 파일로 파일 이동과 관련된 변경 사항을 기록합니다.
3. inotify가 파일 시스템에 무슨 일이 있었는지 기록하지 못하는 경우가 있습니다. 따라서 find를 사용하여 파일 시스템에서 마지막 백업 보다 변경 시간이 늦은 파일을 검색 하는 마지막 단계가 있습니다 .

여기에는 몇 가지 장점이 있습니다.

1. 일부 미디어가 손상되지 않았는지 확인 / 확인할 수있는 AIDE의 체크섬 / 등
2. Inotify는 리소스 사용량을 낮게 유지하며 파일 시스템을 계속해서 다시 검색 할 필요가 없습니다.
3. rsync를 패치 할 필요가 없습니다. 내가 할 수있는 것을 패치해야한다면 부담을 낮추기 위해 패치하는 것을 피하고 싶습니다 (IE는 업데이트가있을 때마다 다시 패치 할 필요가 없습니다).
4. 나는 이전에 Unison을 사용했는데 정말 좋았지 만 Unison이 파일 시스템에 사본을 보관하고 "보관"파일이 다소 커질 수 있다고 맹세 할 수 있습니까?

Unison http://www.cis.upenn.edu/~bcpierce/unison/ 은 움직임과 이름 변경을 감지 할 수 있다고 주장합니다.

이동 / 이름 변경 감지를 추가하기 위해 rsync에 몇 가지 패치가 있습니다.

http://gitweb.samba.org/?p=rsync-patches.git;a=blob;f=detect-renamed-lax.diff;h=1ff593c8f97a97e8970d43ff5a62dfad5abddd75;hb=master

http://gitweb.samba.org/?p=rsync-patches.git;a=blob;f=detect-renamed.diff;h=c3e6e846eab437e56e25e2c334e292996ee84345;hb=master

이 문제를 추적하는 Bugzilla 항목 : https://bugzilla.samba.org/show_bug.cgi?id=2294

이것은 약간 이상한 해결책이지만 ... git은 파일 내용을 기반으로 이동을 감지하고 이름을 바꿉니다. 따라서 문제가있는 디렉토리를 버전 제어 상태로 유지하려면 git은 이동을 감지하고 전송을 피할 수 있습니다. 내용은 (전선의 양쪽에 이미 있기 때문에) 여전히 나무에서 물건을 움직입니다.

그냥 생각이야

흥미로운 제안이 있습니다. 또한 파일 시스템 기능 (예 : ZFS) 사용을 고려했습니다. 그 간단한 일을하는 도구가 없다는 것이 이상하다는 것을 알았습니다. 대부분의 경우 사람들이보고 한대로 Unison 옵션이 작동하지 않습니다.

폴더를 후진 할 때 영화 모음의 백업을 두 번째 하드 디스크의 백업 상태로 유지하는 기능을 원합니다.

이제이 간단한 C 스크립트 http://sourceforge.net/projects/movesync/를 찾았습니다 .

잘 작동하는 것 같습니다. 그것을 실행 한 다음 정상적으로 동기화하십시오.

당신은 사용할 수 있습니다 호스트 기반 IDS 등을 보좌관 및 출력을 사용하는 래퍼 스크립트를 작성합니다. 체크섬을 고려하여 더 복잡한 논리를 작성해야 할 것입니다.

그렇지 않으면 변경 사항이 모든 위치에 반영되므로 네트워크 기반 파일 시스템이 의미가있을 수 있습니다. 그럼에도 불구하고, 귀하가 인터넷을 통해 전송하는 것으로 의심되며 여기에서 옵션이 제한됩니다.

당신은 일제히 시도 할 수 있습니다 ; 특히

-xferbycopying은 로컬 사본을 사용하여 전송을 최적화합니다 (기본값은 true).

옵션에서 언급 한 문서 로

이 환경 설정이 설정되면 Unison은 필요한 컨텐츠가있는 파일이 대상 복제본에 이미 존재하는 경우를 인식하여 네트워크를 통해 파일 컨텐츠를 전송하지 않도록 시도합니다. 일반적으로 파일 이동이 매우 빠르게 전파됩니다. 기본값은 true입니다.

원하는 것을 할 수있는 것처럼 보입니다.

Syrep 은 필요한 작업을 수행합니다. 파일 트리에서 메시지 요약을 최신 상태로 유지합니다. 다이제스트를 유지하면 rsync보다 효율적입니다. Sneakernet을 위해 설계되었으므로 한 번에 업데이트 / makepatch / 병합하는 래퍼를 추가 할 수 있습니다.

이 작업을 수행하는 기존 도구가 있는지 확실하지 않지만 마지막 백업보다 새로운 find기본 디렉토리에서 실행되는 간단한 스크립트를 작성할 수 mtime있습니다. 수정 된 모든 파일 목록이 표시됩니다 . 파일이 단순히 이동 된 경우 목록에 나타나지 않습니다. 불행히도이 목록에는 파일이 추가 / 제거 될 때 디렉토리가 업데이트되므로 파일이 이동 한 디렉토리가 포함됩니다.

해당 파일 목록에서 rsync를 사용하여 해당 파일 만 동기화 할 수 있습니다. rsync에는 파일 목록을 읽을 수있는 옵션이 있습니다. 다음은이 예제를 보여주는 테스트입니다.

$ cd tmp
$ echo test > test
$ ls -la
total 16
drwxr-xr-x 2 root root 4096 Aug 18 11:34 .
drwxr-x--- 5 root root 4096 Aug 18 11:34 ..
-rw-r--r-- 1 root root    5 Aug 18 11:34 test
$ mkdir tmp2
$ find . -mmin 1
$ date
Wed Aug 18 11:35:10 EDT 2010
$ find . -mmin 1
$ find . -mmin 2
.
./test
./tmp2
$ mv test tmp2
$ find . -mmin 1
.
./tmp2

각 find명령을 실행하는 데 약 1 분이 걸렸습니다 . 여기에서 파일을 처음 만들 때이 목록으로 표시됩니다 find. 파일을 다른 디렉토리로 이동하고 find명령을 다시 실행 하면 파일 자체가 아니라 파일을 이동 한 디렉토리 만 표시됩니다. find및 rsync파일 조합을 사용하여 원하는 파일 만 나열하면 목표를 달성 할 수 있습니다.

이게 도움이 되길 바란다.

워크 플로를 고려할 때 다른 사람들이 지금까지 제안한 것과 같은 파일 수준에서 작업하는 것이 최상의 솔루션인지 궁금합니다. 당신은 일할 수 ...

파일 시스템 수준에서

아이디어는 파일 시스템이 백업 간의 작업을 추적하도록하는 것입니다. 파일 시스템을 백업하는 대신 파일 시스템 저널을 백업하십시오 (선택적으로 사용 가능한 백업을 원하는 경우 백업 시스템의 변경 사항을 재생). 파일 시스템 저널은 자연스럽게 몇 바이트로 이동 및 삭제를 표현합니다.

퓨즈를 사용하면“실제 파일 시스템”위에있는 특정 요구 사항을 가진 파일 시스템을 비교적 쉽게 디자인 할 수 있습니다. 나는 그것을 사용한 적이 없지만 LoggedFS 는 유망한 것처럼 보입니다.

이 솔루션을 사용하면 저널 압축 형식을 갖는 것이 좋습니다. 예를 들어, 파일을 10 번 덮어 쓴 경우 저널의 마지막 업데이트 만 유지하십시오. 또 다른 가치있는 최적화는 복사 작업을 인식하고 더 나은 편집을 인식하는 것입니다 (즉, 대부분 다른 파일과 완전히 동일하지는 않은 파일 작성). 아무도 이것을 구현했는지 모르겠습니다. 귀하의 워크 플로우의 경우 어쨌든 중요하지 않다고 생각합니다.

볼륨 레벨에서

아이디어는 볼륨 관리자가 백업 간의 작업을 추적하도록하는 것입니다. 파일 시스템을 백업하는 대신 볼륨 관리자 를 사용하여 스냅 샷 을 작성하고 이전 스냅 샷과 비교 하여 스냅 샷을 백업하십시오 .

파일을 만들고 이름을 바꾸고 제거하기 만하면됩니다. 복사 및 편집과 같은 것을 탐지하거나 파일 생성 후 삭제하는 것을 최적화하는 것이 훨씬 어려울 것입니다.

Unison은 이것에 좋지만 여전히 파일을 로컬로 복사해야하며 파일 내용도 조금이라도 바뀌면 이동 / 이름 바꾸기를 감지 할 수 없습니다.

inode 번호 (* nix 만 해당)를 사용하여 이름이 바뀌거나 이동 한 파일 및 디렉토리를 감지하고 동기화 된 시스템에서 이러한 변경 사항을 재생하는 간단한 Python 스크립트를 작성했습니다. 단독으로 또는 Unison 또는 rsync의 "이름 변경 전 처리기"로 사용할 수 있습니다. 여기 에서 찾을 수 있습니다