Zoning Aix to Netbackup 5230
Hi guys, I just create a zone between AIX (LPAR), 5230 appliance and a storage like this As you can the AIXserver has two FC adapter each one belongs to a zone,butsometimes I lose visibility from netbackup so I have to go to the client and run cfgmgr command or even restart clients services. Then on AIX server I run some commands like this root@PRECBPHCDB]:/usr/openv/netbackup/bin>lsdev -Cc tape The output Im getting is: rmt0 Available 42-T1-01 Other FC SCSI Tape Drive rmt1 Available 44-T1-01 Other FC SCSI Tape Drive rmt2 Available 44-T1-01 Other FC SCSI Tape Drive [root@PRECBPHCDB]:/usr/openv/netbackup/bin>tail It is normal to get"Other FC SCSI Tape drive". Should I install a Veritas driver o something like that?Replication from second copy
Hi guys, My enviroment has 6 5230 appliance, appliance 1 and appliance 2 are working for backups, appliance 3 and appliance 4 are woriking for replications only, and appliance 5 and appliance 6 are replications targets. I create a SLP like this, 1. Backup (to appliance1 and appliance 2) 2. Duplication(to appliance 3 and appliance 4) 3. Replication (to appliance 5 and appliance 6). My issue is that I need to replicate from appliance 3 and 4 not from 1 or 2 and according to netbackup I can oonly replciate from source copy. Any ideas guys??
Netbackup Appliance support for VPC (Virtual Port Channel
Hi, We have new Network infratructure being implemented where the traditional method of stacking switches to allow us to LACP across multiple switches, has been replaced with a new NEXUS 9000 setup which now uses something call VPC (Virtual Port Channelling). I dont know much about this but have been asked by the Technical Architects to confirm that the VPC is supported by the Netbackup appliances? Our appliances are 5230 at version 2.6.0.2 (7.6.0.2) Hopefully someone has come across this before and can help ? Thanks NickStatus 2060019 and status 87 Killing same job
Got following errors in our details on a solaris backup. Im on an appliance, 5220. We are running 7.6.1.1. Link to 2060019 in error message is a cyclical redirect. I saw in other posts that this was a problem in the pre 7.5.0.4 world, but was supposed to be fixed in 7.5.0.5. Which is not our experience. Is there are work around for this? Anyone else seen it in the post 7.6.1.1 version? â05/10/2015 00:56:17 - Critical bptm (pid=4960) Storage Server Error: (Storage server: PureDisk:servername) mtstrm_close_write_channel: Fatal error occured in Multi-Threaded Agent: Close Write Channel command failed: Cr_ErrnoException: Timed out after waiting 180s for the read threads to complete (cnt=1) V-454-96 05/10/2015 00:56:17 - Critical bptm (pid=4960) sts_close_handle failed: 2060019 error occurred on network socket 05/10/2015 00:56:17 - Critical bptm (pid=4960) sts_close_handle failed: 2060019 error occurred on network socket 05/10/2015 00:56:17 - Error bptm (pid=4960) cannot write image to disk, media close failed with status 2060019 05/10/2015 00:56:17 - Info bptm (pid=4960) EXITING with status 87 <---------- Thanks in advance.
Understanding Accelerator (from detailed Status view)
Hi all, I am in need of confirmation or explanation on some logging I see in the detailed status. When I see this in the detailed status (for an Incremental backup): 04/15/2015 07:02:43 - Info bpbkar (pid=98149) accelerator sent 1115317760 bytes out of 5630247936 bytes to server, optimization 80.2% Does this mean the Accelerator has found5630247936 bytesof new/changed data on the clientof which1115317760 bytesis new data to the backup appliance? And how does this related to: 04/15/2015 07:02:45 - Info netbackup (pid=164455) StorageServer=PureDisk:netbackup; Report=PDDO Stats for (netbackup): scanned: 5498334 KB, CR sent: 268206 KB, CR sent over FC: 0 KB, dedup: 95.1%, cache disabled I see that the client-side-dedup has foundscanned: 5498334 KBof new/changed data of whichsent: 268206 KBis sent to the Backup Appliance as this is new unique data. Please correct me where I am wrong or comfirm I am understanding this correctly. Many thanks Regards, Ronald
