Narzędzie lub skrypt do wykrywania przeniesionych lub zmienionych nazw plików w systemie Linux przed utworzeniem kopii zapasowej [zamknięte]

Zasadniczo szukam, czy istnieje narzędzie lub skrypt, który może wykryć przeniesione lub zmienione nazwy plików, dzięki czemu mogę uzyskać listę przemianowanych / przeniesionych plików i zastosować tę samą operację na drugim końcu sieci, aby zaoszczędzić na przepustowości.

Zasadniczo miejsce na dysku jest tanie, ale przepustowość nie, a problemem jest to, że pliki często zostaną zreorganizowane lub przeniesione do lepszej struktury katalogów, dlatego gdy używasz rsync do tworzenia kopii zapasowych, rsync nie zauważy, że zmieniono jego nazwę lub przeniesiono plik i ponownie przesłano go przez sieć, mimo że ten sam plik znajduje się na drugim końcu.

Zastanawiam się więc, czy istnieje skrypt lub narzędzie, które może rejestrować, gdzie znajdują się wszystkie pliki i ich nazwy, a następnie tuż przed utworzeniem kopii zapasowej przeskanowałoby i wykryło przeniesione lub zmienione nazwy plików, a następnie mogę pobrać tę listę i ponownie zastosować operacja przenoszenia / zmiany nazwy po drugiej stronie.

Oto lista „ogólnych” funkcji plików:

1. Duże niezmienne pliki
2. Można je zmienić lub zmienić

[Edytuj:] To są dobre odpowiedzi, a tym, co ostatecznie zrobiłem, było przeanalizowanie wszystkich odpowiedzi i napisanie kodu, aby sobie z tym poradzić. Zasadniczo myślę / pracuję teraz nad:

1. Użycie czegoś takiego jak AIDE do „początkowego” skanowania i umożliwienie mi zachowania sum kontrolnych na plikach, ponieważ powinny one nigdy się nie zmieniać, więc pomogłoby to w wykryciu uszkodzenia.
2. Tworzenie demona inotify, który monitorowałby te pliki / katalog i rejestrował wszelkie zmiany związane z zmianą nazw i przenoszeniem plików do pliku dziennika.
3. Istnieją pewne przypadki krawędzi, w których inotify może nie zarejestrować, że coś się stało z systemem plików, dlatego jest ostatni krok przy użyciu funkcji find do przeszukiwania systemu plików w poszukiwaniu plików, których czas zmiany jest dłuższy niż ostatnia kopia zapasowa .

Ma to kilka zalet:

1. Sumy kontrolne / etc z AIDE, aby móc sprawdzić / upewnić się, że niektóre media nie uległy uszkodzeniu
2. Inotify utrzymuje niskie zużycie zasobów i nie ma potrzeby ponownego skanowania systemu plików w kółko
3. Nie ma potrzeby łatania rsync; Jeśli muszę łatać rzeczy, mogę, ale wolałbym unikać łatania rzeczy, aby zmniejszyć obciążenie (IE nie musi ponownie łatać za każdym razem, gdy jest aktualizacja).
4. Używałem wcześniej Unisona i jest naprawdę fajny, ale mógłbym przysiąc, że Unison zachowuje kopie w systemie plików i że jego pliki „archiwalne” mogą być dość duże?

Unison http://www.cis.upenn.edu/~bcpierce/unison/ twierdzi, że potrafi wykrywać ruchy i zmieniać nazwy.

Istnieje kilka łatek do rsync, aby dodać wykrywanie ruchu / zmiany nazwy:

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

Wpis Bugzilli śledzący ten problem: https://bugzilla.samba.org/show_bug.cgi?id=2294

To trochę dziwne rozwiązanie, ale ... git wykrywa ruchy i zmienia nazwy na podstawie zawartości pliku, więc jeśli miałbyś kontrolować katalogi, o których mowa, to git byłby w stanie wykryć ruchy i takie oraz uniknąć przeniesienia zawartość (ponieważ jest już po obu stronach drutu), a jednocześnie porusza się po drzewie.

Tylko myśl.

ciekawe sugestie tutaj. Zastanawiałem się także nad wykorzystaniem możliwości systemu plików, tj. ZFS. Dziwne było to, że nie ma narzędzia, które wykonałoby tę prostą rzecz. Opcja Unison nie działa w większości przypadków, jak zgłaszają ludzie, nie dla mnie.

Chcę, aby ta funkcja synchronizowała kopie zapasowe mojej kolekcji filmów na drugim dysku twardym podczas cofania folderów.

Teraz znalazłem ten prosty skrypt C http://sourceforge.net/projects/movesync/

Wydaje się, że działa dobrze. Uruchom go, a następnie zsynchronizuj normalnie z np. Unisonem.

Możliwe, że będziesz mógł użyć IDS opartych na hoście, takich jak AIDE i napisać skrypt opakowujący, używając jego danych wyjściowych. Prawdopodobnie będziesz musiał napisać bardziej złożoną logikę, biorąc pod uwagę sumy kontrolne.

W przeciwnym razie system plików oparty na sieci może mieć sens, ponieważ zmiany zostaną odzwierciedlone we wszystkich lokalizacjach. Niemniej jednak podejrzewam, że przenosisz się przez Internet, co ograniczy tutaj opcje.

Możesz spróbować jednomyślnie ; szczególnie

-xferbycopying optymalizuje transfery przy użyciu lokalnych kopii (domyślnie true)

opcja wymieniona w dokumentach jako

Po ustawieniu tej preferencji Unison spróbuje uniknąć przesyłania zawartości pliku przez sieć, rozpoznając, kiedy plik z wymaganą zawartością już istnieje w replice docelowej. Zwykle pozwala to na bardzo szybkie propagowanie ruchów plików. Wartość domyślna to true.

wygląda na to, że może zrobić to, co chcesz.

Syrep robi to, czego potrzebujesz. Utrzymuje aktualne podsumowania wiadomości w drzewie plików; utrzymywanie skrótów sprawia, że ​​jest bardziej wydajny niż rsync. Został zaprojektowany dla sneakernet, więc możesz chcieć dodać opakowanie, które aktualizuje / makepatch / scala jednocześnie.

Nie jestem pewien, czy istnieje narzędzie, które to robi za Ciebie, ale możesz napisać prosty skrypt, który po prostu uruchamia findw katalogu podstawowym, gdzie mtimejest nowszy niż ostatnia kopia zapasowa. Spowoduje to wyświetlenie listy wszystkich zmodyfikowanych plików . Jeśli plik został po prostu przeniesiony, nie pojawi się na liście. Niestety ta lista będzie zawierać katalogi, do których pliki zostały przeniesione, ponieważ katalog jest aktualizowany po dodaniu / usunięciu pliku.

Z tą listą plików możesz użyć rsync do synchronizacji tylko tych plików. rsync ma opcję odczytu z listy plików. Oto test pokazujący ten przykład:

$ 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

Pamiętaj, że od uruchomienia każdej findkomendy czekałem około 1 minuty . Z tego wynika, że ​​podczas początkowego tworzenia pliku zostaje wyświetlony na liście według find. Jeśli przeniosę plik do innego katalogu i ponownie uruchomię findpolecenie, wyświetli się tylko katalog, do którego przeniosłem plik, a nie sam plik. Możesz użyć kombinacji poleceń findi rsync, aby wyświetlić tylko te pliki, które chcesz, prawdopodobnie może to osiągnąć cel.

Mam nadzieję, że to pomoże.

Biorąc pod uwagę Twój przepływ pracy, zastanawiam się, czy praca na poziomie pliku (podobnie jak dotychczas zaproponowali inni) jest najlepszym rozwiązaniem. Możesz pracować ...

Na poziomie systemu plików

Chodzi o to, aby system plików śledził operacje między kopiami zapasowymi. Zamiast wykonać kopię zapasową systemu plików, wykonaj kopię zapasową dziennika systemu plików (i opcjonalnie odtwórz zmiany na komputerze kopii zapasowej, jeśli chcesz gotowej kopii zapasowej). Dziennik systemu plików naturalnie wyraża ruchy i usunięcia w kilku bajtach.

Bezpiecznik sprawia, że ​​stosunkowo łatwo jest zaprojektować system plików o określonych wymaganiach, który jest oparty na „prawdziwym systemie plików”. Nigdy go nie używałem, ale LoggedFS wygląda obiecująco.

Dzięki temu rozwiązaniu warto mieć jakąś formę kompresji dziennika. Na przykład, jeśli plik został nadpisany 10 razy, zachowaj tylko ostatnią aktualizację w dzienniku. Inną opłacalną optymalizacją byłoby rozpoznanie operacji kopiowania, a nawet lepiej edycji (tj. Utworzenie pliku, który jest w większości, ale nie całkowicie identyczny z innym plikiem). Nie wiem, czy ktoś to zaimplementował. W twoim przepływie pracy i tak nie sądzę, żeby miało to duże znaczenie.

Na poziomie głośności

Chodzi o to, aby menedżer woluminów śledził operacje między kopiami zapasowymi. Zamiast wykonać kopię zapasową systemu plików, wykonaj migawkę za pomocą menedżera woluminów i wykonaj kopię zapasową migawki wyrażonej jako różnica od poprzedniej migawki.

Powinno to działać dobrze, jeśli wszystko, co robisz, to tworzyć pliki, zmieniać ich nazwy i usuwać. Znacznie trudniej byłoby wykryć takie rzeczy, jak kopie i edycje, lub zoptymalizować tworzenie pliku, a następnie jego usunięcie.

Unison jest do tego dobry, ale nadal musi lokalnie kopiować pliki i nie może wykryć przeniesienia / zmiany nazwy, jeśli zawartość pliku zmieni się nawet trochę.

Stworzyłem prosty skrypt Pythona do wykrywania przemianowanych / przeniesionych plików i katalogów za pomocą numerów i-węzłów (tylko * nix) i odtworzenia tych zmian na zsynchronizowanym komputerze. Możesz użyć go samodzielnie lub jako „preprocesora zmiany nazwy” dla Unison lub rsync. Można go znaleźć tutaj