Hi Steve,

interesting situation, have you considered, I'm sure you have, but:

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 back it up? ie. shared dynamic. There should be 
no downtime at all. Do the files change that fast? Is the shop 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 you couldn't restore a file?

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

Things I might try:

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

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

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

Miles


-------------------------------------------------------------------------------------------
----------------
Miles Purdy 
Miles Purdy 
System Manager
Farm Income Programs Directorate
Winnipeg, MB, CA
purdym AT fipd.gc DOT ca
ph: (204) 984-1602 fax: (204) 983-7557
-------------------------------------------------------------------------------------------
----------------
>>> stephen.greatbanks AT EDS DOT COM 22-Oct-01 6:54:43 PM >>>
>>> stephen.greatbanks AT EDS DOT COM 22-Oct-01 6:54:43 PM >>>
Miles,
   Thanks for your input. Just to make things a little clearer, the reason
why we jump
through all the hoops to break off a mirror with our current backup
procedure is to
allow clients to carry on using the disks whilst we back up the broken
mirror. Effectively
we are getting a snapshot of the disk at that point in time. In this way, we
have a minimum
of downtime (basically just the time needed for breaking the mirror copies
off).

MP>So if you are backing up filesystems there is no need to break the
mirroring

I realise this is true in general, but not in the situation where the
contents of the
disks are still changing. Breaking off the mirrors is the way you accomplish
this when
using sysback; I was wondering whether TSM provides anything similar. I
guess I am asking
whether there is any easy way to use the client to get a point-in-time
snapshot of a filesystem
and back that up. We really want to minimise the downtime for the client
machine.
It might prove to be the case that we can ship the data off the client to
the TSM server
fast enough that we can get all the data off in the time it used to take to
break the mirrors,
which would certainly help. I don't really have a feel for how much data we
are likely
to be changing on these servers in a day, or how much network bandwidth I
can steal to
do this just yet.
        I know that from the OS point of view, you just see the filesystem
within the LVM, and
that the multiple PP copies of the LP are handled transparently at a lower
level.

MP>However I think you want to back up filesystems, right?

Yep. That isn't the hard bit. The tricky bit is getting a snapshot whilst
keeping the
machine up...

I hope that is a little clearer!

Cheers,

Steve Greatbanks