Define new stgpool and update copygroup

[nathrix]

Hi All,

I need your input for the best solution possible, any thoughts will be much appreciated, so here's some background info:

2 x Storage Management Server for Linux/x86_64 - Version 7, Release 1, Level 9.100 installed (Spectrum Protect Site01 and Site02).
1 x Tape Library at Site02 with 3 x LTO7 tape drives available for use.

Site01 replicates diskpool1 to Site02 diskpool1 and then Site02 runs protect stgpool to the tape library situated at Site02.

So we have three copies of data (one copy at site01 on disk, one copy at site02 on disk and one copy at site02 on tape).

Freaking awesome and easy to manage!

Current config:

TSM: Site01 > q stg DISKPOOL1 f=d


TSM: Site02 > q stg DISKPOOL1 f=d


TSM: Site01 > q co * *LY f=d


TSM: Site01 > q stg DISKPOOL1


As you can see above, diskpool1 Pct Util is at 80.9

Easiest would be to define stgpooldir in diskpool1, problem solved.

Here's the problem, the client does not want to buy more disks.

They want the MONTHLY and YEARLY backups on TAPE, not on DISK, so in effect the risk will be they will only have one copy.

So my questions:
1. Should I create a new primary stgpool at Site01 (diskpool2) and then update the MONTHLY and YEARLY copygroup to the new stgpool (copy destination = diskpool2)?
2. Will all the MONTHLY and YEARLY backup data be migrated from diskpool1 to diskpool2?
3. From there, what will be the best solution/configuration to get the MONTHLY and YEARLY stgpool data to Site02 on TAPE?

Thanks

 

[Mita201]

Hi,
You can't migrate data out of one directory pool to another. Only new data will go into new pool.
You can't have, in current setup, data only on tape. Basically, you will need to connect your clients directly to the server on site2, for operations of MONTHLY and YEARLY backup, if you want data to reside only on tape. Or to go with some quite old feature, create stgpool of devclass server, which will point to tape pool on site02.

 

[marclant]

They want the MONTHLY and YEARLY backups on TAPE, not on DISK, so in effect the risk will be they will only have one copy.

Another option is upgrade the server to 8.1.7 and use retention sets instead of doing yearly/monthly, assuming we are taking client or VM backups, and not TDPs.
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.7/srv.common/r_wn_retention_817.html

 

[Mita201]

Not sure about that. I understood that retained backup will reside where they are, can't be migrated to tape. But this is quite new, so I may be wrong.

 

[marclant]

Not sure about that. I understood that retained backup will reside where they are, can't be migrated to tape. But this is quite new, so I may be wrong.

That is correct, but you don't, need to take a monthly and yearly backup. You just do your daily backups. You create a retention set on the last day of the month and it tags all the active objects at that moment for a longer retention. The same after the last year end incremental, you create a retention set that keeps all the active versions at that time for a longer retention.

So you are only backing up the data once, but you could have different rules for retention. If a file has multiple retention rules, it won't expire until released by all rules. Since you are only backing it up once, you don't need to worry where to store it.

The other thing to consider, if they add tape storage for monthly and yearly, they don't take advantage of the dedup that is in the container pool, because most of that data already exists in the container pool anyway. It would make more sense to increase the size of the container pool.

Tiering to cloud might be a consideration too, could be a private or public cloud.

 

[nathrix]

Some more info and some of my ideas:

MONTHLY/YEARLY (scheduled to run on the 1st of every month).
Backup to run to a newly created disk stgpool and then later migrated off to have space for the next scheduled MONTHLY/YEARLY backups.

(snipped some detail)
TSM: Site01 > q sched MONTHLY NODENAME_MONTHLY f=d
Policy Domain Name: MONTHLY
Schedule Name: NODENAME_MONTHLY
Day of Week: Any
Month: Feb,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec
Day of Month: 1
Week of Month: Any

TSM: Site01 > q sched YEARLY NODENAME_YEARLY f=d
Policy Domain Name: YEARLY
Schedule Name: NODENAME_YEARLY
Day of Week: Any
Month: Jan,Mar,Apr
Day of Month: 1
Week of Month: Any

 

[nathrix]

It would make more sense to increase the size of the container pool.

Was my point exactly, but what do you do when your client refuses to simply purchase more disk space

 

[marclant]

Was my point exactly, but what do you do when your client refuses to simply purchase more disk space

The only thing you can do is present facts. Their solution requires buying additional hardware too, plus added complexity which also adds to the management cost.

Combination of adding more disk and using retention sets would reduce the space needed, eliminate the need/time/space to do monthly/yearly backups, while meeting their long term retention requirements.

 

[nathrix]

Thanks for the advise guys, was hoping for a way to migrate the monthly and yearly backups out to a new stgpool and then migrate that data to tape, my understanding of it was comfirmed by you. They will have to buy more disk storage. Cheers

 

[marclant]

They can however reduce the amount of additional disk and additional processing time by using retention sets in 8.1.7 in lieu of monthly/yearly backups.