Зачем вообще тюнить rsync over SSH
rsync по ssh — стандарт для миграций и бэкапов между серверами: он почти везде доступен, шифрует трафик, умеет докачку и дельта-передачу. Но «из коробки» вы часто упираетесь не в диск и не в сеть, а в CPU (шифрование/компрессия) или в агрессивный дисковый IO, который выбивает page cache и поднимает iowait.
Ниже — практические настройки, которые помогают управлять тремя вещами: скоростью передачи, загрузкой CPU и влиянием на диски. Цель простая: получить предсказуемый rsync, который не превращает ночной прогон в утренний инцидент.
Если вы дополнительно хотите системно «закрутить гайки» по алгоритмам OpenSSH (не только для rsync), пригодится разбор профилей шифров и KEX: как выбрать сильные и быстрые cipher/kex/mac в OpenSSH.
Базовая команда: скелет, от которого пляшем
Начнём с каркаса, который дальше будем дополнять (копируйте и адаптируйте под задачу):
rsync -aHAX --numeric-ids --delete --info=stats2,progress2 -e ssh /src/ user@dst:/dst/Что здесь важно:
-a— режим архива (права, времена, рекурсивность).-HAX— hardlink’и, ACL и xattr (актуально для системных переносов и некоторых приложений).--numeric-ids— сохраняем UID/GID числами (полезно, если/etc/passwdи группы различаются).--delete— зеркалирование (на назначении удаляется то, чего нет на источнике).--info=stats2,progress2— понятная телеметрия (скорость/объём/прогресс).
Дальше всё упирается в бутылочное горлышко: CPU (cipher/compression), диск (сканирование и запись), или сеть (лимиты/конкуренция с бизнес-трафиком).
Выбор SSH cipher/MAC: chacha20 vs aes и когда это реально ускоряет
В ssh скорость часто определяется шифром и режимом аутентификации/целостности. Хорошая новость: современные дефолты OpenSSH безопасные. Плохая: они не всегда оптимальны под ваш CPU и тип нагрузки.
Практическое правило выбора cipher
chacha20-poly1305@openssh.com— часто выигрывает на CPU без AES-NI/VAES и на «шумных» виртуальных ядрах. Хорош как предсказуемый вариант для разношёрстных окружений.aes128-gcm@openssh.com— часто самый быстрый на современных x86 с аппаратным ускорением AES, при этом с адекватной нагрузкой на CPU.aes256-gcm@openssh.com— обычно немного тяжелее, чемaes128-gcm, прирост «криптостойкости» для канала бэкапа часто не даёт практической разницы, а скорость может просесть.
Если сомневаетесь, начните с
chacha20-poly1305, а затем сравните сaes128-gcmкоротким тестом на реальных серверах. Победитель зависит от CPU и текущей нагрузки.
Как задать cipher в rsync over SSH
Алгоритмы задаются параметрами ssh внутри -e:
rsync -a --info=progress2 -e 'ssh -c chacha20-poly1305@openssh.com' /src/ user@dst:/dst/Вариант с AES-GCM:
rsync -a --info=progress2 -e 'ssh -c aes128-gcm@openssh.com' /src/ user@dst:/dst/Если по требованиям/совместимости вы используете режим CTR, тогда дополнительно важен MAC (в GCM и chacha20-poly1305 он «встроен»):
rsync -a --info=progress2 -e 'ssh -c aes128-ctr -m hmac-sha2-256' /src/ user@dst:/dst/Как посмотреть доступные алгоритмы и чем реально договорились
ssh -Q cipher
ssh -Q mac
ssh -Q kexА чтобы увидеть итог переговоров (что выбрал клиент с сервером):
ssh -vv user@dst 'exit' 2>&1 | grep -E 'kex:|cipher:|MAC:'
Compression: когда помогает, а когда только мешает
Компрессию часто включают «на всякий случай», и это типичная причина падения скорости. Сжатие забирает CPU с обеих сторон и может сделать шифрование+компрессию узким местом раньше, чем вы упрётесь в сеть.
Когда стоит включать SSH-компрессию
- Канал медленный, CPU свободен.
- Данные хорошо сжимаются: текст, JSON, SQL-дампы без gzip, логи.
rsync -a --info=progress2 -e 'ssh -C' /src/ user@dst:/dst/Когда компрессию лучше выключить
- Передаёте уже сжатое:
.gz,.zip,.jpg,.mp4, архивы бэкапов. - Видите упор в CPU: в
topпроцессыsshdиrsyncстабильно держат ядра. - Канал быстрый (1–10 Gbit), а CPU средний: компрессия часто снижает итоговый throughput.
rsync -a --info=progress2 -e 'ssh -o Compression=no' /src/ user@dst:/dst/Ограничение скорости: bwlimit и «не забить канал»
--bwlimit — самый простой способ не съесть весь аплинк и не устроить деградацию сервисам. Это лимит на конкретный процесс rsync, а не на интерфейс целиком.
Пример: лимит 50 MiB/s (примерно 400 Mbit/s):
rsync -a --bwlimit=51200 --info=progress2 -e ssh /src/ user@dst:/dst/Если запускаете несколько rsync параллельно, лимит умножается. В таком случае либо снижайте --bwlimit на каждый поток, либо уменьшайте параллелизм (часто это лучше, чем «забивать» диск и сеть десятком процессов).
Для миграций «в два этапа» (ранний прогон + финальная синхронизация) полезно держать дневной лимит ниже, а ночной выше. Практическую схему без простоя удобно строить так же, как в плейбуках миграции: пошаговая миграция сайта с минимальным даунтаймом.
IO и приоритеты: nice/ionice и почему iowait важнее «скорости»
На проде основной ущерб от rsync — это дисковая подсистема. Миллионы мелких файлов разгоняют random read/write, выдавливают page cache и поднимают iowait. Для пользователей это выглядит как «всё стало медленно» даже при нормальной загрузке CPU.
Понижаем CPU-приоритет (nice)
nice -n 19 rsync -a --info=progress2 -e ssh /src/ user@dst:/dst/Это почти бесплатная страховка, если узкое место — CPU и конкурентные задачи на сервере.
Понижаем дисковый приоритет (ionice)
Для фоновых синхронизаций часто подходит idle-класс: IO отдаётся процессу только когда диск простаивает.
ionice -c3 nice -n 19 rsync -a --info=progress2 -e ssh /src/ user@dst:/dst/Если -c3 слишком медленно и вы не укладываетесь в окно, используйте best-effort с низким приоритетом:
ionice -c2 -n 7 nice -n 19 rsync -a --info=progress2 -e ssh /src/ user@dst:/dst/Что смотреть в iotop и iostat
Чтобы понять, кто реально создаёт нагрузку (rsync, sshd, файловая система, сопутствующие процессы):
iotop -oPaДля общей картины по устройствам и задержкам:
iostat -xz 1Если растут %util и await, а вместе с ними растёт latency у базы/приложения, уменьшайте агрессию: ionice, --bwlimit, перенос окна, либо меняйте стратегию (ранний прогон + короткий финальный).
Измерение скорости: прогресс rsync и «честный» тест SSH throughput
Встроенный прогресс rsync обычно достаточен, но для выбора cipher полезно быстро померить «чистую» пропускную способность SSH (без дисков и dеlta-логики rsync).
Прогресс и статистика rsync
rsync -a --info=progress2,stats2 -e ssh /src/ user@dst:/dst/Тест канала через pv (диагностика)
Тест ниже не заменяет rsync, но помогает понять, упираетесь ли вы в CPU шифрования и какой cipher быстрее на конкретной паре хостов:
dd if=/dev/zero bs=1M count=4096 | pv | ssh -c chacha20-poly1305@openssh.com user@dst 'cat >/dev/null'Повторите с AES-GCM:
dd if=/dev/zero bs=1M count=4096 | pv | ssh -c aes128-gcm@openssh.com user@dst 'cat >/dev/null'Практические рецепты под типовые сценарии
1) Нужно быстро перекачать много данных, CPU ограничен
- Сравните
chacha20-poly1305иaes128-gcm, оставьте то, что быстрее в ваших условиях. - Компрессию выключайте (
-o Compression=no), если данные плохо сжимаются. - Не занижайте
--bwlimitбез причины: растягивание окна повышает шанс пересечения с пиками нагрузки.
rsync -aHAX --numeric-ids --delete --info=progress2 -e 'ssh -c aes128-gcm@openssh.com -o Compression=no' /src/ user@dst:/dst/2) Прод-сервер: аккуратно, без iowait и без забитого канала
- Понижаем приоритеты
nice/ionice. - Ограничиваем
--bwlimit. - Делаем несколько коротких инкрементальных прогонов вместо одного «монолитного».
ionice -c2 -n 7 nice -n 19 rsync -a --delete --bwlimit=20480 --info=progress2 -e 'ssh -c chacha20-poly1305@openssh.com -o Compression=no' /src/ user@dst:/dst/3) Много мелких файлов, rsync долго сканирует
Тут чаще виноваты метаданные и количество inode-операций, а не cipher. Рабочая тактика — уменьшать объём изменений к финальному окну:
- Сделать первый прогон заранее (за часы/день), финальный — максимально короткий.
- Исключить каталоги, которые можно пересобрать/докачать отдельно (cache/tmp и другие «шумные» директории).
- По возможности стабилизировать записи на время финального прогона (readonly, пауза генерации кэшей/логов/очередей).
rsync -a --delete --info=progress2 --exclude='cache/' --exclude='tmp/' -e ssh /src/ user@dst:/dst/Частые ошибки и быстрые проверки
Включили compression и стало медленнее
Проверьте CPU: если sshd упирается в ядро, компрессия почти всегда ухудшит итоговый throughput. Отключайте и сравнивайте на коротком тесте.
Поставили bwlimit, но сеть всё равно забита
Проверьте количество параллельных rsync: лимит применяется к каждому процессу. Плюс не забывайте про другие фоновые задачи (обновления, ротация логов, другие бэкапы).
После rsync всё тормозит, хотя копирование уже закончилось
Часто это эффект выдавленного page cache и очередей IO. Снижайте приоритеты через ionice, планируйте в окно низкой нагрузки и смотрите iostat -xz 1 во время прогона.
Мини-чеклист: как быстро подобрать оптимальные настройки
- Определите узкое место: CPU (
top), диск (iostat,iotop), сеть (мониторинг интерфейса). - Сравните
chacha20-poly1305иaes128-gcmна коротком тесте. - Компрессию включайте только если данные сжимаются и CPU есть в запасе.
- На проде используйте
niceи чаще всегоionice. - Если мешаете бизнес-трафику — добавьте
--bwlimitи/или перенесите окно. - Для больших миграций: ранний прогон + финальный короткий прогон.
Заключение
Тюнинг rsync over ssh — это баланс: максимальная скорость против предсказуемой нагрузки на CPU и IO. Правильный cipher (обычно chacha20-poly1305 или aes128-gcm), осознанная компрессия, аккуратный --bwlimit и приоритизация через nice/ionice почти всегда дают больше эффекта, чем попытки «ускорить rsync флагами» вслепую.
Практичный подход: померить короткими тестами, зафиксировать выбранные параметры и запускать синхронизацию так, чтобы она была максимально незаметна для продакшена.
Если вы переносите проекты между серверами и нужен предсказуемый ресурс по CPU/диску, под такие задачи удобнее выделять отдельный VDS под бэкапы/миграции, чтобы не конкурировать с боевыми сервисами.
