So, the key is having the VOLHIST file saved, somewhere else, so it can be
reloaded to the rebuilt source server so he can find his DB backup !

Also sounds like doing a RECONCILE on a regular basis, is a good idea !
How often do you run RECONCILE ?

Thanks for enlightening me................

For a while there, we though it was FM ;-) !

Thanks also to "Dwight E. Cook" for your feedback.  These are currently test 
boxes we are playing with
so I plan to "destroy" the source server and try a recovery !





"Hooft, Jeroen" <Jeroen.Hooft AT ATOSORIGIN DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
07/19/2002 04:43 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Server-to-Server DB backup and recovery


Zoltan

We have a setup as you describe.

Your devconfig will have the TARGET SERVER as a device-class:
DEFINE DEVCLASS DEFAULT_SERVER_DEV DEVTYPE=SERVER MAXC.......
DEFINE SERVER LAMPS_VBB44_S1 COMMMETHOD=TCPIP HLADDRESS=......

The volhist will show your Database-backup pointing to the right
server/devclass:
* Location for volume LAMPS_VBB44_S1.DBB.026972100 is: 'LAMPS_VBB44_S1'
 2002/07/18 08:01:39  BACKUPFULL  2139  0 1 DEFAULT_SERVER_DEV
LAMPS_VBB44_S1.DBB.026972100

With this information you can restore your TSM-DB. Just a "dsmserv restore
db" will do the trick. I tested this once during a TSM course and it
worked
fine (as long as your target server is up). If you have DRM, you can also
send your prepare-plan to the TARGET SERVER. This prepare plan can then be
viewed by the html-interface on the TARGET SERVER.

About Reconcile Volume: That's a (little buggy) tool that corrects errors
in
the administration of the virtual volumes. If a "BA STG" using
server-to-server is interrupted, chances are high that the information on
the target server is inconsistent with the info on the source server.
Reconcile will make this info consistent.

Regards
Jeroen