TSM Sharepoint expiration

[spiffy]

hey all,

hoping someone can help me out here with this one. We have TSM for Sharepoint or DocAve configured and working in our environment.

It is pretty much a backup solution that dumps its files to TSM (comparible to RMAN or SQL backtrack)

Everything seems to be controlled from within Docave, including backup pruning.

Now i think i am having an issue where it appears that expiration on the node that is set up for Docave is not doing anything. I cannot see where i am reclaiming tapes, and my storagepool for Sharepoint is growing quite fast (i have a dedicated tsm storagepool for DocAve backups)

On TSM my node is set up with with Backup Delete Allowed - YES and the node is in its own MGMT Class with the following parameters set as per the documentation:

VerExists - 1
VerDelete - 0
RetExtra - 0
RetOnly - 0

On the Docave server, there is data pruning policies too set like so

Data Pruning Production:

All backup types selected
Select latest backup data to keep 2 full backup cycles
Keep at least 5 days old data
remove backup job = yes

I randomly do a q content on some of the volumes in the storagepool and see files with their unique filenames with timestamps of over 2 months ago.

I am not sure if i have to manually delete the old data from these volumes, i cant imagine having to do this, it would be kinda stupid..
Expiration should do this, or at least purge that stuff so reclamation can take effect on the volumes...

any ideas? anyone else with DovAve having any issues?

 

[TonyB]

Hi,

My first suspicion would be that the objects are never being marked as "inactive" within TSM. Expiration parameters only apply to inactive objects, so that might explain why there's no deletion going on.

You might want to have a look at the state of the objects via the backups table using something like:

select state, count(state) from backups where node_name='your node name' group by state

Cheers,

T

 

[BBB]

Yeh I agree with Tony, it looks like the docave pruning isn't happening.

 

[Leigh]

same here - I've upgraded to the new version of TSM for SharePoint and it's not expiring the data.

 

[Leigh]

check here..

http://www-01.ibm.com/support/docview.wss?uid=swg21326529

 

[Jeff_Jeske]

Did you know it expires only AFTER a full backup. Even if you have it set to purge at 60 days if you only run a full once every 30 days some of the data could be up to 89 days old.

 

[spiffy]

So what happens if the backup fails? does it still run the expire/prune job?

I see where i can set it to prune before the backup, i may set it to that..

Also, it only runs the expiry after a full backup?,, that aint cool....

 

[spiffy]

I just ran that select statement..

STATE Unnamed[2]
------------------ -----------
ACTIVE_VERSION 57736
INACTIVE_VERSION 3



not cool......

I need to figure out how to fix this and fast....

 

[Jeff_Jeske]

Well... hopefully if your full job fails you rerun it!

This might be a helpful link:

http://www-01.ibm.com/support/docview.wss?uid=swg21393627

 

[spiffy]

Thanks for that link, i will look at it and see what i can see.

 

[Jeff_Jeske]

Just a follow up..... When I first deployed my DocAve SharePoint backup agent I didn't have my full backup in the same backup plan as my incremental. Later I determined that I needed to have them in the same plan so I deleted the two previous plans and created a new one with both the incr and monthly full within it.

Over the last few months I have been watching my SP TDP occupancy and its larger than I expected it to be. So I decided to run a select to see what was out there and I found a bunch of old data that needed to be manually deleted.

select * from backups where node_name='NODE_NAME_IN_CAPS' order by backup_date > C:\FILENAME.TXT

I then cut and pasted the object numbers of the data I wanted gone and put them in a document with a list like this:
delete object 175000000
delete object 175000001
delete object 175000002

I bound the document to a script and ran the script. This purged all the old useless backup plan data. Keep in mind I needed to delete thousands of objects so I ended up parsing the select statment dump file inserting the delete object command where needed and removing the data I wanted to keep. Fairly simple but a tad dangerous if you select an object you might still need. Be carefull. It may be smart to run a DB backup before moving forward with the delete.