rsync to narzędzie wiersza poleceń do synchronizacji i backupu plików między katalogami lub komputerami - lokalnie i przez SSH. Kopiuje tylko to, co się zmieniło (algorytm delta-transfer), dzięki czemu jest szybkie i oszczędza transfer. Podstawowa komenda: rsync -av zrodlo/ cel/.

W skrócie: rsync to koń roboczy każdego admina - od kopii zapasowej dokumentów, przez mirror dysku, po deploy strony na serwer. Poniżej rozkładam flagi na czynniki pierwsze, pokazuję gotowe komendy do skopiowania i tłumaczę, gdzie rsync potrafi cicho skasować dane, jeśli zapomnisz o jednym ukośniku.

rsync w skrócie - kiedy zamiast cp i scp

Trzy narzędzia do kopiowania plików, ale robią różne rzeczy. Konkret w tabeli:

Trade-off: cp i scp są prostsze i wystarczą do jednorazowego skopiowania. rsync wygrywa wszędzie tam, gdzie kopiujesz wielokrotnie ten sam zestaw plików - drugi i każdy kolejny przebieg dotyka tylko tego, co się zmieniło, więc trwa sekundy zamiast godzin. Do backupu, mirrora i deploya to fundamentalna różnica.

Czym jest rsync i jak działa algorytm delta-transfer

rsync to otwarte, darmowe narzędzie z rodziny Unix, stworzone przez Andrew Tridgella i Paula Mackerrasa (dane projektu). Jest preinstalowane w większości dystrybucji Linuksa i w macOS, więc na serwerze zwykle masz je od ręki - rsync --version to potwierdzi.

Sercem rsync jest algorytm delta-transfer. Zamiast wysyłać cały plik od nowa, rsync dzieli plik po stronie odbiorcy na bloki (hash bloku ma około 1 kB), liczy dla nich sumy kontrolne i porównuje je z blokami źródła za pomocą sumy przesuwnej (rolling checksum). Przez sieć leci wtedy tylko to, co faktycznie się różni - reszta jest składana z bloków, które odbiorca już ma. To dlatego drobna zmiana w wielkim pliku oznacza transfer kilku kilobajtów, nie całości.

Na starcie rsync używa quick check - najpierw porównuje rozmiar i czas modyfikacji plików. Jeśli oba się zgadzają, plik jest pomijany bez liczenia sum kontrolnych. To ten mechanizm sprawia, że drugie uruchomienie tej samej synchronizacji przelatuje przez tysiące niezmienionych plików w ułamku czasu. Delta-transfer wchodzi do gry dopiero dla plików, które quick check uzna za zmienione.

Konkret: pierwszy przebieg rsync kopiuje wszystko i trwa tyle, co zwykłe kopiowanie. Prawdziwa oszczędność zaczyna się od drugiego uruchomienia - i to jest cała magia tego narzędzia.

Składnia i najważniejsze flagi

Schemat komendy jest stały: rsync [opcje] ZRODLO CEL. Źródło i cel to katalogi lokalne albo zdalne (user@host:/sciezka). Cała siła rsync siedzi w flagach - oto te, których używasz codziennie:

W praktyce 90% zadań pokrywa jeden zestaw: -avz do transferu plus -P na pasek postępu przy większych paczkach. Resztę dokładasz sytuacyjnie.

Flaga --dry-run - najpierw sprawdź, potem kopiuj

Pro tip admina: zanim odpalisz cokolwiek z --delete albo cokolwiek na produkcji, uruchom to samo z --dry-run. rsync policzy i wypisze pełną listę operacji, ale niczego nie tknie.

# symulacja - zobacz, co się stanie, bez zmian na dysku
rsync -avn --delete ./strona/ user@serwer:/var/www/strona/

Sprawdź listę, a dopiero gdy się zgadza, usuń -n i puść na serio. Ten jeden nawyk uratował więcej danych niż jakikolwiek backup.

Flaga --delete - potężna i niebezpieczna

--delete robi z celu wierne lustro źródła: kasuje w celu wszystko, czego nie ma w źródle. To dokładnie to, czego chcesz przy mirrorze - i dokładnie to, co potrafi wyczyścić backup, jeśli podasz złe źródło.

Ostrzeżenie: --delete bez wcześniejszego --dry-run to najprostsza droga do skasowania danych, które chciałeś zachować. Jeśli pomylisz kierunek albo podasz pusty katalog źródłowy, rsync posłusznie opróżni cel. Zasada admina jest jedna: --delete zawsze najpierw na sucho.

Flaga --exclude - pomijanie plików i katalogów

Przy synchronizacji projektu nie chcesz wieźć node_modules, .git czy cache. Wykluczasz je flagą --exclude:

# pomiń katalogi ciezkie i nieistotne dla backupu kodu
rsync -avz --exclude 'node_modules' --exclude '.git' --exclude '*.log' \
  ./projekt/ user@serwer:/var/www/projekt/

Gdy wzorców jest dużo, wygodniej trzymać je w pliku i wczytać jednym --exclude-from=.rsyncignore. Każdy wzorzec w osobnej linii - działa jak .gitignore.

Znaczenie ukośnika końcowego - najczęstsza pułapka

Ukośnik na końcu źródła zmienia zachowanie rsync i to potyka niemal każdego na starcie:

• rsync -a zrodlo/ cel/ - kopiuje zawartość katalogu zrodlo do cel. Pliki lądują bezpośrednio w cel.
• rsync -a zrodlo cel/ - kopiuje sam katalog zrodlo do środka cel. Dostajesz cel/zrodlo/....

Konkret: ukośnik przy celu nie ma znaczenia, liczy się tylko ukośnik przy źródle. Jeśli po synchronizacji pliki wylądowały o jeden katalog za głęboko, to prawie na pewno brakujący albo nadmiarowy ukośnik. Zapamiętaj raz, oszczędzisz sobie godziny zdziwienia.

rsync lokalnie - synchronizacja katalogów

Zacznijmy od gruntu, czyli kopii między katalogami na tej samej maszynie. Backup katalogu dokumentów na dysk zewnętrzny:

# kopia dokumentow na dysk zewnetrzny, z paskiem postepu
rsync -avh --progress ~/Dokumenty/ /mnt/dysk-zewnetrzny/backup-dokumenty/

Po zakończeniu rsync wypisuje podsumowanie transferu - liczbę plików, ile danych realnie poleciało i jaka była przyspieszenie względem kopii pełnej:

sent 2,14M bytes  received 1,20K bytes  1,43M bytes/sec
total size is 512M  speedup is 239.10

To speedup to właśnie efekt delta-transfer: przy drugim przebiegu wysłano ułamek całości, bo reszta była już na miejscu i niezmieniona. Jeśli chcesz zrobić dokładne lustro dysku (cel ma być identyczny ze źródłem, łącznie z usuwaniem zbędnych plików), dokładasz --delete - ale zgodnie z regułą wyżej, najpierw na sucho.

rsync przez SSH - zdalny backup i deploy

Tu rsync pokazuje pełnię możliwości. Domyślnym kanałem transportu dla połączeń zdalnych jest SSH, więc kopia na serwer to po prostu podanie zdalnego celu w formacie user@host:/sciezka:

# deploy katalogu projektu na serwer przez SSH, z kompresja
rsync -avz ./projekt/ user@serwer:/var/www/projekt/

Flaga -z włącza kompresję w locie, co ma sens przez wolniejsze łącza. Ruch idzie szyfrowanym kanałem SSH - te same klucze i ta sama konfiguracja, na której opiera się logowanie do serwera. Jeśli dopiero zaczynasz z pracą zdalną, warto najpierw ogarnąć logowanie kluczem i podstawy SSH - z rsync spina się to jednym parametrem ProxyJump.

To zależy od ruchu: zdalny backup ma sens tylko wtedy, gdy masz dokąd go wysyłać. Domowy dysk nie zdejmie kopii poza dom, a to on ratuje dane przy pożarze czy kradzieży. Tani VPS jako zdalny target backupu rozwiązuje to za kilkanaście złotych miesięcznie i daje kontrolę, której nie ma pudełkowa chmura. Jeśli dobierasz maszynę pod backup i zadania DevOps, sprawdź porównanie VPS pod backup i automatyzację - dobierzesz zasoby pod realną objętość danych, bez przepłacania.

Automatyczny backup - rsync plus cron

Backup robiony ręcznie to backup, którego prędzej czy później nie zrobisz. Konkret: spinasz rsync z harmonogramem i zapominasz o sprawie. Najprostszy skrypt backupowy wygląda tak:

#!/bin/bash
# backup.sh - nocna kopia danych na zdalny serwer
rsync -az --delete \
  --exclude 'cache' \
  /var/www/dane/ user@serwer:/backup/dane/

Wpis w cronie uruchamia go codziennie o trzeciej w nocy:

0 3 * * * /home/user/backup.sh >> /var/log/backup.log 2>&1

Składnię wpisu i pułapki (PATH, pełne ścieżki, logowanie wyjścia) rozkładam osobno we wpisie o zadaniach cyklicznych w cronie do już istniejącego pliku. Efekt: masz kilkanaście dziennych migawek, a miejsce zajmują tylko zmiany plus jedna pełna kopia.

#!/bin/bash
# snapshot dzienny - niezmienione pliki linkuja sie do wczorajszej kopii
DZIS=$(date +%Y-%m-%d)
rsync -a --delete \
  --link-dest=/backup/latest \
  /var/www/dane/ /backup/$DZIS/
ln -nsf /backup/$DZIS /backup/latest

Każdy katalog /backup/RRRR-MM-DD wygląda jak kompletna kopia i możesz z niego przywrócić pojedynczy plik bez rozpakowywania czegokolwiek - a na dysku zajmuje ułamek tego, co sugeruje liczba migawek. To wzorzec, na którym stoją domowe rozwiązania backupu w stylu Time Machine.

Częste błędy i pułapki

Większość problemów z rsync to nie awarie, tylko powtarzalne potknięcia. Oto te, które łapią najczęściej:

• Zapomniany ukośnik końcowy - pliki lądują o katalog za głęboko (cel/zrodlo/... zamiast cel/...). Zawsze świadomie decyduj o ukośniku przy źródle.
• --delete bez --dry-run - skasowane dane w celu, gdy pomylisz kierunek albo źródło jest puste. Najpierw na sucho, zawsze.
• Permission denied na zdalnym - rsync działa z uprawnieniami użytkownika SSH. Do zapisu w katalogu systemowym potrzebujesz albo właściciela katalogu, albo --rsync-path="sudo rsync", żeby rsync po drugiej stronie startował z podniesionymi uprawnieniami.
• rsync: command not found - rsync nie jest natywnym narzędziem Windows. Na Windowsie uruchamiasz go przez WSL albo dystrybucję cwRsync (domyślnie instaluje się w C:\Program Files\cwRsync). Szczegóły w osobnym wpisie o rsync na Windows rsync -avn --delete zrodlo/ cel/

mirror z usuwaniem zbednych plikow (po sprawdzeniu --dry-run)

rsync -av --delete zrodlo/ cel/

pomijanie katalogow

rsync -avz --exclude 'node_modules' --exclude '.git' zrodlo/ cel/

Kto automatyzuje deploy i backup, naturalnie wchodzi głębiej w pracę z serwerem - solidne [podstawy SSH](/artykul/ssh) to następny logiczny krok, a stały serwer pod te zadania dobierzesz z zestawienia VPS pod DevOps.

## FAQ

### Czym różni się rsync od scp?

scp przy każdym uruchomieniu kopiuje całe pliki od nowa, a rsync przesyła tylko różnice dzięki algorytmowi delta-transfer. rsync potrafi też wznowić przerwany transfer (flaga `-P`), czego scp nie robi. Do jednorazowej kopii scp wystarczy, do powtarzalnej synchronizacji i backupu wygrywa rsync.

### Jak zrobić backup przez rsync over SSH?

Podajesz zdalny cel w formacie `user@serwer:/sciezka`, na przykład `rsync -avz ./dane/ user@serwer:/backup/dane/`. Transport idzie domyślnie przez SSH, więc korzysta z Twoich kluczy i konfiguracji. Dla portu innego niż 22 dodajesz `-e "ssh -p 2222"`. Do regularnego backupu spinasz tę komendę z cronem.

### Co robi flaga --delete w rsync i czy jest bezpieczna?

`--delete` usuwa z celu pliki, których nie ma już w źródle, tworząc wierne lustro. Jest bezpieczna tylko wtedy, gdy wiesz, co robisz - błędny kierunek albo puste źródło skasują dane w celu. Zasada admina: `--delete` zawsze uruchamiaj najpierw z `--dry-run`, sprawdź listę, dopiero potem na serio.

### Jak wykluczyć pliki lub katalogi z rsync?

Używasz flagi `--exclude 'wzorzec'`, na przykład `--exclude 'node_modules' --exclude '.git'`, żeby pominąć ciężkie i nieistotne katalogi. Gdy wzorców jest dużo, wpisz je do pliku po jednym w linii i wczytaj przez `--exclude-from=.rsyncignore`. Składnia wzorców działa podobnie do `.gitignore`.

### Czy rsync działa na Windows?

Tak, choć nie jest natywnym narzędziem Windows. Najwygodniej uruchomić go przez WSL (Windows Subsystem for Linux), gdzie masz pełnego rsync jak w Linuksie. Alternatywa to dystrybucja cwRsync, instalowana domyślnie w `C:\Program Files\cwRsync`. Szczegóły obu ścieżek opisuję w osobnym wpisie o rsync na Windows.

### Jak sprawdzić, co rsync zrobi, zanim to zrobi?

Dodaj flagę `--dry-run` (skrót `-n`) razem z `-v`: `rsync -avn zrodlo/ cel/`. rsync policzy i wypisze pełną listę operacji - które pliki skopiuje, a przy `--delete` które usunie - ale niczego nie tknie. To pierwszy odruch przy każdej komendzie, która może nadpisać albo skasować dane.