I was planning on marking the originals either 'unavailable' or 'offsite';
our off-site storage is about 20 minuts away, so an on-site restore will
start with the courier bringing these tapes back.
We use SAP's brbackup to drive the IBM backint/ADSM interface - which, under
the covers, uses the ADSM API to do the equivalent of a 'dsmc archive' or
'dsmc retrieve'. We tell backint how many concurrent processes to use, and
it fires up that many child processes, This is, IMHO, the ONLY way to go
with the SAP backups via ADSM.
We're on an SP frame, so each of the streams is running directly to tape on
the ADSM server - and we're basicly limited by the tapedrive speed.
We are looking at the possibility of setting up a second ADSM server with a
smaller STK (9714) and two or three drives as our off-site system -- but
we're having trouble justifying the network link cost. Maybe next year.
As for Yves' approach - the disk farm on our SAP database server now stands
at 684 GB; 342 GB of data space (which our DBAs *insist* will last until
this August) and another 342 GB for the mirror. In addition, we have 342 GB
on our SAP test environment (rebuilt about six times per year by restoring
from the production backup). I currently have 72 GB on my ADSM server and am
unlikely to get more for a while - and this has to handle AIX and NT server
incrementals, Oracle off-line redo logs, and several MS Exchange servers
(plus, of course, the ADSM database).
Also, we found that we can't get the same performance in the backup if we go
to disk first. I get about 14 GB/hr to disk for one stream, about 22 GB/hr
for two, and haven't had the time to try three (the ADSM storage pools are
all on 9 GB SSA drives). I'm currently showing about 59 GB/hr to the three
tape units.
We only get one production outage a week on the SAP environment, for 12
hours. In that time period, we do an off-line backup, any database reorgs
our DBAs think we need, and (if there were reorgs) another off-line backup.
Thanks, both of you, for the suggestions!
Tom Kauffman
Sr. Technical Advisor
NIBCO, Inc
kauffmant AT nibco DOT com
> ----------
> From: Kelly J. Lipp[SMTP:lipp AT STORSOL DOT COM]
> Sent: Thursday, May 14, 1998 10:28 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Storage Pool backup & D/R recovery question
>
> I'm just thinking out loud on this one...
>
> Taking the primary pool tapes off-site will work. When you check them out
> of the robot, make sure they get marked unavailable (sort of hard not to)
> so that ADSM will use the copy pool tapes for the restore. Or fetch the
> tapes from the off-site and do the restore from them. If you use the copy
> tapes, you're probably looking at a long restore: 160 GB divided by 30
> GB/hour over 100 M network = 5.2 hours or so, downhill, wind at your back.
> But if it takes two hours to fetch the tapes, you're probably money ahead
> doing it this way.
>
> You're mostly worried about the restore on this one, right? I can't
> divine
> a way to get three copy stg pool tapes. How about another robot with
> smaller capacity tapes? DLT4000s. How about creating another device
> class
> in this robot with format=20C instead of format=35C. I think you would
> have to assign volumes to the pool that used this class instead of using
> scratch tapes to satisfy volume requests. I'm getting way out here now,
> but, hey, this requires some deep thinking! I'll leave the implementation
> to the reader.
>
> My next question would be can a really multi-stream the restore? Can I
> really use more than one tape effectively? How are you doing the backup
> to
> three tapes simultaneously? Three streams from the client, or are you
> using migration from a very small disk pool? If you're using three
> streams, you could use three different primary/copy storage pool
> hierarchies. This might have an effect on your backup stg commands but
> may
> result in a quicker restore since you could start three streams to do it.
>
> Sorry about the stream of consciousness, but hopefully some it will spur
> the right thoughts.
>
> Kelly Lipp
> Storage Solutions Specialists, Inc.
> lipp AT storsol DOT com
> www.storsol.com
> (719) 531-5926
>
> -----Original Message-----
> From: Yves.Morin [SMTP:Yves.Morin AT STANDARDLIFE DOT CA]
> Sent: Thursday, May 14, 1998 8:29 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Storage Pool backup & D/R recovery question
>
> Hi!
>
> Here's what we do here:
>
> Backup Schedule: Backup DB to Disk Pool (120GB un compressed)
> Admin Schedule: backup stg diskpool copypool maxprocess=2
> Admin Schedule: backup stg tapepool copypool maxprocess=2
> Admin Schedule: update stg diskpool highmig=1 lowmig=0
>
> It's the fastest way to do it that I found so far....
>
> Kauffman, Tom wrote:
> >
> > It is currently taking about three hours to back up our 156 GB SAP/R3
> > database, using three tape drives.
> >
> > We then spend about eight hours making a copy for off-site storage, with
> two
> > tape drives. This implies that we will need about eight hours to do the
> > restore from this tape (and it currently *is* one tape). This is too
> long.
> >
> > Is there any good method to force ADSM to do a one-for-one copy on
> storage
> > pool volumes? Or should I consider leaving the copy-pool tape on-site
> and
> > moving the original storage-pool tapes off-site? Or is there yet another
> > technique I'm not seeing here?
> >
> > We're currently running ADSM 2.1.5.13 at the server and 2.1.5.6 on the
> > client (AIX 4.2.1, both of them); we'll be going to ADSM 3 as soon as I
> can
> > get the financing approved. We have four (4) Quantum DLT-7000 drives in
> a
> > StorageTek 9710 silo.
> >
> > TIA
> >
> > Tom Kauffman
> > Sr. Technical Advisor
> > NIBCO, Inc
> >
> > kauffmant AT nibco DOT com
>
|
