Migration / Copy Paths

[BDMcGrew]

Good morning all ... I've used TSM for years on pure disk based systems but now I'm trying to add tape to a system with only 4TB of disk and get migration, copying and DR working. But I'm a bit confused in my methods and would like some clarification by those who use tape!

In the past I've always had something like:

def devc ddupdev devt=file dir=/tsm/disk1 maxcap=64g
def stg dduppool ddupdev po=pr maxscr=8 nextstg=diskpool dedup=yes identifyproc=2

def devc diskdev devt=file dir=/tsm/disk2 maxcap=64g
def stg diskpool diskdev po=pr maxscr=64

def devc copydev devt=file dir=/tsm/disk3,/tsm/disk4 maxcap=64g
dev stg copypool copydev po=co maxscr=128

setopt deduprequiresbackup yes

backup stg diskpool copypool

This has always worked the way I'd epxect and wanted in the past but I've always had boxes with tons of disk space. Now that I'm on a box with tape and only 4TB of disk, I need to do it a bit different and I'm not exactly sure how.

def devc ltotape devt=lto
def stg tapepool lto po=pr

upd stg diskpool nextstg=tapepool

I'm not even sure if the above is the right thing to do. I want to keep de-duplication running if possible since about 30% of the data being backed up is duplicate.

upd co standard standard standard dest=dduppool
upd co standard standard standard type=arch dest=dduppool

Right now data is flowing into the server, going to the dduppool and then to thediskpool. I have not done a copy stg yet. (It was my understanding that) dedupe only occurs when you actually copy the stg and from what I've seen this seemsto be true. I've also not started migrating to tape yet as the disk pool is not full enough to migrate.

So how do I define the migration or copy paths here so that data comes in, gets deduped and then migrates to tape? I have a 48x2LTO4 library and it's my goal to have a copy online and then make a DR copy to take off-site as well.

What am I missing here? And if I have a flaw in my theories, please, point it out

thanks,

-brian

 

[marclant]

So how do I define the migration or copy paths here so that data comes in, gets deduped and then migrates to tape?

What would be the point of that? The data will get rehydrated when you migrate it to tape. You should only use dedup if it's the final destination, if the final destination is tape.

You are better off to disable dedup and follow this flow daily:
- client backup to disk during the night (devtype=disk is better for this method)
- perform backup stgpool to tape copypool in the morning
- followed run expiration and reclamation
- in afternoon, before client backup starts, migrate data from disk to tape primary pool
- you are now ready for the next nightly backups

If you don't disable dedup, there are several things you have to consider:
- you have to do the backup stgpool in order for the data to be deduped
- if you use deduprequiresbackup no, it will be deduped right away, but if data gets damaged during dedup, you can't recover it from backup
- the dedup ratio will be terrible, because there won't be enough data to have a lot of duplicates
- there will be a lot of overhead to identify duplicates (which will be few) and also a lot of overhead to rehydrate the data when migrating it to tape

So, using dedup in your situation would add risk and overhead, but would not offer any space savings.