Система резервирования и архивирования информации. Очень мощная, довольно удобная, но требующая серьезной доработки напильником, то есть настройки. Причем настройка процесса резервирования - это отдельная песня, а сейчас хотелось бы рассказать о вот такой напасти:
The job failed with the following error: The media operation was terminated by the user.

Приход отчета с таким диагнозом для меня стал шоком, потому что я не мог физически отменить бекап. У меня доступа к серверу в тот момент не было.
Первоначальное курение мануалов подсказало, что нужно проверить настойки автоматической отмены заданий. Проверил - ничего не включено, все по-умолчанию, то есть работать до конца. Победного или нет, другой вопрос. Что ж, придется ковырять лог более подробно.
Открываем раздел Job History и смотрим, что происходило во время бекапа. Видно, что бекап снялся, но на стадии его проверки прошел какой-то сбой:
Set Detail Information - Backup
Set type: Backup
Set status: Completed

Set Detail Information - Verify
Set type: Verify
Set status: Completed
Error: e0000602 - A query for media on which the data set being read is continued was unsuccessful. Ensure that all media in the family have been inventoried and cataloged.
Byte count: 0
bytesRate: 0,00 MB/Min
Files: 0
Directories: 0
Skipped files: 0
Corrupt files: 0
Files in use: 0

К чему это приводит? К тому, что при формировании задачи восстановления этот бекап не виден среди всех остальных. Он есть, но к нему нет доступа.
Начинаем шерстить по указанной ошибке гугл, и только гугл, яндекс по ней не знает вообще ничего (надеюсь, теперь узнает). Все ссылки ведут на форумы Symantec, где внятного ответа нет в половине случаев, а то и больше. Но из всей информации ясно одно, проблема возникает на стадии составления каталога кассеты. Предлагается сбросить эти каталоги, сказав Backup Exec'у брать информацию непосредственно читая ленты - как это сделать, описано здесь: seer.entsupport.symantec.com/docs/200962.htm Попытка выполнить эту операцию заканчивается неудачей со следующим вердиктом:
Final error: 0xe0000900 - The requested media is not listed in the media index and could not be mounted. To add the media's catalog information to the disk-based catalogs, run an inventory operation on the media and resubmit the Catalog operation.
Получается цикл, в котором я провертелся в общем и целом около месяца, что является непозволительным сроком. Что делать - непонятно. Виноваты ли кассеты, виновато ли ПО, учитывая, что оно работало, может быть всему виной и сбойный накопитель (самый паскудный сценарий). Все это время пришлось полагаться на встроенный ntbackup, который, в принципе, спасает. Одновременно прокуривал форум Symantec на наличие сходных случаев. И только в одном топике натолкнулся на комментарий сотрудника компании Symantec - "проверьте системные логи на наличие ошибок с кодами ... Они говорят о неисправности с оборудованием"
Чем черт не шутит, не питая особой надежд на то, что это поможет (сам накопитель исправен, в этом я был уверен) открыл логи приложений в самой ОС. Каково же было мое удивление, когда причина всего бардака с каталогизацией появилась прямо перед глазами:
Event Type: Error
Event Source: Backup Exec CatErrorHandler Server
Event Category: None
Event ID: 34323
Date: 26.12.2009
Time: 11:10:31
User: N/A
Computer: %servername%
Description:
Update to catalog file C:\Program Files\Symantec\Backup Exec\Catalogs\%servername%\{01F7A24D-8B4B-4F36-9FDD-E627C9FE7575}_1.fh failed.
Reason: There is not enough space on the disk.
r:\corsica\2213r\becat\beplugins\commonfh\fhbuilder.cpp(772)

For more information, click the following link:
eventlookup.veritas.com/eventlookup/EventLookup...

Вот оно! Проблема была действительно на стадии каталогизации, потому что новосозданный каталог просто не мог записаться на диск, места не хватало. Окинув взглядом папку каталогов, понял, что ее жизненно необходимо убрать с системного раздела. Перенес на другой раздел, перезапустил службы, и заставил Backup Exec перестроить каталоги по описанному выше по ссылке методу. Итогом стало то, что все бекапы, которые были сняты за период сбоев, стали доступны. Что и требовалось.

Мораль истории - даже если приложение ведет достаточно подробные логи само по себе, забывать о логах ОС не рекомендуется. Иногда они все же информативнее.
Надеюсь, эта запись поможет людям, обслуживающим Symantec Backup Exec, сберечь много нервных клеток.