Цифровая инфраструктура современной организации включает не только отдельные файлы и пользовательские документы. В неё входят виртуальные машины, физические серверы, базы данных, корпоративная почта, прикладные системы, конфигурации оборудования и служебная информация. Потеря любого из этих компонентов может привести к остановке рабочих процессов, нарушению взаимодействия с клиентами и длительному восстановлению ИТ-сервисов.
Для защиты данных применяются централизованные системы резервного копирования. Они создают копии по расписанию, контролируют их хранение, фиксируют результаты операций и предоставляют инструменты восстановления. Такой подход отличается от ручного копирования файлов тем, что охватывает разнородные объекты и позволяет управлять ими по единым правилам.
RuBackup - российская система резервного копирования и восстановления, предназначенная для автоматизированной защиты инфраструктурных систем разного масштаба и бизнес-приложений. В число поддерживаемых объектов входят физические серверы, среды виртуализации, виртуальные машины, базы данных и корпоративные программные системы. Продукт включён в Единый реестр российского программного обеспечения под номером 6808 от 16 июля 2020 года.
Роль резервного копирования в ИТ-инфраструктуре
Рабочие данные могут быть повреждены по разным причинам. К ним относятся аппаратные неисправности, ошибочные действия пользователей и администраторов, сбои программного обеспечения, некорректные обновления, повреждение файловой системы и вредоносная активность. В некоторых случаях исходные данные остаются физически доступными, но использовать их уже невозможно из-за нарушения внутренней структуры.
Резервное копирование создаёт дополнительные экземпляры информации, которые можно использовать для возврата системы к более раннему состоянию. Однако копия имеет практическую ценность только тогда, когда она соответствует требованиям организации и действительно восстанавливается.
При проектировании защиты обычно определяют два ключевых показателя. Первый отражает допустимую потерю изменений между последней копией и моментом сбоя. Второй показывает, за какое время должен быть восстановлен сервис. Для архивной папки допустимы одни значения, а для производственной базы данных или системы обслуживания клиентов - другие.
Поэтому единое расписание для всех серверов редко бывает оптимальным. Критичные базы могут копироваться чаще, чем тестовые системы, а долгосрочные архивы - храниться на другом типе носителя. Система резервного копирования помогает автоматизировать эти процессы, но правила защиты формируются самой организацией.
Назначение RuBackup
В официальной документации RuBackup определяется как российская система для автоматизированной защиты данных инфраструктурных систем и бизнес-приложений. Она поддерживает полное, инкрементальное, дифференциальное и синтетическое резервное копирование.
Полное копирование создаёт отдельную копию всего выбранного набора данных. Оно упрощает восстановление, но требует значительного объёма хранилища и времени.
Инкрементальное копирование сохраняет изменения, произошедшие после предыдущей копии. Оно сокращает объём ежедневной передачи, однако при восстановлении может потребоваться последовательность из нескольких элементов.
Дифференциальная копия включает изменения после последней полной копии. Она постепенно увеличивается до создания следующей полной точки, но обычно уменьшает количество зависимых элементов при восстановлении.
Синтетическая полная копия формируется внутри резервной инфраструктуры из уже имеющейся полной копии и последующих изменений. Такой подход может снизить нагрузку на защищаемую систему и сеть, поскольку весь объём данных не требуется повторно считывать с исходного сервера.
Выбор метода зависит от размера объекта, скорости изменения данных, доступного окна копирования и требуемого времени восстановления. На практике разные методы часто объединяются в одну стратегию.
Клиент-серверная архитектура
RuBackup построен по клиент-серверному принципу. В минимальной конфигурации используются сервер резервного копирования и клиентский компонент. Сервер выполняет фоновые процессы, управляет заданиями и координирует операции копирования и восстановления.
В более крупной инфраструктуре могут применяться основной сервер, резервный сервер и медиасерверы. В актуальной документации RuBackup 2.9 мастер настройки предусматривает выбор этих ролей, а также возможность защищённого соединения со служебной базой данных.
Основной сервер отвечает за централизованное управление. На нём хранятся сведения о клиентах, заданиях, расписаниях, носителях и созданных копиях.
Резервный сервер может использоваться для повышения доступности управляющего контура. Его наличие особенно важно в крупной среде, где отказ единственного управляющего узла способен затруднить восстановление множества систем.
Медиасервер участвует в передаче и размещении резервных данных. Распределение нескольких медиасерверов по площадкам позволяет уменьшить нагрузку на центральные каналы и приблизить хранилища к защищаемым ресурсам.
Клиентские компоненты устанавливаются на серверы или взаимодействуют с внешними платформами через специализированные модули. Они передают данные, выполняют необходимые операции с приложением и участвуют в восстановлении.
Защита физических серверов
Физические серверы продолжают использоваться для баз данных, специализированных приложений, инфраструктурных служб и систем, которым требуется прямой доступ к оборудованию. Их отказ может быть связан с неисправностью накопителя, повреждением операционной системы или ошибкой конфигурации.
Файловое копирование позволяет защищать выбранные каталоги и наборы файлов. Перед созданием задания необходимо определить, какие данные действительно нужны для восстановления. Копирование только пользовательских документов не всегда достаточно: могут потребоваться конфигурационные файлы, ключи, сертификаты, системные параметры и сведения о зависимостях.
Для полного восстановления сервера необходимо заранее понимать последовательность действий. Сначала подготавливается оборудование или виртуальная машина, затем устанавливается либо загружается операционная среда, после чего возвращаются данные и конфигурации.
Резервная копия физического сервера не устраняет потребность в документации. Если после аварии неизвестны сетевые настройки, порядок запуска служб и используемые учётные записи, восстановление может занять значительно больше времени, чем сама передача данных.
Работа с виртуальными средами
Виртуальная инфраструктура позволяет размещать множество серверных систем на общей аппаратной платформе. Это упрощает управление вычислительными ресурсами, но одновременно увеличивает возможные последствия отказа хранилища или управляющего компонента.
RuBackup использует отдельные модули для резервного копирования виртуальных машин и их шаблонов. Например, документация версии 2.9 описывает защиту виртуальных машин VMware, включая поддерживаемые выпуски платформы.
Для сред на базе oVirt, zVirt и ROSA Virtualization в документации указана возможность полного, инкрементального и дифференциального копирования виртуальных машин, в том числе с размещением данных в дедуплицированном хранилище.
В RuBackup 2.5 были представлены модули для Microsoft Hyper-V, Proxmox VE и HOSTVM. В RuBackup 2.9 перечень интеграций расширили модулем для платформы виртуализации "Горизонт-ВС".
Копирование на уровне платформы виртуализации позволяет сохранить не только файлы внутри гостевой операционной системы, но и виртуальные диски, конфигурацию машины и связанные параметры. При этом для приложений с активно изменяемыми данными может потребоваться дополнительный механизм согласования.
Например, снимок работающей виртуальной машины не всегда гарантирует логическую целостность базы данных. Часть операций может находиться в оперативной памяти или журнале транзакций. Поэтому критичные приложения желательно защищать с помощью специализированных модулей, понимающих внутреннюю структуру системы.
Резервное копирование баз данных
Система управления базами данных постоянно изменяет файлы, обслуживает параллельные запросы и ведёт журналы операций. Простое копирование файлов работающей базы может привести к получению набора, который нельзя корректно запустить.
Специализированный модуль взаимодействует со штатными механизмами СУБД. Он переводит данные в согласованное состояние, создаёт базовую копию и при необходимости сохраняет журналы изменений.
Документация RuBackup содержит отдельный модуль для PostgreSQL, предусматривающий операции копирования и восстановления. В RuBackup 2.5 также были представлены модули для Oracle, Microsoft SQL Server и SAP HANA.
При настройке защиты базы данных учитываются её объём, интенсивность транзакций, режим работы и требования к потере информации. Если допустима потеря не более нескольких минут, одного ежедневного копирования недостаточно. Может потребоваться регулярное сохранение журналов транзакций или другой механизм восстановления до выбранного момента.
Также важно учитывать связи между базой и приложением. После восстановления СУБД может потребоваться вернуть совместимую версию серверного программного обеспечения, конфигурационные файлы и данные внешних систем.
Защита бизнес-приложений
Корпоративное приложение часто состоит из нескольких взаимозависимых компонентов. Помимо базы данных, в него могут входить файловые хранилища, сервер приложений, почтовые службы, каталоги пользователей, сертификаты и интеграционные модули.
Копирование только одного компонента не обеспечивает восстановление всей системы. Например, база может быть успешно возвращена, но приложение не запустится из-за отсутствующей конфигурации или несовместимой версии программного обеспечения.
RuBackup ориентирован на защиту не только инфраструктурных серверов, но и бизнес-систем. На официальном сайте к объектам защиты отнесены бизнес-приложения, базы данных, физические серверы и виртуальные среды.
В версии RuBackup 2.4 разработчик сообщил о расширении поддержки российских почтовых систем и нативной работе с ленточными библиотеками. В том же выпуске были доработаны модули PostgreSQL, oVirt и zVirt, а также добавлена возможность ограничивать пропускную способность клиента резервного копирования.
Перед внедрением необходимо сверять точную версию приложения с матрицей совместимости. Совпадение названия продукта не гарантирует поддержку всех его выпусков, конфигураций и способов развёртывания.
Централизованная автоматизация
Основное отличие корпоративной системы резервного копирования от набора отдельных скриптов заключается в централизованном управлении. Администратор создаёт задания, назначает расписания, выбирает хранилища и контролирует результаты из одного контура.
Автоматизация уменьшает вероятность того, что копирование будет забыто или выполнено с неправильными параметрами. Однако она не исключает ошибок настройки. Задание может успешно работать месяцами, но не включать недавно созданный каталог или новый сервер.
Поэтому инфраструктуру необходимо регулярно инвентаризировать. Каждый значимый ресурс должен иметь владельца, категорию критичности, заданную глубину хранения и подтверждённый способ восстановления.
Для интеграции с внешними системами и автоматизированными процессами могут использоваться интерфейсы и утилиты командной строки. Их применение позволяет включать резервное копирование в сценарии развёртывания и обслуживания, но требует защиты административных учётных записей и журналирования команд.
Расписание и политики хранения
Задание резервного копирования определяет источник, тип операции, время запуска, место хранения и дополнительные параметры. Политика хранения устанавливает, как долго сохраняются точки восстановления и когда они могут быть удалены.
Слишком короткий срок хранения не позволит восстановить данные, если ошибка была обнаружена поздно. Например, повреждение отчёта может стать заметным только через несколько недель.
Чрезмерно длительное хранение увеличивает требования к ёмкости и усложняет управление информацией. Кроме того, для некоторых данных действуют внутренние или нормативные ограничения по срокам хранения.
Практическая схема может включать ежедневные, еженедельные, ежемесячные и годовые копии. Более старые точки нередко переносятся на отдельный тип носителя. Выбранные сроки должны соответствовать значимости данных, а не устанавливаться одинаково для всей инфраструктуры.
Дедупликация и оптимизация хранилища
В корпоративной среде разные серверы содержат большое количество одинаковых данных. Это файлы операционных систем, библиотеки, шаблоны виртуальных машин и повторяющиеся документы.
Дедупликация позволяет обнаруживать совпадающие блоки и не сохранять их повторно. В результате физический объём хранилища может быть меньше логического размера всех копий.
Особенно заметный эффект возможен при защите множества похожих виртуальных машин. Для зашифрованных, сжатых или мультимедийных данных коэффициент экономии обычно ниже, поскольку их содержимое хуже поддаётся сравнению.
Дедупликация поддерживается RuBackup в ряде сценариев, включая работу с виртуальными машинами и специализированными хранилищами. В составе решений для защиты виртуальной инфраструктуры также заявлены дедупликация, отказоустойчивость и взаимодействие с ленточными библиотеками.
Экономию пространства следует оценивать по результатам пилотного проекта. Использование предполагаемого коэффициента без испытаний может привести к недостаточному объёму хранилища.
Ленточные библиотеки и долгосрочное хранение
Дисковые системы обеспечивают быстрый доступ к данным и подходят для оперативного восстановления. Однако постоянно подключённое хранилище может быть затронуто ошибкой администратора, повреждением инфраструктуры или атакой.
Ленточные библиотеки применяются для хранения больших объёмов и отделения части копий от рабочих систем. Носитель можно извлечь и разместить в другом помещении или на отдельной площадке.
Работа с лентами требует учёта местоположения носителей, контроля сроков эксплуатации и регулярных проверок чтения. Восстановление с ленты обычно занимает больше времени, чем с оперативного дискового хранилища.
RuBackup поддерживает сценарии взаимодействия с ленточными библиотеками, а в версии 2.4 разработчик сообщил о нативной работе с такими устройствами.
Комбинация дискового и ленточного хранения позволяет разделить оперативные точки и долгосрочные архивы. Конкретная схема выбирается с учётом требований к скорости восстановления.
Распределённая инфраструктура
Организация может иметь несколько центров обработки данных, региональные филиалы и изолированные сегменты. Централизованная передача всех данных в одно место создаёт высокую нагрузку на сеть и увеличивает время копирования.
Распределённая архитектура позволяет размещать медиасерверы или хранилища ближе к источникам. Копия сначала создаётся локально, а затем при необходимости переносится на центральную или резервную площадку.
При проектировании учитываются пропускная способность, задержка, объём ежедневных изменений и допустимое окно передачи. Если канал нестабилен, задание должно корректно продолжаться либо перезапускаться после восстановления связи.
Для закрытых контуров может использоваться физическое перемещение носителей. Такой способ уменьшает зависимость от сетевого канала, но требует строгого учёта, контроля целостности и защиты носителя от утраты.
Защита резервной инфраструктуры
Резервные копии содержат концентрированный массив корпоративной информации. Поэтому серверы RuBackup и хранилища должны рассматриваться как критически важные компоненты.
Доступ к ним следует отделять от обычных пользовательских учётных записей. Сотрудник, управляющий рабочими серверами, не всегда должен иметь право удалить все резервные копии.
Административные интерфейсы размещают в контролируемом сегменте, сетевые соединения ограничивают, а действия операторов регистрируют. Пароли и ключи не следует хранить в открытом виде в общих скриптах и документах.
Полезно иметь хотя бы одну копию, которую нельзя оперативно изменить из производственной инфраструктуры. Это может быть отключённый носитель, отдельная площадка или хранилище с ограничением удаления.
RuBackup получил сертификат ФСТЭК России № 4879 от 25 ноября 2024 года по четвёртому уровню доверия. Для использования в конкретной защищённой системе необходимо сверять область действия сертификата, сертифицированную версию и требования к окружению.
Мониторинг заданий
Автоматизированное копирование должно постоянно контролироваться. Отсутствие сообщения об ошибке ещё не доказывает, что актуальная копия существует.
Задание может не запуститься из-за изменения расписания, нехватки места, потери соединения, блокировки учётной записи или обновления защищаемого приложения. Поэтому важно отслеживать не только статус операции, но и возраст последней успешной точки.
Для критичных систем полезно формировать регулярный отчёт. В нём указываются объект, последняя успешная копия, длительность задания, объём данных и результат последнего тестового восстановления.
Уведомления должны быть настроены так, чтобы важные ошибки не терялись среди большого количества сообщений. Ответственный сотрудник должен понимать, кто и в какие сроки устраняет конкретный сбой.
Проверка восстановления
Успешное резервное копирование и успешное восстановление - разные события. Задание может завершиться без ошибки, но возврат данных окажется невозможным из-за повреждения цепочки, отсутствия ключа или несовместимости целевой среды.
Поэтому восстановление необходимо проверять регулярно. Тесты начинают с отдельного файла, затем переходят к виртуальной машине, базе данных и комплексному бизнес-приложению.
Во время проверки оценивается не только целостность данных, но и фактическое время выполнения. Оно может заметно отличаться от расчётного, особенно при большом объёме, ограниченном канале или использовании ленточных носителей.
Восстановленную систему запускают в изолированной сети. Иначе тестовая база или приложение могут подключиться к рабочим сервисам, отправить сообщения либо выполнить повторные операции.
Результаты испытаний документируют. Если восстановление не уложилось в установленный срок, необходимо изменить архитектуру, расписание или способ хранения.
Масштабирование RuBackup
Потребности в защите растут вместе с объёмом данных и числом систем. Клиент-серверная архитектура позволяет расширять инфраструктуру дополнительными компонентами и хранилищами.
Масштабирование следует планировать заранее. В расчёт включают текущий объём, ежедневный прирост, глубину хранения, ожидаемый коэффициент дедупликации и параллельность заданий.
Недостаточно оценить только ёмкость. Сервер и хранилище должны обеспечивать требуемую скорость записи при копировании и чтения при восстановлении. Иногда резервная копия создаётся в допустимое время, но вернуть её быстро невозможно из-за низкой производительности.
На пилотном этапе полезно моделировать одновременное копирование нескольких крупных объектов. Это помогает обнаружить ограничения сети, процессоров, памяти и дисковой подсистемы до промышленного запуска.
Этапы внедрения
Первым этапом становится инвентаризация. Организация определяет все физические серверы, виртуальные машины, базы данных, приложения и файловые ресурсы.
Далее объекты классифицируются по критичности. Для каждого устанавливаются допустимая потеря изменений, время восстановления и глубина хранения.
После этого проектируются серверные роли RuBackup, сетевые связи, хранилища и резервные площадки. Одновременно создаётся модель доступа и распределяется ответственность.
Затем выполняется пилотный проект. В него желательно включить разные типы объектов: файловый сервер, виртуальную машину, базу данных и одно бизнес-приложение.
На пилоте проверяются полное и инкрементальное копирование, работа расписаний, ограничение пропускной способности, уведомления и восстановление. После успешных испытаний системы подключаются поэтапно.
Завершающим этапом становится разработка регламентов. В них фиксируются порядок реагирования на ошибки, обновления системы, проверки копий и действия при аварии.
Ограничения автоматизированной защиты
Система резервного копирования не может самостоятельно определить все критичные данные. Если новый сервер не добавлен в план защиты, RuBackup не создаст его копию без соответствующей настройки.
Копирование также не заменяет отказоустойчивость. При сбое резервная копия помогает вернуть систему, но на это требуется время. Для сервисов, которые не могут останавливаться, дополнительно используются кластеры, репликация и резервные площадки.
Резервная копия не всегда является юридическим архивом. Долгосрочное хранение документов может предъявлять отдельные требования к неизменности, поиску, срокам и подтверждению подлинности.
Наконец, нельзя размещать все копии рядом с оригиналом. Пожар, затопление, отказ системы хранения или компрометация общей административной учётной записи могут одновременно затронуть оба набора.
Заключение
RuBackup представляет собой российское клиент-серверное решение для автоматизированной защиты данных инфраструктурных систем. Система поддерживает несколько типов резервного копирования, распределённую архитектуру, специализированные модули и разные способы хранения данных.
Централизованное управление позволяет создавать единые правила, контролировать выполнение заданий и снижать зависимость от ручных операций. При этом автоматизация не заменяет инвентаризацию, классификацию данных и разработку плана восстановления.
Результативность RuBackup определяется не только набором функций. Необходимо правильно рассчитать инфраструктуру, изолировать часть копий, разграничить административный доступ и регулярно проводить тестовые восстановления. При соблюдении этих условий система резервного копирования становится частью комплексной защиты данных и обеспечивает управляемое восстановление ИТ-сервисов после сбоев и других инцидентов.
