). Затеяна огромная переписка с техсаппортом славной фирмы CA (им отправлено 9 баг-репортов), кое-какие надежды проглядываются. Но попутно, не расчитывая на скорое решение проблем с BAB r11.1, я затеял изучение и пробную обкатку альтернативного продукта - BackupExec v9.1 for Netware. Версия 9.2 не подходит потому, что не поддерживает Netware4.11, а на данном этапе это нужно.
Плотно поработав с BE 9.1 и прочитав документацию
, я хотел бы представить некоторые свои соображения по сравнению двух конкурирующих продуктов. Сразу скажу - многие вещи стали понятными и очевидными только после реальной работы с продуктами, документация спасает далеко не всегда. Итак:
1) В BE очень неудобное разделение полномочий - юзер, админ и супервизор. Т.к. юзер ПО ОПРЕДЕЛЕНИЮ видит только СОБСТВЕННЫЕ задания, то операторам придётся давать права админов, просто для того, чтобы они могли в realtime отслеживать состояния задания. А в окне состояния, к сожалению, присутствует большая такая кнопка <<Cancel Active Job>>. Опасно и не нужно. В BAB-е r11.1 SP1 есть более тонкое разделение полномочий, в т.ч. можно дать возможность следить за чужим заданием в режиме readonly. В ArcserveIT 6.6 разделение полномочий можно было настраивать ещё более удобно и тонко.
2) В BE откровенно удивило, что нет возможности увидеть название ленты, просто вставив её в привод, требуется выполнить операцию Inventory. Странно... BAB покажет вам имя вставленной в магнитофон ленты сразу же, как только заправит её - минута-полторы, от силы, никаких специальных операций для этого не требуется.
3) Сильно обескуражил подход BE к защите лент, находящихся в media set-ах (в BAB аналог называется media pools). Даже с максимальной защитой BE перезапишет ленту из чужого set-а, если она подходит по охранному интервалу (т.е., достаточно старая). Защита осуществляется ТОЛЬКО по временнОму интервалу. Тогда как BAB всегда отвергнет ленту из "чужого" пула, даже если она подходит "по возрасту". Хороший пример - в последнюю пятницу месяца необходимо ставить ленту из месячного пула и наши операторы частенько ошибались, ставя вместо неё недельную (пятничную) ленту - BAB её категорически не принимал, даже если лента пережила "охранный" период ("чужой" пул). BE такую ленту примет, т.е., недельная лента будет перезаписана месячной. Очень неправильное поведение, на мой взгляд, легко ошибиться и реально перезаписать не ту ленту.
4) BE не генерирует в реальном времени протокол работы, к чему привыкли наши операторы. Все репорты/логи - только по окончанию задания. А окно с риалтаймовым представлением состояния задания имеет опасную кнопку отмены задания, про которую я упомянул выше.
5) Агент для бэкапа удалённого сервера у BE не имеет никакого экрана для диагностики, тогда как у NWAgent-а BAB есть и подробный лог и real-time экран статистики - очень полезно.
6) У BAB есть два места, где можно посмотреть названия лент, которые он потребует при последующих бэкапах - в специально генерируемом по окончанию файле предсказазания (на неделю вперёд) и в реальном времени в календарном представлении задания. Именно - НАЗВАНИЕ конкретной ленты. У BE я такого сервиса не нашёл.
7) Не могу определить - сколько времени ждёт нужной ленты BE. У BAB-а это описывается в свойстве задания, н-р, первую ленту - 10 минут, все последующие (продолжение) - 9999 минут (умолчание).
8 ) Если в свойстве задания стоит вытолкнуть ленту по окончанию, и задание распределяется более чем на одну ленту, то BAB, заполнив первую ленту, выталкивает её их привода, BE - нет. По-моему, BAB более логичен.
9) При переходе на следующую ленту (если бэкап вылез за одну ленточку) BE требует явного ответа Yes для продолжения бэкапа. BAB-у было достаточно просто вставить требуемую ленту в привод - и операция возобновлялась. BAB опять более логичен, на мой взгляд - зачем лишние подтверждения, если вы уже и так произвели действия, вставив вторую ленту в магнитофон?
10) Совершенно "убило" поведение BE при отмене задания - он тут же, автоматом, запускает стирание ленты, на которую делался бэкап, с уничтожением записанного из базы данных. Какое его дело, когда и по какой причине я отменяю задание? А если у меня бэкап размазался на пять лент и я отменил задание на пятой - как BE собирается стирать извлечённые из привода первые четыре ленты? BAB при отмене просто закрывает ленту, не стирает ничего, честно добавляя в базу то, что успело записаться до отмены.
11) В BE я могу отменить только задание целиком, в BAB - отдельную сессию (н-р, отменить текущее копирование SERVER/DATA:) - при этом бэкап перейдёт к следующей сессии, если ещё остались невыполненные.
12) В BAB я могу любое задание сохранить в виде внешнего файла - очень удобно при переносе настроенных джобов между серверами и т.п. В BE вместо этой простой функции я должен отдельно сохранить a) политику б) выбор (selection list). Для их переноса на другой сервер требуется существенно больше ручных манипуляций, чем для варианта у BAB-а - просто один файлик с расширением .ASX.
13) Сервер приложений BE заметно больше грузит процессор - вместо обычных для моего железа 25-30% CPU load я вижу 48-52%.
Вот, если ещё что вспомню - напишу. Как уже очевидно, по вышеперечисленному я отдал явное преимущество BAB-у, у которого практически один недостаток - не работает
.
Но будем надеяться на лучшее - сегодня из техподдержки CA (точнее, вчера вечером) прислали test fix, который должен решить проблемы абендов. Это модуль APROCESS.NLM/MSG (по его внутренностям видно, что он вызывает FSTAPE.NLM и INTRLEAV.NLN, которые "роняют" сервер), есть надежда, что этот тестовый фикс решит проблему сразу для обоих (если посмотреть базу знаний у CA, APROCESS там часто упоминался для прошлых версий). Абенд вылазит при передаче неверных параметров в LIBC (новая версия libc не спасает). После обеда попробую тестовые прогоны - в связи с вышеизложенным переход на сильно отличный по идеологии продукт - BE - как-то не очень манит.
