I like everything except update vol access=unavail. I think they need to be
updated access=destroyed for the copy volumes to be used. I think if they
are unavailable TSM will ask for them to be loaded in the library within 60
minutes, blah, blah, blah.
Minor point.
This note is good enough to be renamed: Easy steps to accomplish DR using
another library, or somesuch. Dwight, I'll leave that to you!
Thanks,
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (240) 539-7175
Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Cook, Dwight E
Sent: Thursday, June 28, 2001 9:08 AM
To: [EMAIL PROTECTED]
Subject: Re: complete change of hardware and server-platform ?
Very interesting that things worked well !
(I expected since they were both Unix platforms, but wasn't going to bet the
farm)
Let's look at how TSM acts currently...
IF you have a copy pool (say local to the server) and a primary volume is
bad, and a client requests data from that volume, TSM will pull it from the
copy pool volume with no intervention at all. (last time I tested, this was
the case)
OK, an offsite copy pool... just a backup storage pool that you checkout the
volumes, take them offsite, and update the volume(s) with a status of
"offsite".
Now, we have at a remote location a similar atl with the same drives (can't
get around that) and a server on which the tsm db will restore to...
remember, tape volumes are bound to a device class
device classes have an associated library (when this applies)
YES, you may have tape volumes with absolutely no physical tape devices
defined to TSM (and no libraries)
So now at this remote location you bring up TSM and it may or may not find
what it thinks is the proper library...
And this library has had the copy pool volumes placed in it, and the library
itself just knows them as being in "insert mode"
Now the existing library(ies) within TSM... Who cares, delete the library
definition(s)
You (famous last words) now should be able to perform a "define library
blah" to create a real library definition to the physical library attached
to your current system, update your device class to reference this library
definition, define the existing drives to this library... you are now just
about ready to go !
Get a list of all the volumes in the copypool (q vol stg=blahcopypool)
for each of these volumes, issue a "checkin libvol" command to check
them in private
update the volumes to be readwrite (also update all other, not at
this site, volumes to be unavail)
Now if a client connects and attempts to pull data from the server, it
should automatically go to the copypool volumes.
I would not bother trying to recreate primary pool volumes (would take to
long if this is a real disaster situation)
Once client boxes were recovered, you could continue to move towards turning
this current environment into a full production backup server again OR
towards getting in new hardware for such...
(just my random thoughts.../ standard disclaimer :-| )
Dwight
-----Original Message-----
From: Rainer Wolf [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 28, 2001 4:35 AM
To: Dist Stor Manager
Cc: Cook, Dwight E; France, Don G (Pace)
Subject: complete change of hardware and server-platform ?
Dwight, we tested the aix-to-solaris-tsmdb-moving and it worked very fine-
so maybe we will use this as a regular 'quick-stand-by-server'
only for restore/retrieve purpose ( on data located on an
offsite-copy-server ) and *nothing else*
( no backup - no archive - no dbbackup ... ) and only just for
a short time in case of cpu-crash or in case of desaster.
It's not actual right now but my question is : if there is a need to change
the complete hardware (server platform , backup and archive libraries )
and assuming to have all data ( maybe temporarily for this action )
located on an offsite-copy-server ...
... can i thus move to the db on a new server-platform to get the access
to the db and to the offsite copy pools
then create new dev-classes pointing to the completely new
library-hardware - create a new primary STG on this
newlib-devclasses
and the all by a command like
restore stgpool OLDSTG copypool=offsite-copy-pool newstgpool=NEWSTG
Is this a usual way to change to new server-platforms/librarys/tapes ... ?
- it seems to be easy and straight forward -
Thanks in advance for any hints !
Rainer
----------------------------------------------------------------------------
---
the test we have done:
- on production server-a ( aix-tsm 4.1.3.0 ) doing not all but some of the
full-DBB into a flatfile located on an solaris-system
- on this solaris system server-b ( tsm4.1.3.0 ) with no tapes - only disk
and just the solaris server-package installed we load the db
exported
by the production server-a
( this solaris system has some km distance to the production-server)
- after shutting down the production-tsm-server on the aix system
-not to run both at once- we can start this solaris
'quick-stand-by-server' and have access
- to all the DB-entries
- to all data located on the offsite-copy-server ( server-c
)
The dsmserv.opt on the solaris-server was started with
DISABLESCHED-set-to-YES to avoid any automatic processes
and
EXPINTERVAL-set-to-0 to avoid any db Expiration processes -
additionally we delete all admin schedules on the server-b after
starting.
All primary volumes were changed access to detryoed.
So the only thing would then be to change the clients field
'TCPServeraddress' to the Ip-Address of the solaris-server.
Any client with data that has a copy on the 'offsite-copy-server'
can then immediately restore/retrieve data ( to the time of the
last flatfile-fullbackup - which maybe not the most actual one ).
end of test
----------------------------------------------------------------------------
-
__________________________________________________________
Rainer Wolf [EMAIL PROTECTED]
Tel: 0731-50-22482 Fax: 0731-50-22471
University of Ulm http://www.uni-ulm.de/urz
University Computing Center Albert-Einstein-Allee 11
AG Basissysteme 89069 Ulm
"Cook, Dwight E" wrote:
>
> Uhmmmmm I might just have to put me together a sun box & try this...
> Dwight
>
> -----Original Message-----
> From: France, Don G (Pace) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 13, 2001 4:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ADSM database backup to a file.
>
> There are specific-path references, and file-system-dependent things in
the
> TSM data base - which makes each server you install PLATFORM-SPECIFIC.
> So... the short answer is "no".
>
> -----Original Message-----
> From: Rainer Wolf [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 6:04 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ADSM database backup to a file.
>
> Hi ,
>
> Can I also create this 'flatfile' on a AIX system ( server-a )
> and restore the server on a Solaris system ( server-b ) ?
>
> I would like to use this solaris-adsm/tsm- server only for a quick restore
> of data previously backed up on server-a which uses copy-Storagepools
> via server-server on a third system- (server-c) and I don't want to use
> this solaris system for backup, because it only has disks and no library
> ... someone using such a configuration -or is this quite anomalous ?
>
> ( Szenario : server-a and Clients from this server-a
> (with 'client-data-copys-send-to-server-c' )
> are completely destroyed - then trying to restore latest
> active backups for the Clients as fast as possible on server-b using
> just the copy from server-c )
>
> Thanks in advance for any hints !
>
> Rainer
>
> "Cook, Dwight E" wrote:
> >
> > Sure, to move an adsm environment across town where I was a few states
> away
> > and didn't want to fly in for a half day...
> > define a device class of "FILE" and use it to backup the DB.
> > I did a full, then FTP'ed it over to a new machine that was to become
the
> > server... as soon as I got the full FTP'ed over I did a restore with
> > commit=no, then I locked out clients, did an incremental, FTP'ed that
one
> > over, did a restore with commit=yes and started up TSM. (while I was
> doing
> > that the DNS folks were doing there thing, then the clients just had to
> > bounce their schedulers...)
> > >>-DEFine DEVclass--device_class_name----DEVType--=--FILE------->
> >
> > .-MOUNTLimit--=--1----------------.
> > >-----+---------------------------------+----------------------->
> > '-MOUNTLimit--=--mountlimitvalue--'
> >
> > .-MAXCAPacity--=--4M----.
> > >-----+-----------------------+--------------------------------->
> > '-MAXCAPacity--=--size--'
> >
> > .-DIRectory--=--current_directory_name--.
> > >-----+---------------------------------------+----------------><
> > '-DIRectory--=--directory_name----------'
> >
> > so something like
> > def devc FLATFILE devt=file maxcap=4096M dir=/usr/adsm/flatfile
> > then just use it like
> > backup db t=f s=y dev=flatfile
> > and it will create a file in /usr/adsm/flatfile
> > to automatically get rid of the file in that directory, do like you
would
> > normally... del volhist t=dbb tod=-x and any db backup files in
> > /usr/adsm/flatfile older than "x" will be deleted...
> >
> > Dwight
> >
> > -----Original Message-----
> > From: Zosimo Noriega (ADNOC IS&T) [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 10, 2001 1:10 AM
> > To: [EMAIL PROTECTED]
> > Subject: ADSM database backup to a file.
> >
> > Hi everyone,
> > Can i backup my adsm db into a file because i usually backed up into
tapes
> > using the devclass.
> > if possible, please provide the commands or steps how to do it and how
to
> > restore it.
> >
> > thanks,
> > zosi
