ADSM-L

Re: Client and AIX mirrored disks...

2001-10-23 20:38:42
Subject: Re: Client and AIX mirrored disks...
From: "Greatbanks, Stephen P" <stephen.greatbanks AT EDS DOT COM>
Date: Wed, 24 Oct 2001 10:35:46 +1000
Hi Miles,

MP>Hi Steve,

MP>interesting situation, have you considered, I'm sure you have, but:
MP>- do you really need a point in time, why not just try and back it up,
say 3 times, and on the last try just MP>back it up? ie. shared dynamic.
There should be no downtime at all. Do the files change that fast? Is the
shop MP>truly 24 x 7? There no time during the 24 hour day in which you can
just run a back up? What would happen if MP>you couldn't restore a file?

I've described the situation in more detail later in the email, but we can't
do the backup during the day.
If I can't restore a file on demand, my boss jumps on me from a great
height. Then his boss jumps on top of him, whilst he is still thumping me.
Then her boss jumps on her, to join in the melee and hit me with a length of
pipe... In short, not pretty... And this is before the client finds out...
;)

MP>This of course won't work if you absolutely can't have them changing and
must back up a good copy.

We really need to have all the services shut down on the boxes in question
to get a consistent state on the disk (database files are just one of the
issues). If we had the time, we'd dump the whole machine to tape whilst the
services are down. However, the window is too small for this, so the only
way to backup the consistent filesystem state is to break off the mirror,
restart the services, back up the "faked" filesystems and re-sync the
mirrors when the backup finishes.

MP>Things I might try:

MP>- run more than one backup per day. In several of my boxes I run a
'nightly' and a 'mid day' backup.
MP>- have you tested backing up this filesystem, to see how many files don't
get backed up because they are open MP>or changing?

I don't have the TSM software or a server yet, so I'm not really in the
position where I can judge the likely size of the daily incrementals. I
suspect that the number of new files on each machine is relatively small.
Similarly, I cannot say how many files would be open if a backup was
performed at a given time. The purpose of shutting down the services prior
to the backup is to stop new files transiting the machines, and ensure
databases and other services are shutdown.

MP>Forgive my skepticism, but it seems that things are more complicated than
they need to be or I'm lucky to have MP>a couple of hours to run the
backups. Even with this, I never worry about a couple of files not be backed
up - MP>granted it is usually some perpetual log file.

The situation is only made complicated by the situation I am inheriting. The
existing backup infrastructure has evolved to the point where the client
knows what it does, and it would probably be hard to convince them that they
need to do something else. The client has a definite requirement to have the
machines up 23x7, which is not negotiable. Because of the way the services
interact, the machines *all* have to be down in the same window.

I am firmly in your camp though! Least surprise is the best way to go. IF I
can get every machine backed up in this window (which clearly depends on the
network bandwidth at hand), then there is not an issue.
Outside the backup window, the services *must* be up and the machines *must*
be accessible.

You are lucky to have your few hours backup time though! For legal reasons,
we have to backup *everything*.

MP>What kind of RS/6000's are you setting up? SP? I might have some more
ideas.

A mix of machines in the B50/H50/S80 class.


Cheers,

Steve Greatbanks

<older stuff snipped>
<Prev in Thread] Current Thread [Next in Thread>