<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Ash,<br>
<br>
This is the primary reason for using snapshots for mmbackup ( -S
snapname ) and making sure that only mmbackup sends data to backup
rather than an oob dsmc:<br>
<br>
Tue Jan 17 18:07:31 2017 mmbackup:Audit files
/cs/mmbackup.audit.gpfs* contain 0 failed paths but there were 10012
failures.
<br>
Cannot reconcile shadow database.
<br>
Unable to compensate for all TSM errors in new shadow database.
<br>
Preserving previous shadow database.
<br>
Run next mmbackup with -q to synchronize shadow database. exit
12
<------------ ick!<br>
<br>
Other obvious causes are very, very, odd filenames / paths.<br>
<br>
Jez<br>
<br>
<br>
<div class="moz-cite-prefix">On 28/02/17 16:10, Ashish Thandavan
wrote:<br>
</div>
<blockquote
cite="mid:adb44dd5-63d1-0d8a-ff33-a3fc207ed258@cs.ox.ac.uk"
type="cite">Dear all,
<br>
<br>
We have a small GPFS cluster and a separate server running TSM and
one of the three NSD servers backs up our GPFS filesystem to the
TSM server using mmbackup. After a recent upgrade from v3.5 to
4.1.1, we've noticed that mmbackup no longer logs stuff like it
used to :
<br>
<br>
...
<br>
Thu Jan 19 05:45:41 2017 mmbackup:Backing up files: 0 backed up,
870532 expired, 2 failed.
<br>
Thu Jan 19 06:15:41 2017 mmbackup:Backing up files: 0 backed up,
870532 expired, 3 failed.
<br>
Thu Jan 19 06:45:41 2017 mmbackup:Backing up files: 0 backed up,
870532 expired, 3 failed.
<br>
...
<br>
<br>
<br>
instead of
<br>
<br>
...
<br>
Sat Dec 3 12:01:00 2016 mmbackup:Backing up files: 105030 backed
up, 635456 expired, 30 failed.
<br>
Sat Dec 3 12:31:00 2016 mmbackup:Backing up files: 205934 backed
up, 635456 expired, 57 failed.
<br>
Sat Dec 3 13:01:00 2016 mmbackup:Backing up files: 321702 backed
up, 635456 expired, 169 failed.
<br>
...
<br>
<br>
like it used to pre-upgrade.
<br>
<br>
I am therefore unable to see how far long it has got, and indeed
if it completed successfully, as this is what it logs at the end
of a job :
<br>
<br>
...
<br>
Tue Jan 17 18:07:31 2017 mmbackup:Completed policy backup run with
0 policy errors, 10012 files failed, 0 severe errors, returning
rc=9.
<br>
Tue Jan 17 18:07:31 2017 mmbackup:Policy for backup returned 9
Highest TSM error 12
<br>
mmbackup: TSM Summary Information:
<br>
Total number of objects inspected: 20617273
<br>
Total number of objects backed up: 0
<br>
Total number of objects updated: 0
<br>
Total number of objects rebound: 0
<br>
Total number of objects deleted: 0
<br>
Total number of objects expired: 1
<br>
Total number of objects failed: 10012
<br>
Total number of objects encrypted: 0
<br>
Total number of bytes inspected: 3821624716861
<br>
Total number of bytes transferred: 3712040943672
<br>
Tue Jan 17 18:07:31 2017 mmbackup:Audit files
/cs/mmbackup.audit.gpfs* contain 0 failed paths but there were
10012 failures.
<br>
Cannot reconcile shadow database.
<br>
Unable to compensate for all TSM errors in new shadow database.
<br>
Preserving previous shadow database.
<br>
Run next mmbackup with -q to synchronize shadow database. exit
12
<br>
<br>
If it helps, the mmbackup job is kicked off with the following
options :
<br>
/usr/lpp/mmfs/bin/mmbackup gpfs -n 8 -t full -B 20000 -L 1
--tsm-servers gpfs_weekly_stanza -N glossop1a | /usr/bin/tee
/var/log/mmbackup/gpfs_weekly/backup_log.`date +%Y%m%d_%H_%M`
<br>
<br>
(The excerpts above are from the backup_log.<datestamp>
file.)
<br>
<br>
Our NSD servers are running GPFS 4.1.1-11, TSM is at 7.1.1.100 and
the File system version is 12.06 (3.4.0.3). Has anyone else seen
this behaviour with mmbackup and if so, found a fix?
<br>
<br>
Thanks,
<br>
<br>
Regards,
<br>
Ash
<br>
<br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<div>
<font color="#000000" face="arial">
<b>Jez Tucker</b><br>
Head of Research and Development, Pixit Media<br>
07764193820 <font color="#FF0000">|</font> <a
href="mailto:jtucker@pixitmedia.com">jtucker@pixitmedia.com</a><br>
<a href="http://www.pixitmedia.com">www.pixitmedia.com</a> <font
color="#FF0000">|</font> <a
href="https://twitter.com/PixitMedia">Tw:@pixitmedia.com</a><br>
</font>
</div>
</div>
</body>
</html>
<br>
<div><a href="http://pixitmedia.com" style="font-size:1.3em;font-family:Arial,Helvetica,sans-serif" target="_blank"><img src="http://pixitmedia.com/sig/BVE-Banner4.png"></a><br><font face="Arial, Helvetica, sans-serif" size="1">This email is confidential in that it is intended for the exclusive attention of the addressee(s) indicated. If you are not the intended recipient, this email should not be read or disclosed to any other person. Please notify the sender immediately and delete this email from your computer system. Any opinions expressed are not necessarily those of the company from which this email was sent and, whilst to the best of our knowledge no viruses or defects exist, no responsibility can be accepted for any loss or damage arising from its receipt or subsequent use of this email.</font></div>