Discrepancy between reported amount of data stored on source and target servers

Resolving The Problem

It is normal for the amount of data to be reported differently on the source server and target servers for virtual volumes, if the virtual volumes on the source server have reclaimable space > 0 and the virtual volumes have not yet been reclaimed. A detailed example follows.
In the example, the following names are used:

On the source server:

SRC_SRV = source server
SRC_PRIMSTG = source primary pool
SRC_VIRTPOOL = source copy pool (uses virtual volumes)
MYNODE = node name defined on SRC_SRV

On the target server:

TGT_SRV = target server
TGT_POOL = target archive pool
SRC_NODE = node name with type=server, which SRC_SRV uses to store virtual volume data

In this configuration, the deletion grace period used for the virtual volumes is set to 0.

Assuming that the MYNODE client has backed up 6 files (for a total of 126.7 MB) to the SRC_SRV server, query commands on the SRC_SRV server return the following information:

tsm: SRC_SRV>q vol
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- ----- --------
C:\TSMDATA\FILE\00000320.BFS SRC_PRIMSTG FILE 200.0 63.3 Filling



tsm: SRC_SRV>q con C:\TSMDATA\FILE\00000320.BFS

Node Name Type Filespace FSID Client's Name for File
Name
------------ ---- ---------- ---- -------------------------------------
MYNODE Bkup \\xyz\c$ 14 \ TEMP
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE1
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE2
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE3
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE4
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE5


tsm: SRC_SRV>q occ MYNODE

Node Name Type Filespace FSID Storage Number of Physical Logical
Name Pool Name Files Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- --------- --------- ---------
MYNODE Bkup \\xyz\c$ 14 SRC_PRIMSTG 6 126.69 126.69


What the above shows is that the MYNODE client has backed up 6 objects (1 directory and 5 files) to the source server, and that the total amount of space used is about 126.7 MB.
Following that, a BACKUP STG command is issued to back up the SRC_PRIMSTG pool to the SRC_VIRTPOOL copy pool:

tsm: SRC_SRV>backup stg SRC_PRIMSTG SRC_VIRTPOOL
ANS8003I Process number 5 started.

10/05/2006 10:38:13 ANR1214I Backup of primary storage pool SRC_PRIMSTG to copy storage pool SRC_VIRTPOOL has ended. Files Backed Up: 6, Bytes Backed Up: 132847365, Unreadable Files: 0, Unreadable Bytes: 0. (SESSION: 5)

Following this, a new virtual volume is now created on the source server:

tsm: SRC_SRV>q vol

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- ----- --------

C:\TSMDATA\00000320.BFS SRC_PRIMSTG FILE 200.0 63.3 Filling
TGT_SRV.BFS.160055481 SRC_VIRTPOOL VIRTDEV 126.7 100.0 Full


So, at the end of BACKUP STG command, there is a new volume created on the SRC_SRV server that is named TGT_SRV.BFS.160055481. The data for this virtual volume will be stored on the TGT_SRV server as a single archive file. Specifically, on TGT_SRV target server, we have :

tsm: TGT_SRV>q vol

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- ----- --------

C:\TSMDATA\0000004B.BFS TGT_POOL FILE 300.0 42.2 Filling


tsm: TGT_SRV>q con C:\TSMDATA\0000004B.BFS

Node Name Type Filespace FSID Client's Name for File
Name
-------- ---- ---------- ---- -------------------------------------
SRC_NODE Arch ADSM.SERVER 1 ADSM/TGT_SRV.BFS.160055481BFS.OBJ.1


tsm: TGT_SRV>q occ src_node

Node Name Type Filespace FSID Storage Number of Physical Logical
Name Pool Name Files Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- --------- --------- ---------
SRC_NODE Arch ADSM.SERVER 1 TGT_POOL 1 126.71 126.71


And so, the data at the target server was written on volume C:\TSMDATA\0000004B.BFS
and the content of that volume shows one file, ADSM/TGT_SRV.BFS.160055481BFS.OBJ.1,
which corresponds to the virtual volume on the source server.
The query occupancy shows that the node used to write the virtual volume on the target server (src_node) and wrote one file only, with a total of 126.7 MB.

So, at this point, the source server has 6 objects for a total of 126.7 MB, and the target server has one object for a total of 126.7 MB.

Now, the MYNODE client expires a file on the source server:

C:\tsm\baclient>dsmc expire c:\temp\file3 -su=no -node=MYNODE

A subsequent expiration process then deletes the expired file (assuming that verdeleted=0 as in this case):

tsm: SRC_SRV>expire inventory

10/05/2006 10:48:15 ANR0812I Inventory file expiration process 6 completed:
examined 4 objects, deleting 1 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. (SESSION: 5, PROCESS: 6)

So, after this expiration process, there are now 5 objects left for the MYNODE client, 1 directory and 4 files, for a total of 101 MB, instead of 6 objects and 126.7 MB as indicated by the QUERY OCCUPANCY and QUERY CONTENT commands below :

tsm: SRC_SRV>q occ MYNODE
Node Name Type Filespace FSID Storage Number of Physical Logical
Name Pool Name Files Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- --------- --------- ---------
MYNODE Bkup \\xyz\c$ 14 SRC_PRIMSTG 5 101.35 101.35
MYNODE Bkup \\xyz\c$ 14 VIRTPOOL 5 101.35 101.35


tsm: SRC_SRV>q con TGT_SRV.BFS.160055481
Node Name Type Filespace FSID Client's Name for File
Name
------------ ---- ---------- ---- ------------------------------------
MYNODE Bkup \\xyz\c$ 14 \ TEMP
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE1
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE2
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE4
MYNODE Bkup \\xyz\c$ 14 \TEMP\ FILE5


Reclamation is then run on both source and target servers, and expiration is also run on the target server. However, on the target server, the amount of data stored for the SRC_NODE is still 126.7MB, and not the 101.35 MB now that one file has expired on the source server.
The QUERY OCCUPANCY command on the target server shows :

tsm: TGT_SRV>q occ server1_node

Node Name Type Filespace FSID Storage Number of Physical Logical
Name Pool Name Files Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- --------- --------- ---------
SRC_NODE Arch ADSM.SERVER 1 TGT_POOL 1 126.71 126.71


So, at this point, the source server has 5 objects for a total of 101.35 MB,
and the target server has 1 object for a total of 126.7 MB.

Why? Because there is nothing to reclaim on the source server virtual volume. The QUERY VOLUME command on the source server shows the amount of reclaimable space:

tsm: SRC_SRV>q vol TGT_SRV.BFS.160055481 f=d

Volume Name: TGT_SRV.BFS.160055481
Storage Pool Name: SRC_VIRTPOOL
Device Class Name: VIRTDEV
Estimated Capacity (MB): 126.7
Scaled Capacity Applied:
Pct Util: 80.0
Volume Status: Full
Access: Read/Write
Pct. Reclaimable Space: 20.0
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 1
Write Pass Number: 1
Approx. Date Last Written: 10/05/2006 10:38:13
Approx. Date Last Read: 10/05/2006 10:38:13
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location: TGT_SRV
Volume is MVS Lanfree Capable : No
Last Update by (administrator):
Last Update Date/Time: 10/05/2006 10:38:02


This shows that the virtual volume is FULL, but with only 20% reclaimable space. Because the SRC_VIRTPOOL is set with reclaim=60, this virtual volume is not eligible for reclamation on the source server.

So, when should the same amount of data between a source server and a target server be expected ? When all virtual volumes on the source server have 0% reclaimable space and are all full, and the deletion grace period used for virtual volumes is 0.