Выбор сервера для бэкапов: надеемся на лучшее, готовимся к худшему

Выбор сервера для бэкапов начинается не с модели процессора и не с количества дисковых отсеков. Сначала нужно определить объём защищаемых данных, ежедневный прирост, срок хранения копий, допустимую потерю данных (RPO) и время восстановления (RTO). После этого рассчитывают ёмкость репозитория, необходимую пропускную способность сети и дисковой подсистемы — и только затем подбирают сервер.

Для 10–30 ТБ обычно достаточно одного сервера с LFF-дисками, 32–64 ГБ ECC-памяти и сетью 10 GbE. При 50–150 ТБ уже пригодятся 12–24 дисковых отсека, 128 ГБ RAM, сеть 10/25 GbE и отдельная неизменяемая копия. При 300+ ТБ роли лучше разделять между управляющим сервером, proxy/media-серверами и масштабируемым репозиторием, дополняя дисковое хранение объектным S3-хранилищем или LTO.

Привет!

Век у нас информационный, а потому информация для современного бизнеса ценна как никогда. Помните закон Мерфи? Если что-нибудь может пойти не так, оно пойдёт не так. Когда случится серьёзный сбой или потеря данных, бизнес понесёт финансовые и/или репутационные потери.

Представьте, что одним днём вы распрощаетесь со всеми данными по финансовой отчётности, договорами, лицензиями и соглашениями. Или потеряете информацию из CRM о клиентах, их предпочтениях и покупках. А что насчёт ключей, учётных данных и административных паролей? Не говоря уже про любимую 1С и почтовую корреспонденцию. Звучит плохо, но реализуется легко: вирус-шифровальщик, сбой оборудования или ПО, человеческий фактор, пожар или потоп.

Резервная копия, она же бэкап, — это отдельная копия данных, из которой их можно восстановить после удаления, повреждения или недоступности основной системы. В этой статье мы кратко разберём базовые понятия, но основной акцент сделаем на выборе оборудования.

А значит, пора выбирать сервер для резервного копирования данных. Неплохо, если огнетушитель появился в доме до пожара, а не после, согласны?

Сервер HPE DL380 Gen10 8SFF

• Добавить в сравнение
• Добавить в избранное

Refurbished В наличии

Размер:

2U

CPU:

2 x 1st or 2nd Generation Intel Xeon Scalable

RAM:

DDR4 DIMM 12 слотов (1536 GB)

HDD:

до 8 HDD 2.5'' SFF

5 лет гарантии

Бесплатная доставка

Цена базы:

от 126 000 ₽

4 379 ₽/мес в лизинг

от 103 279 ₽

+ 22 721 НДС

• Добавить в сравнение
• Добавить в избранное

КП за час Сконфигурировать

Сервер HPE DL380 Gen10 Plus 8SFF

• Добавить в сравнение
• Добавить в избранное

Новый В наличии

Размер:

2U

CPU:

2 x 3rd Generation Intel Xeon Scalable

RAM:

DDR4 DIMM 16 слотов (2048 GB)

HDD:

до 8 HDD 2.5'' SFF

5 лет гарантии

Бесплатная доставка

Цена базы:

от 369 782 ₽

12 850 ₽/мес в лизинг

от 303 100 ₽

+ 66 682 НДС

• Добавить в сравнение
• Добавить в избранное

КП за час Сконфигурировать

Зачем нужен сервер для резервных копий

Малый бизнес для бэкапов часто использует флешки, внешние жёсткие диски, другие ПК, ноутбуки и рабочие станции. Схема рабочая, но не профильная. Внешний диск можно использовать как дополнительную копию, однако он не заменит управляемую систему резервного копирования.

Реальная история: генеральный директор одной небольшой компании примерно на 150 сотрудников раз в квартал просил записать резервную копию документов и баз данных на диск, который хранил дома в сейфе. Получался простейший физический air gap: пока диск отключён и находится в другом месте, шифровальщик из корпоративной сети до него не доберётся.

Но если использовать такую копию как единственный основной бэкап, это всё равно что на машине с низким клиренсом отправиться по просёлочным ямам дорогам рассекать. Между квартальными копиями можно потерять до трёх месяцев данных, а успешность восстановления никто не гарантирует.

Для надёжного резервного копирования лучше использовать сервер или специализированное хранилище. Это масштабируемое и управляемое решение, которое особенно важно при больших объёмах данных и строгих требованиях к восстановлению.

Преимущества сервера для бэкапов:

• Автоматизация. Можно настроить полные, инкрементальные и дифференциальные копии по расписанию, контролировать их выполнение и автоматически применять правила хранения. Это снижает влияние человеческого фактора и обеспечивает регулярность.

• Сетевой доступ. Один сервер может принимать данные с физических серверов, виртуальных машин, рабочих станций, СУБД и удалённых филиалов. По той же сети выполняется восстановление.

• Централизованное управление. Администратор видит состояние заданий, объём репозитория, ошибки, сроки хранения и результаты проверки. Можно настроить отчёты и уведомления, а также тестовое восстановление в изолированную среду.

• Отказоустойчивость. Серверы поддерживают RAID, резервные блоки питания, несколько сетевых интерфейсов, ECC-память, горячую замену компонентов и удалённое управление. Однако это повышает доступность самого сервера, а не отменяет необходимость независимых копий.

• Хранение больших объёмов данных. В сервер можно установить десятки HDD, SSD для метаданных и кэша, RAID-контроллер, HBA и сетевые адаптеры 10/25/40/100 GbE. При необходимости к нему подключают дисковые полки.

• Версионирование. Можно хранить несколько точек восстановления и откатываться к состоянию до ошибки, неудачного обновления или атаки шифровальщика.

• Управление доступом. Права на создание, чтение и удаление копий можно разделить. Учётные данные рабочего сервера не должны автоматически давать право удалить бэкапы.

• Защита данных. Шифрование, многофакторная аутентификация, журналирование, неизменяемые репозитории и изолированные копии значительно усложняют уничтожение резервных данных при атаке.

Сервер можно заставить выполнять сразу несколько ролей: резервное копирование, почта, хостинг и другие приложения. Но в рабочей инфраструктуре репозиторий лучше отделять от основных нагрузок. Если шифровальщик получит административный доступ к одному универсальному серверу, он может уничтожить и рабочие данные, и лежащие рядом копии.

О виртуализации таких ролей подробнее читайте в статье «Как выбрать сервер для виртуализации».

Виды серверов для бэкапа: от ПО до оборудования

Под каждую задачу есть свой вариант системы резервного копирования. Разница заключается не только в оборудовании и локации, но и в ПО, способе хранения, уровне изоляции и архитектуре.

RPO, RTO, retention и backup window

Эти параметры напрямую влияют на конфигурацию сервера:

• RPO — Recovery Point Objective. Максимальный объём данных, который бизнес готов потерять, выраженный во времени. RPO в 24 часа допускает потерю изменений за сутки, а RPO в 15 минут требует значительно более частых копий или репликации журналов.

• RTO — Recovery Time Objective. Максимально допустимое время восстановления сервиса. Если RTO равен четырём часам, за это время сервер, сеть и репозиторий должны успеть прочитать и передать нужный объём данных, а команда - запустить работающий сервис.

• Retention. Срок хранения резервных копий и количество доступных версий. Для оперативного восстановления может быть достаточно 30–90 дней, а бухгалтерские или архивные данные иногда хранят годами.

• Backup window. Интервал, в который должно уложиться резервное копирование. Например, если полную копию можно создавать только с 22:00 до 06:00, окно составляет восемь часов.

Короткие RPO и backup window повышают требования к сети, дискам и CPU. Короткий RTO повышает требования к скорости чтения репозитория и целевой системы восстановления. Именно поэтому сервер нельзя выбирать только по количеству терабайт.

Правило 3-2-1-1-0

Классическое правило 3-2-1 (3 копии данных, 2 на разных носителях, 1 в другой локации) сегодня принято усложнять, расширяя до 3-2-1-1-0:

• 3 копии данных: рабочая и как минимум две резервные;

• 2 типа носителей или независимые системы хранения;

• 1 копия за пределами основной площадки;

• 1 изолированная либо неизменяемая копия;

• 0 необнаруженных ошибок после проверки и тестового восстановления.

Четвёртая единица особенно важна из-за ransomware. В качестве хранилища может использоваться immutable-репозиторий, S3 Object Lock, WORM-картридж или физически отключённая лента. Ноль означает, что копия не просто создана: её целостность проверена, а процедура восстановления протестирована.

Софт для бэкапа: российский и опенсорсный

Выбор ПО определяет поддерживаемые источники, схему хранения, дедупликацию, совместимость с виртуализацией и требования к CPU и RAM.

• Кибер Бэкап от компании «Киберпротект». В актуальной документации представлена версия 18.6. Решение поддерживает централизованную защиту физических и виртуальных сред, СУБД, приложений, ленточных устройств и различных хранилищ. В поколении 18 получили развитие медиасерверы, многопоточное копирование, интеграции с российскими платформами виртуализации, мониторинг и защита от шифровальщиков. Перед закупкой нужно сверить конкретную ОС, гипервизор, СУБД и ленточное устройство с матрицей совместимости Кибер Бэкапа. Оценок в духе «лучшее отечественное решение» здесь не нужно: продукт следует сравнивать по поддержке вашей инфраструктуры, производительности и лицензированию.

• RuBackup от компании «РуБэкап», входящей в «Группу Астра». В апреле 2026 года официально выпущена RuBackup 2.9. Платформа поддерживает физические системы, СУБД, российские и зарубежные среды виртуализации, файловые и блочные пулы, S3-совместимые хранилища и ленточные библиотеки. Утверждение, что RuBackup не работает с VMware, устарело: в документации заявлена поддержка ряда версий VMware vSphere. Совместимость всё равно нужно проверять для конкретного релиза vSphere и RuBackup.

• Handy Backup от «Новософт». Есть редакции для отдельных компьютеров и серверной инфраструктуры. Решение подходит для файлов, рабочих станций, серверов и ряда прикладных систем. Конкретную редакцию выбирают по числу защищаемых машин, типам источников и требуемым модулям.

• Duplicity. Консольный инструмент для инкрементальных зашифрованных копий. Поддерживает разные удалённые назначения, но требует самостоятельной настройки расписаний, мониторинга и проверки восстановления.

• Duplicati. Решение с открытым исходным кодом для Windows, Linux и macOS. Поддерживает шифрование, дедупликацию и различные локальные и облачные назначения. Для корпоративного использования нужно отдельно продумать мониторинг, обновление и защиту учётных данных.

• Bacula. Кроссплатформенная система для централизованного резервного копирования, восстановления и проверки данных. Актуальная ветка Bacula Community — 15.0.x, включая релиз 15.0.3. Поддерживает файловые, дисковые и ленточные сценарии. Корпоративная Bacula Enterprise развивается отдельно, поэтому возможности Community и Enterprise нельзя смешивать в одном сравнении.

• Bareos. Развивающийся форк Bacula с открытым исходным кодом. В августе 2026 года выпущена версия 25.1; в ней появилась техническая предварительная версия нового WebUI и расширены возможности управления ключами аппаратного шифрования LTO. Bareos подходит для централизованной схемы с управляющим сервером, клиентскими агентами и отдельными storage daemon, но требует компетенций Linux-администратора.

• rsync. Инструмент синхронизации файлов и каталогов. Сам по себе он не обеспечивает полноценное версионирование, каталог резервных копий, application-consistent backup или защиту от удаления. Если шифровальщик испортил исходные файлы, обычная синхронизация может перенести повреждения в копию.

• AMANDA. Система сетевого резервного копирования, поддерживающая дисковые и ленточные назначения. Подойдёт организациям, которые готовы самостоятельно сопровождать Linux-инфраструктуру и проверять совместимость компонентов.

• BorgBackup. Дедуплицирующий инструмент с шифрованием и сжатием. Стабильная документация относится к ветке 1.4.5, тогда как Borg 2.0 пока представлен бета-версиями. Режим append-only помогает защитить удалённый репозиторий от удаления со стороны скомпрометированного клиента, однако администратор репозитория всё равно должен быть защищён отдельно. Возможности и ограничения описаны в документации BorgBackup.

Есть и зарубежные коммерческие решения: Veeam Backup & Replication, Veritas NetBackup, Commvault и другие. При выборе нужно учитывать не только функциональность, но и возможность закупки, продления лицензий, получения обновлений и технической поддержки.

Идём дальше.

Виды серверов для бэкапа по типу размещения

Есть два стула три основных варианта: разместить оборудование у себя, использовать облако или объединить локальную и облачную инфраструктуру.

Объектное хранилище — это не обязательно публичное облако. S3-совместимый репозиторий можно развернуть в собственном ЦОДе. Важно различать обычное версионирование объектов и Object Lock: только корректно настроенная блокировка с заданным сроком хранения защищает версии от преждевременного удаления.

Виды локальных серверов для резервного копирования

Выбор конкретного решения зависит от бюджета, объёма данных, требований к производительности и стратегии восстановления. Компании часто используют комбинацию серверов, NAS, СХД, объектных хранилищ и лент.

Сетевые хранилища — NAS.

NAS — специализированное устройство, подключённое к Ethernet-сети. Оно предоставляет файловый доступ по SMB или NFS и может выступать репозиторием для копий с рабочих станций и серверов.

Плюсы:

• централизованное хранение;

• простое подключение по сети;

• встроенные расписания и снимки в ряде моделей;

• возможность RAID и горячей замены дисков;

• сравнительно невысокая стоимость начального решения;

• расширение с помощью дополнительных дисков или полок в поддерживаемых моделях.

Минусы:

• производительность ограничена сетевыми интерфейсами, контроллером и дисками;

• младшие модели плохо справляются с большим количеством параллельных заданий;

• файловая шара с правами на удаление у backup-клиентов уязвима для шифровальщика;

• встроенный снимок на том же NAS не защищает от потери всего устройства.

NAS подходит для дома, филиала и малого бизнеса. Для сложных сценариев стоит сравнить его с сервером или SAN — подробнее об этом читайте в статье «NAS, SAN и DAS: чем отличаются и что выбрать».

Серверы для бэкапов — Backup Servers.

Это серверы общего назначения, полностью или преимущественно выделенные под резервное копирование. Подробнее о конструктивных отличиях такого оборудования рассказано в статье «Чем сервер отличается от обычного компьютера».

Сервер может использовать внутреннюю дисковую корзину либо подключаться к NAS, СХД, JBOD, S3 или ленточной библиотеке. Например, модели формата 2U могут поддерживать 12 LFF или 24 SFF, а системы высокой плотности — 24–36 LFF и больше.

Плюсы:

• гибкая программно-аппаратная конфигурация;

• масштабирование CPU, RAM, сетевых адаптеров и накопителей;

• возможность установить RAID-контроллеры, HBA и платы Fibre Channel;

• централизованное управление и мониторинг;

• резервные БП, ECC-память и горячая замена;

• поддержка шифрования и программной дедупликации.

Минусы:

• стоимость выше, чем у простого NAS;

• нужны компетенции для настройки и обслуживания;

• один сервер остаётся одной площадкой отказа;

• потребуется инфраструктура: стойка, охлаждение, ИБП и коммутаторы.

В небольшой системе все функции могут выполняться одним сервером. При росте инфраструктуры роли лучше разделять:

• Управляющий backup-сервер хранит конфигурацию, каталог, расписания, политики и сведения о точках восстановления. Большая дисковая корзина ему не обязательна.

• Proxy или media server читает данные из источников, обрабатывает потоки, выполняет сжатие, дедупликацию и шифрование, а затем передаёт данные в репозиторий. Именно здесь часто нужны дополнительные CPU, RAM и быстрые сетевые интерфейсы.

• Репозиторий хранит резервные копии. Для него важны полезная ёмкость, производительность дисков, защита от удаления, контроль целостности и масштабируемость.

Разделение ролей позволяет независимо наращивать вычислительные узлы и ёмкость. Кроме того, компрометация управляющего сервера не должна автоматически давать злоумышленнику административный доступ к репозиторию.

Системы хранения данных — СХД.

СХД изначально проектируют для хранения и передачи больших объёмов данных. Они поддерживают дисковые полки, два контроллера, несколько путей доступа, автоматическое перестроение массивов, снимки и репликацию.

Плюсы:

• высокая ёмкость и плотность хранения;

• масштабирование дополнительными дисками и JBOD;

• резервирование контроллеров, БП и сетевых путей;

• централизованное управление;

• аппаратное или программное сжатие и дедупликация в поддерживаемых системах;

• поддержка файлового, блочного или объектного доступа в зависимости от модели.

Минусы:

• более высокая стоимость;

• сложность настройки и сопровождения;

• необходимость проверить совместимость протоколов, HBA, ПО и прошивок;

• снимки и репликация СХД сами по себе не заменяют независимый бэкап.

Для средних и крупных инфраструктур СХД часто становится основным дисковым репозиторием. Но резервную копию всё равно нужно выводить в другой домен отказа — на вторую площадку, в S3 или на ленты.

Ленточные хранилища и библиотеки — Tape Drives.

Эти штуки могут удивить неискушённых технологиями людей. Помните VHS-видеомагнитофоны? «Терминатор» с озвучкой Володарского? Achievement unlocked — вы родились в прошлом веке. И восстали роботизированные ленточные библиотеки из ядерного пепла…

На самом деле магнитные ленты из серверного сегмента никуда не уходили. Они остаются востребованными для долгосрочного хранения благодаря большой ёмкости, низкому энергопотреблению и возможности создать настоящий физический air gap.

Основной открытый стандарт — LTO, Linear Tape-Open. Данные считывает и записывает ленточный привод. Картриджи бывают перезаписываемыми и WORM — Write Once, Read Many. WORM-носитель нельзя штатно перезаписать или очистить, поэтому он подходит для неизменяемых архивов.

С аппаратной точки зрения используются:

• одиночные внешние и внутренние приводы;

  

• автозагрузчики с несколькими слотами и одним или несколькими приводами;

  

• масштабные ленточные библиотеки с роботизированной подачей картриджей;

  

• виртуальные ленточные библиотеки VTL, которые работают на дисках, но эмулируют ленточный интерфейс для совместимости с существующим ПО.

Актуальное поколение — LTO-10. Согласно официальным характеристикам LTO Program, для него предусмотрены картриджи двух вариантов:

• 30 ТБ без сжатия и до 75 ТБ при коэффициенте 2,5:1;

• 40 ТБ без сжатия и до 100 ТБ при коэффициенте 2,5:1.

Скорость передачи достигает 400 МБ/с. Реальный коэффициент сжатия зависит от данных: уже сжатые видео, архивы и зашифрованные файлы могут практически не уменьшаться.

Плюсы лент:

• большая ёмкость и сравнительно низкая стоимость хранения одного терабайта;

• WORM и аппаратное шифрование;

• низкое энергопотребление при хранении;

• долгий срок хранения при соблюдении условий;

• физическая изоляция после извлечения картриджа.

Минусы:

• последовательный доступ и сравнительно долгое восстановление отдельных файлов;

• необходимость менять картриджи или использовать роботизированную библиотеку;

• требования к температуре, влажности, транспортировке и периодической проверке;

• нужны специалисты, которые умеют работать с приводами, библиотеками и каталогом лент;

• переход на LTO-10 требует учитывать отсутствие совместимости с LTO-9.

Ленты особенно полезны для долгосрочного retention, больших архивов и изолированной копии в правиле 3-2-1-1-0. Для оперативного восстановления удобнее сначала читать данные с дискового репозитория, а ленту использовать как второй или третий уровень защиты.

Immutable repository, Object Lock, WORM и air gap

Обычный репозиторий можно удалить вместе с рабочими данными, если злоумышленник получил административные права. Поэтому хотя бы одна копия должна быть неизменяемой или изолированной.

• Immutable repository запрещает изменение или удаление копий до окончания установленного срока. Защита должна действовать на уровне репозитория, а не только интерфейса backup-программы.

• Object Lock блокирует удаление определённых версий объектов в S3-совместимом хранилище. Возможности режимов Governance и Compliance отличаются, поэтому правила удаления нужно проверять у конкретного провайдера или продукта.

• WORM разрешает записать данные один раз и многократно их читать. Механизм встречается в ленточных картриджах и специализированных системах хранения.

• Физический air gap означает, что носитель действительно отключён от сети и оборудования. Извлечённая лента или отключённый диск не зависят от сетевых прав и общих административных учётных записей.

Неизменяемость не отменяет шифрование, разграничение прав и проверку восстановления. Можно безупречно защитить от удаления резервную копию, которая изначально оказалась повреждённой или содержит уже зашифрованные данные.

Почему RAID и снапшот не заменяют резервную копию

RAID защищает доступность массива при отказе диска, но не создаёт независимую копию данных. Удалённый файл одновременно исчезнет со всех дисков массива. Шифровальщик зашифрует данные поверх RAID, а сбой контроллера, ошибка администратора или потеря всего сервера затронет массив целиком.

Снапшот позволяет быстро вернуться к предыдущему состоянию тома или виртуальной машины, но часто зависит от исходной СХД и общих блоков данных. Если массив потерян, снимок может исчезнуть вместе с ним. Если злоумышленник получил права администратора СХД или гипервизора, он может удалить и рабочие данные, и снимки.

При этом длительное использование снапшота может замедлить производительность системы, поэтому оптимальный сценарий использования данного механизма - сделать снапшот, провести изменения, убедиться что они успешны, удалить снапшот.

Репликация тоже не всегда равна бэкапу: она может быстро перенести на вторую площадку удаление, логическую ошибку или зашифрованные блоки. Но иногда бэкап удобнее делать именно с реплицированных данных, чтоб не влиять на рабочие нагрузки.

RAID, снапшоты и репликация полезны как уровни доступности и быстрого восстановления. Полноценной резервной копией они становятся только тогда, когда данные хранятся независимо, имеют собственный срок хранения и могут быть восстановлены после потери исходной системы.

Требования к серверу для бэкапа

Переходим к подбору конфигурации. Универсального сервера не существует: для файлового офиса на 20 ТБ и виртуальной инфраструктуры на 500 ТБ нужны разные архитектуры.

Однако подбор можно сделать вполне предметным. Сначала рассчитываем ёмкость и скорость, затем определяем роли сервера, число дисков, CPU, RAM и сетевые интерфейсы.

Технические характеристики сервера

Частая ошибка — поставить быстрый сетевой адаптер в сервер, оставив старый гигабитный коммутатор или массив из нескольких медленных HDD. Производительность цепочки определяется её самым медленным участком.

Как рассчитать ёмкость репозитория

Для предварительной оценки используйте формулу:

Требуемая полезная ёмкость = (исходный объём данных + ежедневный прирост × срок хранения) ÷ ожидаемый коэффициент дедупликации × 1,2–1,3.

Где:

• исходный объём — полный объём защищаемых данных;

• ежедневный прирост — новые или уникально изменённые данные за сутки;

• срок хранения — количество дней retention;

• коэффициент дедупликации — реальный ожидаемый результат, а не максимальное число из рекламной презентации;

• 20–30% — запас под рост, служебные данные, перестроение массива и временные операции.

Пример. Компания защищает 50 ТБ данных. Ежедневно появляется или уникально изменяется 1 ТБ, копии хранятся 30 дней, ожидаемый коэффициент дедупликации равен 1,5.

(50 + 1 × 30) ÷ 1,5 × 1,25 = примерно 66,7 ТБ полезной ёмкости.

Это не сырая ёмкость дисков. К полученному значению нужно добавить потери на RAID, файловую систему и резерв свободного места. Например, восемь дисков по 12 ТБ — это 96 ТБ сырой ёмкости, но после RAID 6, форматирования и технологического запаса доступный объём будет заметно меньше.

Если политика предусматривает несколько независимых полных цепочек, месячные и годовые копии, их считают отдельно. Для зашифрованных архивов, видео и уже сжатых файлов коэффициент дедупликации лучше принимать близким к единице, пока тесты не доказали обратное.

Как рассчитать скорость записи и восстановления

Требуемая скорость резервного копирования:

Скорость записи = объём данных задания ÷ backup window × 1,2–1,3.

Допустим, нужно записать 10 ТБ за восемь часов:

10 ТБ ÷ 8 часов = примерно 347 МБ/с.

С запасом 25% потребуется около 434 МБ/с устойчивой полезной производительности. Гигабитная сеть с теоретическим пределом около 125 МБ/с здесь не справится. Практичным минимумом будет 10 GbE — при условии, что источники, диски и коммутаторы также обеспечивают нужную скорость.

Для восстановления применяется похожая формула:

Скорость восстановления = восстанавливаемый объём ÷ RTO × 1,2–1,3.

Если в течение четырёх часов нужно восстановить 20 ТБ:

20 ТБ ÷ 4 часа × 1,25 = примерно 1,74 ГБ/с.

Такой сценарий уже требует сети 25 GbE или нескольких каналов, производительного массива и целевой платформы, способной принимать данные с этой скоростью.

При расчёте учитывайте, что:

• один HDD и массив из 12 HDD дают разную последовательную скорость;

• случайное чтение большого количества мелких файлов медленнее последовательного потока;

• шифрование и дедупликация нагружают CPU;

• параллельные задания конкурируют за диски и сеть;

• восстановление из S3 или с ленты может быть медленнее локального дискового репозитория;

• фактическая скорость всегда проверяется тестовым копированием и восстановлением.

Три типовые конфигурации

Конфигурация на 10–30 ТБ полезной ёмкости

Подходит небольшому офису, филиалу, файловому серверу и нескольким виртуальным машинам.

• один башенный или стоечный сервер с 6–8 отсеками LFF;

• 8–12 современных процессорных ядер;

• 32–64 ГБ ECC RAM;

• отдельные SSD в RAID 1 под ОС;

• Enterprise HDD в RAID 6 или RAIDZ2;

• два сетевых интерфейса 10 GbE либо один рабочий и один резервный;

• два блока питания и ИБП;

• копия в S3 с Object Lock, на отключаемом диске или LTO.

Такой сервер может объединять управление, media-функции и репозиторий. Но неизменяемую копию всё равно нужно хранить отдельно.

Конфигурация на 50–150 ТБ

Подходит среднему бизнесу, инфраструктуре виртуализации и нескольким филиалам.

• сервер на 12–24 LFF или сервер с внешней JBOD;

• 16–24 ядра, больше при тяжёлой дедупликации и шифровании;

• 128–256 ГБ ECC RAM;

• пара SSD/NVMe под ОС, каталог и метаданные;

• RAID 6/60, RAIDZ2/3 либо архитектура, рекомендованная производителем ПО;

• сеть 10/25 GbE;

• резервные БП, сетевые пути и мониторинг;

• отдельный управляющий сервер или виртуальная машина;

• immutable-репозиторий и удалённая копия в S3 либо на ленте.

Здесь уже важно проверить производительность перестроения массива. Один большой RAID из множества ёмких HDD может восстанавливаться после отказа несколько суток и всё это время работать с повышенным риском.

Конфигурация на 300+ ТБ

При таком объёме речь обычно идёт не об одном «очень большом сервере», а об архитектуре:

• отдельный управляющий backup-сервер;

• несколько proxy/media-серверов;

• масштабируемый дисковый или объектный репозиторий;

• несколько узлов хранения либо СХД с дисковыми полками;

• 256–512 ГБ RAM на media/storage-узел при соответствующих требованиях ПО;

• сеть 25/40/100 GbE;

• отдельная backup-сеть и сегментация управления;

• LTO-библиотека, удалённый S3 с Object Lock или второй неизменяемый репозиторий;

• резервирование каталога и конфигурации самой backup-системы.

Главный критерий здесь — не максимальная ёмкость корпуса, а возможность добавлять узлы и дисковые полки без полной перестройки системы.

Серверы резервного копирования для разных сфер

Система резервного хранения может состоять из управляющего ПО, одного или нескольких proxy/media-серверов и репозиториев. В маленькой инфраструктуре всё это помещается на одном сервере. В крупной — распределяется между несколькими площадками.

Условно можно выделить три категории, но чётких границ не существует. Исходите из объёма данных, RPO, RTO и бюджета.

Домашние пользователи

Серверный шкаф :D

Домашнему пользователю обычно не нужна инфраструктура уровня предприятия. Возможные варианты:

• старый ПК или недорогой башенный сервер с TrueNAS или OpenMediaVault;

• NAS от Synology, QNAP и других производителей;

• внешний HDD или SSD;

• облачное хранилище как дополнительная удалённая копия.

Даже дома не стоит хранить единственную копию на постоянно подключённом диске. Шифровальщик, скачок напряжения или ошибка пользователя могут затронуть и основной компьютер, и подключённый накопитель.

Малый бизнес, нужды небольших офисов и филиалов

Здесь нужно учитывать масштабируемость, безопасность, поддержку приложений и время восстановления.

• NAS. Подходит для файловых серверов, рабочих станций и небольшого числа виртуальных машин. Желательны RAID, два сетевых интерфейса и поддержка неизменяемых снимков или отдельного S3-назначения.

• Башенный или стоечный сервер. Dell PowerEdge T/R, HPE ProLiant ML/DL, Lenovo ThinkSystem ST/SR и другие линейки позволяют поставить аппаратный RAID, ECC-память, резервные БП и сетевую карту 10 GbE.

• Объектное или облачное хранилище. Используется как удалённая копия. При выборе нужно считать не только хранение, но и исходящий трафик, операции, минимальный срок хранения и время полного восстановления.

Для типичного офиса полезно отдельно учитывать данные рабочих станций, файловые шары, почту, 1С, СУБД и виртуальные машины. Если полный бэкап не помещается в ночное окно, переходят на инкрементальную схему, добавляют параллельные потоки или повышают скорость сети и репозитория.

Средний и крупный бизнес

Диапазон широкий — от пары серверов до нескольких ЦОДов.

• Производительные NAS и СХД. Используются как дисковый уровень для быстрого резервного копирования и восстановления.

• Enterprise-серверы. Dell PowerEdge R, HPE ProLiant DL, Lenovo ThinkSystem SR и аналогичные платформы поддерживают большие дисковые корзины, несколько процессоров, HBA, Fibre Channel и быстрые сетевые интерфейсы.

• Масштабируемые репозитории. Позволяют добавлять узлы и дисковые полки по мере роста данных.

• Объектные хранилища. Подходят для длительного retention и географически удалённых копий. Object Lock защищает версии от преждевременного удаления.

• Ленточные библиотеки. Используются для долгосрочного архива, WORM и физического air gap.

• Несколько media server. Распределяют нагрузку между площадками, виртуальными средами и СУБД.

В крупной инфраструктуре особенно важно разделить контуры управления. Backup-сервер, репозиторий, гипервизоры и рабочий домен не должны использовать одну административную учётную запись. Для критичных операций нужны MFA, отдельные роли и журналирование.

Вместо выводов

Резервируйте данные, друзья. Поверьте, вы скажете себе спасибо в будущем. Выбор сервера для резервирования — это как подготовка к важному экзамену: надеемся, что всё пройдёт гладко и вытянем лёгкий билет, но готовимся к самым сложным вариантам.

Правильный порядок такой:

1. Определить защищаемые системы и объём данных.

2. Зафиксировать RPO, RTO, retention и backup window.

3. Рассчитать полезную ёмкость и скорость восстановления.

4. Выбрать ПО и проверить его совместимость.

5. Разделить управляющую роль, обработку потоков и хранение там, где этого требует масштаб.

6. Реализовать правило 3-2-1-1-0.

7. Регулярно проверять целостность и проводить тестовое восстановление.

Сисадмины делятся на три типа: первый ещё не делает бэкапы, второй уже делает, а третий проверяет восстановление. Сам факт появления зелёной отметки «задание выполнено» ничего не гарантирует. Цель резервного копирования — не создать файл с копией, а вернуть бизнес-систему в работу за установленное время.