Co oznacza f +++++++++ oznacza w dziennikach rsync?

Używam rsyncdo tworzenia kopii zapasowej plików na serwerze i mam dwa pytania:

1. W połowie procesu muszę przerwać i zacząć od rsyncnowa.
   Zacznie się rsyncod miejsca, w którym się zatrzymał, czy też rozpocznie się od początku?

2. W plikach dziennika, które widzę "f+++++++++". Co to znaczy?

na przykład:

2010/12/21 08:28:37 [4537] >f.st...... iddd/logs/website-production-access_log
2010/12/21 08:29:11 [4537] >f.st...... iddd/web/website/production/shared/log/production.log
2010/12/21 08:29:14 [4537] .d..t...... iddd/web/website/production/shared/sessions/
2010/12/21 08:29:14 [4537] >f+++++++++ iddd/web/website/production/shared/sessions/ruby_sess.017a771cc19b18cd
2010/12/21 08:29:14 [4537] >f+++++++++ iddd/web/website/production/shared/sessions/ruby_sess.01eade9d317ca79a

Przyjrzyjmy się, jak działa rsync i lepiej zrozummy tajemnicze linie wyników:

1 - Ogromną zaletą rsync jest to, że po kolejnej przerwie działa płynnie.

Kolejne wywołanie rsync nie prześle ponownie plików, które zostały już przesłane, jeśli nie zostały one w międzyczasie zmienione. Ale zacznie ponownie sprawdzać wszystkie pliki od początku, aby się dowiedzieć, ponieważ nie jest świadomy, że zostało przerwane.

2 - Każdy znak to kod, który można przetłumaczyć, jeśli przeczytasz sekcję dotyczącą -i, --itemize-changeswman rsync

Dekodowanie przykładowego pliku dziennika z pytania:

> f.st ......

> - the item is received
f - it is a regular file
s - the file size is different
t - the time stamp is different

.d..t ......

. - the item is not being updated (though it might have attributes 
    that are being modified)
d - it is a directory
t - the time stamp is different

> f +++++++++

> - the item is received
f - a regular file
+++++++++ - this is a newly created item

Odpowiednia część strony podręcznika rsync:

-i, --itemize-changes

Żąda prostej szczegółowej listy zmian wprowadzanych w każdym pliku, w tym zmian atrybutów. To jest dokładnie to samo, co określenie --out-format = '% i% n% L'. Jeśli powtórzysz tę opcję, niezmienione pliki również zostaną wyprowadzone, ale tylko wtedy, gdy odbierający rsync ma co najmniej wersję 2.6.7 (możesz użyć -vv ze starszymi wersjami rsync, ale to również włączy wyjście innych pełnych komunikatów mędrcy).

Ucieczka „% i” ma tajemniczy wynik o długości 11 liter. Ogólny format jest podobny do ciągu YXcstpoguax, w którym Y jest zastępowane typem wykonywanej aktualizacji, X jest zastępowane typem pliku, a pozostałe litery reprezentują atrybuty, które mogą być wyprowadzane, jeśli są modyfikowane.

Typy aktualizacji, które zastępują Y, są następujące:

• A <oznacza, że ​​plik jest przesyłany do zdalnego hosta (wysyłany).
• A >oznacza, że ​​plik jest przesyłany do lokalnego hosta (odbierany).
• A coznacza, że ​​następuje lokalna zmiana / utworzenie elementu (na przykład utworzenie katalogu lub zmiana dowiązania symbolicznego itp.).
• A hoznacza, że ​​element jest twardym łączem do innego elementu (wymaga opcji --hard-links).
• A .oznacza, że ​​element nie jest aktualizowany (chociaż może mieć atrybuty, które są modyfikowane).
• A *oznacza, że ​​pozostała część wyszczególnionego obszaru wyjściowego zawiera komunikat (np. „Usuwanie”).

Typy plików, które zastępują X to: fdla pliku, a ddla katalogu, Ldla dowiązania symbolicznego, a Ddla urządzenia i Sdla pliku specjalnego (np. Nazwane gniazda i kolejki FIFO).

Pozostałe litery w powyższym ciągu to rzeczywiste litery, które zostaną wyświetlone, jeśli powiązany atrybut elementu jest aktualizowany lub „.” bez zmian. Trzy wyjątki od tej reguły to: (1) nowo utworzony element zastępuje każdą literę znakiem „+”, (2) identyczny element zastępuje kropki spacjami oraz (3) nieznany atrybut zastępuje każdą literę znakiem „?” (może się to zdarzyć podczas rozmowy ze starszą wersją rsync).

Atrybut powiązany z każdą literą jest następujący:

• A coznacza, że ​​zwykły plik ma inną sumę kontrolną (wymaga - sumy kontrolnej) lub że dowiązanie symboliczne, urządzenie lub plik specjalny ma zmienioną wartość. Zauważ, że jeśli wysyłasz pliki do rsync starszej niż 3.0.1, ta flaga zmiany będzie obecna tylko dla zwykłych plików różniących się sumą kontrolną.
• A soznacza, że ​​rozmiar zwykłego pliku jest inny i zostanie zaktualizowany podczas przesyłania pliku.
• A toznacza, że ​​czas modyfikacji jest inny i jest aktualizowany do wartości nadawcy (wymaga --times). Alternatywna wartość T oznacza, że ​​czas modyfikacji zostanie ustawiony na czas transferu, co ma miejsce, gdy plik / dowiązanie symboliczne / urządzenie jest aktualizowane bez --czasów i gdy dowiązanie symboliczne jest zmieniane, a odbiornik nie może ustawić swojego czasu. (Uwaga: podczas korzystania z klienta rsync 3.0.0, możesz zobaczyć flagę s połączoną z t zamiast odpowiedniej flagi T dla tego błędu ustawienia czasu).
• A poznacza, że ​​uprawnienia są różne i są aktualizowane do wartości nadawcy (wymaga --perms).
• An ooznacza właściciela jest inny i jest aktualizowany do wartości nadawcy (wymaga --owner i uprawnienia super użytkownika).
• A goznacza, że ​​grupa jest inna i jest aktualizowana do wartości nadawcy (wymaga --group i uprawnień do ustawienia grupy).
• uSzczelina jest zarezerwowana do wykorzystania w przyszłości.
• Te aśrodki, które informacje ACL zmieniło.
• Te xśrodki, które rozszerzone informacje atrybut zmieniły.

Możliwe jest jeszcze jedno wyjście: podczas usuwania plików "% i" wyświetli ciąg "* deleting" dla każdego usuwanego elementu (zakładając, że rozmawiasz z ostatnią dostateczną rsync, która rejestruje usunięcia zamiast wyprowadzać je jako szczegółowa wiadomość).

Jakiś czas temu musiałem zrozumieć dane rsyncwyjściowe skryptu, który pisałem. Podczas pisania tego scenariusza przeszukałem go i doszedłem do tego, co @mit napisał powyżej . Wykorzystałem te informacje, a także dokumentację z innych źródeł, do stworzenia własnego podkładu na temat flag bitowych i sposobu uzyskania rsyncflag bitowych dla wszystkich akcji (domyślnie nie robi tego).

Publikuję tutaj te informacje w nadziei, że pomogą one innym, którzy (tak jak ja) natkną się na tej stronie za pośrednictwem wyszukiwania i potrzebują lepszego wyjaśnienia rsync.

Dzięki połączeniu z --itemize-changesflagą i z -vvvflagą, rsyncdaje nam szczegółową wyjście wszystkich zmian systemu plików, które zostały zidentyfikowane w katalogu ze źródłami w porównaniu do katalogu docelowego. Flagi bitowe utworzone przez rsyncmożna następnie zdekodować, aby określić, co się zmieniło. Aby zdekodować znaczenie każdego bitu, skorzystaj z poniższej tabeli.

Wyjaśnienie pozycji każdego bitu i wartości w rsyncwyjściu:

YXcstpoguax  path/to/file
|||||||||||
||||||||||╰- x: The extended attribute information changed
|||||||||╰-- a: The ACL information changed
||||||||╰--- u: The u slot is reserved for future use
|||||||╰---- g: Group is different
||||||╰----- o: Owner is different
|||||╰------ p: Permission are different
||||╰------- t: Modification time is different
|||╰-------- s: Size is different
||╰--------- c: Different checksum (for regular files), or
||              changed value (for symlinks, devices, and special files)
|╰---------- the file type:
|            f: for a file,
|            d: for a directory,
|            L: for a symlink,
|            D: for a device,
|            S: for a special file (e.g. named sockets and fifos)
╰----------- the type of update being done::
             <: file is being transferred to the remote host (sent)
             >: file is being transferred to the local host (received)
             c: local change/creation for the item, such as:
                - the creation of a directory
                - the changing of a symlink,
                - etc.
             h: the item is a hard link to another item (requires 
                --hard-links).
             .: the item is not being updated (though it might have
                attributes that are being modified)
             *: means that the rest of the itemized-output area contains
                a message (e.g. "deleting")

Przykładowe dane wyjściowe rsync dla różnych scenariuszy:

>f+++++++++ some/dir/new-file.txt
.f....og..x some/dir/existing-file-with-changed-owner-and-group.txt
.f........x some/dir/existing-file-with-changed-unnamed-attribute.txt
>f...p....x some/dir/existing-file-with-changed-permissions.txt
>f..t..g..x some/dir/existing-file-with-changed-time-and-group.txt
>f.s......x some/dir/existing-file-with-changed-size.txt
>f.st.....x some/dir/existing-file-with-changed-size-and-time-stamp.txt 
cd+++++++++ some/dir/new-directory/
.d....og... some/dir/existing-directory-with-changed-owner-and-group/
.d..t...... some/dir/existing-directory-with-different-time-stamp/

Przechwytywanie rsyncwyjścia (skupione na flagach bitowych):

W moim eksperymentów zarówno --itemize-changesflag i-vvv flagi są potrzebne, aby dostać się rsyncdo wyjścia wpis dla wszystkich zmian w systemie plików. Bez -vvvflagi triple verbose ( ) nie widziałem listy zmian katalogu, łącza i urządzenia. Warto poeksperymentować z wersją rsync, aby upewnić się, że obserwuje i odnotowuje wszystko, czego się spodziewałeś.

Jednym z przydatnych zastosowań tej techniki jest dodanie --dry-runflagi do polecenia i zebranie listy zmian, określonej przez rsync, w zmiennej (bez dokonywania żadnych zmian), aby można było samodzielnie wykonać pewne przetwarzanie listy. Coś podobnego do poniższego przechwyciłoby dane wyjściowe w zmiennej:

file_system_changes=$(rsync --archive --acls --xattrs \
    --checksum --dry-run \
    --itemize-changes -vvv \
    "/some/source-path/" \
    "/some/destination-path/" \
| grep -E '^(\.|>|<|c|h|\*).......... .')

W powyższym przykładzie wyjście (stdout) z rsyncjest przekierowywane do grep(przez stdin), więc możemy izolować tylko te wiersze, które zawierają flagi bitowe.

Przetwarzanie przechwyconych danych wyjściowych:

Zawartość zmiennej można następnie rejestrować w celu późniejszego wykorzystania lub natychmiastowo iterować pod kątem interesujących nas elementów. Używam dokładnie tej taktyki w scenariuszu, o którym pisałem podczas badania rsync. Możesz spojrzeć na skrypt ( https://github.com/jmmitchell/movestough ), aby zobaczyć przykłady przetwarzania końcowego przechwyconych danych wyjściowych w celu wyodrębnienia nowych plików, zduplikowanych plików (ta sama nazwa, ta sama zawartość), kolizji plików (ta sama nazwa, różne zawartość), a także zmiany w strukturze podkatalogów.

1) Wodin, to nie do końca prawda. Jeśli używasz tagu --partial lub -P (tak samo jak --partial --progress), rsync wznawia przerwane transfery.

2) Dokładnie, to typowe dane wyjściowe dla tagu --itemize-changes.

1.) „Zrestartuje synchronizację”, ale nie prześle plików o tym samym rozmiarze i sygnaturze czasowej itp. Najpierw tworzy listę plików do przesłania i na tym etapie zobaczy, że przesłał już niektóre pliki i pominie je. Powinieneś powiedzieć rsync, aby zachował znaczniki czasu itp. (Np. Używając rsync -a ...)

Podczas gdy rsync przesyła plik, będzie nazywać go czymś w rodzaju .filename.XYZABCzamiast filename. Następnie, gdy zakończy przesyłanie tego pliku, zmieni jego nazwę. Tak więc, jeśli zabijesz rsync podczas przesyłania dużego pliku, będziesz musiał użyć opcji --partial, aby kontynuować transfer zamiast zaczynać od zera.

2.) Nie wiem, co to jest. Czy możesz wkleić kilka przykładów?

EDYCJA: Zgodnie z http://ubuntuforums.org/showthread.php?t=1342171 te kody są zdefiniowane na stronie podręcznika rsync w sekcji dotyczącej -i, --itemize-changesopcji.

Naprawiono część, jeśli moja odpowiedź była oparta na odpowiedzi Joao