SAN Client can't detect FT Media server
I experiance some issues in a SAN client. There's an VCS 2 nodes cluster for Oracle DB on Solaris system, and the SAN backups were running well before. Recently, I've changed the hostname of these NBU clients, and the SAN clients can't detecet FT media server anymore. These clients just only can backup using LAN instead of SAN now Belows are some informations and screenshots OS version and NetBackup version: Master server: RedHat 6.5, NBU 7.7.3 3 Media Servers: Solaris 10 U11, NBU 7.7.3 2 Clients: Solaris 10 U11, NBU 7.7.3 Cluster name and hostname: cluster name: fhsoms node1: fhsoms001 node2: fhsoms002 nbemmcmd -listhosts -verbose I didn't edit /kernel/drv/st.conf after I changed the hostname of the NBU clients. Because there's no any words about hostname in this file. I tried to delete cbn file in /dev/rmt on NBU clients, and rescan the drive devices I use vxlogview -o 200 to check nbftclnt logs, and it seems the client can discover the archive python devices Although I rescan the FT devices via GUI and excute rescan command on Master server and 3 Media servers, the SAN clients still can't detect FT media server I tried to restart NBU service and PBX on client, reboot OS and rebuilt zone on SAN switch,but it seems not work Any inputs by you experts is highly appreciated.
NetBackup SAN Client slow scanning /dev/sg devices
Hi folks Is there any way to tune the SAN client, specifically its initial scanning of /dev/sg devices? Can we specifiy what devices to scan, or types of devices to ignore? Our initial scan takes ~2.5hrs (~1100 /dev/sg devices, 99% of which it retries 10x times..) Log filled with the following type messages: 0,51216,200,200,1463,1536330116729,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg621 2 retries left,13:DeviceInquiry,1 0,51216,200,200,1464,1536330117730,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg621 1 retries left,13:DeviceInquiry,1 0,51216,200,200,1465,1536330118730,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg621 0 retries left,13:DeviceInquiry,1 0,51216,200,200,1466,1536330118731,71722,139769537492800,0:,80:Device type 0 found on /dev/sg621 Vendor/Product: "IBM 2810XIV 000 ",16:StdDeviceInquiry,1 0,51216,200,200,1467,1536330118731,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 9 retries left,13:DeviceInquiry,1 0,51216,200,200,1468,1536330119731,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 8 retries left,13:DeviceInquiry,1 0,51216,200,200,1469,1536330120732,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 7 retries left,13:DeviceInquiry,1 0,51216,200,200,1470,1536330121733,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 6 retries left,13:DeviceInquiry,1 0,51216,200,200,1471,1536330122733,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 5 retries left,13:DeviceInquiry,1 0,51216,200,200,1472,1536330123734,71722,139769537492800,0:,83:called from DiscoverDevices EVPD Page 0x83 "" device name /dev/sg620 4 retries left,13:DeviceInquiry,1 Starts at the highest sg number, and doesnt permit any FT backups to proceed until its hit sg1 (about 2.5hrs later) It seems very strange, as I can immediately query the tape devices, eg: lsscsi | grep tape [3:0:6:0] tape ARCHIVE Python V000 /dev/st0 [3:0:6:1] tape ARCHIVE Python V000 /dev/st1 [4:0:6:0] tape ARCHIVE Python V000 /dev/st2 [4:0:6:1] tape ARCHIVE Python V000 /dev/st3 or: ls -l /dev/sg* | grep tape crw-rw----. 1 root tape 21, 1049 Sep 7 13:15 /dev/sg1049 crw-rw----. 1 root tape 21, 1050 Sep 7 13:15 /dev/sg1050 crw-rw----. 1 root tape 21, 887 Sep 7 13:15 /dev/sg887 crw-rw----. 1 root tape 21, 888 Sep 7 13:15 /dev/sg888 I found this post with similar symptoms, marked solved, but since we're already at NetBackup 8.. https://vox.veritas.com/t5/NetBackup/SAN-Client-service-takes-a-long-time-to-start/td-p/650362 Any help appreciated! Many thanks, Ian
