>Allowing only 32 tapedrives is seriously shortsighted. The number of
>tapedrives directly limits the amount of data one can put in a cell;
>if you can't back it up, you should not put it in the cell.
>
>The ASSUMPTIONS:
>
> Exabyte 8200's. (That's all I have time data for.)
> Full backups must be done within a 24 hour period.
> Full backups are done one day per week.
> There are no network problems durring backups. (very optimistic)
> There are no AFS problems durring backups. (very optimistic)
> One tape takes 3 hours to write. (very optimistic)
> All tapes have no errors and are the correct length. (ify)
> backup has zero overhead per volume set. (30mins/set actually)
> use just one cell.
I agree that Transarc should increase the number from 32 to some other larger
constant, however I disagree with some of your assumptions.
Why must Full backups be done within a 24 hour period? We back up 40 gig over a
2 day period (fulls once a week over 2 days and incrementals every day). If we
run out of time for 2 days, we will make it three days and so on. Since the
backups are broken down into separate volume sets, it makes no difference which
day the volumeset is scheduled for the full backup.
Network problems can be eased by placing your servers a backbone (e.g., an FDDI
backbone). The backup machine also belongs there.
We experience no AFS problems that hinder our backups. I'd be curious as to
your experiences in this area.
Transarc should write to the end of the tape instead of a predetermined length.
But as far as time to write and tape errors, consider buying new and better
equipment if this is a problem for you. A couple of vendors are
coming out with some impressive new tape drives this year (not 8mm or 4mm but a
brand new format). Its worth researching this market.
As for the 30mins/set overhead per volume set,
I assume you mean the wait between when you issue the dump command for the
volset and when it actually starts writing to tape? This is due to 2 things.
The first is an inefficiency in the scan to make sure each volume you are
backing up has a different clone time from the previous one. We took out this
feature from our source code base and the wait has been cut down from
20 minutes to 2 minutes. Transarc needs to change this and I've sent them a
description of the problem some time ago. The second problem is
when your volumesets have wildcard hosts in them. It turns out that its much
faster to have volumesets with specific hosts in them rather than wildcarding
this (of course this is more a pain to manage).
People might also notice the latency between starting up the
backup command and waiting for the first prompt. This is also due to an
inefficiency that reads in all the volume sets and resolves the host names via
gethostbyname(). I can't tell you how many times the name server is called at
startup in our cell. We finally put a small code segment in that caches the
host names. The prompt now almost comes up instantaneously.
Mark Giuffrida
University of Michigan
IFS/AFS Deployment Project
[EMAIL PROTECTED]
