Сервер под резервное копирование: как подобрать конфигурацию
Сервер бэкапа подбирается не так, как сервер приложений: ядра и память здесь вторичны, а решают ёмкость, диски и сеть. Считаем объём репозитория с учётом дедупликации, выбираем уровень RAID и разбираем, когда вместо сервера выгоднее массив.
Сервер резервного копирования устроен иначе, чем сервер приложений. Здесь почти не нужны процессорные ядра и оперативная память под виртуальные машины, зато критично важны дисковая подсистема, пропускная способность сети и предсказуемость записи больших последовательных потоков. Подбирать его по остаточному принципу — из того, что списали с продуктивной нагрузки, — распространённая и дорогая ошибка.
Разберём расчёт по шагам: сколько нужно ёмкости, какие диски ставить, сколько ядер и памяти на самом деле требуется и когда вместо сервера правильнее взять готовый дисковый массив.
Шаг 1. Считаем ёмкость
Отправная точка — суммарный объём защищаемых данных, а не размер дисков на продуктиве. Формула для типового расчёта на месяц хранения выглядит так:
- Полная копия. Объём данных × 1 — базовая точка отсчёта.
- Инкрементальные копии. Суточный прирост обычно 2–5 % от объёма; за 30 дней это ещё 0,6–1,5 объёма.
- Дедупликация и сжатие. На виртуальных машинах однородной среды экономия достигает 5:1, на базах данных — 2:1, на архивах и медиа — почти нулевая.
- Запас на рост. 30 % на год, иначе через восемь месяцев придётся докупать полку.
Пример: 20 ТБ продуктивных данных, месяц хранения, среда виртуализации. 20 ТБ полной копии плюс примерно 20 ТБ инкрементов даёт 40 ТБ; при дедупликации 3:1 — около 14 ТБ фактических, плюс 30 % запаса — 18 ТБ полезной ёмкости. С учётом уровня RAID и резервных дисков это 24–26 ТБ сырой ёмкости.
Шаг 2. Диски и уровень RAID
| Вариант | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| SATA/SAS 7200 об/мин, RAID 6 | дешёвый терабайт, надёжность при отказе двух дисков | долгое восстановление массива | основной сценарий для резервных копий |
| SATA/SAS, RAID 10 | быстрое восстановление, высокая запись | половина ёмкости уходит на зеркала | если окно копирования очень узкое |
| SSD-кеш поверх дисков | ускоряет метаданные дедупликации | дороже, требует контроллера с поддержкой | при большом числе мелких файлов |
| Полностью твердотельный массив | минимальное время восстановления | цена терабайта в разы выше | только под мгновенное восстановление сервисов |
| Ленточная библиотека | дешёвое долговременное хранение, физическая изоляция | медленный доступ, отдельное ПО | третья копия по правилу 3-2-1 |
Для резервного копирования почти всегда выигрывают ёмкие жёсткие диски корпоративного класса в RAID 6. Настольные модели сюда не годятся: у них нет защиты от вибрации в многодисковой корзине и не тот показатель допустимой нагрузки в год. Обязательно закладывайте один диск горячего резерва на каждые 12–16 дисков в корзине.
Аппаратный RAID-контроллер нужен с батарейной или конденсаторной защитой кеша — без неё запись в кеш при пропадании питания превращается в повреждённый массив.
Шаг 3. Процессоры, память, сеть
Здесь легко переплатить. Реальные потребности скромнее, чем кажется:
- Процессор. Один сокет, 8–16 ядер. Дедупликация и сжатие нагружают процессор, но не так, чтобы требовать двухсокетной платформы. Про то, где вообще нужен второй сокет, мы писали отдельно.
- Оперативная память. Правило большинства систем дедупликации — 1 ГБ памяти на 1 ТБ хранимых данных, минимум 32 ГБ. Для 20 ТБ репозитория это 32–64 ГБ.
- Сеть. Гигабита хватает на 3–4 ТБ за ночное окно. Если данных больше, ставьте адаптеры на 10 Гбит/с — иначе копирование не уложится в окно и начнёт мешать рабочему дню.
- Корпус. Число дисковых отсеков важнее высоты. Двухюнитовая платформа на 12 дисков большого формата — типовой выбор; четырёхюнитовая на 24–36 дисков берётся под рост.
Шаг 4. Сервер, СХД или NAS
Три архитектуры решают одну задачу по-разному.
- Сервер с локальными дисками. Самый дешёвый терабайт и полный контроль. Подходит, когда репозиторий один и растёт предсказуемо. Смотрите Dell, HPE, Supermicro, Lenovo, Huawei.
- Дисковый массив. Отдельная система хранения с двумя контроллерами оправдана, когда к репозиторию обращаются несколько серверов копирования или когда нужна репликация на вторую площадку.
- NAS. QNAP и Synology закрывают небольшие объёмы до 50–100 ТБ и малые офисы: дешевле, проще в обслуживании, но потолок производительности ниже.
Третья копия по правилу 3-2-1 обычно уезжает либо на ленточный накопитель, либо на удалённую площадку. Лента до сих пор остаётся самым дешёвым способом хранить редко запрашиваемые данные и единственным, который физически невозможно зашифровать по сети.
Что часто упускают при подборе
- Скорость восстановления, а не копирования. Заказчик считает окно бэкапа и забывает посчитать, за сколько часов система поднимется обратно. RAID 6 из ёмких дисков восстанавливает 100 ТБ сутками.
- Лицензии. Программное обеспечение резервного копирования лицензируется по числу защищаемых машин или сокетов — лицензии закладывайте в смету сразу.
- Поддержка на железо. Сервер бэкапа живёт дольше продуктивного, и сервисный контракт на 5 лет здесь окупается.
- Изоляция. Репозиторий, доступный из домена под учётной записью администратора, шифруется вместе со всем остальным.
Частые вопросы
Можно ли использовать под бэкап списанный продуктивный сервер? Можно, если у него достаточно дисковых отсеков и есть поддержка. Но чаще у списанной машины много ядер и мало места под диски — то есть ровно наоборот тому, что нужно.
Сколько дисков ставить в один массив RAID 6? Оптимально 8–12. На больших группах время восстановления растёт нелинейно, и риск второго отказа во время ребилда становится заметным.
Нужен ли отдельный сервер под ПО копирования? На малых объёмах роль сервера управления и репозитория совмещают. От 50 ТБ их разумно разнести: управление на небольшую машину, хранение на ёмкую.
Даёт ли дедупликация выигрыш всегда? Нет. На уже сжатых данных — видео, архивы, зашифрованные базы — она почти ничего не экономит, но забирает память и процессор.
Гигабитной сети точно не хватит? Гигабит — это около 400 ГБ в час при идеальных условиях. Считайте по своему объёму суточного прироста и длине окна.
Сколько закладывать запаса по ёмкости? 30 % на год. Ёмкость репозитория растёт не только от прироста данных, но и от увеличения глубины хранения, о которой обычно просят уже после запуска.
Подберём конфигурацию под ваш объём
Пришлите объём защищаемых данных, требуемую глубину хранения, длину ночного окна и используемое ПО копирования на server@tkasiatorg.ru. Посчитаем ёмкость с учётом дедупликации и подберём сервер, диски и контроллер одним комплектом — либо предложим систему хранения, если так выйдет дешевле.
