Если вынести бэкапы «куда-то наружу», вопрос быстро упирается не в цену гигабайта, а в протокол и свойства хранилища: выдержит ли оно много мелких файлов, даст ли нормальный throughput, есть ли внятная модель прав, можно ли включить immutability, и как не потерять данные из‑за человеческой ошибки или шифровальщика.
На практике у админов и DevOps чаще всего всплывают три варианта: S3-compatible объектное хранилище, WebDAV и SFTP. Они решают похожую задачу (удалённое хранение), но ведут себя по‑разному под нагрузкой, в сценариях восстановления и в вопросах безопасности.
Ниже — сравнение «без маркетинга»: где сильные стороны каждого варианта, где типовые ловушки и как это ложится на связку с restic, borg и rclone. По пути разберём server-side и client-side encryption, а также практику immutability и retention.
Модель данных: объектное хранилище vs файловый доступ
Ключевое различие — не в порте и не в утилите, а в модели данных: «объекты через API» или «файлы по сети».
S3-compatible: объекты, версии и политики
S3 — это объектное хранилище: вы кладёте объект в бакет, у объекта есть ключ (путь-подобная строка), метаданные, версии (если включены), политики доступа и часто lifecycle-правила. Внутри нет «настоящей» POSIX-ФС: нет гарантированно атомарного rename() как на локальном диске, нет привычных блокировок файловой системы.
Сильная сторона S3-compatible в том, что оно изначально спроектировано под параллелизм, версионирование и управляемое хранение по времени. Там, где на SFTP/WebDAV обычно нужен отдельный сервер, снапшоты и строгая дисциплина, у S3-compatible часто есть нативные механики вроде Object Lock/WORM (immutability) и lifecycle (retention).
WebDAV и SFTP: «папка по сети», но с нюансами
WebDAV расширяет HTTP методами для работы с файлами (PROPFIND, MOVE, LOCK и т.д.) и выглядит как удалённая «папка». SFTP — подсистема SSH для файловых операций. Оба варианта ближе к привычному файловому миру: каталоги, файлы, права, удаление.
Это делает их понятными, но не гарантирует, что они хорошо подходят под современные бэкапы, где сотни тысяч маленьких чанков и большой параллелизм — норма. Кроме того, для файловых протоколов вы почти всегда сами отвечаете за серверную часть: обновления, диск, мониторинг, резервирование.
Throughput и задержки: где реально быстрее
Для бэкапов важны два разных показателя:
- пропускная способность на больших потоках данных;
- производительность на мелких операциях (много файлов/объектов, листинг, проверки, метаданные).
S3-compatible: сильнее на параллелизме
Объектные API часто выигрывают, когда клиент умеет распараллеливать загрузку (multipart, несколько потоков) и когда хранилище не упирается в один сервер. Для инструментов уровня rclone это стандарт: увеличили количество потоков — упёрлись в сеть или лимиты провайдера, но не в «одного демона», как бывает у SFTP.
Нюанс: если инструмент делает очень много «маленьких запросов» (частые list/stat), латентность S3 API становится заметной. Тут решают детали реализации S3-compatible и то, насколько эффективно клиент кэширует и группирует операции. Если хотите углубиться в практические настройки скорости, пригодится материал про настройку multipart и параллелизма rclone для S3.
SFTP: часто упирается в один сервер и CPU
SFTP — это один SSH-сервер (или кластер, но тогда нужна своя архитектура). Сквозная скорость обычно зависит от:
- CPU на шифрование SSH (особенно на небольших VM);
- дисковой подсистемы на стороне сервера;
- параллелизма (одной сессии часто мало);
- параметров TCP и окна, которые влияют на «дальние» каналы.
В простом варианте «один сервер, один каталог для бэкапов» SFTP может быстро стать узким горлом, если источников много. Зато предсказуемость высокая: видно, где упёрлось (CPU, диск, сеть), и это проще дебажить.
WebDAV: бывает нормально, но сильно зависит от реализации
WebDAV часто поднимают поверх веб‑сервера и обычной файловой системы. Он может быть быстрым на больших файлах, но на «бэкапных» сценариях с множеством мелких объектов и частыми PROPFIND нередко становится больно. Дополнительно WebDAV иногда провоцирует лишние round-trip из‑за метаданных и блокировок.
Практическое правило: если бэкап — это «много чанков + дедупликация + параллельная заливка», чаще выигрывает S3-compatible. Если «один архив в сутки», SFTP/WebDAV могут быть проще и вполне достаточны.
Совместимость с restic, borg и rclone
Инструмент бэкапа — половина решения. Важно, что именно он делает поверх выбранного транспорта и насколько «родным» является бэкенд.
restic
restic отлично чувствует себя с S3-compatible: это один из самых популярных и «нативных» бэкендов. Restic пишет данные чанками, активно работает с индексами и метаданными репозитория и выигрывает от стабильной работы API и параллелизма.
Restic умеет работать и по SFTP. Обычно этот вариант выбирают, когда нужно «быстро и просто» на свой сервер. Но чаще он упирается в производительность конкретного SFTP-сервера и файловой системы, особенно при росте количества снимков и параллельных задач. Если вы выбираете S3 как основную цель для restic/borg-сценариев, пригодится отдельный разбор: как хранить бэкапы в S3: практические схемы для restic и borg.
С WebDAV история сложнее: можно пытаться через прокладки и монтирование, но для надёжных бэкапов лучше избегать схем, где репозиторий «кажется локальной папкой», а на деле это сеть с кешами, таймаутами и внезапными обрывами.
borg
borg исторически ориентирован на доступ к репозиторию как к файловой структуре (локально или по SSH). Поэтому классика — borg по SSH: это даёт хороший контроль и зрелую практику эксплуатации (отдельный пользователь, ограниченные ключи, понятные права).
С S3-compatible для borg обычно идут через дополнительные слои (синхронизацию/экспорт репозитория), что повышает риск неконсистентности при ошибках и прерываниях. Если нужен «нативный S3 без лишних прослоек», чаще выбирают restic.
rclone
rclone — универсальный «транспорт»: умеет и S3-compatible, и WebDAV, и SFTP. Для сценария «складывать готовые архивы/дампы» rclone часто идеален: шифрование на клиенте через rclone crypt, проверки, синхронизация, лимиты скорости.
Но важно помнить: rclone — не бэкап-система сама по себе. Он не заменяет дедупликацию, план восстановления и политики хранения, если вы не настроили это отдельно.
Шифрование: server-side vs client-side
Про шифрование в бэкапах лучше думать как про два разных слоя: «шифрование в покое» и «шифрование до отправки».
Server-side encryption: удобно, но не всегда достаточно
Server-side encryption означает, что данные «на диске сервиса» лежат зашифрованными, а ключи управляются на стороне провайдера (иногда с интеграцией KMS). Это хорошо снижает риск утечки при компрометации физического носителя, но:
- не защищает от чтения через API при утечке ключей доступа;
- не всегда подходит под требования, где провайдер не должен иметь доступа к ключам.
Client-side encryption: ваш ключ — ваша ответственность
Client-side encryption — когда вы шифруете данные до отправки в хранилище. Restic и borg делают это по умолчанию на уровне репозитория. Rclone может шифровать через crypt.
Для SFTP/WebDAV важно не путать шифрование «в канале» (TLS/SSH) и шифрование «в покое»: если на удалённой стороне лежит незашифрованный tar.gz, то компрометация бэкап‑сервера = компрометация содержимого бэкапов. В большинстве случаев разумно выбирать модель, где содержимое на удалённом хранилище зашифровано вашим ключом.
Immutability и retention: защита от удаления и шифровальщика
Главный враг бэкапа — не падение диска, а сценарии, когда бэкапы удалили или зашифровали вместе с продом. Поэтому immutability и retention — критические свойства.
S3-compatible: сильная сторона — политики хранения
Во многих S3-compatible реализациях можно включить версионирование и режимы, близкие к WORM: объект нельзя удалить или перезаписать до истечения срока. Это и есть практическая immutability. Плюс можно настроить lifecycle, который будет чистить старые версии по правилам (retention), не полагаясь только на то, что вы всегда вовремя выполните forget --prune или аналогичную ротацию.
Важно: immutability в S3 — не «галочка». Она меняет модель восстановления после компрометации: даже если атакующий получил ключ и попытался удалить бэкапы, хранилище может физически запретить удаление в пределах retention-окна.
SFTP/WebDAV: чаще держится на дисциплине и архитектуре
На SFTP/WebDAV иммутабельность обычно достигается организационными и инфраструктурными мерами:
- отдельный сервер под бэкапы (не тот же хост, что прод);
- раздельные учётки и ключи «только на запись» там, где это возможно;
- ограничения пользователя SSH (chroot/ограничение путей, запрет shell);
- снапшоты файловой системы/тома по расписанию;
- второй уровень копирования (в другое место) или офлайн-копия.
Это работает, но требует аккуратной эксплуатации и даёт больше шансов на «дырку», когда один неверный доступ (или root на бэкап‑сервере) позволяет уничтожить всё.
Операционная надёжность: что проще поддерживать годами
S3-compatible
Плюсы: меньше серверной рутины (если хранилище управляемое), масштабируемость, удобные политики retention, часто высокая доступность. Минусы: нужна аккуратность с ключами доступа, понимание стоимости операций и нюансов API, плюс обязательная привычка регулярно тестировать восстановление.
SFTP
Плюсы: простая модель, легко дебажить, всё прозрачно. Минусы: вы обслуживаете сервер, диск, мониторинг, обновления, лимиты. При росте объёмов и количества клиентов придётся продумывать масштабирование (и оно не «из коробки»).
WebDAV
Плюсы: часто легче проходит через корпоративные сети, иногда проще для «пользовательских» интеграций. Минусы: неоднородность реализаций, проблемы на мелких файлах и метаданных, повышенный риск странных таймаутов и несовместимостей клиентов.
Безопасность: ключи, права и поверхность атаки
С точки зрения безопасности полезно разложить вопрос на три уровня: аутентификация, авторизация, и «что будет, если утечёт ключ/пароль».
- S3-compatible: доступ обычно через access key/secret key. Важно делать минимальные политики (только нужный бакет, только нужные операции), разделять ключи по средам, ротировать и хранить секреты безопасно. При утечке ключа атакующий получает доступ по API, поэтому версионирование и immutability резко повышают устойчивость.
- SFTP: опора на SSH-ключи. Можно ограничивать пользователя и каталоги, отключать shell, использовать отдельный ключ только для бэкапа. При компрометации ключа злоумышленник получает файловый доступ в рамках прав — и если права позволяют удалять, бэкап уязвим.
- WebDAV: часто используют basic/digest или токены поверх HTTPS. Ошибка в настройке веб‑сервера, лишние методы, неверные права на каталог — типовые причины инцидентов. Для бэкапов это рискованнее, чем кажется.
Типовые сценарии: что выбирать в реальной жизни
1) Бэкапы приложений и VM, нужен простой restore
Если вы храните большие архивы или образы и вам важно просто скачать файл и развернуть — SFTP или S3-compatible одинаково уместны. Выбор чаще упирается в требования к immutability и в то, насколько вы готовы администрировать отдельный бэкап‑сервер.
2) Дедупликация, много снапшотов, много источников
Чаще побеждает S3-compatible в паре с инструментом, который комфортно с ним работает (например, restic): лучшее масштабирование по throughput, проще удерживать рост объёма, проще добавить retention на стороне хранилища.
3) «Нужна папка, куда кладём бэкапы по SSH, и всё»
SFTP — самый прямой путь. Он хорош, когда требований немного, команда небольшая и вы хотите минимальную «магию». Но заложите ограничения сразу: отдельный сервер, мониторинг места, регулярные снапшоты и план на «что будет при 10x росте».
4) WebDAV «потому что так исторически сложилось»
Если WebDAV уже используется и работает — можно оставить, но для долгосрочного backup storage я бы оценил миграцию на S3-compatible или SFTP. У WebDAV слишком много тонких мест: от совместимости клиентов до сюрпризов на количестве файлов.
Чек-лист выбора: вопросы до внедрения
- Сколько объектов/файлов будет создаваться в сутки: «1 архив» или «миллионы чанков»?
- Нужна ли immutability (защита от удаления/перезаписи) и на какой срок?
- Где будет шифрование: client-side encryption (предпочтительно) или только server-side encryption?
- Как будет устроена retention: на стороне инструмента бэкапа, на стороне хранилища, или в обоих местах?
- Какая целевая скорость восстановления: сколько минут/часов вы можете себе позволить?
- Сколько рутины вы готовы обслуживать: сервер под SFTP/WebDAV или управляемое S3-compatible?
- Как именно вы будете тестировать restore и как часто?
Вывод
Для современных бэкап-сценариев (много снапшотов, параллелизм, требования к защите от удаления) S3-compatible чаще всего даёт лучший баланс: высокий throughput, удобные политики retention и возможность построить immutability на уровне хранилища.
SFTP остаётся отличным «рабочим» вариантом, когда нужна максимальная простота и прозрачность, а объёмы и параллелизм умеренные. Но за простоту вы платите обслуживанием сервера и более слабой защитой от разрушительных действий, если не построили отдельную архитектуру.
WebDAV имеет право на жизнь, но как основа для надёжного backup storage его обычно выбирают реже: слишком зависит от реализации и хуже переносит бэкапную нагрузку с большим количеством операций по метаданным.
