Производительность резервного копирования установки BackupExec внезапно упала на 50-70% без видимой причины. Не было ни вмешательства пользователя, ни реконфигурации, ни обновлений, и все ленты были затронуты сразу. Система развернута в 32-разрядной системе Windows 2003 SBS, удаленные агенты не задействованы (кроме локального, что означает отсутствие участия в сети).
Я не нахожу никаких подсказок о причине сбоя. В результате резервное копирование автоматически отменяется через 6 часов, тогда как раньше оно занимало 4 часа, и было обработано только около 50% файлов и 20% объема данных по сравнению с обычным запуском полного резервного копирования. Емкость ленты тоже не используется (раньше 90%, теперь только малая).
Я попытался отключить резервное копирование отдельных экземпляров, а также попытался отказаться от использования поставщиков моментальных снимков, но безрезультатно.
Сообщение об ошибке отсутствует, так как время ожидания задания резервного копирования истекает, прежде чем оно может быть завершено (так что на самом деле ошибка - «задание резервного копирования не было завершено в течение времени» или подобное).
Обновить: Проблема сохраняется с AOFO или без него. Мы также запустили чистящую ленту. 4 ленты используются уже около 2 лет, одна лента довольно свежая. Оба поколения лент показывают одни и те же проблемы, поэтому, похоже, они не связаны с лентой. Однако мы собираемся попробовать еще раз с совершенно новым.
Есть идеи, как это отладить?
Вы можете отлаживать BEX с помощью утилиты SGMon, она находится в каталоге программы .. однако она имеет довольно обширный вывод ..
Вы также можете создавать более мелкие задания и запускать их последовательно или, чтобы сначала создать резервную копию в «папке», а затем запустить «дублирующее» задание резервного копирования на ленту. Если он не справляется с заданием папки, это проблема с сетью / источником, если сбой на ленте, это проблема с диском [r] / лентой.
Один из наших серверов начал делать что-то вроде этого, мы как можно скорее заменили сам диск, проблема решена.
Должен быть задействован хотя бы один удаленный агент, тот, что на сервере, резервное копирование которого выполняется, даже если это сам сервер резервного копирования. Проверяли ли вы ленточный накопитель на наличие ошибок или предупреждений? ленточный накопитель нуждается в чистке? Вы используете AOFO?
Емкость ленты тоже не используется (раньше 90%, теперь только малая).
Я видел подобное поведение, и проблема заключалась в том, что набор лент был X несжат, а X * 2 сжат. Как только я получил больше X, резервное копирование замедлилось (из-за накладных расходов на сжатие), и внезапно у меня появилось все это дополнительное пространство.
Проверьте свои журналы работы. Такие вещи обычно вызваны тем, что BE имеет кричащую подгонку к одному файлу где-то (возможно, базе данных Access, PST или аналогичному на файловом ресурсе, на котором пользователь оставил блокировку файла), и должно быть немедленно возможно идентифицировать именно тот момент во время работы, на котором все замедляется.