Dell PowerProtect DD как бэкап-репозиторий: выбор модели

Что именно нужно от бэкап-репозитория

Бэкап-репозиторий - это не просто «папка на диске». Это место, где резервные копии хранятся предсказуемо и безопасно: с понятной скоростью, контролем заполнения, защитой от ошибок и удобным восстановлением.

Проблема «обычного файлового шара» обычно не в том, что он плохой. Его просто никто не проектировал под ночные пики записи, долгий ретеншн и регулярные восстановления.

От хранилища бэкапов чаще всего хотят три вещи: скорость, срок хранения и надежность.

Скорость нужна, чтобы окно бэкапа укладывалось в ночь или выходные, а не «ползло» в рабочее время. Срок хранения - чтобы хватало места на нужный ретеншн (например, 30-90 дней ежедневных копий и несколько месячных). Надежность - чтобы восстановление не превращалось в лотерею, а отказ диска или контроллера не обнулял недели работы.

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

Поэтому при выборе модели важно смотреть не только на терабайты. Для Dell PowerProtect DD как бэкап-репозитория критичны два параметра: поток записи (ingest) и поток чтения на восстановление.

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

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

Термины, без которых легко ошибиться в выборе

Если вы рассматриваете Dell PowerProtect DD как бэкап-репозиторий, сначала договоритесь о терминах. Иначе один человек считает емкость, другой говорит про скорость, а в итоге покупают не то.

Типы бэкапов: что именно пишем каждую ночь

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

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

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

Скорость и время: поток и окно

Поток бэкапов - скорость, с которой данные должны записываться в репозиторий (TB/час или MB/с). Окно бэкапа - сколько часов у вас есть, чтобы уложиться в SLA.

Базовая связка простая: объем за ночь / окно = минимально нужный поток. Потом добавьте запас на «плохие дни»: больше изменений, повторные джобы, больше параллельных задач.

Ретеншн - сколько времени вы храните точки восстановления (14 дней, 30 дней, 12 недель и т.д.). Важно фиксировать не только срок, но и частоту: ежедневные, еженедельные и ежемесячные копии могут храниться по разным правилам.

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

Перед расчетом полезно коротко зафиксировать:

• где нужен полный, а где допустимы инкременты;
• сколько данных меняется в день (а не только общий объем);
• какое окно реально доступно по графику;
• за сколько часов нужно поднять ключевые сервисы.

Какие входные данные собрать перед расчетом

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

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

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

Мини-чеклист, который обычно хватает для старта:

• что бэкапим и сколько (ВМ, физика, БД, файлы);
• сколько данных защищаем сейчас и как быстро это растет;
• как часто делаем копии (полные, инкрементальные, логи) и сколько точек храним;
• какое окно бэкапа доступно и какие ограничения по сети между площадками;
• требования по RPO и RTO простыми словами.

RPO и RTO лучше записывать «человечески». Например: «можем потерять не больше 1 часа данных» и «сервис должен подняться за 4 часа». Это сразу влияет на частоту бэкапов, скорость записи и на то, какие проверки восстановления стоит включить в приемку.

Мини-пример для согласования цифр с владельцами систем: 80 ВМ и 6 физических серверов, 45 ТБ данных, рост 3% в месяц, ночное окно 8 часов, канал между площадками 300 Мбит/с, ежедневные копии плюс логи каждый час, ретеншн 30 дней. С таким набором входных данных уже можно честно считать поток и емкость, а не «выбирать модель на глаз».

Как посчитать требуемый поток бэкапов: пошагово

Поток бэкапов - это сколько данных в час (или в секунду) вы должны записать в репозиторий, чтобы уложиться в окно резервного копирования. Для Dell PowerProtect DD как бэкап-репозиторий этот расчет важнее, чем просто емкость: если не хватает производительности, бэкапы начнут «выползать» в рабочее время.

Шаги расчета

1. Соберите ежедневный объем изменений (change rate) по системам. Лучше брать цифры из отчетов бэкап-софта или статистики хранилищ, а не «на глаз». Отдельно отметьте базы данных, почту, VDI и файловые шары: у них разный профиль изменений.

2. Переведите объем изменений в требуемую скорость записи:

Поток (ТБ/ч) = Ежедневные изменения (ТБ) / Окно бэкапа (ч).

Если окно 10 часов, а изменений 6 ТБ, то базово нужно 0,6 ТБ/ч.

3. Учтите параллельность. Важно не только «сколько всего», но и сколько задач пишут одновременно, и какого они типа (полный, инкрементальный, синтетический полный).

4. Добавьте запас на пиковые дни. Чаще всего это еженедельные полные, ежемесячные закрытия, квартальные отчеты. Практично закладывать плюс 20-40% к расчетному потоку, а для «тяжелых» систем иметь отдельный коэффициент.

Что зафиксировать для сверки на приемке

Запишите в цифрах: окно бэкапа, суммарные изменения за сутки, максимальную параллельность, целевой суммарный поток записи и «пиковый» сценарий (например, полные бэкапы в выходные). Эти значения потом легко сравнить с фактическими метриками по job-ам и временем укладывания в окно.

Как прикинуть емкость под ретеншн и дедупликацию

Емкость в бэкап-репозитории часто «съедается» не одним большим полным бэкапом, а суммой точек восстановления за период ретеншна. Поэтому полезно мыслить не терабайтами «данных в проде», а количеством и размером restore point.

Дедупликация: почему она не одинаковая для всех

Коэффициент дедупликации и компрессии сильно зависит от типа данных и от того, как вы делаете бэкап.

ВМ и типовые файловые наборы часто дают хороший повтор блоков, особенно при ежедневных инкрементах. Базы данных ведут себя по-разному: влияет частота изменений и то, делаете ли вы бэкап на уровне образа или через агент. Архивы, медиа, зашифрованные или уже сжатые файлы (видео, ZIP, backup-цепочки другого продукта) почти не дедуплицируются. Это лучше закладывать отдельно.

Не пытайтесь «угадать» один красивый коэффициент на все. Разбейте источники на 3-4 группы по ожидаемой дедупликации и считайте емкость по ним раздельно.

Ретеншн: считать точки восстановления, а не только «объем в неделю»

Базовый расчет выглядит так:

1. определите размер полного бэкапа для каждой группы и средний дневной прирост;
2. задайте расписание (полный раз в неделю, инкремент каждый день, синтетика и т.п.);
3. посчитайте, сколько точек восстановления храните (например, 30 дневных и 12 недельных);
4. сложите «сырой» объем всех точек и только потом применяйте реалистичную дедупликацию.

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

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

Не планируйте «впритык». Заложите рост данных (например, на 12-18 месяцев) и технический запас 20-30% к расчетной полезной емкости, чтобы переживать пики и изменения в политике ретеншна.

Интеграция с бэкап-софтом и требования к сети

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

Обычно выбирают один из вариантов подключения:

• NFS/CIFS (сетевой каталог): просто стартовать, но чаще больше трафика идет «как есть», а нагрузка на бэкап-сервер выше.
• VTL (виртуальная библиотека): удобно, если процессы завязаны на «ленточную» логику, но важно проверить лимиты по числу потоков.
• Boost (интеграция на уровне приложения): обычно дает лучшую эффективность по сети и CPU, потому что оптимизации лучше согласованы с бэкап-софтом.

Способ интеграции влияет на фактический «полезный» поток. Например, при одинаковом расписании 20 параллельных задач через NFS могут упереться в CPU бэкап-сервера и сетевой интерфейс. Через Boost узкое место чаще смещается в диск и ресурсы самого DD, а по сети проходит меньше данных.

По сети ориентир простой: 10G часто хватает для небольших и средних окон бэкапа, 25G уместны при росте параллелизма и больших ежедневных инкрементах, 40/100G обычно нужны в крупных средах. Но «скорость порта» не равна «скорости бэкапа»: важны коммутаторы, MTU, очереди и то, где реально стоит узкое место.

Если есть возможность, разведите трафик. Бэкап-данные отдельно, администрирование и мониторинг отдельно. Так меньше шанс, что обновление или сбор логов неожиданно «съедят» полосу в окно бэкапа.

Для сценария на два ЦОДа заранее решите, будет ли репликация постоянной или «ночной». Проверьте требуемую полосу под ежедневный прирост, качество канала (задержку и потери), окна, когда репликация не должна мешать бэкапу, и где будут тестовые восстановления.

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

Модель удобнее выбирать по двум ограничениям: по потоку записи (ingest) и по полезной емкости под ретеншн.

Берете свои рассчитанные значения и смотрите, где упретесь раньше. Если по потоку - нужна модель «быстрее». Если по ретеншну - модель «больше». Практичный ориентир: держите запас 20-30% и по потоку, и по емкости, чтобы не жить на грани при росте, пиках и внеплановых полных бэкапах.

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

Смешанные нагрузки часто ломают простой расчет. Много мелких задач (файловые сервера, виртуалки с небольшими инкрементами) требуют высокой параллельности и стабильной производительности на коротких потоках. Несколько крупных задач (базы, большие файловые шары) требуют высокой пиковой скорости и достаточных сетевых портов. Поэтому смотрите не только на суммарные MB/s, но и на то, сколько задач идет одновременно.

Если нужно быстро свериться на встрече, помогает простая матрица:

• окно бэкапа не закрывается - приоритет ingest и лимиты по потокам;
• ретеншн не помещается - приоритет полезной емкости (и понимание, что именно считается usable);
• RTO важнее всего - приоритет чтения, параллельных восстановлений и сети;
• есть рост - заранее решите, как будете масштабироваться и что это значит для простоя;
• есть репликация/второй сайт - учитывайте дополнительный поток и окно репликации.

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

Типовые ошибки при подборе и закупке

Самая частая причина разочарования в Dell PowerProtect DD как бэкап-репозитории - неверные допущения на этапе расчета. Покупают модель «впритык» под средний день, а потом получают очереди, срывы окон бэкапа и медленные восстановления.

Чаще всего встречаются такие ошибки:

• считают только «обычный» день и забывают про пики (еженедельные полные, квартальные закрытия, массовые обновления, добавление новых серверов);
• держат на репозитории то, что по смыслу уже архив, и раздувают оперативный контур;
• ожидают «дедуп как у соседей» без замера на своих данных;
• меряют успех только скоростью записи и не проверяют реальное RTO на чтении;
• упираются в сеть (интерфейсы, MTU, коммутаторы, перегруз, нехватка параллельных потоков) и не замечают этого.

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

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

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

Обязательные проверки восстановления при приемке

Приемка PowerProtect DD как бэкап-репозитория - это не только «бэкап прошел». Важно доказать, что восстановление действительно работает, укладывается в RTO и повторяемо.

Набор тестов, без которых приемка неполная

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

Дальше сделайте выборочное восстановление файлов и объектов из разных дней ретеншна. Хороший тест - поднять один и тот же файл из «вчера», «недели назад» и «месяца назад», а также восстановить отдельный объект (почтовый ящик, таблица, объект в приложении), если ваш бэкап-софт это поддерживает.

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

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

Если предусмотрена репликация, нужен тест восстановления на второй площадке. Критерий простой: подтверждение актуальности реплики и восстановление именно из копии на удаленном DD. Для реалистичности задайте сценарий «основная площадка недоступна» и проверьте порядок действий.

Что оформить документально

Чтобы приемка не превратилась в спор «помню, что работало», заранее зафиксируйте артефакты:

• протоколы по каждому тесту (дата, сценарий, точка восстановления, результат, замечания);
• метрики (фактическое RTO, объем восстановленных данных, скорость, загрузка сети/хоста в пределах доступного);
• логи из бэкап-софта и PowerProtect DD, подтверждающие операции;
• матрица ответственности (кто запускает тесты, кто подтверждает работоспособность сервиса, кто подписывает акт).

Пример расчета и план приемки на простом сценарии

Сценарий: 200 ВМ и 2 базы данных. Окно ночного бэкапа 8 часов. Ретеншн 30 дней. Репозиторий - Dell PowerProtect DD.

Для прикидки важнее не общий размер, а ежедневные изменения (change rate). Допустим, средний размер ВМ 150 ГБ, но меняется в среднем 3% в сутки. Базы по 2 ТБ каждая, изменения 5% в сутки.

Оценка потока:

• ВМ: 200 x 150 ГБ x 3% = 900 ГБ изменений в сутки.
• Базы: 2 x 2 ТБ x 5% = 200 ГБ изменений в сутки.
• Итого: около 1,1 ТБ данных на запись в сутки.
• Поток на окно 8 часов: 1,1 ТБ / 8 ч = примерно 140 ГБ/ч, или около 40 МБ/с средний.

Дальше учтите пики и накладные расходы. На практике минимум часто приходится умножать на 2-3, чтобы переживать «плохие ночи». В этом примере целевой ориентир по записи получается 80-120 МБ/с.

Затем проверьте, что выбранная модель выдержит не только среднее, но и пик: еженедельные full, параллельные задачи, пересчет синтетики, внутренние операции. Полезно заложить запас по потоку 30-50% и рост данных на год 20-30%. Если сегодня нужен пик 120 МБ/с, на год планируйте 150-180 МБ/с.

По ретеншну важно помнить: 30 дней не равны 30 ТБ. При дедупликации и компрессии итоговая емкость зависит от типа данных и схемы (incremental forever, weekly full и т.д.). Поэтому на приемке стоит подтвердить не только скорость, но и реальный коэффициент сокращения на ваших данных.

В обязательную приемку добавьте как минимум три восстановления:

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

Результат считается приемлемым, если восстановление идет без ошибок, RTO укладывается в требования, а скорости не деградируют в разы при типичных сценариях (например, одновременное восстановление плюс ночной бэкап).

Следующие шаги: что сделать до закупки и после установки

Когда вы выбираете Dell PowerProtect DD как бэкап-репозиторий, заранее зафиксируйте не только цифры для расчета, но и то, как вы будете доказывать, что система действительно восстанавливает данные в нужные сроки.

До закупки

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

Короткий набор того, что стоит подготовить: change rate по ключевым системам, размер полных и инкрементальных копий, окно бэкапа; ретеншн по типам данных и требования RPO/RTO; ожидаемый рост и план расширения; ограничения по размещению (питание, стойки, охлаждение); список интеграций (каким софтом бэкапите, какие протоколы и режимы нужны, где будет каталог и управление).

Отдельно заранее согласуйте сеть и способ подключения. Частая причина «не тянет поток» - не модель, а неподготовленные порты, VLAN, MTU, разная скорость на участках или неверно выбранный режим интеграции.

После установки

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

Минимальный рабочий набор: тест восстановления файла, VM и базы (по одному реальному примеру) с замером времени до доступности; контроль целостности (встроенные проверки и отчеты без «красных» статусов); прогон бэкапа в пиковом окне и параллельное восстановление хотя бы 1-2 заданий; проверка ретеншна на практике (удаление точек, прогноз заполнения, защита от внезапного «съедания» емкости); операционные процедуры (кто реагирует на алерты, как часто делаете тестовые restore, где храните протоколы).

Простой подход, который дисциплинирует: еженедельный плановый restore для 1-2 критичных сервисов и ежемесячный расширенный тест для одного приоритетного контура, с фиксированными RTO/RPO.

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