Файловые копии и синхронизации остаются базовой «гигиеной» админа: деплой, зеркала, перенос данных, ежедневные backups, выгрузка в облако и восстановление после инцидентов. В 2026 году по-прежнему чаще всего всплывают три инструмента: rsync, rclone и SFTP. На поверхности они похожи (все «переносят файлы»), но по сути решают разные задачи и дают разные гарантии.
Ниже — практичный разбор: где важен incremental, где решает checksum, как ограничивать полосу без сюрпризов, на что смотреть в логах и какие грабли чаще всего встречаются в проде.
Коротко: чем отличаются по идеологии
Rsync — инструмент для эффективной синхронизации файловых деревьев между двумя сторонами, обычно по SSH. Его сильная сторона — минимизация передаваемых данных (дельта-алгоритм) и богатые опции сохранения атрибутов. Идеален для «сервер ↔ сервер», «сервер ↔ локал», для зеркал и регулярных синков.
Rclone — «швейцарский нож» для удалённых хранилищ: объектные (S3-подобные), облачные диски, WebDAV, SFTP и другие. Он умеет copy/sync, шифрование на клиенте, контроль целостности и тонкую настройку сетевого поведения. Главный плюс — перенос и синхронизация между разными провайдерами и протоколами, включая S3.
SFTP — протокол безопасной передачи файлов поверх SSH. Это не «синхронизатор» сам по себе, а транспорт и набор операций (листинг, загрузка/выгрузка, переименование). Его сильная сторона — простота, совместимость и удобное разграничение доступа (права, chroot, запрет shell).
Сравнение по задачам: что выбрать в реальной жизни
1) Быстрый и предсказуемый sync между серверами
Если нужно зеркалировать директории между Linux-серверами (медиа, выгрузки, статика, каталоги бэкапов) — чаще всего выигрывает rsync. Он экономит канал, умеет докачивать частично переданные файлы и хорошо логируется.
SFTP здесь тоже возможен, но «из коробки» он переливает файлы без оптимизаций под дельту. Rclone может делать sync по SFTP-бэкенду, но это обычно лишний слой, если у вас и так «SSH между двумя серверами».
2) Backups в облако или объектное хранилище
Для выгрузки бэкапов в S3-подобные хранилища наиболее практичен rclone: он построен вокруг «remote» и решает типовые задачи одной-двумя командами, включая тонкую настройку параллельности и лимитов.
Rsync сам по себе «не про S3»: обычно нужен промежуточный сервер или шлюз, что усложняет схему. SFTP годится как «простой удалённый сейф» (второй сервер-хранилище), но для облаков чаще неудобен и не использует нативные плюсы объектного стора (версионирование, retention, Object Lock).
3) Разовые передачи файлов и доступ для людей или подрядчиков
Когда нужна понятная точка входа для человека или внешнего скрипта (принять архив, дать доступ к ограниченной папке, сделать «приёмник» выгрузок) — самый прямой выбор SFTP. Его проще объяснить и проще контролировать на уровне прав и ключей.
Rsync и rclone тут тоже работают, но это скорее «инструменты админа», а не универсальный «файловый вход» для пользователей.
Если вы выбираете площадку под регулярные синки и бэкапы «сервер ↔ сервер», обычно удобнее держать выделенный узел под хранение и планировщик задач. Под это хорошо подходит VDS: можно изолировать доступы, диски и политики хранения от прод-сервера.
Incremental: где он настоящий, а где вы про разное
Термин incremental часто используют в двух смыслах, и это источник путаницы:
- Инкрементальная передача: передаём только изменения, экономим трафик и время.
- Инкрементальные бэкапы: храним историю состояний (снимки или версии) и можем откатиться.
Rsync и «дельта внутри файла»
У rsync есть ключевая фишка: при обновлении файла на удалённой стороне он может передать только изменившиеся блоки. Это полезно для больших файлов, которые меняются частично.
Но дельта-алгоритм не всегда выигрывает. Если файлы меняются целиком (архивы, уже сжатые бэкапы) или CPU ограничен, попытка «сэкономить трафик» может обернуться лишней нагрузкой и меньшей скоростью.
Rclone: сравнение, догрузка и возможности хранилища
Rclone чаще работает по модели «сравнить и догрузить недостающее». Для объектных хранилищ это нормальный путь: объект, как правило, обновляется целиком, и «дельта внутри файла» обычно не применяется.
Историю (настоящую инкрементальность в смысле «версий или снимков») rclone обычно реализует не сам, а через политику хранилища: versioning, retention и подобные механики. Если вы строите бэкапы в S3, заранее продумайте lifecycle и правила удержания — это зачастую важнее, чем выбор одной команды.
