Як швидко перенести великі файли між серверами через SSH за допомогою rsync

Команда rsync через SSH — один із найнадійніших та найшвидших способів перенесення великих файлів між двома серверами на Linux. Особливо це актуально, коли йдеться про сотні гігабайт вебсайтів, резервних копій, медіатеки або даних додатків. rsync має унікальну здатність передавати лише змінені блоки файлів, що значно прискорює процес у порівнянні з класичним копіюванням. Принцип роботи простий: файли з вихідного сервера через зашифроване SSH-з’єднання синхронізуються з цільовим сервером, а у разі розриву — передача продовжується з того ж місця.

При міграції серверів, оновленні хостингу, зміні дата-центру чи резервному копіюванні важливі не лише швидкість, а й цілісність даних. Завантаження великого архіву повністю і повторне його завантаження при помилках забирає багато часу і нервів. rsync у цьому випадку зберігає часові позначки, права доступу, власників і структуру директорій. Саме тому ця команда дуже популярна серед системних адміністраторів Linux, DevOps-фахівців та експертів з вебхостингу.

У цьому керівництві ми поетапно розглянемо, як переносити великі файли між двома Linux-серверами через SSH за допомогою rsync, із докладними прикладами команд. Також розповімо, як налаштувати параметри для підвищення продуктивності, перевірити безпеку, опрацювати можливі помилки, протестувати передачу та підготуватися до запуску у продакшн. Якщо плануєте міграцію на новий VPS або хостинг, перед виконанням переконайтеся, що на обох серверах достатньо вільного місця, є доступ по SSH і правильні права користувачів. Для вибору оптимальної інфраструктури рекомендуємо ознайомитись із Hostragons рішення для VPS серверів та Пакети Лінукс Хостингу.

Що таке rsync і чому його обирають для перенесення великих файлів?

rsync — це потужний інструмент командного рядка для синхронізації файлів і папок як локально, так і між віддаленими серверами. Головна перевага — алгоритм дельта-передачі, який замість повної копії пересилає лише змінені частини файлу. Наприклад, якщо у 80 ГБ резервній копії змінилося лише 2 ГБ, rsync передасть тільки ці 2 ГБ, значно скоротивши час і трафік.

SSH додає шифрування, тому дані не передаються у відкритому вигляді. Це критично для захисту клієнтських даних, замовлень інтернет-магазинів, медіаархівів, резервних копій баз даних та інших конфіденційних файлів. У світі хостингу безпека — це не лише SSL для сайту, а й безпечний канал передачі між серверами. Якщо для трафіку сайту ви використовуєте сертифікат SSL, то для передачі файлів обов’язково застосовуйте SSH.

На відміну від FTP або ручного завантаження, rsync гнучкіший: він зберігає права доступу, підтримує символічні посилання, видаляє цільові файли, яких вже немає в джерелі, обмежує пропускну здатність і дозволяє тестувати передачу до фактичного виконання. У випадках роботи з великими файлами це дає суттєві переваги та знижує ризики.

Коли варто використовувати rsync через SSH?

rsync по SSH особливо рекомендується для перенесення великих, численних або часто змінюваних файлів. Для простого каталогу з кількома зображеннями можна використати SFTP, але при тисячах файлів, різних правах або великих архівах краще обрати rsync.

• Якщо переносите сайт зі старого сервера на новий VPS.
• Коли потрібно скопіювати папки з тисячами медіафайлів, наприклад, каталог завантажень WordPress.
• Для регулярного перенесення щоденних, тижневих або місячних резервних копій.
• При зміні дата-центру або провайдера хостингу.
• Якщо синхронізуєте файли додатків між продакшн і резервним середовищем.
• Для довготривалих передач з ризиком розриву з’єднання.

Наприклад, завантаження 250 ГБ медіатеки на домашній ПК, а потім повторне її завантаження на новий сервер — це подвійна робота, що подовжує час і навантажує інтернет-канал. rsync дозволяє передавати файли напряму між серверами, уникаючи цього проміжного кроку.

Що потрібно підготувати перед початком?

Знання самої команди — не єдина умова успішної операції. Важливо перевірити умови на обох серверах, щоб уникнути втрати даних або перерваних передач. Нижче наведено ключові пункти, що мають бути підтверджені в продакшн-середовищі.

1. Перевірте доступ по SSH

Між вихідним і цільовим серверами має встановлюватися SSH-з’єднання. Стандартний тест: ssh користувач@ip-адреса-сервера. Якщо SSH працює на нестандартному порту, додаємо ключ -p, наприклад: ssh -p 2222 користувач@ip-адреса. Якщо підключення не вдається, rsync також не працюватиме — потрібно перевірити брандмауер, налаштування Fail2ban, порт, права користувача та ключі або пароль.

2. Переконайтеся, що rsync встановлений

У більшості дистрибутивів Linux rsync встановлено за замовчуванням, але варто це перевірити командою rsync --version. Якщо немає — встановіть: для Debian/Ubuntu apt install rsync, для AlmaLinux, Rocky Linux чи CentOS — dnf install rsync або yum install rsync. На VPS від Hostragons цей процес займає кілька секунд.

3. Перевірте наявність вільного дискового простору

Якщо на цільовому сервері недостатньо місця, передача перерветься. Щоб дізнатись розмір каталогу-джерела, скористайтесь du -sh /шлях/до/каталогу. Для перевірки вільного місця на цільовому сервері — df -h. Рекомендується залишати запас простору понад розмір файлів (приблизно 10–20%), щоб уникнути проблем із тимчасовими файлами та логами. Наприклад, для перенесення 500 ГБ даних краще мати 550–600 ГБ вільного місця.

4. Заплануйте роботу з критичними файлами і сервісами

При роботі з живими сайтами файли можуть змінюватись під час передачі — це користувацькі завантаження, кеші, логи. У великих міграціях спершу передають основні дані, потім сайт переводять у режим технічного обслуговування і виконують остаточну синхронізацію. Це допомагає мінімізувати час простою. Для сайтів на WordPress корисно ознайомитися з Посібник з переносу хостингу WordPress.

Базова команда rsync для перенесення файлів між серверами

Найчастіше використовується команда такого вигляду: rsync -avz /шлях/до/джерела/ користувач@цільовий-ip:/шлях/до/призначення/. Ключ -a означає архівний режим, який зберігає права, часові позначки та символічні посилання. -v — виводить деталі процесу. -z — стиснення даних під час передачі. Важливо звернути увагу на косу риску в кінці шляху джерела: /шлях/до/джерела/ копіює вміст каталогу, а /шлях/до/джерела — копіює сам каталог.

Приклад: потрібно перенести 180 ГБ вебфайлів із /var/www/site/public_html/ зі старого сервера на новий у ту ж саму папку:

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

Якщо не хочете використовувати root, створіть на цільовому сервері користувача з правами на запис у потрібну папку, наприклад deploy, і налаштуйте власність відповідно. Для продакшн-серверів рекомендується працювати з обмеженими правами користувачів задля безпеки.

Рекомендовані параметри для безпечного й надійного перенесення rsync

Для великих файлів базова команда може бути недостатньою — варто додати опції для стійкості до збоїв, контролю цілісності та захисту від помилок. Ось приклад команди, що часто використовується в реальних сценаріях:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /шлях/до/джерела/ користувач@цільовий-ip:/шлях/до/призначення/

-a — архівний режим; -H — зберігає жорсткі посилання; -A — зберігає ACL-права; -X — розширені атрибути. --numeric-ids використовує числові ідентифікатори користувача і групи, що корисно, якщо імена відрізняються між серверами. --partial залишає частково передані файли, щоб не починати заново при збої. --progress показує хід передачі. --append-verify продовжує передавання із перевіркою доданих даних, що важливо для великих файлів.

Не всі опції потрібні у кожному випадку. Наприклад, для простого сайту достатньо -aHAX, але для додатків з особливими правами важливо зберегти ACL і розширені атрибути. Тому спершу рекомендується провести тестову передачу.

Як використовувати rsync, якщо SSH працює на нестандартному порту?

Якщо SSH-сервер слухає не порт 22, а інший, його потрібно вказати у команді rsync. Прямий запис -e ssh -p 2222 не спрацює, оскільки -p — це аргумент для ssh, а не для rsync. Правильний синтаксис:

rsync -avz -e 'ssh -p 2222' /шлях/до/джерела/ користувач@цільовий-ip:/шлях/до/призначення/

Якщо використовуєте SSH-ключ, можна додати опцію -i:

rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /шлях/до/джерела/ користувач@цільовий-ip:/шлях/до/призначення/

Це зручно для автоматизації у скриптах чи cron-завданнях.

Як протестувати передачу перед реальним запуском: використання --dry-run

Один з найпрофесійніших підходів — спочатку виконати тестову симуляцію з параметром --dry-run. Він не копіює файли, а лише показує, що буде передано. Це допомагає уникнути помилок із неправильними шляхами або випадковим видаленням файлів.

Приклад команди:

rsync -avz --dry-run /var/www/site/ користувач@цільовий-ip:/var/www/site/

Вивід покаже список файлів і каталоги, які будуть скопійовані або видалені. Особливо важливо використовувати цей режим, якщо застосовується опція --delete, яка видаляє файли на цільовому сервері, яких немає на джерелі.

Типова послідовність: перевірка SSH, перевірка дискового простору, тест з --dry-run, пробне копіювання невеликої директорії, і вже потім повномасштабна передача. Це займає кілька додаткових хвилин, але економить години у разі помилок.

Налаштування стиснення, обмеження пропускної здатності та шифрування для кращої продуктивності

Швидкість роботи rsync залежить не лише від розміру файлів, а й від потужності CPU серверів, типу дисків, мережевої затримки, пропускної здатності та кількості файлів. Велика кількість дрібних файлів переноситься повільніше, ніж один великий, через накладні операції з метаданими. VPS з NVMe-дисками мають суттєво вищу швидкість читання-запису, тому для великих міграцій рекомендуємо звернути увагу на NVMe VPS сервер.

Опція -z (стиснення) корисна для текстових файлів, логів і деяких резервних копій, але не дає користі для вже стиснутих файлів (zip, tar.gz, jpg, mp4, gzip) і при швидкому мережевому каналі. При перенесенні великих медіафайлів між двома серверами з 1 Гбіт/с каналом іноді краще вимкнути стиснення.

Для обмеження мережевого трафіку використовується опція --bwlimit. Наприклад, --bwlimit=50000 встановить обмеження приблизно в 50 МБ/с. Це допомагає уникнути перевантаження мережі під час роботи сайту. Ідеально планувати великі перенесення на ніч, задавати обмеження швидкості і моніторити навантаження серверів.

Порівняння rsync, scp, SFTP та FTP

Існує багато способів передати файли, але кожен має свої плюси і мінуси. Нижче наведена таблиця, яка допоможе обрати найбільш доречний інструмент для великих файлів і серверних міграцій.

Як бачимо, rsync — найкращий вибір для повторюваних синхронізацій і великих обсягів. scp простий, але не має алгоритму диференціальної передачі. FTP без шифрування не відповідає сучасним стандартам безпеки. Хоча FTP зручний в панелях, для критичних операцій рекомендуються SSH-методи.

Приклад покрокового плану перенесення живого сайту

Передача сайту — це не лише копіювання файлів. Важливо налаштувати DNS, базу даних, SSL, версію PHP, права доступу і поштові сервіси. Нижче наведено приклад робочого процесу для великого сайту з мінімальним простоєм.

• Підготуйте на новому сервері вебсервер, PHP, базу даних та необхідні модулі.
• Зменшіть TTL DNS запису до 300 секунд задля швидшого оновлення. Для керування доменом можна скористатися Перевірка домену та управління доменом.
• Запустіть перший rsync, коли сайт ще працює — це перенесе більшість даних.
• Зробіть дамп бази даних і перенесіть його на новий сервер.
• Переведіть сайт у режим технічного обслуговування.
• Запустіть другий rsync для синхронізації змінених файлів.
• Оновіть базу даних чи застосуйте інкрементальний метод.
• Перевірте права доступу, працездатність сайту та логи на новому сервері.
• Встановіть або оновіть SSL сертифікат — для цього може стати в пригоді встановлення сертифіката SSL.
• Змініть DNS записи на нову IP-адресу.

Основна передача відбувається, поки сайт працює, тому простої практично немає. Затримка виникає тільки під час останньої синхронізації та DNS-перенаправлення. Для великих WordPress сайтів із великою медіатекою це дозволяє скоротити простої з годин до кількох хвилин.

Як перевірити цілісність даних після передачі

Після завершення rsync недостатньо просто побачити, що команда відпрацювала. Варто порівняти кількість файлів, їхній обсяг і ключові файли. Для швидкої перевірки можна порівняти розмір каталогу командою du -sh на обох серверах. Через особливості файлової системи значення можуть трохи відрізнятися.

Для більш ґрунтовної перевірки запустіть rsync повторно з тим самим набором параметрів. Якщо нічого не буде передано — це сигнал, що синхронізація пройшла успішно.

Для контролю контрольних сум можна використати опцію -c:

rsync -avc --dry-run /шлях/до/джерела/ користувач@цільовий-ip:/шлях/до/призначення/

Цей режим порівнює не лише розмір і дату, а й checksum файлів. Проте він збільшує навантаження на CPU і диск, тому використовувати слід обережно, особливо з великими обсягами.

Якщо переносили сайт, перевірте також роботу на рівні додатків: головну сторінку, адмінпанель, завантаження зображень, сторінку оплати, форми зворотного зв’язку та логи помилок. Для інтернет-магазинів важливо протестувати інтеграції платежів і автоматичні завдання (cron) на новому сервері.

Поширені помилки і як їх виправити

Помилка Permission denied

Ця помилка часто пов’язана з відсутністю прав користувача SSH або відсутністю дозволів на запис у цільову папку. Спершу спробуйте підключитись по SSH тим самим користувачем. Якщо підключення вдалось, перевірте можливість створення файлу у папці. Можливо, потрібно змінити власника папки через chown або налаштувати стратегію з sudo.

Помилка No space left on device

Передача перерветься, якщо на цільовому диску закінчилось місце. Перевірте розділи командою df -h. Іноді основний диск має вільне місце, але /tmp або інші монтування заповнені. Видаліть старі логи, кеші і резервні копії або збільшіть диск/перейдіть на VPS з більшою ємністю.

Помилка Connection reset або Broken pipe

Під час тривалих передач можуть виникати розриви мережі. Якщо ви використовуєте --partial та --append-verify, просто повторіть команду — передача відновиться з останнього місця. Також налаштуйте SSH keepalive, додавши у клієнтський конфіг ServerAliveInterval 60, щоб уникати розривів через бездіяльність.

Надто повільна передача

Повільність може бути через велику кількість дрібних файлів, обмеження I/O диску, навантаження CPU при стисненні або мережеві обмеження. Для великої кількості дрібних файлів іноді швидше створити архів tar і передати його, але тоді втрачається перевага rsync — диференціальна передача. При великих стиснутих файлах вимкніть -z і порівняйте швидкість. Використовуйте інструменти iotop, htop, iftop для виявлення вузьких місць.

Кращі практики безпеки при передачі файлів між серверами

Під час передачі не можна нехтувати безпекою. Особливо це стосується root-доступу, SSH-ключів і резервних копій, які містять чутливі дані. Рекомендується використовувати SSH-ключі з паролем замість паролів. Права на файли ключів мають бути суворо обмежені, приватні ключі не можна розповсюджувати.

Для передачі створіть тимчасового користувача з доступом лише до потрібних папок. Після завершення роботи відключіть або видаліть цей акаунт. Обмежте SSH доступ за IP, налаштуйте firewall, використовуйте Fail2ban і оновлюйте OpenSSH до актуальної версії.

Якщо переносите дампи баз даних або особисті архіви, після передачі обов’язково очистіть тимчасові файли на обох серверах. Залишати .sql, .zip чи .tar у вебпапках — велика загроза безпеці. Такі файли краще зберігати поза вебдокументами або видаляти після завершення операції.

Використання rsync для автоматичного резервного копіювання

rsync підходить не лише для одноразової передачі, а й для регулярного резервного копіювання. Наприклад, можна налаштувати cron-завдання, яке щовечора копіюватиме потрібний каталог на резервний сервер. Зазвичай використовується безпарольне SSH-з’єднання через ключі, передаються лише змінені файли, а також застосовується обмеження пропускної здатності.

Приклад команди для регулярного бекапу:

rsync -a --delete --bwlimit=30000 /var/www/site/ backup@ip_резервного_сервера:/backup/site/

Опція --delete синхронізує ціль з джерелом, видаляючи зайві файли. Через це потрібно бути уважним, щоб випадково не втратити дані. Для критичних резервних копій краще використовувати snapshot-и, версіонування або інші стратегії збереження історії змін.

Правило 3-2-1 для резервного копіювання — це тримати мінімум 3 копії даних, на 2 різних носіях, і 1 копію в іншому місці. rsync допомагає автоматизувати частину цього процесу між серверами. Для більш детального планування можна звернутися до Рішення для резервного копіювання та послуги корпоративного хостингу.

Чекліст перед початком перенесення великих файлів

Перед запуском процесу переконайтеся у наступному, щоб знизити ризики помилок. Цей список має стати стандартом у продакшн-операціях.

• rsync встановлений на обох серверах?
• SSH-з’єднання перевірене з правильним користувачем і портом?
• На цільовому сервері достатньо вільного місця?
• Проведено тест з параметром --dry-run?
• Для живого сайту заплановано режим обслуговування і останню синхронізацію?
• Якщо використовується --delete, чи перевірені шляхи?
• Після передачі заплановані перевірки розмірів, прав і тестування сайту?
• Чи буде безпечно очищено тимчасові резервні копії і дампи?

Хоча ці пункти здаються простими, більшість типових проблем пов’язана саме з ними: неправильний шлях, відсутність прав, брак місця або необдумана зміна DNS. Добре спланований процес rsync скорочує час міграції та підвищує успішність операції.

Поширені запитання

Чи починається передача заново при розриві SSH з’єднання?

Ні, за умови правильного використання параметрів. Опції --partial та --append-verify зберігають часткові файли і дозволяють продовжити передачу з місця зупинки. Проте перед повторним запуском рекомендується перевірити вільне місце на диску і стан файлів.

Чи можна rsync-ом переносити базу даних «на гарячу»?

rsync переносить файли, але копіювати працюючу базу даних таким способом не рекомендується, оскільки можна отримати неповні чи пошкоджені дані. Для MySQL/MariaDB краще робити дамп через mysqldump або фізичне резервне копіювання, а потім передавати отриманий файл rsync.

Чи потрібен root-доступ на обох серверах для rsync?

Root не обов’язковий. Достатньо мати користувача з правами запису в цільову папку. Якщо потрібно зберігати власника, права чи особливі атрибути, може знадобитися вищий рівень прав. Для безпеки рекомендується працювати з мінімально необхідними правами.

Чи безпечний параметр --delete?

При правильному використанні --delete допомагає синхронізувати каталог з дзеркалом. Однак якщо вказати неправильний шлях, можна втратити файли. Тому перед застосуванням слід обов’язково робити тест з --dry-run і перевіряти шляхи.

Що краще для великих файлів: rsync чи scp?

Для разових копіювань невеликої кількості файлів scp підійде. Але для великих обсягів, численних файлів і повторних синхронізацій rsync ефективніший завдяки диференціальній передачі, можливості продовжити зупинений процес і контролю пропускної здатності.

Висновки та наступні кроки

Передача великих файлів між серверами через SSH за допомогою rsync — це швидкий, безпечний та контрольований спосіб. Правильні параметри роблять процес стійким до обривів, дозволяють передавати лише змінені файли й зменшують час простою живих сайтів. Перед основною роботою обов’язково перевірте SSH-доступ, місце на диску, проведіть тестову передачу з --dry-run і лише потім запускайте повний перенос.

Якщо плануєте перехід на новий сервер з більшою ємністю або продуктивністю, ознайомтеся з рішеннями Hostragons — VPS, хостинг, домени і SSL-сертифікати допоможуть зробити міграцію безпечною і комфортною. Починайте з невеликих тестів, вимірюйте результати і плануйте останнє синхронізування відповідно.