1. The database backup contains all nodes information so separate effort
is not required/necessary.
2. Volume history & device configuration. While no modification is
necessary to volume history, device configuration is quite likely to be
different on a different machine (even with the same library and tape
drives). You must modify device configuration to enable the database to
be restored.
Steffan
Rodrigo Cordovil Gazzaneo wrote:
>
> >Your details are a bit hazy, I hope this'll fix you up...
>
> I hope so !
>
> >You can get away with using the "original" data tapes by doing..
> >1) Steps to take on the original site...
> >run a FULL backupDB (BACKUPFULL in volhist)
> >collect the "original" data tapes
> >collect volhist and devcnfg and options files
> >(i.e. Volume History and Device Config files)
>
> Seems okay until now. Shouldn't I export the node so my client definitions
> could be imported on the remote site ? Just knowing volhist and devconfig
> is enough ?
>
> >2) Steps to take on the remote site....
> >put volhist and devcnfg and options on the remote system
> >put "original" tapes into the library/drive as needed
> >modify devcnfg "inventory"(if needed) and "define" lines to
> >reflect the configuration/inventory on the remote site.
>
> Modify ? Merge both the files ? Include the lines regarding one server on
> the other server's files ?
>
> >run restore db (pit restore - select date of you last backup)
>
> When I restore DB I overwrite the prior DB ? I don't want it, I want to add
> the definitions and the last backup data to this second server.
>
> >And you should be set for the most part. You can get similar results
> >with Export/Import server, DUMP/LOAD/AUDIT DB, DRM PREPARE(if you got it),
> >etc.
>
> I thought DRM covered ADSM Server crash. I am not worried with server
> crash, my problem is client crash, and transporting data in a way the
> server can be replicated elsewhere.
>
> It's like plain tape situation. You backup one box, move the tape to
> another site and write it down on other server. I want to make it through
> ADSM. That's why I thought of Export / Import.
>
> I don't want to overwrite the DB on the second site. I want to add data to
> it.
>
> >....THE END...
> >Now the solution to the tape-tape copy w/one drive is the following...
> >Setup migration from Tape(Old Tape)->Disk then from Disk->Tape(New T
>
> Like reclamation ... I will probably do this : Switch my reclamation area
> to my scratch pool area when making copies. But it is going to be slow ...
>
> Thanks,
>
> Rodrigo
>
> >ADSML
> >> -----Original Message-----
> >> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf
> >> Rodrigo Cordovil Gazzaneo
> >> Sent: Monday, August 30, 1999 7:16 PM
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> Subject: Exporting client nodes with limited resources
> >>
> >>
> >> Sorry, I forgot to add the subject before
> >>
> >> Hi ADSM / TSM gurus ,
> >>
> >> I need to implement a solution for a ADSM client crash (an
> >> Exchange Server). The problem is that the failover machine is
> >> located at another site, covered by another ADSM Server, and
> >> there isn't enough network band to run server to server
> >> communication, so I will need to Import / Export node
> >> (sometimes the lowest latency comm "media" available ).
> >>
> >> For export, I began running the preview and obviously a big
> >> mass of data was indicated for migration. The FILEDATA options
> >> reduced the size for only the necessary to recover the node,
> >> but I had yet another issue ...
> >>
> >> The first server (that contains the node data) has only one
> >> 3590-B11 drive installed, so I can't make tape to tape copy.
> >> Here is my question :
> >>
> >> Can I use the data tapes themselves for export ? I would be
> >> generating a tape containing the definitions for this client
> >> node and moving it together with the data tapes (I'll keep
> >> track of them with q volume and q content).
> >>
> >> If not, what other options do I have ?
> >>
> >> I have 2 stupid ideas :
> >>
> >> - move client's latest data from tape to disk (don't know
> >> if I have space for it ...) and export it.
> >>
> >> - during the weekend (probably the WHOLE weekend !) implement
> >> a server to server copy, what would be like passing a camel
> >> through a needle's hole ... might not work with data growth.
> >>
> >> Last option : buy another tape drive ...
> >>
> >> Can anyone help me ? Or am I in big trouble ?
> >>
> >> best regards,
> >> Rodrigo
> >>
|
