Have you looked for jumbo-frame (lack of) configuration everywhere? That reminds me of failure modes I’ve seen in due to missing (or not compatible) jumbo frame support. Is the new server on a new switch? Does the new server support a larger jumbo frame size that might be rejected between it and the failing clients?
Nick On Thu, Jan 24, 2019 at 5:30 PM Tom Alverson <tom.alver...@gmail.com> wrote: > While waiting for IBM to respond to my PMR request, I wonder if any of you > have seen an issue like this - Here is our current setup > Multiple Exchange 2013 CU21 servers running TSM Baclient 7.1.0.1 and > TDP/Exchange 7.1.0.1 backing up to TSM Storage server 7.1.7.2 on AIX. > Backups have been very slow and efforts to improve things have not helped. > We only back up one full DAG every day (roughly 700GB) and do incrementals > on the other 14 DAGs (we would love to do more fulls but the one full takes > up almost the whole day). > > We set up a shiny new DELL/RHEL server and put the same exact 7.1.7.2 > storage software on it (both dump the data to Data Domains). We did a > quick incremental backup test to the new server and it was much faster. We > let it start our nightly backup run and the first FULL ran much faster than > on the old server and the next incremental worked but everything after that > would fail. We actually moved two exchange servers to the new RHEL server > and both had the same issue. They would fail right at the beginning of the > job right after it puts the banner info in the log (i.e. what you are > backing up) but where you would normally get the TSM storage server name > logged after a few seconds, these would wait 30 seconds then time out > (ANS1017E Session rejected: TCP/IP connection failure.). The same issue > happened if you went to the restore tab in the GUI, it would never > communicate with the storage server. Of course there were no error > messages on the storage server end and only the connection failure on the > client after 30 minutes. > > I ran a test file level backup from DSM.EXE to both the "servername" > nodename and then to the "servername_EXC" nodename with no issues. Moving > both servers back to the old storage server allowed them to work again (but > slowly as always). Does anyone have any clues as to what might be going > on? I tried to check if there was any Exchange CUxx limitation to the > 7.1.0.1 agent but did not see any. > > Tom >
