Zacznij od rsync -ai --dry-run -e "ssh -p PORT_SSH" /sciezka/do/katalogu/ uzytkownik@host:/sciezka/do/katalogu/. Pierwsza ścieżka to źródło, druga to cel. Przeczytaj pełne ścieżki w planie zmian, a potem usuń wyłącznie --dry-run. Opcję --delete dodasz na końcu, w osobnej próbie.
Ten wzorzec - najpierw próba, potem wykonanie, na końcu kontrola - wraca w każdym scenariuszu na tej stronie. Rsync nie ma przycisku „cofnij", więc jedyny moment, w którym zatrzymasz złą synchronizację, jest przed nią.
Bezpieczny wzorzec między dwoma serwerami
Rsync kopiuje pliki lokalnie albo między hostem lokalnym i jednym hostem zdalnym. Transferu, w którym źródło i cel są jednocześnie zapisane jako dwa hosty zdalne, nie wykonasz - polecenie uruchamiasz na serwerze źródłowym, a zapis idzie na cel przez SSH. Rsync musi być zainstalowany po obu stronach.
PORT_SSH, uzytkownik@host i /sciezka/do/katalogu/ to placeholdery - podstaw swój port SSH, konto zdalne i rzeczywiste ścieżki. Gdy samo połączenie jeszcze nie wchodzi, zacznij od procedury logowania i diagnostyki SSH, zanim uruchomisz transfer. Końcowy slash przy obu katalogach jest zamierzony, a katalog docelowy powinien istnieć.
Najpierw wykonaj próbę.
rsync -ai --dry-run -e "ssh -p PORT_SSH" \
/sciezka/do/katalogu/ \
uzytkownik@host:/sciezka/do/katalogu/--dry-run niczego nie zmienia. Opcja -i, czyli --itemize-changes, wypisuje dla każdego aktualizowanego elementu, co dokładnie się zmieni. Czytaj całe ścieżki, nie pierwszą linię wyniku - błędny cel potrafi ujawnić się dopiero w środku listy. Jeśli źródło, cel i plan się zgadzają, uruchom odpowiadające polecenie wykonawcze:
rsync -ai -e "ssh -p PORT_SSH" \
/sciezka/do/katalogu/ \
uzytkownik@host:/sciezka/do/katalogu/-a to skrót -rlptgoD: włącza rekursję i zachowuje między innymi dowiązania, uprawnienia, czas modyfikacji, grupę, właściciela, urządzenia oraz pliki specjalne. Nie obejmuje ACL, atrybutów rozszerzonych, czasu dostępu, czasu utworzenia ani wykrywania twardych dowiązań. To, czy właściciel i grupa faktycznie się zachowają, zależy też od uprawnień procesu odbierającego.
Jak rsync wybiera pliki do przesłania?
Domyślnie rsync porównuje rozmiar i czas ostatniej modyfikacji - to tak zwany quick check. Plik zakwalifikowany do aktualizacji nie musi jechać w całości, bo algorytm transferu potrafi przesłać same różnice względem wersji istniejącej na celu. Lista plików i porównanie drzewa powstają jednak przy każdym uruchomieniu, więc nie licz na gwarantowany czas kolejnego przebiegu.
Opcja --checksum zaostrza kontrolę przed transferem: dla plików o zgodnym rozmiarze porównuje sumę zawartości zamiast czasu modyfikacji, co wymaga odczytu danych po obu stronach. W testach niżej używamy jej jako mocniejszego sprawdzenia zawartości - nie jako dowodu, że aplikacja działa, ani że elementy wyłączone filtrami są w porządku.
Jednorazowe przerzucenie plików na nowy serwer to inny temat - opisujemy je osobno. Tutaj zostajesz przy synchronizacji serwer - serwer, w której źródło i cel są jawnie ustalone.
Slash na końcu źródła zmienia wynik
Jedna kreska rozstrzyga, czy kopiujesz zawartość katalogu, czy katalog razem z jego nazwą. Poniższy przykład dotyczy katalogu docelowego, który już istnieje. Na źródle znajduje się takie drzewo.
/sciezka/do/katalogu/
|-- index.html
|-- config/
| `-- app.conf
`-- public/
`-- asset.cssŹródło ze slashem oznacza kopiowanie zawartości katalogu.
rsync -ai --dry-run /sciezka/do/katalogu/ /sciezka/do/celu//sciezka/do/celu/
|-- index.html
|-- config/
| `-- app.conf
`-- public/
`-- asset.cssBez slasha rsync kopiuje katalog pod jego nazwą i w celu powstaje dodatkowy poziom.
rsync -ai --dry-run /sciezka/do/katalogu /sciezka/do/celu//sciezka/do/celu/
`-- katalogu/
|-- index.html
|-- config/
| `-- app.conf
`-- public/
`-- asset.cssKońcowy slash celu zabezpiecza też zamiar utworzenia katalogu, gdy lista transferu zawiera pojedynczy element. Bez niego nieistniejący cel może zostać potraktowany jako nowa nazwa tego elementu.
| Decyzja | Wynik w pokazanej parze katalogów |
|---|---|
Źródło /sciezka/do/katalogu/ |
zawartość trafia bezpośrednio do istniejącego celu |
Źródło /sciezka/do/katalogu |
w istniejącym celu powstaje poziom katalogu/ |
Dodane --delete |
nadmiarowe elementy są usuwane z katalogów celu objętych synchronizacją |
--delete ze zwykłym wykluczeniem |
elementy pasujące do wykluczenia są domyślnie chronione przed usunięciem |
--delete-excluded |
niekwalifikowane reguły tracą domyślną ochronę po stronie odbiorcy |
Trzy scenariusze serwerowe
Każdy scenariusz rozdziela to samo pięć razy: źródło, cel, próbę, wykonanie i kontrolę po transferze. PLIK_FILTROW, IDENTYFIKATOR_KOPII oraz WERSJA_WYDANIA to placeholdery zależne od twojego środowiska.
Synchronizacja katalogu aplikacji na drugi host
Źródłem jest /sciezka/do/aplikacji/ na serwerze, na którym uruchamiasz polecenie. Celem jest /sciezka/do/aplikacji/ na uzytkownik@host. Do PLIK_FILTROW wpisz wyłącznie reguły zatwierdzone dla tej konkretnej aplikacji. Nie zakładaj z góry, że cache albo pliki z określonym rozszerzeniem wolno pominąć - to decyzja podejmowana per aplikacja, nie odruch.
Najpierw wyświetl plan zmian bez zapisu na celu.
rsync -ai --dry-run -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/aplikacji/ \
uzytkownik@host:/sciezka/do/aplikacji/Gdy plan się zgadza, uruchom polecenie wykonawcze.
rsync -ai -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/aplikacji/ \
uzytkownik@host:/sciezka/do/aplikacji/Na koniec uruchom osobną kontrolę z --checksum i tym samym plikiem filtrów.
rsync -aic --dry-run -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/aplikacji/ \
uzytkownik@host:/sciezka/do/aplikacji/Brak wpisów o zmianach oznacza, że w chwili kontroli rsync nie planuje aktualizacji zawartości ani atrybutów objętych -a dla elementów dopuszczonych przez te filtry. Nie mówi nic o wykluczonych ścieżkach, ACL, atrybutach rozszerzonych ani o tym, czy aplikacja działa.
Kopia plików do hosta backupowego
Źródłem jest /sciezka/do/danych/ na serwerze wykonującym polecenie. Celem jest osobny katalog /sciezka/do/kopii/IDENTYFIKATOR_KOPII/ na uzytkownik@host. Rodzic katalogu docelowego ma istnieć, a IDENTYFIKATOR_KOPII ma nadawać twój proces backupu, nie ręcznie dobrana wartość z poradnika.
Zacznij od próby.
rsync -ai --dry-run -e "ssh -p PORT_SSH" \
/sciezka/do/danych/ \
uzytkownik@host:/sciezka/do/kopii/IDENTYFIKATOR_KOPII/Po akceptacji planu wykonaj kopię.
rsync -ai -e "ssh -p PORT_SSH" \
/sciezka/do/danych/ \
uzytkownik@host:/sciezka/do/kopii/IDENTYFIKATOR_KOPII/Kopię traktuj jako sprawdzoną dopiero po próbie odtworzenia. Odtwórz dane do pustego, odizolowanego katalogu /sciezka/do/testu-odtworzenia/, a następnie porównaj wynik ze źródłem:
rsync -ai -e "ssh -p PORT_SSH" \
uzytkownik@host:/sciezka/do/kopii/IDENTYFIKATOR_KOPII/ \
/sciezka/do/testu-odtworzenia/
rsync -aic --dry-run --delete \
/sciezka/do/danych/ \
/sciezka/do/testu-odtworzenia/Druga komenda tylko planuje zmiany. Pusty plan mówi, że drzewo i atrybuty z -a się zgadzają - nie mówi, czy aplikacja umie z tych danych skorzystać. Wynik niepusty porównuj z punktem w czasie, z którego powstała kopia, bo żywe źródło mogło się zmienić po transferze. Katalog per wykonanie nie daje jeszcze retencji ani izolacji - te decyzje należą do procesu backupu serwera, a zakres próby odtworzeniowej opisujemy osobno.
Wdrożenie do katalogu wydania
Źródłem jest gotowy katalog /sciezka/do/build/. Celem jest nieużywany jeszcze przez aplikację katalog /sciezka/do/releases/WERSJA_WYDANIA/ na uzytkownik@host. WERSJA_WYDANIA identyfikuje artefakt w twoim procesie wydawniczym.
Obejrzyj plan zmian bez zapisu na celu.
rsync -ai --dry-run -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/build/ \
uzytkownik@host:/sciezka/do/releases/WERSJA_WYDANIA/Po zaakceptowaniu planu uruchom polecenie wykonawcze.
rsync -ai -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/build/ \
uzytkownik@host:/sciezka/do/releases/WERSJA_WYDANIA/Osobna kontrola porównuje zawartość i pokazuje także elementy nadmiarowe w katalogu wydania. --delete pozostaje tu spięte z --dry-run, więc test niczego nie usuwa:
rsync -aic --dry-run --delete -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/build/ \
uzytkownik@host:/sciezka/do/releases/WERSJA_WYDANIA/Przełączenie dowiązania current to zewnętrzny etap wdrożenia, zależny od serwera WWW, procesów aplikacji, migracji i mechanizmu wycofania. Te komendy weryfikują katalog plików - nie dowodzą dostępności aplikacji i nie obiecują braku przerwy w działaniu.
Jak używać --delete, żeby niczego nie stracić?
--delete usuwa po stronie odbiorcy elementy nieobecne po stronie nadawcy, ale tylko w katalogach objętych synchronizacją. Zanim go dotkniesz, zobacz, jak wygląda wpadka złożona z klasycznych błędów wokół tej opcji.
Wieczorne wdrożenie, administrator wyciąga z historii powłoki sprawdzone wcześniej polecenie z
--delete. Tyle że ostatnim razem odtwarzał kopię w drugą stronę i ścieżki stoją odwrotnie: kopia jest nadawcą, produkcja odbiorcą. Rsync robi dokładnie to, o co go poproszono - dosynchronizowuje stary stan i kasuje z produkcji wszystko, czego nie ma w kopii. Żaden komunikat nie pyta „czy na pewno". Jedyną zaporą była próba z--dry-run, której tym razem nikt nie przeczytał.
Dlatego kolejność jest zawsze ta sama:
- Ustal, który host jest nadawcą, a który odbiorcą - kasowanie zachodzi na odbiorcy.
- Zabezpiecz stan celu mechanizmem właściwym dla twojego systemu, na przykład snapshotem.
- Uruchom pełne polecenie z
--delete,--dry-runi-i. - Przeczytaj wszystkie wpisy
*deletingoraz pełne ścieżki aktualizowanych elementów. - Sprawdź plik filtrów i stronę działania każdej reguły.
- Dopiero po akceptacji planu usuń
--dry-run, nie zmieniając pozostałych argumentów.
Nie podawaj źródła wzorcem powłoki w rodzaju /sciezka/do/katalogu/*, jeśli oczekujesz obsługi nadmiarowych plików całego katalogu - powłoka rozwinie wzorzec i przekaże rsync pojedyncze elementy zamiast katalogu.
Próbę kasowania wykonaj dla ustalonego kierunku.
rsync -ai --dry-run --delete -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/katalogu/ \
uzytkownik@host:/sciezka/do/katalogu/Po zaakceptowaniu wszystkich wpisów uruchom odpowiadające polecenie wykonawcze bez --dry-run.
rsync -ai --delete -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/katalogu/ \
uzytkownik@host:/sciezka/do/katalogu/Zwykła reguła --exclude, --include albo niekwalifikowana reguła filtra działa domyślnie po obu stronach: pomija pasujące elementy w liście nadawcy i chroni pasujące elementy odbiorcy przed --delete. --delete-excluded zmienia niekwalifikowane reguły na działające tylko po stronie nadawcy, więc ochrona odbiorcy znika. Ten sam skutek dla pojedynczej reguły daje modyfikator s, czyli reguła tylko po stronie nadawcy. Modyfikator r i reguła protect działają na odbiorcy i mogą chronić elementy przed usunięciem. Gdy pracujesz nad filtrami, dodaj -vv albo --debug=FILTER, a rsync wskaże, która reguła złapała który element.
Odwrócony kierunek obejrzysz bez zmiany danych w poniższej próbie.
rsync -ai --dry-run --delete -e "ssh -p PORT_SSH" \
uzytkownik@host:/sciezka/do/stanu-kopii/ \
/sciezka/do/katalogu-produkcyjnego/Tutaj katalog produkcyjny jest odbiorcą i każdy element obecny wyłącznie w nim kwalifikuje się jako nadmiarowy w zakresie synchronizacji. Jeśli to nie jest zamierzony kierunek odtworzenia, nie uruchamiaj wariantu bez --dry-run.
Co się psuje
Najpierw odczytaj standard error i kod wyjścia rsync, dopiero potem przypisuj przyczynę. Zero oznacza sukces procesu według rsync, a kod różny od zera identyfikuje klasę błędu opisaną w man page. Żaden z nich nie jest samodzielnym dowodem poprawności backupu ani działania aplikacji.
| Objaw | Następny test i miejsce wykonania |
|---|---|
| rsync zgłasza błąd zapisu lub odczytu | Na hoście wskazanym w komunikacie sprawdź konto procesu oraz prawa do konkretnej ścieżki. -a nie omija ograniczeń uprawnień. |
| stderr wskazuje błąd operacji plikowej | Na odbiorcy sprawdź wolne miejsce i pulę inode systemu plików zawierającego cel. Nie diagnozuj braku miejsca z samego faktu przerwania. |
| sesja SSH została przerwana | Odczytaj kod i stderr na hoście uruchamiającym rsync. Pokazany scenariusz nie zachowuje pliku częściowego, więc po usunięciu przyczyny ponów tę samą komendę dla pełnego zakresu. |
| element źródłowy znika podczas przebiegu | Sprawdź kod i listę znikających ścieżek na nadawcy. Man page klasyfikuje taki stan jako transfer częściowy z powodu zniknięcia plików źródłowych. |
| dane źródłowe zmienia aplikacja | Przygotuj spójny punkt wejścia metodą właściwą dla aplikacji przed rsync. Pokazane polecenia nie zatrzymują zapisów i nie tworzą snapshotu aplikacyjnego. |
| właściciel albo grupa na celu nie odpowiada wymaganiom procesu | Na odbiorcy porównaj właściciela i grupę z kontem uruchamiającym usługę. Zachowanie właściciela wymaga odpowiednich uprawnień, a grupy - prawa do ustawienia danej grupy. |
Kod wyjścia to warunek podstawowy, nie jedyny sygnał. Do oceny przebiegu masz jeszcze stderr, wynik -i, log oraz osobną próbę porównawczą po transferze.
Automatyzacja bez cichej awarii
Cron albo timer systemd uruchomi wrapper o czasie, ale harmonogram nie sprawdzi za ciebie, czy kopia daje się odtworzyć. Poniższy skrypt zapisuje standard output i standard error rsync do PLIK_LOGU, zachowuje kod błędu i przekazuje go systemowi uruchamiającemu:
#!/bin/sh
if rsync -ai -e "ssh -p PORT_SSH" \
--exclude-from=PLIK_FILTROW \
/sciezka/do/katalogu/ \
uzytkownik@host:/sciezka/do/katalogu/ >> PLIK_LOGU 2>&1
then
:
else
KOD_RSYNC=$?
printf 'rsync zakończył się kodem %s\n' "$KOD_RSYNC" >&2
exit "$KOD_RSYNC"
fiPLIK_LOGU to placeholder ścieżki do logu. Niezerowy status wrappera musi ktoś zamienić w alarm, a na alarm musi ktoś reagować - skrypt sam nie wysyła powiadomień i nie definiuje retencji logu. Automatyzacja bez tych dwóch rzeczy psuje się po cichu i nikt nie wie od kiedy.
Czy rsync wystarczy jako backup?
Rsync skopiuje pliki do katalogu backupowego, ale pokazane polecenie nie ustanawia retencji, izolacji ani kryterium odtworzenia. Lustro z --delete odwzorowuje na celu również usunięcia ze źródła - plik skasowany na produkcji zniknie z kopii przy następnym przebiegu, w zakresie synchronizowanych katalogów. Historię stanów budujesz oddzielnymi katalogami, snapshotami albo innym mechanizmem zarządzanym poza tą komendą.
Pełny proces backupu serwera - z retencją, izolacją i testem odtworzenia - opisujemy osobno. O użyteczności kopii rozstrzyga udane odtworzenie, nie pusty wynik kolejnego przebiegu z --dry-run.
Pytania o rsync
Czym jest rsync?
Rsync to narzędzie do lokalnego i zdalnego kopiowania plików, które przesyła tylko elementy wymagające aktualizacji. W transferze zdalnym pracuje przez remote shell, w tym SSH, albo łączy się z demonem rsync. W tym poradniku używamy wyłącznie wariantu przez SSH, uruchamianego na jednym serwerze z drugim hostem jako celem lub źródłem.
Czy rsync jest bezpieczny?
W pokazanych komendach transport szyfruje SSH wybrane opcją -e, więc dane w drodze są chronione. Ryzyko zostaje po stronie operacyjnej: kierunek transferu, prawa konta, filtry i --delete. --dry-run pokazuje plan bez zmian - pod warunkiem, że przeczytasz go dla pełnych ścieżek i z tymi samymi opcjami, które trafią do wykonania.
Dlaczego rsync przesyła plik, którego nie zmieniałem?
Quick check porównuje rozmiar i czas ostatniej modyfikacji, więc wystarczy, że jakieś narzędzie po drodze odświeżyło znacznik czasu, a plik zakwalifikuje się do aktualizacji. Uruchom próbę z -i i odczytaj, który atrybut się różni. Kontrolę po zawartości wymusisz opcją --checksum, kosztem odczytu danych po obu stronach.
Czym różni się protokół rsync od transportu SSH?
Protokół rsync uzgadnia między hostami dane potrzebne do odtworzenia aktualizowanego pliku na odbiorcy. Transport to kanał, którym te dane płyną - i nie należy ich utożsamiać. Zapis uzytkownik@host:/sciezka/do/katalogu/ z pojedynczym dwukropkiem wybiera remote shell, a -e "ssh -p PORT_SSH" wskazuje, że tym kanałem jest SSH na konkretnym porcie.
Czy rsync wystarczy do backupu serwera?
Wystarczy jako warstwa kopiowania plików. Pokazane polecenia nie definiują retencji, izolacji kopii, zasad dostępu ani testu aplikacyjnego po odtworzeniu. Kod sukcesu rsync jest więc jednym dowodem technicznym w procesie backupu, a nie potwierdzeniem, że serwer da się odtworzyć.
Źródło techniczne i granica odpowiedzi
Twierdzenia o składni i zachowaniu rsync zweryfikowaliśmy w oficjalnym man page projektu, w sekcjach DESCRIPTION, GENERAL, USAGE, OPTIONS, FILTER RULES i EXIT VALUES:
https://download.samba.org/pub/rsync/rsync.1
Ta strona pokazuje rsync w pracy serwer - serwer: synchronizację katalogu aplikacji, kopię na host backupowy i wdrożenie do katalogu wydania. Pełną listę opcji utrzymuje projekt rsync pod adresem powyżej. Retencję i test odtworzenia, podobnie jak jednorazowe przeniesienie plików na nowy serwer, opisujemy w osobnych tekstach. Pozostałe narzędzia do pracy na plikach serwera zebraliśmy w jednym miejscu.