NetWorker. Сбой восстановления с ошибкой «NDMP Service Error: Не удается определить формат»

Симптомы связаны с двумя основными проблемами:

1. Администратор резервного копирования не уделяет должного внимания постоянно повторяющимся ошибкам ввода-вывода заголовка NMDP. Это предупреждение NetWorker содержит ошибку VNX и должно относиться к нему серьезно
2. Оба продукта (NetWorker и VNX) рассматривают повреждение заголовка NMDP как тривиальную ошибку. В особом случае резервного копирования происходит перезапуск, если повреждение достигает точки, которая не может быть автоматически разрешена при попытке чтения данных

Файлы, необходимые для восстановления, охватывают несколько резервных копий (полную + разностную + инкрементную) и несколько томов.

Восстановление набора сохранений NDMP и пофайловое восстановление (с возможностью просмотра) завершаются сбоем с тесно связанными ошибками

Просматриваемый журнал сбоев восстановления:

42744:nsrndmp_recover: Tape server paused: reached the end of file
42897:nsrndmp_recover: Opened the tape device : c208t0l0
42870:nsrndmp_recover: Continuing recover from the next volume
42619:nsrndmp_recover: NDMP Service Error: Cannot identify format.  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
42617:nsrndmp_recover: NDMP Service Log: server_archive: emctar vol 1, 0 files, 61440 bytes read, 0 bytes written
42738:nsrndmp_recover: Data server halted: Error during the restore.
42856:nsrndmp_recover: NDMP data server has an internal error.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
16279:winworkr: NDMP retrieval: child failed with status of 1
42897:nsrndmp_recover: Opened the tape device : c208t0l5
Mover listen address is NULL(NDMP_ADDR_LOCAL)

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

root@NW-server# nsrndmp_recover -s NW-server -c NAS-host -S 1011119015 -v off -m "NAS-host::/root_vdm_1/users/recover_emc" "/root_vdm_1/users/VDI_Users/v009/project/Plan04.2012"
42879:nsrndmp_recover: Peforming recover with no file mark dependency..
05/31/16 17:25:50.504040 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
42787:nsrndmp_recover: Performing recover from NDMP type of device
05/31/16 17:26:01.269862 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
May 31 17:26:02 NW-server root: [ID 702911 local0.alert] NetWorker media: (waiting) waiting for LTO Ultrium-5 tape VN0116L5 on NAS-host
95555:nsrmmd: ndmp tape mtio failed, I/O error
42850:nsrndmp_recover: Failed to load volume 1111782299 fnum 3 <<<<<< cannot load File Number 3
42855:nsrndmp_recover: Failed to load the tape.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
root@NW-server #

Самый главный симптом заключается в том, что сканер не в состоянии пройти через требуемые тома резервных копий, он преждевременно останавливается до считывания каких-либо данных!

root@NW-server # scanner -vvv -p "rd=NAS-host:c208t0l5 (NDMP)"
8909:scanner: using 'rd=NAS-host:c208t0l5 (NDMP)' as the device name
05/31/16 17:29:08.919423 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8968:scanner: Reading the label...
8969:scanner: Reading the label done
8936:scanner: scanning LTO Ultrium-5 tape VN0116L5 on rd=NAS-host:c208t0l5 (NDMP)
96367:scanner: volume id 1111782299 record size 262144 bytes
created 5/24/16 21:00:35 expires 5/24/18 21:00:35
8973:scanner: setting position from fn 0, rn 0 to fn 2, rn 0
05/31/16 17:29:09.073276 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
05/31/16 17:29:09.201476 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8761:scanner: done with LTO Ultrium-5 tape VN0116L5 <<<<<<<< No Errors , no mention of any file after File number 2 !!

Использование файла отладочного флага NW: /nsr/debu/ndmp_auto_pos не помогло с полным сохранением резервной копии или просматриваемым восстановлением.

Неверный формат тома NDMP, вызванный повреждением заголовка NDMP, иногда приводит к ошибочным номерам файлов (например, автоматический перезапуск резервного копирования).  

Проверка журналов NW показывает, что каждая резервная копия сопровождается ошибкой ввода-вывода при записи заголовка NDMP. Это постоянная проблема, которая возникает при каждом резервном копировании, это указывает на постоянное повреждение.

70896 05/01/16 12:18:05 0 0 2 1 23177 0 NW-server nsrd NSR info NAS-host:/root_vdm_1/userdata saving to pool 'NDMPPool' (VN0050L5)
42597 05/01/16 12:18:05 2 0 0 1 23990 0 NW-server nsrmmd NSR warning ndmp header: I/O error   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
71193 05/01/16 12:18:05 0 0 0 1 23177 0 NW-server nsrd NSR info NDMP Save Notice: NAS-host:/root_vdm_1/users NDMP save running on 'NW-server'

Анализ журналов сетевой системы хранения данных показывает, что для размера буфера устройств NDMP установлено значение, меньшее размера блока устройства, настроенного в NW. По умолчанию конфигурация NetWorker устанавливает размер блока для устройств LTO-5 равным 256 Кб, но размер буфера устройств NDMP (NDMP.bufsz) равен 128 Кбайт. Эта часть связана только с заголовком NDMP, так как размер блока данных настраивается в NAS параметрами конфигурации PAX (по умолчанию 60k).

2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error

Во время резервного копирования в журнале VNX отображается связанное сообщение:

1466097048: NDMP: 3: Session 236 (thread ndmp236) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072) Set NDMP.bufsz >= 262144 and reboot

Это не считается проблемой резервного копирования, так как поток данных еще не запущен, но приводит к повреждению заголовка NMDP (см. NDMP: 3. Сеанс 384 (поток ndmp384) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072)Set NDMP.bufsz >= 262144 and reboot), который устраняет эту проблему, устанавливая размер буфера устройств NDMP равным 256 Кбайт. Однако это исправление не решает проблему с резервными копиями, которые уже были записаны.

Указанное выше повреждение заголовка NMDP может не вызывать проблем с восстановлением, но в случае перезапуска резервного копирования в базе данных носителей NW зарегистрирован неверный номер файла. При этом автоматическое позиционирование ленты аннулируется, и NAS сообщает, что существующие данные в этой позиции не могут быть распознаны как действительный поток данных NDMP (Ошибка службы NDMP: Не удается определить формат)

Таким образом, существует два типа коррупции:

1. Ошибки ввода-вывода заголовка NDMP, вызванные несогласованной настройкой размера блока между NetWorker и VNX, этот тип повреждения обходится функцией автоматического позиционирования, и он может существовать годами, и его никто не заметит. При условии, что в каждом наборе сохранений зарегистрированы правильные номера файлов.
2. При перезапуске резервного копирования несколько верхних и нижних колонтитулов NDMP записываются последовательно, и сервер NW пропускает нужный номер файла, с которого начинается следующее резервное копирование, что аннулирует автоматическое позиционирование при использовании отладки автоматического позиционирования без NDMP (/nsr/debug/ndmp_auto_pos) в данном случае бесполезна, так как интерфейс управления лентой (MTIO) прекратит чтение, как только обнаружит двойную метку файла (вызванную повреждением заголовка NDMP C1)