Кибер Бэкап 17 — основные сущности

[!info]
Основная модель приведена по руководству Кибер Бэкап 17.4 и актуальным статьям базы знаний Киберпротекта, обновлённым в 2025–2026 годах.

В интерфейсе близкими словами могут называться разные уровни:

vCenter
└── ESXi-хост
    └── виртуальная машина
        └── гостевая ОС
            └── приложение
                └── база данных

Перед созданием плана нужно определить:

1. какой объект выбран источником;
2. какой агент его обслуживает;
3. на каком уровне создаётся снимок;
4. на каком уровне будет выполняться восстановление.

Состояния устройства

• Обнаруженное — объект найден, но агент не установлен или объект не управляется.
• Управляемое — объект обслуживается зарегистрированным агентом.
• Защищённое — назначен план защиты.
• Незащищённое — применённого плана нет.

Управляемое ≠ защищённое
Есть агент ≠ есть успешная копия
Есть план ≠ план выполнялся

Внутренний идентификатор

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

Клиент с таким идентификатором уже создан
Агент уже зарегистрирован

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

План защиты — постоянный набор правил.

Он определяет:

• источник;
• расписание;
• место сохранения;
• срок хранения;
• обработку ошибок;
• дополнительные параметры;
• модули защиты.

План ≠ запуск
План ≠ резервная копия

План как контейнер модулей

В одном плане могут находиться модули:

• резервное копирование;
• Active Protection;
• оценка уязвимостей.

К одному устройству можно применить несколько планов, только если их активные модули не конфликтуют.

План A: резервное копирование
План B: оценка уязвимостей

допустимо.

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

создаёт конфликт.

План устройства и план группы

Если устройство входит в группу с назначенной политикой, конфликтующий индивидуальный план потребует:

• удалить устройство из группы;
• изменить групповой план;
• применить новый план всей группе.

Групповой план является наследуемой политикой, а не просто массовой кнопкой.

Редактирование общего плана

При изменении через одно устройство интерфейс может предложить:

Применить изменения ко всему плану

или:

Создать новый план только для выбранных устройств

Первый вариант меняет конфигурацию всех назначенных машин.

Задание

Задание — исполняемая работа, созданная из плана или ручной команды.

Внутри продукта задания обслуживаются подсистемой Task Manager.

Действие

Действие — конкретный зарегистрированный запуск.

Примеры:

• создание копии;
• восстановление;
• применение плана;
• проверка;
• репликация;
• очистка;
• установка агента.

Действие содержит:

• время;
• статус;
• устройство;
• агент;
• план;
• журнал;
• код ошибки;
• дочерние этапы.

Родительские и дочерние действия

Запуск плана
├── машина 01
├── машина 02
├── машина 03
└── машина 04

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

История действий

По умолчанию вкладка Действия хранит историю 180 дней.

Файл конфигурации:

Windows:
%ProgramFiles%\Acronis\TaskManager\task_manager.yaml

Linux:
/usr/lib/Acronis/TaskManager/task_manager.yaml

Киберпротект предупреждает:

• сильное уменьшение срока может удалить незавершённые активности;
• сильное увеличение ухудшает производительность сервера управления.

Удалена запись действия ≠ удалена копия
Есть запись действия ≠ данные физически доступны

Зависшие действия

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

Это означает:

• состояние может храниться на сервере управления;
• перезапуск агента не всегда очищает центральную запись;
• аварийная очистка базы Task Manager не удаляет архивы;
• такие процедуры нельзя считать штатной отменой.

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

Резервная копия — сохранённое представление данных на определённый момент.

Полная

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

Инкрементальная

Содержит изменения после предыдущей копии. Зависит от цепочки.

Дифференциальная

Содержит изменения после полной копии.

Отменённая полная копия

Актуальная статья Киберпротекта фиксирует:

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

Незавершённая полная копия не может быть базой цепочки.

FULL
├── INC-01
├── INC-02
└── INC-03

или:

FULL
├── DIFF-01
│   └── INC-01
└── DIFF-02

Почему очистка не всегда освобождает место

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

Временно могут превышаться:

• срок хранения;
• число копий;
• лимит размера;
• фактическое потребление места.

Последняя копия, созданная планом, сохраняется даже при нарушении правила хранения.

В хранилище копии группируются по шаблону:

<имя машины> - <имя плана защиты>

Такую группу можно считать пользовательским представлением архива.

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

Экспорт

Создаёт одну самодостаточную полную копию выбранной точки.

Точка из цепочки -> независимая полная копия

Репликация

Переносит резервные копии в другое расположение с сохранением истории.

Одна независимая точка -> экспорт
История и цепочки -> репликация

Ручное перемещение файлов

Руководство запрещает вручную редактировать файлы резервных копий и рекомендует экспорт или репликацию.

cp, mv, rsync и файловые менеджеры не понимают внутреннюю структуру TIBX, состояние записи и каталог продукта.

Агент
  -> Узел хранения
      -> Управляемое хранилище
          -> NFS / SAN LUN / локальная ФС

Узел хранения = серверная служба
Управляемое хранилище = логический объект
Физический путь = backend

В дедуплицированном управляемом хранилище:

• используется формат версии 11;
• TIBX версии 12 не поддерживается;
• постоянная репликация может снижать производительность;
• нагрузка зависит от CPU, RAM, дисков и базы дедупликации.

Проверка определяет возможность чтения копии.

Методы:

• контрольные суммы;
• запуск ВМ.

Контрольная сумма не подтверждает работоспособность приложения. Запуск ВМ не заменяет функциональный тест сервиса.

В матрице 17.4 отдельные планы проверки не поддерживают NFS-папки.

Квота назначается устройству и разрешает определённые функции.

При несоответствии квоты плану требуется:

• изменить квоту;
• отключить неподдерживаемые модули.

Актуальная база знаний содержит отдельную статью:

Лицензии числятся назначенными после удаления устройств

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

1. Кибер Бэкап 17.4 — руководство пользователя
   https://docs.cyberprotect.ru/ru-RU/CyberBackup/17.4/CyberBackup_userguide_ru-RU.pdf

2. Кибер Бэкап 17.4 — справочник командной строки
   https://docs.cyberprotect.ru/ru-RU/CyberBackup/17.4/CyberBackup_cmdlineref_ru-RU.pdf

3. Формат архива резервных копий версии 12 (TIBX)
   https://kb.cyberprotect.ru/articles/515

4. Если отменить полное резервное копирование машины
   https://kb.cyberprotect.ru/articles/462

5. Лицензии числятся назначенными после удаления устройств
   https://kb.cyberprotect.ru/articles/457

6. Завершение заданий в разделе «Действия» вручную
   https://kb.cyberprotect.ru/articles/activity

7. Не запускаются новые планы в 17.3/17.4
   https://kb.cyberprotect.ru/articles/534

8. Повторный идентификатор при регистрации агента
   https://kb.cyberprotect.ru/articles/already-reg

9. Отключение и повторное подключение хранилищ
   https://kb.cyberprotect.ru/articles/attach-detach

10. Часто задаваемые вопросы
    https://kb.cyberprotect.ru/articles/124