Альтернативы S3 для self-hosted в 2026 году (RustFS, Garage, SeaweedFS, Ceph)
Выбор самохостеджного S3 после MinIO
Amazon S3 стала де-факто стандартом API для объектного хранилища. После того, как репозиторий открытого исходного кода MinIO был архивирован в апреле 2026 года, осталось семь заслуживающих доверия самодостаточных альтернатив.
Эти варианты не взаимозаменяемы. Некоторые из них представляют собой полноценные движки объектного хранилища, которые управляют собственным форматом хранения данных; другие — это тонкие шлюзы, предоставляющие доступ к файлам, которые у вас уже есть. Именно это разделение — нативное хранилище или файловый шлюз — определяет больше всего в вопросах резервного копирования, восстановления и миграции, чем любой список функций.
В этой статье сравниваются RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy и rclone. Каждый раздел описывает модель хранилища, уровень поддержки функций S3, область применения проекта и то ограничение, которое обычно определяет выбор. В конце статьи приводится руководство по выбору для развертывания на одном сервере и на нескольких серверах.
Для более общей картины — объектное хранилище, базы данных, поиск и ИИ-нативные данные — см. Инфраструктура данных для ИИ-систем.
Сравнение самодостаточных S3-хранилищ
Самый важный вопрос — нужна ли вам распределенное объектное хранилище или S3-интерфейс перед уже существующим хранилищем.
| Программное обеспечение | Модель хранилища | Распределенность | Совместимость с S3 | Обычные файлы на диске | Сложность | Лучшее применение |
|---|---|---|---|---|---|---|
| RustFS | Нативное объектное хранилище | Да | Высокая, протестированный подмножество | Нет | От низкой до средней | Общая замена MinIO |
| Garage | Нативное объектное хранилище | Да | Хорошая, более узкий API | Нет | От низкой до средней | Небольшие распределенные кластеры |
| SeaweedFS | Распределенное хранилище blob и файлов | Да | Высокая | Нет | Средняя | Огромное количество файлов и смешанное хранилище |
| Ceph RGW | Объектный шлюз Ceph | Да | Высокая | Нет | Высокая | Крупная инфраструктура хранения |
| VersityGW | S3-шлюз поверх POSIX | Зависит от бэкенда | Хорошая | Да | Низкая | S3 поверх обычных файлов |
| S3Proxy | S3-трансляционный слой | Зависит от бэкенда | Умеренная | Да с filesystem-nio2 | Средняя | Шлюзы и трансляция протоколов |
| rclone serve s3 | S3-шлюз | Зависит от бэкенда | Базовая, экспериментальная | Да с локальным бэкендом | Очень низкая | Простые и легковесные развертывания |
RustFS является ближайшей прямой заменой традиционного развертывания MinIO. Garage подходит для небольших распределенных кластеров. SeaweedFS и Ceph решают более широкие задачи хранения. VersityGW может предоставить доступ к существующей POSIX файловой системе через S3, сохраняя сами объекты обычными файлами. Для детальной таблицы сравнения функций Garage, MinIO и AWS S3 см. Garage vs MinIO vs AWS S3.
Два различных типа S3-хранилища
Нативное объектное хранилище владеет собственным форматом хранения:
RustFS, Garage, Ceph RGW и SeaweedFS относятся к этой категории. Файлы, видимые на базовых дисках, являются деталями реализации, и приложения не должны манипулировать ими напрямую.
Файловый S3-шлюз имеет другую связь с хранилищем:
С помощью такого программного обеспечения, как VersityGW, файловая система может оставаться авторитетным представлением данных. Объект, такой как:
s3://archive/documents/2026/report.pdf
может соответствовать напрямую:
/storage/archive/documents/2026/report.pdf
RustFS: Ближайшая замена MinIO
RustFS — это распределенная система объектного хранилища, написанная на Rust и выпущенная под лицензией Apache-2.0. Он предоставляет S3-ориентированную модель работы, знакомую пользователям MinIO, что делает его первым проектом, который стоит оценить при замене MinIO.
Текущая реализация S3 в RustFS покрывает операции, которые большинство приложений ожидают: бакеты, объекты, многочастичная загрузка (multipart uploads), условные запросы, метаданные объектов, теги, версионирование, управление жизненным циклом, блокировка объектов, presigned URL, политики бакетов, CORS, уведомления, конфигурация репликации и серверное шифрование.
RustFS публикует матрицу совместимости с S3, которая представляет собой протестированный подмножество, а не заявление о полной совместимости с Amazon S3. Снимок, проверенный по коммиту 1e6f5f1e от 9 августа 2026 года, содержит 455 реализованных стандартных тестов, 5 тестов поведения жизненного цикла, 17 нереализованных стандартных тестов и 270 исключенных случаев, которые не блокируют прохождение проверки совместимости. Исполняемые списки в каталоге scripts/s3-tests являются источником правды, когда эти цифры меняются.
Где уместен RustFS
RustFS является кандидатом, когда приложение ожидает полноценного S3 объектного хранилища.
Типичное использование включает объектное хранилище приложений, репозитории резервных копий, хранилище медиафайлов, артефакты ИИ и потоков данных, внутренняя S3-инфраструктура, рабочие нагрузки Kubernetes и замена существующих эндпоинтов MinIO.
Он работает с SDK от AWS и общими S3-клиентами. Приложениям обычно требуется настраивать кастомный эндпоинт, учетные данные, настройки региона (при необходимости) и использование пути (path-style addressing).
Важное ограничение
RustFS владеет представлением хранилища. Файлы в каталоге данных RustFS являются внутренними данными RustFS.
Это делает RustFS неправильным решением, когда требование состоит в том, чтобы каждый S3-объект оставался обычным файлом, который можно исследовать, копировать, синхронизировать с помощью rsync или восстанавливать без программного обеспечения объектного хранилища. Это требование указывает на выбор файлового шлюза.
Garage: Распределенный S3 без сложности Ceph
Garage — это S3-совместимое распределенное объектное хранилище для небольших и средних самодостаточных инсталляций. Его разрабатывает компания Deuxfleurs под лицензией AGPL v3, и он используется в production-среде с момента первоначальных выпусков проекта в 2020 году.
Garage создан для работы на нескольких обычных серверах, включая серверы в разных физических локациях. Репликация является частью дизайна.
Garage привлекателен, когда у вас есть три небольших сервера, а не стойка с выделенным оборудованием для хранения. Рабочий путь настройки, от Docker до топологии кластера, репликации и TLS через reverse-proxy, описан в быстром старте Garage.
Где уместен Garage
Garage имеет смысл для homelab-сред, небольших хостинговых платформ, географически распределенных серверов, реплицированных резервных копий и кластеров, где Ceph был бы избыточным.
Его функциональность уже, чем у AWS S3. В таблице совместимости Garage отсутствуют политики бакетов, ACL и версионирование бакетов. Выбирайте Garage вместо RustFS, когда легковесная многоузловая репликация является основным требованием. Выбирайте RustFS, когда важнее более широкая поддержка S3 и совместимость с приложениями, работающими с MinIO.
SeaweedFS: Больше, чем объектное хранилище
SeaweedFS начинался как решение для эффективного хранения огромного количества файлов. Сейчас это распределенная платформа хранения, предоставляющая S3, файловую систему FUSE, WebDAV, SFTP и HDFS. SeaweedFS 4.48 была выпущена 28 сентября 2026 года.
Серверы объема (volume servers) упаковывают blob-объекты в append-only файлы объема. Мастера отслеживают тома, а не отдельные файлы. Filer предоставляет семантику иерархической файловой системы. Дизайн нацелен на рабочие нагрузки с миллионами или миллиардами относительно небольших объектов.
Поддержка S3
SeaweedFS документирует версионирование, блокировку объектов, правила жизненного цикла, тегирование, CORS, контрольные суммы, presigned URL, multipart-загрузки, политики бакетов, IAM, STS и несколько режимов серверного шифрования.
Один и тот же кластер может обслуживать S3 табличные бакеты и встроенный REST-каталог Iceberg, поэтому Spark, Trino, DuckDB и аналогичные движки могут использовать таблицы Iceberg без отдельного Hive Metastore или Glue. Однокомандный пример S3 проекта слушает порт 8333.
Где уместен SeaweedFS
Рассматривайте SeaweedFS для веб-краулеров и архивов, репозиториев изображений и документов, миллиардов небольших объектов, озёр данных, смешанных S3 и файловых нагрузок, а также для хранилища, которое расширяется за счет добавления серверов объема.
Здесь нужно понимать больше компонентов, чем в простой установке RustFS. SeaweedFS может предоставить семантику файловой системы через свой filer и FUSE-монтирование, но объекты хранятся внутри формата его томов. Он не удовлетворяет требованию, чтобы каждый S3-объект оставался независимым обычным файлом в файловой системе хоста.
Ceph RGW: Вариант инфраструктуры крупного масштаба
Ceph шире, чем просто S3-хранилище. Кластер может предоставлять блочные устройства через RBD, файловую систему через CephFS и объектное хранилище через RADOS Gateway (RGW). RGW представляет S3-совместимый API, подкрепленный RADOS.
Ceph поддерживает репликацию, кодераспределение (erasure coding), домены отказов, несколько шлюзов, мультисайтовые развертывания, политики доступа и инструментацию управления кластером.
Где уместен Ceph
Ceph имеет смысл, когда объектное хранилище является одной частью более крупной платформы хранения: постоянные тома Kubernetes, диски виртуальных машин, общие файловые системы, крупные S3-репозитории и кластеры, которым нужны явные домены отказов.
Для одного сервера с несколькими терабайтами установка Ceph только ради получения S3-эндпоинта трудно обосновать. Если вы уже управляете Ceph, RGW — очевидный выбор для S3. Если нет, RustFS или Garage достигают полезного объектного хранилища с меньшим количеством механизмов.
VersityGW: S3 поверх обычных файлов
VersityGW — это вариант, который стоит оценить, когда сама файловая система важна. Это S3-шлюз под лицензией Apache-2.0, который может предоставить доступ к POSIX-файловым системам, ScoutFS, Azure Blob Storage, другим S3-сервисам и пользовательским бэкендам.
Его POSIX-бэкенд отображает S3-бакеты и объекты на каталоги и файлы. Например:
s3://website-assets/images/logo.png
соответствует пути, такому как:
/storage/website-assets/images/logo.png
Нагрузка logo.png остается обычным файлом.
Почему обычные файлы полезны
Вы можете исследовать хранилище с помощью обычных Unix-инструментов:
find /storage -type f
du -sh /storage/*
Вы можете прочитать объект без S3-сервера:
cat /storage/archive/2026/source.html
Традиционные инструменты резервного копирования файловой системы применяются напрямую: rsync, restic, borg, tar и zfs send. Если программное обеспечение шлюза исчезнет, нагрузки останутся файлами в древовидной структуре каталогов.
S3-метаданные в POSIX-бэкенде
S3-метаданные не помещаются в сам POSIX-файл. VersityGW по умолчанию хранит их в расширенных атрибутах. С марта 2026 года метаданные объекта — это единый xattr user.metadata, содержащий JSON, потому что один xattr на ключ достигал ограничений длины ключа файловой системы. Команда versitygw utils convert-xattr-metadata переписывает старые атрибуты по ключам. При чтении система по-прежнему откатывается к старой схеме, если user.metadata отсутствует.
Файловые системы без xattr могут использовать --sidecar (или VGW_META_SIDECAR), чтобы хранить метаданные в отдельном древовидном каталоге. Проект помечает sidecar и --nometa как менее протестированные, чем xattr. --nometa отключает хранение метаданных и нацелен на только-чтение хостинг датасета, который уже существует; политики бакетов и ACL — это метаданные, поэтому в этом режиме они недоступны.
Версии объектов могут храниться в отдельном каталоге. В POSIX-примере проекта передается --versioning-dir для старых версий, в то время как текущая нагрузка остается в своем естественном пути.
Изменение файла за шлюзом может привести к несоответствию S3-метаданных, включая ETag, с новыми байтами. Рабочая модель эксплуатации:
Доступ приложения:
Чтение через S3
Запись через S3
Доступ администратора:
Чтение файловой системы напрямую
Исследование файловой системы напрямую
Резервное копирование файловой системы напрямую
Избегать изменения объектов за шлюзом
VersityGW 1.8.0, версия, которая уже стала целевой для релиза COSI-драйвера в сентябре 2026 года, добавляет независимый сервис IAM (versitygw iam), STS AssumeRoleWithWebIdentity и условия IAM-политик.
S3Proxy: Универсальный трансляционный слой
S3Proxy реализует S3 API и транслирует запросы на несколько бэкендов: локальные файлы, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP и другие S3-сервисы. Требует Java 17 или новее.
Рекомендуемый провайдер на диске — filesystem-nio2. Старый провайдер filesystem устарел. Ключи объектов становятся путями файловой системы, а метаданные используют пользовательские расширенные атрибуты, поэтому нагрузки остаются обычными файлами.
Файловый бэкенд отказывает в версионировании объектов и серверном шифровании. Версионирование остается неподдерживаемым (supportsVersioning() возвращает false, и такие запросы остаются HTTP 501), потому что схема версий, записанная на реальный диск, стала бы форматом, который проекту пришлось бы поддерживать. Серверное шифрование отказывается по той же классу причин: сообщение о AES256 поверх текстового файла, который кто-то может прочитать, было бы ложным утверждением. In-memory бэкенд transient-nio2 реализует оба, и данные погибают вместе с процессом. README проекта также указывает политики бакетов, тегирование объектов и ACL, отличные от private и public-read, как неподдерживаемые.
S3Proxy — инструмент, когда вам нужна эта трансляция между бэкендами. Для прямого S3-to-POSIX шлюза VersityGW имеет меньшую поверхность.
rclone serve s3: Легковесный, но экспериментальный
rclone serve s3 предоставляет доступ к bэкенду rclone через S3-совместимый API. Документация по-прежнему помечает команду как экспериментальную.
Для локальной файловой системы:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Без --addr сервер связывается с 127.0.0.1:8080. --auth-key включает Signature Version 4. Многочастичная загрузка записывается в временный объект в порядке номеров частей и переименовывается на место по завершении, так что неудачная загрузка не заменяет существующий объект.
Объекты, записанные через бэкенд local, становятся файлами под этим путем. Та же команда может стоять перед другими remote-бэкендами rclone. Это разумный выбор для внутреннего инструментария, лаборатории или временного этапа миграции. Это слабый постоянный S3-слой для многих неродственных production-приложений.
Что насчет MinIO?
Репозиторий MinIO на GitHub был архивирован 13 февраля 2026 года, кратковременно расархивирован, и снова архивирован 25 апреля 2026 года. Он доступен только для чтения. Уведомление в репозитории направляет операторов к AIStor, коммерческому дистрибутиву MinIO, и утверждает, что community-издание доступно только в виде исходного кода.
Существующее развертывание MinIO может продолжать работать, особенно если оно изолировано и его поведение уже понятно. Полный хронологический порядок, операционные риски и поэтапный план миграции изложены в MinIO CE в 2026.
Для понимания S3-поведения системы, которую вы можете оставить, MinIO как альтернатива AWS S3 документирует, как MinIO соответствует S3. Шпаргалка по командам MinIO — это компаньон для аудита кластера, который все еще работает. Для новой установки активная поддерживаемая альтернатива — это стандарт.
Обычные файлы против нативного объектного хранилища
Используйте RustFS, Garage, SeaweedFS или Ceph, когда объектное хранилище должно контролировать долговечность, метаданные, распределение и формат. Это обеспечивает более богатую семантику S3, репликацию или кодераспределение, горизонтальное масштабирование и версионирование, если проект его реализует. Цена — зависимость от на-дисковом представлении движка.
Используйте VersityGW, S3Proxy или rclone, когда существующая файловая система должна оставаться авторитетной. Это обеспечивает простые восстанавливаемые файлы, традиционное резервное копирование, прямое исследование и совместимость с ZFS, XFS, ext4 и NFS. Распределенная долговечность тогда должна идти от файловой системы или массива хранения, а не от процесса S3. На одном сервере или NAS этот обмен часто является правильным.
Выбор правильного самодостаточного S3-сервера
Для одного сервера, который должен напоминать MinIO, начните с RustFS.
Для трех или более скромных серверов, где репликация является основным требованием, и приложение может обходиться без политик бакетов и версионирования, выбирайте Garage.
Для огромного количества небольших объектов, смешанного доступа к файловой системе или рабочей нагрузки озера данных, которая может вырасти в таблицы Iceberg, рассмотрите SeaweedFS.
Когда тот же кластер должен также предоставлять блочные устройства и распределенную файловую систему, выбирайте Ceph RGW.
Когда требование конкретно — S3 API поверх обычных файлов — NAS, архив, репозиторий документов, краулер или цель резервного копирования — начните с VersityGW.
Когда задача — транслировать S3 на Azure, GCS, Swift, SFTP или другой S3-сервис, используйте S3Proxy.
Когда развертывание маленькое, временное и может терпеть экспериментальный сервер, rclone serve s3 может быть достаточно.
Рекомендуемая архитектура для одного сервера хранилища
Если приложения должны достигать данных только через S3, RustFS владеет слоем объектов, а файловая система является деталью реализации:
Если сами файлы должны пережить шлюз, храните данные в POSIX-дереве:
Во втором дизайне избыточность обеспечивается зеркалом ZFS, RAID, снимками (snapshots), репликацией файловой системы или традиционным инструментом резервного копирования. S3-сервис может быть заменен без переписывания формата данных.
Итоги
Поддерживаемое самодостаточное S3 по-прежнему существует после того, как публичный репозиторий MinIO стал доступным только для чтения. Выбор, который имеет значение — владеет ли S3 байтами или только прикрывает уже существующие файлы. Каждое сравнение выше следует из этого ответа.
