Цифровая инфраструктура современной организации включает документы, базы данных, виртуальные машины, корпоративные приложения, файловые серверы и другие информационные ресурсы. Потеря даже части этих данных может привести к остановке работы сотрудников, нарушению производственных процессов и необходимости длительного восстановления информационных систем. Поэтому резервное копирование является одним из базовых элементов обеспечения устойчивости ИТ-инфраструктуры.
В российских организациях наряду с традиционными решениями все чаще рассматриваются системы резервного копирования российского производства. Они применяются в государственных учреждениях, промышленных предприятиях, финансовых организациях, образовательных учреждениях и коммерческих компаниях. Основная задача таких систем не отличается от задач других решений этого класса: необходимо регулярно создавать резервные копии, обеспечивать их сохранность и предоставлять возможность восстановить данные после сбоя, ошибки пользователя или информационного инцидента.
При этом система резервного копирования представляет собой не просто программу для копирования файлов. В корпоративной инфраструктуре это комплекс средств, отвечающий за создание копий, расписание заданий, хранение данных, контроль их целостности, разграничение доступа, мониторинг и восстановление.
Что такое система резервного копирования российского производства
Под системой резервного копирования российского производства обычно понимается программное решение, разработанное российской компанией и предназначенное для организации централизованного бэкапа информационной инфраструктуры.
Такая система может использоваться для защиты физических серверов, виртуальных машин, рабочих станций, баз данных, файловых хранилищ и отдельных приложений. В зависимости от архитектуры она устанавливается непосредственно в инфраструктуре организации или взаимодействует с выделенными серверами и системами хранения.
Как правило, в состав решения входит сервер управления. Он хранит настройки, расписания, информацию о защищаемых объектах и сведения о созданных резервных копиях. Дополнительно могут использоваться агенты, устанавливаемые на защищаемые серверы, прокси-компоненты для обработки данных, каталоги резервных копий и специализированные узлы хранения.
На практике организация резервного копирования может строиться по-разному. Небольшой компании может быть достаточно одного сервера и отдельного дискового хранилища. Крупной организации требуется распределенная инфраструктура, включающая несколько площадок, резервные хранилища и большое количество одновременно выполняемых заданий.
Зачем организациям требуется резервное копирование
Одной из наиболее очевидных причин потери данных остается отказ оборудования. Накопители, серверы, контроллеры и другие компоненты могут выйти из строя. Современные системы хранения способны использовать избыточность и автоматически переживать отказ отдельных дисков, однако такая технология не является полноценной заменой резервного копирования.
Данные также могут быть удалены или изменены сотрудником. Пользователь способен случайно удалить документ, перезаписать нужную версию файла или внести ошибочные изменения в информационную систему. Если резервные копии создаются регулярно, данные можно вернуть к состоянию до возникновения ошибки.
Еще одна группа рисков связана с программными сбоями. Неудачное обновление приложения, повреждение базы данных или ошибка конфигурации способны сделать информационную систему недоступной.
Отдельного внимания требуют кибератаки. Программы-вымогатели и другие вредоносные инструменты могут повреждать рабочие данные и пытаться получить доступ к резервным копиям. По этой причине современная система бэкапа должна защищать не только производственные серверы посредством создания копий, но и сами резервные данные.
Какие объекты могут резервироваться
Современная система резервного копирования российского производства должна учитывать разнообразие ИТ-инфраструктуры. Простого сохранения пользовательских папок для корпоративной среды обычно недостаточно.
Одним из основных объектов являются физические серверы. На них могут работать файловые службы, приложения, базы данных и другие корпоративные системы. В зависимости от решения возможно резервирование отдельных каталогов, разделов диска либо всего сервера.
Большое значение имеет работа с виртуальной инфраструктурой. Виртуализация позволяет разместить множество серверных систем на ограниченном количестве физических узлов. Поэтому потеря одного элемента инфраструктуры потенциально может затронуть сразу несколько сервисов. Бэкап виртуальных машин позволяет сохранить виртуальные диски, конфигурацию и другие необходимые компоненты.
Другой важный объект - базы данных. Их резервирование имеет особенности, поскольку информация активно изменяется во время работы. Простое копирование файлов базы не всегда гарантирует получение согласованного состояния. Поэтому специализированные решения могут использовать механизмы взаимодействия с системами управления базами данных.
Также могут защищаться файловые серверы, общие каталоги, пользовательские компьютеры и различные прикладные системы. Перечень поддерживаемых объектов зависит от конкретного программного продукта и его версии.
Полное резервное копирование
Полный бэкап предполагает сохранение всего выбранного объема информации. Например, если сервер содержит 500 ГБ защищаемых данных, полное резервирование в исходном виде предполагает обработку всего этого объема.
Преимущество подхода заключается в относительно понятной структуре копии. При восстановлении система использует полный набор сохраненных данных.
Недостатком является повышенная нагрузка на сеть, серверы и хранилище. Если ежедневно создавать полные копии большого количества систем, объем резервной инфраструктуры быстро увеличится.
Поэтому полное копирование обычно является частью более сложной схемы и сочетается с другими методами.
Инкрементальные и дифференциальные копии
При инкрементальном резервировании после первоначальной полной копии сохраняются только изменения, произошедшие с момента предыдущего задания. Такой подход позволяет уменьшить объем передаваемых данных и сократить время резервного копирования.
Например, если из нескольких терабайт информации за сутки изменилось только 50 ГБ, системе не требуется повторно передавать неизменившиеся данные.
Дифференциальный подход предполагает сохранение изменений относительно последней полной резервной копии. По мере накопления изменений размер очередной дифференциальной копии может увеличиваться.
Нельзя утверждать, что один метод всегда лучше другого. Схема выбирается с учетом доступного места, требуемой скорости создания копий и времени восстановления.
RPO и допустимая потеря данных
Перед внедрением системы резервного копирования необходимо определить требования к сохранности информации. Один из основных показателей называется RPO - Recovery Point Objective.
Он определяет допустимый период потери изменений. Если резервирование выполняется раз в 24 часа, теоретически организация может потерять почти сутки информации, созданной после последней успешной копии.
Для архива документов такая ситуация в отдельных случаях может оказаться приемлемой. Для активно изменяющейся базы данных потеря нескольких часов информации может быть недопустима.
Поэтому разные информационные системы обычно получают разные политики резервирования. Критичные ресурсы копируются чаще, менее значимые - реже. Такой подход позволяет разумнее использовать вычислительные мощности и емкость хранилища.
RTO и скорость восстановления
Второй важный показатель - RTO, или Recovery Time Objective. Он показывает, за какое время необходимо восстановить работу после сбоя.
Сам факт наличия резервной копии не означает, что система быстро вернется в рабочее состояние. Восстановление нескольких терабайт данных через медленный сетевой канал может занять много часов.
Поэтому при проектировании необходимо учитывать не только скорость создания резервных копий, но и скорость обратного процесса.
Для критичных сервисов организации иногда предусматривают отдельные производительные хранилища или технологии быстрого запуска восстановленных систем. Для менее важных архивных ресурсов допустимо более продолжительное восстановление.
Где хранятся резервные копии
Выбор хранилища является одним из ключевых вопросов построения бэкап-инфраструктуры.
Для оперативных резервных копий часто используются дисковые системы. Они обеспечивают сравнительно быстрый доступ к информации и позволяют автоматизировать создание и восстановление копий.
Другим вариантом являются объектные хранилища. Они применяются для работы с большими объемами данных и могут использоваться как один из уровней корпоративной системы резервирования.
В некоторых инфраструктурах сохраняются ленточные накопители. Их преимуществом может быть возможность физически отделить записанные носители от основной сети.
Также организация может иметь резервную площадку. В этом случае дополнительная копия данных передается в другой центр обработки данных или территориально удаленное хранилище.
На практике нередко применяется сочетание нескольких вариантов.
Принцип 3-2-1
При организации резервного хранения часто используется правило 3-2-1. Его базовая идея заключается в том, чтобы иметь несколько экземпляров информации, сохранять их с использованием разных способов хранения и держать хотя бы одну копию отдельно от основной инфраструктуры.
Например, рабочая информация находится на производственном сервере. Первая резервная копия создается на отдельном дисковом хранилище. Еще одна копия передается на удаленную площадку.
Подобная схема позволяет уменьшить зависимость от одного оборудования или одной серверной площадки.
Однако правило 3-2-1 следует воспринимать как общий принцип, а не как единственно возможную архитектуру. Конкретная схема должна учитывать угрозы, стоимость инфраструктуры и требования конкретной организации.
Защита резервных копий от кибератак
Резервное хранилище само является объектом, который необходимо защищать. Вредоносное программное обеспечение или злоумышленник, получивший расширенные права в сети, может попытаться удалить копии перед повреждением основных данных.
Поэтому важным направлением развития современных систем стала защита резервной инфраструктуры.
Один из подходов - неизменяемое хранение. Резервная копия на определенный период переводится в состояние, при котором ее нельзя обычным способом удалить или перезаписать.
Дополнительно используется разделение административных учетных записей. Пользователь, управляющий обычными серверами, не обязательно должен иметь возможность управлять резервными копиями.
Применяются многофакторная аутентификация, журналирование действий, ограничения сетевого доступа и отдельные сегменты инфраструктуры.
Чем сильнее резервная система изолирована от производственной среды, тем сложнее одному инциденту одновременно повредить основные и резервные данные.
Шифрование данных
Резервная копия может содержать практически полный набор корпоративной информации. Поэтому несанкционированный доступ к ней представляет отдельную угрозу.
Для защиты могут использоваться механизмы шифрования. Данные шифруются при передаче между компонентами или непосредственно в резервном хранилище.
При использовании шифрования необходимо уделять внимание ключам. Если ключ утрачен, восстановить защищенную копию может оказаться невозможно. Если же ключ хранится вместе с системой без дополнительной защиты, снижается эффективность самого шифрования.
Таким образом, управление ключевой информацией должно быть частью общей политики информационной безопасности организации.
Дедупликация и сжатие
Резервирование большого количества серверов требует значительного объема дискового пространства. Сократить требования к хранилищу позволяют дедупликация и сжатие.
Дедупликация выявляет повторяющиеся фрагменты данных и позволяет не хранить одинаковую информацию многократно. Это может быть особенно полезно в виртуальной инфраструктуре, где множество машин содержит похожие системные файлы.
Сжатие уменьшает физический объем данных за счет алгоритмической обработки.
Результат зависит от типа информации. Уже сжатые архивы, видеофайлы и некоторые зашифрованные данные могут практически не уменьшаться в размере. Поэтому реальные требования к емкости хранилища лучше определять с помощью предварительного тестирования.
Совместимость с российскими программными платформами
Одним из основных критериев выбора системы российского производства является совместимость с фактически используемой инфраструктурой.
Организация может использовать российские операционные системы, платформы виртуализации, системы управления базами данных и системы хранения. Бэкап-решение должно корректно взаимодействовать с необходимыми продуктами и версиями.
Следует учитывать разницу между общей поддержкой и глубокой интеграцией. Система может позволять копировать виртуальную машину как набор данных, но не поддерживать восстановление отдельных файлов внутри нее. Аналогичная ситуация возможна с базами данных и приложениями.
Поэтому перед внедрением необходимо составить точный перечень защищаемых платформ и проверить возможности решения для каждой из них.
Централизованное управление и мониторинг
В корпоративной инфраструктуре количество заданий резервного копирования может исчисляться десятками, сотнями или тысячами. Контролировать их вручную затруднительно.
Поэтому важна централизованная консоль, в которой отображаются состояние заданий, расписания, использование хранилищ и возникающие ошибки.
Система должна позволять быстро определить, какие объекты успешно защищены, а для каких резервная копия не создавалась в установленный срок.
Полезны уведомления о сбоях и предупреждения о приближении к лимиту свободного пространства. В крупных инфраструктурах данные о состоянии бэкапа могут передаваться в общую систему мониторинга.
При этом зеленый индикатор успешно выполненного задания не должен рассматриваться как единственное подтверждение надежности. Необходимо проверять возможность восстановления.
Почему важно тестировать восстановление
Главная цель резервного копирования заключается не в создании файлов бэкапа, а в возвращении данных после инцидента.
Даже успешно созданная копия потенциально может оказаться непригодной. Причиной может стать повреждение цепочки, некорректная работа приложения, ошибка конфигурации или отсутствие необходимых данных.
Поэтому организациям рекомендуется регулярно проводить тестовые восстановления.
Для файлового сервера это может быть восстановление нескольких документов. Для виртуальной инфраструктуры - запуск резервной виртуальной машины в изолированной сети. Для критической бизнес-системы полезны более масштабные учебные сценарии.
Такие проверки позволяют не только оценить техническое состояние копий, но и выяснить реальное время восстановления.
Масштабируемость системы
При выборе российского решения следует учитывать рост инфраструктуры. Количество данных в организации обычно увеличивается, появляются новые информационные системы и виртуальные машины.
Система, рассчитанная только на текущие потребности, через несколько лет может столкнуться с ограничениями.
Необходимо оценивать максимально допустимый объем защищаемых данных, количество одновременных заданий, возможность подключения дополнительных хранилищ и серверов обработки.
Отдельное значение имеет пропускная способность сети. Если в определенный момент большое количество серверов одновременно начинает передавать резервные данные, нагрузка может повлиять на рабочие приложения.
Поэтому расписания часто распределяются по времени, а для крупных систем предусматривается специализированная сетевая инфраструктура.
Политики хранения резервных копий
Создавать копии бессрочно обычно невозможно из-за ограниченного объема хранилища. Поэтому устанавливается срок хранения.
Например, ежедневные резервные копии могут сохраняться определенное количество дней, еженедельные - более длительный период, а месячные - использоваться для долгосрочного архива.
Сроки выбираются исходя из требований организации, характера данных и нормативных обязательств.
Слишком короткий период хранения может привести к тому, что нужная версия уже будет автоматически удалена к моменту обнаружения ошибки. Чрезмерно длительное хранение всех копий, напротив, увеличивает затраты на инфраструктуру.
Поэтому политика должна учитывать реальную вероятность необходимости восстановления данных за разные периоды.
Типичные ошибки при организации бэкапа
Распространенной ошибкой является размещение резервных копий непосредственно на том же сервере, где находятся исходные данные. В случае отказа устройства обе версии могут быть потеряны одновременно.
Другая проблема - использование только одной резервной площадки без дополнительной копии. Серьезный инцидент способен затронуть всю локальную инфраструктуру.
Еще одна ошибка заключается в отсутствии мониторинга. Задание может не выполняться несколько недель, а администратор обнаружит это только после потери исходных данных.
Опасно также не проводить тесты восстановления. Наличие резервных файлов не гарантирует, что организация умеет правильно ими воспользоваться.
Следует учитывать и человеческий фактор. Инструкции по восстановлению должны быть документированы, а ответственные специалисты должны понимать последовательность действий в аварийной ситуации.
Резервное копирование и аварийное восстановление
Бэкап и аварийное восстановление связаны между собой, но не являются одинаковыми понятиями.
Система резервного копирования отвечает преимущественно за создание и предоставление сохраненных данных. План аварийного восстановления описывает весь процесс возвращения инфраструктуры в рабочее состояние.
Если физический сервер полностью вышел из строя, одной резервной копии недостаточно. Необходимо оборудование, на котором система будет запущена, доступ к сети, необходимые учетные записи и понимание порядка восстановления зависимых сервисов.
В крупной инфраструктуре важно заранее установить приоритеты. Например, сначала могут восстанавливаться службы аутентификации и сеть, затем базы данных, после этого прикладные сервисы.
Такая последовательность должна проверяться до реального инцидента.
Как выбирать систему резервного копирования российского производства
Выбор следует начинать с анализа собственной инфраструктуры, а не с перечня функций конкретного продукта.
Необходимо определить объем данных, количество физических и виртуальных серверов, используемые операционные системы, системы виртуализации и базы данных. Затем устанавливаются требования к частоте создания копий и времени восстановления.
Следующим этапом становится оценка совместимости. Желательно проверять поддержку конкретных версий используемого программного обеспечения.
Также необходимо оценить безопасность: наличие механизмов неизменяемого хранения, шифрования, разграничения прав, журналирования и дополнительной аутентификации.
Важно изучить архитектуру масштабирования. Организация должна понимать, что потребуется сделать при увеличении объема данных в два или три раза.
Наконец, необходимо провести тестовое внедрение. Оно позволяет измерить фактическую скорость резервирования и восстановления именно в той инфраструктуре, где будет использоваться система.
Значение документации и технического сопровождения
Даже функционально развитая система требует правильной эксплуатации. Поэтому при выборе российского решения имеет значение качество технической документации.
Администраторы должны иметь возможность получить информацию по установке, обновлению, резервированию различных платформ и устранению типичных ошибок.
Также важен жизненный цикл продукта. Корпоративная система резервного копирования используется годами, поэтому необходимо учитывать регулярность обновлений и поддержку новых версий совместимого программного обеспечения.
При обновлении самой бэкап-системы желательно заранее проверять процедуру миграции конфигурации и каталогов резервных копий.
Место российских бэкап-систем в ИТ-инфраструктуре
Система резервного копирования российского производства может быть частью более широкой стратегии технологической независимости. При переходе организации на российские серверные операционные системы, платформы виртуализации и прикладное программное обеспечение возникает необходимость обеспечить их полноценную защиту.
При этом выбор отечественного продукта сам по себе не решает задачу сохранности информации. Результат зависит от архитектуры всей системы: количества копий, качества хранилищ, защиты учетных записей, мониторинга и регулярного тестирования.
Даже надежное программное обеспечение может оказаться неэффективным при неправильной настройке. И наоборот, грамотно спроектированная инфраструктура резервирования значительно уменьшает последствия многих видов технических инцидентов.
Заключение
Система резервного копирования российского производства предназначена для защиты цифровой информации и восстановления ИТ-систем после аппаратных отказов, ошибок пользователей, программных сбоев и кибератак. Она может использоваться для физических серверов, виртуальных машин, баз данных, файловых ресурсов и других элементов корпоративной инфраструктуры.
При выборе такой системы необходимо учитывать не только происхождение программного обеспечения, но прежде всего его технические характеристики и соответствие задачам организации. К ключевым параметрам относятся совместимость с используемыми платформами, поддерживаемые способы резервирования, производительность, масштабируемость, защита резервных копий и удобство восстановления.
Не менее важна архитектура хранения. Несколько копий, размещение части данных на отдельной площадке, использование разграничения доступа и механизмов неизменяемого хранения позволяют повысить устойчивость инфраструктуры к серьезным инцидентам.
Основным показателем качества бэкапа остается возможность фактически восстановить информацию в требуемый срок. Поэтому резервное копирование необходимо рассматривать как непрерывный процесс: задания должны контролироваться, копии - проверяться, сценарии восстановления - регулярно тестироваться, а политика защиты данных - пересматриваться по мере изменения инфраструктуры.
При таком подходе система российского производства становится не просто средством периодического копирования файлов, а одним из основных компонентов обеспечения надежности и непрерывности работы корпоративных информационных систем.
