ADSM-L

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

2005-10-13 13:04:04
Subject: Re: performance of restore v. retrieve v. backupset restore
From: Nancy Reeves <Nancy.Reeves AT WICHITA DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 13 Oct 2005 12:03:43 -0500
Does MOVE NODEDATA move all files of the node, or just the active ones?

Nancy Reeves
Technical Support, Wichita State University
Nancy.Reeves AT wichita DOT edu          316-978-3860

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 10/13/2005
11:25:07 AM:

> ==> 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