Как выбрать сервер для бэкапов: архитектура PBBA, SOBR и сайзинг backup-узла

Почему сервер для бэкапов — это не просто файловое хранилище

В небольших инфраструктурах резервные копии иногда складывают на обычный сервер с большим объемом дисков. Такой подход может работать для простых задач, но он плохо масштабируется и часто не учитывает реальные требования восстановления. Проблемы проявляются не в день обычного копирования, а в момент аварии, массового удаления данных, отказа массива или ransomware-атаки.

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

RPO и RTO: от них начинается расчет backup-сервера

RPO показывает, сколько данных компания готова потерять между последней резервной копией и аварией. RTO показывает, за какое время систему нужно вернуть в рабочее состояние. Эти показатели напрямую влияют на архитектуру backup-узла: частоту заданий, объем инкрементов, скорость записи, число параллельных потоков, сетевые интерфейсы и производительность дисков.

Если RPO жесткий, backup-сервер должен стабильно принимать частые инкременты и не создавать очередь заданий. Если RTO жесткий, важна не только запись копий, но и скорость чтения при восстановлении: репозиторий должен отдавать данные достаточно быстро, чтобы восстановление виртуальных машин, баз данных или файловых сервисов не растянулось на сутки.

PBBA и SOBR: когда нужен не один сервер, а масштабируемая backup-архитектура

В простом сценарии backup-сервер может совмещать роль управляющего узла и репозитория. В более зрелой инфраструктуре эти роли разделяют: управляющий сервер, proxy-узлы, репозитории, immutable-хранилище, offsite-копии и отдельный контур восстановления. Для крупных объемов данных может потребоваться подход PBBA или масштабируемый репозиторий.

PBBA-подход означает, что узел резервного копирования проектируется как специализированный аппаратно-программный комплекс под задачу backup и recovery. SOBR-подход позволяет объединять несколько репозиториев в масштабируемую архитектуру, где емкость и производительность можно наращивать по мере роста данных.

Выбор между одним сервером, несколькими репозиториями, СХД, NAS, объектным хранилищем или специализированным appliance зависит от масштаба инфраструктуры, ПО резервного копирования, требований к RPO/RTO, бюджета, offsite-стратегии и требований безопасности.

CPU и RAM: почему backup-серверу нужны вычислительные ресурсы

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

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

Дисковая подсистема: емкость, RAID и профиль ввода-вывода

Backup-нагрузка часто отличается от нагрузки баз данных или виртуализации. Для репозитория важны последовательная запись, стабильное чтение при восстановлении, нормальная работа RAID, предсказуемое поведение при отказе диска и возможность расширения емкости. При этом нельзя забывать о проверке целостности, синтетических full backup, merge-операциях и периодических заданиях обслуживания.

HDD остаются частым выбором для емких backup-репозиториев, но их нужно правильно объединять в RAID и учитывать время rebuild. SSD или NVMe могут использоваться для метаданных, кэша, высокоскоростных репозиториев, staging-зон или сценариев, где восстановление должно быть максимально быстрым.

Сеть: backup-узел должен успевать принимать и отдавать данные

Сетевые интерфейсы backup-сервера должны соответствовать объему данных и окну резервного копирования. Если несколько серверов, гипервизоров или СХД одновременно отправляют инкременты, один гигабитный интерфейс может стать жестким ограничением. Для корпоративных задач часто рассматривают 10G, 25G, агрегацию портов или отдельный backup-контур.

При проектировании нужно учитывать не только порт на сервере, но и коммутатор, SFP/DAC-кабели, VLAN, маршрутизацию, сетевую изоляцию, MTU, пропускную способность источников данных и скорость восстановления обратно в продуктивную инфраструктуру.

Для подбора сетевой части используйте раздел «Сетевое оборудование», а если backup-сервер связан с отдельной системой хранения, проверьте также хранилища данных и СХД.

WORM, immutability и защита резервных копий от удаления

Резервная копия не защищает бизнес, если злоумышленник может удалить или зашифровать ее вместе с основной инфраструктурой. Поэтому для backup-архитектуры важно проектировать отдельные учетные записи, изолированный доступ, immutable-репозитории, WORM-механизмы, offsite-копии и регламенты восстановления.

Immutability и WORM не отменяют резервное копирование, но снижают риск изменения или удаления копий в течение заданного периода. Конкретная реализация зависит от ПО резервного копирования, файловой системы, хранилища, appliance, облачного или объектного уровня, политики безопасности и требований компании.

Какие данные подготовить для подбора сервера резервного копирования

Чтобы корректно подобрать сервер для бэкапов, специалисту нужны исходные данные: объем защищаемых данных, типы систем, RPO/RTO, глубина хранения, ежедневный прирост, ПО резервного копирования, количество потоков, сеть, требования к восстановлению, offsite-копии, защита от удаления и бюджет.

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