Backup Central

Hi *,

I have a scenario. We had an onsite tape that got mangeled by a drive. The tape showed 75% usage initially. When we did the restore from offsite tapes, TSM reported that it completed successfully but there was still 15% left on the tape. The user went ahead and did a del vol discarddata=yes ( yes , I already hear the groans ) and looking through the logs see the following message :

14.07.2008 10:28:05 ANR1256W Volume C60255 contains files that could not be
restored. (SESSION: 130878)

What we would like to do is setup TSM on a test server and perform a mini-DR. That is, restore the database prior to the del and do a query content on the volume and check against the current database to see what data is missing.

My questions :

1) Why would TSM report the restore being successful when there was still data on it ? Could it be that running an audit vol would have fixed the volume against database and there was no data lost, just a volume messing up the TSM database pointers ?

2) We have the volumes that were used for the restore. Is there any way of restoring the data and then importing it back into the current environment ?


TSM Server :
TSM 5.3.6.3 ( being upgrading to TSM 5.4 shortly )
AIX5.3

Rich


Standard Life : 175 ans au coeur de nos vies
Standard Life: Part of our lives for 175 years

Rich,
My guess is that TSM expired some of the data that was on that volume,
so when it restored it only restored non-expired data.... I guess if you
have the database backup volume from when you would like to restore, you
can try and do a point in time restore, that should work on your mini DR
server.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Richard Mochnaczewski
Sent: Friday, July 18, 2008 7:19 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Deletion of onsite tape

Hi *,

I have a scenario. We had an onsite tape that got mangeled by a drive.
The tape showed 75% usage initially. When we did the restore from
offsite tapes, TSM reported that it completed successfully but there was
still 15% left on the tape. The user went ahead and did a del vol
discarddata=yes ( yes , I already hear the groans ) and looking through
the logs see the following message :

14.07.2008 10:28:05 ANR1256W Volume C60255 contains files that could
not be
restored. (SESSION: 130878)

What we would like to do is setup TSM on a test server and perform a
mini-DR. That is, restore the database prior to the del and do a query
content on the volume and check against the current database to see what
data is missing.

My questions :

1) Why would TSM report the restore being successful when there was
still data on it ? Could it be that running an audit vol would have
fixed the volume against database and there was no data lost, just a
volume messing up the TSM database pointers ?

2) We have the volumes that were used for the restore. Is there any way
of restoring the data and then importing it back into the current
environment ?


TSM Server :
TSM 5.3.6.3 ( being upgrading to TSM 5.4 shortly )
AIX5.3

Rich


Standard Life : 175 ans au coeur de nos vies Standard Life: Part of our
lives for 175 years

On Jul 18, 2008, at 10:18 AM, Richard Mochnaczewski wrote:

1) Why would TSM report the restore being successful when there was
still data on it ? Could it be that running an audit vol would have
fixed the volume against database and there was no data lost, just a
volume messing up the TSM database pointers ?

The Restore Volume command likes to return successful status even if
the whole volume could not be restored, just to test your
mettle. IBM Technote 1142533 corroborates this. I gather that
the user did not first run the command with Preview=Yes to uncover any
circumstances which could prevent full success. Or, did they try
several Move Data operations to see if the data could be gotten off
the tape, though with a struggle? (See "Tape problems handling" in
ADSM QuickFacts.) If Backup Stgpool regimens were not up to date,
then there will likely be some files on the volume which could not be
recovered, which is always possible, no matter how diligent we may try
to be; hence the importance of trying several copy operations first.

See the good TSM description of the ANR1256W message for further info.

my sympathies, Richard Sims