>At MIT, we do a vos backup of about 20,000 volumes nightly. It turns
>out that "vos backupsys" takes too long, as does just about every other
>method. The only way that we can complete this task in about 7 hours
>is:
>
>- Have a list of the servers, and split them equally among four threads
> of the program, running in parallel. Each thread will then do a
> "vos listvol" on the server, and then "vos backup" of each appropriate
> volume that needs to be cloned nightly (after checking the name of
> the volume).
>
>It turns out that a "vos listvldb" is too expensive, and too slow, and
>that this out-performs "vos backupsys", even if you were only to specify
>a server. Somehow, there is an additional advantage gained by
>completing all the transactions on a single server before moving on to
>the next; I can only attribute this speedup to the inefficiencies of the
>kernel in establishing a connection to a new host. RX is based on UDP,
>so theoretically, this speedup should not be occurring, but it is.
At the "umich.edu" cell at the University of Michigan, we are currently hovering
just below 7000 volumes. We are taking the new attitude that the only way AFS
will scale highly is to have each file server do all its own maintenance (backup
clones, backups to tape stacker, etc) in parallel.
Thus, each night each server does a "vos backupsys -server localhost
-localauth". Its quite reasonable now as we expect each of the five servers to
finish cloning within 1 hour of starting the command (with most of the time
spent in the actual cloning process). I could see how having 50,000 volumes
would make even this too expensive though.
We are also fighting the methodolgy of doing tape backups from a central point and
distributing the backups to the file servers themselves through an automated
cron job and tape stacker. We have (and are) learning a lot as we put this into
production. I have a 600 line Expect script which manages this daily backup and
we are hoping to put it into final production over the next 2-4 weeks. If there
is interest in this script I will send it to the afs-contrib area when its
ready. It automatically initializes all tapes (defeating the expiration stamp)
and will delete the dumpid on the recycled tape from the backup database. I'd
be interested in others who have attempted this.
Mark Giuffrida
University of Michigan
[EMAIL PROTECTED]
