Full backup of TSM Client Ver 6.3

[tsmrefresher101]

Dear All,

Please suggest!

We have a process to get final full backup for an year while retiring client nodes.

Have tried multiple ways, but it was always ending up in Incr backup. Unsure if selective backup could cover all the Filespaces. Please advice on how to achieve this in command line.

OS - Linux

Thanks in advance!

 

[marclant]

A selective backs up everything you specify, more info: dsmc help selective

However, if you are decommissioning a node and want to keep the last backup for a year, active backups never expire, so your last incremental backup includes ALL that data already. Even if some files were backed up 2 years ago, if they are active, they are on the server. The only advantage a full gives you is that if your data is stored on tapes, it will be spread on less tapes if you do a full. There's no other advantage.

If your server (not client) is 8.1.7 or higher, a retention set is an even better approach: https://www.ibm.com/support/knowled...v.admin/t_admin_retention_overview.html?pos=2

And lastly, an archive is another alternative, but not much real value since your last incremental already captured what you need.

 

[tsmrefresher101]

A selective backs up everything you specify, more info: dsmc help selective

However, if you are decommissioning a node and want to keep the last backup for a year, active backups never expire, so your last incremental backup includes ALL that data already. Even if some files were backed up 2 years ago, if they are active, they are on the server. The only advantage a full gives you is that if your data is stored on tapes, it will be spread on less tapes if you do a full. There's no other advantage.

If your server (not client) is 8.1.7 or higher, a retention set is an even better approach: https://www.ibm.com/support/knowled...v.admin/t_admin_retention_overview.html?pos=2

And lastly, an archive is another alternative, but not much real value since your last incremental already captured what you need.

Appreciate the reply.. This is a requirement by client to take a final full backup before decommission, hence the struggle.

Have used selective command to take full backup of every FS in the system. Now this wouldn't reflect anywhere in the "q fi" or from TSM server too. How to check the backup status of each filespace after selective backup? any select commands to check the same.. Tried to direct the output of selective command to a file, still this shows the total objects only but looking for filespace wise.

Thanks in advance!

 

[marclant]

There's no way to tell by looking at the filespace. The filespace will show the last backup date of a complete backup of the filesystem (incremental or selective). By complete, I mean that the whole filesystem is processed.

You may be better off with an archive then, save the output of the archive as proof. But again, no proof at the filespace level.

I know it's hard to convince your client, but their requirement is not really a business requirement. If the data is stored on tape, then making a selective to have all that data together on fewer tapes is a valid requirement. However, if they think they have are more protected with a selective than an incremental, the issue here is that they don't understand how progressive incremental forever works. T

After the last incremental, the server will have all the active version (latest version) of all the files that exist on that filesystem at the time of the backup, regardless when it was backed that day, last week or last year.

After the last incremental, the server will have all the active version (latest version) of all the files that exist on that filesystem at the time of the selective backup.

So as you see, you don't get a more recent backup with a selective, you just get the same data again, and as mentioned earlier, that can be beneficial if stored directly on tape. However one could move the data on a smaller set of tapes anyway with move nodedata.

 

[RecoveryOne]

My two cents is an archive of the node to be retired is the way to go. This way, you can set the retention on it and have it automatically expire. So your client can say 'I need this kept for 5 years'. Great, retention set to 5 years, it's documented in whatever journal/ticket system you use and you are covered. Downside is, if two years into keeping that data for a total of 8 years, you would need to restore and rearchive (don't think we can change retention for archives on the fly). Also less for you to remember. Extra bonus here: Use the archive description field! I use it to document case numbers and other valuable info.

Here's a handy script I whipped up to print out a list of well...everything you archived for a specific node. Its dirty, and it doesn't take into consideration if your node has more than one archive. I do think some credit for the query goes to marclant as well (been too long marclant!).
Requires KSH:

#!/bin/ksh
#Global Variables
TSMADMIN=<admin account>
TSMSE=<Tsm server)
TSMPA=<password for admin account>

# Function to call tivoli!
tsmcmd() {
    dsmadmc -se=${TSMSE} -id=${TSMADMIN} -pa=${TSMPA} -dataonly=yes "$*"
}

is_node() {
    tsmcmd "q node $x" | grep -q $x
    if [ $? -eq 0 ]; then
        ISNODE="TRUE"
        echo "Node $x is here"
    else
        ISNODE="FALSE"
        echo "Node $x does not exist"
        exit 1

    fi
}

echo "Please enter the node you want archive list for: "
# Read input
typeset -u x
read x
# Null selection, exit
if [ -z "$x" ]; then
    echo "Invalid selection"
    exit 1
fi

is_node "$x"
if [ $ISNODE == "TRUE" ]; then
    tsmcmd "select filespace_name||hl_name||ll_name as \"Full name\" from archives where node_name='$x'" | sed '/^$/d' > $x.archive.txt
    echo "File $x.archive.txt should be created in your cwd."
fi

 

[marclant]

(don't think we can change retention for archives on the fly)

You can update the retention anytime, but it affects all objects bound to that management class. Every time Expiration starts, it looks at what the retention is at the moment, then compares that to the objects on the server, and expires those that qualify. So you can either make it expire earlier or later if needed.

 

[RecoveryOne]

You can update the retention anytime, but it affects all objects bound to that management class. Every time Expiration starts, it looks at what the retention is at the moment, then compares that to the objects on the server, and expires those that qualify. So you can either make it expire earlier or later if needed.

I was incorrect then! Thank you for the clarification!
I so far have not yet had to update the retention for a node previously archived.

 

[tsmrefresher101]

Many Thanks Marclant and RecoveryOne! Appreciate the help..

 

[RecoveryOne]

You are welcome and good luck.