Check which pool a node is being backup on

[fadzlirot]

Hi guys,

I cant seems to find a way to know which pool a node is being backup on. anyone knows how? because sometimes i have to create a new node just to make sure it is backed up on the right pool.

 

[Rigido]

I use the following script, you can use it as a starting point:

select rpad(node_name,30) as NODE, -
rpad(stgpool_name,30) as STGPOOL, type, -
cast((sum(PHYSICAL_MB)/1024)as DEC(10,2)) as PHYSICAL_GB -
from  occupancy -
group by NODE_NAME,stgpool_name,type order by 1,4 desc

I would add that a normal "Q OCCUPANCY <nodename>" will do the trick

 

[marclant]

You can also check from the client using:
dsmc query mgmtclass -detail:

Domain Name               : WORKSTATIONS
Activated Policy Set Name : STANDARD
Activation date/time      : 09/12/2007 12:36:50
Default Mgmt Class Name   : WORKSTATIONS
Grace Period Backup Retn. : 30 day(s)
Grace Period Archive Retn.: 365 day(s)


MgmtClass Name                  : WORKSTATIONS
Description                     :
Space Management Technique      : None
Auto Migrate on Non-Usage       : 0
Backup Required Before Migration: YES
Destination for Migrated Files  : BACKUPPOOL
Copy Group
        Copy Group Name........: STANDARD
        Copy Type..............: Backup
        Copy Frequency.........: 1 day(s)
        Versions Data Exists...: 3 version(s)
        Versions Data Deleted..: 1 version(s)
        Retain Extra Versions..: 30 day(s)
        Retain Only Version....: 60 day(s)
        Copy Serialization.....: Dynamic
        Copy Mode..............: Modified
        Copy Destination.......: SHARKPOOL
        Lan Free Destination...: NO

The "Copy Destination" is the pool, for this particular machine, it goes to SHARKPOOL.

 

[Rigido]

Marclant, that's true if you never changed domain, set, mgmt or copygroup.

 

[marclant]

True Rigido, but he asked which pool the it is being backed up to (present) and for new nodes.

 

[Rigido]

True Rigido, but he asked which pool the it is being backed up to (present) and for new nodes.

You''re right...

 

[fadzlirot]

Marclant, that's true if you never changed domain, set, mgmt or copygroup.

Hi Rigido, refering to Marclant suggestion, does it mean if I changed any of the domain, set, mgmt or copygroup, it will not be updated when I use the q mgmtclass -detail?

 

[Rigido]

No...
If you do a query mgmt on the client side, you see the actual mgmt class/es the client can use.
You can register a node on a domain, do backups (let's say it will store data on poolA) then move node to another domain, activate a new set with a different default mgmt class or just update the copy group, from now on node will store data on poolB...but it still has data on poilA if you don't do a "move nodedata"

 

[fadzlirot]

I use the following script, you can use it as a starting point:

select rpad(node_name,30) as NODE, -
rpad(stgpool_name,30) as STGPOOL, type, -
cast((sum(PHYSICAL_MB)/1024)as DEC(10,2)) as PHYSICAL_GB -
from  occupancy -
group by NODE_NAME,stgpool_name,type order by 1,4 desc

I would add that a normal "Q OCCUPANCY <nodename>" will do the trick

I cant figure out yet how to use select statement on TSM but we skip that.
I just want to point out using the q OCCUPANCY will show the final pool that the data will rest, not the first pool that the data goes out to (pardon my english),

for example

tsm: TSM_BAB>q occupancy BROADPAC_DAILY_WINDOWS

Node Name      Type     Filespace       FSID     Storage        Number of      Physical       Logical
                        Name                     Pool Name          Files         Space         Space
                                                                               Occupied      Occupied
                                                                                   (MB)          (MB)
----------     ----     ----------     -----     ----------     ---------     ---------     ---------
BROADPAC_-     Bkup     \\broadpa-         1     BAB_DAILY-        11,110     130,567.6     130,567.5
DAILY_WI-               c\d$                     _3576POOL                           3             8
NDOWS

From here it says BAB_DAILY_3576POOL but actually they will go to a diskpool first before being migrated there.

 

[fadzlirot]

No...
If you do a query mgmt on the client side, you see the actual mgmt class/es the client can use.
You can register a node on a domain, do backups (let's say it will store data on poolA) then move node to another domain, activate a new set with a different default mgmt class or just update the copy group, from now on node will store data on poolB...but it still has data on poilA if you don't do a "move nodedata"

oooh. I see. Thank you Rigido.

 

[Rigido]

The query occupancy command gives you a "photo" of where actually node stored data.
If you have a disk pool to receive data and a tape pool to migrate to and you do the query before and after migration, the query will say node has data on disk pool on the first run then on tape on the second run.
If you do the query while the migration is running you will see node has data on both of the pools.