lt;[EMAIL PROTECTED]>
Sent: Wednesday, February 27, 2002 11:26 AM
Subject: Re: Idea for a TSM feature
> > -Original Message-
> > From: James Thompson [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 27, 2002 12:51 PM
> > To: [EMAIL PROTECTED]
> > Subj
OK,
I understand the requirement, but I doubt many people would use it because
it essentially requires a duplicate copy of your used disk space on each
client that is involved. Run this select. It will give you an answer in MB
of the space required to do what you are asking. You can add where o
Right now, AFAIK, there's no way to influence how Tivoli makes decisions
about which files to remove from the migrated file cache -- I think adding
ways to influence those decisions would probably be better than to add a
'special' disk storage pool type.
The ability to say "Okay, if there's a sho
> -Original Message-
> From: James Thompson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 27, 2002 12:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Idea for a TSM feature
...
> This would not break anything with TSM. It is really simple
> to get in a state
Cascanette [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, February 27, 2002 9:53 AM
To: [EMAIL PROTECTED]
Subject:Re: Idea for a TSM feature
However what would happen if you were on a DR and you needed to perform a
Point in Time restore. Keeping only the active files would not necessary be
the
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: Idea for a TSM feature
With current/future tape technology the most important thing for
performance
is to be able to stream data to and from the
>The feature that I would like to see is the ability to create a special disk
> storage pool, that would only migrate inactive versions of backup objects to
> the next storage pool. This would keep all the active versions on disk
> storage.
>
> I'm sure everyone has certain nodes(systems) that ar
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: Idea for a TSM feature
With current/future tape technology the most important thing for
performance
is to be able to stream data to and from the
, February 27, 2002 9:49 AM
To: [EMAIL PROTECTED]
Subject:Re: Idea for a TSM feature
Yes, but one thing to keep in mind is that most people would also want to
keep the "Last Version" also, even if it is inactive. The reason is that if
someone deletes a file, the next day it would b
ailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 27, 2002 12:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Idea for a TSM feature
>So you are saying to separate the active/inactive versions from the =
tapes?
That would be the net effect for files that were sent to this special =
disk
storage pool
As long as it is a onesy/twosy type operation, going to tape does not incur
a large performance penalty, so restores of the 'Last Version' would not in
my opinion, as it relates to this feature, be that critical.
This feature would be more geared toward operations that typically require a
lot of
: [EMAIL PROTECTED]
Subject: Re: Idea for a TSM feature
>So you are saying to separate the active/inactive versions from the tapes?
That would be the net effect for files that were sent to this special disk
storage pool. Only inactive versions would be on the next storage pools.
However t
With current/future tape technology the most important thing for performance
is to be able to stream data to and from the tape drive. Certain TSM
operations stream data to tape really well (migration). Due to the
granularity of TSM (file level) retreiving data from tape is normally not
streamed.
al
Storage Administrator
Freightliner, LLC
(503) 745-6850 phone/vmail
-Original Message-
From: Doug Thorneycroft [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 27, 2002 9:19 AM
To: [EMAIL PROTECTED]
Subject: Re: Idea for a TSM feature
Yes,
I posed a similar question a month or so ago,
My i
Yes,
I posed a similar question a month or so ago,
My idea was to add a switch to migration that
would migrate only inactive files.
This way you could restore an entire server
using multiple sessions, without needing to
use collocation or worry about tape contention.
-Original Message-
I am sure others will reply, but why not use large cached primary disk
pools?
If you need to, define a separate pool for each "important" client, large
enough to hold a "full" backup. That way, all the active files will usually
be in the pool. (Exceptions will break this, eg a big file that chang
>So you are saying to separate the active/inactive versions from the tapes?
That would be the net effect for files that were sent to this special disk
storage pool. Only inactive versions would be on the next storage pools.
However tape backup storage pools would still have both active/inactiv
So you are saying to separate the active/inactive versions from the tapes?
-Original Message-
From: James Thompson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 27, 2002 11:44 AM
To: [EMAIL PROTECTED]
Subject: Idea for a TSM feature
Thought I would throw an idea I had for a TSM f
18 matches
Mail list logo
