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

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

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

Тож мені цікаво, чи існує сценарій чи інструмент, який може записувати, де всі файли та їх імена, то безпосередньо перед створенням резервної копії він міг би переглядати та виявляти переміщені чи перейменовані файли, то я можу взяти цей список та повторно застосувати операція переміщення / перейменування з іншого боку.

Ось перелік "загальних" особливостей файлів:

1. Великі незмінні файли
2. Їх можна перейменувати або перемістити

[Редагувати]] Це все хороші відповіді, і в кінцевому підсумку я переглядав усі відповіді і буду писати якийсь код для вирішення цього питання. В основному, над чим я зараз думаю / працюю:

1. Використовуючи щось на зразок AIDE для "початкового" сканування і дайте мені можливість зберігати контрольні суми у файлах, оскільки вони ніколи не змінюються, тому це допоможе виявити корупцію.
2. Створення демон-ініціатора, який би контролював ці файли / каталоги та записував будь-які зміни, пов’язані з перейменовуванням та переміщенням файлів у файл журналу.
3. Є деякі крайні випадки, коли inotify може не зафіксувати, що щось сталося з файловою системою, тому є останнім кроком використання знахідки для пошуку у файловій системі файли, які мають час зміни останнього, ніж остання резервна копія .

Це має ряд переваг:

1. Контрольні суми / тощо від AIDE, щоб мати можливість перевірити / переконатися, що деякі ЗМІ не стали корумпованими
2. Inotify забезпечує низьке використання ресурсів і не потребує повторного сканування файлової системи знову і знову
3. Не потрібно виправляти rsync; Якщо мені доведеться виправити те, що я можу, але я вважаю за краще уникати виправлень, щоб зменшити навантаження (IE не потрібно повторно виправляти щоразу, коли є оновлення).
4. Раніше я використовував 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/

Здається, добре працює. Запустіть його, а потім нормально синхронізуйте, тобто unison.

Можливо, ви зможете використовувати хост-IDS, такий як AIDE, і написати скрипт для обгортки, використовуючи його вихід. Вам, ймовірно, доведеться написати більш складну логіку з урахуванням контрольних сум.

В іншому випадку мережева файлова система може мати сенс, оскільки зміни відображатимуться у всіх місцях. Тим не менш, я підозрюю, що ви здійснюєте передачу через Інтернет, що обмежить тут варіанти.

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

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

варіант, зазначений у документах як

Коли цей параметр встановлений, Unison намагатиметься уникати передачі вмісту файлів по всій мережі, розпізнаючи, коли в цільовій репліку вже існує файл з необхідним вмістом. Зазвичай це дозволяє дуже швидко поширювати ходи файлів. Значення за замовчуванням - справжнє.

схоже, це може робити те, що ти хочеш.

Syrep робить все, що потрібно. Він постійно оновлює дайджести повідомлень на дереві файлів; дотримання дайджестів навколо робить його більш ефективним, ніж rsync. Він був розроблений для sneakernet, тому ви, можливо, захочете додати обгортку, яка робить оновлення / makepatch / spage одразу.

Я не впевнений, чи існує існуючий інструмент, який робить це для вас, але ви можете написати простий скрипт, який просто запускає 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. Його можна знайти тут