Windows 2003 SQL Server w/TDP 5.5.1.0
TSM Server 5.4.3.2
Can someone shed some light on what would be the correct copygroup settings for
legacy TDP backups of SQLServer databases assuming a schedule of weekly fulls
and daily (some more frequent) where we would want to be able to recover to any
ALMS is required if you use the new high density frames. These can provide
three times the tape density as the normal frames. ALMS is needed to
automatically manage which tapes are located in which slots, keeping the
most frequently used tapes in the most readily accessible physical
slots.
Hi TSM-ers!
I have two nodes which I cannot delete. When I issue a DELETE FILESPACE
* for one of these node, I see the following errors in the log:
ANR0984I Process 59041 for DELETE FILESPACE started in the BACKGROUND at
15:30:40.
ANR0800I DELETE FILESPACE * for node KL10143J started as process
Or use the latest firmware for the TS3500. If you want/need to go to a
version 8.x firmware you have to have ALMS. Version 7.x is the latest for
without ALSM. With the Version 8.x you get the builtin CIMOM agent if you
want to use the TPC to monitor/report on your TS3500(s).
Bill Boyer
Living
Bill
Can you tell us more about the CIMOM agent.
Thanks len
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Bill
Boyer
Sent: Tuesday, August 18, 2009 9:38 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] ALMS benefit to shared-library
On 18/08, Loon, EJ van - SPLXM wrote:
Hi TSM-ers!
I have two nodes which I cannot delete. When I issue a DELETE FILESPACE
* for one of these node, I see the following errors in the log:
ANR0984I Process 59041 for DELETE FILESPACE started in the BACKGROUND at
15:30:40.
ANR0800I DELETE
I wanted to get the collective opinion of the list on a problem we are
facing with synchronous write.
In our environment we use TSM library sharing and we typically over-commit
the tape drives in our library, relying on the client sessions waiting in
a MediaW state until a drive becomes
The retention policy for backups to IBM Tivoli Storage Manager should be
enforced by time period. Take a look at the Backing up Microsoft SQL
Server with IBM Tivoli Storage Manager redbook -
http://www.redbooks.ibm.com/abstracts/SG246148.html
You may need to define the copy group with the
History.have a client backing up with a 30-day retention policy
(vere=nolimit rete=30) and last week they came as requested that the
retention be change to No Limit across the board. Keep everything. Lawyers
involved. Now they feel that the resource requirements for doing that for an
indefinite
How much data are you talking about ?
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Bill
Boyer
Sent: Tuesday, August 18, 2009 2:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Need some how-to assistance please
History.have a client backing up with
One way would be to move the nodes to another domain with unlimited
retention, and then rename them node_archive. You would then need to
recreate then nodes in the current domain for backups to continue.
This will cause the data to be backed up again for all nodes, but at
least it will only be
Current primary storagepool occupancy is 8.9TB.
32 nodes in the domain with 8 of them being TDP SQL agent nodenames.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Ochs, Duane
Sent: Tuesday, August 18, 2009 3:32 PM
To: ADSM-L@VM.MARIST.EDU
You only had a 30 day retention policy... If the data was deleted you could
only go back 30 days.
This doesn't seem to difficult an issue. For that much data and that many nodes
just run an archive on each system.
If they must have the data that is already saved... I'd say best bet is
backups
The want the OLDEST backup versions, not the most recent. I guess I could do
an export node specifying a fromdate/time of when the TSM server was created
and the todate/time of 30-days ago.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Ochs,
Hi all,
This situation has never happened to me before so I'm a little unsure of
the steps and order to fix it. Running AIX 5.3 with a TSM instance at
5.5.1. LTO drives are zoned in through a switch to the TSM server, 2
drives to each fibre card. Support for the IBM drives was not renewed
with
The Win2K 32bit 6.1.0 client config wizard on 3 clean installs (machines
that have never had a client before) did not put PASSWORDACCESS GENERATE
into the newly created dsm.opt file.
Doesn't seem to be in the fix list for 6.1.0.2.
Anybody else run into this? Got a workaround other than
It is undocumented, but when replacing fibre-connected LTO drives you
must halt and restart the TSM server in order for it to correctly sense
the new serial numbers. Nothing will work on the new replaced drive
until you bounce the server. A Sun/STK engineer told me about this one.
I know this is
17 matches
Mail list logo
