FTP хостинг и облачные хранилища: платные и бесплатные решения

FTP и облачные хранилища до сих пор остаются рабочими инструментами для передачи и хранения файлов в IT-инфраструктуре любого масштаба. И дело тут не в ностальгии — протоколу больше 50 лет, — а в том, что он решает конкретные задачи быстрее и проще, чем многие «модные» альтернативы.

Почему FTP до сих пор жив

Протокол FTP придумал в 1971 году студент MIT Абхай Бушан. Это один из первых протоколов передачи файлов — старше HTTP, старше SSH, старше большинства инженеров, которые его используют. Тем не менее FTP поддерживается всеми операционными системами из коробки, без танцев с конфигами.

Главная сила FTP — работа с большими файлами. Протокол поддерживает докачку при обрывах соединения, параллельные потоки передачи и не требует упаковки данных перед отправкой. Когда Вам нужно перекинуть 50-гигабайтный дамп базы на удалённый сервер — FTP отработает быстрее, чем HTTP-загрузка или синхронизация через базовые облачные клиенты. Чистая математика: меньше overhead — быстрее передача.

Но есть нюанс. Базовый FTP передаёт данные открытым текстом — включая логин и пароль. Это было нормально в 1971-м, когда в сети сидели три с половиной исследователя. Сегодня — нет.

Пароль FTP летит по сети в plaintext. Один tcpdump на промежуточном узле — и учётные данные скомпрометированы. FTPS или SFTP обязательны.

FTPS, SFTP, WebDAV: разбираемся в протоколах

Путаница между FTPS и SFTP — классика жанра. Вроде похожие аббревиатуры, а под капотом — два совершенно разных механизма.

FTPS (FTP over SSL/TLS) — это тот же FTP, обёрнутый в SSL-сертификат. Данные шифруются, аутентификация защищена, но архитектура протокола не меняется. Два канала (управление + данные), активный и пассивный режимы — всё на месте. Для корпоративных сетей, где уже настроен FTP-сервер, переход на FTPS — путь наименьшего сопротивления.

SFTP — отдельный протокол, работающий поверх SSH. Один порт (обычно 22), один канал, встроенная аутентификация по ключам. Проще для файрволов, сложнее для legacy-систем, которые привыкли к классическому FTP.

WebDAV — HTTP-расширение для управления файлами. Работает через стандартные порты 80/443, проходит через любой прокси. Удобен для интеграции с веб-приложениями, но для массовых бэкапов терабайтных архивов — избыточен.

Для compliance в корпоративной сети — SFTP или FTPS с IP-фильтрами, квотами и логированием. Для быстрой передачи между доверенными узлами внутри VLAN — хватит и обычного FTP. Контекст решает.

Серверное ПО: чем раздавать файлы

Выбор FTP-сервера зависит от ОС, масштаба и того, сколько времени Вы готовы потратить на настройку.

vsftpd (Very Secure FTP Daemon) — стандарт де-факто на Linux. Стоит в репозиториях Ubuntu, Debian, RHEL. Конфиг — один файл /etc/vsftpd.conf, запуск — пара команд. Потребляет минимум ресурсов, заточен под безопасность. Идеален для задач «поднять FTP за 10 минут и забыть». Ограничение — базовая функциональность, без модулей расширения.

ProFTPD — гибкая альтернатива с конфигом в стиле Apache. Поддерживает виртуальных хостов, SQL-аутентификацию, LDAP, квоты. Если нужно раздать доступ 500 пользователям из Active Directory — ProFTPD справится. Цена — чуть больше RAM и времени на конфигурацию.

Serv-U — коммерческое решение от SolarWinds для Windows. Веб-интерфейс управления, AD-интеграция, кластеризация, аудит-логи для compliance-отчётов. Лицензия — от $600 (~55 000 ₽) за сервер.

IIS FTP — встроенный в Windows Server. Бесплатен, если у Вас уже есть лицензия на Windows Server. Интеграция с Active Directory нативная, настройка через GUI. Производительность — средняя, расширяемость — ограниченная.

Для малого и среднего бизнеса на Linux — vsftpd или ProFTPD закрывают 90% задач. Если у Вас Windows-инфраструктура и нужен compliance — Serv-U или IIS.

Облачные хранилища с FTP-доступом

Вот здесь начинается интересное. Облачные провайдеры давно научились интегрировать FTP-доступ к своим хранилищам. Вы получаете облачную надёжность (репликация, DDoS-защита, SLA) и привычный протокол для автоматизации.

Selectel позволяет подключить S3-совместимое хранилище по FTP, FTPS или SFTP. Данные хранятся в трёх копиях, цена стартует от 0,81 ₽/мес за гигабайт. Для тех, кто привык работать с FileZilla или WinSCP — всё подключается за 5 минут через стандартные FTP-клиенты.

Cloud.ru (бывший SberCloud), Yandex Cloud, VK Cloud — все предлагают объектные хранилища с S3 API. Прямого FTP-доступа у них нет, но поднять gateway-прокси (s3fs-fuse, rclone) занимает полчаса. Это не чистый FTP, а обёртка — со всеми вытекающими ограничениями по скорости случайного доступа.

Специализированные FTP-хостинги (ihor.online, FirstByte, Xelent) предлагают именно арендованное дисковое пространство с FTP/SFTP-доступом. Тарифы начинаются от 1–2 ₽ за гигабайт в месяц, есть бесплатные предложения на 25–100 Гб. Серверы размещены в российских дата-центрах Tier III, с DDoS-защитой и RAID-массивами. Некоторые провайдеры строят хранилища на базе Ceph с трёхкратной репликацией — данные живут на трёх физических узлах одновременно, и выход из строя одного диска или целого сервера не приводит к потерям.

Отдельная категория — FTP-доступ к облачным хранилищам через gateway. Rclone, s3fs-fuse, goofys — все эти инструменты монтируют S3-бакет как файловую систему или проксируют FTP-запросы в S3 API. Работает, но с оговорками: случайный доступ к мелким файлам медленнее, чем на нативном FTP, а листинг директорий с миллионом объектов превращается в долгую операцию. Для потоковых бэкапов крупных файлов — приемлемо. Для ежедневной работы с тысячами мелких файлов — лучше поднять честный FTP-сервер.

Бесплатный FTP-хостинг на 25–100 Гб — рабочий вариант для бэкапов небольших проектов. Проверьте SLA и политику хранения перед миграцией прода.

Экономика: считаем деньги

Вопрос «поднять свой FTP или арендовать» — это вопрос TCO (Total Cost of Ownership).

Собственный FTP-сервер на выделенном железе — это покупка сервера (от 100 000 ₽ за б/у 2U с RAID), лицензии на ОС (если Windows), электричество, канал, время администратора. Для компании с парой терабайт бэкапов и штатным сисадмином — вариант рабочий.

Аренда FTP-хранилища у провайдера — от 400 ₽/мес за 200 Гб до 5 000–10 000 ₽/мес за терабайт. DDoS-защита, физическая безопасность дата-центра и RAID — включены в цену. Не нужно покупать диски, менять их при сбоях и следить за температурой в серверной.

Бесплатные облака (Google Drive 15 Гб, Mega 20 Гб) — подходят для личных файлов и мелких проектов. Для бизнес-бэкапов — нет. Отсутствие SLA, риск блокировки аккаунта, ограничения API — всё это превращает «бесплатно» в «дорого» при первом же инциденте.

Для SMB с бюджетом и без штатного инженера — аренда FTP-хранилища или S3 с SFTP-gateway. Для enterprise с compliance-требованиями — Serv-U на выделенном сервере в колокации или managed-хранилище у крупного провайдера (Selectel, Cloud.ru).

Скорость: что влияет на передачу данных

Пропускная способность FTP зависит не только от ширины канала. Есть несколько факторов, которые часто упускают из виду.

Параллельные соединения: FTP поддерживает многопоточную передачу. FileZilla по умолчанию открывает до 10 параллельных соединений — и на гигабитном канале это даёт ощутимый прирост относительно однопоточной загрузки. Если провайдер ограничивает число соединений на аккаунт (обычно 5–20), — передача замедляется.

Шифрование: FTPS и SFTP добавляют CPU overhead. На сервере с Xeon E5-2690 v4 (14 ядер) это незаметно. На VPS с двумя vCPU — разница между FTP и SFTP может достигать 15–20% на потоке в 500 Мбит/с.

Латентность: для передачи терабайтных дампов между Москвой и Новосибирском (RTT ~45 мс) размер TCP-окна и буферизация важнее, чем «чистая» скорость канала. Увеличение TCP window size в sysctl и настройка буфера FTP-сервера дают ощутимый прирост.

S3-совместимые хранилища (MinIO, Ceph) с multipart upload обгоняют классический FTP на файлах свыше 5 Гб — за счёт параллельной загрузки фрагментов и автоматических retry. Каждый фрагмент (обычно 64–128 Мб) загружается отдельным потоком, и при обрыве переотправляется только он, а не весь файл целиком. Это вариант для edge computing и распределённых архитектур, где FTP уже не справляется с требованиями к отказоустойчивости и масштабу.

Замеры из реальных тестов: передача 100 Гб дампа через vsftpd по гигабитному каналу (без шифрования, один поток) занимает около 15 минут. Тот же объём через SFTP — 17–18 минут. Через rclone в S3 с multipart upload (8 потоков) — 12–13 минут. Разница не катастрофическая, но при ежедневных бэкапах за месяц набегают часы.

Когда FTP — не ответ

FTP хорош для прямолинейных задач: забрать файл, положить файл, автоматизировать бэкап. Но если Вам нужно версионирование объектов, политики жизненного цикла (lifecycle policies), интеграция с CI/CD пайплайнами или гранулярный контроль доступа на уровне объектов — S3 API закроет эти потребности лучше.

Не стоит строить на FTP систему обмена файлами для 200 сотрудников. Для этого есть Nextcloud, Seafile или тот же SharePoint. FTP — инструмент инженера, а не портал для бухгалтерии.

Безопасность: чеклист для параноиков

Если Вы уже решили поднять FTP-сервер или арендовать хранилище — потратьте полчаса на базовую защиту. Это не формальность, а гигиена.

IP-фильтрация — первый рубеж. В vsftpd это директива tcp_wrappers=YES и файлы /etc/hosts.allow, /etc/hosts.deny. В Serv-U — графический интерфейс с белыми и чёрными списками. Ограничьте доступ диапазоном IP-адресов офиса и VPN — уже одним этим Вы отсечёте 99% автоматизированных атак.

Квоты на дисковое пространство — защита от случайного (или намеренного) переполнения хранилища. В ProFTPD настраиваются через модуль mod_quotatab, в vsftpd — средствами ОС (setquota). Без квот один «щедрый» скрипт бэкапа может забить весь диск и положить соседние сервисы.

Логирование — третий элемент. Формат xferlog в vsftpd записывает каждую операцию: кто, когда, какой файл, в каком направлении. Для compliance (ФЗ-152, PCI DSS) эти логи хранятся отдельно от самого FTP-сервера и ротируются через logrotate. Пренебрежёте — при аудите придётся объяснять, почему нет следов доступа к персональным данным.

Отдельно про пассивный режим: если FTP-сервер стоит за NAT, настройте диапазон портов для PASV-соединений (pasv_min_port, pasv_max_port в vsftpd) и откройте эти порты на файрволе. Без этого клиенты будут подключаться, авторизовываться — и зависать при попытке получить листинг директории. Классическая проблема, на которую уходят часы дебага.

Миграция с self-hosted на облако

Типичный сценарий: в компании 5 лет крутился FTP на стареющем сервере в серверной. Диски начали сыпаться, RAID degraded, а бюджет на новое железо — не согласован. Переезд на облачный FTP-хостинг выглядит логично.

Алгоритм миграции прямой. Разворачиваете аккаунт у провайдера, получаете реквизиты для подключения. Через rsync поверх SSH (или через lftp в режиме mirror) синхронизируете файловую структуру. Меняете DNS-запись или IP в скриптах бэкапа. Тестируете подключение из всех точек — офис, VPN, CI-сервер. Отключаете старый сервер.

Подводный камень — права доступа. На локальном FTP у Вас были UNIX-права, chroot-jail, виртуальные пользователи. У облачного провайдера модель доступа может отличаться: один аккаунт на всё хранилище или ограниченное число пользователей. Проверьте это до миграции, а не после.

Ещё один момент — скорость первичной синхронизации. Если у Вас 2 Тб данных и канал 100 Мбит/с — загрузка займёт около 45 часов. Планируйте миграцию на выходные и не забудьте про delta-sync: не нужно перезаливать всё при повторном запуске.

# Зеркалирование FTP через lftp с докачкой

lftp -e "mirror --reverse --verbose --continue \

  /local/backup/ /remote/backup/; quit" \

  -u "$USER,$PASS" ftps://new-storage.example.com

Протоколу 55 лет, и он продолжает работать — потому что прост, предсказуем и делает ровно то, что от него ждут. Выбор между FTP хостингом и облачным хранилищем определяется не модой, а задачей, бюджетом и тем, кто будет это поддерживать в три часа ночи.