TSM seems to always do full backup

[MrHPUX]

I have the TSM client 5.1.5 loaded on many AIX 5.1 servers.
On a couple of these servers, it seems as though an incremental backup is not occuring. Virtually all files are getting backed up every time a incremental backup is run. I am including the summary section from two of the servers I am having problems with.

BTW, the same problem occurs even when I manually run a incremental backup.

07/07/03 08:54:12 Total number of objects inspected: 57,007
07/07/03 08:54:12 Total number of objects backed up: 56,973

07/07/03 08:54:12 Total number of objects updated: 0 07/07/03 08:54:12 Total number of objects rebound: 0 07/07/03 08:54:12 Total number of objects deleted: 0
07/07/03 08:54:12 Total number of objects expired: 0
07/07/03 08:54:12 Total number of objects failed: 3
07/07/03 08:54:12 Total number of bytes transferred: 6.18 GB
07/07/03 08:54:12 Data transfer time: 7,246.49 sec
07/07/03 08:54:12 Network data transfer rate: 895.59 KB/sec
07/07/03 08:54:12 Aggregate data transfer rate: 160.81 KB/sec
07/07/03 08:54:12 Objects compressed by: 0%
07/07/03 08:54:12 Elapsed processing time: 11:12:36



07/07/03 05:16:34 Total number of objects inspected: 24,269
07/07/03 05:16:34 Total number of objects backed up: 24,248
07/07/03 05:16:34 Total number of objects updated: 0
07/07/03 05:16:34 Total number of objects rebound: 0
07/07/03 05:16:34 Total number of objects deleted: 0
07/07/03 05:16:34 Total number of objects expired: 0
07/07/03 05:16:34 Total number of objects failed: 0
07/07/03 05:16:34 Total number of bytes transferred: 553.88 MB
07/07/03 05:16:34 Data transfer time: 421.97 sec
07/07/03 05:16:34 Network data transfer rate: 1,344.10 KB/sec
07/07/03 05:16:34 Aggregate data transfer rate: 21.26 KB/sec
07/07/03 05:16:34 Objects compressed by: 0%
07/07/03 05:16:34 Elapsed processing time: 07:24:25

 

[comtec17]

What is it that you are backing up?

How are you backing them up? Selective/Archive/Inc

If you have database directories or files or an application that touchs the files all the time they will backup.

 

[MrHPUX]

I am backing up the files with inc
The files/directories are NOT database files. This problem exists even when I backup only the / (root) filesystem.

Brian
<*(((>< er

 

[gwichman]

Assuming the above is true and you are indeed backing up all files, you'll need to give more info on how you do your incremental backups (how are they being initiated? can we see your schedule that initiated them? &quot;q sched f=d&quot; for the one in question). It might also be useful to see your dsm.opt and dsm.sys files on one of the servers.

 

[comtec17]

What version of TSM server are you using?

 

[MrHPUX]

This problem exists even when I perform a manual incremental backup. The syntax I have been testing with is:
tsm> incr -ver /

after this backup completes, if I issue the same command, all files backup again.

This problem also occurrs when the schedule comes from the server.

Server Version 5, Release 1, Level 1.0

dsm.opt
************************************************************************
* Tivoli Storage Manager *
* *
* Sample Client User Options file for AIX and SunOS (dsm.opt.smp) *
************************************************************************

* This file contains an option you can use to specify the TSM
* server to contact if more than one is defined in your client
* system options file (dsm.sys). Copy dsm.opt.smp to dsm.opt.
* If you enter a server name for the option below, remove the
* leading asterisk (*).

************************************************************************

* SErvername A server name defined in the dsm.sys file
quiet

dsm.sys
************************************************************************
* Tivoli Storage Manager *
* *
* Sample Client System Options file for AIX and SunOS (dsm.sys.smp) *
************************************************************************

* This file contains the minimum options required to get started
* using TSM. Copy dsm.sys.smp to dsm.sys. In the dsm.sys file,
* enter the appropriate values for each option listed below and
* remove the leading asterisk (*) for each one.

* If your client node communicates with multiple TSM servers, be
* sure to add a stanza, beginning with the SERVERNAME option, for
* each additional server.

************************************************************************

SErvername server_a
COMMmethod TCPip
TCPPort 1500
TCPServeraddress core2-crp-day1-tsmp3
ErrorLogName /var/tsm/dsmerror.log
SchedLogName /var/tsm/dsmsched.log
SchedLogRetention 30

PASSWORDACCESS GENERATE
Managedservices schedule webclient

 

[gwichman]

ok nothing you're doing is wrong. Have you performed a query to see if TSM is indeed saving multiple copies of the same file?

 

[MrHPUX]

It does not appear that the TSM server is saving multiple copies.

 

[gwichman]

So if you run a simple little test.. make a directory and touch/vi some test files in it.. back it up twice in a row.. does it back up both files on both runs? I suspect not..

What i suspect is happening is your retention settings are expiring old copies of data by time the next backup runs and thus it backs them all up again. do a &quot;q co f=d&quot; and dump the output here. It should give us an idea of what your retention settings are at. Specifically you could do it just for the copygroup those particular nodes are under.

 

[MrHPUX]

The problem has been solved. The server had a setting that was forcing a complete backupup each time.

Thanks for all the responses.

Brian
<*(((>< er

 

[ddlldd2000]

Hi MrHPUX,

Where do you find the option to force full backup each time on server?

Thanks,

David

 

[Cr4igy]

It was probably set to absolute instead of modified in the copygroup settings...

Craigy

 

[nickyxx9]

I had a problem with similar symptoms - TSM was doing what looked like a full backup every time.

My problem was caused by trying to be too clever with Exclude statements.

I had one job that ran to back up most of the R: drive to a disk storage pool, and another job to back up R:\index to a tape storage pool. for the first job I ran:
dsmc inc -optfile=dsm.opt, with the optfile specifying the domain R:.

For the second job I ran:
dsmc inc -optfile=index.opt with the optfile specifying a default EXCLUDE of the R: drive, and just an include of R:\index going to a different management class.

When the second job ran, it excluded and therefore expired everything that had been backed up by the first job.

So the next backup, everything got backed up again.

The guy from TSM support said it was an easy mistake to make but I think he was just being kind...