Альтернативы MinIO в 2026 году: собственный S3 после архивации репозитория

Сервер MinIO с открытым исходным кодом больше не поддерживается: репозиторий minio/minio на GitHub был архивирован 25 апреля 2026 г. и теперь доступен только для чтения. Реальные варианты замены — Silo, форк того же кода от сообщества (AGPL-3.0); SeaweedFS и RustFS (Apache-2.0, с erasure coding); Garage (AGPL-3.0, копии распределяются по площадкам); и Ceph RGW для кластеров из нескольких серверов.

Коротко

Коротко: Silo — для минимальных изменений при уходе с MinIO; SeaweedFS или RustFS — для erasure coding на одном сервере под пермиссивной лицензией; Garage — для небольших серверов в нескольких городах, без версионирования; Ceph — для множества серверов и команды, которая будет их обслуживать.

Поддерживается ли ещё MinIO?

Как проект с открытым исходным кодом — нет. MinIO, Inc. теперь продаёт AIStor, а история README репозитория и примечания к выпускам показывают, как сервер под AGPL поэтапно сворачивали:

• 24 мая 2025 г. Выпуск, помеченный как «Breaking Release» (с несовместимыми изменениями), объявил устаревшей встроенную веб-консоль и удалил вход через LDAP и OIDC, которые, по словам MinIO, «теперь доступны в составе продукта AiStor». В июне издание Blocks & Files сообщило, что консоль community-версии лишилась функций администрирования и в ней остался лишь простой обозреватель объектов.
• 15 октября 2025 г. Распространение только в исходном коде: «Мы больше не будем предоставлять предварительно скомпилированные бинарные выпуски для community-версии». Последний выпуск community-версии, опубликованный 16 октября, исправил уязвимость повышения привилегий.
• 3 декабря 2025 г. «Режим сопровождения» (Maintenance Mode): никаких новых функций и пул-реквестов, а критические исправления безопасности «рассматриваются в индивидуальном порядке».
• 23 декабря 2025 г. MinIO объявила о трёх тарифах AIStor: Free (один узел), Enterprise Lite (несколько узлов, менее 400 ТиБ) и Enterprise.
• 12 февраля 2026 г. Уведомление сменилось на «ЭТОТ РЕПОЗИТОРИЙ БОЛЬШЕ НЕ ПОДДЕРЖИВАЕТСЯ» со ссылками на AIStor Free и AIStor Enterprise.
• 25 апреля 2026 г. GitHub отображает репозиторий как «архивированный владельцем 25 апреля 2026 г. Теперь он доступен только для чтения».

Существующие инсталляции продолжают работать, а код остаётся доступным под AGPL, но с октября 2025 г. не вышло ни одного выпуска community-версии, а архивированный репозиторий не получает исправлений. Всё, что доступно из интернета, следует перевести на поддерживаемую сборку или на другой сервер.

Для одной машины собственный ответ MinIO — AIStor Free: «полнофункциональная архитектура развёртывания на одном узле» с erasure coding, без искусственных ограничений ёмкости и только с поддержкой от сообщества. Он бесплатен, но это не код под AGPL: его лицензия «ограничивает любое распространение или перепродажу ПО AIStor», а для работы на нескольких узлах нужен платный тариф.

Silo: форк MinIO от сообщества

Pigsty, который использует MinIO в качестве репозитория резервных копий PostgreSQL, 25 октября 2025 г. сделал форк сервера под именем pgsty/minio, а 6 августа 2026 г. переименовал его в pgsty/silo. Pigsty называет Silo «независимым форком, поддерживаемым сообществом», не связанным с MinIO, Inc. Silo поставляет то, что перестал поставлять апстрим: бинарные файлы для Linux, macOS и Windows, мультиархитектурные контейнеры, пакеты RPM, DEB и APK, исправления безопасности с опубликованными бюллетенями и полную веб-консоль. Он сохраняет S3 API и формат хранения, включая переменные MINIO_* и данные .minio.sys, а его руководство по миграции описывает перевод на Silo существующей установки minio.service.

Различия перечислены в аудите совместимости Silo. Исполняемый файл теперь называется silo; двенадцать действий на уровне бакета, в том числе запись политик, версионирования, Object Lock и жизненного цикла, больше не сопоставляются с ресурсом, указывающим только на объекты, например bucket/*; токены OIDC, подписанные общими секретами, отклоняются; самообновление на месте отключено. Silo меньше года, и его развивает одна организация: фиксируйте версии и сохраняйте возможность отката.

Garage, SeaweedFS, RustFS и Ceph RGW: сравнение

Garage

Garage — это «лёгкое геораспределённое хранилище данных, реализующее протокол объектного хранилища Amazon S3». Он хранит полные копии; erasure coding прямо отнесён к целям, которые проект перед собой не ставит. Значение replication_factor не может превышать число узлов: при 1 «избыточности нет», и документация оставляет этот вариант для тестов; при 3 каждый объект хранится на трёх узлах, по возможности в разных зонах, и сохраняется при потере двух из них.

Цена такой простоты — покрытие S3: нет версионирования, нет Object Lock, нет политик бакетов и ACL — вместо них Garage использует права, назначаемые каждому ключу на каждый бакет. Правила жизненного цикла поддерживают только истечение срока хранения и незавершённые составные (multipart) загрузки. Если ваш инструмент резервного копирования зависит от версионирования или неизменяемости данных, ищите другое решение.

SeaweedFS

SeaweedFS состоит из master-сервера, серверов томов, filer и S3-шлюза. Репликация задаётся для каждого тома трёхзначным кодом, определяющим число дополнительных копий в других дата-центрах, стойках и на других серверах; 000 означает единственную копию. Erasure coding использует 10 шардов данных и 4 шарда чётности: данные занимают в 1,4 раза больше места и сохраняются при потере любых 4 шардов, а произвольные соотношения доступны только в версии Enterprise. Erasure coding применяется к «тёплым» данным: записи попадают в обычные тома, а фоновый обработчик, включённый по умолчанию, кодирует том, когда он заполнен на 80% и в течение пяти минут в него ничего не записывалось. При менее чем четырёх серверах erasure coding защищает от отказа дисков, при четырёх и более — от отказа серверов.

S3-шлюз поддерживает версионирование, Object Lock, политики бакетов, удаление по истечении срока в правилах жизненного цикла (без переходов между классами хранения), SSE-S3, SSE-KMS, SSE-C, IAM и STS, но не поддерживает репликацию бакетов, а также настройку веб-сайта и уведомлений. SeaweedFS открыто разрабатывается с 2014 г.

RustFS

RustFS ближе всех к MinIO по архитектуре: это сервер на Rust, который объединяет диски в наборы erasure coding (erasure sets) и пулы по правилам топологии MinIO, с веб-консолью и под лицензией Apache-2.0 вместо AGPL. В его таблице функций доступными значатся версионирование, Object Lock, шифрование на стороне сервера, управление жизненным циклом, репликация бакетов и площадок, IAM и OIDC. Документация описывает три режима: один узел с одним диском («полагайтесь на резервные копии»), один узел с несколькими дисками (выдерживает отказ до M дисков чётности) и четыре узла и более для рабочих нагрузок в продакшене.

При любом сравнении RustFS и MinIO главный вопрос — зрелость. Версия RustFS 1.0.0 вышла 16 сентября 2026 г., после бета-версий и релиз-кандидатов, а 1.0.1 — 3 октября. Чтение дискового формата MinIO пока остаётся предварительной функцией, доступной только с флагом сборки, который по умолчанию отключён, а объекты, зашифрованные MinIO, прочитать нельзя, поэтому уход с MinIO означает копирование через S3 API. Протестируйте такой молодой выпуск на собственной нагрузке, прежде чем доверить ему единственную копию каких-либо данных.

Ceph RGW

Ceph Object Gateway (RGW) добавляет S3 API к кластеру Ceph, который также может предоставлять блочное и файловое хранилище; код распространяется под лицензией LGPL-2.1 или LGPL-3. Объекты хранятся в реплицируемых пулах или пулах с erasure coding, где доменом отказа по умолчанию служит хост. Профиль erasure code по умолчанию — 2+2, и большинству пулов с erasure coding нужно не меньше k+m хостов или стоек. Флаг --single-host-defaults в cephadm создаёт кластер на одной машине с двумя репликами на разных дисках, но документация называет такие кластеры «как правило, непригодными для продакшена». Поддержка S3 в RGW обширна, включая Object Lock, хотя репликация бакетов работает только между зонами.

Сравнение функций S3

Репликация, erasure coding или RAID на одном сервере

Все три подхода расходуют сырую ёмкость на избыточность, но в разных пропорциях:

• Репликация хранит полные копии: 2 ТБ сырой ёмкости на каждый полезный терабайт при двух копиях и 3 ТБ — при трёх.
• Erasure coding (избыточное кодирование) разбивает каждый объект на k шардов данных и m шардов чётности и выдерживает потерю любых m из них: (k+m)/k сырой ёмкости на полезный терабайт, то есть 1,5 для 8+4 и 1,4 для 10+4.
• RAID 6 или ZFS RAIDZ2 хранит по два блока чётности на группу дисков и выдерживает отказ двух дисков в каждой группе: n/(n−2) для группы из n дисков, то есть 1,5 для шести дисков и 1,2 для двенадцати.

На одной машине копии и шарды должны попадать на разные диски. Silo, AIStor Free и RustFS с первой же записи распределяют каждый объект по набору дисков (erasure set): набор из 12 дисков с 4 шардами чётности ничего не теряет при отказе любых 4 дисков. SeaweedFS применяет erasure coding к заполненным томам, но недавние записи ждут в обычных томах и защищены только своей настройкой репликации. Garage считает копии по узлам, поэтому Garage на одном узле хранит единственную копию: разместите его данные на RAIDZ2 или RAID 6 либо добавьте узлы. Для Ceph нужны описанные выше настройки для одного хоста. Ни одно из этих решений не переживёт потерю самого сервера.

Полезная ёмкость на серверах с 88, 264 и 528 ТБ

В наших трёх серверах хранения используются жёсткие диски по 22 ТБ — четыре, двенадцать или двадцать четыре, — а также по два NVMe-накопителя для системы и метаданных:

Десятичные терабайты, без учёта накладных расходов файловой системы; Linux показывает диск на 22 ТБ как примерно 20 ТиБ. Примечание: на четырёх дисках 14 шардов SeaweedFS распределяются по три-четыре на каждый диск, поэтому отказ второго диска приводит к потере данных.

Стоимость полезного терабайта — это месячная цена, делённая на полезную ёмкость. На сервере на 264 ТБ за $469 в месяц полезный терабайт при трёх копиях (88 ТБ) стоит в 2,5 раза дороже, чем при RAIDZ2 из 12 дисков (220 ТБ), а erasure coding 8+4 делает его на 25% дешевле, чем при двух копиях. Количество дисков важно не меньше, чем сырой объём: при устойчивости к отказу двух дисков у четырёх дисков полезной остаётся половина ёмкости, у двенадцати и более — две трети и больше. Важно и время перестроения: заполнение диска на 22 ТБ при условной скорости 200 МБ/с занимает около 30 часов, поэтому мы не стали бы использовать диски такого объёма в схемах, выдерживающих отказ менее чем двух дисков.

Собственное хранилище против S3, R2 и B2

Публичные цены по прайс-листу на октябрь 2026 г., без налогов:

Возьмём 176 ТБ хранимых данных — это полезная ёмкость сервера на 264 ТБ с erasure coding 8+4 — и 50 ТБ исходящего трафика в месяц, из расчёта 1 ТБ = 1 000 ГБ:

• AWS S3: около $3 920 за хранение и $4 300 за передачу данных, то есть около $8 200 в месяц без учёта запросов.
• Cloudflare R2: около $2 640 в месяц плюс операции, без платы за исходящий трафик.
• Backblaze B2: около $1 220 в месяц; 50 ТБ исходящего трафика укладываются в бесплатный лимит.
• Один сервер на 264 ТБ: $469 в месяц при любом трафике.

Это сравнение не вполне равноценное: по словам AWS, S3 «по умолчанию хранит данные с избыточностью как минимум в 3 зонах доступности», тогда как один сервер — это одна машина в одном здании. Для данных, которые нельзя потерять, сравнивайте с двумя серверами в двух городах: по этим расчётам это всё равно дешевле B2. Если у вас всего несколько терабайт и мало трафика, B2 или R2 обойдутся дешевле любого выделенного сервера хранения. Наше руководство по тарификации канала показывает, как плата за исходящий трафик растёт вместе с объёмом.

Миграция с MinIO через rclone

Если вы остаётесь на формате MinIO, Silo может подхватить существующие данные на месте — по его руководству по миграции. Для любого другого сервера копируйте объекты через S3 API с помощью rclone.

1. Учтите, что не будет скопировано. Пользователей, ключи доступа, политики бакетов, правила жизненного цикла и настройки репликации нужно заново создать на новом сервере. В бакетах с версионированием rclone копирует текущую версию каждого объекта; старые версии появляются — в виде переименованных файлов — только с --s3-versions. Сроки хранения Object Lock можно перенести с помощью --metadata со значением copy, если приёмник это поддерживает.

2. Опишите оба эндпоинта в ~/.config/rclone/rclone.conf. Источник настраивается по примеру для MinIO из документации rclone; приёмник здесь — Garage, который принимает provider = Other, запросы в стиле path-style и собственное имя региона. Для SeaweedFS используйте provider = SeaweedFS, а для Ceph — provider = Ceph с пустым регионом.

[old]
type = s3
provider = Minio
env_auth = false
access_key_id = OLD_ACCESS_KEY
secret_access_key = OLD_SECRET_KEY
region = us-east-1
endpoint = http://minio.example.net:9000

[new]
type = s3
provider = Other
env_auth = false
access_key_id = NEW_ACCESS_KEY
secret_access_key = NEW_SECRET_KEY
region = garage
endpoint = http://storage.example.net:3900
force_path_style = true

3. Сделайте пробный прогон, скопируйте и проверьте — по одному бакету за раз. Если S3 с обеих сторон, документация rclone рекомендует --checksum.

# buckets on each side
rclone lsd old:
rclone lsd new:

# preview, then copy one bucket
rclone sync old:backups new:backups --checksum --fast-list --transfers 32 --checkers 64 -P --dry-run
rclone sync old:backups new:backups --checksum --fast-list --transfers 32 --checkers 64 -P

# compare sizes and hashes on both sides
rclone check old:backups new:backups

4. Настройте и переключитесь. Значения rclone по умолчанию консервативны, поэтому увеличьте --transfers и --checkers и поэкспериментируйте; --fast-list расходует около 1 ГиБ ОЗУ на миллион объектов. Повторяйте синхронизацию, пока расхождений почти не останется, затем остановите запись, запустите синхронизацию ещё раз и переключите эндпоинт. sync удаляет в приёмнике объекты, которых нет в источнике, поэтому дважды проверьте имена бакетов.

5. Заложите время. При переносе между двумя разными серверами каждый объект скачивается и заново загружается машиной, на которой работает rclone. При эффективной скорости 1 Гбит/с перенос 100 ТБ занимает около девяти дней, при 5 Гбит/с — меньше двух. Темп обычно задают диски или аплинк старого сервера, а не порт 10 Гбит/с на стороне приёмника.

Чего не может один сервер хранения

• Один сервер — один домен отказа. Erasure coding и RAID защищают от отказа дисков, но не от выхода из строя материнской платы, блока питания или всего здания и не от ошибки администратора. Документация RustFS прямо говорит об одноузловых конфигурациях: «если выйдет из строя весь сервер или будет повреждено более M дисков, данные будут потеряны».
• Избыточность — не резервная копия. Удалённый бакет исчезает сразу со всех дисков. Версионирование и Object Lock помогают, но исправимыми ошибки делает именно независимая копия в другом месте.
• Критически важным данным нужна вторая площадка. Это может быть второй сервер хранения в другом городе — например, Амстердам и Франкфурт, — который наполняется по расписанию командой rclone copy, никогда ничего не удаляющей, или репликацией бакетов. Или кластер Garage из трёх серверов на 88 ТБ в Амстердаме, Франкфурте и Цюрихе с replication_factor = 3: по одной копии в каждом городе и около 88 ТБ полезной ёмкости.

Какой сервер выбрать для собственного S3-хранилища

Сервер хранения на 88 ТБ стоит $149 в месяц и выдаётся примерно за 15 минут в Амстердаме, Франкфурте, Цюрихе и Нью-Йорке. Он подходит для узла Garage или в качестве хранилища резервных копий: 44 ТБ полезной ёмкости при устойчивости к отказу двух дисков. Сервер на 264 ТБ за $469 в месяц, который собирается в течение 24 часов в Амстердаме, Франкфурте и Нью-Йорке, имеет достаточно дисков для erasure coding 8+4 или RAIDZ2 из 12 дисков на одной машине. Сервер на 528 ТБ за $999 в месяц, который собирается в течение 72 часов в Амстердаме и Франкфурте, добавляет 24-ядерный EPYC и 256 ГБ памяти ECC для более крупных наборов erasure coding.

У всех трёх — память ECC, два NVMe-накопителя, доступ к IPMI и порт 10 Гбит/с без учёта трафика, поэтому восстановление 100 ТБ стоит столько же, сколько месяц простоя. Схемы на ZFS и mdadm описаны в нашем руководстве по программному RAID, а варианты резервного копирования — на странице серверов для хранения и резервного копирования. Мы не лучший выбор, если у вас всего несколько терабайт — тогда B2 или R2 обойдутся дешевле, — или если нужна надёжность хранения в нескольких дата-центрах без необходимости что-либо администрировать самостоятельно: это задача управляемого объектного хранилища.

Источники

• minio/minio, история README и Releases · minio/minio — MinIO на GitHub
• Представляем новые уровни подписки MinIO AIStor: Free, Enterprise Lite и Enterprise — MinIO, 23 декабря 2025 г.
• Пользователи MinIO недовольны удалением интерфейса администрирования из Community Edition — Blocks & Files, 19 июня 2025 г.
• pgsty/silo и Совместимость Silo и MinIO Server — PGSTY
• Формат файла конфигурации, Статус совместимости с S3 и Цели и сценарии использования — документация Garage; Deuxfleurs/garage — Forge Deuxfleurs
• Erasure coding для «тёплого» хранения, Репликация и Amazon S3 API — вики SeaweedFS; seaweedfs/seaweedfs — GitHub
• rustfs/rustfs — GitHub; Установка — документация RustFS
• Erasure code, Развёртывание нового кластера Ceph с помощью Cephadm, S3 API шлюза Ceph Object Gateway, Операции с бакетами и Выпуски Ceph (указатель) — документация Ceph; COPYING — ceph/ceph на GitHub
• Amazon S3 и rclone sync — документация rclone
• Прайс-лист AWS: Amazon S3, US East (N. Virginia), опубликован 14 октября 2026 г.; Прайс-лист AWS: передача данных, US East (N. Virginia), опубликован 16 сентября 2026 г.; Классы хранения объектов — Amazon Web Services
• Цены — документация Cloudflare R2, последнее обновление 1 октября 2026 г.
• Цены на B2 Cloud Storage — Backblaze, проверено в октябре 2026 г.