Richard Rhodes wrote:
Here are just some of the problems . . .
Rick,
Yes, we see the exposure, but aren't the ones managing the budget.
The completed DR architecture, when it's in place, will include on-
site and off-site copies of both data centers.
Thanks for your insights,
Keith Arbogast
Allen Rout wrote:
I'm having difficulty figuring out why this still feels not-answered
to you.
Allen,
That statement, i.e. ...my dilemma, was more an justification of my
original post than a commentary on the answers I had received. The
simplest version of my question would have been, What am I
Richard,
You asked thought provoking questions, but didn't answer mine.
Hi, again . . .
I guess I don't quite understand the situation.
You have a remote site with a server you want to backup to your TSM server.
Then, you ask why you would need VV's back at the remote site. What I
don't
Hi Keith,
virtual volumes used to be a big benefit while bridging big distances for
DR of backup data via fc/scsi was extremely expensive.
Today, I use the feature in our multi-site infrastucture to do my
additional db-snapshots to one (central) tsm-server. No tape is involved in
this part of
I'm curious. We've never relied on storing the TSM db backup to tape. We
backup to disk and rcp it to a 2nd site.
That's seems the simplest method. Anyone else do the same?
[EMAIL PROTECTED] 08/23/2007 9:00:35 AM
Richard,
You asked thought provoking questions, but didn't answer mine.
Hi,
Nicholas Cassimatis wrote:
With all of the features in TSM, there are a number of them that
don't work for specific situations. Simultaneous writes on backup/
migration, virtual volumes, NDMP backups, 3rd mirrors of DB and Log
volumes, adding documentation to your Prepare file - lots of features
Richard Rhodes wrote:
I guess I don't quite understand the situation.
Richard,
I'm sorry I haven't made our situation clearer. In the current phase
of the project we are building a TSM server in Bloomington to backup
local clients to disk which will be migrated to virtual volumes in
Richard,
I'm sorry I haven't made our situation clearer. In the current phase
of the project we are building a TSM server in Bloomington to backup
local clients to disk which will be migrated to virtual volumes in
Indianapolis. After migrating local clients to the new server, we
plan to
I said . . .
Let me see if I fully understand . . . .
Bloomington
TSM-a
local clients backup to disk pool
disk pool migrates to TSM-b/VV at Indianapolis
== primary tape pool is on TSM-b/VV at Indianapolis
vv server - contains primary pool from TSM-b
Indianapolis
TSM-b
On Thu, 23 Aug 2007 09:46:17 +1000, Stuart Lamble [EMAIL PROTECTED] said:
On 23/08/2007, at 7:29 AM, Nicholas Cassimatis wrote:
And a TSM DB Backup takes (at least) one volume, so with physical
cartridges, that's a whole tape. With VV's, you're only using the
actual
capacity of the backup,
On Thu, 23 Aug 2007 09:40:28 -0400, Keith Arbogast [EMAIL PROTECTED] said:
Knowing when they do and when they don't is the crux of my dilemma.
The virtual volume methodology is presented in IBM designed training
classes, Administrator's manuals, and in a very recent TSM Webcast
as if it is
Richard Rhodes said
Let me see if I understand...
Rick,
Yes, you understand very well. We will not have offsite copy pools
until there are 3584's at both data centers. It is a huge concern for
those who understand the implications.
All the best,
Keith
I am not understanding the crucial advantage(s) of using virtual
volumes to backup a data center to a remote site. Why not backup
nodes in a remote data center to a TSM server in a local data center?
Sure, do it, we backup many remote sites to our central datacenter.
The question is, what is
Richard,
You asked thought provoking questions, but didn't answer mine. What
is the compelling reason to use virtual volumes? Offsite copypools
and certain restorability of the TSM database are essential. Thank
you for spotlighting those points. However, I can do those without
virtual volumes.
Well I would say, then, the reason for VV is to eliminate the need for
real volumes: using virtual volumes on a remote TSM server eliminates
the need to move real tape volumes to the remote server in the event of
a disaster. Are they useful: that's a matter or opinion.
Somebody made the very
I think orinally, it was because intersite SCSI/FC was impossible or too
expensive, while IP was cheap. (Or maybe one TSM server had scsi tape
drives and a second did not.)
Virtual volumes are basically treating one TSM server as a client and
archiving to the other TSM server over IP.
On 23/08/2007, at 7:29 AM, Nicholas Cassimatis wrote:
And a TSM DB Backup takes (at least) one volume, so with physical
cartridges, that's a whole tape. With VV's, you're only using the
actual
capacity of the backup, which is more efficient on space.
At the cost of some reliability. What
17 matches
Mail list logo
