DRM - Do you need to schedule a 'backup stgpool' command?

[uk086242]

Hello,

I am setting up DRM for a particular storage pool.

I have ensured that the copy storage pool in question is managed by TSM DRM (confirmed using the q drmstatus command).

I have also created an admin schedule entry to execute a 'backup stgpool Primary_Storage_Pool Copy_Storage_Pool' command.

Is this admin scheduled process required? The reason I ask is that there is an already existing primary storage pool for a separate set of backups that is configured for use with DRM, but there is no equivalent admin scheduled 'backup stgpool primary_storage_pool copy_storage_pool'. Or will the data be copied from the primary storage pool volumes to the copy storage pool volumes by default?

thanks.

EDIT - I have just spotted that the other already configured and working backup's stgpool had the 'Copy storage pool' value set to a copy storage pool. This means that there was no separate 'backup stgpool....' scheduled process required.

I will amend my new primary stgpool accordingly.

 

[alimirza]

A backup stgpool command is a must to copy data from primary stg to copy stg. So, you should either run the 'backup stgpool primary_stg copy_stg' command manually or you must create an admin schedule to do it. The copy stg pool parameter on the primary stg does not mean that the backup will start automatically

 

[BBB]

Just wanted to clarify... When 'copystgpool' is defined, most stuff going to it will get copied to the copypool at the same time as it goes to the primary. But there can be times when this doesn't happen, so as a fail-safe, you should always have the "backup stgpool" scheduled somewhere as well.

DRM does not automatically ensure copy pools are kept up to date in any way.

 

[hucha]

What I understand is that with copystgpool active on your primarypool you have activated what is known as "simultaneous write" which means that a client backup writes the data both in the primary and the copypool at the same time during the backup, Assuming your copypool is sequential, which is very often the case, this means writing to tape during the backup window what makes controlling your tape drive resources very important, I would not recommend that in a large environment.
To make sure all your backup data gets into the copypool always use the BA STGPOOL prim(disk) copy(seq), as use MIGR prim(disk) prim(seq) and BA STGPOOL prim(seq) copy(seq)
Setting up DRM is something completely different

 

[BBB]

Hucha is correct re copystgpool activating simultaneous write. But it can be very useful in a large environment - for example sending a mammoth database back direct to primary tape and copypool tape at the same time. As hutcha said, making sure you have enough drives is important though, but as long as thats under control it can be very good thing, saving you from having to do a read from primary write to copypool later on.

 

[alimirza]

One thing about the 'copystgpool' parameter on the primary storage pool, (from my orignal post it seems that I forgot that this is for the simultaneous write and BBB thanks for the clarification) is the when you enable the simultaneous write feature and you are using LANFREE through storage agents, the data will not go LANfree and will go only on LAN. This is one of the major downside of the "Simultaneous Write" feature and because of that you may end up spending more time to backup the data any way.

 

[uk086242]

Thanks for the replies everyone - much appreciated.

It seems to work ok, although I am having some problems with the volumes that are being picked up (as scratch) by the copy storage pool when checking them back in after they have been checked out as part of the offsite / vault process.
But I am still looking into this problem.