Blair,
Are you sure that the filespaces not converting require long name support ?
See extract below, from TSM for NetWare Using the Backup-Archive Client
To see the name spaces that are loaded on a volume, enter volumes at the
NetWare console, for example: 411:volumes. You will see display similar to
this:
Mounted Volumes Name Spaces Flags
SYS DOS, LONG
Cp Sa
VOL1 DOS, MAC, LONG Cp SA
411:
VOL1 was backed up with the file space type of NTWFS or DOS name space.
When TSM starts a full incremental of VOL1, it detects that VOL1 has both
MAC and LONG name spaces, but that the data is backed up using the DOS
name space. This causes the file space to be updated to the long name
space. Even though both MAC and LONG are loaded, TSM chooses the name
space that can handle the longer name; in this case, it is the LONG name
space.
Hope this helps,
John
Blair Wickstrand <Blair_Wickstrand AT BR-INC DOT CA> on 07/25/2000 03:53:19 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: John Naylor/HAV/SSE)
Subject: Re: Netware long name support
Hello,
Thankyou for your quick reply. included here is my dsm.opt file. As You can see
I already have specified the "memoryefficientbackup no" option with no luck.
I've been experimenting with various parameters to try and improve
backup/restore performance. I find CPU utilization is very heavy on a Compaq
Proliant 1850R 550Mhz unit.
The odd thing is that on remote servers, SYS always seems to get long name,
while other volumes are problematic. It also seems that on servers where all
currently installed volumes were created at time of server build, long name
support is also there. I've tried command lines like "dsmc inc -memoryef=no
orion\io:" with no luck.. The one good thing I've noted from installing Service
pack5 over Service pack 4 is that the huge memory leak in SMDR while backing up
NDS seems to have been minimized. previously SMDR would allocate the amount of
memory equal to the size of our NDS database which is about 100megs and never
let it go, each backup would grab another 100megs until server runs out of
memory. At this time I back it up via command line. However, it seems for every
domain that is backed up from a remote server there is an SMS/SMDR ?? connection
left behind that is only clearable by unloading smdr.
COMMMETHOD TCPip
TCPSERVERADDRESS tazmo
*Processorutilization 10000000
*RESOURCEUTILIZATION 20
SCHEDLOGRETENTION 4 S
NODENAME rigel
PASSWORDACCESS GENERATE
QUERYSCHEDPERIOD 1
DOMain sys:
Domain SERVERSPECIFICINFO
DOMain vol1:
DOMain nds:
MEMORYEFFICIENTBackup No
DOMain Orion\mars:
DOMain Nebula\Saturn:
*DOMain Nebula\Jupiter:
Domain Galaxy\Fire:
DOMain SOL\ICE:
*Domain Pulsar\NDS:
Domain Solarwind\Flare:
DOmain Eclipse\Lunar:
DOMain Orion\SERVERSPECIFICINFO
DOMAIN NEBULA\SERVERSPECIFICINFO
DOMAIN GALAXY\SERVERSPECIFICINFO
DOMAIN SOL\SERVERSPECIFICINFO
DOMAIN PULSAR\SERVERSPECIFICINFO
DOMAIN COMET\SERVERSPECIFICINFO
COMPression OFF
TCPBuffsize 512
TCPWindowsize 64
TXNBytelimit 64000
largecommbuffers yes
NWIGNORECOMPRESSbit yes
MAXCMDRetries 2
Changingretries 2
RETRYPeriod 5
SCHEDLOGname sys:\tivoli\dmsched.log
SCHEDMODe Polling
*TCPClientAddress 204.209.188.227
ERRORLOGname sys:\tivoli\dmserror.log
EXCLUDE sys:\system\secaudit.log
EXCLUDE sys:\system\events.log
EXCLUDE sys:\system\system.log
EXCLUDE sys:\system\btrieve.trn
EXCLUDE SYS:\system\tsa\err$hst.*
EXCLUDE sys:\system\tsa\err$log.*
EXCLUDE sys:\system\tsa\skip$log.*
EXCLUDE sys:\system\tsa\tsa$temp.*
EXCLUDE sys:\system\sys$log.err
EXCLUDE sys:\_swap_.mem
EXCLUDE sys:\vol$log.err
EXCLUDE sys:\tts$log.err
EXCLUDE JUPITER:\CINFO\temp\*.tmp
*
* NWUSER server_1_name\user:password
* NWUSER server_2_name\user:password
* NWUSER nds_tree_name\user:password
*
NWPWFILE YES
John Naylor <John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK> on 07/25/2000 03:46:14
AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Blair Wickstrand/Poco)
Fax to:
Subject: Re: Netware long name support
Blair,
To convert your filespaces to long name support, it is not sufficient to omit
the parameter "memoryefficient yes" from your dsm.opt.
You must run a full uncremental backup with "memoryefficientbackup no" in your
dsm.opt.
Dont forget to unload dsmc to pick up the change.
This will force conversion, but 2 caveats
Conversion run will take quite longer than normal backup, because of the
database changes, so you
may want to plan it for outside your busiest backup window.
The conversion will also use more memory on the client, so may cause problems if
you are already suffering memory leaks, or just generally short of memory on the
client.
John
Blair Wickstrand <Blair_Wickstrand AT BR-INC DOT CA> on 07/24/2000 05:59:00 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: John Naylor/HAV/SSE)
Subject: Netware long name support
Hello,
I am experiencing sporadic long name support on my servers using the Client
3.7.2 ( DSMC ver 3.07b ) on Netware5 service pack 5. The ADSM server is running
version 3.7 .
What is happening is that on a given server volume SYS gets backed up with long
name while another volume on the same server only gets shortname. Another backup
product which we are converting from ( Arcserve) has no trouble getting
longnames. I am not using the parameter "memoryefficient yes" . I have noticed
a patterm where volume SYS is the most likely to have long name support
indicated. Dsrepair has been run on these servers. The good part is that on file
restores the long names are retained. The web client however only shows files
and directories as short names.
12 07/20/2000 08:09:49 NTWFS ORION\IO:
13 07/23/2000 22:58:27 NTWFS ORION\MARS:
14 00/00/0000 00:00:00 NovellSMS ORION\SERVER SPECIFIC INFO
15 07/20/2000 08:08:56 NTW:LONG ORION\SYS:
Has anyone any ideas on how to fix this ?
Thanks,
Blair
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group
**********************************************************************
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group
**********************************************************************
|
