[OpenAFS] Backup-strategy

Craig_Everhart@transarc.com Craig_Everhart@transarc.com
Mon, 16 Dec 2002 11:34:03 -0500 (EST)


Excerpts from transarc.external.openafs: 16-Dec-02 Re: [OpenAFS]
Backup-strategy "Klaas Hagemann"@northsa (1750*)

> It works very well, but it takes too long time.
> We have more than 20000 volumes and it takes round about 10 seconds for
> every volume. So we cannot back up all at one day.
> Even running multiple jobs at once using the "&" does not help.
> Any suggestions to make this one faster or how to do multiple jobs at once
> in a better way?

It shouldn't take that much longer to do vos dump|vos restore than it
would to do vos release, except that with vos release the traffic goes
volserver-to-volserver, while with dump/restore it goes
volserver-to-vos-to-volserver.  If the network speed of the
satellite-central link is dominant, then it should take the same time to
do either one.  How long does it take to do a release vs. dump/restore? 
You say 10 seconds for the dump/restore but I don't know how long for
the release.  Is a day long enough for 20000 of those?  My guess is that
the 10 seconds is mostly setup time, not data transfer time.  If it were
longer, I'd say that it would generally get shorter for successive
dumps/restores, since you'd be doing only incremental dumps, and no
volume creations.

I don't think that 10 seconds is that long a time for dump/restore.  But
it could still be shorter for successive runs.  If you really feel that
concurrent jobs don't speed things up, then maybe the slowness is the
satellite-central site link speed.  You're shipping in principle a lot
of data across it.

Basically, you've gotten even further into site engineering.

Glad that the architecture works for you, sort of.  Maybe you need to
back up half the volumes every other day.  Or some of them only weekly. 
Let the mount of the user.foo.backup volumes take care of the daily
restoration requests.

		Craig