Ебаное говно

[scif_yar]

Problem

An upgrade from NetBackup 7.7.3, 8.0 or 8.1 to NetBackup 8.1.1 (or equivalent NetBackup Appliance version upgrade) may fail during the attempt to upgrade the NBDB (EMM) database.

Cause

The issue is a result of configuring a user in NBAC. In previous versions (NetBackup 7.7.3 – 8.1) adding a user put an entry in the ACTL_User_Details database table. This table is for RBAC and the table is not currently used. RBAC (Role Based Access Control) is a feature planned for a future release of NetBackup. For now, only the "root" (and optionally the "nonroot") user name(s) are the only entries the table should have. However, the installer checks the table, finds other usernames, and that prevents updating of the database, which in turn fails the upgrade to 8.1.1. The additional user names were added with a NULL character in the last 3 fields of the table (userIdTag, userIdInt, userIdStr) and the upgrade of the NBDB database cannot proceed when the table contains a NULL character in those fields.
https://www.veritas.com/support/en_US/article.100042241
--
ЕБАНОЕ ИНДУССКОЕ ГОВНО

Comments

[elglin]

Более всего в таких случаях бесит, что энтерпрайзный, мать его, продукт за примерно офигиард денег. За платную поддержку которого ты еще и отстегиваешь некисло.
Когда ты берешь опенсорс, продукцию ООО "Вектор" или сам что на коленке делаешь, ты, по крайней мере, с самого начала соглашаешься с возможностью нетривиальных багов, с которыми хрен поймет, что делать.

Не, я очень рад, что мы спрыгнули с этого поделия Veritas, при всем моем уважении к его истории и все такое. Какой-то он в последние годы стал глюкавый.

[scif_yar]

вот это
An upgrade from NetBackup 7.7.3, 8.0 or 8.1 to NetBackup 8.1.1
пиздец бесит.
как и сам солюшн.

Впрочем там и остальное в 8.1 вида ояябу
NetBackup 8.1 Storage Lifecyle Policy (SLP) configuration screen will report error "network read failed(42)" or "premature eof encountered(233)", if the storage unit group is used for any SLP operations.
https://www.veritas.com/support/en_US/article.100040027

[elglin]

Мы эти SLP пытались юзать где-то во времена 7.1, оно даже работало, потом там что-то заглючило, за давностью лет не помню, что - а дальше, как сибирские лесорубы, сказали "Ага-а" и перенастроили все на классику.
Интересно, что у них выдает этот network read failed. Либо в каком-то вызове захардкожен таймаут, либо еще что-то аналогичной костыльности - ну или тупое отсутствие попытки повтора на свал вызова - там же Си, скорее всего, то есть read() на сокете. У меня такого дерьма тоже хватает, но я свои поделия за многабабла не продаю.

[scif_yar]

в классике низя disk2disi2tape сделать, как раз SLP отвечает за многоходовочку.
Но тут то ошибка всплыла почти сразу после перехода 8.0 - 8.1, причем в 8.0 ее не было.

[elglin]

Ты прав, а я вспомнил, в чем дело было. Нам навязали внешний DataDomain с дедупликацией (ну и это было как раз D2D2T с использованием SLP), но очень быстро выяснилось, что бэкап файловика на него не влезает, в результате чего оно использовалось не для того, для чего стоило бы (тогда наше мнение в вопросе бэкапной системы было по рупь ведро, решения принимала головная контора, а эксплуатация была на нас). Потом этот внешний DataDomain был послан к фигам после того, как в очередной раз он отвалился от NB, а всем было влом чинить. Его попытались реанимировать с гениальной идеей организовать репликацию бэкапов через Атлантику - я поделил объем на пропускную способность канала, написал пяток писем с подсчетом, что не взлетит, на что получил ответ "а вы попробуйте", притворился гордым ежом, меня так и не пнули, а автор гениальной идеи через пару месяцев к ней охладел и более мне мозг не трахал.