Связаться с экспертомПопробовать бесплатно
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ООО «Яндекс.Облако»

Решение проблем в Cloud Backup

Статья создана
Обновлена 20 августа 2026 г.
Открыть в Markdown

В этом разделе описаны типичные проблемы, которые могут возникать при работе Cloud Backup, и методы их решения.

Почему ВМ или сервер BareMetal не добавляются в Cloud Backup?

Убедитесь, что:

Подробнее в статье Подключение виртуальных машин Compute Cloud к Cloud Backup.

Подробнее в статье Подключение сервера BareMetal к Cloud Backup.

Как заново подключить к сервису ВМ или сервер BareMetal, удаленные из Cloud Backup?

Если вы удалили ВМ или сервер BareMetal из Cloud Backup и хотите подключить их к сервису заново, воспользуйтесь инструкциями:

  • Заново установите агента Cloud Backup, воспользовавшись инструкцией.

Как заново подключить ВМ или сервер BareMetal к Cloud Backup после восстановления резервной копии в другую ВМ или другой сервер?

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

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

Почему не удаляются старые резервные копии после переподключения ВМ к Cloud Backup?

При переподключении ВМ добавляется в Cloud Backup как новый ресурс. Резервные копии новой ВМ хранятся согласно привязанной политике резервного копирования.

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

Ошибка при попытке восстановить ВМ или сервер BareMetal из резервной копии

Текст ошибки:

Not all of the items are mapped. Please, check your goal instance and its volumes.

Ошибка возникает из-за того, что Cloud Backup не может найти подходящий по размеру диск на целевой машине.

Размер загрузочного диска целевой ВМ или сервере BareMetal должен быть не меньше размера загрузочного диска исходной машины.

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

Примечание

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

Ошибка при подключении ВМ на Windows

Текст ошибки:

Fetching agent id from config
Iteration 0: The term 'acropsh' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Убедитесь, что:

Ошибка авторизации при установке агента Cloud Backup на ВМ Linux

Текст ошибки:

Failed to parse cloudbackup from instance attributes IAM token and instance registration id are empty, unable to provide authorization

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

Убедитесь, что:

  • К виртуальной машине привязан сервисный аккаунт.
  • Сервисному аккаунту назначена роль backup.editor.

Как обновить агент Cloud Backup на ВМ?

Используйте инструкцию Обновить агент Cloud Backup на ВМ.

Почему после обновления ОС перестало работать резервное копирование?

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

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

Чтобы восстановить работоспособность агента Cloud Backup, нарушенную после обновления ядра ОС, необходимо обновить версию заголовков ядра Linux, на которую ориентируется DKMS при сборке модуля SnapAPI. Как только версия заголовков ядра станет соответствовать версии ядра, DKMS пересоберет модуль SnapAPI под нужную версию ядра Linux при следующем запуске защищаемого ресурса.

Чтобы обновить версии заголовков ядра Linux, воспользуйтесь инструкцией Восстановить работоспособность агента Cloud Backup после обновления ядра Linux.

Почему создание резервной копии занимает так много времени?

Возможные причины:

  • Высокая степень сжатия резервной копии.

    В спецификации политики резервного копирования описаны степени сжатия:

    • COMPRESSION_UNSPECIFIED — не задано;
    • NORMAL — стандартное сжатие;
    • HIGH — сильное сжатие;
    • MAX — максимальное сжатие;
    • OFF — отключено.

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

  • Не используется отслеживание содержимого резервных копий (Changed Block Tracking).

    В сервисе Cloud Backup эта логика задается через параметр cbt в спецификации политики резервного копирования. У него есть несколько вариантов значений:

    • CHANGED_BLOCK_TRACKING_UNSPECIFIED — значение по умолчанию (не задано);
    • USE_IF_ENABLED — использовать, если функция включена;
    • ENABLE_AND_USE — явно включить и использовать;
    • DO_NOT_USE — не использовать вообще.

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

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

  • Параметр fastBackupEnabled в значении false.

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

    • Если fastBackupEnabled: true — изменения определяют по размеру файла и его временной метке (timestamp). Это и есть суть «быстрого» резервного копирования.
    • Если fastBackupEnabled: false — сервис будет сравнивать все содержимое файла с тем, что уже есть в резервной копии, чтобы понять, есть ли изменения.

  • Большой размер диска, над которым проводится резервное копирование.

Создание инкрементальных резервных копий ВМ или сервера BareMetal занимает больше времени, чем обычно

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

Out-Of-Memory Killer (OOM Killer) в Linux завершает процесс агента Cloud Backup

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

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

Примечание

Ограничение использования оперативной памяти агентом Cloud Backup может привести к снижению скорости выполнения операций резервного копирования и восстановления данных.

Как восстановить ВМ или сервер BareMetal с LVM из резервной копии?

Если для организации дискового пространства защищаемого ресурса вы используете LVM, ознакомьтесь с особенностями восстановления ресурсов с LVM в Cloud Backup.

Проблемы с установкой агента Cloud Backup на ВМ с низкими вычислительными ресурсами

Установка агента Cloud Backup является ресурсоемкой операцией. Если вы хотите использовать виртуальную машину в минимально возможной конфигурации или, например, ВМ с уровнем производительности vCPU ниже 100%, рекомендуем на время установки агента Cloud Backup увеличить ресурсы ВМ.

Почему размер бэкапов Cloud Backup в консоли не совпадает с фактическим размером самих резервных копий?

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

Размер каждого архива можно посмотреть с помощью интерфейса командной строки Yandex Cloud — командой yc backup backup list-archives.

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

Примечание

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

Если удалить ВМ, ее резервные копии останутся?

Да, резервные копии останутся после удаления ВМ. Резервные копии привязаны к политике резервного копирования, а не к ВМ.

Возникает ошибка с кодом 400 при установке агента

Полный текст ошибки:

Cloud backup service request for registering agent failed: unexpected status code: url=<https://backup.api.cloud.yandex.net/backup/agent/v1/api/registerAgent>, status=400

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

Для решения попробуйте переподключить виртуальную машину к Cloud Backup.

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

Как посмотреть журналы использования сервиса Cloud Backup?

В системах на базе ядра Linux, например Ubuntu, файлы журналов Cloud Backup можно найти по следующим путям:

  • /var/log/baas-agent-installer/log.txt
  • /var/log/trueimage-setup.log
  • /var/log/Acronis

В Windows-системах журнал Cloud Backup находится в файле %AppData%\BackupAgentInstaller*.log.

Также можно собрать локальный системный отчет:

  • Linux: запустите сценарий bash с привилегиями root для сбора отчета: /usr/lib/Acronis/BackupAndRecovery/systeminfo.
  • Windows: запустите C:\Program Files\Common Files\Acronis\AdvReport\systeminfo.exe.

Более подробно об этом описано в документации провайдера резервного копирования.

Возникает ошибка Unable to install agent при установке

Чаще всего ошибка возникает на этапе сборки модуля ядра snapapi26. Это происходит, когда версия устанавливаемого модуля не соответствует версии ядра вашей виртуальной машины.

Чтобы проверить статус агента и убедиться, что он действительно не зарегистрировался в сервисе, выполните в Yandex Cloud CLI команду:

yc backup vm get <идентификатор_ВМ> --folder-id <идентификатор_каталога>

Если агент не установлен или не зарегистрирован, команда вернет ошибку или пустой ответ.

Для решения проблемы:

  1. Проверьте логи установки. Подключитесь к ВМ по SSH и изучите следующие файлы. Чаще всего корень проблемы кроется именно там:

    /var/log/baas-agent-installer/log.txt
/var/log/trueimage-setup.log (в этом файле обычно и видны ошибки сборки snapapi26)
/var/log/Acronis

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

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

  • Идентификатор виртуальной машины.
  • Перечисленные выше лог-файлы.

ВМ Cloud Backup долго находится в статусе «Регистрируется»

Скорее всего, к виртуальной машине не прикреплен сервисный аккаунт. Для корректной работы Cloud Backup нужно прикрепить к виртуальной машине сервисный аккаунт с минимальной ролью backup.user.

После добавления сервисного аккаунта нужно вручную установить агент на ВМ.

Предыдущая
История изменений