Когда речь заходит о передаче файлов на VDS, чаще всего всплывают четыре варианта: SFTP, FTPS, rsync и WebDAV. Формально все они «про файлы», но на практике отличаются по модели безопасности, удобству для пользователей, нагрузке на сервер, дружелюбности к фаерволам/прокси и тому, насколько хорошо подходят для автоматизации.
Ниже — практичное сравнение: SFTP vs FTPS (про совместимость и сеть), rsync vs SFTP (про скорость и деплой), и WebDAV как «папка по HTTP». В конце — чек-лист, чтобы быстро выбрать рабочий вариант именно под вашу задачу.
Коротко о главном: чем эти протоколы отличаются
Важно не путать уровни и назначение. Слова похожие, а «движущие части» разные.
- SFTP — файловый протокол поверх SSH. Это не «FTP с шифрованием», а отдельный протокол, который обычно живёт на TCP-порту 22 (или на вашем нестандартном).
- FTPS — это FTP + TLS (явный или неявный). Наследует архитектуру FTP: отдельные каналы управления и данных, активный/пассивный режим, диапазоны портов.
- rsync — инструмент синхронизации. Чаще всего работает поверх SSH и силён тем, что передаёт только изменения (дельта-алгоритм), умеет в точное зеркало и управление правами.
- WebDAV — расширение HTTP для работы с файлами. Для клиента часто выглядит как сетевой диск/папка и удобен там, где уже есть HTTPS, прокси и корпоративные ограничения.
SFTP на VDS: дефолтный выбор для админов и «быстрого старта»
SFTP почти всегда оказывается самым простым стартом на VDS: SSH обычно уже настроен, аудит и контроль доступа понятны, а клиентских программ — море (включая графические).
Почему SFTP обычно выигрывает
- Один порт: как правило, TCP 22. Это удобно и для фаерволов, и для диагностики.
- Единая модель учёток: системные пользователи/группы, понятные права на FS, привычная админская рутина.
- Нормальная автоматизация: ключи SSH, отдельные users под деплой, понятное ограничение доступа на уровне ОС.
- Безопасность «из коробки»: шифрование и аутентификация SSH, логирование, rate-limit/ban по событиям входа.
Слабые места SFTP (о которых вспоминают поздно)
- Медленнее на «деплой дерева»: если вы постоянно заливаете большое количество файлов (особенно по сети с высоким RTT), SFTP часто проигрывает rsync.
- Нужны аккуратные права и изоляция: если даёте доступ разработчикам/контент-менеджерам, заранее решите вопрос с ограничением каталогов и запретом «лишних» действий.
- Управление ключами: в команде быстро появляется потребность в регламенте (кто выдал доступ, где хранится, как отзывать, как ротировать).
Минимальный практичный набор для SFTP на VDS
Базовая идея: отдельный пользователь под файлы, вход по ключам, минимальные права на каталоги. Если хотите именно «файловый доступ без shell», тестируйте ограничения аккуратно, чтобы не отрезать себе администрирование.
SFTP — хороший «стандарт по умолчанию» для VDS, когда нужен безопасный доступ и минимум компонентов. Но если задача — быстрый деплой и синхронизация, чаще выигрывает rsync.
Если вы только выбираете инфраструктуру под проекты и хотите держать всё под контролем на уровне ОС и сети, обычно удобнее начинать с VDS: так проще выстроить отдельные учётки, ключи, права и политику доступа.
FTPS на VDS: когда нужен именно «FTP, но безопасный»
Сравнение SFTP vs FTPS обычно упирается не в криптографию (оба могут быть безопасными), а в инфраструктуру и совместимость. FTPS выбирают, когда у заказчика/партнёра есть процессы и софт, заточенные под FTP/FTPS, и «перейти на SFTP» организационно сложно.
Что важно понимать про FTPS
- Сложнее с портами: кроме порта управления нужны порты для данных. В пассивном режиме придётся открыть диапазон и правильно настроить сервер и фаервол.
- NAT/фаервол/прокси: классический FTP исторически плохо дружит с сетевыми промежуточными устройствами. FTPS добавляет TLS, и некоторые «умные» инспекторы трафика уже не могут корректно помогать.
- Сертификаты: чтобы FTPS был удобным для пользователей, нужен валидный сертификат и корректная цепочка, иначе клиенты будут ругаться или подключаться «в небезопасном режиме».
Explicit vs Implicit FTPS
Обычно встречаются два режима.
- Explicit FTPS — клиент подключается к FTP и затем «повышает» соединение до TLS специальной командой. Сейчас встречается чаще.
- Implicit FTPS — TLS обязателен сразу при подключении на отдельный порт. Иногда используется по наследству.
Когда FTPS на VDS оправдан
- Есть внешний контрагент и у него строго FTPS.
- Есть старое ПО, которое «умеет только FTP/FTPS» и не поддерживает SFTP.
- Нужна совместимость с конкретными MFT-процессами и аудитом на стороне клиента.
Практический совет: если вы поднимаете FTPS «для людей», не откладывайте TLS на потом. Проще сразу сделать нормально: валидный сертификат, корректное имя хоста, и понятные инструкции клиентам.
Для FTPS и WebDAV по-настоящему рабочий сценарий — это предсказуемый TLS без предупреждений в клиентах. Если вы используете публичный доступ, удобнее сразу оформить нормальные SSL-сертификаты, чем разбираться с ошибками доверия на десятках рабочих станций.
rsync на VDS: лучший инструмент для синхронизации и деплоя
Если вы выбираете не «как дать человеку скачать/залить файл», а «как поддерживать на сервере актуальную копию проекта», то сравнение rsync vs SFTP часто заканчивается в пользу rsync.
Почему rsync часто быстрее SFTP
- Дельта-алгоритм: передаются только отличия. Это заметно экономит трафик и время при частых небольших изменениях.
- Инкрементальная синхронизация: быстро «догоняет» сервер до состояния локальной копии (и наоборот).
- Точное зеркало: времена, права, симлинки, удаление лишнего на стороне сервера — всё управляется флагами.
Типовые сценарии rsync на VDS
- Деплой статических сайтов и фронтенд-сборок.
- Выгрузка медиа с исключениями, докачкой и контролем изменений.
- Синхронизация конфигов между узлами (когда не хочется вручную копировать файлы).
- Резервное копирование на другой сервер по SSH (если архитектура это допускает).
Подводные камни rsync
- Удаление файлов: неправильные флаги могут стереть лишнее. Привычка «сначала dry-run» реально спасает.
- Права и владельцы: при синхронизации под разными пользователями можно получить неожиданную модель доступа.
- Нагрузка на CPU/диск: на слабой VDS сравнение и вычисление дельт могут быть заметными на больших объёмах мелких файлов.
Пример безопасной «сухой» синхронизации
rsync -avhn --delete ./build/ deploy@server:/var/www/site/
rsync -avh --delete ./build/ deploy@server:/var/www/site/Первая команда показывает, что будет сделано (флаг -n), вторая — применяет изменения. Если деплоите по расписанию или из CI, добавьте логирование в файл и храните его хотя бы несколько дней.
Если вы хотите собрать процесс деплоя в более предсказуемую схему (атомарные релизы, откат, права), пригодится отдельный разбор: деплой и бэкапы через rsync по SSH.
WebDAV на VDS: «сетевой диск» поверх HTTP
WebDAV — хороший вариант, когда файл-сервис нужен не только админам, но и обычным пользователям/контент-менеджерам, и особенно когда хочется работать с файлами как с папкой. При этом WebDAV живёт в мире HTTP: прокси, TLS, логи, лимиты.
Плюсы WebDAV
- Удобен как «общая папка»: многие ОС и приложения умеют подключаться.
- Работа через стандартные порты: чаще всего 443, что помогает проходить корпоративные ограничения.
- Хорошо сочетается с reverse proxy: можно унифицировать TLS-терминацию, логи и ограничения на загрузку.
Минусы WebDAV на VDS
- Безопасность зависит от реализации: важно настроить аутентификацию, права, TLS и отключить лишние методы там, где они не нужны.
- Не всегда быстрый на большом числе файлов: операции листинга (PROPFIND) могут быть тяжёлыми.
- Конфликты редактирования: если несколько людей правят один файл, заранее решите вопрос с lock/версионированием/регламентом.
Сравнение: SFTP vs FTPS vs rsync vs WebDAV по критериям
Чтобы выбрать протокол под задачу, полезно разложить по нескольким признакам: сеть/порты, автоматизация, удобство для людей и операционные риски.
Сеть, порты и фаервол
- SFTP: обычно один TCP-порт (удобно).
- FTPS: помимо управляющего порта нужен диапазон для пассивного режима (сложнее и потенциально рискованнее).
- rsync по SSH: один порт SSH, плюс знакомая модель доступа.
- WebDAV: 443 (как правило, самый «проходимый» вариант).
Автоматизация и CI/CD
- rsync чаще всего лидер для деплоя и синхронизаций.
- SFTP подходит, но при больших деревьях чаще медленнее и хуже масштабируется по времени.
- FTPS возможен, но в CI/CD нередко усложняет настройку из-за режимов соединения и требований к сертификатам.
- WebDAV удобен для интеграций приложений, но как инструмент деплоя используется реже.
Удобство для конечных пользователей
- WebDAV часто самый «пользовательский»: подключается как диск/папка.
- SFTP тоже понятен: есть много GUI-клиентов и встроенные средства.
- FTPS привычен тем, кто исторически живёт в мире FTP-клиентов.
- rsync — в основном про админов и автоматизацию.
Практические рекомендации для VDS: что выбрать в типовых ситуациях
Ситуация 1: доступ разработчикам к файлам проекта
Если нужен простой и безопасный интерактивный доступ — берите SFTP. Если деплой делается автоматически из CI — лучше rsync по SSH, а SFTP оставить как аварийный/ручной канал.
Ситуация 2: деплой статики/артефактов сборки
Почти всегда оптимально: rsync (скорость, зеркалирование, удаление лишнего, контроль изменений). Для сложных проектов добавьте атомарность релизов и откат; по теме может помочь материал: пошаговый план миграции сайта без простоя.
Ситуация 3: обмен файлами с партнёром, у него только FTPS
Тогда FTPS оправдан, но закладывайте время на настройку диапазона портов, пассивного режима и TLS. На VDS это решаемо, просто сложнее, чем SFTP.
Ситуация 4: «общая папка» для команды/клиента, желательно как диск
Смотрите в сторону WebDAV. Он особенно удобен, когда нужно работать с файлами из приложений, которые умеют WebDAV, или когда корпоративные сети режут нестандартные порты.
Чек-лист выбора протокола (и что проверить перед запуском)
Вопросы к задаче
- Это ручная загрузка файлов или регулярная синхронизация?
- Нужно ли передавать только изменения (дельты) и получать «зеркало как на локальной машине»?
- Кто пользователь: админ/CI или менеджер/клиент?
- Есть ли сетевые ограничения: можно ли открыть нестандартные порты, есть ли NAT, есть ли корпоративные прокси?
Базовые меры безопасности (для любого варианта)
- Открывайте только нужные порты. Для FTPS особенно внимательно относитесь к диапазонам.
- Разделяйте пользователей и права: отдельные учётки под деплой, под контент и под администрирование.
- Включайте логирование и периодически просматривайте аномалии (ошибки входа, неожиданные удаления, всплески трафика).
- Продумайте восстановление доступа: что будете делать, если ключ/пароль утрачен, а доступ нужен срочно.
Итоги: как не ошибиться с выбором
Практическое правило для VDS выглядит так:
- SFTP — универсальный вариант «по умолчанию» для безопасного доступа к файлам.
- rsync — почти всегда лучший выбор для деплоя и синхронизаций (особенно в сравнении rsync vs SFTP на больших деревьях).
- FTPS — берите, когда нужна совместимость со старым миром FTP и внешними требованиями (и будьте готовы к настройке портов и сертификатов).
- WebDAV — удобен как «файловый сервис поверх HTTP/HTTPS», когда важна простота для пользователей и работа через 443.
Частая ошибка — выбирать протокол «потому что привыкли», а не потому что он решает конкретную задачу. На практике обычно хватает одного основного пути (rsync или SFTP) и одного запасного (SFTP или WebDAV) — так вы получаете и удобство, и управляемость.
