File unavailable mystery

[kimon]

I am running the command "dsmc restore -se=internal -latest <file>".



I get back: ANS4035W File '<file>' currently unavailable on server.



I am backing up to a library, but no volumes have ever been removed from the library. The status of all the volumes is either empty, filling of full.



It is true that the file was deleted on the client, but the copy group is configured to keep one deleted version forever. All other files in the same directory (there are over 30), which were also deleted are still available.



On my server I know that <file> exists, because:



select * from backups where node_name=<node> and ll_name=<file> and ll_name=<dir> and filespace_name=<filespace>



NODE_NAME: <node>

FILESPACE_NAME: <filenpace>

FILESPACE_ID: 1

STATE: INACTIVE_VERSION

TYPE: FILE

HL_NAME: <dir>

LL_NAME: <file>

OBJECT_ID: 12223

BACKUP_DATE: 2002-11-23 06:22:30.000000

DEACTIVATE_DATE: 2002-11-23 06:41:47.000000

OWNER: root

CLASS_NAME: DEFAULT



How could it be unavaible?

 

[kimon]

Another piece of info, by looking at the occupancy table, I have found that this file is stored in two segments becase SETGMENTS: 1/2 is listed.



However, the database does not list the second segment:



select * from contents where SEGMENT!='1/1' and NODE_NAME=<node>



This returns only the segment 1/2. Should it not also return to me segment 2/2?



Where has the other half of my file gone?



Thanks for any ideas,



Kimon

 

[LED888]

Kimon,



When doing the restore did you also use the parameter -ina ?

-ina will show the inactive copy.

If the file have been deleted from the workstation, the status of the most recent file have been changed from active to inactive.





"It is true that the file was deleted on the client, but the copy group is configured to keep one deleted version forever. All other files in the same directory (there are over 30), which were also deleted are still available."



This will depend on the setting in your copy group.

From the TSM server issue: q stg f=d

There is a parameter called "Retain Only Version." This parameter controls how long to keep the inactive file. The default, I think, is 60. Once the file becomes an inactive file, 60 days from that day the file will be "deleted."



If you want to keep the file forever, just restore the file and then archive the file. Archiving is design for long term storage.





Give this a try and see if this will show the file that you want to restore

dsmc restore -se=internal -pick -ina <file>



The pick option creates a list of backup versions, images, or archive copies that match the file specification you enter. From the list, you can select the versions to process.

Only active backups are considered unless you also use either the inactive or the latest option.



Sias

 

[kimon]

I have found that the reason the file is unavailable is because it is damaged. My clue was watching the console screen as the restore took place and I saw:



processing file space /store 1 for file /backup/data/ 39.cpio stored as Backup

- data integrity error detected.



Then, doing a "query content <node> damaged=yes" the file was listed.



However, this still leaves the question why are so many files "damaged" (looks to be about 10%), and what can I do about it?



If I can determine right after the backup that the file is damaged, I could back up the file again. But if one could do that, would not tivoli tell me that the backup failed or retry itself? :evil:



I'm using a R/W optical library. Maybe I have a driver problem...



Kimon