> We've been lucky and haven't had many large restores -- usually only a few
> files at a time. Does ADSM restore logically by file or by tape? For
> example, if you're restoring an entire file system, does it go down the
> directory structure and restore them in that order (which could result in
> the same tape being mounted several times) or does it get a list of all
> the tapes it will need and then restore all files from tape1, followed by
> all files from tape2, etc. I do remember that allowing your directories
> to be migrated to tape can cause tape mount thrashing, but I don't
> remember about the restore of files.
>
> Anyone know the answer to this?
>
> Tina
>
> -----Original Message-----
> From: Kelly J. Lipp [SMTP: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
|
