I do agree that the amount of files plays a role in the time that it
takes to back up the node. My other question to this was why I could not
see the sans volumes anymore since we upgraded to NetWare 6.5. After the
upgrade is when I noticed we stopped backing up sans volumes. So in the
scheduled event, had to put the volumes in the object line or the
DSM.opt file. There are a lot of files to scan, but the backups are 10
times longer than they were before the upgrade to 6.5....We did not add
volumes or change anything except upgrade the OS. I have looked at 3
other nodes with the same amount of files being scanned,
objects inspected= 828,367 backed up 16gb in 3:49:00 (novell node)
objects inspected= 1,558,704 backed up 39.04 gb in 1:26:03 (unix)
compared to Novell Cluster node with San volumes at
objects inscpected=1,544,740 backed up 2.82 gb in 6:28:00
Thanks, Mark Hayden
Informations Systems Analyst
E-Mail: MHayden AT epa.state.il DOT us
>>> mark.stapleton AT BERBEE DOT COM 9/22/2004 12:02:53 PM >>>
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of Mark Hayden
>Up until this last upgrade of NetWare
>6.5 this worked fine, we ran INC backups daily and TSM would
>see all the Sans volumes assigned to each Server within the
>cluster. What has happened since the upgrade is SPEED (or lack
>of) of backups , and as you will see below we have to tell the
>Tsm schedule to include the sans volumes. has anyone ran into
>this problem? We are running 5.2.2 on the client with TSM
>server code of 5.2.2.1. Adding the volumes to the schedule is
>one thing, but take a look at how long our backups are now
>taking.....This is also very slow when doing restores.....We
>have just added NetWare SP2 as well, but did not help.....
>
>Executing scheduled command now.
>09/21/2004 19:59:38 --- SCHEDULEREC OBJECT BEGIN INC_S_IEPA_03
>09/22/2004 02:27:38 --- SCHEDULEREC STATUS BEGIN
>09/22/2004 02:27:39 Total number of objects inspected: 1,544,740
>09/22/2004 02:27:39 Total number of objects backed up: 10,643
>09/22/2004 02:27:39 Total number of objects updated: 0
>09/22/2004 02:27:39 Total number of objects rebound: 0
>09/22/2004 02:27:39 Total number of objects deleted: 0
>09/22/2004 02:27:39 Total number of objects expired: 105
>09/22/2004 02:27:40 Total number of objects failed: 1
>09/22/2004 02:27:40 Total number of bytes transferred: 2.82 GB
>09/22/2004 02:27:40 Data transfer time: 221.26 sec
>09/22/2004 02:27:40 Network data transfer rate: 13,386.33
>KB/sec
>09/22/2004 02:27:40 Aggregate data transfer rate: 127.22
KB/sec
>09/22/2004 02:27:40 Objects compressed by: 0%
>09/22/2004 02:27:41 Elapsed processing time: 06:28:00
Look carefully.
1. While elapsed time from beginning to end of the backup is 6+ hours,
the actual amount of time transferring data is 221 seconds.
2. Look at the number of objects getting inspected--1.5+ million.
3. Look at transfer speed rate at the time the backup
completed--13MB/sec
What appears to be happening is that the time it takes to scan the
(large) directory structure is eating up most of the 6.5 hours. There
is
not much to be done for this as is--there is no TSM journaling service
for NetWare as there is for Windows.
You may want to consider the idea of breaking up the backup by using
multiple TSM node definitions, so that the backup (and directory scan)
are multithreaded. Multiple discussions on how to do this exist in the
adsm-l mailing list archive at http://search.adsm.org.
--
Mark Stapleton (stapleton AT berbee DOT com)
Berbee Information Networks
Office 262.521.5627
|
