TSM v7.x Image Backup Occupancy

[booman55]

We recently upgraded from v6.3.x to v7.1.4.100 and noticed that our image backups are storing hundreds of files now when the backup statistics still show them sending a single large file.

Does v7.1.x chunk these files now when storing them in TSM server??

Thanks in advance.

 

[moon-buddy]

Not sure but I believe the answer is yes.

It used to be one large file but the restore speeds was bad. I heard in the past that they will be redesigning this to get more restore speed. Maybe this is it.

 

[booman55]

Thanks...that was my suspicion as well.

 

[marclant]

Starting at 7.1.1, TSM is using SPLITLARGEObjects from the node attribute to split objects larger than 10GB.

source: https://www.ibm.com/support/knowled....itsm.srv.upgrd.doc/r_srv_upgrd_cmds_upd.html

SPLITLARGEObjects
Specifies whether large objects that are stored by this node are automatically split into smaller pieces, by the server, to optimize server processing. The parameter is optional. Specifying Yes causes the server to split large objects (over 10 GB) into smaller pieces when stored by a client node. Specifying No bypasses this process. Specify No only if your primary concern is maximizing throughput of backups directly to tape. The default value is Yes.

source: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.3/srv.reference/r_cmd_node_register.html

 

[booman55]

Thanks Marclant...I've been going nuts trying to find this. Taking this a step further I think it still binds these smaller objects together when calculating occupancy. For example, when migration is running it will move the smaller files, but pct utilized in storage pool won't update until all of the chunks have been moved. The same goes for backup storage pool copy. If I sql query the storage pool occupancy, I'm seeing a 20 TB deficit in offsite pool and I know it's not that far behind. We've had to cancel backup storage pool a few times to eject tapes, so it's behind but not by 20 TB.

Not sure if I want to turn this off or not. Backups have been running pretty good.

 

[marclant]

For example, when migration is running it will move the smaller files, but pct utilized in storage pool won't update until all of the chunks have been moved.

That would make sense, it's still one backup object (1 file/1 db/1 image), but it's divided in chunks. So occupancy would only be updated once the whole file/image/db (all chuncks) have been migrated.

Not sure if I want to turn this off or not. Backups have been running pretty good.

If you do, it's done at the node level. But since the default is ON, that means that's what is recommended, plus as you say backups are running good, so why fix something that's not broken.

 

[marclant]

One advantage of this is less log pinning because transactions finish sooner. So let's say you were migrating or doing a backup stgpool and processing a 500GB image, that would be a single transaction that would pin the log which can lead to performance problems and worse case fill the logs and crash the server. So by splitting in 10GB chunks, at every 10GB, the transaction is closed and a new one starts for the next chunk.

 

[booman55]

Agreed on all points. Thanks for info.