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
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
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
-
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 of TSM saying that it is missing the source
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,
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.3.1.1 because
, 6.2 or 6.3? Do the errors occur
with any particular kind of data? Is it 'old' data, or fresh data
recently written to TSM? Are you able to restore the files from
copypool if this error occurs?
On 29 mei 2012, at 20:46, Ray Carlson wrote:
Or as IBM called it, Orphaned deduplicate
Deduplication
Ray Carlson
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
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 of TMS
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
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
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
13 matches
Mail list logo
