ADSM-L

Re: performance of restore v. retrieve v. backupset restore

2005-10-13 12:25:43
Subject: Re: performance of restore v. retrieve v. backupset restore
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 13 Oct 2005 12:25:07 -0400
==> On Thu, 13 Oct 2005 10:57:30 -0500, Nancy Reeves <Nancy.Reeves AT WICHITA 
DOT EDU> said:


> The clients are all 5.2.2.0 The server is also 5.2.2.0 on AIX. We have
> LTO2 tapes in a robot with 6 drives. Each disk volume to be moved is 39.9
> G. One is 20% full, one is 50% full, and one is 95% full.

> Since my tapes hold 200G, if I use a backupset, I will have only 1 tape
> mount.  However, if I use a regular restore, I can have the restore multiple
> threads and drives (given that maxnummp is high and mountretention is low).
> I do not have collocation on, but I could change that and "force" a full
> backup of the filesystems that need to be moved, so they would be
> collocated, but that wouldn't be much different than using a backupset,
> would it?

> Any advice?

If you MOVE NODEDATA, perhaps to a (temporary) collocated stgpool, then you
can get all the data to one place without having to back it all up again.

If you've got enough disk, you might want to MOVE NODEDATA again, just before
the restore, onto FILE or DISK devclasses.  Depending on your tape
architecture, it could imprrove your restore speed anywhere from a bit to a
lot.


In your shoes, I'd shove the data in a FILE devclass with volume size ~5GB
just before the restore.  Multiple threads, because multiple volumes, and
disk's good seek behavior.


- Allen S. Rout