Archive Policy Retention on Server2Server backup

[Rick111]

Hi

local = the main TSM server that backs up all the clients
target = the remote tsm server that is just used to take a copy of the primary storage pool on the "local" server

I've setup server2server diskpool backup but have ran out of space. I'm looking to get more disk but whilst I was looking around I got thinking about the default 365 archive retention on the target server.

What impact does this have if I change it to say, 15 days? Will it causes much more daily data transfer but better utilisation of disk usage? I'm a bit unsure how the policy works on Server2Server diskpool backups so any information would he helpful.

Thanks
R

 

[moon-buddy]

It depends on how you originally had setup archiving.

If you had specified the default values, changing the retention to 15 does not free up disk space. Changing to 15 days will be applied to next the archive run.

As for your question of whether TSM will run archiving more if the retention is set to 15 days, the answer is: it is based on the archive schedule. You know the schedules so you can tell when archiving will run. The only thing to note is that the archive expires after 15 days.

See 'help define copy'

 

[Rick111]

Hi Thanks

What I'm confused about though is this isn't a traditional archive "thing" it's actually an offsite copy of a storage pool using another TSM server so I was unsure how expiration and everything works in that relation.

I still can't get my head around it. My main TSM server is sending a copy of it's primary storage pool to another TSM server. This is in the event of a catastrophic disk failure at the main site and then I can just pull the data back across. Obviously I only want the latest "version" of the storage pool to be retrieved so how does this relate to the archive policy?

Am I really storing a 365 day spanned copy of the storage pool and what does that even mean?

Maybe I'm asking the wrong questions because I have it set up all wrong...

 

[marclant]

So, your copy pool for server1 is on virtual volumes on server2. In this case, server1 is responsible to expire the data off from the virtual volumes. Server2 just sees the volumes as having less space and will reclaim them once eligible. The retention is controlled by the source server (server1) and not by the target (server2).

So when the primary copy expires on server1, the copy expires too. You have to think server2 as if it was just a bunch of tapes, it doesn't control anything, it just stores the data for server1. Server1 is still responsible for it's own data.

Are you running expiration on the source server and reclamation on both the primary and copy pool? If not, that could be why you are running low on space.

 

[Rick111]

Thank you very much. That clears things up for me. I am running expiration and I believe I am running out of space just because the copypool size is only slightly bigger than the source pool and we have to take into account reclamation.

I was more worried about the archive policy on the target as I just couldn't get my head around the relevance but you have cleared that up with "think server2 as if it was just a bunch of tapes, it doesn't control anything"

So thanks again, appreciate your feed back. I'll get back at my manager for more disk.

Cheers
R