One thing to keep in mind, collocation=on does not mean one tape
per node, nor does collaction=FILES mean one tape per filespace.
It might if you set maxscratch to an infinitely large number, but
with collocation on ADSM will attempt to use the fewest number of
tapes for a node or filespace. If there are not enough tapes to
do one per tape (which would be the least number of tapes
possible), ADSM will put data for more than one node onto
one tape.
-- Tom
Thomas A. La Porte
DreamWorks Feature Animation
tlaporte AT anim.dreamworks DOT com
On Wed, 17 Mar 1999, Dusedau, Stefan wrote:
>Kelly,
>
>We do not have collocation turned on since we could not afford the number of
>tapes it would require. I just ran a simple SQL (select node_name, count(*)
>from volumeusage group by node_name). This produces a list of how many
>volumes contain data for each node on the server. The top hitter is a node
>that has been backing up for 26 months and uses 1036 volumes. Of course this
>includes drm copies, archives and inactive copies so the actual number for a
>restore will be less. I have spoken with IBM about this on several occasions
>and they have recommended exporting and importing the nodes. This would
>probably take a week to do for a node using 500 tapes. By the way we have
>our copy group setup as VERE=7 VERD=1 RETE=45 RETO=60.
>
>Also, I have found that the average tape mount on a 3494 is between 30 and
>60 seconds. This is for 5 3494s connected to AIX and AS/400 environments so
>I believe that it is the 3494s not the operating system.
>
>I am interested in to hear what others have done to help in this area.
>
>Thank You,
>
>Stefan Dusedau
>infoWorks
>A Viacom technology service
>(212)258-6739
>stefan.dusedau AT viacom DOT com <mailto:stefan.dusedau AT viacom DOT com>
>
>
> -----Original Message-----
> From: Kelly J. Lipp [mailto:lipp AT storsol DOT com]
> Sent: Tuesday, March 16, 1999 6:09 PM
> To: 'Dusedau, Stefan'
> Subject: RE: restore times
>
> I don't think the reclamation process would spread data on
>that many tapes.
> I wonder what actual experience will show with a system
>that has been
> running for a year or more.
>
>
> Kelly J. Lipp
> Storage Solutions Specialists, Inc.
> www.storsol.com
> lipp AT storsol DOT com
> (719)531-5926
>
> -----Original Message-----
> From: Dusedau, Stefan
> Sent: Tuesday, March 16, 1999 1:08 PM
> To: 'lipp AT storsol DOT com'
> Subject: RE: restore times
>
> Kelly,
>
> I agree with most of what you said regarding tape mounts.
>The one
> difference
> is that 30 day retention does not mean 30 tapes. If you nave
>a node that
> has
> been backing up for a year and file "A" has not changed or
>been deleted in
> that time, it may be on any of the hundreds of tapes that
>have been used
> during reclamation. Now multiply this by the number of files
>that do not
> change often and you have spread your data across more tapes
>then the last
> 30 days have used.
>
> Thank You,
>
> Stefan Dusedau
> infoWorks
> A Viacom technology service
> (212)258-6739
> stefan.dusedau AT viacom DOT com <mailto:stefan.dusedau AT
> viacom DOT com>
>
>
> -----Original Message-----
> From: Kelly J. Lipp
>[mailto:lipp AT STORSOL DOT COM]
> Sent: Tuesday, March 16, 1999 11:30 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: restore times
>
> If one does a realistic examination of
>restore times, tape
> mounts, unless
> you have very slow tapes, usually won't come
>into play.
>
> Let's start the discussion with service
>level agreements.
> For instance,
> all of us should have in place agreements
>with our customers
> that sound
> something like this:
>
> 1. For single file restores, we offer a
>restore time of one
> hour or less.
> 2. For a directory tree restore up to 200
>MB, we offer a
> restore time of
> one hour or less.
> 3. For a full disk restore up to 4 GB, we
>offer a restore
> time of four
> hours or less.
> 4. For a full system restore up to 100 GB,
>we offer a
> restore time of 24
> hours.
>
> Wiggle these to meet your needs.
>
> Think about what many of us can offer now.
>Are the numbers
> above
> reasonable from a business standpoint? Most
>of us state
> we'll do it as
> fast as possible when we should be putting
>in place SLAs
> that more
> accurately reflect reality.
>
> Restore statistics:
>
> 99% of restores are for single files, or
>small numbers of
> files from
> yesterday. Not a problem with ADSM.
> 1% of the restores are bigger than this:
>complete
> directories, all the data
> for an application, a complete disk, a
>complete system.
> This flat does not
> happen very often, but one should be
>concerned (but not
> overly so) about
> it.
>
> Let's look at the larger restores. Pick a
>hard one like the
> full disk
> restore. Assume a 30 day data retention
>(verdeleted,
> verexists, retextra,
> retonly all set to 30). Worst case, 30 tape
>mounts will be
> required during
> a full restore of the disk. Most of the
>data will be on the
> first tape
> with small amounts scattered on the rest of
>the 30. In
> fact, looking at
> typical usage, the same files tend to change
>so the same
> files will show up
> on many of the tapes. So during a restore,
>these files will
> only be
> restored once, and perhaps from the most
>recent tape. Tape
> mounts just
> went way down.
>
> But let's keep it at 30 mounts. Say each
>mount takes two
> minutes and the
> time to reach data is another minute for a
>total of three
> minutes per tape.
> Then we can do some real work and move
>data. For this
> case, we'll expend
> 90 minutes of our four hour window. Are we
>in trouble? I
> don't think so.
> We should meet our SLA for this restore.
>Will we actually
> need to mount
> 30 tapes? Probably not, since we've got
>reclamation going
> on as well.
>
> If tape mounts really become a problem, and
>I'm maintaining
> this is the
> least of your worries about large restores,
>one can always
> use collocation
> to reduce them.
>
> Think about your data. It's usage and its
>change patterns.
> Think about
> your other protection mechanisms: RAID,
>shadowing, etc.
> Think about your
> restore requirements and SLAs. For those of
>you still
> believing GFS
> (Grandfather, father, son) backups are still
>better, think
> about this: you
> have to mount all of the incrementals
>between a full even
> though most of
> same files change everyday. Using this
>method, more files
> are actually
> restored and then deleted than ADSM would
>actually restore!
>
> BTW, one should test the restore times
>before publishing
> SLAs. However, if
> one applies reason and logic, this just
>isn't all that hard.
>
> Thanks,
>
> Kelly J. Lipp
> Storage Solutions Specialists, Inc.
> www.storsol.com
> lipp AT storsol DOT com
> (719)531-5926
>
> -----Original Message-----
> From: McAllister Craig-WCM033
> Sent: Tuesday, March 16, 1999 9:00 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: restore times
>
> That certainly appealed to me at one point,
>however, this
> will "push" one
> version of your files out of the queue you
>have made from
> your management
> class. (Selective backup will keep two
>copies of exactly the
> same file, and
> may push one older, different version out
>into expiration)
> For this reason, perhaps if you want this
>type of
> functionality, you should
> be looking at file archival, rather than
>backup.
>
> It certainly works for me.
>
> -Craig.
>
> -----Original Message-----
> From: Fluker, Tom R
>[mailto:Tom.Fluker AT VIASYSTEMS DOT COM]
> Sent: 16 March 1999 15:34
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: restore times
>
>
> It appears to me that one of the problems
>with restores
> taking so long is
> that the incremental nature of ADSM will,
>over time, spread
> the required
> files over many volumes in a tape storage
>pool. Requiring
> mounts, and
> searches, of multiple tapes requires a lot
>of time.
>
> Has anybody tried, say once a month,
>performing selective
> backups for
> entire
> file systems in an effort to aggregate all
>the files
> required for a restore
> in reasonable proximity to each other?
>Incremental backups
> would then get
> scattered but it may limit the number of
>tapes that would be
> required.
> Would this help the restore time problem?
>
> I'm considering such an idea and was
>wondering if anybody
> has had any
> similar experiences that may help.
>
> Tom Fluker
> Tom.Fluker AT viasystems DOT com
>
|
