How to measure the age of restored data

[chzink]

Hello,

we want to determinate the average age of our restored data in our TSM backup environment.
What is the best way to achieve this goal ?

Pre-Thanks for hints.

Regards,

Christoph

 

[nutznboltz]

What exactly to you mean by "age of our restored data"? Using the word "restored" that way confuses me. Do you mean the data was backed up and then restored and you want to know how long ago?

 

[chzink]

Hello,

thank you for the reply.

Yes, of course. The restores are made by others than the backup admins, so we want to know what they restore and how old it is (e.g. 1 day or 10 days).
I looked at the RESTORES SQL Table in the TSM db but didn't find any information
of the restores.

For Oracle db's we use rman, this tool doesn't reply anything (about restores) to the TSM db.

Regards,

Christoph

 

[MrOdysseus]

Hello,
It would all depend on your policy set, and how often you run the backups.

If you run

Q COPY

It can give you an idea of the policy's in place. If you have multiple policy, you would need to determine which one your server is using.

*VERSIONS DATA EXISTS* - This value specifies the maximum
number of versions of a file which may be retained. If this is exceeded by additional backups or imports, then the next expiration run on the server will remove the oldest versions until there are only this many left. **This may be "NOLIMIT" or a whole number. *RETAIN EXTRA VERSIONS* - This value specifies the maximum number of days to retain an inactive copy when there is an active copy in the database. **This may be "NOLIMIT" or a whole number. *RETAIN ONLY VERSION* - This value specifies the maximum number of days to retain the only inactive version of a file once there are no active versions. **This may be "NOLIMIT" or a while number. **This does not affect active copies which are always retained. *VERSIONS DATA DELETED* - This is the maximum number of inactive versions of a file to retain once the file no longer has an active version. *DESTINATION* - This specifies the storage pool to which newly backed up data will go if it is bound to this management class during backup. **Rebound data will not move to a new pool automatically. **Data may be moved from this pool through migration or MOVE DATA commands.http://adsm.org/lists/html/ADSM-L/2002-02/msg00471.html

Hope that helps,
-Ody

 

[rowl]

I am curious if there is a way to do this as well. If I understand the question, it is the same issue I have been asked to investigate. User requests mydoc.doc to be restored. When did we back that up? Yesterday? three days ago? six months ago? The goal in my case was to determine how long backups should remain on a faster tier of storage before being migrated to another storage pool where restores may take longer. In another case I was asked to gather this information to guide retention policies (As a manager put it, if everything we restore was backed up in the last week, why do we have 90 day retention?).