View Files Backup in the Last Backup

[mbrown89]

Hi all

My first time posting to the forum!
We seem to be backing up 1-4TB of data overnight to our TSM server which would be normal if our users have created a lot of data but I've not seen much data being created. I'd like to be able to see what data was backup during the last backup. Is this possible? Am I able to see a list of files and directories?
Thanks!

 

[marclant]

The easiest method and in human readable format it to look at the dsmsched.log on the client if it was a scheduled backup.

From the server, it's ugly, really ugly. The data is not stored in a way that it's associated with a given backup, it just has a backup date. So you need to first know when the backup started and ended.

So let's say you have the following:
nodename: NODE1
backup started at: 2018-08-15 22:00:00
backup ended at: 2018-08-16 07:36:00

You would use this query:

select node_name,hl_name,ll_name,backup_date,actual_size from backups where backup_date>'2018-08-14 22:00:00.000000' and backup_date<'2018-08-15 07:36:00.000000' and node_name='NODE1' order by hl_name,ll_name

The node name (NODE1) had to be in uppercase.
The date/time has to be in the exact same format as my example including the milliseconds to 6 positions.

hl_name is the directory name
ll_name is the filename

 

[mbrown89]

Thanks marclant. the SQL query worked a treat. I don't have a dsmsched.log. I looked it up and from what I can tell it should be in `/opt/tivoli/tsm/client/ba/bin/`. It doesn't exist so looks like I need to enable it somehow!

 

[marclant]

Thanks marclant. the SQL query worked a treat. I don't have a dsmsched.log. I looked it up and from what I can tell it should be in `/opt/tivoli/tsm/client/ba/bin/`. It doesn't exist so looks like I need to enable it somehow!

It's enabled by default, but only for backups scheduled with Spectrum Protect, not manual or scheduled with a 3rd party scheduler line cron or other.

If not in the path you pointed out, it will be in $DSM_LOG if defined or in "schedlogname" option in dsm.opt.

 

[ILCattivo]

I have found that by default the baclient on Linux servers puts the dsmerror & dsmsched log files in '/var/logs' . For RHEL\CENTOS anyway...

Might also be 'dsm.sys' where the log files are defined for Linux clients..

 

[mbrown89]

I have found that by default the baclient on Linux servers puts the dsmerror & dsmsched log files in '/var/logs' . For RHEL\CENTOS anyway...

Might also be 'dsm.sys' where the log files are defined for Linux clients..

Our TSM runs on Linux and dsmerror.log does indeed live in /var/logs/mmbackup/

It's enabled by default, but only for backups scheduled with Spectrum Protect, not manual or scheduled with a 3rd party scheduler line cron or other.

If not in the path you pointed out, it will be in $DSM_LOG if defined or in "schedlogname" option in dsm.opt.

Our backup is scheduled using cron so based on your response it would explain why dsmsched.log isn't being created. `schedlogname` isn't defined in `dsm.opt` or `dsm.sys`.

I have found an audit log which `mmbackup` is being piped out to. I'm able to go through that and find what's been backed up. I'll make a change to `dsm.opt` to include schedlogname as a learning exercise.

Thanks both for your help!

 

[marclant]

I'll make a change to `dsm.opt` to include schedlogname as a learning exercise.

It won't change anything. The schedlogname as a default value of dsmsched.log in the client directory. You can change the name and location with the option, but it only works if the backup is scheduled with Spectrum Protect. The output file you got from mmbackup will be what you need to use in your case.

 

[mbrown89]

It won't change anything. The schedlogname as a default value of dsmsched.log in the client directory. You can change the name and location with the option, but it only works if the backup is scheduled with Spectrum Protect. The output file you got from mmbackup will be what you need to use in your case.

I ran `q options` in `dsmc` and noted `SCHEDLOGNAME` does have an entry. So that definitely confirms what you said marclant.