When I do a copy process the source vol of the netware server and the destination have long file name support, but arcserve will not copy the data with long file names. Is this a standard issue due to the age of the version I am using or is it a result of something else. any help would be appreciated
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
The copy feature in Arcserve 6.1 does not copy long file names
- Thread starter Thnoss
- Start date
As long as both servers are running the TSA agents and SMDR (required in order for SMS to work), there should be no problems copying long filenames. A lack of long filenames is usually related to the above. What version of NetWare are you using? -----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
markshaw100
IS-IT--Management
Thnoss
What are you using to copy across. TSA/NWAGENT?
Are there errors in the log?? (ARCH$SVR.LOG)- I'll bet there are...
Typical scenario is IPX/SPX SAP packets not going through WAN routers 4b, 23f and another one as I recall. There's a full list on Novell somewhere.
Looking at a debug trace at one time it appeared to use IPX to authenticate then switch over to SPX2 to shovel the data across. It there's a problem with SAP packets getting filtered then your backup server won't even know that the TSAs are at the other end and won't use 'em!. ;o)
Check the SAP packets if using IPX/SPX - or check config/condition of agents if loaded.
Cheers
Mark
What are you using to copy across. TSA/NWAGENT?
Are there errors in the log?? (ARCH$SVR.LOG)- I'll bet there are...
Typical scenario is IPX/SPX SAP packets not going through WAN routers 4b, 23f and another one as I recall. There's a full list on Novell somewhere.
Looking at a debug trace at one time it appeared to use IPX to authenticate then switch over to SPX2 to shovel the data across. It there's a problem with SAP packets getting filtered then your backup server won't even know that the TSAs are at the other end and won't use 'em!. ;o)
Check the SAP packets if using IPX/SPX - or check config/condition of agents if loaded.
Cheers
Mark
- Thread starter
- #4
Thanks Guys
To answer Thelad's question both servers are running netware 4.11, both have tsands, and tsa410 loaded, but I don't know if this has enabled sms.
Mark I am using the enterprise version of arcserve and as far as I can tell it is using tsa to copy. The error that I have been receiving is cannot login to 4.z tsa with user supervisor, I read up on this and the recommendation was to create another account with the same rights level, whcih I did and still no luck. I hate to sound ignorant, but could you explain how to do this trace on the packets, as the only debug trace I know of is for tracing errors with the NDS.
Thnoss
To answer Thelad's question both servers are running netware 4.11, both have tsands, and tsa410 loaded, but I don't know if this has enabled sms.
Mark I am using the enterprise version of arcserve and as far as I can tell it is using tsa to copy. The error that I have been receiving is cannot login to 4.z tsa with user supervisor, I read up on this and the recommendation was to create another account with the same rights level, whcih I did and still no luck. I hate to sound ignorant, but could you explain how to do this trace on the packets, as the only debug trace I know of is for tracing errors with the NDS.
Thnoss
markshaw100
IS-IT--Management
Thnoss
RCONSOLE into the backup and production (target) servers.
Check for NWAGENT and TSA on the production server.
Type "modules TSA*" (no quotes). Check that some version of the TSA is returned (TSA410 for files and TSANDS to back up NDS)
Check for NWAGENT with "MODULES NWAGENT*" (No quotes)
If loaded OK. It is good insurance to unload and reload if they're not currently "in use".
NWAGENT 6.x and 7 seem to have some instability. They appear to unload more reliabily by using UNLOAD NWAGENT from the console command line rather than using the menus. I've had them many times and ABEND using the menus but never when unloading manually.
To check SAP packets. RCONSOLE onto each in turn
"LOAD IPXCON"
"Services"
"Display entire services table"
Look for the server "at the other end" in the list ...
Assuming its called FS10 - you'll see something like this
FS10 CE100B_1_E82 0004
FS10 CE100B_1_E82 004B
FS10 CE100B_1_E82 0107
FS10 CE100B_1_E82 023F
If you don't see 0x04 0x4b and 0x23f you probably have problems. Check on the Novell site for descriptions of what the packets to.
Now reverse the process and look on the other server. The packets broadcast should match at each end. If not then your backup server won't be able to "see" the TSA and will default to a simple "DOS" based copy.
Regards
Mark
RCONSOLE into the backup and production (target) servers.
Check for NWAGENT and TSA on the production server.
Type "modules TSA*" (no quotes). Check that some version of the TSA is returned (TSA410 for files and TSANDS to back up NDS)
Check for NWAGENT with "MODULES NWAGENT*" (No quotes)
If loaded OK. It is good insurance to unload and reload if they're not currently "in use".
NWAGENT 6.x and 7 seem to have some instability. They appear to unload more reliabily by using UNLOAD NWAGENT from the console command line rather than using the menus. I've had them many times and ABEND using the menus but never when unloading manually.
To check SAP packets. RCONSOLE onto each in turn
"LOAD IPXCON"
"Services"
"Display entire services table"
Look for the server "at the other end" in the list ...
Assuming its called FS10 - you'll see something like this
FS10 CE100B_1_E82 0004
FS10 CE100B_1_E82 004B
FS10 CE100B_1_E82 0107
FS10 CE100B_1_E82 023F
If you don't see 0x04 0x4b and 0x23f you probably have problems. Check on the Novell site for descriptions of what the packets to.
Now reverse the process and look on the other server. The packets broadcast should match at each end. If not then your backup server won't be able to "see" the TSA and will default to a simple "DOS" based copy.
Regards
Mark
- Thread starter
- #6
Thanks Mark
The 004b packet is missing, and according to the Novell site this packet is used for a Btrive server service. I haven't found any info that says this should cause my problem, but apart from that the other packets are on both servers. What I did find is that arcserve help says 4.x servers have a issue loging into tsa when using the Supervisor account, so I have created another account and will see if this helps.
thnoss
The 004b packet is missing, and according to the Novell site this packet is used for a Btrive server service. I haven't found any info that says this should cause my problem, but apart from that the other packets are on both servers. What I did find is that arcserve help says 4.x servers have a issue loging into tsa when using the Supervisor account, so I have created another account and will see if this helps.
thnoss
markshaw100
IS-IT--Management
Thnoss
If in doubt. Start off the copy job then type
ARCSERVE DEBUG ON
at the console. You can then see what happens as
the job tries to authenticate. I'd have a look at
any switches or routers etc. and see what packets
might be getting filtered out etc.
(use ARCSERVE DEBUG OFF soon after as it will rapidly
fill up your hard drive! ;0)
Regards
Mark
If in doubt. Start off the copy job then type
ARCSERVE DEBUG ON
at the console. You can then see what happens as
the job tries to authenticate. I'd have a look at
any switches or routers etc. and see what packets
might be getting filtered out etc.
(use ARCSERVE DEBUG OFF soon after as it will rapidly
fill up your hard drive! ;0)
Regards
Mark
- Status
Similar threads
- Locked
- Question
- Locked
- Question