Сервер для бэкап-репозитория: CPU, RAM, диски и restore

Почему надо считать restore, а не только backup

Скорость backup и скорость restore - это разные вещи. Backup похож на «сбор мусора в мешки»: данные можно записывать постепенно, очередями, ночью и с повторами. Restore - это «вернуть все на место прямо сейчас», часто под давлением: система упала, пользователи ждут, бизнес стоит.

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

Чтобы планирование было предметным, обсуждают не «терабайты» и «окно бэкапа», а измеримые цели:

• RTO: за сколько минут или часов сервис должен заработать.
• Скорость restore на одну задачу (МБ/с, ГБ/мин) и суммарно.
• Сколько восстановлений нужно тянуть параллельно (например, 1, 5 или 20).
• Сколько занимает восстановление самого критичного узла (БД, контроллер домена).

На практике restore почти всегда тормозит по комбинации причин: дискам не хватает IOPS, CPU не успевает разжимать и собирать данные, RAM не держит кэш, сеть становится узким местом, а формат хранения добавляет накладные расходы (длинные цепочки инкрементов, шифрование, проверки целостности).

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

Как дедупликация и компрессия нагружают сервер

Дедупликация и компрессия выглядят как простой способ «уменьшить бэкап», но для сервера это всегда вычисления, память и дополнительные операции с диском.

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

Где именно выполняются расчеты

Важно заранее понять, где будет происходить обработка и кто заплатит за нее ресурсами:

• На источнике (агент/клиент). Нагрузка уходит на защищаемый сервер, по сети летит меньше данных.
• На прокси. Источники «дышат» свободнее, но прокси нужен сильный CPU и достаточная RAM.
• На репозитории. Инфраструктура проще, но сам сервер должен тянуть и прием, и обработку, и выдачу данных при восстановлении.

Почему backup может стать быстрее, а restore медленнее

Дедуп и компрессия часто ускоряют backup: по сети и на диск пишется меньше. Но restore может замедлиться, потому что данные нужно «собрать» из фрагментов, разжать и проверить. Если упираетесь в CPU, RAM (кэш метаданных) или случайные чтения с дисков, восстановление будет идти рывками.

Пример: офис из 200 ПК ежедневно сохраняет похожие профили и документы. Бэкап получается компактным. Но при аварии, когда нужно поднять десятки рабочих мест за час, репозиторию приходится параллельно разжимать и собирать много потоков данных. Слабый процессор или медленный массив начинают тормозить именно restore.

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

Подбор CPU под дедупликацию, компрессию и восстановление

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

Частота на ядро важнее, чем кажется

Для restore часто критична производительность одного ядра. Восстановление одной крупной ВМ или базы данных нередко упирается в последовательные операции (поиск, сборка, распаковка). Тут высокая частота и современная архитектура дают больше, чем просто «побольше ядер».

Больше ядер выгодно, когда идет много задач одновременно: несколько restore, параллельно ночной backup, синтетические full, проверки целостности. Тогда нагрузка распараллеливается, и дополнительные ядра превращаются в реальную скорость.

Практичное правило: если RTO подразумевает массовое восстановление после инцидента, закладывайте запас по CPU, а не «впритык под ночное окно». Иначе в день аварии вы упретесь в процессор даже при нормальных дисках.

Шифрование и пиковый restore

Шифрование резко поднимает требования к CPU, особенно если оно включено вместе с дедупликацией и компрессией. Проверяйте аппаратное ускорение и реальную производительность на распаковку плюс расшифровку.

В обычный день вы восстанавливаете один файл - и все быстро. В день инцидента нужно поднять 20 ВМ, каждая требует параллельного чтения, распаковки и сборки. Если CPU держится на 90-100%, скорость становится «пилой», а RTO срывается.

Перед покупкой полезен короткий прогон: 3-5 задач restore одновременно плюс фоновые операции. По графикам CPU быстро видно, где закончится запас.

Сколько RAM нужно репозиторию и почему это влияет на restore

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

Если RAM не хватает, restore превращается в «прыжки» по хранилищу: метаданные и блоки не помещаются в кэш, и система снова и снова читает их с диска. На дедуплицированных репозиториях это особенно заметно: один виртуальный диск может собираться из множества кусочков, и без кэша каждый кусочек становится отдельной операцией ввода-вывода.

Оценивать память лучше от активного набора и параллельности:

• Активный набор: какие точки восстановления вы реально будете чаще читать (например, последние 7-14 дней).
• Параллельность: сколько одновременных restore-потоков нужно в час пик.
• Дедупликация: чем «тоньше» (на уровне блоков), тем выше требования к RAM.
• Запас под ОС и сервисы: не планируйте память «в ноль», иначе кэш будет постоянно вымываться.

SSD-кеш иногда помогает при случайных чтениях, но не заменяет RAM. Он ускорит промахи кэша, но не уберет проблему, если индексы и метаданные не помещаются в памяти. Часто добавление RAM дает более ровную скорость restore, чем добавление еще пары дисков.

Признаки, что вы уперлись в память: резкие провалы скорости восстановления, рост задержек диска при чтении и активная подкачка, даже если CPU не загружен. Например, при восстановлении двух ВМ скорость «плавает», а при добавлении третьей падает почти до нуля.

Диски, RAID и контроллер: как собрать быстрый репозиторий

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

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

HDD vs SSD: где экономить, а где нельзя

Ориентируйтесь на latency и IOPS, а не только на гигабайты в секунду. Для последовательного backup HDD могут быть «нормальными», но при restore из дедуплицированного репозитория чтение становится более случайным.

Рабочий компромисс: SSD под метаданные и активный набор, HDD под объем.

RAID, контроллер и предсказуемый restore

RAID выбирайте под чтение и стабильную задержку:

• RAID10 обычно дает самый предсказуемый restore, но дороже по емкости.
• RAID6 часто удобен для объема на HDD, но восстановление и ребилд могут заметно просаживать скорость.

По контроллеру важнее не «самый дорогой», а подходящий режим. Для программных хранилищ часто лучше HBA (IT) и надежные диски. Если используете аппаратный RAID, кэш контроллера с защитой помогает при записи, но restore чаще упирается в чтение и задержки.

Пример: репозиторий на RAID6 из HDD, и внезапно нужно поднять 10 ВМ параллельно. Ночной backup был быстрым, а днем restore начинает «дергаться» из-за случайных чтений и фоновой деградации массива. Небольшой SSD-слой под метаданные и «горячие» бэкапы часто дает больший эффект, чем добавление еще одного шкафа HDD.

Что именно тормозит restore на практике

Restore почти всегда сложнее, чем backup. При записи данные идут длинным потоком и хорошо ложатся на диски. При восстановлении чтение часто становится хаотичным: система дергает множество небольших блоков, и время уходит в задержки.

Один из частых виновников - цепочки инкрементальных копий. Чтобы собрать «последнее состояние» ВМ или файлового сервера, ПО читает базовый full и много инкрементов. Даже при умеренном объеме число обращений к хранилищу растет, и восстановление растягивается.

Дедупликация и компрессия тоже меняют картину: данные раскладываются по «уникальным» кусочкам. На restore это оборачивается большим числом мелких чтений и дополнительной работой CPU на распаковку и сборку.

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

Если вам важен прогнозируемый RTO и restore случается часто, иногда помогает разделение ролей: один узел хранит данные, другой выполняет «тяжелую» обработку (дедупликация, компрессия, сборка).

Сеть и скорость восстановления: как не упереться в канал

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

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

Выбор 10/25/40/100G проще всего привязать к расчету: сколько терабайт нужно вернуть и за сколько часов. Пример: восстановить 8 ТБ за 4 часа - это около 4,4 Гбит/с чистых данных. С накладными расходами лучше иметь запас и смотреть в сторону 10G или 25G, а не надеяться на 1G.

Если в аварийное окно вы поднимаете много ВМ и баз, отдельная сеть под backup и отдельная под продуктивный трафик часто спасают от взаимного влияния.

Пошаговый расчет: от RTO к CPU, RAM и дискам

Начинайте не с емкости, а с того, как быстро вы должны поднять сервис после сбоя. Сервер может делать быстрый backup, но провалить восстановление.

Сначала опишите 2-3 реальных сценария restore. Обычно это: одна критичная ВМ, восстановление базы данных и массовый инцидент (например, пачка ВМ после шифровальщика). Для каждого сценария зафиксируйте RTO и переведите его в требуемую скорость. Например, 2 ТБ за 4 часа - это около 140 МБ/с полезных данных. С учетом накладных расходов лучше целиться ближе к 200+ МБ/с.

Дальше оцените параллельность. Если нужно поднимать 4 ВМ одновременно, скорость и IOPS требуются суммарно, а не «на одну задачу».

Дальше логика простая: считайте CPU под дедупликацию, компрессию, шифрование и распаковку (с запасом, чтобы скорость не «пилила»), подбирайте диски под пропускную способность и IOPS, и отдельно проверяйте контроллер и настройки массива.

Финальный шаг всегда один - пробный restore. Прогоните восстановление типовой ВМ и тяжелого набора файлов, измерьте фактические МБ/с, загрузку CPU и очередь диска. Если CPU держится у потолка или диски постоянно в очереди, запас уже закончился.

Пример сценария: емкость vs быстрый restore

Допустим, у организации 60 ВМ и 10 физических серверов. Ежедневный прирост - около 2 ТБ, полные бэкапы раз в неделю, окно backup - 10 часов ночью. Цель: восстановить 2 критичные системы (например, AD и базу учетной системы) за 2 часа, а все остальное поднять в течение суток.

Если смотреть только на backup, часто выбирают много HDD и успокаиваются. Но restore обычно читает более «неудобно», чем пишет backup: мелкими блоками, параллельно, в рабочее время. Поэтому репозиторий стоит выбирать от сценария чтения.

Компрессия экономит место, но добавляет нагрузку на CPU при записи и при восстановлении. Шифрование еще сильнее упирается в CPU и может «съесть» ваши 2 часа даже при быстрых дисках.

Если нужен упор в емкость, обычно берут большой HDD-массив (часто RAID6) и смиряются с тем, что массовое восстановление не будет быстрым. Если нужен упор в restore, чаще выигрывает гибрид: HDD под объем плюс SSD под метаданные и активный набор, больше RAM под кэш и более сильный CPU под обработку.

Перед покупкой решает короткий тест на реальных данных: восстановите те самые 2 системы и замерьте устойчивую скорость (не пик), загрузку CPU, задержки чтения на дисках и то, упираетесь ли вы в сеть.

Частые ошибки при выборе сервера под бэкап-репозиторий

Чаще всего сервер подбирают по объему, а не по скорости восстановления. В итоге бэкапы пишутся ночью, но любое массовое восстановление днем тянется часами.

Еще одна ловушка - «много дисков = быстро». Большой массив из емких HDD без расчета IOPS и задержек почти гарантированно упрется в случайное чтение, особенно при дедупликации и параллельном restore.

CPU тоже часто недооценивают. Дедупликация, компрессия и шифрование могут съесть процессор одновременно, и скорость восстановления падает даже при хорошем дисковом массиве.

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

Короткий чеклист перед покупкой и тестом restore

Перед закупкой зафиксируйте самое важное:

• RTO и приоритеты: что должно подняться первым, что может подождать.
• Сколько restore задач должно идти параллельно в худший день.
• Какая скорость восстановления нужна на одну задачу и суммарно.

Дальше проверьте «узкие места» на пилоте с реальными настройками (включая дедупликацию, компрессию и шифрование, если вы планируете их использовать): CPU, RAM (нет ли постоянного swap), задержки чтения и очередь диска, реальную пропускную способность сети в рабочее время.

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

Следующие шаги: пилот, измерения и выбор поставщика

Начните с исходных данных. Один и тот же сервер может показать отличный backup, но провалить восстановление, если цель по RTO не задана и реальный restore не измерен.

Соберите вводные на одной странице: объем данных под защитой и прирост, типы нагрузок (VM, базы, файлы), целевое RTO и список критичных сервисов, окно backup, ограничения площадки и план роста на 1-3 года. Затем запланируйте пилот: протестируйте не только запись, но и разные варианты восстановления (одна крупная ВМ, много мелких файлов, восстановление на другую площадку).

Если вы выбираете железо и интеграцию у локального производителя, имеет смысл просить конфигурацию под ваши цифры RTO и параллельность. Например, GSE.kz (gse.kz) как производитель и системный интегратор может собрать серверную конфигурацию под сценарии восстановления и обеспечить поддержку 24/7 через сервисную сеть.

Фиксируйте результаты пилота цифрами (скорость restore, время до готовности сервиса, загрузка ресурсов) и уже по ним утверждайте конфигурацию: серверы, дисковую подсистему, сеть и интеграцию с вашим ПО бэкапа.