Mackey,
Yes I did know that, and it really makes AIX recoveries MUCH more simple
than anything else at this time. We actually backup to the ADSM server
because it had spare RAID space available for those 30 sysback images.
Pretty strange...
Glenn: gwfutrell AT fedex DOT com
Myself: dmhendri AT fedex DOT com
Have a great one...
David
Mackey Morgan wrote:
>
> David, I see what you mean. Did you know that Sysback/6000 can write backups
> to
> the Sysback server's disk as well as tape? This would eliminate the problems
> you mentioned with tape mounts, but would, of course, require some significant
> RAID 1 or 5 disk capacity to store a large number of backups. With this
> arrangement, all you should have to worry about backing up to tape would be
> the
> Sysback/6000 server itself!
>
> I'd be happy to send a note to Glen. What's his address? For that matter, what
> is yours?
>
> Internet: mmorgan AT us.ibm DOT com
> VoiceMail: (972) 280-3278
> IBM Global Services, Product Support Services-----------AIX, SP, ADSM Software
> Services
>
> ADSM-L AT VM.MARIST DOT EDU on 01-26-98 10:25:41 AM
> Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet
> To: ADSM-L AT VM.MARIST DOT EDU @ internet
> cc:
> Subject: Re: db size
>
> Mackey,
>
> Great to hear Texas is as you left it! Since I was the last (of us) to
> leave Memphis, I turned off the lights for you...
>
> I agree with your thoughts on recovering systems. What I implied by
> "lights out" is: automate as much as possible. An example might be 30
> AIX gateways which have been using sysback to backup to a remote drive
> attached to one of the servers. Each system is backed up once every 30
> days. This means operations must mount a tape each day and manually
> track the volumes. Since Gartner indicates an avg 8X cost reduction in
> resource requirements for automated vs. manual tape management, and
> automation reduces the possibility that the tape you need to recover was
> never made, ops opts for automation. Even though there might be a trade
> off in a true disaster scenario. But in that instance here, the
> critical data wouldn't be available until we recovered the ADSM server
> anyway.
>
> So, they mainly want to rid themselves of manual tape mounts. From Jump
> start servers for Solaris, partial OS installs for HP-UX 10.x, and
> sysback with AIX (or just mksysbs on an sp2), we can recover the system
> in a somewhat automated fashion (and even since I've been here in COS I
> have recovered at least 7 SP2 nodes on COS2). This makes the recovery
> of a system dependent on another server, but it is a trade off they hope
> will buy them less error prone recoveries via automation.
>
> Send Glenn a note, he'd love to hear from you...
>
> David
>
> Mackey Morgan wrote:
> >
> > David,
> >
> > Dallas is fine. Being back in Texas is great! Glad to hear you and Glen are
> > doing well in your new respective homes. One small problem, though. I think
> > I
> > forgot to turn out the lights when I left Memphis!
> >
> > I didn't get the implication you made about "lights out operation" with
> > regard
> > to mksysbs. I understand ADSM's utility in backing up/managing the mksysb
> > (or
> > Sysback) images, as they can be quite space consuming. Sysback has the nice
> > feature of providing a network boot capability for your clients as well. I
> > think Sysback's network boot capability is easier to maintain (ie.
> understand!) > than NIM. Anyway you slice it, whether network boot (available
> on
> most > systems), tape boot (N/A on all systems), or diskette boot (N/A on all
> >
> systems), the key is have some way to get the client system OS back up and >
> running...so that you can run the ADSM client code...so that you can restore >
> the best version of your data to the client system. The only other thought I >
> have about it is that the Sysback server and the ADSM server shouldn't be the
> >
> same box unless you've got a bootable tape drive to restore it from--you
> gotta >
> have some place that can always be recovered without the assistance of
> another >
> server, because that server may not be available when you need it most (ie.
> the
> >
> disaster scenario). If I missed your point about "lights out", then teach me >
> something. I need it. > > Mackey Morgan > Internet: mmorgan AT us.ibm DOT
> com > >
> ADSM-L AT VM.MARIST DOT EDU on 01-23-98 02:48:15 PM > Please respond to
> ADSM-L AT VM.MARIST DOT EDU @ internet > To: ADSM-L AT VM.MARIST DOT EDU @
> internet > cc: >
> Subject: Re: db size > > Mackey, > > How's Dallas? > > I agree with you,
> however, we backup the mksysb's for AIX. One > additional note though is, if
> you are trying to go to "lights out" > operation, you have no choice. We are
> trying to achieve that with AIX > mksysbs, Solaris Jumpstart servers and HP-UX
> full backups. > > On a side note, Colorado is nice, and Glenn loves Orlando.
> They are > trying to build another 82-noder here to replace the old 82-sp2
> (new
> one > uses more SMPs). Maybe I'll see ya, eh? > > David Hendrix > > Mackey
> Morgan wrote: > > > > Ann, > > I would add that ADSM is not generally used to
> back up UNIX (ie. the operating > > system), which accounts for a huge chunk
> of
> those 200,000 files you mentioned. > > I support AIX installations for which I
> recommend using either mksysb (an AIX > > command contained in the fileset
> bos.sysmgt.sysbr) for operating system backup > > or else Sysback/6000, a
> separate program product that is moderately priced and > > has excellent
> features for backup/recovery of AIX Opsys and non-root Volume > > Groups. So
> for
> the "bare metal restore" portion of your overall backup > strategy > (please
> don't forget this part!! :-o) , use one of these products > and, with the >
> possible exception of AIX/UNIX configuration files (eg. /etc/*), > there
> wouldn't > be any need to duplicate the backup of base UNIX over and over >
> again (you > select what to backup/exclude via your include/exclude file). If
> >
> you are not > using AIX, you should be looking for similar products or OS >
> utilities that work > with your OS. > > Mackey Morgan, > IBM Global Services,
> >
> Product Support Services-AIX, SP, ADSM Software Services > > >
> ADSM-L AT VM.MARIST DOT EDU on 01-22-98 12:59:26 PM > Please respond to >
> ADSM-L AT VM.MARIST DOT EDU @ internet > To: ADSM-L AT VM.MARIST DOT EDU @
> internet > cc: > >
> Subject: db size > > ---------------------------- Forwarded with Changes >
> --------------------------- > From: INTERNET.OWNERAD at SNADGATE > Date:
> 1/22/98 >
> 11:44AM > To: Jerry Lawson at ASUPO > *To: *ADSM-L at SNADGATE > Subject: db >
> size > >
> -------------------------------------------------------------------------------
> >
> > > Ann - > > One of the General Information manuals suggests as a rule of
> thumb >
> that your > DB should be 1 to 5% the size of the DASD you are backing up. >
> Therefore, at > most liberal, 1% of 150 GB is 1.5 GB. > > The DB uses >
> approximately 600-800 bytes per file, if I remember correctly. > Thus clients
> >
> that have a lot of files (and Unix machines of 200,000 files > seem to be >
> common, if not small) it can add up fast. Additionally, the use > of copy
> pools >
> will add more to the DB. > > Jerry Lawson > jlawson AT thehartford DOT com >
> > >
> ______________________________ Forward Header >
> __________________________________ > > Subject: DB size > Author:
> INTERNET.OWNERAD at SNADGATE > Date: 1/22/98 > 11:44 AM > > Hi all, >
> I
> have recently experienced several problems with > the database running > out
> of
> space. While it true it is the first time I have > backed 10 Unix > clients
> succesfully, shouldn't 1-1 and half gb of database be > enough for > almost
> anything? Our estimate is 150 gb of raw data is being backed > up . > Ann
> Courchaine
|
