Привет, Хабр! Сегодня рассмотрим самые популярные вопросы, с которыми пользователи Кибер Бэкапа обращаются в техническую поддержку.

Развертывание и лицензирование

1. Насколько мощной должна быть машина для развёртывания Сервера Управления?

Данный вопрос связан с неверным пониманием архитектуры Кибер Бэкапа. Да, в традиционной клиент-серверной архитектуре подразумевается наличие мощного сервера как центра обработки всего на свете и небольших передающих модулей - агентов. В нашем продукте все устроено ровно наоборот. Всю работу по формированию архива из сырых данных, а также по перемещению пакетов полученного архива, верификации, дедупликации и прочим интересным штукам делают агенты, мощные и независимые. И ресурсы потребляют именно агенты А вот сервер управления нужен для работы нашего замечательного универсального веб-интерфейса. Здесь пользователь может настроить планы защиты своих машин, проверить статистику, узнать о наличии ошибок и предупреждений в работе агентов и назначить им лицензионные ключи. Таким образом, сервер управления, несмотря на присутствие в названии слова «сервер», — скорее диспетчерский компонент, который преобразует данные планов в скрипты, рассылает их агентам и подтверждает валидность лицензии, назначенной на агента. Попутно отметим, что агенты могут работать без сервера управления до 30 дней. Получив скрипт, агенты выполняют его по заданному расписанию самостоятельно, без обращения к серверу управления.

Если в вашей среде используется от 10 до 100 агентов, то под сервер управления достаточно выделить сравнительно маломощную машину, или же развернуть сервер на машине с другим ПО, совместив несколько ролей сервера. Если же число агентов/виртуальных машин становится больше, то серверу управления потребуется больше ресурсов — 8+ ядер ЦПУ, 8+ ГБ ОЗУ, SSD 10-16 ГБ и внешняя СУБД.

2. Сколько стоит лицензия для сервера управления?

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

3. Почему купленный мной лицензионный ключ не подходит?

Лицензионные ключи в нашем продукте имеют привязку по мажорным версиям. После выхода Кибер Бэкапа 16-й версии в апреле этого года мы продаём лицензионные ключи, совместимые именно с 16-й версией продукта. Системные администраторы, не обновившие Кибер Бэкап до новой версии и пытающиеся расширить количество защищаемых хостов, приобретают новый ключ, а  продукт 15-й версии его не принимает, и не должен. Выходов из ситуации два — обновить Кибер Бэкап до последней сборки (это — рекомендуемый нами сценарий) или отправить нам заявку на смену версии лицензионного ключа.

4. Почему лицензионный ключ для АРМ нельзя назначить на ОС на базе Linux?

Иногда случается что менеджер реселлера не уточняет, какая ОС стоит на защищаемых АРМ-ах, и продаёт покупателю пакет самых дешёвых лицензий — лицензий для рабочих станций. Но архитектура нашего продукта устроена так (и это сложилось исторически), что все машины под управлением ОС на базе Linux воспринимаются агентами, как серверные. Поэтому для лицензирования агентов на таких машинах необходимо приобрести серверный тип лицензии, даже если у вас эти машины выполняют роль простых рабочих станций.

5. Почему после покупки лицензионного ключа недоступна часть функционала?

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

Использование продукта

6. Неполадки с VSS

Существенная часть обращений в поддержку связана с отказом в работе того или иного средства записи (райтера) VSS. Особенно это касается работы с приложениями Microsoft, при резервном копировании почтовых ящиков и баз Exchange и контроллеров домена Active Directory. В случаях неполадок с VSS помогает диагностика состояния службы VSS с помощью специализированных утилит, например VSS Doctor, либо штатными средствами ОС Windows. Например, можно вывести список активных средств записи и посмотреть, какие из них «упали» и почему, а поиск по Базам Знаний Microsoft подскажет как исправить проблему. Отметим, что неполадки с VSS касаются не только работы с физическими серверами под управлением ОС семейства Windows, но и при работе с платформами виртуализации, поддерживающими службу VSS в гостевых ОС.

7. Некорректная сборка модуля SnapAPI при установке продукта на ОС Linux

Иногда попытка установить Кибер Бэкап на машину с ОС Linux заканчивается ошибкой типа «Не удалось построить модуль ядра SnapAPI. Операции с резервными копиями на уровне дисков будут недоступны.» Как правило, такая ошибка говорит о том, что перед установкой нашего продукта были  установлены не все требуемые пакеты, либо о несоответствии версии ядра. В таких случаях необходимо проверить что все пакеты, упомянутые в нашей документации (см. здесь, стр. 38) как необходимые, корректно установлены в ОС и при необходимости установить недостающие, а также обновить версию ядра до поддерживаемой. После этого можно повторно попытаться развернуть агент из дистрибутива, либо собрать модуль SnapAPI вручную, этому посвящена статья в нашей Базе знаний.

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

8. Восстановленная машина заменяет собой старую

Иногда у пользователей возникает следующая проблема. Если восстановить из резервной копии типа «Вся машина» не в исходное место, а на другое шасси (или на новую виртуальную машину), так, чтобы в сети оказалось две машины: старая и новый клон, в веб-интерфейсе новая машина займёт место старой, а при попытке зарегистрировать заново старую, она займёт место новой. Причина заключается в том, что при восстановлении получился полный клон, новая машина имеет тот же уникальный ID агента, что и старая. Поэтому для сервера управления они — как один и тот же агент, который почему-то меняет ip-адреса. Решением будет удаление агента на одной из машин при помощи нашей внутренней утилиты очистки (доступна по запросу) и повторная установка агента после этого, либо ручная замена UUID агента — подробности см. в этой статье в Базе знаний.

9. Ручное перемещение файлов архивов резервных копий

Иногда, для реорганизации хранилища и освобождения места, пользователи переносит файлы архивов *.tibx вручную, через проводник либо командную строку ОС. В результате рушатся связи между частями архива, нарушаются цепочки инкрементов и при попытке восстановления данных может возникнуть ошибка типа: «Нарушена целостность архива». Не следует переносить файлы архивов вручную, рекомендуем воспользоваться функцией репликации, доступной в нашем продукте, а ненужные архивы и точки восстановления удалять через веб-интерфейс продукта.

10. Невозможно гранулярно восстановить файлы и папки из дискового архива с дедупликацией на уровне файловой системы NTFS

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

11. Ограничение файловой системы NTFS на фрагментированность файла

При резервном копировании с хранилищем на томе с файловой системой NTFS может возникнуть ошибка: «Ошибка Windows: (0x80070299) Запрошенная операция не может быть завершена из-за ограничения файловой системы.»

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

Мы рекомендуем заранее форматировать тома NTFS, которые вы планируете использовать под хранение массивных архивов,  с размером кластера 64 Кб, вместо стандартных 4 Кб,  и при форматировании включить поддержку больших сегментов файловых записей (FRS). Подробнее о NTFS см. здесь.  Также помогает включение в плане резервного копирования разбиения архива на тома, например, по 500 Гб. В 16-й версии Кибер Бэкапа разбиение поддерживается даже при хранении резервной копии в управляемых хранилищах, чего не было в предыдущих версиях продукта.

12. Прекращение резервного копирования после обновления ОС, либо обновления агента

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

Причина часто скрывается в том, что закрыты порты, необходимые модулям нашего продукта для успешного обмена данными. Порт может быть закрыт изначально, или закрыться после некоторых обновлений. Мы рекомендуем проверять связь между модулями и соответствующими узлами с помощью утилиты telnet. Список портов, используемых для работы компонентов Кибер Бэкапа можно посмотреть в статье в нашей Базе знаний.

13. Порты открыты, сеть исправна, но агент отображается, как недоступный

Самая частая причина этой проблемы — сбой в работе соответствующей службы (Management Machine Service в Windows и mms в Linux). Зачастую для восстановления корректной работы в таких случаях достаточно перезапустить службу, либо сменить учётную запись, от имени которой служба запускается, на корректную. Список служб для ОС Windows приведен в Базе знаний здесь, а для ОС Linux — здесь.

14. Перенос сервера управления

К этой задаче также относится задача резервного копирования сервера управления для обеспечения отказоустойчивости. К сожалению, на данный момент для нашего продукта нет никаких сценариев дублирования, резервного копирования или переноса сервера. Агент может быть подключен одновременно только к одному серверу управления. Перенос возможен только на идентичное шасси методом резервного копирования всей машины и восстановления его на новом сервере (или как виртуальную машину). При необходимости миграции сервера управления, скажем, с ОС Windows на Linux можно только попробовать экспортировать в файлы планы резервных копий с последующим импортом их на новый сервер. А сам сервер на новом месте необходимо будет развернуть с нуля и вручную зарегистрировать на нём всех агентов.

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

15. При некоторых ошибках резервного копирования необходимо проверить работу протокола SMB

В случае возникновения ошибок при резервном копировании в сетевую папку, доступ к которой предоставлен посредством SMB, мы рекомендуем попробовать смонтировать сетевую папку вручную и записать в нее данные средствами ОС, без участия агента. В зависимости от полученного результата будет понятно, есть ли проблема в работе протокола SMB и если есть, то какая именно. В результате понадобиться предпринять некоторые шаги, например, ручное указание используемой версии, что бывает востребовано при работе с некоторыми СХД, плохо работающими с SMB версии 3 - более подробно см. статью в Базе знаний.

И завершим наш парад популярных вопросов бесплатным советом. 

Одной резервной копии мало

Не самый популярный, но самый важный и краеугольный момент. Сам факт того, что вы сделали одну резервную копию и храните ее в одном месте не спасёт вас от всех бед. Архивы резервных копий тоже могут испортиться (из-за повреждения жёсткого диска, например), и тогда вся идея резервного копирования пойдёт прахом. Если архивы резервных копий у вас хранятся в единственном экземпляре, то можно считать что у вас и нет резервных копий. Не часто, но регулярно в техподдержку обращаются пользователи с битым архивом и необходимостью что-то восстановить, а восстанавливать нечего. Потому для надёжного хранения критически важной информации используйте правило «3-2-1»: храните три резервных копии данных на двух разных типах носителей и храните одну копию вне офиса. 

И напоследок. Много полезного можно найти в нашем цикле, посвященном развертыванию КБ. Первая часть здесь, вторая — здесь.

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