ADSM-L

AW: Slow restore for large NT client

2000-12-15 12:20:12
Subject: AW: Slow restore for large NT client
From: Stefan Holzwarth <stefan.holzwarth AT ZENTRALE.ADAC DOT DE>
Date: Fri, 15 Dec 2000 18:20:36 +0100
> What I think is happening is this:
> Due to the incremental forever backup method the files are becoming
> fragmented on the tapes. A file changes so a new version is 
> written to the
> tape. The oldest version is then deleted  leaving a gap on 
> the tape. The
> problem with fragmented tapes is that the seek speed of the 
> tape drives is
> very slow.

This is also my opinion and you should have a look at the managementclasses:

If you have 3 additional versions of a file and all of the data fits onto a
single tape
you have only 25% (1+3/100) information on that tape - means only 25%
throughput...

I am not sure, there are some things you or TSM can do against:

weekly selective backups at the cost of traffic and loosing one
fileversion
second incremental backup each day with different managementclass (only
one version)
creating backupsets weekly and "forewardrecovery" with the last
incrementals
new TSM feature could be:  single restore session can use more than one
tapeunits

Any more ideas?

With Regards,
Stefan Holzwarth
ADAC Germany

> -----Ursprüngliche Nachricht-----
> Von: Mark Bryant [mailto:mark.bryant AT ZURICH DOT COM]
> Gesendet am: Donnerstag, 21. September 2000 13:19
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Slow restore for large NT client
> 
> My view on the slow restore problem is that it is down to the tape
> technology. I've done quite a bit of testing with restores on 
> AIX, NetWare
> and NT and can say the following:
> 
> 1. I can rule out the network and server performance as the 
> bottle neck.
> Doing a full backup and restore will give comparable 
> performance and ADSM
> will run as fast as the network will allow. Also as fast as any other
> product (Arcserve, BackupExec).
> 2. Large filesystems containing large files will give a 
> reasonable restore
> performance. Large filesystems with lots of small files give 
> a terrible
> restore performance.
> 
> What I think is happening is this:
> Due to the incremental forever backup method the files are becoming
> fragmented on the tapes. A file changes so a new version is 
> written to the
> tape. The oldest version is then deleted  leaving a gap on 
> the tape. The
> problem with fragmented tapes is that the seek speed of the 
> tape drives is
> very slow. Some are better than others, I've found Magstar  3570's are
> quite a bit faster than DLT's. So when we come to do a full 
> restore the
> tape drives are spending most of the time searching rather than
> transferring data.
> Arcserve and the like do not have this problem as they are 
> generally setup
> for a weekly full, daily differential so are able to stream 
> data off the
> tapes in one big block and are only really limited by the 
> transfer rate of
> the tape drive.
> The probem with ADSM has really got worse over the last few 
> years due to
> the amazing growth in disk capacity/price. It is now becoming a real
> problem when we have these big fileservers going in.
> I'm not sure what the answer is. Some things that can help 
> are to make sure
> you are collocation on your tape pools and run regular reclamation to
> reduce the fragmentation.
> 
<Prev in Thread] Current Thread [Next in Thread>
  • AW: Slow restore for large NT client, Stefan Holzwarth <=