Send primary stgpool tapes offsite

[itcsge]

Guys - we have too much data to back up and duplicate via copystgpools - so i'm thinking about committing a cardinal TSM sin of sending primary tapes offsite rather than duplicating and sending the copy stgpools offsite.

Is this poissible? does anyone do this? or is it just something to not even consider doing?

tia

 

[tenpin]

Look into overflow location, you can checkout primary storage pool volumes this way. Make sure you setup something to watch the logs for volume requests.
Docs:
http://publib.boulder.ibm.com/infoc.../com.ibm.itsmaixn.doc/anragd55221.htm#manlibi

 

[itcsge]

thanks tenpin - i'm considering that option but wouldn't it only allow me to send it offsite once the tape was full?

 

[chad_small]

No the tapes don't have to be full to be sent offsite. I have to ask why you would want to sent the primary tapes offsite? The more handling being done on the primary the more chance for lost data.

 

[chad_small]

WOW! Forever? If that's the case I would definitely look into a dedupe/block level backup tool to cut down on the amount of data that actually has to be backed up nightly. I swear some requirements are just nuts!

 

[tbyrne]

Is this possible? does anyone do this? or is it just something to not even consider doing?

Forever - that's pretty ugly. What you are contemplating can be done (not necessarily a great idea for all the aforementioned reasons, but it has its place as a strategy). There is always the risk unrecoverable data loss due to media damage or loss, but if that risk is acceptable, you can do it.

We have some customers that utilize that strategy in limited cases (like you, it's for mail, although they don't retain everything forever as you are.)

If you decide to do this, a product called AutoVault can make life a lot easier. We use it ourselves and for many of our customers, and it will vault primary pool tapes, as well as copypool and DB tapes. Primary pool tapes can be set to vault only when full, or based on the age of the tape. We find that it greatly simplifies the process of managing the tape rotation process.

Chad's suggestion of a deduplication solution might also be worth considering - we've found that long-term accumulations of mail data can lend itself very well to that; we've seen 20:1 data reduction factors on this type of data. As always, YMMV.

Good luck!

Ted

 

[n9hmg]

dude: Unless this forever data is the only data backed up in this instance, bring it in to an isolated primary pool, so your normal data can be expired,migrated,reclaimed,etc.. Heck, concerning even the forever data, you could go ahead and expire, making a ba db and sending that with a volhist to go with that old data, so you can keep your database sane, but recover any point in time from the forever crap.

portable magnetic media, multi-year retention, no copypool protection... you know you might as well write to /dev/null, right?

I know how it is with legal requirements. As long as you're not liable for failure in restoring the mandated retained data, you're off the hook. Make sure you're clear, or have a good CYA trail with having warned management.

 

[egtegt]

I'd like to know if someone has solved the main problem that I have with such solutions : How do you manage copypool reclamation with primary tapes sent offsite ?

If a tape in the vault need to be reclaimed and the corresponding files are in non accessible tapes, then it will be stuck forever in the vault though it may contains only 1 or 2 percent of data.

This is the reason why I consider that checkin primary tapes out can only be an interim solution while waiting for the new library. Or you end up with hundreds of tapes 99% empty.

Up to now, the only solution I found was to decrease data retention on primary tapes and make regular Archiving or backupsets with a long retention.

I don't take in account the solution not to duplicate pools, the fact that TSM uses full incremental renders this solution too dangerous for me.