Restoring From CopyPool to a different Primary STGPool

[rdavila]

Hi,

The help for RESTORE VOLUME states theres a parameter called NEWstgpool

NEWstgpool

     Specifies the name of the new storage pool to which to restore the
     files. This parameter is optional. If you do not specify this
     parameter, files are restored to the original primary storage pool.

My primary disk pool is called BACKUPPOOL and it has a next storage pool called TAPEPOOL of type LTO.

I need to restore volume L00075 that belongs to the TAPEPOOL and I have the list of CopyPool tapes I need for the restore.
Given that my Primary DISK Pool is called BACKUPPOOL, if I do the following:

RESTORE VOLUME L00075 NEWSTGPOOL=BACKUPPOOL

Will that restore the files into the BACKUPPOOL so I can access them faster than if I had restored them into the TAPEPOOL (to which the original L00075 volume belongs to).

Thanks

 

[heada]

I've never tried it that way, but it should work and yes, any client restores that would need that data would pull it from the disk pool and not the tape pool (assuming you mark the failed tape as destroyed)

-Aaron

 

[rdavila]

Thanks,

As a matter of fact I did an AUDIT VOLUME L00075 FIX=no and the actlog showed 0 errors on the tape. The problem is need to restore a lot of files that reside on that tape and it's not working.

When I start the restore the directories are restored right away, but then the BA client just stays there waiting and nothing happens. I checked the actlog in the console and TSM is not even mounting the volume!

Yet when I did the AUDIT VOLUME, TSM mounted the volume immediately and read it without problems. I've tried in different computers (changing the node name in dsm.opt) and exactly the same thing happens.

That is why I thought of the idea of marking the tape as destroyed and restoring the volume from the DR tapes.

You think it is a good idea?
Sorry I got off topic.

 

[heada]

My question would be why is TSM not mounting the volume for a restore but will for an audit? Is it marked available (even read-only would allow a client restore).

If the audit mounts the tape and finds no errors, the client should be able to request data from the tape and TSM should be able to mount it.

-Aaron

 

[rdavila]

To be honest, that's exactly the question I've been asking myself for the last 3 days.
The directories are been restored and I can see in the actlog when TSM mounts the "file based" volumes of the stg pool that holds Directory Objects (the one used with the DIRMC directive).

I can restore anything from other nodes w/o problems. I checked the node status and is not locked either.

Q SES shows the session but bytes received/sent simply don't increase after the initial restoration of Directories.

Yesterday I started the restore at about 7:00AM and left it running for more than 3 hours and nothing. That's when I gave up.

I hope RESTORE VOLUME to the DISK based stg pool solves the problem and then I'll get rid of the offending tape.

Thanks

 

[heada]

The directory entries are created from the TSM database and not from a storage pool so that explains why those are created quickly. What does the activity log show for this client restore?

-Aaron

 

[rdavila]

On UNIX clients directory entries are stored in the TSM database, but on Windows clients directory entries are stored in a storage pool. (TSM Implementation Guide chapter 6 page 247)

Tomorrow I'll try another restore and I'll post the part of the actlog related to it. Also I'll post whatever I can find in the client's error logs.

Thanks for your help!

 

[rdavila]

Hi,

This the result from the actlog. The node's name is PSTSTORAGE

11/10/2007 11:23:52  ANR0406I Session 2253 started for node PSTSTORAGE (WinNT) (Tcp/Ip 172.23.1.7(4053)). (SESSION: 2253)
11/10/2007 11:24:07  ANR8340I FILE volume /tsmdata/tsmserver/DirBackupPool/00009C8E.BFS mounted. (SESSION: 2253)
11/10/2007 11:24:07  ANR0510I Session 2253 opened input volume /tsmdata/tsmserver/DirBackupPool/00009C8E.BFS. (SESSION: 2253)
11/10/2007 11:24:07  ANR0514I Session 2253 closed volume /tsmdata/tsmserver/DirBackupPool/00009C8E.BFS. (SESSION: 2253)
11/10/2007 11:24:07  ANR8340I FILE volume /tsmdata/tsmserver/DirBackupPool/00009DA6.BFS mounted. (SESSION: 2253)
11/10/2007 11:24:07  ANR0510I Session 2253 opened input volume /tsmdata/tsmserver/DirBackupPool/00009DA6.BFS. (SESSION: 2253)
11/10/2007 11:24:08  ANR0514I Session 2253 closed volume /tsmdata/tsmserver/DirBackupPool/00009DA6.BFS. (SESSION: 2253)
11/10/2007 11:24:09  ANR0406I Session 2254 started for node PSTSTORAGE (WinNT) (Tcp/Ip 172.23.1.7(4047)). (SESSION: 2254)
11/10/2007 11:24:10  ANR0403I Session 2254 ended for node PSTSTORAGE (WinNT). (SESSION: 2254)

As you can see a first session is started and the disk-based volumes containing the Directory Entries are mounted.
All the Directory Entries are restored in seconds.
Then a second session is started and it ends almost immediately without mounting the L00075 volume which contains the files.

After that, this is the result of QUERY MOUNT

tsm: TSMSERVER1>q mou
ANR8376I Mount point reserved in device class LTOCLASS1, status: RESERVED.
ANR8334I         1 matches found.

I have the required DR tapes onsite to restore the L00075 volume. But I'm going to try something else first.
MOVE DATA L00075 STGPOOL=BACKUPPOOL RECONSTRUCT=No Wait=No

I hope that works better that doing a RESTORE VOLUME. What do you think?

 

[heada]

The move data should mount the primary volume and move the data into the other pool. It should work but it shouldn't be any faster or slower than a pure tape restore. I can't explain why the tape didn't mount for the restore. Has the data expired? I've seen where a restore will run and recreate the directories but no data is restored since the files had expired.

-Aaron

 

[rdavila]

Well, I finally restored the data.
I logged on to a W2003 server and edited the dsm.opt to make it appear as the node PSTSTORAGE. (which is exactly what I do on my workstation)

This time it worked perfectly. I doubt it has anything to do with the OS since I can restore files on my workstation that were backed up on W2K and W2003 servers.

Now for the confusing part. I did the MOVE DATA and it completed without problems. When I did the restore, it still mounted the L00075 and did the restore from there instead of the BACKUPOOL. I suppoese it is because I didn't mark the L00075 as DESTROYED. I tried again from two different workstations and the original problem happened again (it wouldn't mount the L00075 volume).

In short, when I try to restore from my WinXP workstations TSM will not mount the volume. If I restore from one of my W2003 servers it works perfectly. The data was originally backed up in a W2K server.

 

[JohanW]

I wouldn't call it working perfectly if L00075 was moved back to disk, not returned to scratch and used for the subsequent restore instead of the diskpool that should have had the data, while L00075 should no longer have had it.

But if it works, .. back up the data again and BURN L00075. Then bury it with a stake through its heart. At a crossroads. After *really* demolishing it.

 

[rdavila]

LOL

Believe me, that's very close to what I had in mind.
For now I updated L00075 to READONLY os it doesn't get used for writing again.

I'll work on a SELECT to get a list of all FILESPACES contained on L00075 and restore them to a temporary server. Then I'll back them up again and mark the tape as DESTROYED. I have about 10 spare tapes so I can trash this one.

I just want to be really, really sure all the data is in the disk pool before I do it.

Thank you so much for all your help heada and JohanW.
I hope in the future I can be of help to others in the forum as well.

 

[JohanW]

select node_name, filespace_name from contents where volume_name='L00075' group by node_name, filespace_name

 

[JohanW]

Do take care to make selective full backups. Not incrementals.

 

[rdavila]

I did have the selective full in mind.

Thanks for the select.