Stephen,

It depends on what it is you are backing up.

As you know TSM only normally does incrementals, so if your data is a number of 
small files,  the time taken to traverse your directory tree is reasonable and 
only a reasonable  subset need to be backed up, then the TSM backup process may 
be fast enough for your needs, replacing steps (ii) to (vii)

If any of those conditions are not met, so that the TSM backup time becomes too 
large to bear, then TSM can replace just step (vi) to good effect. 

Regards

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia 

>>> "Greatbanks, Stephen P" <stephen.greatbanks AT EDS DOT COM> 23/10/2001 
>>> 10:11:44 >>>
Zlatko,
        Thanks for the information. I do realise that the AIX mirroring is
totally transparent from the user (and TSM) point of view. That is not
really my question though. The current backup procedure is (roughly)

(i)     Stop all clients using the filesystems
(ii)    Do a mksysb
(iii)   Break off one of the mirror copies
(iv)    Re-mount the broken mirror copies as phantoms that we backup
(v)     Allow clients to access disks
(vi)    Backup the broken mirrors
(vii)   Re-sync the mirrors

The reason we do this is to minimise the downtime for the machine
and to allow a backup to continue whilst clients can use the filesystems.
Effectively we are taking a point-in-time snapshot of the filesystems.
I guess that what I was asking is whether there is anything in the TSM
client (in terms of smarts) to allow it to do something similar.
Am I right in thinking that the client will rely on the filesystem not
changing underneath it?


If we cannot, then we will just have to wear the downtime.

Thanks for that,

Steve Greatbanks

ps - You are of course right about varyon/varyoff working at the VG, rather
than the LV level.