09.08.2026

Российский бэкап RuBackup: как устроена система резервного копирования и восстановления данных

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

RuBackup относится к российским системам резервного копирования и предназначен для автоматизированной защиты данных инфраструктурных систем и бизнес-приложений. Разработчик указывает работу с виртуальными средами, физическими серверами, базами данных и другими корпоративными ресурсами. Программное обеспечение включено в Единый реестр российского ПО; государственная карточка продукта актуализировалась в 2026 году.

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

Что такое RuBackup

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

Такое построение позволяет отделить управление резервированием от непосредственного размещения защищаемых данных. Центральная часть отвечает за организацию процессов, а специализированные компоненты взаимодействуют с информационными ресурсами.

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

Зачем требуется централизованная система

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

Централизованная система формирует единый контур управления. В RuBackup предусмотрены средства автоматического резервирования СУБД, виртуальных машин, файловых и иных информационных ресурсов, а также функции восстановления.

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

Полное резервное копирование

При полном резервировании сохраняется весь выбранный информационный ресурс. Для файлового сервера это может быть набор каталогов, для виртуальной машины - её диски и связанные данные, для СУБД - полный резервный набор согласно возможностям соответствующего модуля.

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

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

В RuBackup различные модули поддерживают несколько типов резервирования. Например, документация модуля VMware описывает полное, инкрементальное и дифференциальное копирование, а для Proxmox VE актуальная документация также выделяет полный и инкрементальный режимы.

Инкрементальное резервирование

Инкрементальная схема предназначена для сохранения изменений, появившихся после предыдущих операций резервного копирования.

Предположим, в начале недели была создана полная копия. В последующие дни можно сохранять только изменившиеся данные. Это уменьшает объём передаваемой информации и позволяет чаще формировать новые точки восстановления.

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

Поэтому при эксплуатации важно следить не только за последним успешно завершённым заданием, но и за целостностью всей используемой последовательности.

Поддерживаемые режимы зависят от конкретного модуля и защищаемой платформы, поэтому при проектировании следует проверять документацию именно для нужной СУБД, гипервизора или приложения.

Дифференциальная схема

При дифференциальном копировании сохраняются изменения относительно базовой полной точки. По мере удаления от момента полного резервирования объём дифференциальной копии обычно увеличивается.

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

В RuBackup возможность дифференциального резервирования предусмотрена не для всех сценариев одинаково, поэтому конкретный набор режимов требуется сверять с соответствующим модулем. Например, для VMware официальная документация прямо указывает полный, инкрементальный и дифференциальный варианты.

Выбор метода зависит от допустимого резервного окна, объёма свободного пространства и требований к скорости восстановления.

Расписания резервного копирования

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

В актуальной документации RuBackup 2.9 предусмотрено глобальное расписание. Правила позволяют привязывать определённый тип резервного копирования к ресурсу и времени запуска. Для задания можно определять полный, инкрементальный или дифференциальный режим в тех случаях, когда выбранный ресурс его поддерживает.

Расписание необходимо проектировать с учётом нагрузки. Если одновременно запустить копирование большого количества серверов, узким местом может стать сеть или целевое хранилище.

Поэтому крупные задания часто распределяют по времени. Для одних систем резервное окно приходится на ночь, для других копирование выполняется несколько раз в сутки.

Срочное резервирование

Помимо регулярных операций иногда требуется создать дополнительную копию непосредственно перед изменением системы.

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

Документация RuBackup предусматривает срочное резервное копирование, которое запускается отдельно от постоянного расписания. Подобная возможность доступна как через клиентские средства, так и в рамках административного управления в зависимости от модуля и конфигурации.

Срочный бэкап при этом не заменяет регулярную политику. Он представляет собой дополнительную точку восстановления для конкретной ситуации.

Защита виртуальных машин

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

RuBackup содержит специализированные модули для виртуальных сред. В документации представлены, в частности, средства работы с Proxmox VE и Microsoft Hyper-V, а также отдельные модули других платформ. Для Hyper-V документация указывает резервирование дисков и снимков виртуальной машины, а для Proxmox описываются операции с дисками ВМ.

В апреле 2026 года была опубликована версия RuBackup 2.9. Среди изменений разработчик отметил расширение перечня поддерживаемых платформ виртуализации, включая новый модуль для среды "Горизонт-ВС".

Это показывает, почему совместимость нельзя считать статичной: при планировании необходимо ориентироваться на актуальную версию продукта.

Физические серверы

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

RuBackup позиционируется разработчиком как система защиты не только виртуальных, но и физических серверов.

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

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

Работа с базами данных

СУБД нельзя всегда корректно защитить простым копированием файлов работающего сервера. В момент операции база может изменяться, поэтому резервный набор должен быть сформирован согласованным способом.

В RuBackup применяются специализированные модули для баз данных и других приложений. Общая документация системы относит СУБД к автоматически резервируемым ресурсам.

Для разных систем возможности отличаются. Например, существует отдельная документация для PostgreSQL, а также модули для других типов баз данных. В материалах RuBackup описывается в том числе резервирование NoSQL-систем, где конкретный модуль поддерживает полный и инкрементальный режимы.

При проектировании необходимо проверять не просто наличие поддержки названия СУБД, но и совместимость с её конкретной версией.

Восстановление резервных копий

Цель бэкапа заключается не в создании архива, а в возможности получить данные обратно.

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

Это позволяет распределять ответственность. В одной организации восстановлением занимается только централизованная ИТ-служба. В другой владелец информационной системы может самостоятельно возвращать свои данные.

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

Почему необходимо тестировать восстановление

Сообщение "резервное копирование завершено успешно" ещё не означает, что информационная система гарантированно вернётся в рабочее состояние после аварии.

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

Поэтому резервные копии необходимо периодически использовать в тестовых восстановлениях.

Для файла такой тест сравнительно прост: документ возвращается в отдельный каталог и проверяется. Для базы данных или виртуальной машины требуется изолированная тестовая среда.

Практическое восстановление показывает, соответствуют ли процедуры ожиданиям и достаточно ли производительности инфраструктуры.

Показатель RPO

Recovery Point Objective определяет допустимый объём потери последних изменений.

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

Для архива документов это иногда допустимо. Для активно работающей базы заказов или финансовой системы - нет.

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

RuBackup предоставляет механизм расписаний, но требуемый RPO задаёт не сама программа: его определяет организация на основе своих бизнес-требований. Возможности системы затем используются для реализации выбранной политики.

Показатель RTO

Recovery Time Objective определяет, сколько времени организация может потратить на восстановление сервиса.

Большой объём данных может успешно сохраняться каждую ночь, но его обратная передача займёт много часов.

Поэтому необходимо заранее оценивать скорость восстановления. На неё влияют производительность исходного и целевого оборудования, сеть, формат копий и последовательность необходимых действий.

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

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

Репозиторий резервных копий

Для управления большим количеством версий необходим централизованный репозиторий.

В административных интерфейсах RuBackup операции восстановления связаны с репозиторием, где пользователь выбирает требуемую резервную копию и инициирует её восстановление. Такой порядок, например, описывается в актуальной документации модуля Hyper-V.

Структурированный каталог особенно важен при большом числе информационных систем. Администратор должен быстро найти нужный ресурс и требуемую дату, а не вручную искать архив среди файлов на диске.

С репозиторием также связаны сроки хранения и контроль ёмкости хранилища.

Сроки хранения данных

Создавать новые копии бесконечно невозможно. Даже большое дисковое пространство со временем заканчивается.

Поэтому для резервных данных задаётся срок хранения. Например, ежедневные точки могут сохраняться сравнительно недолго, а некоторые недельные или месячные экземпляры - дольше.

В интерфейсах RuBackup параметры срока хранения используются при формировании резервных операций.

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

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

Использование S3-хранилищ

Резервные системы могут использовать различные типы целевых хранилищ. В актуальной документации RuBackup 2.9 описана работа с S3-совместимыми решениями, включая MinIO, TATLIN.OBJECT, VK Cloud и "Скала^р МХД.О".

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

Например, большое удалённое хранилище способно обеспечить дополнительное размещение копий, но скорость возврата многотерабайтной системы будет зависеть от доступной пропускной способности.

Поэтому тип хранения выбирают не только по ёмкости, но и по требованиям RTO.

Дедупликация

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

Для отдельных модулей RuBackup предусмотрена работа с дедуплицированными хранилищами. Например, такая возможность описана в документации по резервированию VMware vSphere.

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

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

Защита резервной инфраструктуры

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

Необходимо ограничивать административный доступ, контролировать сетевые соединения и разделять полномочия.

Особенно опасна ситуация, когда одна и та же учётная запись имеет неограниченный доступ одновременно к продуктивным серверам и всем резервным копиям. Компрометация такой записи способна затронуть оба уровня.

Резервные хранилища желательно логически отделять от обычной пользовательской инфраструктуры.

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

Защита от логических ошибок и вредоносных действий

Резервирование используется не только при физической поломке оборудования.

Файл может быть случайно удалён пользователем. Ошибочное обновление способно изменить данные. Вредоносное программное обеспечение может зашифровать доступные рабочие каталоги.

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

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

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

Мониторинг выполнения заданий

Автоматическое резервирование требует постоянного контроля.

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

Если резервная копия одного сервера не создаётся несколько недель, проблема может стать заметной только после аварии.

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

Автоматизация уменьшает объём ручных действий, но не отменяет эксплуатационный контроль.

RuBackup и российский программный стек

RuBackup является российским программным продуктом и присутствует в Едином реестре российского ПО. Официальный сайт указывает номер реестровой записи 6808 от 16 июля 2020 года; государственный реестр содержит актуальную карточку системы.

Такой статус может учитываться организациями при построении инфраструктуры на основе отечественного программного обеспечения.

При этом происхождение продукта и техническая совместимость - разные характеристики. Российская СРК не обязательно автоматически поддерживает абсолютно любую отечественную ОС, СУБД или платформу виртуализации.

Перед внедрением необходимо проверять конкретную матрицу совместимости и документацию выбранного модуля.

Актуальная версия и развитие системы

По состоянию на 2026 год документация представлена для ветки RuBackup 2.9. В апреле разработчик сообщил о выпуске версии 2.9 с расширением перечня поддерживаемых платформ виртуализации.

Это важный момент для информационных материалов: перечень интеграций и возможностей может изменяться от версии к версии.

Поэтому характеристики старых выпусков нельзя автоматически переносить на новую версию, и наоборот.

Перед проектированием промышленной системы необходимо сверять возможности непосредственно в актуальной документации.

Как планировать внедрение RuBackup

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

Второй этап - классификация по критичности. Для каждого объекта определяются RPO, RTO и срок хранения.

Затем рассчитываются объёмы. Важно учитывать не только текущий размер данных, но и скорость их роста.

Следующий вопрос - архитектура сети. Резервное копирование большого массива через канал с недостаточной пропускной способностью может не помещаться в доступное окно.

После этого выбираются типы хранилищ и расписания.

До промышленного запуска желательно проверить систему на пилотной группе ресурсов и обязательно провести восстановление тестовых данных.

Типичные ошибки при резервном копировании

Одна из наиболее распространённых проблем - наличие только одного резервного экземпляра рядом с основной системой.

Вторая - отсутствие контроля. Автоматическое задание существует, но никто не проверяет его статус.

Третья - отсутствие регулярных тестов восстановления.

Ещё одна проблема возникает после изменения инфраструктуры. Новый сервер вводят в эксплуатацию, но забывают добавить в политику резервирования.

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

Заключение

RuBackup - российская клиент-серверная система резервного копирования, предназначенная для автоматизированной защиты данных корпоративной ИТ-инфраструктуры. Она работает с различными категориями информационных ресурсов, включая физические серверы, виртуальные среды и базы данных, а её архитектура строится вокруг основного сервера, служебной базы и дополнительных компонентов резервного копирования.

В системе предусмотрены расписания, централизованные и локальные сценарии восстановления, а для разных модулей доступны полное, инкрементальное и в отдельных случаях дифференциальное резервирование. Актуальная версия 2.9 продолжает расширять поддержку инфраструктурных платформ.

RuBackup включён в российский реестр программного обеспечения, однако этот статус необходимо рассматривать отдельно от технической совместимости. Для каждого проекта следует проверять поддержку конкретных версий ОС, гипервизоров, СУБД и систем хранения.

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

Главный критерий работоспособности резервной системы - возможность получить нужные данные обратно в установленный срок. Поэтому RuBackup следует рассматривать как технологический компонент более широкой стратегии устойчивости ИТ-инфраструктуры, куда входят мониторинг, защита доступа, отказоустойчивость и заранее подготовленный план аварийного восстановления.

Смотрите также

Для любых предложений по сайту: healthierworld@cp9.ru