Корпоративные данные можно представить как айсберг. На поверхности — «боевые» базы данных, биллинг, высоконагруженные сервисы. В их инфраструктуру бизнес обычно инвестирует в первую очередь. Но под водой находится не менее важный и постоянно растущий массив вторичных данных: резервные копии, архивы за несколько лет и реплики для аварийного восстановления.
Именно этот слой часто становится источником лишних расходов. По мере роста объемов данных ИТ-директорам приходится выбирать между двумя неудобными сценариями: либо тратить значительный бюджет на дорогое хранение архивов, либо экономить и мириться с более долгим восстановлением в случае сбоя.
Разберем, как менялся рынок систем хранения, почему классические аппаратные решения уступают место программно-определяемым системам (SDS) и как выстроить архитектуру, в которой стоимость хранения не конфликтует со скоростью восстановления.
S3 или блочные диски?
На практике выбор между S3 и блочными дисками сводится к балансу между стоимостью хранения и скоростью восстановления.
Объектное хранилище S3 подходит для недорогого долгосрочного размещения резервных копий. В нем удобно хранить большие объемы неструктурированных данных: медиаархивы, логи, старые документы, архивные бэкапы. Главный плюс такого подхода — низкая стоимость хранения.
Но у объектного хранилища есть и ограничение: восстановление данных из него обычно занимает больше времени. Для архивов это допустимо, а вот в аварийном сценарии может напрямую влиять на RTO — допустимое время простоя сервиса.
Блочные диски решают другую задачу. Они дороже, но незаменимы там, где важно быстро вернуть систему в рабочее состояние. Такой тип хранения подходит для критичных виртуальных машин, системных разделов и транзакционных баз данных, например PostgreSQL или 1С. За счет низких задержек и предсказуемой производительности блочное хранилище позволяет заметно сократить время восстановления.
Именно поэтому универсального варианта здесь нет: S3 выигрывает по цене, блочные диски — по скорости доступа и восстановления.
Сколько стоит хранение бэкапов
Разница в стоимости между уровнями хранения становится особенно заметной уже на объеме в 1 ТБ.
Объектное хранилище для резервных копий обычно обходится в среднем в 1 500–2 500 рублей в месяц за 1 ТБ, а в холодных классах хранения — иногда и дешевле 1 000 рублей.
Высокопроизводительное блочное хранилище для быстрого восстановления сервисов стоит существенно дороже — порядка 10 000–16 000 рублей в месяц за 1 ТБ.
Разница может превышать десятикратную. А если речь идет о десятках или сотнях терабайт, плюс о глубине хранения в несколько лет, переплата становится уже не операционной мелочью, а заметной статьей ИТ-бюджета.
Почему классические СХД перестают быть оптимальным выбором
Долгое время корпоративные хранилища строились на специализированных аппаратных системах высокого класса. Это надежные решения, но обычно дорогие, сложные в масштабировании и тесно привязанные к конкретному вендору.
Если в такой системе заканчивается место, компании часто приходится докупать оборудование того же производителя. Перенос больших массивов резервных копий на другую платформу превращается в отдельный проект: дорогой, долгий и рискованный.
Именно поэтому рынок постепенно смещается в сторону программно-определяемых хранилищ — Software-Defined Storage, или SDS.
Что меняет SDS
Долгое время корпоративные хранилища строились вокруг специализированных аппаратных платформ. Это надежный подход, но у него есть известные ограничения: высокая стоимость, зависимость от конкретного вендора и сложность масштабирования. Когда емкость заканчивается, компании приходится расширяться в рамках той же экосистемы. Переезд на другую платформу превращается в отдельный инфраструктурный проект с дополнительными затратами и рисками.
Поэтому рынок постепенно смещается в сторону программно-определяемых систем хранения — SDS, или Software-Defined Storage. В этой модели логика управления выносится в программный слой, а инфраструктура собирается на базе стандартных серверов.
Проще говоря, «интеллект» хранилища оказывается в софте: он управляет размещением данных, политиками отказоустойчивости, маршрутизацией и масштабированием. Это дает бизнесу больше гибкости. Инфраструктуру можно расширять постепенно, добавляя новые узлы по мере роста нагрузки, а не заменяя всю систему целиком.
SDS не отменяет базовую экономику хранения: держать большие массивы «холодных» данных на дисках все равно дороже, чем в объектном хранилище. Но сам подход заметно снижает стоимость входа, упрощает масштабирование и уменьшает зависимость от одного поставщика.
Гибридная модель: быстрое восстановление без переплаты за архив
Когда архитектурой управляет программный слой, появляется возможность комбинировать разные типы хранения в рамках одной схемы.
С практической точки зрения это выглядит так: «горячие» точки восстановления размещаются на блочном хранилище, а основной архив — в объектном. Такой подход позволяет не выбирать между скоростью и ценой, а использовать сильные стороны обоих типов хранения.
Именно на этой логике строятся гибридные решения с двухуровневым размещением данных. В такой модели каждый новый бэкап сохраняется сразу в двух контурах:
- базовая копия отправляется в объектное хранилище S3 для долгосрочного и экономичного хранения;
- дополнительная копия или снапшот размещается в блочном хранилище как «горячий» резерв для быстрого восстановления.
Дальше вступают в работу политики хранения. Например, последние точки восстановления за 1–3 дня можно держать на быстрых блочных дисках, чтобы обеспечить минимальный RTO при сбое. Более старые копии автоматически переводятся в S3, где хранение обходится дешевле.
В результате компания получает более рациональную модель: критичные сервисы восстанавливаются быстро, а архивы не раздувают расходы на инфраструктуру.
В решении Акура эту логику поддерживает функция Double Storage. Она позволяет одновременно использовать блочное и объектное хранилище как цели репликации: быстрый блоковый слой — для минимального RTO и оперативного восстановления, объектный — для более экономичного долгосрочного хранения резервных копий. Такой подход помогает снять типичный компромисс между стоимостью архива и скоростью recovery без построения отдельных сценариев репликации для каждого типа хранения.
Что важно учесть перед внедрением
Гибридный подход выглядит привлекательно, но у него есть и ограничения. Перед внедрением стоит проверить:
- как именно работают политики хранения и перемещения данных между уровнями;
- сколько времени реально занимает восстановление из каждого контура;
- нет ли дополнительных расходов на операции чтения, запись снапшотов и сетевой трафик;
- как решаются вопросы целостности данных, отказоустойчивости и совместимости с текущей инфраструктурой.
Именно эти детали определяют, действительно ли гибридная схема снижает стоимость владения, а не просто переносит расходы из одной статьи бюджета в другую.
Таким образом, для долгосрочного архива лучше подходит объектное хранилище, для быстрого возврата сервисов — блочное. Гибридная модель объединяет оба сценария и помогает снизить стоимость хранения без отказа от требований к отказоустойчивости. Главное — заранее проверить, как такая схема работает на практике: от политик хранения до реального времени восстановления.