Эксперты в подборе IT-оборудования
Сервер для бэкапа и архивный сервер решают две задачи, хотя их постоянно называют одним словом. Первый нужен, чтобы быстро вернуть работу после сбоя. Второй - чтобы дёшево держать данные, которые уже не меняются, но которые нельзя удалить. Разберём, чем они отличаются по железу, сколько всего этого нужно небольшой компании и во что обойдётся хранение архива.
Копирование файлов на внешний диск перестаёт работать примерно тогда, когда копий становится больше одной, а восстанавливать приходится рабочее состояние системы целиком. Отдельный сервер даёт три вещи, которых у внешнего диска нет: расписание без участия человека, проверку целостности копий и изоляцию от той машины, которую он защищает.
Хранение резервных копий на том же сервере, который они защищают, - это не резервное копирование, а вторая копия на том же диске. Шифровальщик, добравшийся до общей папки, заберёт и её. Сервер - это железо, а чем копировать физические серверы на него, разобрано в статье про Кибер Бэкап.
Термины «архивное хранение» и «резервное копирование» часто используют как синонимы. Разница между ними примерно как между страховым полисом и библиотекой: у одного задача вернуть вас в исходное состояние, у другой - хранить и выдавать по запросу.
| Сервер для бэкапа | Архивный сервер | |
|---|---|---|
| Что хранит | копии активных данных | данные, которые больше не меняются |
| Зачем | восстановиться после сбоя | освободить основные системы и сохранить историю |
| Срок хранения | дни, недели, месяцы | годы, десятилетия |
| Как часто пишется | ежедневно, иногда ежечасно | однократно, дальше только чтение |
| Главное требование | скорость восстановления | стоимость хранения и целостность |
| Что решает при выборе | производительность дисков и сети | плотность дисков и цена за терабайт |
В небольшой компании обе роли часто живут на одной машине, и это нормально. Понимать разницу нужно из практических соображений: требования к скорости у архива в разы ниже, и железо под него дешевле.
Подсистема хранения решает почти всё. Варианты и их место:
| Тип накопителей | Плюсы | Минусы | Где применять |
|---|---|---|---|
| HDD SATA/SAS | доступная цена, большие объёмы | невысокая скорость, шум и тепло | основной объём бэкапов и архива - рабочая лошадка |
| SSD SATA/SAS | быстрый доступ, нет механики | дороже за терабайт, ресурс перезаписи | буфер под свежие копии, откуда чаще всего восстанавливают |
| NVMe | максимальная скорость, минимальные задержки | дорого, объёмы меньше | там, где восстановление считают в минутах |
| Ленточные накопители (LTO) | самое дешёвое долгое хранение, физическая изоляция | последовательный доступ, дорогой привод | архив от десятков терабайт |
Типовая для малого и среднего бизнеса схема - HDD корпоративной серии под основной объём плюс небольшой SSD-буфер под последние копии. Массив собирают зеркальный или RAID 6: у бэкап-сервера приоритетом становится способность пережить отказ диска прямо во время восстановления, а скорость записи вторична. Сколько места понадобится, зависит от схемы копий: инкрементальный и дифференциальный бэкап занимают его по-разному.
Бэкап - нагрузка на диски и сеть, а не на вычисления. Для сервера, обслуживающего парк небольшой компании, хватает 4-8 ядер и 16-32 ГБ оперативной памяти.
Цифры растут в одном случае: если включена дедупликация - механизм, который вырезает повторяющиеся блоки данных и даёт хранить те же копии на заметно меньшем объёме. Дедупликация упирается в память и процессор, и вот тогда появляются требования в 64 ГБ и выше. Порядок решения простой: сначала считаете, сколько сэкономите на дисках, потом сравниваете со стоимостью памяти.
Память под бэкап-сервер берут с ECC. Причина та же, что и везде, где данные лежат долго: незамеченная ошибка бита попадёт в копию и всплывёт при восстановлении, когда исправлять уже нечем.
Гигабитная сеть переносит примерно 400 ГБ в час при полной загрузке канала. Значит, ночное окно в шесть часов - это около 2,4 ТБ в идеальных условиях. Копировать надо 3 ТБ - вы в окно не укладываетесь и нужен канал быстрее. Надо 2 ТБ - укладываетесь впритык, без запаса на медленные диски и деградацию. Это единственный сетевой расчёт, который здесь нужен.
Для большинства небольших компаний 1 Гбит/с закрывает задачу, особенно если основной объём идёт инкрементами. 10 Гбит/с берут, когда окно короткое или объёмы измеряются десятками терабайт. Интерфейсы на 25 и 40 Гбит/с встречаются в крупных внедрениях, к типовой серверной небольшой компании отношения не имеют.
Полезный приём, который стоит ноль: вынести бэкап в отдельный сетевой сегмент или хотя бы на отдельный интерфейс. Тогда ночное копирование перестаёт конкурировать с рабочим трафиком, а заражённая рабочая сеть не видит хранилище копий напрямую.
Это единственный расчёт, который надо сделать до покупки, и делается он на салфетке.
Возьмём компанию с 10 ТБ данных, приростом 100 ГБ в сутки и политикой хранения «ежедневные копии за 30 дней, еженедельные за 3 месяца, ежемесячные за год». С учётом сжатия и дедупликации потребуется хранилище примерно на 30-40 ТБ.
Порядок счёта такой:
Отдельно посчитайте архив, если он нужен: он растёт линейно и никогда не уменьшается.
Две метрики задают всю конфигурацию. RTO - за сколько система должна вернуться в строй. RPO - за какой период допустимо потерять данные. Чем жёстче обе, тем дороже решение, поэтому их назначают по типам данных, а не одним числом на всю компанию.
| Тип данных | Реалистичный RTO | Реалистичный RPO | Что это значит для сервера |
|---|---|---|---|
| Критичные бизнес-приложения (учёт, склад, почта) | часы | часы | SSD-буфер под свежие копии, проверенная процедура восстановления |
| Операционные данные и файловые ресурсы | сутки | сутки | обычные HDD, ежедневная копия |
| Историческое и архивное | недели | недели | максимальная плотность дисков, скорость не важна |
Здесь стоит быть честным с собой: «восстановиться за минуты» стоит дорого и требует отработанной процедуры, а не одного лишь железа. Для большинства небольших компаний реальные цифры - часы, и это нормально. Как считать обе метрики под свою инфраструктуру, разобрано в статье про RPO и RTO простыми словами.
Вторая половина задачи устроена иначе.
Скорость не нужна, нужна плотность. К архивным данным обращаются редко, поэтому платить за SSD и быстрые интерфейсы незачем. Считать надо стоимость терабайта и то, сколько дисков влезет в корпус: платформа с корзиной на 12 дисков против корзины на 8 меняет экономику архива сильнее любых других параметров.
Целостность важнее доступности. Архив, который пролежал пять лет и не читается, хуже отсутствующего - на него рассчитывали. Значит, нужны файловая система или ПО с контролем контрольных сумм и регулярная фоновая проверка данных. Это условие, ради которого архив вообще стоит держать.
Неизменяемость. Для архива важна возможность запретить перезапись и удаление на заданный срок - режим WORM (write once, read many) на уровне ПО или носителя. Он же защищает от шифровальщика: то, что нельзя перезаписать, нельзя и зашифровать.
Про ленту честно. LTO остаётся самым дешёвым способом хранить терабайты годами: у поколения LTO-9 картридж вмещает 18 ТБ без сжатия, у LTO-10 - 30 ТБ у первых поставок 2025 года, а спецификация обновлена до 40 ТБ. Но стоимость входа определяется приводом, и он дорогой. Для небольшой компании лента обычно не окупается: ниже нескольких десятков терабайт архива дешевле обойдутся диски, а физическую изоляцию даст съёмный носитель в сейфе. Ленты стоит считать, когда архив измеряется сотнями терабайт и хранится годами - подробнее в разборе про ленточную библиотеку.
Альтернатива ленте, которую для СМБ считают чаще, - объектное хранилище с S3-совместимым интерфейсом на своём железе: оно даёт версионирование, блокировку объектов и понятную работу с большими массивами неизменяемых данных. Разбор с расчётом экономики - в статье про объектное хранилище S3 в своей стойке. А как раскладывать данные по уровням хранения в зависимости от того, как часто к ним обращаются, показано в материале про холодное хранение данных.
Отдельный случай, который в малом бизнесе всплывает регулярно: архив содержит персональные данные, и тогда к нему добавляются требования закона.
Ключевое - где физически стоит сервер. Требование локализации по 152-ФЗ означает, что базы с персональными данными российских граждан должны находиться на территории России. Для архива вывод простой: облачное архивное хранилище зарубежного провайдера не подходит, а свой сервер в своей серверной подходит по определению. Что именно попадает под требование и как это устроено, разобрано в статье про локализацию персональных данных.
Второе - сроки. Персональные данные хранят ровно столько, сколько нужно для заявленной цели, после чего уничтожают. Архив, который бесконечно копит всё подряд, из актива превращается в риск: чем больше данных лежит, тем дороже обойдётся утечка. Поэтому политику удаления для архива продумывают одновременно с политикой хранения, а не через три года после запуска.
Железо определяет потолок, ПО - то, насколько удобно им пользоваться. При выборе смотрят на несколько вещей:
Обзоры конкретных продуктов мы не делаем: их возможности меняются от версии к версии, и оценивать их надо на своём стенде. Практический совет один - до покупки лицензий проверьте, что выбранное ПО умеет восстанавливать вашу конкретную конфигурацию, а не одну лишь копию файлов.
Подробный разбор с расчётом конфигурации под конкретный парк - в отдельной статье про то, как выбрать сервер под бэкапы. Здесь - короткий список вопросов, на которые надо ответить до разговора с поставщиком:
Последний вопрос задают реже всего, а он решающий. Резервная копия, из которой ни разу не восстанавливались, - это предположение, а не копия.
Иммутабельное хранение стало нормой. Шифровальщики научились искать и удалять резервные копии до того, как зашифруют основные данные. Поэтому копия, которую нельзя изменить в течение заданного срока, из дополнительной меры превратилась в базовое требование.
Воздушный зазор возвращается. Физически отключённый носитель - съёмный диск, лента в сейфе - защищает от того, от чего не спасает ни одна сетевая настройка. Для небольшой компании это самый дешёвый способ закрыть третью копию из правила 3-2-1.
Гибридные схемы вместо выбора «своё или облако». Быстрое восстановление держат локально, долгое хранение уводят в облако или на дешёвый локальный слой. Для СМБ это обычно означает: свежие копии на своём сервере, глубокий архив - там, где терабайт дешевле.
Что такое сервер бэкапов простыми словами?
Отдельная машина, которая по расписанию забирает копии данных с рабочих серверов, хранит их по заданной политике и возвращает состояние на нужную дату. Ключевое слово - отдельная: копии должны лежать не там же, где оригиналы.
Чем архивный сервер отличается от обычного файлового?
Задачей и режимом работы. Файловый сервер отдаёт данные, с которыми работают каждый день. Архивный хранит то, что уже не меняется, и оптимизирован под стоимость терабайта и долгую сохранность.
Какой тип резервного копирования подходит для долгосрочного архива?
Для архива обычно делают полную копию с последующей неизменяемостью, а не цепочку инкрементов. Причина простая: восстановление из длинной цепочки инкрементов через несколько лет упирается в целостность всех звеньев сразу.
Сколько дисков нужно серверу для бэкапа?
От объёма и выбранного уровня RAID. Минимально работающая схема для небольшого офиса - два диска в зеркале, но она не даёт запаса на рост. Практичнее платформа с корзиной на 8-12 дисков: докупать диски дешевле, чем менять сервер.
Можно ли использовать под бэкап восстановленный сервер?
Для этой задачи - вполне. Бэкап-серверу не нужны свежие процессоры, а корпус с большой дисковой корзиной и резервированием питания служит долго. Смотреть надо на ресурс дисков и на срок гарантии.
Нужна ли лента небольшой компании?
Обычно нет. Стоимость входа определяет привод, а не картриджи, и на объёмах ниже нескольких десятков терабайт диски выходят дешевле. Физическую изоляцию проще получить съёмным диском, который увозят с площадки.
Считаете сервер под резервное копирование или архив?
Инженеры ITTELO подберут дисковую подсистему под ваш объём и политику хранения, посчитают, укладывается ли копирование в ночное окно, соберут и протестируют платформу под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
