В этой статье я поделюсь практическим опытом оптимизации производительности и защищенности систем резервного копирования (СРК). Многие наши клиенты задумываются о том, как построить архитектуру корпоративных бэкапов и при этом оптимизировать затраты. Мы рассмотрим архитектурные особенности системы, поговорим о тонкостях настройки дедупликации, обсудим безопасность резервных копий и проанализируем актуальные решения на российском рынке. Материал основан на реальном опыте внедрений и будет полезен как техническим специалистам, так и руководителям ИТ-подразделений.
Особое внимание уделим балансу между производительностью, надежностью и стоимостью владения — трем китам, на которых держится эффективная система резервного копирования. Разберем типичные ошибки, с которыми мы сталкиваемся при проектировании систем, и покажем, как их избежать.
Меня зовут Алексей Зотов, я руковожу направлением ИТ-инфраструктуры в К2Тех. За плечами — более 15 лет работы с системами резервного копирования: от небольших инфраструктур до комплексов на тысячи хостов и петабайты данных. Моя команда, специалисты которой в среднем имеют 7–8 лет опыта, ежегодно проектирует, внедряет и поддерживает СРК для десятков заказчиков, а всего — уже для сотен.
В предыдущей статье мы рассмотрели влияние архитектуры резервного копирования на производительность системы. Напомню, что она состоит из трех ключевых компонентов: управляющего сервера, медиасервера и клиента. Каждый из них может стать узким местом и значительно снизить общую производительность.
Давайте детальнее рассмотрим каждый компонент. Управляющий сервер (его также называют primary server, master server или узел управления) содержит базу данных со всей конфигурацией, политиками, расписаниями и исторической информацией. Медиасерверы принимают данные от конечных клиентов и записывают их на подключенные устройства хранения. Клиентский уровень включает различные типы агентов для файловых систем, баз данных, приложений и виртуальных машин.
Даже если вы установите высокопроизводительные медиасерверы и внедрите современные системы хранения данных, медленный или перегруженный клиент не сможет обеспечить достаточную скорость передачи данных. В этом случае инвестиции в дорогостоящее оборудование не принесут желаемого результата — один высокопроизводительный компонент не способен компенсировать ограничения остальных элементов системы. Необходимо смотреть на архитектуру в комплексе, иначе узкое горлышко в любом месте приведет к проблемам во всем процессе.
Проблемы с производительностью могут возникнуть не только на уровне клиента — узким местом часто становятся системы хранения, каналы передачи данных и даже модули шифрования.
В нынешних реалиях заказчики существенно изменили подход к выбору решений для резервного копирования. На первый план вышли два фундаментальных требования технического характера:
Прежде всего, платформа должна обеспечивать комплексную защиту существующей инфраструктуры. Решение становится своеобразным защитным зонтиком, который покрывает весь спектр используемых технологий – от виртуальных машин до специализированных приложений.
Соответствие архитектурным требованиям заказчика. Ему важна поддержка всего стека технологий резервного копирования: работа с различными типами накопителей (диски, ленточные библиотеки), интеграция с облачными хранилищами, дедупликация и репликация данных, возможности построения распределенной инфраструктуры с несколькими центрами обработки данных.
Дополнительные критерии включают удобство использования. Характерный пример из прошлого — решение IBM TSM / Spectrum Protect, чей консольный интерфейс традиционно вызывал нарекания у администраторов. Также значимы качество технической документации и экономическая эффективность решения.
Однако экономия на отдельных компонентах, к которой подталкивает рыночная ситуация, приводит к общему снижению производительности всей инфраструктуры. Залог эффективности системы резервного копирования – сбалансированная архитектура.
Из практического опыта. Часто встречаю попытки оптимизировать бюджет за счет применения дисков сверхвысокой емкости (18–20 ТБ). На первый взгляд большие и емкие HDD кажутся привлекательными, но небольшое количество физических накопителей существенно ограничивает производительность дисковой подсистемы в целом. А восстановление после отказа такого емкого накопителя может занять вплоть до нескольких недель. Причем в течение всего периода ребилда производительность системы хранения будет существенно снижена, что повлияет еще и на скорость создания новых резервных копий.
Мы рекомендуем при проектировании дисковых систем хранения использовать накопители емкостью не более 10–12 терабайт. Это обеспечивает оптимальный баланс между производительностью, надежностью и стоимостью владения. При таком подходе время восстановления после сбоя существенно сокращается, а общая производительность системы остается на приемлемом уровне даже при выходе из строя одного из дисков.
Дедупликация: хороший способ снизить цену дисков
С точки зрения скорости резервного копирования сильно помогает использование дедупликации. Она позволяет сжимать бэкапы за счет разбиения данных на блоки фиксированной или переменной длины, сохраняя только уникальные. При этом правильная дедупликация — глобальная, которая учитывает в едином пуле абсолютно все блоки по всем сессиям резервного копирования, независимо от типа клиента.
Система анализирует эти блоки и при обнаружении идентичных сохраняет только одну копию, что особенно эффективно при резервном копировании однотипных систем. В результате мы наблюдаем впечатляющие показатели сжатия — до 25:1, что позволяет сократить требования к дисковому пространству в 20–25 раз.
Раньше на российском рынке доминировали Dell EMC DataDomain и HPE StoreOnce, которые обеспечивали высокую производительность за счет оптимизированного под дедупликацию железа. Сейчас им на смену пришло Yadro с их Tatlin.Backup.
Программную дедупликацию в той или иной степени поддерживают все основные решения на российском рынке: «Кибер Бэкап», RuBackup, Vinchin Backup & Recovery и Aishu AnyBackup. Однако важно понимать, что дедупликация требует значительных вычислительных ресурсов. Для эффективной работы необходимы большие объемы оперативной памяти и процессорной мощности. Это особенно критично при использовании дедупликации на уровне клиентских систем — до передачи данных на медиасервер.
Дедупликация на клиентской стороне может быть эффективна при резервном копировании в нерабочее время, когда основные бизнес-процессы не загружают системные ресурсы. Предварительная дедупликация помогает рационально использовать каналы передачи данных, что критично при ограниченном временном окне для резервного копирования.
Наиболее эффективна дедупликация на медиасерверах или устройствах хранения. Она ускоряет сжатие данных между ЦОДами и филиалами, упрощает создание дополнительных копий.
При проектировании системы бэкапа важно правильно настроить параллельную обработку данных. Наш опыт показывает, что мультипоточность заметно повышает скорость бэкапа, если каналы и устройства хранения вывозят дополнительную нагрузку. Успех здесь целиком зависит от грамотного планирования расписания и мониторинга нагрузки.
Защита бэкапов: проще сказать, чем сделать
За последние годы характер угроз резервным копиям кардинально изменился. По нашим наблюдениям, если раньше основную опасность представляли автоматизированные атаки программ-шифровальщиков, то сейчас мы сталкиваемся с целенаправленными, хорошо спланированными действиями злоумышленников.
Эта тенденция привела к значительным изменениям в индустрии. Отвечая на запрос рынка, производители стали массово развивать решения для Linux, также появились инновационные продукты наподобие ExaGrid с изолированными зонами хранения (landing zone) для противодействия подобным атакам.
Сейчас эти защитные меры теряют актуальность. Мы наблюдаем все больше сложных сценариев атак: киберпреступники получают доступ к консоли управления резервным копированием, целенаправленно уничтожают резервные копии, монтируют носители данных и форматируют их.
Поэтому наиболее эффективным методом защиты становится физическая изоляция резервных копий — air gap. Злоумышленникам становится гораздо сложнее удалить данные, когда кассета лежит в сейфе. В качестве дополнительного уровня защиты может использоваться выделенный сервер резервного копирования, физически изолированный от корпоративной сети.
В базовых мерах безопасности важно не только правильно настроить операционную систему, но и грамотно организовать сетевое взаимодействие. Часто встречаемая ошибка — открытие всех портов «на всякий случай», что значительно увеличивает риски. Вместо этого следует внедрить динамическое управление портами, чтобы файрволы открывали только те из них, которые реально нужны для текущего взаимодействия с агентами. А сетевой доступ к ОС и интерфейсу управления должен быть ограничен, например, через выделенный jump-сервер или терминальный сервер, что поможет предотвратить несанкционированный доступ.
Также рекомендуется использовать стандартные практики ИБ:
- антивирусное ПО для всех компонентов СРК с настройкой исключений по лучшим практикам;
- SIEM системы для мониторинга как операционной системы, так и сервисов СРК;
- использование «взломо-стойких» паролей для УЗ;
- использование ролевых моделей моделей с четким разграничением прав доступа.
Дополнительно не стоит забывать и о встроенных механизмах защиты в систему резервного копирования: многие системы позволяют настроить автоматическое завершение неактивных сессий, уведомления о последнем входе текущего пользователя и пересылку журналов аудита на внешний syslog сервер.
Для облачных копий желательно использовать Retention Lock — технологию неизменяемого хранения данных. На практике это выглядит так: при записи бэкапа устанавливается фиксированный период хранения. В течение этого периода даже администратор с максимальными правами не может ни удалить данные, ни сократить срок их хранения. При попытке удаления система просто вернет ошибку 404.
А вот шифрование резервных копий часто создает больше проблем, чем решает. По требованиям российского законодательства системы шифрования должны иметь сертификат ФСБ. Многие западные решения для резервного копирования, включая NetBackup, такой сертификации не имеют. Они больше ориентированы на международные стандарты безопасности. При этом отечественные разработчики, например, создатели «Кибер Бэкапа», уже активно работают в этом направлении.
К сожалению, дополнительный слой криптографической защиты в любом случае существенно увеличивает нагрузку на вычислительные ресурсы, требует больше оперативной памяти и процессорного времени. В результате заметно снижается скорость как создания резервных копий, так и восстановления данных. При этом шифрование не защищает данные от уничтожения.
В качестве дополнительного уровня защиты мы рекомендуем развертывание систем обнаружения вторжений (IDS). В нашей практике большинство успешных атак на системы резервного копирования начинались с компрометации контроллеров домена или других критических систем. IDS позволяет выявить такую активность на ранних стадиях.
Ну и, конечно, нужно защищаться от человеческого фактора. Даже в банках большинство инцидентов связано именно с действиями или бездействием сотрудников: некорректное конфигурирование резервного копирования, пропуск важных компонентов защиты, оставленные открытыми сетевые порты. Из нашей практики: однажды при проведении регламентных работ на SAP-системе заказчика администраторы отключили резервное копирование и потом забыли включить его обратно. Как назло, в период, когда бэкапы не создавались, система вышла из строя. К счастью, сохранились предыдущие резервные копии на ленточных носителях. Нам удалось восстановить данные, импортировав их обратно в систему резервного копирования, но так везет далеко не всегда. Обычно подобные инциденты приводят к полной потере данных.
В этом контексте даже самые продвинутые технические решения не гарантируют защиты. Наиболее эффективным подходом остается внедрение строгих регламентов работы и четко документированных процедур обеспечения безопасности. Важно регулярно проводить аудит соблюдения этих процедур и обучение персонала.
Мы живем в эпоху стремительных изменений на российском рынке резервного копирования.
Однако базовые принципы остаются неизменными: производительность системы определяется ее самым слабым звеном, будь то клиент, медиасервер или система хранения. На практике мы часто видим, как заказчики инвестируют значительные средства в высокопроизводительные системы хранения, но забывают о необходимости обеспечить достаточную пропускную способность сети или оптимизировать настройки клиентских агентов. Из нашего опыта внедрений могу выделить три ключевых фактора успеха:
1. Комплексный подход к архитектуре:
тщательное планирование окон резервного копирования;
оптимизация параллельных потоков данных;
правильный выбор размера накопителей (не более 10-12 ТБ для оптимального баланса производительности);
грамотное использование дедупликации.
2. Многоуровневая система безопасности:
физическая изоляция критичных копий (air gap);
использование retention lock для облачных копий;
строгий контроль учетных записей и сетевых портов;
внедрение IDS для раннего обнаружения угроз.
3. Стратегический подход к выбору ПО для резервного копирования:
оценка российских решений («Кибер Бэкап», RuBackup, «Береста») и альтернатив из дружественных стран (Vinchin, Aishu);
учет особенностей технической поддержки и локализации;
возможности интеграции с существующей инфраструктурой.
Успешность проекта часто определяется не только техническими характеристиками, но и качеством его внедрения, оптимизации и поддержки. Инвестируйте время в тщательное планирование и тестирование — это всегда окупается.
Буду рад обсудить ваш опыт в комментариях. Какие подходы к оптимизации производительности бэкапов используете вы? С какими проблемами сталкиваетесь при миграции на новые решения?
P.S. Если у вас остались вопросы по конкретным аспектам настройки систем резервного копирования, пишите в комментариях. Постараюсь подробно ответить, опираясь на наш практический опыт.
