Руководства

Быстрая передача больших файлов между серверами по SSH с помощью rsync

  • 13 минут чтения
  • Команда Hostragons
Быстрая передача больших файлов между серверами по SSH с помощью rsync

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

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

В этом руководстве подробно рассмотрим процесс переноса больших файлов между двумя Linux-серверами по SSH с помощью rsync, приведём реальные примеры команд, расскажем, как повысить производительность, проверить безопасность и обработать возможные ошибки. Также покажем, как делать тестовые передачи и на что обратить внимание перед запуском в продуктиве. Если вы планируете миграцию на новый VPS или хостинг, убедитесь, что на исходном и целевом серверах достаточно свободного места, есть доступ по SSH и корректно настроены права пользователей. Для выбора подходящей инфраструктуры рекомендуем ознакомиться с Решения для VPS серверов Hostragons и Пакеты Линукс Хостинга.

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

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

SSH обеспечивает шифрование передачи, поэтому данные не передаются в открытом виде. Это особенно важно для клиентских данных, заказов интернет-магазина, медиаархивов, бэкапов баз данных и конфиденциальных файлов приложений. Безопасность в хостинге — это не только SSL-сертификаты для сайта (подробнее в SSL сертификат), но и защищённый канал передачи данных между серверами с помощью SSH.

По сравнению с FTP или ручным копированием, rsync более гибок: сохраняет права, поддерживает символические ссылки, может удалять удалённые файлы, ограничивать скорость передачи и предварительно проверять операции. Для рискованных задач с большими файлами такой уровень контроля — серьёзное преимущество.

Когда стоит использовать rsync через SSH?

rsync через SSH особенно полезен при переносе больших объёмов данных, множества файлов или часто обновляемых каталогов. Для простой визуальной папки может хватить SFTP, но при тысячах файлов, разных правах и больших архивах rsync — надёжнее и эффективнее.

  • Перенос веб-сайта со старого сервера на новый VPS.
  • Передача каталогов с тысячами медиафайлов, например, папки загрузок WordPress.
  • Копирование ежедневных, еженедельных или ежемесячных резервных копий на другой сервер.
  • Смена дата-центра или хостинг-провайдера.
  • Синхронизация файлов приложений между продуктивной и резервной средой.
  • Долгие передачи с возможными разрывами соединения.

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

Что нужно подготовить перед началом работы

Знания команды rsync недостаточно для успешной операции. Нужно проверить условия на исходном и целевом серверах, чтобы минимизировать риск потери данных или прерванной передачи. Ниже перечислены основные проверки, обязательные в боевых условиях.

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

Должна быть возможность подключения с исходного на целевой сервер по SSH. Стандартный тест: ssh пользователь@ip-адрес. Если SSH работает на нестандартном порту, пробуйте: ssh -p 2222 пользователь@ip-адрес. Если вход не удаётся, rsync тоже работать не будет. Проверьте настройки файрвола, Fail2ban, порт SSH, права пользователя и корректность пароля или ключа.

2. Убедитесь, что rsync установлен

Большинство дистрибутивов Linux идут с предустановленным rsync, но проверить не помешает. На Debian/Ubuntu используйте rsync --version. Если не установлен, команда apt install rsync решит проблему. Для AlmaLinux, Rocky Linux или CentOS подойдёт dnf install rsync или yum install rsync. На Hostragons установка Linux VPS обычно занимает несколько секунд.

3. Проверьте свободное место на диске

Если на целевом сервере недостаточно места, передача прервётся. Узнать размер исходной папки можно командой: du -sh /путь/к/источнику. На целевом сервере проверьте свободное пространство: df -h. Рекомендуется иметь запас не только под размер файлов, но и под временные и лог-файлы. Например, если переносите 500 ГБ, оставьте минимум 550–600 ГБ свободного места.

4. Планируйте работу с критичными сервисами и изменяющимися файлами

Если сайт работает, файлы могут изменяться во время передачи — это особенно актуально для загружаемых пользователями данных, кэша и логов. Для больших переносов сначала отправляют основную часть, затем ставят сайт в режим обслуживания и запускают финальный rsync для синхронизации изменений. Так время простоя сокращается до нескольких минут. Для WordPress полезен Руководство по переносу WordPress хостинга.

Основная команда rsync для переноса файлов между серверами

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

Рассмотрим пример: перенос папки с сайта размером 180 ГБ с сервера root@192.168.1.10 в аналогичное расположение на root@203.0.113.20:

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

Если вы не хотите использовать root, создайте на целевом сервере пользователя с правом записи в нужную папку, например deploy, и используйте его. Это более безопасно, чем работать под root. В продакшене рекомендуется ограничивать права для безопасности.

Рекомендуемые параметры для безопасной и надёжной передачи

Для больших файлов и нестабильных сетей одной базовой команды часто недостаточно. Нужно использовать дополнительные опции для возобновления передачи, контроля целостности и подробного прогресса. Пример комплексной команды:

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

Здесь -H сохраняет жёсткие ссылки, -A — ACL права, -X — расширенные атрибуты, --numeric-ids — идентификаторы пользователей и групп вместо имён (полезно, если они не совпадают на серверах), --partial оставляет частично переданные файлы, --progress показывает ход передачи, а --append-verify позволяет докачать файл с проверкой целостности.

Не все параметры нужны всегда — для простого сайта может хватить -aHAX, а для приложений с особыми правами важна поддержка ACL и атрибутов. Всегда полезно сначала провести тестовую передачу.

Как указать нестандартный порт SSH в команде rsync?

Если SSH-сервер слушает не на стандартном порту 22, укажите его в параметре -e. Правильный формат:

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 (удаление лишних файлов на целевом сервере), тест с --dry-run обязателен, чтобы избежать потери данных.

Типичный рабочий процесс: сначала тест SSH-соединения, проверка места на диске, запуск rsync --dry-run, тест на небольшой папке, а затем основная передача. Это добавляет несколько минут, но экономит часы при ошибках.

Настройки сжатия, ограничения скорости и шифрования для оптимальной производительности

Производительность rsync зависит не только от размера файлов, но и от CPU, типа дисков, сетевой задержки, полосы пропускания и количества файлов. Множество мелких файлов копируется медленнее, чем один большой, из-за обработки метаданных. На VPS с NVMe-дисками скорость чтения и записи значительно выше, поэтому для больших переносов стоит рассмотреть NVMe VPS сервер.

Параметр -z включается для сжатия, что полезно для текстовых файлов и логов, но для уже сжатых архивов (.zip, .tar.gz, .jpg, .mp4) нагрузка на CPU может не оправдать себя. При передаче больших медиафайлов по сети 1 Гбит/с лучше отключить сжатие для максимальной скорости. Для медленных каналов с преобладанием текстовых данных сжатие даёт заметную экономию трафика.

Чтобы не перегружать сеть, используйте --bwlimit=50000 — ограничит скорость примерно 50 МБ/с. Это важно, чтобы не мешать работе сайта и не создавать узкие места. Рекомендуется планировать переносы ночью, ограничивать скорость и контролировать нагрузку на сервер.

Сравнение rsync, scp, SFTP и FTP

Сравнение rsync, scp, SFTP и FTP

Для передачи файлов существует множество инструментов, каждый имеет свои плюсы и минусы. В таблице ниже сравним их по ключевым параметрам для больших файлов и серверной миграции:

Сравнение rsync, scp, SFTP и FTP
МетодБезопасностьДокачкаПроизводительность при больших файлахРекомендуемое использование
rsync + SSHВысокаяПолнаяОтличнаяМиграция серверов, резервное копирование, синхронизация
scpВысокаяОграниченнаяСредняяБыстрая копия небольшого числа файлов
SFTPВысокаяЗависит от клиентаСредняяРучное управление файлами
FTPНизкаяЗависит от клиентаПеременнаяСтарые системы без требований к безопасности

Как видно, rsync выделяется особенно при регулярной синхронизации и больших объёмах данных. scp проще, но не умеет эффективно определять изменения. FTP без шифрования не подходит для современных задач. В панелях хостинга FTP доступ удобен, но для критичных переносов лучше SSH-методы.

Пример рабочего процесса для переноса живого сайта

Перенос сайта — это не только копирование файлов, но и настройка DNS, базы данных, SSL, версий PHP, прав и почты. Вот пример последовательности действий при миграции большого сайта с минимальными простоями:

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

Основной перенос идёт при работе сайта, а простой длится только во время финальной синхронизации и смены DNS. Такой подход позволяет сократить время простоя с часов до минут, что особенно важно для крупных WordPress-сайтов с обширными медиаархивами.

Проверка целостности данных

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

Для более тщательной проверки можно повторно запустить rsync с теми же параметрами. Если новых файлов нет, вывод будет минимальным.

Для контрольной проверки можно добавить опцию -c, которая сравнивает файлы по контрольной сумме:

rsync -avc --dry-run /путь/к/источнику/ пользователь@ip-адрес:/путь/к/назначению/

Однако использование -c сильно нагружает CPU и диск, поэтому подходит только для критически важных данных, например архивов, дампов баз или документов клиентов.

Если переносили сайт, проверьте работоспособность на уровне приложения: главную страницу, админпанель, загрузку изображений, оплату, формы обратной связи и логи ошибок. Для интернет-магазинов важно проверить не только файлы, но и интеграции платежей и cron-задачи на новом сервере.

Частые ошибки и их устранение

Ошибка Permission denied

Чаще всего возникает из-за недостаточных прав SSH-пользователя, отсутствия прав на запись в целевой каталог или проблем с ключами. Проверьте, что можно подключиться по SSH, и попробуйте создать тестовый файл в целевой папке. При необходимости смените владельца папки с помощью chown или настройте sudo-права.

Ошибка No space left on device

Передача прервётся при нехватке места. Проверьте свободное пространство командой df -h. Иногда основной диск свободен, но /tmp или точка монтирования заняты. Очистите старые логи, кэш и бэкапы. Если места всё равно не хватает, рассмотрите расширение диска или переход на VPS с большим объёмом.

Ошибка Connection reset или Broken pipe

При длительной передаче возможны разрывы связи. Если вы используете --partial и --append-verify, просто запустите команду снова — передача продолжится с места обрыва. Помогают и настройки keepalive в SSH, например в клиенте добавьте ServerAliveInterval 60 для уменьшения обрывов при простое.

Очень медленная передача

Причины могут быть в большом количестве мелких файлов, ограничениях диска, нагрузке CPU или пропускной способности сети. В некоторых случаях сначала архивирование (tar) ускоряет копирование, но теряется преимущество rsync по частичным изменениям. Для больших уже сжатых файлов попробуйте отключить -z. Инструменты iotop, htop и iftop помогут определить узкие места по CPU, диску или сети.

Рекомендации по безопасности

Безопасность при передаче данных между серверами — приоритет. Особенно это касается root-доступа, SSH-ключей и бэкапов, содержащих конфиденциальную информацию. Рекомендуется использовать SSH-ключи с паролем вместо пароля, ограничивать права ключей и хранить их в безопасности.

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

Если переносите дампы баз, документы клиентов или личные данные, после операции удаляйте временные файлы как на исходном, так и на целевом серверах. Не храните резервные копии в открытых папках сайта, чтобы избежать утечек.

Использование rsync для автоматического резервного копирования

rsync подходит не только для разовых миграций, но и для регулярного бэкапа. Например, можно настроить cron-задачу для ночного копирования определённой папки на резервный сервер. При этом используется безпарольное подключение по SSH-ключу, передаются только изменения, а скорость ограничивается.

Пример команды для ежедневного бэкапа:

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

Опция --delete синхронизирует папки полностью, удаляя файлы, которых нет в источнике. Используйте её осторожно и тестируйте с --dry-run.

В операциях хостинга часто рекомендуют правило 3-2-1: 3 копии данных, 2 на разных носителях, 1 — в удалённом месте. rsync отлично подходит для копирования между серверами. Для более сложных схем смотрите материалы по Решения для резервного копирования и услуги корпоративного хостинга.

Контрольный список перед запуском переноса

Перед началом переноса больших файлов выполните следующий минимум, чтобы снизить риски:

  • Проверена установка rsync на исходном и целевом серверах?
  • SSH-соединение с нужным пользователем и портом успешно протестировано?
  • Достаточно ли свободного места на диске целевого сервера?
  • Выполнен тест с --dry-run для проверки команд?
  • Для живого сайта запланирован режим обслуживания и финальная синхронизация?
  • Если используется --delete, проверены пути и целевые каталоги?
  • Проведена проверка прав, размеров и тестирование сайта после переноса?
  • Удалены временные файлы и резервные копии после операции?

Эти простые меры часто предотвращают самые распространённые ошибки: неправильный путь, отсутствие прав, переполнение диска и проблемы с DNS. Планирование rsync-процесса ускоряет перенос и снижает вероятность отката.

Часто задаваемые вопросы

Если соединение по SSH прервалось, rsync начнёт передачу заново?

Нет, при правильных параметрах (--partial и --append-verify) передача возобновится с места остановки. Однако перед повторным запуском рекомендуется проверить свободное место и состояние частично переданных файлов.

Можно ли переносить базу данных напрямую с помощью rsync?

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

Нужен ли root-доступ на обоих серверах для использования rsync?

Root-доступ не обязателен. Достаточно пользователя с правом записи в целевой каталог. При необходимости сохранить владельцев, ACL и системные права может потребоваться более высокий уровень доступа. Для безопасности лучше работать с ограниченными правами.

Опасно ли использовать параметр --delete?

Если использовать правильно, --delete помогает точно синхронизировать папки, удаляя лишние файлы на целевом сервере. Но при ошибке в пути или тестировании это может привести к потере данных. Всегда тестируйте с --dry-run перед применением.

Что лучше для больших файлов — rsync или scp?

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

Итоги и следующий шаг

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

Если вы планируете миграцию на новый сервер, расширение хранилища или переход на более производительный хостинг, изучите решения Hostragons с VPS, хостингом, доменами и SSL для безопасного и комфортного перехода. Начинайте с небольших тестов, анализируйте результаты и тщательно планируйте финальную синхронизацию.

Поделитесь этой статьей:

Команда Hostragons

Актуальные руководства от нашей команды экспертов по хостингу, серверам и доменным именам. Давайте вместе найдем оптимальное решение для вашего проекта.

Свяжитесь с нами