Выбор object storage в 2026 редко сводится к «цена за гигабайт в месяц». На бумаге цифры выглядят красиво, но в реальности итоговую стоимость быстро меняют egress (исходящий трафик), retrieval fees (платное восстановление), minimum storage duration (минимальный срок хранения), а также ограничения retention policy и то, как настроены lifecycle rules.
Ниже — сравнение S3 Glacier (архивные классы AWS), Backblaze B2 и Wasabi с позиции админа/DevOps: бэкапы, логи, медиа, «холодные» архивы, редкие восстановления и сценарии «а если придётся выгружать всё».
Что сравниваем: разные философии хранения
S3 Glacier — не один продукт, а набор архивных классов внутри Amazon S3. Чаще всего под «Glacier» имеют в виду Glacier Flexible Retrieval и Glacier Deep Archive. Они дают низкую цену хранения, но «компенсируют» её платным восстановлением, задержками и минимальными сроками хранения.
Backblaze B2 — S3-совместимый object storage с прямолинейной моделью: хранение + запросы + egress. Отдельного «архивного класса» (как у Glacier) нет, поэтому B2 часто выбирают как компромисс: проще считать и проще восстанавливать.
Wasabi — S3-совместимый object storage, который обычно выбирают из‑за простой модели без классических retrieval fees. Но ключевая оговорка — minimum storage duration (часто 90 дней) и особенности биллинга при удалении/перезаписи раньше срока.
Термины, из‑за которых чаще всего ошибаются в расчётах
Egress (исходящий трафик)
Egress — плата за скачивание данных «наружу» из облака (на ваш сервер, в другой регион/провайдер, на локальную инфраструктуру). Для бэкапов это критично: хранить можно дёшево, но один массовый restore может стоить как несколько месяцев хранения.
Retrieval fees (плата за восстановление)
Retrieval fees характерны прежде всего для архивных классов AWS. Там «восстановление» — отдельная операция: вы платите за «поднятие» объекта из архива и часто ещё за выбранный режим (скорость) восстановления. Модель может включать и дополнительные ограничения по объёму поднятых данных.
Minimum storage duration (минимальный срок хранения)
Minimum storage duration означает: если вы удалили или перезаписали объект раньше заданного срока, вы всё равно оплатите его так, как будто он пролежал весь срок. Это особенно неприятно для бэкапов с частой ротацией, инкрементами и «перепаковкой» цепочек.
Retention policy и lifecycle rules
Retention policy — политика неизменяемости/удержания (часто на базе Object Lock / WORM): запрет удалить или перезаписать объект до определённой даты. А lifecycle rules — автоматизация жизненного цикла: перенос между классами, удаление старых версий, очистка незавершённых multipart и т. п.
Retention и lifecycle легко конфликтуют. Например, lifecycle удаляет через 30 дней, но retention удерживает 180 дней — и вы получаете «почему растёт объём и счета».
Если хотите глубже разобраться, как не наступать на такие конфликты, пригодится разбор про настройку lifecycle и retention в S3 для бэкапов.
Сравнение по сценариям, а не по рекламным цифрам
1) «Храним много, восстанавливаем редко» (архив, комплаенс, закрытые проекты)
Это «родная» территория S3 Glacier Deep Archive: дешёвое хранение при условии, что вы готовы к долгому восстановлению и к модели, где восстановление почти всегда платное и не мгновенное.
Backblaze B2 здесь выигрывает простотой: нет стадии «сначала restore, потом download» как у Glacier. Но итоговая стоимость зависит от того, как часто вы всё-таки делаете выборочные скачивания и сколько egress уходит наружу.
Wasabi подходит, если архив действительно «лежит» (редкие изменения). Но если вы регулярно перезаписываете большие объёмы (например, еженедельные full), minimum storage duration превращает «дешево» в «непредсказуемо».
2) «Классические бэкапы 3-2-1: инкременты каждый день, удаление по GFS»
Самый частый провал — игнорирование minimum storage duration. Если у вас retention 7–30 дней и постоянная ротация, Wasabi может оказаться дороже ожидаемого просто потому, что значимая доля данных удаляется «моложе 90 дней».
Для таких бэкапов чаще выбирают:
- Backblaze B2 — предсказуемо при частом churn (много новых объектов и удалений).
- AWS S3 + lifecycle — сначала более доступный класс, потом перевод в Glacier. Но нужно внимательно считать запросы, стоимость переходов и восстановлений.
S3 Glacier напрямую как целевой класс для «горячей» ротации бэкапов — рискованная идея: вы либо упрётесь в minimum storage duration архивного класса, либо в платные и медленные восстановления, либо и в то и в другое.
3) «Disaster Recovery: надо уметь восстановить всё быстро»
Если RTO важен, «чистый Glacier» обычно проигрывает: время восстановления и стоимость retrieval в момент аварии могут стать неприятным сюрпризом. На практике используют многоуровневую схему:
- последние N дней — в более доступном классе/хранилище;
- дальше — перенос в архив по lifecycle rules.
Для DR также критичен egress: при массовом восстановлении счёт за исходящий трафик может быть сопоставим со стоимостью инфраструктуры за месяцы. Если проектируете DR, заложите «катастрофический egress» в бюджет и заранее прогоните тест восстановления.
AWS S3 Glacier: когда он лучший и когда опасен
Сильные стороны
- очень низкая стоимость хранения в Deep Archive;
- богатая экосистема: IAM, аудит, политики доступа, зрелые lifecycle rules;
- удобно для комплаенса, когда нужны строгие политики и неизменяемость.
Типичные подводные камни
- retrieval fees и зависимость цены от режима восстановления;
- задержки восстановления: это не «скачал сразу»;
- minimum storage duration у архивных классов: раннее удаление/замена может стоить денег;
- неочевидные расходы на запросы и операции при большом количестве объектов (листинг, HEAD/GET, инвентарь и т. п.).
Для Glacier считайте стоимость не «за гигабайт», а по сценарию восстановления: сколько данных реально будете поднимать из архива и как быстро это нужно в худший день.
Backblaze B2: простота и предсказуемость, но следите за egress
Где B2 удобен
- регулярные бэкапы с частой ротацией (много удалений и новых объектов);
- проектам, которым нужна S3-совместимость без «архивной математики» Glacier;
- когда важно быстро и просто скачать объект без стадии «restore».
Что проверить заранее
- стоимость egress в вашем профиле (пиковые восстановления, миграции, тестовые выгрузки);
- стоимость операций (классы запросов) при большом количестве мелких объектов;
- ограничения по регионам/локациям, если вам важны юрисдикция или задержка.
Wasabi: «без retrieval fees», но minimum storage duration меняет правила игры
Где Wasabi обычно «заходит»
- большие объёмы данных, которые редко меняются (медиа-архив, репозитории артефактов с редкой зачисткой);
- сценарии, где вы читаете выборочно, но не делаете массовых удалений до истечения минимального срока;
- когда хочется простой модели без отдельной платы за восстановление.
Где начинаются сюрпризы
- цепочки бэкапов с частой ротацией и удалением «моложе 90 дней»;
- перепаковка/консолидация, когда backup-софт переукладывает объекты;
- активное версионирование и частые перезаписи крупных объектов.
Wasabi часто выигрывает, когда данные «лежат» и почти не churn’ятся. Чем больше удалений и перезаписей, тем внимательнее смотрите на minimum storage duration.
Как правильно сравнивать: чек-лист расчёта TCO
Чтобы сравнение было честным, берите свои реальные числа. Минимальный набор:
- Объём данных и рост в месяц.
- Профиль изменений: сколько GB/день добавляется, сколько удаляется, как часто перезаписываются объекты.
- Профиль чтения: выборочные чтения или редкие массовые восстановления.
- План аварийного восстановления: сколько TB нужно скачать за 24–72 часа в худшем случае.
- Lifecycle: через сколько дней переводите в «холодный» слой, когда удаляете, включено ли versioning.
- Retention policy: нужна ли неизменяемость, на какой срок, какие исключения для админов.
- Число объектов и средний размер объекта (миллионы мелких объектов могут быть дороже на операциях, чем «несколько больших»).
Практические шаблоны архитектуры (без привязки к одному бренду)
Шаблон A: «горячее + архив» через lifecycle rules
Храните последние 7–30 дней бэкапов в более доступном слое (быстрое чтение, приемлемый egress), а затем переводите в архивный класс (например, Glacier) по lifecycle rules. Так вы уменьшаете вероятность дорогого retrieval, потому что чаще всего восстанавливают «свежие» данные.
Шаблон B: раздельные бакеты под разные политики
Смешивание «архива на годы» и «ротации на 14 дней» в одном бакете — источник ошибок. Практичнее разнести:
- бакет для короткой ротации (без WORM и без длительного minimum storage duration);
- бакет для долгого хранения (с retention policy и/или переводом в архивный класс).
Так вы снижаете риск конфликта lifecycle rules и retention policy и точнее считаете стоимость.
Шаблон C: тест восстановления как часть регламента
Самая дорогая ошибка — «мы думали, что восстановление будет быстрым и бесплатным». Введите правило: раз в месяц (или квартал) делать тестовый restore фиксированного набора данных и фиксировать результаты.
Если бэкапы у вас гоняются через S3-совместимые хранилища (B2/Wasabi/S3) с rclone, полезно держать под рукой практику по проверке целостности и сверке: синхронизация и проверка S3 в rclone.
Мини-плейбук: как не «влететь» на egress и восстановлении
1) Держите «оперативный» слой рядом с вычислениями
Если восстановление будет происходить на ваших серверах, заранее продумайте, где живёт «точка восстановления». Иногда дешевле и быстрее поднимать данные на сервере в облаке и уже оттуда раздавать их в вашу инфраструктуру — для таких задач часто берут облачный VDS под временный restore-хост и тесты восстановления.
2) Разделяйте политики на уровне бакетов и префиксов
Не смешивайте в одном бакете объекты с разными SLA и сроками хранения. Ротация «7–30 дней» и архив «1–7 лет» — это разные бюджеты, разные lifecycle и разные требования к неизменяемости.
3) Документируйте «худший день»
Для любого хранилища запишите в регламенте: сколько TB вы скачаете при DR, за какое время, каким инструментом и с каким параллелизмом. И отдельно — сколько это будет стоить по вашей тарифной модели. Если нет цифр — у вас нет бюджета, есть надежда.
Итог: кому что выбирать в 2026
S3 Glacier разумен, если вы осознанно строите архив с редкими восстановлением, готовы к задержкам и умеете считать retrieval fees и minimum storage duration. Он силён там, где важны политики, комплаенс и «всё по-взрослому».
Backblaze B2 удобен, когда нужна простота и предсказуемость в повседневных бэкапах, а восстановление должно быть прямым (без стадии «разморозки»). Но egress всё равно держите в уме — особенно для DR и миграций.
Wasabi часто выигрывает на больших объёмах при стабильных данных и понятном жизненном цикле, но minimum storage duration требует дисциплины: если у вас активная ротация и перезаписи, закладывайте это в расчёт и разделяйте данные по бакетам/политикам.
Если хотите «универсальный» подход без угадываний — начните с описания своих lifecycle rules и retention policy на бумаге, затем прогоните расчёт по худшему сценарию восстановления (DR), и только потом сравнивайте провайдеров. В object storage именно «плохой день» обычно самый дорогой.
