Чтобы составить полное описание проблемы, ответьте на следующие вопросы:
    - При каких обстоятельствах происходит сбой процесса. Является ли такое поведение последовательным?
    - Раньше это работало лучше.
    - Время возникновения и наблюдаемая тенденция
поведения — возникает ли проблема только во время высокой нагрузки на среду резервного копирования, резервные копии или определенный тип группы резервного копирования.
    - Когда впервые возникла проблема? Что изменилось тогда?
    - Каков масштаб проблемы (все клиенты/некоторые клиенты, все цели резервного копирования или некоторые)
- Что пытались исправить до сих пор и какие выводы из этого были сделаны.

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

      - Используя интерактивное руководство по совместимости NetWorker, убедитесь, что все компоненты (сервер NetWorker, версия файловой системы, прокси, узлы хранения, клиенты, целевые устройства) поддерживаются.
      - Убедитесь в отсутствии базовой операционной системы или недостатков оборудования, которые могли бы объяснить сбои процесса (сбои диска, заполнение диска, сетевые ошибки и т. д.).

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

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

    - Мониторинг производительности системы при большой нагрузке
- Изучение файлов журналов операционной системы во время сбоев на предмет общности в поведении
- Ознакомьтесь с расписанием NetWorker, чтобы определить, существует ли корреляция между временем возникновения конкретного запланированного действия NetWorker.
    - Выясните, какие операции, не относящиеся к NetWorker, выполняются на этом компьютере, которые могут повлиять на его поведение и коррелирует ли их расписание со временем сбоев.
    - Если сбой происходит постоянно, измените некоторые параметры, чтобы попытаться сузить круг причин.  Например, резервное копирование на другой целевой носитель или резервное копирование данных разных типов из одного клиента NetWorker

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

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

1) Проверьте каталог /nsr/cores для получения последних дампов ядра процессов NetWorker в unix или Linux или проверьте каталог аварий, как определено в реестре Windows (см. шаг 2).

2. Если таковых нет, убедитесь, что операционная система настроена на создание файлов дампа ядра в случае сбоя процесса.  Подробные сведения см. в документации по операционной системе, но вкратце это, скорее всего, потребует изменения значений ulimit -c и -f в Linux или Unix и внесения изменений в реестр в Windows.

Для Windows 2008R2:  
- Обновите реестр новым разделом, указанным в http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.
- Используя рекомендуемые значения, файл дампа создается в C:\Users\Administrator\AppData\Local\CrashDumps- Enable full crashdumps
.

3) Файл ядра может быть просмотрен на самом хост-компьютере или может быть упакован для анализа на другом компьютере.  Подробная информация о том, как упаковать эти файлы ядра, доступна здесь:

Упаковка файлов ядра для UNIX и Linux:
489272: Сбор информации о ядре/аварийном дампе и соответствующих журналах

4) Анализ доступных данных:

- файлы журнала
операционной системы- файл журнала управляющей программы NetWorker с сервера NetWorker и соответствующего узла хранения.  
- Файл ядра или файл аварийного завершения

работы: Детальный анализ файла ядра требует продвинутых знаний о внутренних операциях NetWorker и должен выполняться службой поддержки EMC NetWorker.  Однако можно выполнить начальное чтение файла дампа, чтобы сравнить содержимое файла ядра с известными проблемами.

Linux и HP-UX
gdb [полный путь к процессу] [файл ядра]
(gdb) где

AIX
dbx [полный путь к процессу] [файл ядра]
(dbx) где

Solaris
pstack [ файл ядра ]
dbx [полный путь к процессу] [файл ядра]
(dbx) где

Windows
- Запустите программу
отладчика windbg windows- Нажмите на файл и откройте файл дампа в windbg.
- Введите analyze --v в нижнем окне команды, чтобы получить полную информацию.
    
5. На основании приведенного выше анализа и знаний о поведении системы можно сравнить инцидент со списком известных проблем, подробно описанным в примечаниях к выпуску NetWorker для последней версии.

Если вы подозреваете, что в программном обеспечении NetWorker имеется ошибка, из-за которой процесс не отвечает, необходимо упаковать файл аварийного завершения работы (см. шаг 3) и предоставить его вместе с полным описанием наблюдаемого поведения в службу поддержки Dell Technologies NetWorker для подробного анализа проблемы.