Dear all,
reading the discussion about TSM 7.1 - should I upgrade or not seems to give
me the answer for the question which version should I take for a completely new
installation: for a new installation take TSM 7.1.
but -- maybe some remarks are not given, what if so? therefore I do ask:
I would go with 7.1, I have it on 4 Windows 2008 R2 servers without any
problems. The DB improvements are great, and the use of the Ops Manager has
already provided to be very useful. :)
All the best with the upgrade.
-Original Message-
From: ADSM: Dist Stor Manager
Hi roger,
Thanks for the reply, i don't have another drive (the other is HS)
I'am trying to do the fix=no and come to the result.
Regards, Mickael
+--
|This was sent by bobpatrick808...@yahoo.fr via Backup Central.
|Forward
For us, we're growing quickly enough that it's always easier to
upgrade/install the newest version today than it is tomorrow. If you think
your site will be significantly bigger in the next couple years, I would go
with v7.1 and save yourself the upgrade hassle.
We went with v6.1 on our new TSM
Can any one share the syntax for preschedule / postschedule cmds for linux
Thanks,
Tim Brown
Supervisor Computer Operations
Central Hudson Gas Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.commailto:tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax:
Each option takes a path to an executable, which could be compiled code,
Perl, shell, etc. It runs with the same environment as the scheduler so you
can access all the environment variables that the scheduler process itself
sees.
On Fri, Jan 31, 2014 at 06:46:52PM +, Tim Brown wrote:
Can any
The TSM books show that you can have multiple policysets per domain.
I don't mean just the active vs inactive, but you can have multiple policysets
like NORMAL, OFFHOUR, WEEKEND, within one domain, and switch them back and
forth.
I've never done that, or had a reason to. Seems inordinately
We have the minimal STANDARD (writable) and ACTIVE policysets for our
domains. Domains are assigned by billable unit (lab, institute, cost
center, etc.).
I've never come up with a purpose for multiple policysets, so I also would
be curious to know if one exists.
On Fri, Jan 31, 2014 at
Hi Wanda,
It's an interesting question, and I hope you get many interesting answers. We
only have one policyset per domain, partly from a lack of understandng of
what's possible, and the other part from a lack of imagination. We try not to
create a smorgasbord of TSM backup types and cycles.
When it comes to backups, simplicity is good. I try not to design anything
that I cannot document succinctly.
On Fri, Jan 31, 2014 at 04:35:12PM -0500, Keith Arbogast wrote:
Hi Wanda,
It's an interesting question, and I hope you get many interesting answers. We
only have one policyset per
Hi Wanda,
Scenario 1: I am making multiple changes to my policy set. However, in case
I mess something up, I'll first make a backup copy (of the inactive policy
set) which will let me throw away my changes if I mess something up.
copy policyset standard standard standard_2014-01-31
Scenario
Ah, that's a great idea. I've always captured the old settings to a file
before making changes, but this makes it much faster and more reliable to
recover.
On Fri, Jan 31, 2014 at 04:48:25PM -0500, Andrew Raibeck wrote:
Hi Wanda,
Scenario 1: I am making multiple changes to my policy set.
Only come across a need once in 16-years of working with *SM. This customer
wanted to do periodic full backups. So I had a policy set with set to the
default MODE=MODIFIED and another set to MODE=ABSOLUTE. They would activate
the full policy set when they wanted to do the complete refresh. And
I’ve never been at a site that used more than one policy set.
But if I had been at either of two sites that had to implement infinite “legal
holds” when that order actually came, I’d have used a new policy set to do
exactly that. That’s the only situation in which I’d use that option.
Nick
I have 2 policysets in each domain. They are identical except for the
copygroup destination
parameter.
This is the design I came up with to implement 6.1 with dedup. Backups come
into an ingest
pool on hi-speed disk (bkp_1a) while policyset set_a is active. At 5 am, a
schedule/script
Brian
TSM will only move a backup to the next pool when the pools are disk and
sequential, not when sequential and sequential, so I suggest adding a
dummy sequential pool with no volumes assigned in the middle.
disk - dummy - tape
I've come across this when using an intermediate file pool. It
16 matches
Mail list logo
