bdos1's Posts

bdos1's Posts

Hello, Are you using the NetWorker Virtual Edition? (Note: The reason I'm asking this is because the NVE has it's own built in Firewall). Also, can you please ensure that you are able to use teln... See more...
Hello, Are you using the NetWorker Virtual Edition? (Note: The reason I'm asking this is because the NVE has it's own built in Firewall). Also, can you please ensure that you are able to use telnet/curl (Or similar) to connect to the port 5671 on the affected host? Thanks very much, B
Well, here's your problem at least... Aborting session channel connection (33) to 10.0.51.1; why = An existing connection was forcibly closed by the remote host. An existing connection was forcibl... See more...
Well, here's your problem at least... Aborting session channel connection (33) to 10.0.51.1; why = An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host. This can mean a few things, most likely a Firewall is forcing the connection closed. Here are some things you can do to help. (1) Set Inactivity Timeout in action properties to 0 (Ensures no timeout) (2) Implement TCP Keepalive tuning on the affected Client, Storage Node, Data Domain (3) Put the following option into "Save Operations" if using PSS backups PSS:timeout_mins=0 Note: if you have other options already in Save Operations field, they need to be separated with a semi colon ;  and no spaces in between.
If the affected clients have Anti Virus software installed, then ensure the Anti Virus the correct rules and exceptions in place to allow the NetWorker software to do it's work.  If the affected hos... See more...
If the affected clients have Anti Virus software installed, then ensure the Anti Virus the correct rules and exceptions in place to allow the NetWorker software to do it's work.  If the affected hosts do have Anti Virus software as suspected. Then, as a test, try temporarily disabling the Anti Virus, reboot the machine, & try again a Full backup. If it succeeds then you will know the correct rules need to be put in place. The "Access is denied" suggests to me some other application has a lock on the files (Usually Anti Virus software)...
Okay so here is where your logs will be D:\Networker\nsr\logs\policy\Windows\FileSystem\backup_162669_logs\.. Check in here for the actual backup log which records the failure. From the workflow log y... See more...
Okay so here is where your logs will be D:\Networker\nsr\logs\policy\Windows\FileSystem\backup_162669_logs\.. Check in here for the actual backup log which records the failure. From the workflow log you have shared it doesn't tell us much.
Welcome to the community. May I suggest you attach the log from the backup so we can check the reason for the failure? Backup logs are located here: ../nsr/logs/policy_name/workflow_name/action_nam... See more...
Welcome to the community. May I suggest you attach the log from the backup so we can check the reason for the failure? Backup logs are located here: ../nsr/logs/policy_name/workflow_name/action_name (Be sure to redact any confidential information from the backup logs if posting on the forums.) Normally with large backups you will run into Inactivity Timeouts / TCP Keepalive issues, however, we will need to check the logs to understand exactly what is happening.
I had an issue similar to this before. The resolution was to add all the Storage Nodes being used during the clone into the “Storage Nodes” field of the NetWorker Server's client properties. It need... See more...
I had an issue similar to this before. The resolution was to add all the Storage Nodes being used during the clone into the “Storage Nodes” field of the NetWorker Server's client properties. It needs to be above the “nsrserverhost” and 1 per line. Strange, I know, but it worked... If it's still not working, then add the source and destination storage nodes to the clone command and check the debug log. # nsrclone -D9 -b Media_pool -y "1 year" -J Storage_Node_A -d Storage_Node_B -v -S savesets
On NetApp, the naming convention is: /vol/volname/.. There is also a hidden directory for the snapshots of each volume: /vol/volname/.snapshot/snapshotname A nice trick I like to use sometimes if I... See more...
On NetApp, the naming convention is: /vol/volname/.. There is also a hidden directory for the snapshots of each volume: /vol/volname/.snapshot/snapshotname A nice trick I like to use sometimes if I'm unsure about the syntax for any NDMP Client's saveset is to run a test backup using saveset All. When the backup starts, just terminate it after few mins, you should see all the different savesets listed in the monitoring tab and their syntax. This trick works for VNX and Isilon... I'm not sure about NetApp. However, that said, it's always best to ask your storage team for the correct syntax for the saveset, they will know (Or at least should know). Alternatively, check yourself via putty. 
My suggestion is to get the SSID from the latest successful Full backup from the backup logs. With that in hand, query the Media DB using the SSID:  mminfo -q ssid=ssid_number -r client,level,ssid... See more...
My suggestion is to get the SSID from the latest successful Full backup from the backup logs. With that in hand, query the Media DB using the SSID:  mminfo -q ssid=ssid_number -r client,level,ssid Is the client name what you expect? IE: Does the client name in the Incr backup error match what you get in the mminfo output for the full backup?  138851:save: 'client server:F:\XXXXXXXXXXX' is being reset/promoted to level 'Full' as no backup is found. If not then you may have client ID issues.
After checking the command reference guide for mminfo usage, there does not appear to be an option you can pass to -r to extract information regarding the "type" of saveset which is unfortunate. T... See more...
After checking the command reference guide for mminfo usage, there does not appear to be an option you can pass to -r to extract information regarding the "type" of saveset which is unfortunate. The only alternative I can think of is to use mminfo with the -N option. For example: If you know the type of saveset you're looking for always has the same name (Lotus notes for example has "NOTES:"). Then one could do something like this: mminfo -avot -N NOTES: This will return all the Lotus Notes savesets from the mediadb. Similarly, Isilon NDMP backups usually contain a leading /ifs/.. in it's name. So one could use mminfo -avot -N /ifs to return all Isilon NDMP backups and so on... nsrinfo has a nice option -n to query the namespace, this looks more along the lines of what you need... –n namespace - Indicates the file index name space to query. By default the backup name space is used. The other recognized values are: migrated, archive, nsr (for internal use), bbb (for Block based backup data), db2 (for DB/2 data), informix (for INFORMIX data), iq (for SAP IQ data), msexch (for Exchange data), mssql (for SQL Server data), mysql (for MySQL data), notes (for Lotus Notes data), oracle (for Oracle data), saphana (for SAP HANA data), sybase (for Sybase data), and all. The name space field is case sensitive This mminfo limitation looks suitable for an RFE.
NetWorker 9 introduced a new cloning technology called Recover Pipe to Save (RPS).  The uses of this technology will change over the future versions, but currently this is mainly used for NVP-vP... See more...
NetWorker 9 introduced a new cloning technology called Recover Pipe to Save (RPS).  The uses of this technology will change over the future versions, but currently this is mainly used for NVP-vProxy cloning operations.  Therefore, for now, this should be disabled in the server properties.  NVP-vProxy cloning operations will use this technology automatically even with the 'disable' option ticked.  Having RPS cloning enabled (check box not ticked) has been seen to cause some cloning stability issues.