Поиск и устранение неисправностей в Кибер Бэкапе на Linux

Установка и эксплуатация системы резервного копирования в современных разнородных инфраструктурах требуют от ИТ-инженеров глубоких технических знаний. Ошибки администрирования приводят к сбоям в планах защиты и увеличивают риски потери данных. Понимание архитектуры Кибер Бэкапа и базовых инструментов диагностики помогает оперативно устранять возникающие сложности.

Архитектурная основа и компоненты системы

Для успешной диагностики важно понимать взаимосвязь основных компонентов Кибер Бэкапа. Ядром системы выступает сервер управления. Он координирует работу агентов защиты, узлов хранения и сетевых папок SMB или NFS.

Агенты защиты осуществляют непосредственное резервное копирование. Они бывают двух видов:

• Безагентные (Agentless). Для среды виртуализации Microsoft Hyper-V агент устанавливается непосредственно на хост-сервер. Для других платформ виртуализации (например, VMware vSphere или zVirt) агент поставляется и импортируется в виде специальной виртуальной машины Virtual Appliance.
• Агентские (Agent-based). В этом случае агент устанавливается напрямую в гостевую операционную систему физического сервера или виртуальной машины.

Второй метод незаменим, когда требуется сохранить сложные логические структуры дисков, включая менеджер логических томов (LVM) на Linux-системах. Безагентное резервное копирование не распознает разметку LVM внутри гостевой ОС. При восстановлении это приведет к созданию простых дисков без сохранения исходной логической структуры.

Важной частью экосистемы выступает Кибер Хранилище. Это программно-определяемая система хранения данных, которая разворачивается на стандартном оборудовании архитектуры x86-64 и поддерживает работу с объектным протоколом Amazon S3.

Инструменты мониторинга и расположение журналов

Диагностика любой неполадки в Кибер Бэкапе начинается с анализа логов и оповещений в веб-консоли. Вкладка «Обзор» предоставляет общую информацию о состоянии защищаемых систем. Вкладка «Оповещения» фиксирует сообщения об ошибках с указанием их критичности. Вкладка «Действия» сохраняет историю последних операций в системе.

Для долгосрочного хранения логов аудита мы рекомендуем настроить выгрузку событий на внешний Syslog-сервер или в SIEM-систему. Кибер Бэкап также поддерживает передачу данных телеметрии в системы Prometheus и Grafana.

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

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

• Acronis/AMS — журналы и файлы сервера управления
• Acronis/BackupAndRecovery/MMS — данные агента защиты
• Acronis/BackupAndRecovery/ASN — журналы работы узла хранения
• Acronis/ServiceProcess — журналы выполнения заданий

Типичные неполадки и методы их устранения

Рассмотрим четыре наиболее распространенные проблемы при развертывании СРК на ОС семейства Linux и способы их решения.

Проблема 1. Сбой компиляции модуля ядра SnapAPI

Для блочного резервного копирования дисков необходим низкоуровневый модуль SnapAPI (аналог VSS в ОС Windows). Установка модуля часто прерывается, если в операционной системе отсутствуют пакеты заголовков ядра (kernel-devel), компилятор gcc или make. Их необходимо установить перед запуском инсталлятора СРК.

Если политики информационной безопасности строго запрещают размещать средства разработки на продуктивных серверах, используйте механизм DKMS (Dynamic Kernel Module Support). Вы можете собрать модуль SnapAPI на тестовом стенде с идентичной версией ядра, экспортировать готовый бинарный архив (tarball) и выполнить чистую установку на «боевые» машины без компиляторов. Подробнее читайте в Базе знаний.

Проблема 2. Заблокированная учетная запись root

Некоторые отечественные дистрибутивы (например, РЕД ОС) по умолчанию блокируют учетную запись root. Авторизоваться в веб-консоли Кибер Бэкапа из-под нее не получится.

1) Создайте альтернативного локального пользователя с идентификатором пользователя UID=0 и идентификатором группы GID=0 (группа root)
2) Добавьте новое имя пользователя в конфигурационный файл по абсолютному пути /etc/security/acronisagent.conf
3) Выполните обязательный перезапуск служб сервера управления и агента в терминале Linux

Проблема 3. Блокировка SnapAPI при включенном Secure Boot

При включенной функции безопасной загрузки (Secure Boot) операционная система заблокирует запуск неподписанных модулей ядра. В процессе установки инсталлятор генерирует специальные ключи Machine Owner Key (MOK). После завершения установки администратору необходимо перезагрузить сервер.

Внимание: во время перезагрузки системы автоматически откроется синее окно консоли управления MOK. У администратора есть всего около 10 секунд, чтобы нажать любую клавишу и подтвердить импорт сгенерированного ключа с вводом пароля. Если пропустить этот таймаут, операционная система заблокирует запуск модуля SnapAPI, и низкоуровневый бэкап дисков работать не будет.

Проблема 4. Сбой регистрации агента из-за сетевых настроек

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

Если автоматическая регистрация прерывается ошибкой разрешения доменных имен (DNS lookup failed), выполните ручную привязку:

1) Запишите соответствие IP-адреса и доменного имени сервера управления в системный файл /etc/hosts на стороне агента
2) Перейдите в веб-консоль управления в раздел «Устройства» → «Добавить» и сгенерируйте временный «Маркер регистрации» (токен)
3) Запустите ручную регистрацию с помощью консольной утилиты по ее полному пути 

Порты, используемые для работы компонентов Кибер Бэкапа, показаны на схеме ниже:

Как вручную зарегистрировать агент на сервере управления читайте в Базе знаний. 

Демонстрация

Мы подробно разобрали ключевые аспекты архитектуры и распространенные ошибки администрирования на вебинаре с демонстрацией. Наш инженер техподдержки Егор Киселев показал установку СРК, обход блокировки УЗ root и сборку SnapAPI через DKMS без компиляторов. Вы увидите генерацию отчета диагностики и весь процесс импорта ключей MOK.

Запись вебинара «Быстрый старт: поиск и исправление ошибок в Кибер Бэкапе»

Часто задаваемые вопросы (FAQ)

Подскажите рекомендации по использованию виртуальных машин-агентов (Virtual Appliance) для среды виртуализации zVirt. Необходимо ли устанавливать их на каждый хост? Может ли виртуальная машина-агент с одного хоста выполнять резервное копирование виртуальных машин с другого хоста?

Для резервного копирования виртуальных машин в среде zVirt технически достаточно иметь всего одного агента на весь кластер виртуализации. Однако на практике мы рекомендуем разворачивать по одной виртуальной машине-агенту (Virtual Appliance) на каждый физический хост zVirt — это позволит оптимизировать нагрузку и избежать передачи больших объемов трафика резервного копирования между хостами. В зависимости от интенсивности задач резервного копирования рекомендуется при необходимости увеличивать выделенные ресурсы виртуальной машины агента (количество ядер центрального процессора и объем оперативной памяти).

Разве при безагентном резервном копировании виртуальная машина восстанавливается без логического менеджера томов (LVM)?

Созданная безагентным способом резервная копия типа «Вся машина» для виртуальной машины с томами под управлением логического менеджера томов (LVM) восстановится успешно и сохранит всю структуру томов при условии, что восстановление производится на тот же самый гипервизор.

При настройке Узла хранения можно ли настроить отдельную учетную запись для работы по протоколу BSP без предоставления ей прав администратора и входа в консоль управления?

Да, это полностью поддерживается. Вы можете разграничить права доступа и настроить выделенную учетную запись для работы протокола резервного копирования Backup Service Protocol (BSP). Подробная пошаговая инструкция опубликована в нашей Базе знаний.

Получается, при установке агента для операционной системы Linux для защиты баз данных тоже обязательно ставить модуль SnapAPI и перезагружать сервер?

Если вы устанавливаете агент защиты на операционную систему, в которой отключена функция безопасной загрузки (Secure Boot), то перезагрузка сервера не требуется. Однако если вы обновили ядро операционной системы Linux, а модуль SnapAPI под новую версию ядра еще не собран, вам потребуется заранее запланировать его пересборку из исходных кодов. Поскольку сервисы баз данных обычно работают непрерывно, а ядра на некоторых дистрибутивах обновляются регулярно, этот момент требует дополнительного контроля со стороны системного администратора.

Как именно работает SnapAPI, где он хранит временные данные моментальных снимков и есть ли ограничения при использовании логического менеджера томов (LVM) на операционных системах Linux?

В процессе создания резервной копии модуль SnapAPI записывает разность измененных блоков данных (дельта-снимки) непосредственно в оперативную память сервера. Каких-либо ограничений или конфликтов при совместном использовании модуля SnapAPI и логического менеджера томов (LVM) на операционных системах Linux нет, данная связка работает стабильно.

Для чего идентификаторы пользователя (UID) и группы (GID) создаваемой альтернативной учетной записи обязательно делать равными 0, если невозможно использовать встроенную запись root? Какие технические проблемы могут возникнуть, если этого не сделать?

С технической точки зрения в рамках архитектуры нашего продукта первичный вход в консоль администрирования и регистрация компонентов должны осуществляться исключительно от имени привилегированного пользователя. Параметры UID=0 и GID=0 создают учетную запись, которая на уровне ядра операционной системы полностью аналогична встроенной записи root. Без этих параметров первичная авторизация и управление агентами защиты будут невозможны.

Зачем вообще нужна сущность «Узел хранения», если при выборе места сохранения резервных копий в плане защиты и так доступны сетевые папки общего доступа по протоколам NFS, SMB и локальные диски? В чем его смысл?

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

• Организация управляемых хранилищ (включая централизованную работу с ленточными библиотеками)
• Использование нашего протокола BSP. Протокол BSP шифрует канал передачи данных и использует собственный эффективный алгоритм обмена, избавляя администратора от необходимости держать открытыми в сети общеизвестные порты протоколов SMB и NFS, которые часто используются злоумышленниками в качестве векторов атак.

Подробно разобрали сценарии использования Узла хранения на вебинаре «Быстрый старт. Использование узла хранения».

Использовать один физический сервер под сервер управления и под узел хранения — это нормальная практика? Или все же лучше разделить их на две отдельные машины?

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

По какой логике работают планы очистки и зачем они применяются?

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

Связанные статьи

• Основные компоненты системы резервного копирования
• Рекомендации по организации резервного копирования
• 10 распространенных ошибок при резервном копировании
• Pre‑ и Post‑скрипты для резервного копирования: автоматизация перед и после бэкапа