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 >
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
|
