Свежие кейсы в поле информационной безопасности показывают: даже крупные компании могут совершать такие ошибки в выстраивании системы резервного копирования, что их сервисы не работают по несколько дней после аварии. Бэкапы данных — критический элемент в обеспечении непрерывности бизнеса для любого предприятия. Однако традиционно на отечественных предприятиях они выполняются по остаточному принципу. У сисадмина сервиса много повседневных задач, за которые спросят уже сейчас, а постановка на централизованное бэкапирование даже важных сервисов, особенно в зрелых средах, может отсутствовать. Ведь кажется сложным вначале идти по заведённой процедуре, согласовывая действия со всеми сторонами, а затем впихивать это все в имеющееся расписание, переписывая его параметры в политиках и СРК-агентах. Проще сделать бэкап «на коленке» и восстановить его на свое «личное» пространство.
Меня зовут Михаил Старцев, я — пресейл-инженер по резервному копированию «Тринити». В этой статье я выскажу предположение о том, что привело к такой традиции, а затем расскажу о поэтапном развёртывании резервного копирования на предприятии с нуля, снабдив текст практическими рекомендациями, которые помогут в успешной реализации этого процесса.
Почему все не любят делать бэкапы и зачем они вообще нужны
Так уж сложилось исторически, что когда в конце 90-х и начале 2000-х российское ИТ проходило стадию создания, многим было не до централизации. Позже в 2010-х, когда был накоплен опыт, появились технологии, а также вера в себя, на создание резервного копирования было жалко денег. А у кого-то их и вовсе не было по причине сильно разросшегося ИТ и хороших аппетитов мировых вендоров. Поэтому довольно часто можно было встретить использование пиратского софта или скриптов. В настоящее же время ситуация стала меняться, но нынешнее российское ИТ из-за санкций словно откатилось в те самые ламповые 90-е и начало 2000-х. Цикл истории, похоже, снова идёт на новый оборот… А вы как считаете?
Однако резервное копирование помогает не потерять бизнес и не понести значительные убытки от простоя предприятия. Бэкапирование помогает обеспечить сохранность информации в случае непредвиденных событий (аварий, кибератак, сбоев в системе, ошибок пользователей и пр.). Регулярное создание резервных копий помогает минимизировать потери данных и сокращает время восстановления системы после инцидентов. Таким образом, резервное копирование способствует обеспечению непрерывности бизнес-процессов и защите информации от потери, утечек и уничтожения.
Пошаговое развёртывание резервного копирования
Резервирование данных на предприятии осуществляется в пять этапов:
Понимание требований к резервному копированию.
Анализ потребностей предприятия и угроз безопасности информации, анализа SLA.
Проектирование системы и настройка ИТ-инфраструктуры.
Тестирование и оптимизация системы.
Обучение и поддержка персонала.
Шаг 1: требования к резервному копированию
Перед тем, как приступить к развёртыванию резервного копирования, необходимо провести тщательный анализ потребностей и требований бизнеса. Это включает в себя:
составление модели угроз ИТ-безопасности для ИТ-систем предприятия;
определение объёма данных, подлежащих резервному копированию;
определение частоты и глубины резервного копирования;
оценку уровня критичности данных и их влияния на бизнес-процессы;
установление требований к восстановлению данных (RTO и RPO);
определение доступных бюджетных ресурсов и инфраструктуры.
На мой взгляд, чтобы выбрать максимально эффективное решение для резервного копирования, обязательны все вышеуказанные мероприятия. Начинается этот выбор с анализа потребностей компании и угроз безопасности информации, а также с анализа SLA (Service Level Agreement, соглашение об уровне предоставления услуг), то есть с вычисления рисков для бизнеса и параметров RTO и RPO для каждой из ИТ-систем, подлежащих резервированию.
Шаг 2: анализ потребностей предприятия, угроз и SLA
На основе анализа бизнес-процессов и объёма данных, а также имеющихся технических возможностей (или готовности предприятия потратить на обеспечение этих возможностей определенную сумму денег) для каждого клиента резервного копирования вычисляются важнейшие параметры в области восстановления после сбоя (Disaster Recovery) и требований бизнеса — RTO и RPO:
RTO (Recovery Time Objective) — это максимальное допустимое время, за которое система или сервис должны быть восстановлены после сбоя или инцидента. То есть RTO определяет, сколько времени может проходить между сбоем и восстановлением, чтобы бизнес мог продолжать свою деятельность без серьезных нарушений.
RPO (Recovery Point Objective) — это максимально допустимая потеря данных в случае сбоя или инцидента. Параметр определяет, насколько далеко назад во времени мы можем «переместиться», чтобы восстановить данные после сбоя. Например, если RPO составляет 1 час, это означает, что в худшем случае мы можем потерять данные, созданные за последний час.
Оба этих параметра важны для разработки стратегий восстановления после сбоя и определения необходимых ресурсов, процедур и технологий для минимизации простоя и потерь данных в случае катастрофических событий. То есть эти концепты обеспечивают связь требований бизнеса и ИТ-персонала.
Также выяснение потребностей предприятия, требований ИБ и администраторов ИТ-сервисов позволяет составить модель угроз, на основании анализа которой и выбирается подходящее решение для резервного копирования.
Модель угроз: если скорость восстановления копии стремится к нулю, то к бесконечности стремится цена решения
Составление модели угроз безопасности информации — один из самых важных этапов в процессе обеспечения информационной безопасности, включая и резервное копирование, поскольку данный документ позволяет чётко пройти этап планирования, обоснования грядущих трат перед руководством и соответственно бюджетирования. А как давно известно, хорошее планирование — это уже половина успеха. Когда дело касается безопасности, составление модели угроз должно рассматриваться не как прихоть администратора какой-либо системы, а как прямая ответственность руководства за общее дело.
Модель даст возможность осуществить полноценное стратегическое планирование, из которого станет понятно:
какие риски компания готова принять на себя в лице административного персонала и ЛПР и на какой срок;
когда придет очередь закрывать очередные риски, которые, например, будут спущены в принудительном порядке законодательно или в связи с усложнением ИТ-систем и сколько придется заплатить за то, чтобы административный персонал спал спокойно;
где можно, а где даже нужно разнести финансовые затраты по времени, так как бюджет предприятия не резиновый (а ИБ традиционно стоит дорого).
Вот как модель угроз помогает в стратегическом планировании:
1. Идентификация уязвимостей. Модель угроз помогает выявить уязвимые места в системе, которые могут быть атакованы или подвергнуты риску (например, недостаточно защищённые серверы или уязвимые программные компоненты). Это позволяет определить, какие данные нужно защитить немедленно, то есть резервировать.
2. Оценка рисков. Модель угроз позволяет оценить потенциальные последствия инцидентов безопасности и их вероятность. На основе этой оценки можно определить, какие данные являются наиболее ценными и требуют более частого или тщательного резервного копирования. Это потребует от предприятия дополнительных затрат на дублирование или создание DR-сайтов для резервных копий.
3. Планирование мер защиты. На основе модели угроз будут разработаны стратегии защиты данных. Это может включать в себя выбор подходящих технологий для создания резервных копий, определение частоты и способов резервного копирования (создание планов или политик), а также выбор места хранения копий данных.
4. Анализ уязвимостей копий данных. Модель угроз помогает выявить уязвимости в процессе резервного копирования, такие как недостаточно защищённое хранение резервных копий или недостаточно строгое контролирование доступа к ним. Это позволяет принять меры по устранению этих уязвимостей и обеспечить безопасность копий данных.
5. Выбор подходящих технологий и решений. На основе требований к резервному копированию выбираются подходящие технологии и решения, такие как программное обеспечение для резервного копирования, хранилища данных (локальные серверы, облачные сервисы или сетевые хранилища), аппаратное обеспечение (дисковые массивы или ленточные библиотеки).
Резюмируем: наличие модели угроз позволит правильно выбрать систему резервного копирования, которая будет использовать возможности, однозначно закрывающие существенные ИБ-риски касающиеся локальных устройств хранения, облачных сервисов, гибридных решений или их комбинации.
Факторы, которые следует учитывать при выборе решения для резервного копирования:
скорость резервного копирования и восстановления;
масштабируемость и гибкость системы;
безопасность данных и соответствие нормативным требованиям;
управление и мониторинг резервных копий;
требования к бюджету и расходам на обслуживание;
требования к стоимости обслуживания и уровню автоматизации.
При выборе ПО для бэкапов, конечно, одной модели угроз недостаточно. Ещё потребуется определить сильные и слабые стороны ИТ-инфраструктуры и персонала. Для этого на предприятии проводится аудит своими силами или, если своих компетенций недостаточно или руководство хочет иметь более объективную картину состояния ИТ, силами подрядчиков. Как правило, это интеграторы, которые имеют множество центров компетенций (иногда это бывает важно, особенно для крупных компаний) и большой опыт в эксплуатации и настройке оборудования, проектировании ИТ-систем и процессов.
Шаг 3: проектирование системы и настройка инфраструктуры
Задачи этого этапа включают в себя:
Более основательное и глубокое определение требований к резервному копированию, чем на предыдущем этапе. Необходимо точно определить такие требования к резервному копированию, как частота создания копий, время восстановления после сбоя, объём и типы данных, которые нужно резервировать. Это позволит оценить требуемую мощность компонентов системы и размер окна резервного копирования.
Разработку плана резервного копирования. В него входит определение частоты создания копий, расписания выполнения резервного копирования, выбор методов и стратегий резервного копирования (например, полное копирование или инкрементное), а также определение процедур восстановления данных. Данный пункт позволит оценить возможность вписаться в SLA-ограничения по ИТ-сервисам, предъявляемым сервис-менеджерами или заказчиками сервиса (внутренними и внешними), а также произвести настройки оборудования под соответствующе прогнозируемую нагрузку на него.
Настройка системы резервного копирования. Включает в себя рутинные процедуры: установку и конфигурирование выбранного программного обеспечения для резервного копирования, настройку параметров копирования, определение места хранения копий данных и установку соответствующих прав доступа.
Обеспечение безопасности данных. Необходимо обеспечить защиту резервных копий данных от несанкционированного доступа и утечек. Это может включать в себя проектирование отдельных сетей для резервного копирования (например, разных ИТ-контуров с разными уровнями безопасности), шифрование данных во время передачи и хранения, установку механизмов аутентификации и авторизации, а также регулярную проверку целостности и доступности копий данных и исследование компонентов системы резервного копирования на уязвимости с помощью доступного на предприятии ИБ-инструментария.
Бывает, что на предыдущем шаге были проведены недостаточные исследования, поэтому на этом этапе уже выбранное решение может быть заменено на то, которое будет лучше отвечать задачам предприятия на основании уточнённых определений.
На данном этапе также рекомендуется провести пилотирование выбранного решения. Можно сделать это полностью самостоятельно (если дистрибутивы и документация по продуктам находятся в свободном доступе), а можно бесплатно с помощью интеграторов (например, нас) и вендора.
Ремарка об отечественном ПО для бэкапирования на основе опыта «Тринити»
На наш взгляд на рынке в данный момент наиболее заметны два ПО: Кибер Бэкап и RuBackup. Они выделяются из отечественных решений, проверенных временем и соответствующих отечественным нормативам импортозамещения. У каждого из них есть свои плюсы и минусы, и окончательный выбор зависит от размера предприятия, а также того, какие на нём используются ОС, гипервизоры и серверы приложений. Но замечу, что Кибер Бэкап постепенно выбирается в лидеры. Вероятно, это происходит за счёт:
меньшей нагрузки на администратора при развёртывании и администрировании (и как следствие снижения ошибок из-за человеческого фактора);
расширяющейся поддержки отечественных линукс-ОС и гипервизоров;
публичного признания ошибок в ПО и постоянной стратегии их исправления;
имеющейся программы обучения для администраторов в ведущих учебных центрах страны, а также постоянно приводящихся вебинарах;
наличия блогов на известных ИТ-ресурсах, где комьюнити обсуждает с вендором стратегии использования этого ПО;
наличия понятной и часто обновляемой документации;
возможности бесплатно скачать с сайта пробное ПО Кибер Бэкап в текущей версии, которая работает полнофункционально и без ограничений до того момента, пока пользователь не зарезервирует на ней 1 ТБ бэкэнда (то есть уже сжатого и дедуплицированного контента, коэффициэнты сжатия и дедупликации которого в пилотном проекте в среднем варьируются от 3 до 5, благодаря не большой и не частой выборке данных);
использования своего ноу-хау формата хранения, клиентской дедупликации и сжатия резервных копий.
Согласитесь, таких параметров вполне достаточно для демо-версии ПО, хорошего пилотного тестирования, проверки архитектуры и в целом заявленных возможностей Кибер Бэкап.
Шаг 4: тестирование и оптимизация системы
После развёртывания пилотной инфраструктуры необходимо провести тестирование системы резервного копирования для проверки её работоспособности и эффективности. Этот пункт включает в себя одну главную и несколько рутинных задач.
Главная задача — мониторинг. Его важность зачастую недооценивают. На этом этапе надо разработать модель здоровья для каждого ИТ-сервера, который будет подлежать резервному копированию, а также использовать дополнительную систему мониторинга в связке с системой мониторинга системы резервного копирования. Как правило, система мониторинга у резервного копирования следит только за метриками своего управляющего сервера, выполняет аналитику заданий, используемого оборудования и ресурсов, чего, как понимают продвинутые администраторы, недостаточно для критических сервисов.
Нужно помнить, что система резервного копирования может оказывать определённый эффект на продуктивную систему, который заключается в повышении нагрузки на сеть и диски, повышение использования оперативной памяти, исчерпание места на локальном диске и т. п. В обычной ситуации к серверу может быть применена стандартная модель здоровья. В необычной — такую модель придётся создавать узкому специалисту (например, Zabbix-мэном, бэкапщиком, архитектором сервиса). Главное на данном этапе — настроить систему мониторинга таким образом, чтобы можно было своевременно обнаруживать проблемы и реагировать на любые сбои в процессе бэкапирования.
Рутинные администраторские задачи. Перечисленные ниже пункты (кроме испытаний) придётся делать постоянно, если система живет и развивается, а инфраструктура предприятия, в том числе сетевая, претерпевает перманентные изменения:
проведение тестов восстановления данных для проверки RTO и RPO;
оценка производительности и надёжности системы;
идентификация и устранение возможных проблем и узких мест, в том числе через оптимизацию нагрузки или расписания, переосмысления типа резервного копирования (инкрементное, полное, синтетическое, с помощью снапшотов, или по SAN), а также переключения нагрузки на свободные узлы хранения или NAS;
оптимизация процессов резервного копирования и восстановления;
проведение испытаний и перевод системы в промышленную эксплуатацию.
Шаг 5: обучение персонала и его поддержка
Часто руководители, принимающие решения, полагают, что обучать персонал не нужно — мол, научаться сами, не маленькие же. Так происходит потому, что учить пользованию системой резервного копирования нужно не только системных администраторов, непосредственно за неё отвечающих, но и всех пользователей, от которых зависит безопасность конкретного ИТ–сервиса.
Парадокс, но в любой сложной системе безопасности эта самая безопасность — «слабое звено», которое находится в руках множества людей в компании. Если нет разработанных регламентов резервного копирования, то системный администратор не знает, какую систему как надо бэкапить и сколько хранить данные. В свою очередь администратор сервиса без регламента обязательно забудет поменять настройки системы резервного копирования при изменении системы (у него и так работы навалом). Менеджер сервиса не будет знать, что конкретно и каким способом сейчас резервируется и тоже не сможет проконтролировать резервное копирование без доступа к системе мониторинга (ещё и потому, что информации о том, что именно нужно резервировать, нигде нет).
Но только лишь написать регламент недостаточно. Очень важно разработать процесс, который будет включать всех лиц, ответственных за постановку на резервное копирование на предприятии. Этот процесс также должен обеспечивать правильную очередность принятия решений, контроль изменений, контроль прохождения резервных копий (да да, не всегда копии проходят вовремя, потому что и у администратора системы резервного копирования тоже много своих дел?) и наконец, контроль восстановления резервных копий и контроль аварийного восстановления резервных копий (в простонародье DR-план).
Профессионалам очевидно: мало что-то зарезервировать, нужно потом восстановить это так, чтобы система стала работоспособной. И далеко не всегда при восстановлении системы её неработоспособность происходит из-за банальной неконсистентной копии или копии с ошибками. Часто бывает так, что процесс аварийного восстановления большой и сложной системы требует от администратора навыков сапёра: нужно в точной последовательности знать, где и какие настройки применить, какие конфиги накатить. Мне приходилось сталкиваться со «старыми» системами, у которых уже сменилось несколько администраторов и никто давно не знает, как там вообще всё работает и как это восстанавливать. По моим наблюдениям наличие плана аварийного восстановления хотя бы критичных сервисов нередко положительно влияет на скорость их восстановления, пока админы вспоминают, как же все-таки поднять эту бандуру.
Для разработки процесса резервного копирования и написания регламента потребуется аудит процессов и аудит всех ИТ-систем, поэтому потребуется сотрудничество множества людей:
сервис-менеджеров;
ИТ-администраторов сервиса;
администраторов системы резервного копирования;
руководителей соответствующих отделов, которых затрагивают изменения, проводимые на их оборудовании или сервисах.
Иногда сюда нужно будет включить ответственного ИТ-безопасника или сетевика, если есть сомнения в пропускной способности какого-то сегмента сети или сегмент обособлен.
Но всё вышесказанное ещё не значит, что пользованию системой резервного копирования не надо учить и ИТ-администраторов. Обучение ИТ-персонала пользованию и поддержке системы может, как минимум, снизить риск человеческих ошибок и обеспечить её эффективное функционирование в долгосрочной перспективе. Система ведь новая, никто не сможет прочитать сотни страниц документации сразу — придётся учиться на своих ошибках, которые иногда могут выливаться в потерю данных из-за неправильного понимания процесса её работы.
Резюмируя, отмечу, что обучение может включать в себя:
проведение тренингов и семинаров для ИТ-специалистов и конечных пользователей;
разработку руководств, инструкций и процессов по пользованию системой;
предоставление технической поддержки и консультаций по вопросам резервного копирования.
Главные виды и характеристики резервного копирования
В списке ниже — наиболее распространенные виды резервного копирования. Что из них выбрать, зависит от требований к безопасности данных, доступности ресурсов, масштабов операций и других факторов.
1. Полное копирование (Full Backup) — в этом случае копируются все данные и файлы целиком. Полные копии обычно занимают больше места и требуют больше времени на создание, но они обеспечивают полную защиту данных и простоту восстановления.
2. Инкрементное копирование (Incremental Backup) — создаётся копия только изменённых с момента последнего резервного копирования данных. Это позволяет сократить объём места, используемого для хранения и время, необходимое для создания резервных копий. Однако требует более сложных процедур, так как для восстановления данных может потребоваться несколько копий.
3. Дифференциальное копирование (Differential Backup) — создаётся копия всех данных, изменённых с момента последнего полного резервного копирования. В отличие от инкрементного копирования дифференциальные копии содержат только изменения с момента последнего полного копирования, что упрощает процедуру восстановления.
4. Синтетическое резервное копирование — это метод создания резервных копий данных, при котором происходит объединение инкрементных (предыдущих) резервных копий с полной копией данных. Полное и инкрементное — это два основных типа резервного копирования, которые объединяются в синтетическом резервном копировании. Сначала создаётся полная копия данных, с которой затем объединяются последующие инкрементные копии. В результате получается синтетическая копия данных, содержащая все изменения от момента создания полной копии. Преимущества такого метода включают экономию времени и ресурсов, поскольку для бэкапа всегда используются инкрементные изменения, а полная копия синтезируется системой. Подход обеспечивает более эффективное использование окна резервного копирования, снижает нагрузку на продуктив и систему хранения, поскольку данные, которые повторяются в различных инкрементных копиях, хранятся только один раз в синтетической копии.
5. Мгновенное копирование (Snapshot Backup) — метод, который создаёт «замороженные» консистентные копии данных на определённый момент времени. До создания снимка, как правило, происходит подготовка приложения или гостевой файловой системы. Снимки сохраняются в том состоянии, в котором они находились в момент создания, что позволяет восстанавливать данные до определённой точки во времени.
6. Онлайн и офлайн копирование — первое подразумевает создание резервных копий баз данных без прерывания работы системы, в то время как второе требует временного выключения системы или сервисов для создания копий.
7. Локальное и облачное копирование — локальное копирование предполагает хранение резервных копий на локальных носителях данных, таких как жесткие диски или ленты. Облачное копирование включает в себя хранение резервных копий на удалённых серверах в облачных сервисах.
Один из основных принципов резервного копирования важных данных, руководствуясь которым обслуживают наиболее критичные системы предприятия, звучит так: «Три, два, один». Он предполагает создание трёх независимых копий важных данных в двух разных местах, при этом одна из копий должна находиться вне основного хранилища данных.
Три копии данных: необходимо создать три независимые копии важных данных. Это делается для обеспечения наличия резервных копий, даже если одна из них повреждается или теряется.
Два разных местоположения: копии данных должны быть расположены в двух разных физических или логических местоположениях (устройствах хранения). Это позволяет обезопасить данные от различных рисков, таких как пожар, кража или аппаратные сбои.
Одна копия — вне основного хранилища: хотя две копии могут находиться внутри вашей компании или дома, третья копия должна быть сохранена вне основного хранилища данных. Например, в облачном хранилище или на внешнем носителе информации.
Этот принцип при правильной оценке рисков гарантированно помогает обеспечить надёжность и безопасность данных, а также возможность их восстановления в случае потери или повреждения.
В качестве заключения
Развёртывание системы резервного копирования на предприятии с нуля — это многоэтапный процесс, требующий тщательного анализа, планирования и внедрения. Однако правильно спроектированная и настроенная система резервного копирования позволяет обеспечить защиту и доступность данных, минимизировать риски потери информации и обеспечить непрерывность бизнес-процессов. Вы всегда можете обратиться к нам за советом в таких вопросах.