backup that never expire

[marclant]

this is my first time going this TSM. so noob not allowed here? seeking for proper training as well.

Noobs are definitely allowed and welcome. That was not an attack on you. It's just that Spectrum Protect is a complex product. In order to become a successful administrator, you will need to learn some of the basic and more advanced concepts of the product. We all started at the same place as you, and it took us training and years of experience to get where we are.

While I may give the impression that I am difficult with you, I'm trying to give you material that you can read so that you can understand what you need to do. I can feed you the exact commands all day long, but you would not learn anything.

While you wait for training, I highly recommend you read this RedBook, this will help you understand a lot of things:
http://www.redbooks.ibm.com/redbooks/pdfs/sg244877.pdf

Before you read it cover to cover, focus on these questions to help you understand what you need to figure out here. Start with sections 6.2, 6.5 and 6.6, they have to do with client option files, backups and archives, including retention. And additionally all of Chapter 9 which is about policy management, which talks about management classes, copy groups, destination and retention. Those are all topics you need to understand before you start changing retention and destinations as one small change can result on data loss.

Just skip those sections, they are absolete:
1.2 IBM Tivoli Storage Manager Express
3.3.3 Tivoli Storage Manager database .
12.2 ISC User and Group Management
Chapter 17. Reporting.

 

[marclant]

So one of the thing you need to understand to address your initial question.

You need to find out which management class the archives are going to now?
Is it the default management class?
Are there other nodes using it? If it's the default, it's possible.
This means that if you change the retention, you possibly affect other data.
Then it's better to create a new management class with the retention you need and the destination you want.
You need to validate the policy after a change to a management class.
And use an include.archive entry in the corresponding stanza of dsm.sys to point to that new management class.

As you see, it's complex. We don't know your environment, so there's a lot of decisions we cannot make for you. So I'm giving you material to help you understand what it is you need to do and apply that to your environment. All environments are different and have different business requirements.

 

[seekerTSM]

its so confusing. do you happen to know any training here in PH?

i am confuse on this. i archive the file on 11/28, then i query archive today and found out that it will expire on 01/04/20(37 days)?

but when i check on query mgmtclass, archive retention is 365 days.

 

[marclant]

That's not the archive retention, that's the archive retention failover, I mentioned that last week: https://adsm.org/forum/index.php?threads/backup-that-never-expire.32966/#post-136919

You need the -detail option to see the retention of the FLATFILE_MGMT management class archive copygroup.

 

[seekerTSM]

where to check that? in TSM server or client?

i cant check it on CLIENT

 

[marclant]

Oh, don't provide the management class name. Just query mgmtclass -detail

 

[seekerTSM]

so the retention is 37 days? i thought backup a data using archive is permanent, but its just 37 days?

 

[marclant]

Archive data is kept as long as the retention you set it to. So if you want to keep that data forever, you have 2 options:

1 - update the archive copygroup for the management class FLATFILE_MGMT.
WARNING: This will affect ALL objects archived to that management class by other nodes too. You have to decide if you want that or not.

update copygroup syntax:
https://www.ibm.com/support/knowled...reference/r_cmd_copygroup_archive_update.html
Then activate the policy: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/srv.reference/r_cmd_policyset_activate.html

2 - create a new management class: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/srv.reference/r_cmd_mgmtclass_define.html
- define an archive copy group with the retention you want: https://www.ibm.com/support/knowled...reference/r_cmd_copygroup_archive_define.html
- activate the policy: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/srv.reference/r_cmd_policyset_activate.html
- in your archive command, use the ARCHMC option: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/client/r_opt_archmc.html

 

[seekerTSM]

so if i retain this and no changes made, my archive backup will last only for 37 days?

but i check on TSM server that we have some whos retention is 400 days?

 

[marclant]

Yes, but in a different policy domain. Your node only has access to the management classes that belong in the same domain as the node.

Did you read the material I provided here: https://adsm.org/forum/index.php?threads/backup-that-never-expire.32966/#post-136922

That will help you understand how policy domains, management classes and copy groups work together. You should understand this before you start making changes.

 

[seekerTSM]

yes i read, but it seems if too much that needs to be done if i want to archive our backup for 1 year.

i am now back to start again, and looking for backup but will not expire in 30 days. i thought this archived will save me.

base on the copygroup output, most of our node has only access to flatline and no access on archive_mgmt

 

[marclant]

yes i read, but it seems if too much that needs to be done if i want to archive our backup for 1 year.

Backup and archives are 2 different things. You backup files and you archive files, but you can't archive backups.

base on the copygroup output, most of our node has only access to flatline and no access on archive_mgmt

And the output you showed is actually the backup copygroup. You need TYPE=ARCHIVE to see the archive copy groups

There's a lot flexibility, but with it comes complexity.

 

[seekerTSM]

hi,

any suggestions on how to retain long any specific backup? for example they request to backup E:\ORA_DATA\AGRT and they want to retain it for longest time possible, how can i do that? it seems archiving it will not help. how can i retain that for longer than 30 days retention?

 

[seekerTSM]

hi,

found some command, but not sure if this will cover all archive only or backup as well?

upd copy FLATFILE_POLDOM FLATFILE_POLSET FLATFILE_MGMT t=a retv=365

then use

activate pol FLATFILE_POLDOM FLATFILE_POLSET

reply "Yes" at the confirmation question.

 

[marclant]

That covers archive only, that's what T=A does. HELP UPDATE COPYGROUP

But, do you want ALL the archives from that domain to be retain 365 days, or just the one from that node you were inquiring about?

 

[seekerTSM]

That covers archive only, that's what T=A does. HELP UPDATE COPYGROUP

But, do you want ALL the archives from that domain to be retain 365 days, or just the one from that node you were inquiring about?

i want all, i want every node that i use the command archive, it will be archive for 365 days.

but it will only include all the servers under this FLATFILE_MGMT ?

 

[marclant]

i want all, i want every node that i use the command archive, it will be archive for 365 days.

but it will only include all the servers under this FLATFILE_MGMT ?

Correct. If that's what you want, that's what those commands will do.

 

[seekerTSM]

Correct. If that's what you want, that's what those commands will do.

will it go on all of our nodes or the node only that connected to FLATFILE_MGMT?

and if not, is it possible to make that all our ARCHIVE will have that retention?
so everytime we use ARCHIVE COMMAND, all will have 365 days.

 

[marclant]

Nodes are not connected to a management class. They are a member of a domain. The domain contains management classes, and the management classes contain copy groups.

So, your change only affects nodes that belong to the domain FLATFILE_POLDOM and use the FLATFILE_MGMT management class. If you want ALL the nodes from ALL domains, you need to repeat that change for the archive copy groups of the other domains too.

 

[seekerTSM]

hi,

i want to implement it, i want to extend our ARCHIVE but i have some worries and clarification

if i do that archive retention extention, where will it write? on our DISK or TAPE?
where it will write? is this our disk? what GB is the limit of archive if i do that?
what will be the effect on our TSM on the long run? is our TSM will have no negative effect?


@itsm001:/ #‌ df -Pg

Filesystem GB blocks Used Available Capacity Mounted on

/dev/hd4 4.03 3.15 0.88 79% /

/dev/hd2 4.00 2.45 1.55 62% /usr

/dev/hd9var 5.00 1.03 3.97 21% /var

/dev/hd3 10.03 4.03 6.00 41% /tmp

/dev/hd1 2.00 0.33 1.67 17% /home

/dev/hd11admin 0.12 0.00 0.12 1% /admin

/proc - - - - /proc

/dev/hd10opt 7.16 2.83 4.33 40% /opt

/dev/livedump 0.25 0.00 0.25 1% /var/adm/ras/livedump

/dev/fslv00 25.00 20.12 4.88 81% /export/lpp_source

/dev/fslv01 5.00 2.78 2.22 56% /export/spot

/dev/fslv02 198.00 174.79 23.21 89% /export/mksysb

/dev/fslv03 160.00 135.09 24.91 85% /software

/dev/fslv04 1.00 0.79 0.21 79% /usr/tivoli/tsm

/dev/fslv05 7.00 4.26 2.74 61% /opt/tivoli/tsm

/dev/fslv06 0.25 0.08 0.17 34% /tsm02/instance

/dev/lv_tsmdb_v01 14.94 4.83 10.11 33% /tsm02/db/vol01

/dev/lv_tsmdb_v02 14.94 3.37 11.57 23% /tsm02/db/vol02

/dev/lv_tsmdb_v03 14.94 3.37 11.57 23% /tsm02/db/vol03

/dev/lv_tsmdb_v04 14.94 3.37 11.57 23% /tsm02/db/vol04

/dev/lv_tsmdb_v05 14.94 3.37 11.57 23% /tsm02/db/vol05

/dev/lv_tsmdb_v06 14.94 3.37 11.57 23% /tsm02/db/vol06

/dev/lv_tsmdb_v07 14.94 3.37 11.57 23% /tsm02/db/vol07

/dev/lv_tsmdb_v08 14.94 3.37 11.57 23% /tsm02/db/vol08

/dev/lv_tsmlg_pri 59.50 59.01 0.49 100% /tsm02/log/prim

/dev/lv_tsmlg_mir 59.50 59.01 0.49 100% /tsm02/log/mirror

/dev/lv_tsmlg_arc 199.50 1.47 198.03 1% /tsm02/log/arch

/dev/lv_tsmlg_afo 199.50 0.03 199.47 1% /tsm02/log/arch_fo

/dev/lv_tsmstg_v01 499.00 54.60 444.40 11% /tsm02/stg/vol01

/dev/lv_tsmstg_v02 499.00 29.37 469.63 6% /tsm02/stg/vol02

/dev/lv_tsmstg_v03 499.00 37.90 461.10 8% /tsm02/stg/vol03

/dev/lv_tsmstg_v04 499.00 29.37 469.63 6% /tsm02/stg/vol04

/dev/fslv07 6.00 0.28 5.72 5% /opt/IBM

/dev/templv 498.75 248.03 250.72 50% /tempfs

/dev/nmonlv 0.03 0.01 0.02 39% /var/nmon