For a Library to do its own audit, then yes you want to take the drives
offline. However, you will need one drive online and empty when you want TSM
to synchronize its Library audit with the physical library audit.
Ray C
On Sep 26, 2010, at 10:23 AM, Huebner,Andy,FORT WORTH,IT wrote:
> We tak
Not sure if it is related, but we could not use LTO5 media in our LTO5 drives
until we updated to version 5.5.5.0.
Ray
On Oct 26, 2010, at 7:14 PM, Rodney Luk wrote:
> We replaced 4 LTO3 tape drives with new LTO5 drives in our 3584 library. The
> library has 4 LTO3 and 4 LTO5 tape drives now. A
I have a few Solaris 9 5.5.3 clients and some Linux 5.5.1 clients working with
a 6.3.0 server. their just not supported.
Be aware that NODE REPLICATION of a 6.3.0 Client to a 6.3.0 Server will
sometimes fail because of wanting data from your offsite DR tapes. IBM is
supposedly working on a fix
I had a similar problem, tape changing to unavailable, a few months back. In
my case, it was a problem with how the tape was identified. The Library, an
XLS, had it as "123456". TMS has "123456" as a scratch tape and also had tape
"123456L4" as the tape I wanted. I had to check "123456" out
Tim,
I have been fighting this problem for several months now. IBM is looking at
it, but haven't come up with a solution.
Ray
On May 2, 2012, at 10:39 AM, Tim Brown wrote:
> Error during nodegroup replication, but I cant see any errors on the target
> server
>
>
>
>
he same situation, but do not
realize it.
BEWARE Deduplication
Ray Carlson
rning.
>>
>> I was wondering if you could tell us a bit more about this TSM server.
>> Is it a converted 5.5 server? At which 6.x level did you start using
>> TSM version 6 for this server, 6.1, 6.2 or 6.3? Do the errors occur
>> with any particular kind of data
Can anyone tell me what is in PMR 62476,033,000? Apparently IBM believes that
someone following the steps in that PMR caused the lose.
Thanks,
Ray
On May 30, 2012, at 7:39 AM, Ray Carlson wrote:
> It was a brand new 2008 Server with a 6.3.0 install, which has been upgraded
> to 6
You can try audit of the various volumes.
Also, if you are using Deduplication, there is a know problem of TSM losing the
source data on versions prior to 6.3.2.01.
Ray
On Aug 27, 2012, at 9:56 AM, Dan Olson wrote:
> Hi all,
>
> After a mass restore attempt pulling from 800+ volumes I've got a
Is anyone else having the problem of TSM saying that it is missing the source
data for Deduplicated data? This is causing some of our "Generate Backupset"
and some of our restore jobs to fail. Unfortunately, unless you run some job
that actually attempts to use or restore from the missing data
essage-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ray
> Carlson
> Sent: Wednesday, August 29, 2012 10:05 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [ADSM-L] Missing source data for Deduplication in 6.3.x
>
> Is anyone else having the problem
Nothing new. I'm having various "Generate backupset" jobs fail. Sometime my
expire will fail, and even some of my reclamations. IBM is attributing it all
to the same missing data, and say that all my problem fall under IC85825.
Supposedly, TSM 6.3.2.1 was supposed to fix this problem, and ke
FYI - We had all the normal settings and still lost our source dedupe data
while running 6.3.0 to 6.3.1, and no TSM was not smart enough to figure out it
was gone and back up a fresh copy. We are currently at 6.3.2.7. It was one of
the 6.3.2.x updates, released around 10/1/2012, that finally f
Out of curiosity, had the data been DeDuped when it was on the Disk, before it
was migrated to tape, and then moved back to disk?
We saw many problems with data corruption and damaged files when this was done
with a TSM server prior to 6.3.3.
Ray
On Jun 19, 2013, at 11:20 AM, Andrew Raibeck wro
14 matches
Mail list logo