Newbie question on setting up offsite

[tkunkel]

Last time I touched this product was in version 2 so my memory is very hazy... Bear with me.



Does anyone have a outline of what I should be doing to set up and manage an offsite cycle? Eg:



1) backup stgpool * copypool wait=no

2) backup db t=i devc=lto

3) backup volh

4) backup devc

5) ... (this is where I get lost)



Any help / advice appreciated.

 

[heada]

move drmedia is the next step.



1 - backup primary pools to copy pools

2 - backup DB

3 - backup volhist/devconfig

4 - move drmedia wherestate=mountable tostate=vault (moves copies offsite)

5 - move drmedia wherestate=vaultr tostate=onsiter (moves tapes that were offsite back onsite)



You need to have some things configured beforehand. Look at all the "set drm*" settings. A minimum you need is drmdbbackupdays (how long to keep DB backups offsite) and drmcopystgpool (copy pool that DRM manages). There are a few other posts on this site that give more details.



-Aaron

 

[tkunkel]

Hi Aaron



Many thanks for your intersting posts. They make good reading.



I now have refocussed on the DRM side of things after a prolonged dose of vmware firefighting. So:



The settings are 7-day reuse (db backup, copypool and plan - did I miss anything?) and I have fettled with the drm settings as suggested by various posts. In fact, I just recovered some 2-month old tapes that had been in "vault" since my first abortive attempt!



I now better understand the general process but how can I figure out the number of tapes my daily offsite cycle will require? I know. It is a dumb question but is there a simple select statement that I could crib?



Thanks in advance!

 

[yilas]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>move drmedia is the next step.



1 - backup primary pools to copy pools

2 - backup DB

3 - backup volhist/devconfig

4 - move drmedia wherestate=mountable tostate=vault (moves copies offsite)

5 - move drmedia wherestate=vaultr tostate=onsiter (moves tapes that were offsite back onsite)



You need to have some things configured beforehand. Look at all the "set drm*" settings. A minimum you need is drmdbbackupdays (how long to keep DB backups offsite) and drmcopystgpool (copy pool that DRM manages). There are a few other posts on this site that give more details.



-Aaron</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Hello,



Aaron, you say at the step 5 that you change the state of volumes from "vaultrtrieve" to "onsiteretrieve"...



You have the following states :

Step 1,2,3 : state of volume is "mountable"

Step 4 : state of volume is "vault"

Step 5 : state of volume is "vaultretrieve"



OK. But, I don't understand when the tape is at the state "vaultretrieve". It depends of the value of "Reusedelay" of the copy storage pool ?



Cordially,



Yann

 

[yilas]

OK, I reply myself with information found inside the redbook "Desaster Recovery".



<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>They remain in this state until the data on them expires or they are

eligible for reclamation. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



But now, my question is : imagine that tapes have data which retention is set to infinite, the corresponding tapes will never change the state to "vaultretrieve" ?

 

[heada]

Yilas:



Yes and no. The data will remain at the vault forever but not always the tapes. If a tape falls below the reclamation threshold, TSM will reclaim the offsite tape (make a new copy onsite to a filling copy volume) and send the new copy to the vault. It will then move the old tape to vaultretrieve status and recall it on the next run.



tkunkel:



I don't know of any script or formula that will tell you the daily cycle. I observe the ins and outs of volumes for a little more than a month and go with the averages. I know that I send off about 6 3592 volumes a day from one of my servers and get back on average 5 3592 volumes. You would think that over time, I would run out of tapes but sometimes there is a major jump in the number of recalled tapes due to a longer run of reclamation.



-Aaron

 

[tkunkel]

Just some followup and, naturally, a follow-on question.



First, the followup. To find the amount of data TSM is managing, I can run:



backup stg tapepool copypool maxpr=1 p=y w=y



By doing a preview (p=y) it tells me the number of tapes and how many TB its storing in the source storage pool - good enough for me. But now to the question. The answer this command gave is 18TB. In my case that means the first time I do a true storage pool backup it'll eject between 18 to 25 LTO3 tapes! Ouch. Will this be the case each and every day?



I have read and re-read the 532 admin guide to try to understand how the storage pool backups work but I can't quite seem to find a definitive statement concerning their behaviour. Are they full backups or incrementals?

 

[dhcolesj]

Ok, here goes my possibly feeble attempt to explain:



The data in the online storage pool, lets say "onsite" is your disk storage (I'm assuming you're using this only for backups for each night). The data in your tape pool is previously backed up data, lets say, "onsitetape" storage pool. The data in your drm copy pool is (or should be) exactly the same as what's in your "onsitetape" pool, we'll call it "drmtape"



The previous night's backup resides (most likely) in "onsite". When you "backup" this pool you are copying all the data from that pool to the "drmtape" pool for offsite storage. (this should be ahead of migration if you can't do it simultainiously). When you "backup" the "onsitepool" you are doing the same. Once you do this the first time the two should be maintained so as to stay in exact sync with each other.



After that first backup of the tape pool, you would only need to run a backup of "onsitetape" to catch what went straight to tape the night before, or migrated out of "onsite" if your disk pool is too small. This means that the answer to your question is NO, once you do that initial backup the two tape pools should be the same, and require a similar number of tapes each day. (Of course I know that they're never "Exactly" in sync, but logically they are). Also they are incremental when you are talking about the "onsitetape" to "drmtape" backups because if the data has already been copied to "drmtape" TSM knows not to do it again. Its "full" when you are talking "onsite" to either tape pool because all the data in the disk pool is new data.



So the daily order would be (depending on your version of TSM):

1. Backup "onsite" to "drmtape"

2. Migrate "onsite" to "onsitetape"

3. backup "onsitetape" to "drmtape"

And then of course you would keep track of reclamation needs.

I hope this was helpful along the lines of what you needed to know.