В основном я ищу, существует ли инструмент или сценарий, который может обнаруживать перемещенные или переименованные файлы, чтобы я мог получить список переименованных / перемещенных файлов и применить ту же операцию на другом конце сети для экономии пропускной способности.
В основном дисковое хранилище дешево, а пропускная способность - нет, и проблема в том, что файлы часто реорганизуются или перемещаются в лучшую структуру каталогов, поэтому, когда вы используете rsync для резервного копирования, rsync не заметит, что это переименованный или переместил файл и повторно передал его по сети, несмотря на то, что на другом конце был тот же файл.
Поэтому мне интересно, существует ли скрипт или инструмент, который может записывать, где находятся все файлы и их имена, тогда непосредственно перед резервным копированием он повторно сканировал и обнаруживал перемещенные или переименованные файлы, тогда я мог взять этот список и повторно применить операция перемещения / переименования с другой стороны.
Вот список «общих» функций файлов:
[Редактировать:] Все это хорошие ответы, и в итоге я посмотрел на все ответы и напишу код для решения этой проблемы. В основном я думаю / работаю сейчас над:
Это дает несколько преимуществ:
Унисон http://www.cis.upenn.edu/~bcpierce/unison/ утверждает, что может определять ходы и переименовывать.
В rsync есть пара патчей, чтобы добавить обнаружение перемещения / переименования:
Запись в Bugzilla, отслеживающая эту проблему: https://bugzilla.samba.org/show_bug.cgi?id=2294
Это немного странное решение, но ... git обнаруживает перемещения и переименовывает в зависимости от содержимого файла, поэтому, если вы оставите соответствующие каталоги под контролем версий, тогда git сможет обнаруживать перемещения и тому подобное и избегать передачи контент (поскольку он уже находится по обе стороны провода), все еще перемещая объекты в дереве.
Просто мысль.
здесь интересные предложения. Также подумал об использовании возможностей файловой системы, например, ZFS. Было странно, что нет инструмента, который делает эту простую вещь. Как сообщают люди, вариант Unison не работает в большинстве случаев, и не для меня.
Я хочу, чтобы функция синхронизировала резервную копию моей коллекции фильмов на втором жестком диске при перестановке папок.
Теперь я нашел этот простой скрипт на C http://sourceforge.net/projects/movesync/
Вроде нормально работает. Запустите его, а затем выполните обычную синхронизацию, например, в унисон.
Вы могли бы использовать IDS на основе хоста Такие как Помощник и напишите сценарий оболочки, используя его вывод. Скорее всего, вам придется написать более сложную логику с учетом контрольных сумм.
В противном случае может иметь смысл сетевая файловая система, поскольку изменения будут отражены во всех местах. Тем не менее, я подозреваю, что вы осуществляете перевод через Интернет, что ограничивает возможности здесь.
Вы можете попробовать унисон ; особенно
-xferbycopying оптимизировать передачу с использованием локальных копий (по умолчанию true)
вариант, упомянутый в документы так как
Когда это предпочтение установлено, Unison будет пытаться избежать передачи содержимого файла по сети, распознавая, когда файл с требуемым содержимым уже существует в целевой реплике. Обычно это позволяет очень быстро распространять перемещения файлов. Значение по умолчанию верно.
похоже, он может делать то, что вы хотите.
Сыреп делает то, что вам нужно. Он поддерживает дайджесты сообщений в дереве файлов в актуальном состоянии; хранение дайджестов делает его более эффективным, чем rsync. Он был разработан для сникернета, поэтому вы можете добавить оболочку, которая выполняет обновление / 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
Обратите внимание, что я ждал примерно 1 минуту между запусками каждого find команда. Из этого видно, что при первоначальном создании файла он перечисляется find. Если я переместил файл в другой каталог и повторно запустил find , она отображает только каталог, в который я переместил файл, а не сам файл. Вы можете использовать комбинацию find и rsync команды, чтобы перечислить только те файлы, которые вам нужны, это, вероятно, может достичь вашей цели.
Надеюсь, это поможет.
Учитывая ваш рабочий процесс, мне интересно, является ли работа на уровне файлов (как то, что до сих пор предлагали другие) лучшим решением. Вы могли бы работать ...
Идея состоит в том, чтобы файловая система отслеживала операции между резервными копиями. Вместо того, чтобы делать резервную копию файловой системы, резервное копирование журнала файловой системы (и при желании воспроизвести изменения на резервной машине, если вы хотите получить готовую резервную копию). Журнал файловой системы, естественно, выражает перемещения и удаления в несколько байтов.
Предохранитель позволяет относительно легко спроектировать файловую систему с особыми требованиями, которая находится поверх «реальной файловой системы». Я никогда этим не пользовался, но LoggedFS выглядит многообещающе.
С этим решением было бы полезно иметь некоторую форму сжатия журналов. Например, если файл был перезаписан 10 раз, сохраните в журнале только его последнее обновление. Другой стоящей оптимизацией было бы распознавание операций копирования и, что еще лучше, редактирования (т. Е. Создание файла, который в основном, но не полностью идентичен другому файлу). Я не знаю, реализовал ли кто-нибудь это. Я не думаю, что для вашего рабочего процесса это будет иметь большое значение.
Идея состоит в том, чтобы диспетчер томов отслеживал операции между резервными копиями. Вместо того, чтобы делать резервную копию файловой системы, сделайте снимок с помощью диспетчера томов и сделайте резервную копию снимка выражается как отличие от предыдущего снимка.
Это должно работать хорошо, если все, что вы делаете, это создаете файлы, переименовываете их и удаляете. Было бы намного сложнее обнаружить такие вещи, как копирование и редактирование, или оптимизировать создание файла с последующим его удалением.
Unison хорош для этого, но ему все равно нужно копировать файлы локально, и он не может обнаружить перемещение / переименование, если также содержимое файла даже немного изменилось.
Я сделал простой скрипт Python для обнаружения переименованных / перемещенных файлов и каталогов с использованием номеров inode (только * nix) и воспроизведения этих изменений на синхронизированной машине. Вы можете использовать его отдельно или как «препроцессор переименования» для Unison или rsync. Это можно найти Вот