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

15

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?
Pharaun
źródło

Odpowiedzi:

7

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

Mark Wagner
źródło
6
Dlaczego te łatki nie są zintegrowane? Po prostu dodają flagi, nie są nachalne. Kolejną interesującą łatką jest rsyncsums , która może przechowywać sumy kontrolne pomiędzy uruchomieniami rsync.
Tobu,
5

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.

pjz
źródło
2
Tak. Rozważyłem to, jeśli pliki byłyby małe i oparte na tekście, prawdopodobnie działałoby to dobrze, ale są binarne, a całkowity rozmiar zbliża się do terabajta.
Pharaun
@ Pharaun Potrzebujesz indeksu git bez magazynu obiektów blob. Może zgarnij ten kod z git i dodaj go do libgit2.
Tobu,
Odpowiedni kod zaczyna się od refresh_index w read-cache.c.
Tobu,
5

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.

groovehunter
źródło
4

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.

Warner
źródło
Właśnie o tym myślałem, biorąc jeden z nich i rozszerzając je. Także tak, przesyłam to przez Internet, a przepustowość jest dość ograniczona.
Pharaun
3

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.

pjz
źródło
Właściwie z perspektywy czasu mogłem być zbyt pochopny w związku z tym komentarzem. Czy unison obsługuje zamianę twardego łącza na rzeczywistą zawartość pliku, jeśli się zmieni? Jeśli tak, to mogę być w stanie wykonać magię za pomocą rsnapshot + unison, która spełniłaby moje wymagania bez konieczności pisania tony nowego kodu / dziennika / etc, aby sobie z tym poradzić.
Pharaun
3

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.

Tobu
źródło
2

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.

vmfarms
źródło
2

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.

Gilles „SO- przestań być zły”
źródło
Właściwie pracowałem trochę nad logerem „systemowym” pliku przez inotify, aby śledzić zmiany, ale jeśli zmiany pojawią się szybciej niż prędkość, którą demon może to nagrać, utraci informacje, dlatego trzeba zbudować kopie zapasowe / skanowanie, aby uzyskać stan początkowy i w przypadku powiadomienia utraty informacji. Wygląda na to, że pomysł posiadania czegoś, co znajduje się między systemem plików a resztą systemu, może być dobrym pomysłem, niż jak powiedziałeś, że zmiany można odtworzyć na komputerze kopii zapasowej.
Pharaun
Ale ten logfFS wygląda na interesujący projekt, jedyne, co martwi, to, że przestali programować w sezonie 2008/09. Będę musiał się z nią bawić i sprawdzić, czy to załatwi sprawę.
Pharaun
0

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

rolicot
źródło