Jak szybko i bezpiecznie przenieść duże pliki między serwerami za pomocą rsync przez SSH

Komenda rsync przez SSH to jedno z najskuteczniejszych narzędzi w systemach Linux do szybkiego, bezpiecznego i odpornego na przerwy przesyłania dużych plików między dwoma serwerami. Szczególnie przy przenoszeniu setek gigabajtów danych, takich jak pliki stron WWW, archiwa kopii zapasowych, foldery multimedialne czy dane aplikacji, rsync oferuje znaczną przewagę nad tradycyjnymi metodami kopiowania, przesyłając tylko zmienione fragmenty plików. Zasadniczo pliki ze źródłowego serwera są synchronizowane przez zaszyfrowany tunel SSH do serwera docelowego, a w przypadku utraty połączenia proces można wznowić od miejsca przerwania.

Podczas migracji serwera, modernizacji hostingu, zmiany centrum danych czy wykonywania kopii zapasowych równie ważna co szybkość jest integralność danych. Pobieranie ogromnego archiwum na lokalny komputer i ponowne wgrywanie go na nowy serwer to czasochłonne i podatne na błędy podejście. rsync zachowuje znaczniki czasu, uprawnienia, właściciela i strukturę katalogów, dlatego jest chętnie stosowany przez administratorów Linuxa, zespoły DevOps i ekspertów hostingu w codziennych zadaniach.

W tym poradniku krok po kroku omówimy, jak przenieść duże pliki między dwoma serwerami Linux za pomocą rsync przez SSH, podając praktyczne przykłady komend. Dodatkowo wyjaśnimy, jak poprawić wydajność transferu, zadbać o bezpieczeństwo, jak postępować w przypadku błędów, jak testować transfer oraz na co zwrócić uwagę przed wdrożeniem na produkcję. Jeśli planujesz migrację na nowy VPS lub środowisko hostingowe, upewnij się, że zarówno serwer źródłowy, jak i docelowy mają odpowiednią ilość wolnego miejsca na dysku, dostęp SSH i poprawne uprawnienia użytkowników. Wybór infrastruktury możesz przeanalizować na stronach Hostragons rozwiązania serwera VPS oraz Pakiety hostingu Linux.

Czym jest rsync i dlaczego warto go używać do przenoszenia dużych plików?

rsync to potężne narzędzie wiersza poleceń służące do synchronizacji plików i katalogów lokalnie lub między zdalnymi serwerami. Jego główną zaletą jest algorytm delta transfer, który zamiast przesyłać cały plik za każdym razem, kopiuje tylko zmienione fragmenty. Na przykład, jeśli masz archiwum o rozmiarze 80 GB, a zmieniło się w nim tylko 2 GB danych, rsync prześle jedynie te zmienione części, co znacznie oszczędza czas i przepustowość sieci.

SSH zapewnia szyfrowanie transferu, dzięki czemu dane nie są przesyłane w postaci otwartego tekstu. To jest szczególnie ważne dla danych klientów, zamówień e-commerce, archiwów multimedialnych, kopii zapasowych baz danych czy własnych plików aplikacji. W świecie hostingu bezpieczeństwo danych to nie tylko certyfikaty SSL dla ruchu www – kanał przesyłu plików między serwerami również musi być chroniony. Podczas gdy ruch www chronimy certyfikatem Certyfikat SSL, transfer plików między serwerami powinien odbywać się przez SSH.

rsync jest bardziej elastyczny niż FTP czy ręczne pobieranie i przesyłanie plików. Zachowuje uprawnienia, potrafi przenosić dowiązania symboliczne, usuwać pliki na serwerze docelowym, ograniczać przepustowość i umożliwia testowanie transferu przed jego wykonaniem. Ta kontrola jest szczególnie cenna przy przenoszeniu dużych plików, gdzie ryzyko błędów jest większe.

Kiedy warto korzystać z rsync przez SSH?

Użycie rsync przez SSH sprawdza się szczególnie przy przenoszeniu dużych ilości plików, wielu plików lub często zmieniających się danych. Proste katalogi z grafikami można kopiować ręcznie przez SFTP, ale gdy mamy do czynienia z tysiącami plików, różnymi uprawnieniami i ogromnymi archiwami, rsync staje się niezawodnym rozwiązaniem.

• Przenosisz stronę internetową z starego serwera na nowy VPS.
• Przesyłasz katalogi zawierające tysiące plików multimedialnych, np. folder uploads WordPressa.
• Regularnie kopiujesz kopie zapasowe (dziennie, tygodniowo, miesięcznie) na inny serwer.
• Zmieniasz centrum danych lub dostawcę hostingu.
• Synchronizujesz pliki aplikacji między środowiskiem produkcyjnym a zapasowym.
• Planujesz długotrwałe transfery, gdzie istnieje ryzyko przerwania połączenia.

Na przykład pobranie 250 GB katalogu multimediów na komputer i późniejsze przesłanie go na nowy serwer to dwa osobne transfery, co wydłuża czas i obciąża łącze internetowe. Dzięki rsync można przesłać dane bezpośrednio między serwerami, eliminując ten etap pośredni.

Co przygotować przed rozpoczęciem?

Znajomość samej komendy rsync nie wystarczy. Ważne jest, by sprawdzić warunki na obu serwerach i zminimalizować ryzyko utraty danych lub przerwania transferu. Poniższe kroki są kluczowe w środowisku produkcyjnym.

1. Sprawdź dostęp do SSH

Musisz mieć możliwość połączenia się ze źródłowego serwera na docelowy przez SSH. Standardowo testuje się to komendą: ssh uzytkownik@adres-ip-serwera. Jeśli SSH działa na niestandardowym porcie, użyj: ssh -p 2222 uzytkownik@adres-ip-serwera. Jeśli test się nie powiedzie, rsync nie zadziała. Sprawdź zaporę sieciową, konfigurację Fail2ban, port SSH, uprawnienia użytkownika oraz uwierzytelnianie hasłem lub kluczem.

2. Zweryfikuj, czy rsync jest zainstalowany

W większości dystrybucji Linuxa rsync jest domyślnie dostępny, ale warto to potwierdzić poleceniem rsync --version. Jeśli go brakuje, na Debianie/Ubuntu zainstalujesz go poleceniem apt install rsync, a na AlmaLinux, Rocky Linux lub CentOS przez dnf install rsync lub yum install rsync. Na VPS Hostragons instalacja zwykle trwa kilka sekund.

3. Upewnij się, że jest wystarczająco dużo miejsca na dysku

Brak wolnego miejsca na serwerze docelowym spowoduje zatrzymanie transferu. Sprawdź rozmiar katalogu źródłowego komendą du -sh /sciezka/do/katalogu, a stan dysku na serwerze docelowym poleceniem df -h. Zaleca się rezerwę na pliki tymczasowe i logi – np. dla 500 GB danych zaplanuj co najmniej 550–600 GB wolnego miejsca.

4. Zaplanuj przenoszenie plików zmieniających się na żywo

Na działających stronach pliki mogą być modyfikowane w trakcie transferu, np. uploady użytkowników, cache lub logi. Przy dużych migracjach najpierw przenosi się większość danych, następnie włącza tryb konserwacji i wykonuje końcową synchronizację. W ten sposób czas niedostępności strony ogranicza się do kilku minut. Dla WordPressa pomocne mogą być poradniki takie jak Poradnik przenoszenia hostingu WordPress.

Podstawowa komenda rsync do przenoszenia plików między serwerami

Najprostsza i najczęściej używana forma komendy wygląda tak: rsync -avz /sciezka/źródłowa/ uzytkownik@adres-ip:/sciezka/docelowa/. Parametr -a oznacza tryb archiwizacji, który zachowuje uprawnienia, daty modyfikacji i dowiązania symboliczne. -v pokazuje szczegółowe informacje o przebiegu, a -z włącza kompresję podczas transferu. Zwróć uwagę na ukośnik na końcu ścieżki źródłowej – oznacza on, że kopiowana jest zawartość katalogu, nie sam katalog.

Przykładowo, jeśli chcesz przenieść 180 GB plików strony z katalogu /var/www/site/public_html/ na nowy serwer o adresie 203.0.113.20, użyj:

rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/

Jeśli nie chcesz korzystać z konta root, lepiej utwórz na serwerze docelowym użytkownika z odpowiednimi uprawnieniami do katalogu, np. deploy, i dostosuj właściciela katalogu. Choć root bywa wygodny, dla bezpieczeństwa zaleca się ograniczone konto użytkownika.

Bezpieczne i odporne na przerwy parametry rsync

Przy dużych transferach podstawowa komenda może się nie sprawdzić. Użycie dodatkowych opcji pozwala uniknąć problemów z przerwaniem połączenia, częściowymi plikami czy nieumyślnym usuwaniem danych. Oto przykładowa komenda sprawdzająca się w wielu scenariuszach:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /sciezka/źródłowa/ uzytkownik@adres-ip:/sciezka/docelowa/

Parametry -aHAX oznaczają kolejno: tryb archiwizacji, zachowanie twardych linków (hard links), zachowanie uprawnień ACL oraz rozszerzonych atrybutów plików. --numeric-ids używa identyfikatorów użytkowników i grup zamiast nazw, co bywa pomocne, gdy nazwy różnią się między serwerami. --partial pozostawia częściowo przesłane pliki, --progress pokazuje postęp transferu, a --append-verify pozwala wznowić transfer dużych plików z weryfikacją.

Nie zawsze wszystkie opcje są potrzebne. Przy prostych migracjach strony wystarczy -aHAX, ale gdy ważne są szczegółowe uprawnienia i atrybuty, lepiej użyć pełnego zestawu. Testowanie transferu przed właściwą migracją jest kluczowe.

Jak użyć rsync, gdy SSH działa na niestandardowym porcie?

Jeśli SSH nie korzysta z domyślnego portu 22, trzeba to uwzględnić w komendzie rsync przez parametr -e. Poprawna składnia wygląda tak:

rsync -avz -e 'ssh -p 2222' /sciezka/źródłowa/ uzytkownik@adres-ip:/sciezka/docelowa/

Zwróć uwagę na pojedyncze cudzysłowy wokół całej komendy ssh wraz z portem, co jest ważne w terminalu. Jeśli korzystasz z klucza SSH, możesz dodać parametr -i, np.:

rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /sciezka/źródłowa/ uzytkownik@adres-ip:/sciezka/docelowa/

Taki sposób jest powszechny w automatycznych skryptach i zadaniach cron.

Testowanie transferu z parametrem --dry-run

Zanim zaczniesz faktyczną migrację, warto wykonać testowy przebieg polecenia z opcją --dry-run. Dzięki temu rsync pokaże, które pliki zostałyby przesłane, ale niczego nie zmieni:

rsync -avz --dry-run /var/www/site/ uzytkownik@adres-ip:/var/www/site/

W ten sposób łatwo wychwycisz ewentualne błędy, złe ścieżki czy niezamierzone usuwanie plików, jeśli korzystasz z parametru --delete. Ten ostatni synchronizuje katalog docelowy tak, by dokładnie odzwierciedlał źródło, ale niewłaściwe użycie może prowadzić do utraty danych.

Profesjonalny workflow to: najpierw test SSH, potem sprawdzenie miejsca na dysku, następnie test rsync z --dry-run, próba na małym katalogu, a dopiero potem pełny transfer. Choć to zajmuje kilka dodatkowych minut, chroni przed wielogodzinnymi problemami.

Wydajność – kompresja, ograniczanie pasma i szyfrowanie

Wydajność rsync zależy nie tylko od rozmiaru plików, ale także od mocy CPU serwerów, typu dysku, opóźnień sieciowych, dostępnej przepustowości i liczby plików. Przesyłanie tysięcy małych plików trwa dłużej niż pojedynczego dużego pliku, ze względu na operacje na metadanych. VPS z dyskami NVMe oferują znacznie lepszą szybkość odczytu i zapisu, dlatego warto rozważyć serwer VPS NVMe do intensywnych transferów.

Parametr -z włącza kompresję, co jest korzystne przy plikach tekstowych, logach czy niektórych kopiach zapasowych. Jednak pliki już skompresowane (zip, tar.gz, jpg, mp4, gzip) mogą powodować zbędne obciążenie CPU bez realnej oszczędności transferu. Przy szybkim łączu 1 Gbps i dużych plikach multimedialnych warto rozważyć rezygnację z -z, natomiast przy wolniejszym łączu i plikach tekstowych kompresja się opłaca.

Aby ograniczyć zużycie pasma, można użyć opcji --bwlimit, np. --bwlimit=50000 ustawi limit na około 50 MB/s. To ważne, gdy serwer obsługuje ruch użytkowników i nie chcemy przeciążać łącza. Transfery warto planować na godziny nocne, monitorować obciążenie serwera (load average) i w razie potrzeby ustawiać limity.

Porównanie rsync, scp, SFTP i FTP

Do przenoszenia plików dostępnych jest wiele metod, każda z własnymi zaletami i ograniczeniami. Poniższa tabela podsumowuje, która metoda najlepiej sprawdza się przy dużych plikach i migracjach serwerów.

Z tabeli wynika, że rsync przez SSH wyróżnia się zwłaszcza przy powtarzających się synchronizacjach i dużych plikach. scp jest prosty i szybki, ale nie wykrywa inteligentnie zmian w plikach. FTP bez szyfrowania nie spełnia współczesnych wymagań bezpieczeństwa i powinien być stosowany tylko w wyjątkowych sytuacjach. W przypadku kluczowych migracji i kopii zapasowych rekomendujemy rozwiązania oparte na SSH.

Przykładowy workflow migracji działającej strony WWW

Przenosząc stronę z jednego serwera na drugi, nie wystarczy tylko skopiować pliki. Należy uwzględnić DNS, bazę danych, certyfikaty SSL, wersje PHP, uprawnienia plików i konfigurację maili. Poniżej przykładowy, niskoprzerwowy plan dla strony z dużą ilością danych:

• Zainstaluj i skonfiguruj na nowym serwerze serwer WWW, PHP, bazę danych i potrzebne moduły.
• Przed migracją zmniejsz TTL DNS domeny do np. 300 sekund. Do zarządzania domenami odwiedź Sprawdzanie domen i zarządzanie domenami.
• Uruchom pierwszą synchronizację rsync, gdy strona jest jeszcze aktywna – przeniesie większość danych.
• Wykonaj kopię bazy danych i przenieś ją na nowy serwer.
• Włącz tryb konserwacji (maintenance mode) na stronie.
• Wykonaj drugą synchronizację rsync, aby przesłać pliki zmienione od pierwszej synchronizacji.
• Zaktualizuj bazę danych lub zastosuj migrację przyrostową.
• Sprawdź uprawnienia plików, uruchom stronę i monitoruj logi na nowym serwerze.
• Zainstaluj lub odnow certyfikat SSL. Przydatne mogą być wskazówki z Instalacja certyfikatu SSL.
• Przekieruj rekordy DNS na nowy adres IP serwera.

W ten sposób najdłuższy etap transferu odbywa się przy działającej stronie, a przestój ogranicza się do ostatniej synchronizacji i propagacji DNS. Przy stronach WordPress z dużą ilością mediów można w ten sposób skrócić przerwę z godzin do kilku minut.

Sprawdzanie integralności danych po transferze

Po zakończeniu migracji nie wystarczy, że komenda rsync zakończyła się sukcesem. Trzeba porównać liczbę plików, ich rozmiary i wybrane pliki kluczowe. Prosty sposób to porównanie rozmiarów katalogów poleceniem du -sh na obu serwerach. Jednak ze względu na różnice w systemie plików wartości mogą się nieznacznie różnić. Dokładniejszą weryfikację można przeprowadzić, uruchamiając ponownie rsync z tymi samymi parametrami – jeśli nie ma plików do przesłania, wyświetla minimalny komunikat.

Dla wyższej pewności można użyć opcji -c, która oprócz daty i rozmiaru porównuje sumy kontrolne plików:

rsync -avc --dry-run /sciezka/źródłowa/ uzytkownik@adres-ip:/sciezka/docelowa/

Należy jednak uważać, ponieważ obliczanie sum kontrolnych na bardzo dużych zbiorach danych może mocno obciążyć CPU i dysk. Ta metoda jest polecana dla krytycznych archiwów, kopii baz danych lub ważnych dokumentów.

Po migracji strony warto też przetestować jej działanie: sprawdzić stronę główną, panel administracyjny, upload mediów, formularze kontaktowe, strony płatności i logi błędów. W e-commerce należy dodatkowo zweryfikować integracje płatności i zadania cron na nowym serwerze.

Najczęstsze błędy i jak je rozwiązać

Błąd Permission denied

Ten problem najczęściej wynika z braku uprawnień użytkownika SSH, braku prawa do zapisu w katalogu docelowym lub błędnej konfiguracji kluczy. Najpierw spróbuj połączyć się przez SSH zwykłym loginem. Jeśli się uda, sprawdź możliwość tworzenia plików w katalogu docelowym. W razie potrzeby zmień właściciela katalogu komendą chown lub zaplanuj strategię z użyciem sudo.

Błąd No space left on device

Brak miejsca na dysku powoduje zatrzymanie transferu. Sprawdź miejsca na partycjach poleceniem df -h. Czasem główny dysk ma wolne miejsce, ale /tmp lub punkt montowania docelowego jest pełny. Warto oczyścić stare logi, cache lub archiwa. Jeśli to nie pomoże, rozważ rozbudowę dysku lub wybór VPS o większej pojemności.

Błąd Connection reset lub Broken pipe

Przy długich transferach mogą wystąpić przerwy w połączeniu. Użycie parametrów --partial i --append-verify pozwala wznowić przesyłanie od miejsca przerwania. Pomocne bywają także ustawienia keepalive w SSH, np. ServerAliveInterval 60, które redukują ryzyko rozłączenia podczas bezczynności.

Bardzo wolny transfer

Przyczyną mogą być zbyt mała liczba plików lub ograniczenia sprzętowe (CPU, I/O dysku) albo sieciowe. Jeśli masz dużo małych plików, rozważ najpierw spakowanie ich do archiwum tar, choć wówczas tracisz zaletę rsync – przesyłania tylko zmian. Możesz też wyłączyć kompresję -z dla już skompresowanych plików. Użyj narzędzi jak iotop, htop czy iftop, aby zidentyfikować wąskie gardła sprzętowe lub sieciowe.

Najlepsze praktyki bezpieczeństwa

Podczas transferu danych między serwerami nie wolno lekceważyć kwestii bezpieczeństwa. Szczególnie dostęp root, klucze SSH oraz przechowywane kopie zapasowe wymagają ochrony. Zawsze preferuj uwierzytelnianie kluczem SSH zamiast hasła, trzymaj pliki kluczy w bezpiecznych lokalizacjach z ograniczonymi uprawnieniami i zabezpiecz je hasłem (passphrase).

Dobrym pomysłem jest utworzenie tymczasowego użytkownika z dostępem tylko do niezbędnych katalogów i usunięcie jego uprawnień po zakończeniu transferu. Ogranicz dostęp SSH do konkretnych adresów IP, stosuj firewall, konfiguruj Fail2ban i korzystaj z aktualnych wersji OpenSSH.

Jeżeli przenosisz pliki z danymi wrażliwymi, takimi jak dumpy baz danych czy dokumenty klientów, po zakończeniu transferu usuń tymczasowe pliki na obu serwerach. Nie zostawiaj archiwów .sql, .zip czy .tar w katalogach dostępnych z internetu – najlepiej przechowuj je poza rootem WWW lub usuń po zakończeniu operacji.

Automatyczne kopie zapasowe z rsync

rsync to nie tylko narzędzie do jednorazowych migracji, ale także świetny sposób na regularne tworzenie kopii zapasowych. Można skonfigurować zadanie cron, które codziennie w nocy przesyła wybrany katalog na serwer backupowy bez konieczności podawania hasła, dzięki kluczom SSH. rsync przeniesie tylko zmiany i można ograniczyć pasmo, np. do 30 MB/s, aby nie obciążać produkcyjnego serwera.

Przykładowa komenda do backupu:

rsync -a --delete --bwlimit=30000 /var/www/site/ backup@adres-ip:/backup/site/

Parametr --delete synchronizuje katalogi, usuwając w backupie pliki usunięte na źródle, dlatego trzeba go stosować ostrożnie. Dla krytycznych danych warto rozważyć dodatkowe rozwiązania z wersjonowaniem, snapshotami czy rotacją kopii. W świecie hostingu dobrze sprawdza się zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z jedną kopią w innej lokalizacji.

rsync ułatwia realizację tej strategii, przenosząc kopie między serwerami. Więcej informacji znajdziesz w materiałach Rozwiązania tworzenia kopii zapasowych i usługi hostingu dla firm.

Lista kontrolna przed rozpoczęciem transferu

Przed rozpoczęciem przenoszenia dużych plików warto przejść poniższą listę, by uniknąć typowych problemów. Szczególnie w środowiskach produkcyjnych powinna być standardem:

• rsync jest zainstalowany na obu serwerach?
• SSH działa poprawnie z właściwym użytkownikiem i portem?
• Na serwerze docelowym jest wystarczająco dużo wolnego miejsca?
• Test z parametrem --dry-run został wykonany?
• Na działającej stronie zaplanowano tryb konserwacji i ostatnią synchronizację?
• Jeśli stosujesz --delete, ścieżka docelowa została dokładnie sprawdzona?
• Po transferze planujesz weryfikację rozmiarów, uprawnień i testy aplikacji?
• Zabezpieczysz i usuniesz tymczasowe pliki i kopie zapasowe?

Choć lista jest prosta, najczęstsze błędy wynikają z pominięcia tych punktów: błędne ścieżki, brak uprawnień, niewystarczająca przestrzeń dyskowa i nieprzemyślany DNS. Przemyślany proces rsync skraca czas migracji i zwiększa szanse powodzenia.

Najczęściej zadawane pytania

Co się stanie, jeśli połączenie SSH zostanie przerwane podczas rsync? Czy transfer zacznie się od nowa?

Nie, jeśli używasz odpowiednich parametrów, takich jak --partial i --append-verify, transfer zostanie wznowiony od miejsca przerwania. W wypadku krytycznych migracji warto jednak sprawdzić miejsce na dysku i stan plików tymczasowych przed ponownym uruchomieniem komendy.

Czy rsync może bezpośrednio przenieść aktywną bazę danych?

Nie, rsync przesyła tylko pliki. Aby przenieść bazę danych MySQL lub MariaDB, najlepiej wykonać jej zrzut (np. mysqldump), a następnie przesłać plik dumpa rsyncem. W przypadku systemów na żywo zaleca się tryb konserwacji lub replikację, by zapewnić spójność danych.

Czy do używania rsync potrzebne jest konto root na obu serwerach?

Nie, wystarczy użytkownik z uprawnieniami do zapisu w docelowym katalogu. Jednak jeśli chcesz zachować właścicieli plików i specjalne uprawnienia systemowe, może być potrzebny dostęp root lub podwyższone uprawnienia. Z punktu widzenia bezpieczeństwa lepiej używać kont o ograniczonych uprawnieniach.

Czy parametr --delete jest bezpieczny?

Tak, jeśli jest używany ostrożnie i po wcześniejszym przetestowaniu z --dry-run. --delete synchronizuje katalog docelowy z katalogiem źródłowym, usuwając pliki, których już nie ma u źródła. Nieprawidłowe użycie może spowodować utratę danych, dlatego warto dokładnie sprawdzić ścieżki i wykonać testy.

Co jest lepsze do dużych transferów – rsync czy scp?

Do jednorazowego przesłania niewielkiej liczby plików scp jest szybki i prosty. Jednak przy dużych plikach, wielu plikach i powtarzających się synchronizacjach rsync zwykle wypada lepiej. Potrafi wznowić transfer, rozpoznać zmiany, ograniczyć pasmo i pozwala na testowanie.

Podsumowanie i kolejne kroki

Przenoszenie dużych plików między serwerami za pomocą rsync przez SSH to szybka, bezpieczna i łatwa do kontrolowania metoda. Dzięki właściwym parametrom jest odporna na przerwy w połączeniu, przesyła tylko zmienione dane, a podczas migracji stron ogranicza czas przestojów. Zanim zaczniesz, sprawdź połączenie SSH, dostępne miejsce na dysku i wykonaj test z --dry-run, a potem zaplanuj główny transfer.

Jeśli szukasz nowego serwera, wydajniejszego miejsca na dane lub lepszego hostingu, zapoznaj się z ofertą Hostragons – VPS, hosting, domeny i certyfikaty SSL pomogą Ci przeprowadzić migrację bezpiecznie i sprawnie. Zacznij od małych testów, zmierz wyniki i zaplanuj ostateczną synchronizację, by mieć pewność, że wszystko pójdzie gładko.