Инструмент или скрипт для обнаружения перемещенных или переименованных файлов в Linux перед резервным копированием [закрыто]

В основном я ищу, чтобы увидеть, существует ли инструмент или сценарий, который может обнаружить перемещенные или переименованные файлы, чтобы я мог получить список переименованных / перемещенных файлов и применить ту же операцию на другом конце сети для экономии пропускной способности.

В основном дисковое хранилище дешевое, но пропускная способность - нет, и проблема в том, что файлы часто реорганизуются или перемещаются в лучшую структуру каталогов, поэтому при использовании rsync для резервного копирования rsync не заметит, что он переименован или переместить файл и заново передать его по сети, несмотря на наличие того же файла на другом конце.

Поэтому мне интересно, если существует сценарий или инструмент, который может записывать, где все файлы и их имена, то непосредственно перед резервным копированием он будет повторно сканировать и обнаруживать перемещенные или переименованные файлы, тогда я могу взять этот список и повторно применить операция перемещения / переименования на другой стороне.

Вот список «общих» возможностей файлов:

1. Большие неизменяемые файлы
2. Они могут быть переименованы или перемещены

[Edit:] Это все хорошие ответы, и в итоге я посмотрел на все ответы и напишу некоторый код для решения этой проблемы. В основном, я думаю / работаю сейчас:

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 на основе хоста, например AIDE, и написать скрипт-обертку, используя его вывод. Вам, вероятно, придется написать более сложную логику с учетом контрольных сумм.

В противном случае сетевая файловая система может иметь смысл, так как изменения будут отражены во всех местах. Тем не менее, я подозреваю, что вы переводите через Интернет, что ограничит возможности здесь.

Вы можете попробовать унисон ; особенно

-xferbycopying оптимизировать передачу с использованием локальных копий (по умолчанию true)

вариант упоминается в документах, как

Когда это предпочтение установлено, Unison будет пытаться избежать передачи содержимого файла по сети, распознавая, когда файл с требуемым содержимым уже существует в целевой реплике. Это обычно позволяет перемещать файлы очень быстро. Значение по умолчанию верно.

похоже, он может делать то, что вы хотите.

Syrep делает то, что вам нужно. Сохраняет дайджесты сообщений в файловом дереве в актуальном состоянии; хранение дайджестов делает его более эффективным, чем rsync. Он был разработан для sneakernet, поэтому вы можете добавить обертку, которая обновляет / makepatch / merge сразу.

Я не уверен, есть ли существующий инструмент, который сделает это за вас, но вы могли бы написать простой скрипт, который просто запускает 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

Обратите внимание, что я ждал примерно 1 минуту между запуском каждой findкоманды. Отсюда видно, что при первоначальном создании файла он отображается в списке find. Если я переместу файл в другой каталог и перезапущу findкоманду, он отобразит только каталог, в который я переместил файл, а не сам файл. Вы можете использовать комбинацию findи rsyncкоманд только список файлов , которые вы хотите, это , вероятно , может достичь своей цели.

Надеюсь, это поможет.

Учитывая ваш рабочий процесс, мне интересно, если работа на уровне файлов (например, то, что предлагали другие) является лучшим решением. Вы могли бы работать ...

На уровне файловой системы

Идея состоит в том, чтобы файловая система отслеживала операции между резервными копиями. Вместо создания резервной копии файловой системы, сделайте резервную копию журнала файловой системы (и, при желании, воспроизведите изменения на резервной машине, если вам нужна готовая к использованию резервная копия). Журнал файловой системы, естественно, выражает перемещения и удаления в несколько байтов.

Предохранитель позволяет относительно легко спроектировать файловую систему с особыми требованиями, которая находится поверх «настоящей файловой системы». Я никогда не использовал его, но LoggedFS выглядит многообещающе.

С этим решением было бы целесообразно иметь некоторую форму сжатия журнала. Например, если файл был перезаписан 10 раз, сохраняйте только последнее обновление в журнале. Другая полезная оптимизация - распознавание операций копирования и, что еще лучше, правок (т. Е. Создание файла, который в основном, но не полностью идентичен другому файлу). Я не знаю, реализовал ли кто-нибудь это. Для вашего рабочего процесса, я не думаю, что это все равно будет иметь большое значение.

На уровне громкости

Идея состоит в том, чтобы менеджер томов отслеживал операции между резервными копиями. Вместо создания резервной копии файловой системы, сделайте снимок с менеджером томов и сделайте резервную копию снимка, выраженного в виде различий из предыдущего снимка.

Это должно хорошо работать, если все, что вы делаете, это создаете файлы, переименовываете их и удаляете их. Было бы намного сложнее обнаружить такие вещи, как копии и изменения или оптимизировать создание файла с последующим его удалением.

Унисон хорош для этого, но все еще должен копировать файлы локально, и он не может обнаружить перемещение / переименование, даже если содержимое файла даже немного изменилось.

Я сделал простой скрипт на Python для обнаружения переименованных / перемещенных файлов и каталогов с использованием номеров инодов (только * nix) и воспроизведения этих изменений на синхронизированной машине. Вы можете использовать его отдельно или в качестве «препроцессора переименования» для Unison или rsync. Это можно найти здесь