Tape Count Required for Offsite Storage

[kennedto]

Lets say I have a primary storage pool with 10 tapes TAPEPOOL1 ( for easy artihmetic).
Every day the primary pool gets copied to a copy pool COPYPOOL1

So at this point I have used 20 tapes and have two copies for the data.

If i used DR to send tapes offsite

mov drm * s=dbb wherest=mo tost=vault copystg=COPYPOOL1 rem=bulk

This puts all ten tapes in COPYPOOL1 into the IO/Bin to be sent to the VAULT.


The next day, TAPEPOOL1 is copied to COPYPOOL1 again to make sure we have two copies of the latest data.

So now 30 tapes have been used. 20 onsite 10 offsite.

Now TAPEPOOL1 and COPYPOOL1 are same and some off site data in volumes in VAULT data is one day old.

To make sure we have latest copy of data to VAULT run DR again

mov drm * s=dbb wherest=mo tost=vault copystg=COPYPOOL1 rem=bulk

This puts all ten tapes in COPYPOOL1 into the IO/Bin to be sent to the VAULT.


The next day, TAPEPOOL1 is copied to COPYPOOL1 again to make sure we have two copies of the latest data.

So now 40 tapes have been used. 20 onsite 20 offsite.

If you continue this without reclamation, the number of tapes used will grow by 10 everyday. Is this correct? Or do I misunderstand how this works.

If we have parameters set for reclamation to occur at 8 days seems like it would add up to a lot of offsite tapes needed to
store 10 tapes worth of data in a primary pool. I understand retention policies for a given pool, but in this case COPYPOOL1 is
onsite and offsite and may have several copies. Can you explain how this works?

 

[TiborB]

Well we dont use DRM capagilities, but by my understanding with 'move drm' you are creating something like snapshot of all copypool data with database information in addition to it.
The time of expiration of these drm 'snapshots' are determined by SET DRMDBBACKUPEXPIREDAYS command.

As I understand there is second option to have an offsite copypool - this is like standard copypool but tapes are checked out and have own reclamation policy (in fact no reclamation could be done, only when a tape is empty it would be marked as scratch). In this scenario, all data would be stored once (in the copypool), though count of tapes could be quite high as well due to 'no reclamation' policy resulting in low average utilization of tapes. Alternatively, there could be reclamation done, but it needs a staff, that would react on requests of TSM to insert off-site tape for reclamations. (Again, no personal experiences with that)

 

[moon-buddy]

The DRM process works this way:

1. There is a DRM for the TSM DB if you use tapes. After backing up the TSM DB, the backup is moved to offsite via the 'move DRM * ..." command

2. The second phase of the process is moving COPY pool tapes to the OFFSITE location. Again using 'move DRM * ...."

3. The trend of growth is NOT linear, meaning 10 today, 10 tomorrow, etc. Rather it is a function of: a) when an online tape gets full, b) collocation settings, and c) when expiration and reclamation is done.

4. The offsite tape count is generally higher than the onsite tape count since the reuse value is set a day (recommended) longer than the TSM DB expiry days.

5. Offsite reclamation is done in reference to the online pool. As an example, tape A to M are online pool tapes, and tapes N to Z are offline pool tapes. If reclamation runs against tapes N to Z, there is no need to recall tapes from offsite to be loaded to the tape library. Instead, TSM will load a scratch tape and copy again the data from online to the new set of offsite tapes (say, N1 to Z1) meeting reclamation thresholds. Simultaneously, the TSM DB tracks the offsite tapes (tapes N to Z) and "zeroes out" its contents as the data is copied over to the "new" set.

6. The new offsite tape pools should then be checked out for offsite tape storage and the "old" offsite tapes recalled WHEN the reuse delay reaches ZERO and TSM prompts you to recall these.