Rsync vs SCP: która komenda kopiowania w Linuksie?

Używaj rsync do wszystkiego większego niż szybka jednorazówka, a scp, gdy chcesz mieć plik na drugiej maszynie już teraz. Rdzeń różnicy: scp streamuje cały plik od nowa za każdym razem i nie pamięta zerwanego połączenia, a rsync porównuje źródło z celem, przenosi tylko zmienione bloki i wznawia przerwaną kopię tam, gdzie skończyła. Przy dużym backupie po chwiejnym łączu to różnica między dwiema minutami a zaczynaniem od zera. Oba przychodzą z OpenSSH na praktycznie każdej dystrybucji Linuksa, więc to wybór nawyku, nie instalacji — a nawyk powinien domyślnie wskazywać rsync. Poniżej: prosta tabela porównania, realne różnice w szybkości, trik z wznawianiem, którego scp nie umie, i przypadki, w których scp wciąż jest właściwą odpowiedzią.

Jaka jest różnica między rsync i scp?

scp robi jedną rzecz: otwiera kanał SSH, streamuje bajty, zamyka. Nie ma stanu między uruchomieniami, więc jeśli transfer padnie na 90%, zaczynasz od zera.

rsync to narzędzie synchronizacji, które akurat używa SSH jako transportu. Przed wysyłką buduje listę sum kontrolnych pliku docelowego (algorytm delty na bazie kroczącej sumy kontrolnej) i przesyła tylko różniące się bloki. Uruchom tę samą komendę drugi raz, a drugi przejazd nie przenosi prawie nic. To też czyni rsync naturalnym narzędziem do trzymania dwóch katalogów w zgodzie — wpisz go do harmonogramu, a każdy przejazd kopiuje tylko delty.

Konsekwencje w praktyce:

• Przerwania: rsync wznawia; scp zaczyna plik od nowa.
• Drugie kopiowanie: rsync wysyła tylko zmiany; scp wysyła wszystko ponownie.
• Usuwanie: rsync potrafi zdublować usunięcia przez --delete; scp nie.
• Filtrowanie: rsync ma wzorce --exclude; scp kopiuje wszystko, na co wskażesz.
• Próby na sucho: rsync pokazuje, co by zrobił, przez --dry-run; scp nie daje nic.

Czy rsync jest szybszy od scp?

Przy pierwszym kopiowaniu jednego dużego pliku po szybkim łączu są blisko siebie — oba zatykają SSH, a przejazd po sumach kontrolnych dodaje tylko niewielki narzut. Różnica otwiera się w trzech miejscach:

1. Dużo małych plików. rsync pipeline’uje przechodzenie katalogów i potrafi użyć jednego połączenia; starsze konfiguracje scp odpalały robotę per plik. Tysiące małych plików (jakiś node_modules, instalacja WordPressa) kończy się z rsync wyraźnie szybciej.
2. Ponowne uruchomienia. Skopiuj plik 4 GB, w którym zmieniło się 50 MB, a rsync przeniesie ~50 MB; scp znów przeniesie 4 GB.
3. Kompresja. -z kompresuje w locie, co pomaga na wolnych łączach WAN.

Możesz zmierzyć oba sam — komenda ma identyczny kształt:

# ten sam plik, ten sam serwer, oba po SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# odpal oba ponownie: scp kopiuje od nowa, rsync weryfikuje i wysyła ~nic
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Jeśli spędzasz dzień na serwerach, szybkość transferu to jedna z rzeczy warta zmierzenia raz — tak samo jak ss bije netstat na obciążonych hostach (zobacz ss vs netstat: która komenda portów w Linuksie).

Czy scp wznawia przerwany transfer?

Nie. scp nie ma wznawiania; jeśli połączenie padnie przy 900 MB z 1 GB, zaczynasz jeszcze raz. To najczęściej cytowany argument w każdej debacie rsync-vs-scp i jest prawdziwy.

Cała konstrukcja rsync zakłada, że transfer czasem zostanie przerwany. Kanoniczne zaklęcie wznawiania:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial zostawia półnapisany plik zamiast go usuwać.
• --append-verify wznawia przez dopisanie, po czym weryfikuje sumami kontrolnymi dopisaną część — bezpieczne wobec uszkodzonego pliku częściowego, w odróżnieniu od starego gołego --append.
• --progress pokazuje, gdzie podchwycił.

Owinięte w pętlę ponowień, to backup nastaw-i-zapomnij nawet po wrogim łączu:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

Kiedy użyć scp zamiast rsync?

scp wciąż jest właściwym narzędziem w garstce przypadków:

• Jeden mały plik, raz. Wpisanie scp app.conf user@host:/etc/myapp/ jest krótsze niż każde wywołanie rsync, a nie ma czego wznawiać.
• rsync brakuje po tamtej stronie. rsync potrzebuje swojej binarki po obu stronach. Wiele minimalnych kontenerów i urządzeń dostarcza serwer SFTP dla scp, ale już nie rsync.
• Nie chcesz wystawionego serwera rsync. Rzadkie, ale niektóre środowiska blokują demona rsync specificznie.

Jeden subtelny szczegół warty znajomości: projekt OpenSSH latami temu wycofał oryginalny protokół scp i współczesny scp tak naprawdę mówi pod spodem SFTP. Naprawiło to kwirę z ucieczką ze ścieżek, ale nic nie zmieniło w dwóch ograniczeniach, które tu się liczą — brak wznawiania, brak transferu delty. Zmiana protokołu nie robi z scp rsync.

Powiązane: jeśli twoje pytanie naprawdę brzmi „rsync vs cp”, odpowiedź jest lustrem tego — cp to lokalny odpowiednik scp (bez wznawiania, bez delty, bez atrybutów, jeśli nie dodasz flag), a rsync działa lokalnie i zdalnie. Do lokalnych jednorazówek cp wystarczy.

Które flagi rsync są najważniejsze?

Większości ludzi potrzeba w sumie jednej linii:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flaga	Co robi
-a (archive)	Rekurencja + zachowuje uprawnienia, czasy, grupę, symlinki, urządzenia
-v (verbose)	Wypisuje, co przenosi
-h (human)	Rozmiary czytelne dla człowieka
--partial	Zostawia częściowo przeniesione pliki, więc ponowny start wznawia
--progress	Postęp per plik — to, czego scp nigdy nie miało
-z	Kompresja w locie (wolne CPU przy szybkim LAN-ie: pomiń)
--delete	Mirroruje też usunięcia — niebezpieczne, zawsze paruj z próbą na sucho
--dry-run (-n)	Pokazuje, co by się stało, nic nie zmienia

Dwa nawyki warte wdrożenia. Po pierwsze, próbuj na sucho wszystkiego, co ma --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # przejrzyj
rsync -avh --delete src/ user@server:/srv/dest/             # potem wykonaj

Po drugie, pilnuj końcowego ukośnika — /srv/src kopiuje sam katalog do celu, a /srv/src/ kopiuje jego zawartość. Każdy na tym raz zgrzytnął; rsync nawet ostrzega „no bytes transferred”, gdy miałeś na myśli drugą formę.

Do dziennej albo tygodniowej synchronizacji wrzuć rsync do timera systemd i pozwól mu kopiować tylko delty — strona journalctlowa planowania jest pokryta w ściągawce z journalctl.

Rsync vs scp: werdykt

	scp	rsync
Przychodzi z OpenSSH	Tak	Tak (potrzebne oba końce)
Wznawia przerwany transfer	Nie	Tak (--partial)
Transfer delty przy ponownych przejazdach	Nie	Tak
Zachowuje uprawnienia/symlinki	Częściowo	Pełne (-a)
Wzorce wykluczeń	Nie	--exclude
Próba na sucho	Nie	--dry-run
Mirroruje usunięcia	Nie	--delete
Najlepsze do	Szybkie jednorazówki	Backupy, synchronizacje, duże drzewa

Domyślaj się rsync przy backupach, dużych drzewach, wszystkim po łączu, które potrafi paść, i wszystkim, co uruchomisz więcej niż raz. Używaj scp, gdy komenda jest krótsza niż myśl. Jeśli masz wynieść jedną flagę, niech to będzie --partial — zamienia każde przyszłe zerwane połączenie z restartu w pauzę.