Recently we had to move an environment from Chicago to Naperville.
The move was also an equipment upgrade so all that would be moved was the
tsm image (and then later the tapes & atl)
Anyway we toyed with shutting down tsm and then ftp'ing the db & log files
over to the new box but that wasn't an option due to time... what we ended
up doing was using TSM's "backup db" to a disk file, we then ftp'ed that
file to the other server, did a "restore db .... commit=no" (we had tested
and adjusted our time schedule where the 1'st restore completed just before
when we wanted to take down the prod environment to move) So then we
disabled client sessions and a little bit of other misc activity, took an
incremental tsm db backup, ftp'ed that over, and performed a "reatore db
.... commit=yes".
>From actual outage on the box in Chicago until we were up and running in
Naperville was less time than it took DSN services to update the node's
entry with its new IP address.
So here, any sort of voodoo remote copy (if it would have been any faster)
would have just had us sitting with with nothing to do even longer than we
already were, waiting on everything else... (Oh, that was a 24 GB tsm DB)
AND this worked, correctly, the first time !
What did I set out to say here ? ? ? My thoughts and experiences have shown
me that the options that TSM provides for the recovery of its own
environment work well, are easy to use, flexible, and simple/straight
forward.
just thinking out loud too !
Dwight
-----Original Message-----
From: Richard L. Rhodes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 2:20 AM
To: [EMAIL PROTECTED]
Subject: TSM cold backups
As our TSM Database grows, were hitting the inevitable question
of how big to let the db grow vs purchasing and bringing up another
TSM instance. We're not there yet, but we can see this on the
horizon.
The issues isn't TSM performance, but db backup/recovery. This got
me thinking (always a dangerous thing exercise), does anyone use cold
backups for their TSM db?
In other words, does anyone shutdown their TSM instance, make some
kind of backup of the TSM db and related files, and then bring
the db back up? Another method would be to use EMC BCVs or IBM Shark
FlashCopy to enable a very short shutdown-split-restart-backup
system, like we use for critical databases?
My thought is that it would be much faster to backup and restore the
actual DB files than use TSM's normal backup.
Better yet, is there any way to just copy the TSM db while it is
live? SOmething like Oracle's Hot backup?
Just thinking out loud . . . .
Rick
