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