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
|
