В 2026 году объектное хранилище всё чаще выбирают не «по бренду», а по профилю нагрузки: сколько пишете и читаете, как часто делаете LIST, нужен ли CDN рядом, критична ли стоимость egress и есть ли требования к неизменяемым бэкапам (immutable backups). Backblaze B2, Wasabi и Cloudflare R2 постоянно сравнивают из‑за заявленной S3 compatibility, но экономику и ограничения у каждого провайдера нужно считать по-разному.
Ниже — практичный разбор: как сравнивать pricing, где спрятаны API costs, на что влияет lifecycle, как устроены versioning и механики WORM (Object Lock), и какие сценарии в итоге «стреляют» по бюджету или по надёжности.
Что именно сравниваем в 2026: чек-лист администратора
Чтобы сравнение не превратилось в «цена за гигабайт в вакууме», держите один и тот же чек-лист:
- Хранение: цена за ГБ-месяц, минимальные объёмы, классы хранения (если есть).
- Egress: стоимость исходящего трафика и условия «бесплатности» (если заявлено), а также нюансы: трафик в CDN/клиент, межрегиональные передачи, выход в интернет.
- API costs: стоимость операций (PUT/GET/LIST/HEAD/DELETE), разница между «много мелких файлов» и «несколько крупных», влияние multipart.
- Семантика S3: насколько полно реализованы S3 API и «углы»: V4 signing, multipart, range requests, copy, presigned URL, SSE, CORS, object tagging.
- Lifecycle: правила переходов/удалений, работа с версиями и незавершёнными multipart, политики удержания.
- Versioning: цена «истории», как растёт потребление, как чистить старые версии.
- Immutable backups: Object Lock/WORM, legal hold/retention, ограничения на удаление, требования к времени, совместимость с вашим софтом.
- Экосистема: rclone, s3cmd/aws cli, SDK, поддержка популярных бэкап-решений (restic, Veeam и т.д.).
- Операционка: метрики/логи, аудит, IAM-политики, ключи доступа, пределы на запросы, особенности консистентности листингов.
Короткий портрет: где обычно сильные стороны
Backblaze B2
Backblaze B2 исторически любят за понятную стоимость хранения и то, что это «объектное хранилище как сервис без лишней надстройки». В 2026 его часто рассматривают как универсальное хранилище для бэкапов, архивов и медиа — особенно когда важна предсказуемость цены хранения и вы готовы внимательно посчитать egress и операции.
Практический нюанс: B2 встречается в двух режимах использования — «родной B2 API» и «S3-compatible API». Для администратора это означает простое правило: тестируйте именно тот endpoint/режим, который будет в проде, потому что поведение, лимиты и совместимость клиентов могут отличаться.
Wasabi
Wasabi обычно выбирают, когда нужен простой прайс «за хранение» и ожидается заметная доля чтений (выгрузок), но вы готовы жить с политиками минимального срока хранения или минимального биллинга по объёму (в зависимости от актуальных условий тарифа). В бэкап-сценариях это может быть выгодно, если данные стабильно лежат и не «пилятся» ежедневными агрессивными удалениями.
Практический нюанс: Wasabi часто воспринимают как «S3 почти как AWS». В большинстве сценариев так и есть, но экономику может резко поменять жизненный цикл данных: частые удаления и короткая ретенция иногда превращаются в скрытую доплату на уровне политики хранения.
Cloudflare R2
R2 продвигается как объектное хранилище рядом с edge-инфраструктурой. Ключевая идея, которая в 2026 продолжает привлекать: низкая стоимость «выдачи наружу» при использовании в связке с экосистемой Cloudflare и web-проектами. Для статики, публичных ассетов и «origin для CDN» это часто делает модель расходов заметно приятнее, чем классические хранилища, где egress — основной источник боли.
Практический нюанс: R2 — не просто «ещё один S3». Он сильнее всего там, где важны отдача контента и интеграция с edge, но для тяжёлых бэкап-процессов с большим количеством LIST-операций, версиями и строгими требованиями WORM стоит отдельно проверить: хватает ли вам S3-функциональности и нет ли ограничений, которые всплывут только в проде.
Egress в 2026: почему именно он чаще ломает бюджет
Egress — это исходящий трафик из объектного хранилища. В типовой инфраструктуре он появляется в четырёх ситуациях:
- пользователи скачивают файлы (публичные ассеты, дистрибутивы, медиа);
- приложение читает данные (например, генерация превью, аналитика, пайплайны обработки);
- вы делаете restore из бэкапа или регулярно прогоняете верификацию чтением;
- репликация и миграции между хранилищами или регионами.
Ключевой вывод: «дешёвое хранение» не спасает, если у вас активная раздача. При большой выдаче даже небольшая разница в цене egress быстро перекрывает экономию на ГБ-месяц.
Практика: сначала оцените объём чтений в месяц и долю публичной раздачи. Если egress больше, чем объём хранимых данных, вы выбираете не storage, а тариф на сеть.
Как прикинуть egress без сложной модели
Быстрая оценка «на салфетке» для сравнения провайдеров:
- Сколько ТБ вы храните постоянно (с учётом версий)?
- Сколько ТБ в месяц читаете или раздаёте?
- Сколько операций LIST/HEAD делаете (инвентаризация, сканеры, бэкап-индексация)?
- Какой процент чтений уходит в кэш CDN (может резко уменьшить egress с origin)?
Если у вас web-раздача, проверьте кэширование на уровне CDN/прокси, корректные заголовки Cache-Control/ETag и версионирование URL. Иначе вы будете платить за повторные скачивания, которые могли бы стать cache hit. По практике это одна из самых быстрых точек оптимизации.
По теме кэша и версионирования пригодится отдельный разбор: как правильно версионировать объекты в S3 и настроить кэш CDN.
API costs: когда «дёшево за гигабайт» внезапно становится дорого
Стоимость API-операций проявляется особенно сильно в трёх случаях:
- Много мелких объектов (лог-файлы по минутам, бэкапы чанками по 1–8 МБ, миниатюры).
- Интенсивный LIST (частые инвентаризации, синхронизации «как rsync», сканирование префиксов).
- Multipart и copy в больших объёмах (миграции, перекладка данных, compaction).
Типичная ошибка — перенос «файлового мышления» в object storage: пытаться обращаться к объектам как к файлам в каталоге и постоянно листать «папки». S3-совместимость это позволяет, но экономически (и по latency) часто выгоднее хранить индекс или манифест отдельно и делать LIST только по необходимости.
Практичный совет для бэкапов с дедупликацией
Если ваш бэкап-инструмент хранит чанки, индексы и манифесты (дедупликация на стороне клиента), у вас почти всегда высокий счётчик операций. Это не «плохо», просто это надо заложить в расчёт. Для таких сценариев оценивайте не только «price per GB», а стоимость операций на 1 ТБ залитых данных и на 1 ТБ проверок/переиндексаций.
Минимум, который стоит сделать перед выбором: включить расширенный лог/статистику в клиенте и собрать реальное число PUT/GET/LIST/HEAD за 7–14 дней, а затем экстраполировать на месяц.
Lifecycle: экономия, порядок и защита от разрастания версий
Lifecycle — главный инструмент, чтобы держать стоимость под контролем и не превращать бакет в свалку. На практике lifecycle используют для:
- удаления временных объектов (например, export’ы и артефакты CI) через N дней;
- чистки старых версий при включённом versioning;
- удаления «незавершённых multipart uploads», которые иначе могут висеть и копить мусор;
- разделения ретенций по префиксам:
daily/,weekly/,monthly/.
Тонкость: lifecycle может конфликтовать с требованиями immutable backups. Если вы включаете Object Lock с удержанием, lifecycle-удаление не должно ломать правила ретенции. Поэтому порядок обычно такой: сначала проектируете retention (что и сколько храните), потом настраиваете lifecycle для автоматизации.
Versioning: удобство против неизбежного роста объёма
Versioning — одна из самых недооценённых причин роста расходов. В object storage «перезаписать файл» часто означает «создать новую версию», а старая продолжит занимать место. Для бэкапов это может быть нормой (история нужна), а для ассетов сайта — неприятным сюрпризом, если деплой пушит одни и те же ключи снова и снова.
Практические рекомендации:
- Для ассетов используйте контентные хэши в именах (immutable URLs), а не перезапись ключа.
- Для бэкапов заранее определите политику: сколько версий нужно хранить, и автоматизируйте чистку.
- Заранее решите, как вы будете восстанавливаться: «по манифесту» или «по префиксу и датам».
Immutable backups (Object Lock/WORM): как не обмануть самих себя
Неизменяемые бэкапы в 2026 — уже не «фича для параноиков», а базовая гигиена против шифровальщиков и ошибочных удалений. Обычно речь про Object Lock (WORM), где объект нельзя удалить или перезаписать до окончания срока удержания.
Подводные камни, которые чаще всего ломают ожидания:
- Нельзя “слегка поправить”: любая ошибка в ретенции может дорого стоить — либо не защитили, либо «заморозили» мусор на месяцы.
- Нужно проектировать ключи: лучше писать бэкапы в уникальные ключи (по времени/снимку), а не перетирать один и тот же.
- Нужны отдельные учётки/ключи: минимальные права на запись, отдельные ключи на чтение/restore, раздельные политики.
- Проверяйте поддержку вашим софтом: не каждый клиент корректно работает с Object Lock и retention headers.
Immutable — это не «включил галочку и забыл». Это дисциплина: ключи, права, ретенция, тест восстановления и понимание, как удалять данные по окончании срока.
S3 compatibility: что обязательно проверить перед миграцией
Под «S3 compatibility» провайдеры часто понимают «основные операции работают». Но для продакшена важно прогнать чек-лист совместимости именно под ваш кейс:
- Signature V4, поддержка path-style и virtual-hosted-style (и что требует ваш клиент).
- Multipart upload: лимиты на размер части и их количество, поведение при abort, чистка незавершённых.
- Range requests (важно для стриминга, докачки, некоторых бэкап-инструментов).
- Server-side copy и копирование между бакетами/префиксами (используют миграции и compaction).
- Версии и delete markers при versioning.
- SSE (провайдерская) и клиентское шифрование: что поддерживается и как влияет на совместимость.
- Presigned URL и CORS (если это origin для фронта или загрузки из браузера).
И ещё: проверьте лимиты на частоту запросов и поведение при 429/503. Для бэкапов критично, чтобы клиент корректно делал retry с backoff и не «душил» API.
Минимальный тестовый план, который можно автоматизировать
Если хотите прогнать базовую проверку без самописных скриптов, начните с того, что ваш клиент умеет работать в S3-режиме (rclone, aws cli и т.п.), и проверьте операции: PUT, GET, LIST, multipart, versioning, удаление и восстановление из версий. Ниже — пример заготовки команд для rclone (переменные и remote подставьте свои):
rclone mkdir s3remote:fastfox-s3-test
rclone copy ./testdata s3remote:fastfox-s3-test/testdata
rclone lsjson s3remote:fastfox-s3-test --max-depth 2
rclone cat s3remote:fastfox-s3-test/testdata/1mb.bin > /tmp/restore-1mb.bin
rclone delete s3remote:fastfox-s3-test/testdata/1mb.bin
rclone purge s3remote:fastfox-s3-testВажно: если у вас включён Object Lock, команды удаления будут вести себя иначе — и это нормально. Но это нужно увидеть в тесте заранее, а не во время инцидента.
Сценарии выбора: кто выигрывает в типовых задачах
1) Бэкапы серверов и баз данных (редко читаем, много пишем)
Если вы в основном пишете бэкапы и читаете только при аварии, главный фактор — стоимость хранения плюс стоимость операций записи и удобство lifecycle/retention. Здесь часто хорошо себя показывает Backblaze B2, а Wasabi бывает выгоден при больших объёмах и понятной ретенции. Cloudflare R2 тоже возможен, но его сильная сторона обычно раскрывается не в «холодных» бэкапах, а в раздаче контента и интеграции с edge.
Что проверить: поддержка versioning и Object Lock, политика lifecycle для чистки старых версий и незавершённых multipart, стоимость LIST/HEAD для вашего инструмента бэкапа.
2) Публичные ассеты, статика, медиа (много чтений)
Когда чтений много, egress и кэширование решают всё. Cloudflare R2 часто сильный вариант, если архитектура завязана на экосистему Cloudflare и вы добиваетесь высокого cache hit. Иначе сравнение возвращается к классической модели: хранилище плюс CDN плюс egress из origin.
Что проверить: presigned URL, CORS, range requests, корректные кеш-заголовки, возможность быстро инвалидировать и версионировать.
Если раздаёте статику с домена, заранее убедитесь, что DNS-схема соответствует вашему CDN/edge (особенно на apex-домене). См. также: ALIAS/ANAME на корневом домене для CDN: что учесть.
3) Архив и ретенция на месяцы и годы
Для архива ключевое — предсказуемость хранения, требования комплаенса (immutability) и то, насколько прозрачно управлять lifecycle. Wasabi и Backblaze B2 обычно понятны для такого сценария, но важно не забыть про «цену выхода» (egress) на случай массового восстановления или миграции.
4) Гибрид: бэкапы плюс периодические проверки восстановления
Регулярная проверка restore (хотя бы выборочная) — правильная практика, но она превращает «холодный бэкап» в workload с чтениями. Здесь нужно считать egress и API costs на чтение, а также избегать бесконечных LIST при тестах. Иногда дешевле тестировать восстановление на ограниченном наборе snapshot’ов и держать отдельный манифест объектов.
Как считать total cost: простая модель без таблиц
Чтобы сравнить Backblaze B2, Wasabi и Cloudflare R2 честно, возьмите одну и ту же модель данных на месяц:
- Storage: средний объём хранимых данных (с учётом версий).
- Writes: сколько ГБ залили и сколько объектов создали (это разные величины).
- Reads: сколько ГБ прочитали или раздали.
- Ops: PUT/GET/LIST/HEAD/DELETE (хотя бы грубо, по логам клиента).
- Retention: сколько дней или недель храните, как часто удаляете, есть ли минимальные сроки.
Дальше подставляете прайс каждого провайдера. Если статистики нет — снимите её за 7–14 дней (по логам приложения или бэкап-агента) и экстраполируйте. Даже грубая оценка обычно спасает от выбора, который через месяц окажется в 3–10 раз дороже ожиданий.
Риски и типовые грабли при миграции между B2, Wasabi и R2
- Перенос с versioning: забудете про delete markers и старые версии — получите «мигрировали, а место не освободилось».
- Смена адресации бакета: некоторые клиенты требуют строго path-style или строго virtual-hosted-style.
- Непроверенный lifecycle: правила удаления могут внезапно начать чистить не то (особенно при совпадении префиксов).
- Object Lock без плана выхода: «заморозили» объекты, потом нельзя быстро удалить тестовые данные.
- Сюрпризы по API costs: инструмент делает много LIST/HEAD, а вы считали только ГБ-месяц.
Итог: как выбрать в 2026
Если обобщить практику:
- Backblaze B2 часто выигрывает как универсальный вариант для бэкапов и хранения с понятной моделью, когда вы готовы посчитать egress и операции и вам важна простота.
- Wasabi часто хорошо ложится на большие объёмы и сценарии, где данные лежат достаточно долго, вы не делаете агрессивные удаления и перезаписи, а egress-профиль предсказуем.
- Cloudflare R2 часто сильнее всего в сценариях раздачи и интеграции с edge/CDN, где экономия на egress и высокий cache hit дают максимальный эффект.
Самый надёжный подход — выбрать 1–2 кандидата и прогнать тест на реальном workload: заливка типичных объектов, включение versioning, пробный lifecycle, выборочный restore, замер количества операций и фактической скорости. В объектном хранилище в 2026 выигрывает не «самое дешёвое», а то, которое совпадает с вашим профилем чтения/записи и вашей дисциплиной ретенции.
Если храните бэкапы рядом с приложениями, не забывайте и про базовую инфраструктуру: иногда проще вынести бэкап-агенты и задачи в отдельную машину на VDS, чтобы не забирать ресурсы у продакшена и держать ключи доступа изолированно.
